From 7a9c882067189c70502e86cb9b820cb836d064ec Mon Sep 17 00:00:00 2001 From: Garrett Spong Date: Wed, 5 Jun 2024 17:19:49 -0600 Subject: [PATCH 01/25] Adds Security Labs Knowledge Base content --- .../knowledge_base/index.ts | 26 +- ...stic_global_threat_report_announcement.mdx | 15 + ...aders_navigate_todays_threat_landscape.mdx | 41 ++ .../security_labs/500ms_to_midnight.mdx | 177 +++++ ...ikes_using_a_new_variant_of_rustbucket.mdx | 344 +++++++++ ...ws_Libraries_for_Execution_and_Evasion.mdx | 246 +++++++ .../a_peek_behind_the_bpfdoor.mdx | 428 +++++++++++ ...elastic_detection_tradecraft_with_llms.mdx | 83 +++ ...used_in_malaysian_focused_apt_campaign.mdx | 238 +++++++ ...o_large_scale_dynamic_malware_analysis.mdx | 232 ++++++ .../analysis_of_log4shell_cve_2021_45046.mdx | 66 ++ ...ck_chain_leads_to_xworm_and_agenttesla.mdx | 224 ++++++ ..._protections_rapid_response_to_malware.mdx | 48 ++ ...behind_the_scenes_global_threat_report.mdx | 45 ++ .../blister_configuration_extractor.mdx | 65 ++ .../security_labs/blister_loader.mdx | 471 ++++++++++++ .../bpfdoor_configuration_extractor.mdx | 96 +++ .../security_labs/bpfdoor_scanner.mdx | 105 +++ .../bughatch_malware_analysis.mdx | 528 ++++++++++++++ ...ting_protections_testing_with_detonate.mdx | 67 ++ ...ng_and_detection_with_elastic_security.mdx | 193 +++++ .../cobalt_strike_beacon_extractor.mdx | 125 ++++ ...izing_threat_data_from_the_mozi_botnet.mdx | 450 ++++++++++++ ..._strike_beacons_with_the_elastic_stack.mdx | 113 +++ .../cuba_ransomware_campaign_analysis.mdx | 522 ++++++++++++++ .../cuba_ransomware_malware_analysis.mdx | 443 ++++++++++++ ...ancing_the_night_away_with_named_pipes.mdx | 102 +++ .../deep_dive_into_the_ttd_ecosystem.mdx | 326 +++++++++ .../detect_credential_access.mdx | 316 +++++++++ ...m_activity_with_new_kibana_integration.mdx | 115 +++ ..._responding_to_dirty_pipe_with_elastic.mdx | 274 +++++++ ...d_attacks_with_new_elastic_integration.mdx | 145 ++++ ...detecting_log4j2_with_elastic_security.mdx | 310 ++++++++ ...y_exploited_proxyshell_vulnerabilities.mdx | 18 + ...tection_rules_for_sigred_vulnerability.mdx | 118 +++ .../disclosing_the_bloodalchemy_backdoor.mdx | 402 +++++++++++ .../dissecting_remcos_rat_part_four.mdx | 265 +++++++ .../dissecting_remcos_rat_part_one.mdx | 311 ++++++++ .../dissecting_remcos_rat_part_three.mdx | 367 ++++++++++ .../dissecting_remcos_rat_part_two.mdx | 237 +++++++ .../doing_time_with_the_yipphb_dropper.mdx | 520 ++++++++++++++ .../doubling_down_etw_callstacks.mdx | 217 ++++++ ...tecting_lrpc_based_parent_pid_spoofing.mdx | 204 ++++++ .../elastic_advances_llm_security.mdx | 252 +++++++ ...tic_catches_dprk_passing_out_kandykorn.mdx | 671 ++++++++++++++++++ .../elastic_charms_spectralviper.mdx | 559 +++++++++++++++ ...alware_targeting_ukraine_hermeticwiper.mdx | 248 +++++++ ...23_global_threat_report_spring_edition.mdx | 29 + ...ing4shell_vulnerability_cve_2022_22965.mdx | 54 ++ ...ecurity_labs_discovers_lobshot_malware.mdx | 383 ++++++++++ ...curity_labs_releases_llm_safety_report.mdx | 22 + ...ity_labs_steps_through_the_r77_rootkit.mdx | 378 ++++++++++ ...rity_opens_public_detection_rules_repo.mdx | 11 + .../elastic_security_research_roundup.mdx | 38 + ...rity_uncovers_blister_malware_campaign.mdx | 215 ++++++ .../security_labs/elastic_siem_detections.mdx | 12 + ...ed_from_suddenicon_supply_chain_attack.mdx | 150 ++++ ..._navigating_todays_growing_threatscape.mdx | 54 ++ .../embedding_security_in_llm_workflows.mdx | 498 +++++++++++++ ...ng_detections_against_koadic_using_eql.mdx | 239 +++++++ .../emotet_configuration_extractor.mdx | 68 ++ ...motet_dynamic_configuration_extraction.mdx | 334 +++++++++ ...e_detection_response_and_understanding.mdx | 199 ++++++ .../exploring_the_qbot_attack_pattern.mdx | 474 +++++++++++++ .../exploring_the_ref2731_intrusion_set.mdx | 541 ++++++++++++++ ...es_techniques_and_detection_strategies.mdx | 365 ++++++++++ ...ng_cobalt_strike_beacon_configurations.mdx | 160 +++++ .../fall_2023_global_threat_report_outro.mdx | 58 ++ .../finding_truth_in_the_shadows.mdx | 63 ++ ..._on_9_solutions_burning_down_the_house.mdx | 553 +++++++++++++++ ...ions_2022_elastic_global_threat_report.mdx | 47 ++ ...lnerable_drivers_admin_is_all_you_need.mdx | 75 ++ .../formbook_adopts_cab_less_approach.mdx | 531 ++++++++++++++ ..._detection_thread_creation_trampolines.mdx | 220 ++++++ ...getting_gooey_with_guloader_downloader.mdx | 246 +++++++ ..._the_most_out_of_transforms_in_elastic.mdx | 133 ++++ ...ims_using_defense_evasion_bag_o_tricks.mdx | 360 ++++++++++ ...ng_the_pyramid_with_the_deimos_implant.mdx | 448 ++++++++++++ .../google_cloud_for_cyber_data_analytics.mdx | 654 +++++++++++++++++ ...ogle_workspace_attack_surface_part_one.mdx | 191 +++++ ...ogle_workspace_attack_surface_part_two.mdx | 402 +++++++++++ .../gtr_multipart_series_overview.mdx | 21 + ...or_the_enthusiastic_detection_engineer.mdx | 98 +++ ...al_movement_using_event_query_language.mdx | 279 ++++++++ ...sistence_using_elastic_security_part_1.mdx | 150 ++++ ...sistence_using_elastic_security_part_2.mdx | 216 ++++++ .../security_labs/hunting_memory.mdx | 109 +++ .../hunting_memory_net_attacks.mdx | 77 ++ .../icedid_configuration_extractor.mdx | 68 ++ ...twork_infrastructure_is_alive_and_well.mdx | 322 +++++++++ ...ifying_beaconing_malware_using_elastic.mdx | 154 ++++ ..._with_the_threat_intel_filebeat_module.mdx | 550 ++++++++++++++ .../inital_research_of_jokerspy.mdx | 269 +++++++ ...nside_microsofts_plan_to_kill_pplfault.mdx | 128 ++++ .../into_the_weeds_how_we_run_detonate.mdx | 149 ++++ .../introducing_the_ref5961_intrusion_set.mdx | 528 ++++++++++++++ ...ion_to_hexrays_decompilation_internals.mdx | 497 +++++++++++++ ...invisible_miners_unveiling_ghostengine.mdx | 339 +++++++++ ...days_insights_and_detection_strategies.mdx | 312 ++++++++ .../knotweed_assessment_summary.mdx | 104 +++ ...inux_detection_engineering_with_auditd.mdx | 477 +++++++++++++ .../luna_ransomware_attack_pattern.mdx | 463 ++++++++++++ ...ing_okta_threats_with_elastic_security.mdx | 300 ++++++++ ...ams_from_the_developers_of_siestagraph.mdx | 96 +++ .../netwire_configuration_extractor.mdx | 69 ++ ...twire_dynamic_configuration_extraction.mdx | 248 +++++++ ...exploit_linux_via_privilege_escalation.mdx | 51 ++ ...eping_anymore_somnirecords_wakeup_call.mdx | 65 ++ .../okta_and_lapsus_what_you_need_to_know.mdx | 114 +++ .../security_labs/operation_bleeding_bear.mdx | 265 +++++++ .../parallax_payload_extractor.mdx | 59 ++ ...ling_back_the_curtain_with_call_stacks.mdx | 337 +++++++++ ...s_the_southeast_asian_financial_sector.mdx | 360 ++++++++++ .../security_labs/pikabot_i_choose_you.mdx | 488 +++++++++++++ ...laying_defense_against_gamaredon_group.mdx | 393 ++++++++++ ...ecurity_engineering_stateful_detection.mdx | 161 +++++ .../qbot_configuration_extractor.mdx | 88 +++ .../security_labs/qbot_malware_analysis.mdx | 476 +++++++++++++ ...re_in_the_honeypot_how_we_capture_keys.mdx | 377 ++++++++++ ...rupted_sodinokibi_and_the_supply_chain.mdx | 104 +++ ...tain_persistence_as_an_advanced_threat.mdx | 141 ++++ ...new_developments_of_the_blister_loader.mdx | 192 +++++ .../sandboxing_antimalware_products.mdx | 174 +++++ ...vered_in_asean_member_foreign_ministry.mdx | 467 ++++++++++++ ...within_how_ebpf_interacts_with_signals.mdx | 287 ++++++++ .../sinking_macos_pirate_ships.mdx | 188 +++++ ...peek_elastic_2022_global_threat_report.mdx | 25 + .../spring_cleaning_with_latrodectus.mdx | 583 +++++++++++++++ .../starter_guide_to_understanding_okta.mdx | 423 +++++++++++ ...y_situations_ecsaping_your_threat_data.mdx | 258 +++++++ .../stopping_vulnerable_driver_attacks.mdx | 79 +++ ...mlining_esql_query_and_rule_validation.mdx | 219 ++++++ ..._okta_visibility_and_detection_dorothy.mdx | 123 ++++ ...awing_the_permafrost_of_icedid_summary.mdx | 62 ++ .../the_elastic_container_project.mdx | 516 ++++++++++++++ ..._the_flag_elastic_security_bsides_2020.mdx | 12 + ..._around_the_dance_floor_with_pipedance.mdx | 322 +++++++++ ...alation_via_linux_process_capabilities.mdx | 122 ++++ ...g_financial_services_intrusion_ref0657.mdx | 325 +++++++++ .../security_labs/unpacking_icedid.mdx | 367 ++++++++++ .../unveiling_malware_behavior_trends.mdx | 157 ++++ ...24_intrusion_set_and_related_campaigns.mdx | 594 ++++++++++++++++ ...memory_threats_with_kernel_call_stacks.mdx | 135 ++++ ...and_esre_to_find_similar_user_sessions.mdx | 121 ++++ .../using_llms_to_summarize_user_sessions.mdx | 122 ++++ .../vulnerability_summary_follina.mdx | 37 + .../add_required_kb_resource_metadata.test.ts | 3 + .../add_required_kb_resource_metadata.ts | 4 +- .../content_loaders/esql_loader.test.ts | 13 +- .../langchain/content_loaders/esql_loader.ts | 17 +- .../content_loaders/security_labs_loader.ts | 54 ++ .../elasticsearch_store.ts | 28 +- .../server/routes/knowledge_base/constants.ts | 2 + .../server/assistant/tools/index.ts | 2 + .../tools/security_labs/security_labs_tool.ts | 56 ++ 155 files changed, 35151 insertions(+), 13 deletions(-) create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/2022_elastic_global_threat_report_announcement.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/2022_elastic_global_threat_report_helping_security_leaders_navigate_todays_threat_landscape.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/500ms_to_midnight.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/DPRK_strikes_using_a_new_variant_of_rustbucket.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/Hunting_for_Suspicious_Windows_Libraries_for_Execution_and_Evasion.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/a_peek_behind_the_bpfdoor.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/accelerating_elastic_detection_tradecraft_with_llms.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/advanced_techniques_used_in_malaysian_focused_apt_campaign.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/an_elastic_approach_to_large_scale_dynamic_malware_analysis.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/analysis_of_log4shell_cve_2021_45046.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/attack_chain_leads_to_xworm_and_agenttesla.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/automating_security_protections_rapid_response_to_malware.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/behind_the_scenes_global_threat_report.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/blister_configuration_extractor.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/blister_loader.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/bpfdoor_configuration_extractor.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/bpfdoor_scanner.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/bughatch_malware_analysis.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/click_click_boom_automating_protections_testing_with_detonate.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/cloud_monitoring_and_detection_with_elastic_security.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/cobalt_strike_beacon_extractor.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/collecting_and_operationalizing_threat_data_from_the_mozi_botnet.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/collecting_cobalt_strike_beacons_with_the_elastic_stack.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/cuba_ransomware_campaign_analysis.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/cuba_ransomware_malware_analysis.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/dancing_the_night_away_with_named_pipes.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/deep_dive_into_the_ttd_ecosystem.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/detect_credential_access.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/detect_domain_generation_algorithm_activity_with_new_kibana_integration.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/detecting_and_responding_to_dirty_pipe_with_elastic.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/detecting_living_off_the_land_attacks_with_new_elastic_integration.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/detecting_log4j2_with_elastic_security.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/detection_and_response_for_the_actively_exploited_proxyshell_vulnerabilities.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/detection_rules_for_sigred_vulnerability.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/disclosing_the_bloodalchemy_backdoor.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/dissecting_remcos_rat_part_four.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/dissecting_remcos_rat_part_one.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/dissecting_remcos_rat_part_three.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/dissecting_remcos_rat_part_two.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/doing_time_with_the_yipphb_dropper.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/doubling_down_etw_callstacks.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/effective_parenting_detecting_lrpc_based_parent_pid_spoofing.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/elastic_advances_llm_security.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/elastic_catches_dprk_passing_out_kandykorn.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/elastic_charms_spectralviper.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/elastic_protects_against_data_wiper_malware_targeting_ukraine_hermeticwiper.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/elastic_publishes_2023_global_threat_report_spring_edition.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/elastic_response_to_the_the_spring4shell_vulnerability_cve_2022_22965.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/elastic_security_labs_discovers_lobshot_malware.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/elastic_security_labs_releases_llm_safety_report.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/elastic_security_labs_steps_through_the_r77_rootkit.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/elastic_security_opens_public_detection_rules_repo.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/elastic_security_research_roundup.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/elastic_security_uncovers_blister_malware_campaign.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/elastic_siem_detections.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/elastic_users_protected_from_suddenicon_supply_chain_attack.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/elastics_2022_global_threat_report_a_roadmap_for_navigating_todays_growing_threatscape.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/embedding_security_in_llm_workflows.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/embracing_offensive_tooling_building_detections_against_koadic_using_eql.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/emotet_configuration_extractor.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/emotet_dynamic_configuration_extraction.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/exploring_applications_of_chatgpt_to_improve_detection_response_and_understanding.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/exploring_the_qbot_attack_pattern.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/exploring_the_ref2731_intrusion_set.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/exploring_windows_uac_bypasses_techniques_and_detection_strategies.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/extracting_cobalt_strike_beacon_configurations.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/fall_2023_global_threat_report_outro.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/finding_truth_in_the_shadows.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/flare_on_9_solutions_burning_down_the_house.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/forecast_and_recommendations_2022_elastic_global_threat_report.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/forget_vulnerable_drivers_admin_is_all_you_need.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/formbook_adopts_cab_less_approach.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/get_injectedthreadex_detection_thread_creation_trampolines.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/getting_gooey_with_guloader_downloader.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/getting_the_most_out_of_transforms_in_elastic.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/ghostpulse_haunts_victims_using_defense_evasion_bag_o_tricks.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/going_coast_to_coast_climbing_the_pyramid_with_the_deimos_implant.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/google_cloud_for_cyber_data_analytics.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/google_workspace_attack_surface_part_one.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/google_workspace_attack_surface_part_two.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/gtr_multipart_series_overview.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/handy_elastic_tools_for_the_enthusiastic_detection_engineer.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/hunting_for_lateral_movement_using_event_query_language.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/hunting_for_persistence_using_elastic_security_part_1.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/hunting_for_persistence_using_elastic_security_part_2.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/hunting_memory.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/hunting_memory_net_attacks.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/icedid_configuration_extractor.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/icedids_network_infrastructure_is_alive_and_well.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/identifying_beaconing_malware_using_elastic.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/ingesting_threat_data_with_the_threat_intel_filebeat_module.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/inital_research_of_jokerspy.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/inside_microsofts_plan_to_kill_pplfault.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/into_the_weeds_how_we_run_detonate.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/introducing_the_ref5961_intrusion_set.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/introduction_to_hexrays_decompilation_internals.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/invisible_miners_unveiling_ghostengine.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/itw_windows_lpe_0days_insights_and_detection_strategies.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/knotweed_assessment_summary.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/linux_detection_engineering_with_auditd.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/luna_ransomware_attack_pattern.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/monitoring_okta_threats_with_elastic_security.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/naplistener_more_bad_dreams_from_the_developers_of_siestagraph.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/netwire_configuration_extractor.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/netwire_dynamic_configuration_extraction.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/nimbuspwn_leveraging_vulnerabilities_to_exploit_linux_via_privilege_escalation.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/not_sleeping_anymore_somnirecords_wakeup_call.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/okta_and_lapsus_what_you_need_to_know.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/operation_bleeding_bear.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/parallax_payload_extractor.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/peeling_back_the_curtain_with_call_stacks.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/phoreal_malware_targets_the_southeast_asian_financial_sector.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/pikabot_i_choose_you.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/playing_defense_against_gamaredon_group.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/practical_security_engineering_stateful_detection.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/qbot_configuration_extractor.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/qbot_malware_analysis.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/ransomware_in_the_honeypot_how_we_capture_keys.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/ransomware_interrupted_sodinokibi_and_the_supply_chain.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/ref2924_howto_maintain_persistence_as_an_advanced_threat.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/revisiting_blister_new_developments_of_the_blister_loader.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/sandboxing_antimalware_products.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/siestagraph_new_implant_uncovered_in_asean_member_foreign_ministry.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/signaling_from_within_how_ebpf_interacts_with_signals.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/sinking_macos_pirate_ships.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/sneak_peek_elastic_2022_global_threat_report.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/spring_cleaning_with_latrodectus.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/starter_guide_to_understanding_okta.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/stixy_situations_ecsaping_your_threat_data.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/stopping_vulnerable_driver_attacks.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/streamlining_esql_query_and_rule_validation.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/testing_okta_visibility_and_detection_dorothy.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/thawing_the_permafrost_of_icedid_summary.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/the_elastic_container_project.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/threat_hunting_capture_the_flag_elastic_security_bsides_2020.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/twice_around_the_dance_floor_with_pipedance.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/unlocking_power_safely_privilege_escalation_via_linux_process_capabilities.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/unmasking_financial_services_intrusion_ref0657.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/unpacking_icedid.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/unveiling_malware_behavior_trends.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/update_to_the_REF2924_intrusion_set_and_related_campaigns.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/upping_the_ante_detecting_in_memory_threats_with_kernel_call_stacks.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/using_llms_and_esre_to_find_similar_user_sessions.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/using_llms_to_summarize_user_sessions.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/vulnerability_summary_follina.mdx create mode 100644 x-pack/plugins/elastic_assistant/server/lib/langchain/content_loaders/security_labs_loader.ts create mode 100644 x-pack/plugins/security_solution/server/assistant/tools/security_labs/security_labs_tool.ts diff --git a/x-pack/plugins/elastic_assistant/server/ai_assistant_data_clients/knowledge_base/index.ts b/x-pack/plugins/elastic_assistant/server/ai_assistant_data_clients/knowledge_base/index.ts index 1e867ac4ae468..3be99c6809c9a 100644 --- a/x-pack/plugins/elastic_assistant/server/ai_assistant_data_clients/knowledge_base/index.ts +++ b/x-pack/plugins/elastic_assistant/server/ai_assistant_data_clients/knowledge_base/index.ts @@ -26,8 +26,12 @@ import { GetElser } from '../../types'; import { createKnowledgeBaseEntry, transformToCreateSchema } from './create_knowledge_base_entry'; import { EsKnowledgeBaseEntrySchema } from './types'; import { transformESSearchToKnowledgeBaseEntry } from './transforms'; -import { ESQL_DOCS_LOADED_QUERY } from '../../routes/knowledge_base/constants'; +import { + ESQL_DOCS_LOADED_QUERY, + SECURITY_LABS_RESOURCE, +} from '../../routes/knowledge_base/constants'; import { getKBVectorSearchQuery, isModelAlreadyExistsError } from './helpers'; +import { loadSecurityLabs } from '../../lib/langchain/content_loaders/security_labs_loader'; interface KnowledgeBaseDataClientParams extends AIAssistantDataClientParams { ml: MlPluginSetup; @@ -204,13 +208,21 @@ export class AIAssistantKnowledgeBaseDataClient extends AIAssistantDataClient { this.options.logger.debug(`ELSER model '${elserId}' is already deployed`); } - this.options.logger.debug(`Checking if Knowledge Base docs have been loaded...`); - const kbDocsLoaded = (await esStore.similaritySearch(ESQL_DOCS_LOADED_QUERY)).length > 0; - if (!kbDocsLoaded) { - this.options.logger.debug(`Loading KB docs...`); + this.options.logger.debug(`Checking if ESQL Knowledge Base docs have been loaded...`); + const esqlDocsLoaded = (await esStore.similaritySearch(ESQL_DOCS_LOADED_QUERY)).length > 0; + if (!esqlDocsLoaded) { + this.options.logger.debug(`Loading ESQL KB docs...`); await loadESQL(esStore, this.options.logger); } else { - this.options.logger.debug(`Knowledge Base docs already loaded!`); + this.options.logger.debug(`ESQL Knowledge Base docs already loaded!`); + } + + const labsDocsLoaded = await esStore.kbResourceExists(SECURITY_LABS_RESOURCE); + if (!labsDocsLoaded) { + this.options.logger.debug(`Loading Security Labs KB docs...`); + await loadSecurityLabs(esStore, this.options.logger); + } else { + this.options.logger.debug(`Security Labs Knowledge Base docs already loaded!`); } } catch (e) { this.options.logger.error(`Error setting up Knowledge Base: ${e.message}`); @@ -242,7 +254,7 @@ export class AIAssistantKnowledgeBaseDataClient extends AIAssistantDataClient { transformToCreateSchema(changedAt, this.spaceId, authenticatedUser, { // TODO: Update the LangChain Document Metadata type extension metadata: { - kbResource: doc.metadata.kbResourcer ?? 'unknown', + kbResource: doc.metadata.kbResource ?? 'unknown', required: doc.metadata.required ?? false, source: doc.metadata.source ?? 'unknown', }, diff --git a/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/2022_elastic_global_threat_report_announcement.mdx b/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/2022_elastic_global_threat_report_announcement.mdx new file mode 100644 index 0000000000000..e29c3b2989edb --- /dev/null +++ b/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/2022_elastic_global_threat_report_announcement.mdx @@ -0,0 +1,15 @@ +--- +title: "2022 Elastic Global Threat Report Announcement" +slug: "2022-elastic-global-threat-report-announcement" +date: "2022-11-30" +description: "Discover our latest findings & strategic recommendations to better stay informed of potential directions threat actors may focus on." +author: + - slug: devon-kerr +image: "gtr-blog-image-720x420.jpg" +category: + - slug: reports +--- + +Today Elastic Security Labs celebrates another milestone: launching the [2022 Elastic Global Threat Report](https://www.elastic.co/explore/security-without-limits/global-threat-report), our inaugural summary of threat trends, forecasts, and recommendations. We analyzed millions of telemetry events from sources around the world to share these insights with you; all part of our continued commitment to transparency, and our mission to protect the world's data. + +You can find the report [here](https://www.elastic.co/explore/security-without-limits/global-threat-report), we're excited to share it with you. diff --git a/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/2022_elastic_global_threat_report_helping_security_leaders_navigate_todays_threat_landscape.mdx b/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/2022_elastic_global_threat_report_helping_security_leaders_navigate_todays_threat_landscape.mdx new file mode 100644 index 0000000000000..e676f8c21714c --- /dev/null +++ b/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/2022_elastic_global_threat_report_helping_security_leaders_navigate_todays_threat_landscape.mdx @@ -0,0 +1,41 @@ +--- +title: "2022 Elastic Global Threat Report: Helping security leaders navigate today’s threat landscape" +slug: "2022-elastic-global-threat-report-helping-security-leaders-navigate-todays-threat-landscape" +date: "2022-11-30" +description: "A significant percentage of all cyber threats achieve a degree of success against technical, procedural, and human mitigations. So what is a company to do in the face of such unfavorable odds? Find out in this article." +author: + - slug: ken-exner +image: "gtr-blog-image-720x420.jpg" +category: + - slug: reports +--- + +As the threat landscape continues to evolve, cybersecurity stakes are growing exponentially higher for today’s organizations. Between Log4j, geopolitical tension, and increasing ransomware threats, security is not just at the top of the business agenda but also the societal agenda. Meanwhile, threat actors have adopted new capabilities and methods while increasing their cadence of activity. + +Threat detection and response has come a long way since the firewall dissolved and the cloud took center stage. AI and machine learning, for example, have been major contributors to the advancement of cybersecurity. Machine learning is being used to identify malicious behavior from bad actors by modeling network behavior and improving overall threat detection. + +What’s been difficult is the sea of sameness filled with vendors promising products to mitigate today’s threats while preparing for the next one. As the [2022 Elastic Global Threat Report](https://www.elastic.co/explore/security-without-limits/global-threat-report) outlines, a significant percentage of all threats achieve a degree of success against technical, procedural, and human mitigations. So what is a company to do in the face of such unfavorable odds? At Elastic, we believe there are several ingredients that are critical to managing today’s threat landscape. + +## Build a program, not just a tool + +Vendors need to start thinking about security products as more than software. They are part of a living, breathing program that takes care and feeding. For Elastic, it’s not just about shipping a solution; it’s about offering a holistic approach to security that happens to come with a great product. It’s sharing insights and best practices and creating a community focused on security data intelligence that extends the value of Elastic Security for customers. + +The 2022 Elastic Threat Report is an important part of that program, and we’re excited to share our knowledge with the community. In addition to vital information from the Elastic Security Labs team, the report provides actionable guidance to security practitioners about how to maximize positive outcomes for their organizations. + +## It takes an (open) community + +The foundation of any good program is a strong community that can support and foster it. Take Elastic’s commitment to open security, for example. The community born from vendors being transparent about their security controls, detection rules, and threat logic can be a force multiplier of best practices across the entire industry. + +When vendors engage their experts with experts from across the broader security community about new threats they’ve observed or innovative methods for detecting nuanced attacks, it creates greater scalability of system defenses — not just for the enterprise but also for their customers. + +For example, at Elastic we recently opened our Endpoint Security [protections-artifacts repo](https://github.com/elastic/protections-artifacts), adding to our already open [detection-rules repo](https://github.com/elastic/detection-rules/tree/main/rules), to foster further collaboration with our community and be transparent about how we protect users. + +## Treat the cause, not the symptom + +Despite the ever-growing threat landscape and the risks that it poses, many organizations are still treating security symptoms instead of the cause. Companies can no longer afford to keep the security team siloed and separate from the engineering team. The two functions must work closely to build products and solutions that can withstand the barrage of advancing threats. + +At Elastic, we design and build products with security in mind from the start, so it’s baked into every solution we ship to our customers. In fact, we take security so seriously that the office of InfoSec is part of the engineering organization. + +We hope that the 2022 Elastic Global Threat Report will help your understanding of the important shifts in the threat landscape, and provide the information you need to make your organization more resilient, prepared, and protected. + +[Download the 2022 Elastic Global Threat Report](https://www.elastic.co/explore/security-without-limits/global-threat-report). diff --git a/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/500ms_to_midnight.mdx b/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/500ms_to_midnight.mdx new file mode 100644 index 0000000000000..b96b7a0c885bb --- /dev/null +++ b/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/500ms_to_midnight.mdx @@ -0,0 +1,177 @@ +--- +title: "500ms to midnight: XZ / liblzma backdoor" +slug: "500ms-to-midnight" +date: "2024-04-05" +description: "Elastic Security Labs is releasing an initial analysis of the XZ Utility backdoor, including YARA rules, osquery, and KQL searches to identify potential compromises." +author: + - slug: samir-bousseaden + - slug: mika-ayenson + - slug: jake-king +image: "500ms-to-midnight.jpg" +category: + - slug: security-research +tags: + - linux + - vulnerability + - cve-2024-3094 +--- + +## Key Takeaways + +* On March 29, 2024, Andres Freund identified malicious commits to the command-line utility XZ, impacting versions 5.6.0 and 5.6.1 for Linux, and shared the information on the oss-security mailing list. +* Andres’ discovery was made after an increase of _500ms_ in latency was observed with SSH login attempts initiated from a development system, amongst other anomalies. +* The backdoor identified has been designed to circumvent authentication controls within SSH to remotely execute code, potentially gaining access to other systems in the environment. +* The code commits were added and signed by [JiaT75](https://tukaani.org/xz-backdoor) (now suspended), who contributed to the popular open source project for several years. +* Security researchers are still undertaking an initial analysis of the payload, dissecting both the build process and the backdoor. +* Elastic has released both YARA signatures, detection rules, and osquery queries, allowing Linux system maintainers to understand the impact and block potential compromises early. + +## The XZ / liblzma backdoor at a glance + +On March 29 2024, the widely adopted XZ package used within many Linux distributions as a library used by the system to interact with SSH client connections (and many other system utilities) was pulled into the spotlight after a _500ms_ delay with intermittent failures. What began as a routine investigation into that anomaly would take a surprising and unexpected twist: malicious, obfuscated code was planted in the package by a maintainer–code that was also in circulation for a few weeks via a poisoned build process. + +Andres Freund, the developer who initially [identified the malicious contributions](https://www.openwall.com/lists/oss-security/2024/03/29/4), observed that the changes had been implemented in versions `5.6.0` and `5.6.1` of the XZ Utils package but had not been widely adopted across all Linux distributions, outside of select bleeding-edge variants typically used for early-stage testing. + +[Initial analysis](https://bsky.app/profile/filippo.abyssdomain.expert/post/3kowjkx2njy2b) has shown that the backdoor is designed to circumvent authentication controls in `sshd` via `systemd` and attempts to execute code within a pre-authentication context. Observations made so far have shown that the malicious code is not in its final target state and was perhaps caught early through haphazard mistakes the developer neglected to consider, causing impacts to legitimate SSH use cases. + +Alongside the malicious package being circulated within a small number of Linux distributions, several observations have been made in the popular package management software HomeBrew, which has impacted some macOS users. The maintainers of Homebrew-- and other software packages that included this library-- are presently rolling back to prior versions that aren't impacted by these malicious changes, although mainly out of an abundance of caution, as compromised builds were only targeting deb and rpm packages. + +The following notice was released on the Tukaani Project’s homepage (the project owner of the [XZ Utils Git repository](https://github.com/tukaani-project/xz)) shortly after the news of the backdoor broke. + +![XZ Utils backdoor notification on the Tukaani Project](/assets/images/500ms-to-midnight/image2.png "XZ Utils backdoor notification on the Tukaani Project") + + +The compromise itself, while high risk, is relatively minor in terms of real-world impact given the stage of discovery. This situation should remind security professionals about the importance of understanding supply-chain compromise, monitoring Linux workloads, and auditing system controls. In this situation, defenders had the advantage of time. + +## Backdoor analysis + +### XZ backdoor build process: + +[CVE-2024-3094](https://nvd.nist.gov/vuln/detail/CVE-2024-3094) explains how the changes in the `liblzma` were created from the malicious additions to the library’s build scripts and directly impacts any software that links the library on an impacted system. + +The maliciously modified build script is divided into three stages, starting with the additions in `m4/build-to-host.m4` and progressing through the obfuscation and execution stages. At a high level, some obfuscation techniques include character substitution and selective byte processing commands via the `tr` and `head` commands to decode and execute the malicious payloads in the test files. Interestingly, many impacted tools used are standard Linux system tools typically used by administrators for legitimate purposes. + +The [build process](https://gynvael.coldwind.pl/?lang=en&id=782) runs as follows : + +* **Stage 0:** The initial malicious code additions attempt to decode the Stage 1 script (hidden code segments) by changing byte values from specific test files, which under normal circumstances appear corrupt, to form a valid XZ stream. +* **Stage 1:** This stage leverages a bash file with special checks (e.g., the Linux architecture the script runs on) and Bash commands to analyze the environment (e.g. `[ "$(uname)" = "Linux" ]`) to ensure compatible conditions are met for the backdoor. Depending on the outcome of the checks, additional malicious scripts or payloads may be executed. +* **Stage 2:** This phase involves an infected.txt file, which details the altered extraction and compilation code modifications, namely: + * Reconstruction Data: Byte manipulation and decoding techniques on obfuscated compressed data from test files to reconstruct the malicious payload using commands like `sed` and `awk` + * Obfuscation and Extraction: Complex decryption and obfuscation techniques using the `tr` command to extract the binary backdoor to remain hidden from typical detection mechanisms + * Build Process Manipulation: This changes the build and compilation steps to embed the binary backdoor into Linux system processes + * Extension Mechanism: A design that allows for new scripts and updates to the backdoor without modifying the original payload + * Future Stage Preparation: Sets the groundwork for malicious follow-up activities, like propagating the backdoor + +## Assessing impact: + +Given the limited usage of the impacted beta distributions and software, this compromise should impact few systems. Maintainers of Linux systems are however encouraged to ensure systems are not running impacted versions of `xzutils` / `liblzma` by leveraging the following osquery queries: + +[Linux](https://gist.github.com/jamesspi/ee8319f55d49b4f44345c626f80c430f): + +``` +SELECT 'DEB Package' AS source, name, version, + CASE + WHEN version LIKE '5.6.0%' OR version LIKE '5.6.1%' THEN 'Potentially Vulnerable' + ELSE 'Most likely not vulnerable' + END AS status +FROM deb_packages +WHERE name = 'xz-utils' OR name = 'liblzma' OR name LIKE 'liblzma%' +UNION +SELECT 'RPM Package' AS source, name, version, + CASE + WHEN version LIKE '5.6.0%' OR version LIKE '5.6.1%' THEN 'Potentially Vulnerable' + ELSE 'Most likely not vulnerable' + END AS status +FROM rpm_packages +WHERE name = 'xz-utils' OR name = 'liblzma' OR name LIKE 'liblzma%'; + +``` + +[macOS](https://gist.github.com/jamesspi/5cb060b5e0e2d43222a71c876b56daab): + +``` +SELECT 'Homebrew Package' AS source, name, version, + CASE + WHEN version LIKE '5.6.0%' OR version LIKE '5.6.1%' THEN 'Potentially Vulnerable' + ELSE 'Most likely not vulnerable' + END AS status +FROM homebrew_packages +WHERE name = 'xz' OR name = 'liblzma'; +``` + +The following KQL query can be used to query Elastic Defend file events: + +``` +event.category : file and host.os.type : (macos or linux) and file.name : liblzma.so.5.6.* +``` + +Alternatively, manually checking the version of XZ running on a system is as simple as running the [following commands](https://x.com/Kostastsale/status/1773890846250926445?s=20) (from researcher [Kostas](https://twitter.com/Kostastsale)) and checking the output version. Remember, versions 5.6.0 and 5.6.1 are impacted and should be rolled back or updated to a newer version. + +``` +for xz_p in $(type -a xz | awk '{print $NF}' | uniq); do strings "$xz_p" | grep "xz (XZ Utils)" || echo "No match found for $xz_p"; done +``` + +## Malware protection + +The following [YARA signature](https://github.com/elastic/protections-artifacts/blob/main/yara/rules/Linux_Trojan_XZBackdoor.yar) (disk and in-memory) is deployed in Elastic Defend to block the XZ backdoor. + +``` +rule Linux_Trojan_XZBackdoor { + meta: + author = "Elastic Security" + fingerprint = "f1982d1db5aacd2d6b0b4c879f9f75d4413e0d43e58ea7de2b7dff66ec0f93ab" + creation_date = "2024-03-30" + last_modified = "2024-03-31" + threat_name = "Linux.Trojan.XZBackdoor" + reference_sample = "5448850cdc3a7ae41ff53b433c2adbd0ff492515012412ee63a40d2685db3049" + severity = 100 + arch_context = "x86" + scan_context = "file, memory" + license = "Elastic License v2" + os = "linux" + strings: + /* potential backdoor kill-switch as per https://gist.github.com/q3k/af3d93b6a1f399de28fe194add452d01?permalink_comment_id=5006558#file-hashes-txt-L115 */ + $a1 = "yolAbejyiejuvnup=Evjtgvsh5okmkAvj" +/* function signature in liblzma used by sshd */ + $a2 = { F3 0F 1E FA 55 48 89 F5 4C 89 CE 53 89 FB 81 E7 00 00 00 80 48 83 EC 28 48 89 54 24 18 48 89 4C 24 10 } + /* unique byte patterns in backdoored liblzma */ + $b1 = { 48 8D 7C 24 08 F3 AB 48 8D 44 24 08 48 89 D1 4C 89 C7 48 89 C2 E8 ?? ?? ?? ?? 89 C2 } + $b2 = { 31 C0 49 89 FF B9 16 00 00 00 4D 89 C5 48 8D 7C 24 48 4D 89 CE F3 AB 48 8D 44 24 48 } + $b3 = { 4D 8B 6C 24 08 45 8B 3C 24 4C 8B 63 10 89 85 78 F1 FF FF 31 C0 83 BD 78 F1 FF FF 00 F3 AB 79 07 } + condition: + 1 of ($a*) or all of ($b*) +} +``` + +Detections of this signature will appear in Elastic as follows: + +![Detecting the Linux.Trojan.XZBackdoor signature in Elastic](/assets/images/500ms-to-midnight/image4.png "Detecting the Linux.Trojan.XZBackdoor signature in Elastic") + + +## Behavior Detection + +Leveraging [Elastic Defend](https://docs.elastic.co/en/integrations/endpoint)’s network and process events, we published a new EQL [detection rule](https://github.com/elastic/detection-rules/blob/main/rules/linux/persistence_suspicious_ssh_execution_xzbackdoor.toml) to identify instances where the SSHD service starts, spawns a shell process and immediately terminates unexpectedly all within a very short time span: + +``` +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.executable != "/usr/sbin/sshd"] by process.parent.pid, process.parent.entity_id + [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 +``` + +![Matches while simulating execution via the backdoor using XZBot - github.com/amlweems/xzbot](/assets/images/500ms-to-midnight/image1.png "Matches while simulating execution via the backdoor using XZBot - github.com/amlweems/xzbot") + + + +![Timeline view displaying events matching the EQL query](/assets/images/500ms-to-midnight/image3.png "Timeline view displaying events matching the EQL query") + + +## Linux: the final frontier + +While observations of supply chain-based attacks or exploitation of vulnerabilities rarely reach this level of global press coverage, Elastic’s observations described in the [2023 Global Threat Report](https://www.elastic.co/explore/security-without-limits/global-threat-report) show that Linux-based signature events continue to grow in our dataset. This growth is partially tied to growth in the systems we observe that report on threat behavior, but it strongly suggests that adversaries are becoming increasingly focused on Linux systems. + +Linux is and will continue to be on the [minds of threat groups](https://www.elastic.co/security-labs/a-peek-behind-the-bpfdoor), as its widespread adoption across the internet reinforces its importance. In this case, adversarial groups were trying to circumvent existing controls that would allow for future compromise through other means. + +While the objectives of the person(s) behind the XZ backdoor haven’t been made clear yet, it is within the technical capabilities of many threat entities focused on espionage, extortion, destruction of data, intellectual property theft, and human rights abuses. With the ability to execute code on impacted Internet-accessible systems, it’s reasonable to assume that bad actors would further infiltrate victims. Elastic Security Labs sees that Linux visibility has been dramatically improving and enterprises have started to effectively manage their Linux populations, but many organizations reacting to this supply chain compromise are still at the start of that process. diff --git a/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/DPRK_strikes_using_a_new_variant_of_rustbucket.mdx b/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/DPRK_strikes_using_a_new_variant_of_rustbucket.mdx new file mode 100644 index 0000000000000..41e182af17026 --- /dev/null +++ b/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/DPRK_strikes_using_a_new_variant_of_rustbucket.mdx @@ -0,0 +1,344 @@ +--- +title: "The DPRK strikes using a new variant of RUSTBUCKET" +slug: "DPRK-strikes-using-a-new-variant-of-rustbucket" +date: "2023-07-14" +subtitle: "A DPRK campaign using a new variant of the RUSTBUCKET malware is underway with updated capabilities and reduced signature detection." +description: "Watch out! We’ve recently discovered a variant of RUSTBUCKET. Read this article to understand the new capabilities we’ve observed, as well as how to identify it in your own network." +author: +- slug: salim-bitam +- slug: ricardo-ungureanu +- slug: colson-wilhoit +- slug: seth-goodwin +- slug: andrew-pease +image: "photo-edited-12@2x.jpg" +category: +- slug: attack-pattern +- slug: activity-group +tags: +- ref9135 +- rustbucket +- dprk +- bluenoroff +- cryptocurrency +- apt38 +--- +## Key takeaways +- The RUSTBUCKET malware family is in an active development phase, adding built-in persistence and focusing on signature reduction. +- REF9135 actors are continually shifting their infrastructure to evade detection and response. +- The DPRK continues financially motivated attacks against cryptocurrency service providers. +- If you are running Elastic Defend, you are protected from REF9135 + + +## Preamble +The Elastic Security Labs team has detected a new variant of the RUSTBUCKET malware, a family that has been previously attributed to the BlueNorOff group by [Jamf Threat Labs](https://www.jamf.com/blog/bluenoroff-apt-targets-macos-rustbucket-malware/) in April 2023. + +This variant of RUSTBUCKET, a malware family that targets macOS systems, adds persistence capabilities not previously observed and, at the time of reporting, is undetected by VirusTotal signature engines. Elastic Defend behavioral and prebuilt detection rules provide protection and visibility for users. We have also released a signature to prevent this malware execution. + +The research into REF9135 used host, binary, and network analysis to identify and attribute intrusions observed by this research team, and other intelligence groups, with high confidence to the Lazarus Group; a cybercrime and espionage organization operated by the Democratic People’s Republic of North Korea (DPRK). + +This research will describe: + +- REF9135’s use of RUSTBUCKET for sustained operations at a cryptocurrency payment services provider +- Reversing of an undetected variant of RUSTBUCKET that adds a built-in persistence mechanism +- How victimology, initial infection, malware, and network C2 intersections from first and third-party collection align with previous Lazarus Group reporting + + +## RUSTBUCKET code analysis + + +### Overview +Our research has identified a persistence capability not previously seen in the RUSTBUCKET family of malware, leading us to believe that this family is under active development. Additionally, at the time of publication, this new variant has zero detections on VirusTotal and is leveraging a dynamic network infrastructure methodology for command and control. + + + +![Execution flow of REF9135](/assets/images/DPRK-strikes-using-a-new-variant-of-rustbucket/image1.jpg) + +### Stage 1 +During Stage 1, the process begins with the execution of an AppleScript utilizing the **%2Fusr%2Fbin%2Fosascript** command. This AppleScript is responsible for initiating the download of the Stage 2 binary from the C2 using cURL. This session includes the string **pd** in the body of the HTTP request and **cur1-agent** as the User-Agent string which saves the Stage 2 binary to **%2Fusers%2Fshared%2F.pd,** ([7887638bcafd57e2896c7c16698e927ce92fd7d409aae698d33cdca3ce8d25b8](https://www.virustotal.com/gui/file/7887638bcafd57e2896c7c16698e927ce92fd7d409aae698d33cdca3ce8d25b8)). + + + +![Stage 1 command line](/assets/images/DPRK-strikes-using-a-new-variant-of-rustbucket/image2.jpg) + +### Stage 2 +The Stage 2 binary ( **.pd** ) is compiled in Swift and operates based on command-line arguments. The binary expects a C2 URL to be provided as the first parameter when executed. Upon execution, it invokes the **downAndExec** function, which is responsible for preparing a POST HTTP request. To initiate this request, the binary sets the User-Agent string as **mozilla%2F4.0 (compatible; msie 8.0; windows nt 5.1; trident%2F4.0)** and includes the string **pw** in the body of the HTTP request. + + + +![Setting the HTTP parameters before sending the request](/assets/images/DPRK-strikes-using-a-new-variant-of-rustbucket/image12.jpg) + +During execution, the malware utilizes specific macOS APIs for various operations. It begins with [NSFileManager's](https://developer.apple.com/documentation/foundation/nsfilemanager) **temporaryDirectory** function to obtain the current temporary folder, then generates a random UUID using [NSUUID's](https://developer.apple.com/documentation/foundation/nsuuid) **UUID.init** method. Finally, the malware combines the temporary directory path with the generated UUID to create a unique file location and writes the payload to it. + +Once the payload, representing Stage 3 of the attack is written to disk, the malware utilizes [NSTask](https://developer.apple.com/documentation/foundation/nstask) to initiate its execution. + + + +![Generating the Stage 3 file path](/assets/images/DPRK-strikes-using-a-new-variant-of-rustbucket/image11.jpg) + +### Stage 3 +In Stage 3, the malware ([9ca914b1cfa8c0ba021b9e00bda71f36cad132f27cf16bda6d937badee66c747](https://www.virustotal.com/gui/file/9ca914b1cfa8c0ba021b9e00bda71f36cad132f27cf16bda6d937badee66c747)) is a FAT macOS binary that supports both ARM and Intel architectures written in Rust. It requires a C2 URL to be supplied as a parameter. + +The malware initiates its operations by dynamically generating a 16-byte random value at runtime. This value serves as a distinctive identifier for the specific instance of the active malware. Subsequently, the malware proceeds to gather comprehensive system information, including: + +- Computer name +- List of active processes +- Current timestamp +- Installation timestamp +- System boot time +- Status of all running processes within the system + +The malware establishes its initial connection to the C2 server by transmitting the gathered data via a POST request. The request is accompanied by a User-Agent string formatted as **Mozilla%2F4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident%2F4.0)**. + +Upon receiving the request, the C2 server responds with a command ID, which serves as an instruction for the malware. The malware is designed to handle only two commands. + + + +#### Command ID 0x31 +This command directs the malware to self-terminate. + + + +#### Command ID 0x30 +This command enables the operator to upload malicious Mach-O binaries or shell scripts to the system and execute them. The payload is stored in a randomly generated temporary path and created within the current user TMP directory following the naming convention of **`$TMPDIR%2F.\<8 random digits\>`** + +Below is a summary of the command structure, indicating the constants, arguments, and payload components for easy comprehension. + + + +![Command structure example](/assets/images/DPRK-strikes-using-a-new-variant-of-rustbucket/image5.jpg) + +The malware proceeds by granting execution permissions to the uploaded file using the **chmod** API. + +After executing the payload, the malware sends a status update to the server, notifying it of the completed execution, and then sleeps for 60 seconds. Following this delay, the malware loops to collect system information once again and remains in a waiting state, anticipating the arrival of the next command from the server + + + +### The undetected version of RUSTBUCKET +Using code similarities from the sample in our telemetry, we searched VirusTotal and identified an undetected variant of RUSTBUCKET. + +As of the publication of this research, the [newly discovered version](https://www.virustotal.com/gui/file/de81e5246978775a45f3dbda43e2716aaa1b1c4399fe7d44f918fccecc4dd500) of the malware has not been flagged by any antivirus engines on VirusTotal. A thorough analysis of the sample brought to light the addition of a new persistence capability and C2 infrastructure. The behavioral rules for Elastic Defend prevent, and Elastic’s prebuilt detection rules identify, this activity. We have also released a signature that will prevent this new variant of RUSTBUCKET. + + + +![VirusTotal results at the time of publication](/assets/images/DPRK-strikes-using-a-new-variant-of-rustbucket/image7.png) + +### Persistence +A predominant method utilized by malware to achieve persistence on macOS is through the utilization of LaunchAgents. In macOS, users have individual LaunchAgents folders within their Library directory, enabling them to define code that executes upon each user login. Additionally, a system-level LaunchAgents folder exists, capable of executing code for all users during the login process. Elastic Defend monitors for the creation of LaunchAgents and LaunchDaemons containing malicious or suspicious values as a way to detect these persistence techniques. + +In the case of this updated RUSTBUCKET sample, it establishes its own persistence by adding a plist file at the path **`%2FUsers%2F\%2FLibrary%2FLaunchAgents%2Fcom.apple.systemupdate.plist`** , and it copies the malware’s binary to the following path **`%2FUsers%2F\%2FLibrary%2FMetadata%2FSystem Update`**. + + + +![File content of plist used for persistence](/assets/images/DPRK-strikes-using-a-new-variant-of-rustbucket/image9.jpg) + +There are several elements of the plist file, using standard true%2Ffalse or string values: + +- **Label:** The key "Label" specifies the name of the LaunchAgent, which in this case is **com.apple.systemupdate**. This expects a string value. +- **RunAtLoad:** This indicates that the LaunchAgent should execute its associated code immediately upon loading, specifically during system startup or user login. This expects a true%2Ffalse value. +- **LaunchOnlyOnce:** This prevents the malware from being executed multiple times concurrently and expects a true%2Ffalse value. +- **KeepAlive:** This key instructs the system to keep the LaunchAgent running and relaunch it if it terminates unexpectedly. This expects a true%2Ffalse value. +- **ProgramArguments:** The "ProgramArguments" key specifies an array of strings that define the program or script to be executed by the LaunchAgent. This expects a string value and in this case, the LaunchAgent executes the file located at **"`%2FUsers%2F\%2FLibrary%2FMetadata%2FSystem Update`"** and provides the C2 URL **"https:%2F%2Fwebhostwatto.work[.]gd"** as an argument to the malware. + + +## RUSTBUCKET and REF9135 analysis + + +### Overview +The RUSTBUCKET campaign has previously been associated with BlueNorOff by Jamf and Sekoia.io. BlueNorOff is believed to be operating at the behest of the DPRK for the purposes of financial gain in order to ease the strain of global sanctions. BlueNorOff is a sub-unit of the overarching DPRK offensive cyber attack organization, the [Lazarus Group](https://attack.mitre.org/groups/G0032/). The [2016 Bangladesh Bank robbery](https://www.nytimes.com/interactive/2018/05/03/magazine/money-issue-bangladesh-billion-dollar-bank-heist.html) stands out as BlueNorOff's most notorious attack, wherein their objective was to illicitly transfer over $850M from the Federal Reserve Bank of New York account owned by Bangladesh Bank, the central bank of Bangladesh, by exploiting the SWIFT network. + + + +> As an analyst note, if you’re interested in a tremendously verbose and detailed walkthrough of this intrusion, Geoff White and Jean Lee released a 19-part podcast through the [BBC World Service](https://www.bbc.co.uk/programmes/w13xtvg9/episodes/downloads) that is an unbelievable account of this event. + +### Networking infrastructure +The persistence mechanism identified previously calls out to **https:%2F%2Fwebhostwatto.work[.]gd**. Third-party research into this URL indicates that 12%2F89 [VirusTotal](https://www.virustotal.com/gui/url/e299c9f2233f025256ab29d53d070a8f94d1c2c1a2b6f3a7c13e16df185e9e32/detection) vendors have identified it as malicious, and it exists within a community collection documenting the [DangerousPassword phishing campaign](https://www.cyfirma.com/outofband/tracking_dangerouspassword_campaign_by_lazarusgroup/). + + + +![VT detections and community collections for https://webhostwatto.work[.]gd](/assets/images/DPRK-strikes-using-a-new-variant-of-rustbucket/image6.png) + +VirusTotal [last saw](https://www.virustotal.com/gui/domain/webhostwatto.work.gd/detection) the domain pointing to **104.168.167[.]88**. Which has been specifically identified in a Sekoia.io [blog](https://blog.sekoia.io/bluenoroffs-rustbucket-campaign/) in May as part of BlueNorOff’s RUSTBUCKET campaign. + + + +![Updated RUSTBUCKET IP (104.168.167[.]88) previously identified by Sekoia.io](/assets/images/DPRK-strikes-using-a-new-variant-of-rustbucket/image4.jpg) + +Further connecting **webhostwatto.work[.]gd** to DangerousPassword, BlueNorOff, and the DPRK campaigns, this domain shares a TLS leaf certificate fingerprint hash ( **1031871a8bb920033af87078e4a418ebd30a5d06152cd3c2c257aecdf8203ce6** ) with another domain, **companydeck[.]online**. + +**companydesk[.]online** is included in the [VirusTotal Graph](https://www.virustotal.com/graph/g6e8b200cfd774d129558fa5715c83d1bc81099f5cd7643719580be988ec01b8f) (VirusTotal account required) for [APT38](https://attack.mitre.org/groups/G0082/), which is also known as DangerousPassword, BlueNorOff, etc. + + + +![Selection from the VirusTotal Graph for DangerousPassword](/assets/images/DPRK-strikes-using-a-new-variant-of-rustbucket/image3.jpg) + +DangerousPassword and BlueNorOff are campaigns that have both been previously associated with the DPRK. + +Using the IP address (**64.44.141[.]15**) for our initial C2 domain, **crypto.hondchain[.]com**, we uncovered 3 additional C2 domains: + +- **starbucls[.]xyz** +- **jaicvc[.]com** +- **docsend.linkpc[.]net** (dynamic DNS domain) + +While there are only 5 hosts (4 total domains) registered to the C2 IP address (indicating that this was not a high-capacity hosting server), we looked for additional relationships to increase the association confidence between the domains. To do this, we replicated the same fingerprinting process previously used with **webhostwatto.work[.]gd**. The TLS fingerprint hash for **starbucls[.]xyz** ( **788261d948177acfcfeb1f839053c8ee9f325bd6fb3f07637a7465acdbbef76a** ) is the same fingerprint as **jaicvc[.]com**. + +With these two domains having the same TLS fingerprint hash and the fact that they were both registered to the IP address, we were able to cluster these atomic entities, and their siblings, together with high confidence: + +- All hosts were registered to **64.44.141[.]15** +- **starbucls[.]xyz** and **crypto.hondchain[.]com** were observed being used by our malware samples +- **starbucls[.]xyz** and **jaicvc[.]com** shared a TLS fingerprint + + +![Domains registered to REF9135 C2 IP address](/assets/images/DPRK-strikes-using-a-new-variant-of-rustbucket/image8.jpg) + +Looking at the “First” column (when they were first observed through 3rd party passive DNS), these hosts are being created rapidly, likely as an attempt to stay ahead of detection efforts by research teams. We are associating the following domains and IP address to the REF9135 campaign with high confidence: + +- **starbucls[.]xyz** +- **jaicvc[.]com** +- **crypto.hondchain[.]com** +- **64.44.141[.]15** + +We have not observed **docsend.linkpc[.]net** being used with the RUSTBUCKET samples we analyzed. However, its shared IP registration and host siblings lead us to state with a moderate degree of confidence that it is directly related to RUSTBUCKET and REF9135 as C2 infrastructure; and a high degree of confidence that it is malicious (shared infrastructure as part of other campaigns). + + + +### Defense evasion +The campaign owners used techniques to hinder the collection of Stage 2 and Stage 3 binaries by analysts who may have overlooked User-Agent strings in their investigations, as well as internet scanners and sandboxes focused on collecting malicious binaries. + +As outlined in the Stage 1 section, there is a specific User-Agent string ( **cur1-agent** ) that is expected when downloading the Stage 2 binary, if you do not use the expected User-Agent, you will be provided with a 405 HTTP response status code (Method Not Allowed). + +It also appears that the campaign owners are monitoring their payload staging infrastructure. Using the expected User-Agent for the Stage 3 binary download (**mozilla%2F4.0 (compatible; msie 8.0; windows nt 5.1; trident%2F4.0)**), we were able to collect the Stage 3 binary. + +Finally, we observed REF9135 changing its C2 domain once we began to collect the Stage 2 and 3 binaries for analysis. When making subsequent requests to the original server (**crypto.hondchain[.]com**), we received a 404 HTTP response status code (Not Found) and shortly after, a new C2 server was identified (**starbucls[.]xyz**). This could be because we caught the binary before it was rolled off as part of a normal operational security practice (don’t leave your valuable payload attached to the Internet to be discovered) or because they observed a connection to their infrastructure that was not from their targeted network. + +Of note, while the User-Agent strings above could initially appear to be the default cURL or Firefox User-Agents strings to an analyst, they are not. The default cURL User-Agent string is **curl%2Fversion.number** whereas the malware uses **cur1-agent** (using a **1** in place of the **l** in “curl”). Additionally, the “Firefox” string is all lowercase (**mozilla%2F4.0 (compatible; msie 8.0; windows nt 5.1; trident%2F4.0)**), unlike actual [Firefox User-Agent strings](https://www.useragentstring.com/pages/Firefox/) which are camel-cased. + +This requirement to download payloads allows the attackers to restrict distribution to only requestors who know the correct UA string. This provides strong protection against both scanning services and researchers, who would otherwise have early access to hosted malicious files for analysis and detection engineering. + + + +### Victimology +The REF9135 victim is a venture-backed cryptocurrency company providing services to businesses such as payroll and business-to-business transactions with a headquarters in the United States. This victim fits the mold from prior reporting on BlueNorOff targeting organizations with access to large amounts of cryptocurrency for theft. + + + +## Observed adversary tactics and techniques +Elastic uses the MITRE ATT&CK framework to document common tactics, techniques, and procedures that advanced persistent threats use against enterprise networks. + + + +### Tactics +Tactics represent the why of a technique or sub-technique. It is the adversary’s tactical goal: the reason for performing an action. + +- [Initial access](https://attack.mitre.org/tactics/TA0001) +- [Execution](https://attack.mitre.org/tactics/TA0002) +- [Defense evasion](https://attack.mitre.org/tactics/TA0005) +- [Discovery](https://attack.mitre.org/tactics/TA0007) +- [Lateral movement](https://attack.mitre.org/tactics/TA0008/) +- [Command and control](https://attack.mitre.org/tactics/TA0011) + + +## Diamond model +Elastic Security utilizes the [Diamond Model](https://www.activeresponse.org/wp-content/uploads/2013/07/diamond.pdf) to describe high-level relationships between adversaries, capabilities, infrastructure, and victims of intrusions. While the Diamond Model is most commonly used with single intrusions, and leveraging Activity Threading (section 8) as a way to create relationships between incidents, an adversary-centered (section 7.1.4) approach allows for a, although cluttered, single diamond. + + + +![REF9135 Diamond Model](/assets/images/DPRK-strikes-using-a-new-variant-of-rustbucket/image13.jpg) + +## Detection logic + + +### Prevention +- [MacOS.Trojan.RustBucket](https://github.com/elastic/protections-artifacts/blob/main/yara/rules/MacOS_Trojan_RustBucket.yar) +- [Persistence via Suspicious Launch Agent or Launch Daemon](https://github.com/elastic/protections-artifacts/blob/main/behavior/rules/persistence_persistence_via_suspicious_launch_agent_or_launch_daemon.toml) + + +### Hunting queries +The events for EQL are provided with the Elastic Agent using the Elastic Defend integration. Hunting queries could return high signals or false positives. These queries are used to identify potentially suspicious behavior, but an investigation is required to validate the findings. + + + +#### EQL queries +Using the Timeline section of the Security Solution in Kibana under the “Correlation” tab, you can use the below EQL queries to hunt for behaviors observed in REF9135. + +**Suspicious Curl File Download via Osascript** + + + +``` +process where process.parent.name : "osascript" and process.name : "curl" and process.args : "-o" +``` + + **Suspicious URL as argument to Self-Signed Binary** + + + +``` +process where event.type == "start" and event.action == "exec" and + process.code_signature.trusted == false and + process.code_signature.signing_id regex~ """[A-Za-z0-9\_\s]{2,}\-[a-z0-9]{40}""" and + process.args : "http*" and process.args_count <= 3 +``` + +#### YARA +Elastic Security has created YARA rules to identify this activity. Below are YARA rules to identify the RUSTBUCKET malware: + + + +``` + rule MacOS_Trojan_RustBucket { + meta: + author = "Elastic Security" + creation_date = "2023-06-26" + last_modified = "2023-06-26" + license = "Elastic License v2" + os = "MacOS" + arch = "x86" + category_type = "Trojan" + family = "RustBucket" + threat_name = "MacOS.Trojan.RustBucket" + reference_sample = "9ca914b1cfa8c0ba021b9e00bda71f36cad132f27cf16bda6d937badee66c747" + severity = 100 + + strings: + $user_agent = "User-AgentMozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0)" + $install_log = "/var/log/install.log" + $timestamp = "%Y-%m-%d %H:%M:%S" + condition: + all of them +} +``` + +## References +The following were referenced throughout the above research: + +- [https:%2F%2Fwww.jamf.com%2Fblog%2FBlueNorOff-apt-targets-macos-rustbucket-malware%2F](https://www.jamf.com/blog/bluenoroff-apt-targets-macos-rustbucket-malware/) +- [https:%2F%2Fblog.sekoia.io%2FBlueNorOffs-rustbucket-campaign%2F](https://blog.sekoia.io/bluenoroffs-rustbucket-campaign/) + + +## Observations +All observables are also available for [download](https://github.com/elastic/labs-releases/tree/main/indicators/rustbucket) in both ECS and STIX format in a combined zip bundle. + +The following observables were discussed in this research. + +| Observable | Type | Name | Reference | +| --- | --- | --- | --- | +| webhostwatto.work[.]gd | Domain | N%2FA | REF9135 C2 domain | +| crypto.hondchain[.]com | Domain | N%2FA | REF9135 C2 domain | +| starbucls[.]xyz | Domain | N%2FA | REF9135 C2 domain | +| jaicvc[.]com | Domain | N%2FA | REF9135 C2 domain | +| docsend.linkpc[.]net | Domain | N%2FA | REF9135 C2 domain | +| companydeck[.]online | Domain | N%2FA | Associated by REF9135 TLS fingerprint hash | +| 104.168.167[.]88 | ipv4 | N%2FA | REF9135 C2 IP address | +| 64.44.141[.]15 | ipv4 | N%2FA | REF9135 C2 IP address | +| 788261d948177acfcfeb1f839053c8ee9f325bd6fb3f07637a7465acdbbef76a | x509-certificate | jaicvc[.]com | REF9135 C2 TLS fingerprint hash | +| 1031871a8bb920033af87078e4a418ebd30a5d06152cd3c2c257aecdf8203ce6 | x509-certificate | webhostwatto.work[.]gd | REF9135 C2 TLS fingerprint hash | +| 9ca914b1cfa8c0ba021b9e00bda71f36cad132f27cf16bda6d937badee66c747 | SHA-256 | N%2FA | MacOS.Trojan.RustBucket | +| 7fccc871c889a4f4c13a977fdd5f062d6de23c3ffd27e72661c986fae6370387 | SHA-256 | N%2FA | MacOS.Trojan.RustBucket | +| ec8f97d5595d92ec678ffbf5ae1f60ce90e620088927f751c76935c46aa7dc41 | SHA-256 | N%2FA | MacOS.Trojan.RustBucket | +| de81e5246978775a45f3dbda43e2716aaa1b1c4399fe7d44f918fccecc4dd500 | SHA-256 | ErrorCheck | MacOS.Trojan.RustBucket | +| 4f49514ab1794177a61c50c63b93b903c46f9b914c32ebe9c96aa3cbc1f99b16 | SHA-256 | N%2FA | MacOS.Trojan.RustBucket | +| fe8c0e881593cc3dfa7a66e314b12b322053c67cbc9b606d5a2c0a12f097ef69 | SHA-256 | N%2FA | MacOS.Trojan.RustBucket | +| 7887638bcafd57e2896c7c16698e927ce92fd7d409aae698d33cdca3ce8d25b8 | SHA-256 | %2FUsers%2FShared%2F.pd | Stage 2 | + + + diff --git a/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/Hunting_for_Suspicious_Windows_Libraries_for_Execution_and_Evasion.mdx b/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/Hunting_for_Suspicious_Windows_Libraries_for_Execution_and_Evasion.mdx new file mode 100644 index 0000000000000..7db7cbd8cf190 --- /dev/null +++ b/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/Hunting_for_Suspicious_Windows_Libraries_for_Execution_and_Evasion.mdx @@ -0,0 +1,246 @@ +--- +title: "Hunting for Suspicious Windows Libraries for Execution and Defense Evasion" +slug: "Hunting-for-Suspicious-Windows-Libraries-for-Execution-and-Evasion" +date: "2023-03-01" +description: "Learn more about discovering threats by hunting through DLL load events, one way to reveal the presence of known and unknown malware in noisy process event data." +author: + - slug: samir-bousseaden +image: "blog-thumb-roman-columns.jpg" +category: + - slug: security-operations + - slug: security-research + - slug: detection-science +tags: + - detection engineering + - threat hunting + - threat detection +--- + +Dynamic-link library (DLL) image loads is one of the noisiest types of event in Windows, which may discourage defenders from using it for detection engineering or threat hunting. Even if logged in some environments, it’s often limited to function-specific DLLs such as scheduled tasks (taskschd.dll), Windows Management Instrumentation (wmiutil.dll) and potentially DLLs loading from a few suspicious folders. In addition to the data volume issue, the false positive (FP) rate of the detection rules using DLL events also tend to be proportional to the data volume. + +Unfortunately, both advanced adversaries and also commodity malwares are taking advantage of those limitations to increase the chances of their attack success, especially during the delivery phase via diverse spear phishing procedures. + +The most commonly observed delivery techniques are the following : + +- Loading malicious DLLs using binary execution proxies Rundll32 and Regsvr32 +- Sideloading a malicious DLL from a virtual disk image (ISO/VHD files) into a convenient signed benign binary +- Extracting a DLL from a malicious Microsoft Office document (i.e. Word, Excel) and immediately loading it via Visual Basic for Applications (VBA) +- Downloading or extracting a DLL using a [lolbin](https://lolbas-project.github.io/) and loading it by another program +- Sideloading a malicious DLL extracted from a compressed archive (zip, rar, etc) into a signed benign binary +- Dropping a malicious DLL in the current directory of an existing program vulnerable to DLL sideloading (e.g. OneDrive, Slack, Teams) via one of several means +- Less common but also very effective is the use of Windows Installer MSIEXEC to load a malicious DLL + +# What DLL events do we log with Elastic Endpoint ? + +With the exception of the following Microsoft DLLs, Elastic endpoint since version 7.16 records all non-Microsoft signed DLLs: ![](/assets/images/Hunting-for-Suspicious-Windows-Libraries-for-Execution-and-Evasion/table1.jpg) + +We also added some enrichments to both DLL and process events that records the following metadata: ![](/assets/images/Hunting-for-Suspicious-Windows-Libraries-for-Execution-and-Evasion/table2.jpg) + +Below is an example of device information for DLL and Process execution from mounted ISO and VHD files, two file objects increasingly used to deliver malware: ![](/assets/images/Hunting-for-Suspicious-Windows-Libraries-for-Execution-and-Evasion/image14.jpg) + +Here is an example of process execution relative file creation and modification times for svchost.exe : ![](/assets/images/Hunting-for-Suspicious-Windows-Libraries-for-Execution-and-Evasion/image18.jpg) + +The relative execution time enrichment will help us create less noisy detection rules (we can match our rules against the first or few image load or process execution instances), and the device information will allow us to better target suspicious use of ISO/VHD files for malicious purposes. + +# Detection + +In this section we share some detection ideas that are both reliable signals and effectively match the most common scenarios we mentioned earlier. + +## DLL via Rundll32 / Regsvr32 + +As captured in our own [Global Threat Report](https://www.elastic.co/security-labs/2022-elastic-global-threat-report-announcement), Rundll32 and Regsvr32 lolbins are two of the most abused binary execution proxies. These utilities can load malicious DLLs and are a commonly seen component of many phishing attacks (malicious shortcuts, ISO file, macro enabled documents): ![](/assets/images/Hunting-for-Suspicious-Windows-Libraries-for-Execution-and-Evasion/image7.jpg) + +During a recent period of about 90 days, our internal malware sandbox saw roughly 21K malware alerts where the malicious file was a DLL loaded by either regsvr32 or to a lesser degree rundll32. + +The following two endpoint behavior protection rules are effective against about 80% of those samples (~17k out of ~21k) leveraging rundll32 or regsvr32 to execute malicious modules: - [Unusual DLL Extension Loaded by Rundll32 or Regsvr32](https://github.com/elastic/protections-artifacts/blob/main/behavior/rules/defense_evasion_unusual_dll_extension_loaded_by_rundll32_or_regsvr32.toml)- [RunDLL32/Regsvr32 Loads Dropped Executable](https://github.com/elastic/protections-artifacts/blob/main/behavior/rules/initial_access_rundll32_regsvr32_loads_dropped_executable.toml) + +### Rundll32 or Regsvr32 Executing an oversized File + +The following EQL query correlates creation of an executable file event with file size equal or greater than 100MB (this threshold can be adjusted to your environment) subsequently followed by being loaded as a DLL via rundll32 or regsvr32: + +![](/assets/images/Hunting-for-Suspicious-Windows-Libraries-for-Execution-and-Evasion/image23.jpg) + +Below are examples of malicious control panel (CPL) files with sizes over 700MB, a technique used to bypass AV file scanning and reputation-based cloud services that implement a maximum file size for uploaded files: + +![](/assets/images/Hunting-for-Suspicious-Windows-Libraries-for-Execution-and-Evasion/image34.jpg) + +### Rundll32 or Regsvr32 loading a DLL with a suspicious original file name + +Some malicious DLLs have a suspicious original file name, such as ending with .EXE extension or with a great mismatch between the length of the original file name and the actual DLL name. This kind of defense evasion is less common and is employed by a good number of known malware families: + +![](/assets/images/Hunting-for-Suspicious-Windows-Libraries-for-Execution-and-Evasion/image10.jpg) + +A few examples: + +![](/assets/images/Hunting-for-Suspicious-Windows-Libraries-for-Execution-and-Evasion/image33.jpg) + +## DLL via Disk Images + +Embedding malicious payloads in virtual disk images isn’t new or particularly novel, but the technique has gained in popularity among commodity malware families. + +### Suspicious ImageLoad from an ISO Mounted Device + +The following rule looks for the execution of commonly-abused Windows binaries to load a DLL from a mounted virtual disk image: + +![](/assets/images/Hunting-for-Suspicious-Windows-Libraries-for-Execution-and-Evasion/image9.jpg) + +Below are some example of the technique: + +![](/assets/images/Hunting-for-Suspicious-Windows-Libraries-for-Execution-and-Evasion/image20.jpg) + +### Suspicious Microsoft Image Loaded from a Disk Image + +The following rule is triggered when an executable, running from a mounted virtual disk image (.vhd, .iso), loads a suspicious Microsoft-signed DLL such as the taskschd, bitsproxy or vaultclient modules that are associated with some common malware capabilities like persistence, credential access, and evasion. + +![](/assets/images/Hunting-for-Suspicious-Windows-Libraries-for-Execution-and-Evasion/image30.jpg) + +This query identifies many commodity malware families delivered via ISO files: + +![](/assets/images/Hunting-for-Suspicious-Windows-Libraries-for-Execution-and-Evasion/image6.jpg) + +### Potential DLL SideLoad via a Renamed Signed Binary + +The following query identifies attempts to load an unsigned DLL from a mounted virtual disk (.iso, .vhd) and using a renamed signed binary (original file name is different than the process name). + +![](/assets/images/Hunting-for-Suspicious-Windows-Libraries-for-Execution-and-Evasion/image25.jpg) + +This depicts some examples of matches where a signed and renamed program is loading a DLL from a mounted disk image: + +![](/assets/images/Hunting-for-Suspicious-Windows-Libraries-for-Execution-and-Evasion/image15.jpg) + +### Potential DLL SideLoad via a Microsoft Signed Binary + +This detection identifies attempts to load unsigned DLLs from a mounted virtual disk (.iso, .vhd) and using a signed Microsoft binary: + +![](/assets/images/Hunting-for-Suspicious-Windows-Libraries-for-Execution-and-Evasion/image3.jpg) + +Below is an example in which Microsoft OneDrive and Windows Control Panel executables are abused to sideload malicious modules for initial access and execution. + +![](/assets/images/Hunting-for-Suspicious-Windows-Libraries-for-Execution-and-Evasion/image19.jpg) + +## DLL from Archive Files + +Similarly to virtual disk images, attackers can also use ZIP/RAR archive files with embedded malicious DLL paired with a trusted binary or a shortcut (LNK) file to gain access. + +![](/assets/images/Hunting-for-Suspicious-Windows-Libraries-for-Execution-and-Evasion/image5.jpg) + +The following screen capture shows how this query identifies a malicious file from a RAR archive which was auto-extracted into a temporary user directory. This scenario is moderately common. + +![](/assets/images/Hunting-for-Suspicious-Windows-Libraries-for-Execution-and-Evasion/image27.jpg) + +## DLL via Malicious Documents + +Microsoft Office documents can be also used to deploy and load a malicious DLL to avoid spawning a suspicious child process. The following query correlates an executable (PE) file creation event with a DLL load event. + +![](/assets/images/Hunting-for-Suspicious-Windows-Libraries-for-Execution-and-Evasion/image11.jpg) + +Below are some examples of malicious Word and Excel documents using this delivery technique. + +![](/assets/images/Hunting-for-Suspicious-Windows-Libraries-for-Execution-and-Evasion/image16.jpg) + +## DLL via MSIEXEC + +MsiExec is another great option when you need to execute malicious DLLs because this activity blends in well with legitimate software installers. Two observed delivery methods are: + +- Calling the DLLRegisterServer export from a random DLL using the command-line arguments /y or /z as documented here +- Build an installer that uses custom actions to load and execute a DLL as documented here and here + +The following query can be used to identify the execution of the built-in Windows Installer, MSIEXEC, to call the exported function and run code: + +![](/assets/images/Hunting-for-Suspicious-Windows-Libraries-for-Execution-and-Evasion/image26.jpg) + +Examples where MSI is used to load malicious DLLs: + +![](/assets/images/Hunting-for-Suspicious-Windows-Libraries-for-Execution-and-Evasion/image4.jpg) + +DLLs delivered via Windows Installer custom actions can be detected by correlating a DLL file creation event where the calling process is MsiExec and where that DLL is subsequently loaded by the same MsiExec process. + +It's worth noting that there are some legitimate uses of Windows Installer custom actions and this query may require some filtering in environments where those are used. + +![](/assets/images/Hunting-for-Suspicious-Windows-Libraries-for-Execution-and-Evasion/image12.jpg) + +The following query matches the Gwisin Ransomware documented by [AhnLab](https://asec.ahnlab.com/en/37483/) and for which a [PoC](https://github.com/ChoiSG/GwisinMsi) has been created. + +## DLL delivery via lolbins + +Some malware relies on trusted Microsoft binaries to download, decode or extract DLLs. This query correlates PE file creation or modification by common built-in tools, followed by an image load. + +![](/assets/images/Hunting-for-Suspicious-Windows-Libraries-for-Execution-and-Evasion/image13.jpg) + +Examples of malware identified using this detection approach: + +![](/assets/images/Hunting-for-Suspicious-Windows-Libraries-for-Execution-and-Evasion/image28.jpg) + +## DLL sideload into existing program + +The following detection identifies attempts to load a recently-created and unsigned DLL file by an already existing signed process within the same current directory. Comparing the difference between the creation time of the existing program and the DLL creation time we can spot these kinds of anomalies. + +![](/assets/images/Hunting-for-Suspicious-Windows-Libraries-for-Execution-and-Evasion/image29.jpg) + +The next example matches when the malicious secure32.dll process (created 28 seconds ago) is written to the current OneDrivedirectory and automatically loaded by OneDrive.exe (created 2.5 years ago): + +![](/assets/images/Hunting-for-Suspicious-Windows-Libraries-for-Execution-and-Evasion/image17.jpg) + +## DLL loading from suspicious directories + +Dropping a DLL to a user-writable directories and side loading that with a trusted binary is also a common pattern. The following query looks for this behavior and, by leveraging relative creation and modification times, it can reduce the alerts volume while limiting those to a time window following initial execution. + +![](/assets/images/Hunting-for-Suspicious-Windows-Libraries-for-Execution-and-Evasion/image8.jpg) + +The most commonly-targeted user-writable directories are `?:\Users\Public` and `?:\ProgramData`. The full query containing more than 70 suspicious folders can be found [here](https://github.com/elastic/detection-rules/blob/main/rules/windows/defense_evasion_unsigned_dll_loaded_from_suspdir.toml). + +Below see a example depicting malicious matches where various trusted binaries were abused to load malicious DLLs: ![](/assets/images/Hunting-for-Suspicious-Windows-Libraries-for-Execution-and-Evasion/image2.jpg) + +![](/assets/images/Hunting-for-Suspicious-Windows-Libraries-for-Execution-and-Evasion/image21.jpg) + +## DLL load with a abnormal creation time + +Another interesting scenario is identifying a DLL load event where the DLL has a suspicious creation time, and which could be a result of timestomping. This query compares inconsistencies between the creation time and filename modification time using dll.Ext.relative_file_name_modify_time and dll.Ext.relative_file_creation_time immediately followed by an image load: ![](/assets/images/Hunting-for-Suspicious-Windows-Libraries-for-Execution-and-Evasion/image1.jpg) + +The following is an example where malware drop DLLs in trusted directories and then use timestomping to ensure those DLLs blend in with existing files in those directories: ![](/assets/images/Hunting-for-Suspicious-Windows-Libraries-for-Execution-and-Evasion/image22.jpg) + +## DLL from removable device + +DLL side-loading from a removable device is still a valid infection vector, especially for air-gapped networks. An example was recently shared by [Mandiant](https://www.mandiant.com/resources/blog/china-nexus-espionage-southeast-asia) involving an espionage-oriented threat. The following EQL query can be used to find similar behavior: ![](/assets/images/Hunting-for-Suspicious-Windows-Libraries-for-Execution-and-Evasion/image24.jpg) + +Here is an example with several matches: ![](/assets/images/Hunting-for-Suspicious-Windows-Libraries-for-Execution-and-Evasion/image31.jpg) + +## Protection Rules + +Elastic provides significant capabilities for identifying unusual or malicious library load events with existing behavior protection rules that take advantage of Windows Libraries events: + +- [NTDLL Loaded from an Unusual Path](https://github.com/elastic/protections-artifacts/blob/main/behavior/rules/defense_evasion_ntdll_loaded_from_an_unusual_path.toml) +- [Suspicious NTDLL Image Load](https://github.com/elastic/protections-artifacts/blob/main/behavior/rules/defense_evasion_suspicious_ntdll_image_load.toml) +- [DLL Loaded from an Archive File](https://github.com/elastic/protections-artifacts/blob/main/behavior/rules/execution_dll_loaded_from_an_archive_file.toml) +- [Microsoft Office Loaded a Dropped Executable File](https://github.com/elastic/protections-artifacts/blob/main/behavior/rules/initial_access_microsoft_office_loaded_a_dropped_executable_file.toml) +- [Suspicious ImageLoad from an ISO Mounted Device](https://github.com/elastic/protections-artifacts/blob/main/behavior/rules/defense_evasion_suspicious_imageload_from_an_iso_mounted_device.toml) +- [Potential Evasion via Oversized Image Load](https://github.com/elastic/protections-artifacts/blob/main/behavior/rules/defense_evasion_potential_evasion_via_oversized_image_load.toml) +- [Suspicious ImageLoad via Windows Update Auto Update Client](https://github.com/elastic/protections-artifacts/blob/main/behavior/rules/defense_evasion_suspicious_imageload_via_windows_update_auto_update_client.toml) +- [Privilege Escalation via Microsoft Exchange DLL Hijacking](https://github.com/elastic/protections-artifacts/blob/main/behavior/rules/defense_evasion_privilege_escalation_via_microsoft_exchange_dll_hijacking.toml) +- [Potential DLL SideLoad via a Microsoft Signed Binary](https://github.com/elastic/protections-artifacts/blob/main/behavior/rules/defense_evasion_potential_dll_sideload_via_a_microsoft_signed_binary.toml) +- [Potential DLL SideLoad via a Renamed Signed Binary](https://github.com/elastic/protections-artifacts/blob/main/behavior/rules/defense_evasion_potential_dll_sideload_via_a_renamed_signed_binary.toml) +- [Library Load of a File Written by a Signed Binary Proxy](https://github.com/elastic/protections-artifacts/blob/main/behavior/rules/command_and_control_library_load_of_a_file_written_by_a_signed_binary_proxy.toml) +- [Potential DLL Search Order Hijacking of an Existing Program](https://github.com/elastic/protections-artifacts/blob/main/behavior/rules/defense_evasion_potential_dll_search_order_hijacking_of_an_existing_program.toml) +- [Suspicious DLLRegisterServer Execution via MSIEXEC](https://github.com/elastic/protections-artifacts/blob/main/behavior/rules/defense_evasion_suspicious_dllregisterserver_execution_via_msiexec.toml) +- [ImageLoad of a File dropped via SMB](https://github.com/elastic/protections-artifacts/blob/main/behavior/rules/lateral_movement_imageload_of_a_file_dropped_via_smb.toml) +- [RunDLL32/Regsvr32 Loads Dropped Executable](https://github.com/elastic/protections-artifacts/blob/main/behavior/rules/initial_access_rundll32_regsvr32_loads_dropped_executable.toml) +- [Unusual DLL Extension Loaded by Rundll32 or Regsvr32](https://github.com/elastic/protections-artifacts/blob/main/behavior/rules/defense_evasion_unusual_dll_extension_loaded_by_rundll32_or_regsvr32.toml) +- [RunDLL32/Regsvr32 Loads a DLL Downloaded via BITS](https://github.com/elastic/protections-artifacts/blob/main/behavior/rules/defense_evasion_rundll32_regsvr32_loads_a_dll_downloaded_via_bits.toml) +- [Potential Initial Access via DLL Search Order Hijacking](https://github.com/elastic/protections-artifacts/blob/main/behavior/rules/defense_evasion_potential_initial_access_via_dll_search_order_hijacking.toml) +- [Suspicious Control Panel DLL Loaded by Explorer](https://github.com/elastic/protections-artifacts/blob/main/behavior/rules/defense_evasion_suspicious_control_panel_dll_loaded_by_explorer.toml) +- [Protected Process Light Bypass via DLL Tampering](https://github.com/elastic/protections-artifacts/blob/main/behavior/rules/defense_evasion_protected_process_light_bypass_via_dll_tampering.toml) +- [Potential Privilege Escalation via DLL Redirection](https://github.com/elastic/protections-artifacts/blob/main/behavior/rules/privilege_escalation_potential_privilege_escalation_via_dll_redirection.toml) +- [Potential Privilege Escalation via Missing DLL](https://github.com/elastic/protections-artifacts/blob/main/behavior/rules/privilege_escalation_potential_privilege_escalation_via_missing_dll.toml) +- [Potential Privilege Escalation via Elevated IFileOperation](https://github.com/elastic/protections-artifacts/blob/main/behavior/rules/privilege_escalation_potential_privilege_escalation_via_elevated_ifileoperation.toml) +- [Suspicious DLL Loaded by Svchost](https://github.com/elastic/detection-rules/blob/main/rules/windows/persistence_service_dll_unsigned.toml) +- [Suspicious DLL Loaded from a Removable Media](https://github.com/elastic/protections-artifacts/blob/main/behavior/rules/initial_access_suspicious_dll_loaded_from_a_removable_media.toml) +- [Suspicious Control Panel DLL Loaded by Explorer](https://github.com/elastic/protections-artifacts/blob/main/behavior/rules/defense_evasion_suspicious_control_panel_dll_loaded_by_explorer.toml) +- [Dynwrapx Image Load via Windows Scripts](https://github.com/elastic/protections-artifacts/blob/main/behavior/rules/execution_dynwrapx_image_load_via_windows_scripts.toml) +- [Suspicious Image Load via Windows Scripts](https://github.com/elastic/protections-artifacts/blob/main/behavior/rules/execution_suspicious_image_load_via_windows_scripts.toml) +- [Potential Image Load with a Spoofed Creation Time](https://github.com/elastic/protections-artifacts/blob/main/behavior/rules/defense_evasion_potential_image_load_with_a_spoofed_creation_time.toml) + +## Conclusion + +Compared to detections that rely on process execution events and where adversaries expose more detection opportunities via command-line flags and parent process relationships, designing detections based on DLL events requires more enrichment and correlation to decrease noise rate and increase confidence. + +In this publication we shared numerous examples of how we’re using DLL events to identify threats. You can use the different capabilities Elastic endpoint offers to produce higher signal alerts, too. Given the multitude of methods of delivering malicious code as DLLs, though, relying on behavioral detections alone is not enough. Combining this logic with malware file classification, shellcode detection features, and user-entity based analytics (UEBA) improves the fidelity of this metadata for detection purposes. diff --git a/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/a_peek_behind_the_bpfdoor.mdx b/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/a_peek_behind_the_bpfdoor.mdx new file mode 100644 index 0000000000000..cc70a80f8e04a --- /dev/null +++ b/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/a_peek_behind_the_bpfdoor.mdx @@ -0,0 +1,428 @@ +--- +title: "A peek behind the BPFDoor" +slug: "a-peek-behind-the-bpfdoor" +date: "2022-07-13" +description: "In this research piece, we explore BPFDoor — a backdoor payload specifically crafted for Linux in order to gain re-entry into a previously or actively compromised target environment." +author: + - slug: jake-king + - slug: colson-wilhoit +image: "blog-security-detection-720x420.png" +category: + - slug: attack-pattern +--- + +## Preamble + +[BPFDoor](https://doublepulsar.com/bpfdoor-an-active-chinese-global-surveillance-tool-54b078f1a896) is a backdoor payload specifically crafted for Linux. Its purpose is for long-term persistence in order to gain re-entry into a previously or actively compromised target environment. It notably utilizes BPF along with a number of other techniques to achieve this goal, taking great care to be as efficient and stealthy as possible. PWC researchers discovered this very interesting piece of malware in 2021. PWC attributes this back door to a specific group from China, Red Menshen, and detailed a number of interesting components in a high-level threat research post released [last week](https://www.pwc.com/gx/en/issues/cybersecurity/cyber-threat-intelligence/cyber-year-in-retrospect/yir-cyber-threats-report-download.pdf). + +PWC’s findings indicated that ​​Red Menshen had focused their efforts on targeting specific Telecommunications, Government, Logistics, and Education groups across the Middle East and Asia. This activity has been across a Monday-to-Friday working period, between 01:00 UTC and 10:00 UTC, indicating that the operators of the malware were consistent in their attacks, and operation during a working week. + +Perhaps most concerningly, the payload itself has been observed across the last 5 years in various phases of development and complexity, indicating that the threat actor responsible for operating the malware has been at it for some time, undetected in many environments. + +> **BPFDoor Tools** +> +> The Elastic Security Team has created a few tools that will aid researchers in analyzing the BPFDoor malware. +> +> The BPFDoor scanner will allow you to scan for hosts infected with the BPFDoor malware and the BPFDoor configuration extractor will allow you to extrapolate the malware’s configuration or hardcoded values which can lead to additional observations you can use for further analysis, developing additional signatures or connecting to the backdoor utilizing our client. +> +> - [BPFDoor scanner](https://www.elastic.co/security-labs/bpfdoor-scanner) +> - [BPFDoor configuration extractor](https://www.elastic.co/security-labs/bpfdoor-configuration-extractor) + +## Attack Lifecycle + +This inherently passive backdoor payload is built to be a form of persistence – a method to regain access if the first or second stage payloads are lost. It is built for and intended to be installed on high-uptime servers or appliances, IoT/SCADA, or cloud systems with access to the Internet. The backdoor usually sits in temporary storage so if a server were to be rebooted or shut down, the backdoor would be lost. + +It should be assumed that if this malware is found on a system the initial-access (1st stage) or post-exploitation (2nd stage) payloads are still most likely present and possibly active elsewhere in the environment. This backdoor excels at stealth, taking every opportunity to blend in and remain undetected. + +In the below steps, we will break BPFDoor’s actions down according to the vast majority of the samples available. + +1. When executed the binary copies itself into /dev/shm/. A temporary filesystem /dev/shm stands for shared memory and is a temporary file storage facility serving as an efficient means of inter-process communication +2. Renames its process to kdmtmpflush, a hardcoded process name +3. Initializes itself with the -init flag and forks itself. Forking in Linux means creating a new process by duplicating the calling process +4. Deletes itself by removing the original binary invoked. The forked process continues to run +5. Alters the forked processes’ creation and modification time values, also known as [timestomping](https://attack.mitre.org/techniques/T1070/006/) +6. Creates a new process environment for itself and removes the old one setting (spoofing) a new process name. It changes the way it appears on the system akin to wearing a mask. The process is still kdmtmpflush but if you were to run a ps you would see whatever value it set +7. Creates a process ID (PID) file in /var/run. PID files are text files containing the process of the associated program meant for preventing multiple starts, marking residency, and used by the program to stop itself. This file resides in /var/run, another temporary file storage facility +8. Creates a raw network socket. On Linux, a socket is an endpoint for network communication that allows you to specify in detail every section of a packet allowing a user to implement their own transport layer protocol above the internet (IP) level +9. Sets BPF filters on the raw socket. [BPF](https://www.kernel.org/doc/html/v5.12/networking/filter.html) allows a user-space program to attach a filter onto any socket and allow or disallow certain types of data to come through the socket +10. Observes incoming packets +11. If a packet is observed that matches the BPF filters and contains the required data it is passed to the backdoor for processing +12. It forks the current process again +13. Changes the forked processes working directory to / +14. Changes (spoofs) the name of the forked process to a hardcoded value +15. Based on the password or existence of a password sent in the “magic packet” the backdoor provides a reverse shell, establishes a bind shell, or sends back a ping + +> **Atypical BPFDoor sample** +> +> Of note there is one [sample](https://www.virustotal.com/gui/file/07ecb1f2d9ffbd20a46cd36cd06b022db3cc8e45b1ecab62cd11f9ca7a26ab6d/detection) we have come across that does not seem to exhibit steps 1 - 4. It doesn’t alter its initial name to a hardcoded value and simply executes from its placed location, otherwise, it models the same behavior. + +Below you can see visual representations of the BPFDoor process tree, utilizing Elastic’s Analyzer View. The first image displays the tree prior to active use of the backdoor (i.e reverse shell, bind shell, or pingback) and the second image after a reverse shell has connected and performed post-exploitation activities. + +![Elastic Analyzer View of the BPFDoor initial invocation process tree](/assets/images/a-peek-behind-the-bpfdoor/analyzer-view.png) + +![Elastic Analyzer View of BPFDoor following a reverse shell connection and post exploitation actions](/assets/images/a-peek-behind-the-bpfdoor/bpfdoor_analyzer.png) + +## Defense Evasion Insights + +BPFDoor is interesting given the anti-forensics, and obfuscation tactics used. Astute readers will observe slight differences in the PID tree visible when running a ps ajxf on an infected host when compared to executed data within the Analyzer View inside of Elastic. This is due to the process name spoofing mentioned in step 6 (above) of the attack lifecycle above. The image below is taken from a system running BPFDoor with an active reverse shell connection established: + +![An observed running process created by the BPFDoor reverse shell](/assets/images/a-peek-behind-the-bpfdoor/observed-process.jpg) + +The difference lies in the fact that kdmtmpflush and sh are run prior to spoofing, and are captured at runtime by Elastic Endpoint. This is an accurate representation of the processes active on the host, further confirming the importance of appropriate observation software for Linux hosts - you can’t always trust what you see on the local system: + +![Elastic Analyzer View of BPFDoor demonstrating real process capture.](/assets/images/a-peek-behind-the-bpfdoor/analyzer-terminated.jpg) + +BPFDoor also holds in its repertoire the ability to subvert the traditional Linux socket client - server architecture in order to hide its malicious traffic. The methods which it utilizes to achieve this are both unusual and intriguing. + +The sockets interface is almost synonmous with TCP/IP communication. This simple interface has endured for over 40 years - predating both Linux and Windows implementations. + +![Example of how TCP/IP and socket interfaces function](/assets/images/a-peek-behind-the-bpfdoor/tcp-ip.png) + +BPFDoor uses a raw socket (as opposed to ‘cooked’ ones that handle IP/TCP/UDP headers transparently) to observe every packet arriving at the machine, ethernet frame headers and all. While this might sound like a stealthy way to intercept traffic, it’s actually not – on any machine with a significant amount of network traffic the CPU usage will be consistently high. + +That’s where BPF comes in - an extremely efficient, kernel-level packet filter is the perfect tool to allow the implant to ignore 99% of network traffic and only become activated when a special pattern is encountered. This implant looks for a so-called magic packet in every TCP, UDP and ICMP packet received on the system. + +Once activated, a typical reverse shell - which this back door also supports - creates an outbound connection to a listener set up by the attacker. This has the advantage of bypassing firewalls watching inbound traffic only. This method is well-understood by defenders, however. The sneakiest way to get a shell connected would be to reuse an existing packet flow, redirected to a separate process. + +In this attack, the initial TCP handshake is done between the attacker and a completely legitimate process – for example nginx or sshd. These handshake packets happen to be also delivered to the backdoor (like every packet on the system) but are filtered out by BPF. Once the connection is established, however, BPFDoor sends a magic packet to the legitimate service. The implant receives it and makes a note of the originating IP and port the attacker is using, and it opens a new listening socket on an inconspicuous port (42391 - 43391). + +The implant then reconfigures the firewall to temporarily redirect all traffic from the attacker’s IP/port combination to the new listening socket. The attacker initiates a second TCP handshake on the same legitimate port as before, only now iptables forwards those packets to the listening socket owned by the implant. . This establishes the communication channel between attacker and implant that will be used for command and control. The implant then covers its tracks by removing the iptables firewall rules that redirected the traffic. + +Despite the firewall rule being removed, traffic on the legitimate port will continue to be forwarded to the implant due to how Linux statefully tracks connections. No visible traffic will be addressed to the implant port (although it will be delivered there). + +![A diagram representing the aforementioned network flows](/assets/images/a-peek-behind-the-bpfdoor/network-flows.png) + +## BPF Filters + +As stated in step 9 (above), [BPF](https://www.kernel.org/doc/html/v5.12/networking/filter.html) or Berkeley Packet Filters is a technology from the early ’90s that allows a user-space program to attach a network filter onto any socket and allow or disallow certain types of data to come through the socket. These filters are made up of bytecode that runs on an abstract virtual machine in the Linux kernel. The BPF virtual machine has functionality to inspect all parts of incoming packets and make an allow/drop decision based on what it sees. . You can see in the image example below what this looks like within the BPFDoor source code: + +![BPFDoor source code BPF Filters](/assets/images/a-peek-behind-the-bpfdoor/bpfdoor-source-code.jpg) + +We took this BPF code, converted it, and wrote it up as pseudo code in an effort to aid our research and craft packets able to successfully get through these filters in order to activate the backdoor. + +![BPFDoor source code BPF Filter Pseudocode](/assets/images/a-peek-behind-the-bpfdoor/bpf-pseudocode.jpg) + +The above capabilities allow BPFDoor to attach a filter onto any socket and allow or disallow certain types of data to come through the socket - used carefully by the adversary to invoke a series of different functions within the payload. + +## Historical Analysis + +We wanted to see over time, between BPFDoor payloads, what, if anything, the threat actors modified. A number of samples were detonated and analyzed ranging from the uploaded source code to a [sample](https://www.virustotal.com/gui/file/599ae527f10ddb4625687748b7d3734ee51673b664f2e5d0346e64f85e185683/detection) uploaded last month. We found that the behavior over time did not change a great deal. It maintained the same relative attack lifecycle with a few variations with the hardcoded values such as passwords, process names, and files - this is not uncommon when compared to other malware samples that look to evade detection or leverage payloads across a variety of victims. + +We posture that the threat group would change passwords and update process or file names in an effort to improve operational security and remain hidden. It also makes sense that the general functionality of the backdoor would not change in any great way. As the saying goes “If it’s not broken, don’t fix it”. Our malware analysis and reverse engineering team compared the source code (uploaded to [VirusTotal](https://www.virustotal.com/gui/file/8b9db0bc9152628bdacc32dab01590211bee9f27d58e0f66f6a1e26aea7552a6/detection) and found on [Pastebin](https://pastebin.com/raw/kmmJuuQP)) to a recently uploaded sample highlighting some of the notable changes within the main function of the malware in the images below. + +![A side by side comparison of the main functions for the Pastebin source code and a sample uploaded to VT last month focusing on the hardcoded string values for the passwords, process names and file name](/assets/images/a-peek-behind-the-bpfdoor/pastebin.jpg) + +As we mentioned earlier, one recent [sample](https://www.virustotal.com/gui/file/07ecb1f2d9ffbd20a46cd36cd06b022db3cc8e45b1ecab62cd11f9ca7a26ab6d/detection) we have come across that does not seem to exhibit some of the tactics of prior payloads has been observed - It doesn’t alter its initial name to a hardcoded value and simply executes from its placed location, otherwise, it models relatively the same behavior. + +## Linux Malware Sophistication + +A trend we have had the privilege of observing at Elastic, is the threat landscape of Linux targeted attacks - these being focused often on cloud workloads, or systems that typically have less observational technology configured in many of the environments we see. The trend of complex, well-designed payloads is something that is often simply overlooked, and specifically in the case of BPFDoor, remained hidden for years. + +It is important to consider these workloads a critical component of your security posture: A lack of visibility within cloud workloads will eventually lead to large gaps in security controls - adversarial groups are further growing to understand these trends, and act accordingly. Best practices state that endpoint defenses should be consistent across the fleet of systems under management, and conform to a least privilege architecture. + +## Detection of BPFDoor + +After researching this malware it became apparent as to why the backdoor remained in use and hidden for so long. If you aren’t intimately familiar with Linux process abnormalities or weren’t looking for it you would generally not detect it. Even though it takes advantage of Linux capabilities in a stealthy manner to evade detection, there are still opportunities for both behavioral and signature-based detections. + +The first area of opportunity we witnessed while testing was the behavior we observed during the initial execution of the malware, specifically its working directory, in a shared memory location /dev/shm. This is a native temporary filesystem location in Linux that uses RAM for storage, and a binary executing from it let alone generating network connections is fairly uncommon in practice. + +During execution, BPFDoor removes existing files from /dev/shm and copies itself there prior to initialization. A detection for this would be any execution of a binary from this directory as root (you have to be root to write to and read from this directory). + +This was verified by detonating the binary in a VM while our Elastic Agent was installed and observing the sequence of events. You can see an image of this detection on the Kibana Security Alerts page below. This rule is publicly available as an Elastic SIEM detection rule - [Binary Executed from Shared Memory Directory](https://github.com/elastic/detection-rules/blob/main/rules/linux/execution_process_started_in_shared_memory_directory.toml): + +![Elastic Alert in Kibana - Binary Executed from Shared Memory Directory](/assets/images/a-peek-behind-the-bpfdoor/Elastic_Alert_in_Kibana_-_Binary_Executed_from_Shared_Memory_Directory.png) + +The second opportunity we noticed, for detection, was a specific PID file being created in /var/run. We noticed the dropped PID file was completely empty while doing a quick query via the [Osquery integration](https://docs.elastic.co/en/integrations/osquery_manager) to the /var/run directory. While this is not inherently malicious, it is unusual for the file size of a PID to be 0 or above 10 bytes and thus we created an additional rule centered around detecting this unusual behavior. + +Our [Abnormal Process ID or Lock File Created](https://github.com/elastic/detection-rules/blob/main/rules/linux/execution_abnormal_process_id_file_created.toml) rule identifies the creation of a PID file in the main directory of /var/run with no subdirectory, ignoring common PID files to be expected: + +![Elastic Alert in Kibana - Abnormal Process ID or Lock File Created](/assets/images/a-peek-behind-the-bpfdoor/abnormal-process.png) + +The third area we wanted to look at was the network connections tied to two of the three capabilities (reverse shell and bind shell) the backdoor possesses. We wanted to see if there were any suspicious network connections tied to process or user abnormalities we could sequence together based off of the way BPFDoor handles establishing a reverse or bind shell. + +The reverse shell was the first capability focused on. Taking a deep look at the process tree in and around the reverse shell establishment allowed us to key in on what would be considered a strange or even abnormal sequence of events leading to and involving an outbound network connection. + +We developed a hunt rule sequence that identifies an outbound network connection attempt followed by a session id change as the root user by the same process entity. The reason we developed these network focused hunt rules is due to possible performance issues caused if running these continually. + +The bind shell was the last capability we honed in on. Identifying an abnormal sequence of events surrounding the bind shell connection was difficult due to the way it forks then accepts the connection and kills the accepting process post established connection. Therefore we had to focus on the sequence of events within the process entity id directly involving the network connection and subsequent killing of the accepting process. + +After developing the 2 detection rules along with the 2 hunt rules listed below and in addition to the 6 YARA signatures deployed we were able to detect BPFDoor in a myriad of different ways and within different stages of its life cycle. As stated earlier though, if you detect this malware in your environment it should be the least of your concerns given the threat actor will most likely have already successfully compromised your network via other means. + +![Elastic Detection Summary of complete BPFDoor attack lifecycle](/assets/images/a-peek-behind-the-bpfdoor/complete-bpfdoor.png) + +### Existing Detection Rules + +The following Elastic Detection Rules will identify BPFDoor activity: + +- [Abnormal Process ID or Lock File Created](https://github.com/elastic/detection-rules/blob/main/rules/linux/execution_abnormal_process_id_file_created.toml) +- [Binary Executed from Shared Memory Directory](https://github.com/elastic/detection-rules/blob/main/rules/linux/execution_process_started_in_shared_memory_directory.toml) + +### Hunting Queries + +This EQL rule can be used to successfully identify BPFDoor reverse shell connections having been established within your environment: + +**EQL BPFDoor reverse shell hunt query** + +``` +sequence by process.entity_id with maxspan=1m +[network where event.type == "start" and event.action == "connection_attempted" and user.id == "0" and not process.executable : ("/bin/ssh", "/sbin/ssh", "/usr/lib/systemd/systemd")] +[process where event.action == "session_id_change" and user.id == "0"] +``` + +![Elastic Alert in Kibana - Suspicious Network Connection Attempt by Root](/assets/images/a-peek-behind-the-bpfdoor/attempt-by-root.png) + +The hunt rule we created here identifies a sequence of events beginning with a session id change, followed by a network connection accepted, in correlation with ptmx file creation and a deletion of the process responsible for accepting the network connection. This EQL rule can be used to successfully identify BPFDoor bind shell connections within your environment: + +**EQL BPFDoor bind shell hunt query** + +``` +sequence by process.entity_id with maxspan=1m +[process where event.type == "change" and event.action == "session_id_change" and user.id == 0 and not process.executable : ("/bin/ssh", "/sbin/ssh", "/usr/lib/systemd/systemd")] +[network where event.type == "start" and event.action == "connection_accepted" and user.id == 0] +[file where event.action == "creation" and user.id == 0 and file.path == "/dev/ptmx"] +[process where event.action == "end" and user.id == 0 and not process.executable : ("/bin/ssh", "/sbin/ssh", "/usr/lib/systemd/systemd")] +``` + +![Elastic Alert in Kibana - Suspicious Network Connection Accept by Root](/assets/images/a-peek-behind-the-bpfdoor/Elastic_Alert_in_Kibana_-_Suspicious_Network_Connection_Accept_by_Root.png) + +### YARA Rules + +In addition to behavioral detection rules in the Elastic Endpoint, we are releasing a set of BPFDoor Yara signatures for the community. + +**BPFDoor YARA rule** + +``` +rule Linux_Trojan_BPFDoor_1 { + + meta: + Author = "Elastic Security" + creation_date = "2022-05-10" + last_modified = "2022-05-10" + os = "Linux" + arch = "x86" + category_type = "Trojan" + family = "BPFDoor" + threat_name = "Linux.Trojan.BPFDoor" + description = "Detects BPFDoor malware." + reference_sample = "144526d30ae747982079d5d340d1ff116a7963aba2e3ed589e7ebc297ba0c1b3" + strings: + $a1 = "hald-addon-acpi: listening on acpi kernel interface /proc/acpi/event" ascii fullword + $a2 = "/sbin/iptables -t nat -D PREROUTING -p tcp -s %s --dport %d -j REDIRECT --to-ports %d" ascii fullword + $a3 = "avahi-daemon: chroot helper" ascii fullword + $a4 = "/sbin/mingetty /dev/tty6" ascii fullword + $a5 = "ttcompat" ascii fullword + condition: + all of them +} + +rule Linux_Trojan_BPFDoor_2 { + meta: + Author = "Elastic Security" + creation_date = "2022-05-10" + last_modified = "2022-05-10" + os = "Linux" + arch = "x86" + category_type = "Trojan" + family = "BPFDoor" + threat_name = "Linux.Trojan.BPFDoor" + description = "Detects BPFDoor malware." + reference_sample = "3a1b174f0c19c28f71e1babde01982c56d38d3672ea14d47c35ae3062e49b155" + strings: + $a1 = "hald-addon-acpi: listening on acpi kernel interface /proc/acpi/event" ascii fullword + $a2 = "/sbin/mingetty /dev/tty7" ascii fullword + $a3 = "pickup -l -t fifo -u" ascii fullword + $a4 = "kdmtmpflush" ascii fullword + $a5 = "avahi-daemon: chroot helper" ascii fullword + $a6 = "/sbin/auditd -n" ascii fullword + condition: + all of them +} + +rule Linux_Trojan_BPFDoor_3 { + meta: + Author = "Elastic Security" + creation_date = "2022-05-10" + last_modified = "2022-05-10" + os = "Linux" + arch = "x86" + category_type = "Trojan" + family = "BPFDoor" + threat_name = "Linux.Trojan.BPFDoor" + description = "Detects BPFDoor malware." + reference_sample = "591198c234416c6ccbcea6967963ca2ca0f17050be7eed1602198308d9127c78" + strings: + $a1 = "[-] Spawn shell failed." ascii fullword + $a2 = "[+] Packet Successfuly Sending %d Size." ascii fullword + $a3 = "[+] Monitor packet send." ascii fullword + $a4 = "[+] Using port %d" + $a5 = "decrypt_ctx" ascii fullword + $a6 = "getshell" ascii fullword + $a7 = "getpassw" ascii fullword + $a8 = "export %s=%s" ascii fullword + condition: + all of them +} + +rule Linux_Trojan_BPFDoor_4 { + meta: + Author = "Elastic Security" + creation_date = "2022-05-10" + last_modified = "2022-05-10" + os = "Linux" + arch = "x86" + category_type = "Trojan" + family = "BPFDoor" + threat_name = "Linux.Trojan.BPFDoor" + description = "Detects BPFDoor malware." + reference_sample = "591198c234416c6ccbcea6967963ca2ca0f17050be7eed1602198308d9127c78" + strings: + $a1 = { 45 D8 0F B6 10 0F B6 45 FF 48 03 45 F0 0F B6 00 8D 04 02 00 } + condition: + all of them +} + +rule Linux_Trojan_BPFDoor_5 { + meta: + Author = "Elastic Security" + creation_date = "2022-05-10" + last_modified = "2022-05-10" + os = "Linux" + arch = "x86" + category_type = "Trojan" + family = "BPFDoor" + threat_name = "Linux.Trojan.BPFDoor" + description = "Detects BPFDoor malware." + reference_sample = "76bf736b25d5c9aaf6a84edd4e615796fffc338a893b49c120c0b4941ce37925" + strings: + $a1 = "getshell" ascii fullword + $a2 = "/sbin/agetty --noclear tty1 linux" ascii fullword + $a3 = "packet_loop" ascii fullword + $a4 = "godpid" ascii fullword + $a5 = "ttcompat" ascii fullword + $a6 = "decrypt_ctx" ascii fullword + $a7 = "rc4_init" ascii fullword + $b1 = { D0 48 89 45 F8 48 8B 45 F8 0F B6 40 0C C0 E8 04 0F B6 C0 C1 } + condition: + all of ($a*) or 1 of ($b*) +} + +rule Linux_Trojan_BPFDoor_6 { + meta: + Author = "Elastic Security" + creation_date = "2022-05-10" + last_modified = "2022-05-10" + os = "Linux" + arch = "x86" + category_type = "Trojan" + family = "BPFDoor" + threat_name = "Linux.Trojan.BPFDoor" + description = "Detects BPFDoor malware." + reference_sample = "dc8346bf443b7b453f062740d8ae8d8d7ce879672810f4296158f90359dcae3a" + strings: + $a1 = "getpassw" ascii fullword + $a2 = "(udp[8:2]=0x7255) or (icmp[8:2]=0x7255) or (tcp[((tcp[12]&0xf0)>>2):2]=0x5293)" ascii fullword + $a3 = "/var/run/haldrund.pid" ascii fullword + $a4 = "Couldn't install filter %s: %s" ascii fullword + $a5 = "godpid" ascii fullword + condition: + all of them +} +``` + +## Interacting with BPFDoor + +The Elastic Security Team has released several tools that can aid in further research regarding BPFDoor to include a network scanner used to identify infected hosts, a BPFDoor malware configuration extractor, and a BPFDoor client binary that can be used to actively interact with a sample. + +### BPFDoor Scanner + +The Elastic Security Team [has released](https://www.elastic.co/security-labs/bpfdoor-scanner) a Python script that can identify if you have BPFDoor infected hosts. + +The scanner sends a packet to a defined IP address using the default target port (68/UDP)and default interface. It listens to return traffic on port 53/UDP. + +![BPFDoor scanner tool](/assets/images/a-peek-behind-the-bpfdoor/BPFDoor_scanner_tool.jpg) + +### BPFDoor Configuration Extractor + +This tool will allow you to extract configurations from any BPFDoor malware you may have collected. This will allow you to develop additional signatures and further analysis of the malware as well as your environment. + +The BPFDoor configuration extractor can be downloaded [here](https://www.elastic.co/security-labs/bpfdoor-configuration-extractor). + +![BPFDoor configuration extractor](/assets/images/a-peek-behind-the-bpfdoor/BPFDoor_configuration_extractor.jpg) + +### BPFDoor Client POC + +Quickly after beginning our research into this malware we realized we would also need to actively interact with BPFDoor in order to observe the full extent of the capabilities that it possesses and monitor what these capabilities would look like from a host and SIEM level. + +In order to do this, we had to break down the BPF filters in the BPFDoor source code so we could craft packets for the different protocols. To do this, we used [Scapy](https://scapy.net/), a packet manipulation program, to ensure we could pass the filters for the purpose of activating the backdoor. Once we ensured we could pass the filters, Rhys Rustad-Elliott, an engineer at Elastic built a BPFDoor client that accepts a password, IP address, and port allowing you to connect to a BPFDoor sample and interact if you possess the sample’s hardcoded passwords. + +Depending on the password or lack of password provided, BPFDoor will behave exactly the same way it would in the wild. You can invoke a reverse shell, establish a bind shell, or connect to it with no supplied password to receive a ping-back confirming its installation. + +![A preview of the BPFDoor Client developed by Elastic Security to assist in research](/assets/images/a-peek-behind-the-bpfdoor/A_preview_of_the_BPFDoor_Client_developed_by_Elastic_Security_to_assist_in_research.jpg) + +Researchers looking to use BPFDoor can [reach out to Elastic Security](mailto:threat-notification@elastic.co) for access to the BPFDoor client POC. Please note that these tools will be shared at our discretion with those in the trusted security community looking to improve the detection of this vulnerability. + +## Impact + +The following MITRE ATT&CK Tactic, Techniques, and Sub-techniques have been observed with the BPFDoor malware. + +### Tactics + +Tactics represent the “why” of an ATT&CK technique or sub-technique. It is the adversary’s tactical goal: the reason for performing an action. + +- [Execution](https://attack.mitre.org/tactics/TA0002/) + +### Techniques (sub-techniques) + +Techniques (and sub-techniques) represent ‘how’ an adversary achieves a tactical goal by performing an action. + +- [Native API](https://attack.mitre.org/techniques/T1106/) +- [External Remote Services](https://attack.mitre.org/techniques/T1133/) +- [Hide Artifacts](https://attack.mitre.org/techniques/T1564/) +- [Indicator Removal on Host](https://attack.mitre.org/techniques/T1070/) +- [Non-Application Layer Protocol](https://attack.mitre.org/techniques/T1095/) +- [Command and Scripting Interpreter: Unix Shell](https://attack.mitre.org/techniques/T1059/004) +- [Abuse Elevation Control Mechanism: Setuid and Setgid](https://attack.mitre.org/techniques/T1548/001/) + +## Source Pseudocode + +To clearly articulate the details of this malware, we’ve created [two diagrams](https://www.elastic.co/pdf/bpfdoor_pseudocode.pdf) that outline the specific pseudocode for BPFDoor based on the source code uploaded to VT and found on Pastebin. While this contains a lot of detail, it is simple to understand if researchers choose to further this research. + +## Summary + +While threat groups continue to increase in maturity, we expect this kind of mature, well designed and hidden threat will continue to be found within Linux environments. These kinds of findings reiterate the importance of comprehensive security controls across the entirety of a fleet, rather than simply focusing on user endpoints. + +BPFDoor demonstrates a perfect example of how important monitoring workloads within Linux environments can be. Payloads such as this are near-on impossible to observe and detect without sufficient controls, and should be considered a moving trend within the general adversarial landscape. + +## Observables + +| Observable | Type | Reference | Note | +| ---------------------------------------------------------------- | ------------ | -------------------- | -------------------------------- | +| /dev/shm/kdmtmpflush | process name | BPFDoor process name | Observed process name of BPFDoor | +| /var/run/haldrund.pid | file name | BPFDoor file name | Observed BPFDoor PID file | +| /var/run/kdevrund.pid | file name | BPFDoor file name | Observed BPFDoor PID file | +| /var/run/xinetd.lock | file name | BPFDoor file name | Observed BPFDoor lock file | +| 74ef6cc38f5a1a80148752b63c117e6846984debd2af806c65887195a8eccc56 | SHA-256 | BPFDoor malware | | +| 07ecb1f2d9ffbd20a46cd36cd06b022db3cc8e45b1ecab62cd11f9ca7a26ab6d | SHA-256 | BPFDoor malware | | +| 76bf736b25d5c9aaf6a84edd4e615796fffc338a893b49c120c0b4941ce37925 | SHA-256 | BPFDoor malware | | +| 93f4262fce8c6b4f8e239c35a0679fbbbb722141b95a5f2af53a2bcafe4edd1c | SHA-256 | BPFDoor malware | | +| 96e906128095dead57fdc9ce8688bb889166b67c9a1b8fdb93d7cff7f3836bb9 | SHA-256 | BPFDoor malware | | +| 599ae527f10ddb4625687748b7d3734ee51673b664f2e5d0346e64f85e185683 | SHA-256 | BPFDoor malware | | +| 2e0aa3da45a0360d051359e1a038beff8551b957698f21756cfc6ed5539e4bdb | SHA-256 | BPFDoor malware | | +| f47de978da1dbfc5e0f195745e3368d3ceef034e964817c66ba01396a1953d72 | SHA-256 | BPFDoor malware | | +| fd1b20ee5bd429046d3c04e9c675c41e9095bea70e0329bd32d7edd17ebaf68a | SHA-256 | BPFDoor malware | | +| 5faab159397964e630c4156f8852bcc6ee46df1cdd8be2a8d3f3d8e5980f3bb3 | SHA-256 | BPFDoor malware | | +| f8a5e735d6e79eb587954a371515a82a15883cf2eda9d7ddb8938b86e714ea27 | SHA-256 | BPFDoor malware | | +| 5b2a079690efb5f4e0944353dd883303ffd6bab4aad1f0c88b49a76ddcb28ee9 | SHA-256 | BPFDoor malware | | +| 97a546c7d08ad34dfab74c9c8a96986c54768c592a8dae521ddcf612a84fb8cc | SHA-256 | BPFDoor malware | | +| c80bd1c4a796b4d3944a097e96f384c85687daeedcdcf05cc885c8c9b279b09c | SHA-256 | BPFDoor malware | | +| 4c5cf8f977fc7c368a8e095700a44be36c8332462c0b1e41bff03238b2bf2a2d | SHA-256 | BPFDoor malware | | + +## References + +- https://doublepulsar.com/bpfdoor-an-active-chinese-global-surveillance-tool-54b078f1a896 +- https://www.pwc.com/gx/en/issues/cybersecurity/cyber-threat-intelligence/cyber-year-in-retrospect/yir-cyber-threats-report-download.pdf +- https://www.pangulab.cn/en/post/the_bvp47_a_top-tier_backdoor_of_us_nsa_equation_group + +## Artifacts + +Artifacts are also available for [download](https://assets.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt294e7cd5c4b8a050/628e88d93b9b8554904a703c/bpfdoor-indicators.zip) in both ECS and STIX format in a combined zip bundle. diff --git a/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/accelerating_elastic_detection_tradecraft_with_llms.mdx b/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/accelerating_elastic_detection_tradecraft_with_llms.mdx new file mode 100644 index 0000000000000..3ea1fb2b95eaa --- /dev/null +++ b/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/accelerating_elastic_detection_tradecraft_with_llms.mdx @@ -0,0 +1,83 @@ +--- +title: "Accelerating Elastic detection tradecraft with LLMs" +slug: "accelerating-elastic-detection-tradecraft-with-llms" +date: "2023-09-29" +description: "Learn more about how Elastic Security Labs has been focused on accelerating our detection engineering workflows by tapping into more generative AI capabilities." +author: + - slug: mika-ayenson + - slug: jess-daubner +image: "photo-edited-09@2x.jpg" +category: + - slug: detection-science + - slug: machine-learning + - slug: generative-ai +--- + +In line with our [Openness Initiative](https://www.elastic.co/blog/continued-leadership-in-open-and-transparent-security), we remain committed to transparency and want to share how our internal AI R&D efforts have increased the productivity of our threat detection team. For the past few months, Elastic Security Labs has been focused on accelerating our detection engineering workflows by tapping into more generative AI capabilities. + +## The ONWeek Exploration Odyssey + +At Elastic, outside of our long-running [Space, Time](https://www.elastic.co/about/our-source-code) tradition, we dedicate a week every 6 months to work either independently or in a team on something we call ONWeek. This is a week where we all step away from feature work, tech debt, and other similar tasks; and use the week to focus on innovative ideas, active learning opportunities, applied research, and proof of concept work. During the previous ONWeek in May, we explored ideas to leverage large language models (LLMs) with Elastic’s existing features to enhance security alert triaging and productivity for tier 1 analysts and on, internal productivity workflows, and understanding the foundational building blocks for our experimentation and tuning. Figure 1 shows several different opportunities for research we have, which involve ingesting events, passing data through tailored prompts, and generating different classes of content designed for different Elastic workflows. + +![Figure 1: GenAI Security Use Cases](/assets/images/accelerating-elastic-detection-tradecraft-with-llms/image1.jpg) +Figure 1: GenAI Security Use Cases + +Fundamentally we explored several traditional ML approaches, but ultimately focused on starting simple and gradually increasing complexity, while keeping in mind these tools and concepts: + - **Start Simple** - A mantra that guided our approach. + - **Azure OpenAI** - Access to the GPT-4 LLM + - **Prompt Engineering** - Developing tailored instructions for the LLM. + - **LangChain** - Python library to help craft LLM applications. + +One of our goals is to streamline Elastic’s detection engineer workflows, allowing for greater focus on better detections while showcasing the depth and nuances of our query languages. On the way there, we’re spending time experimenting to validate our prompts and prepare them for operational use. We want to make sure that as we iterate over our prompts, we don’t incidentally introduce regressions. As AI advancements emerge, we intend for our T&E to ensure that any adjustments, be it fine-tuning, model replacements, or prompt modifications, are deliberate. Ultimately, we aspire for our analysts to seamlessly utilize the latest AIML features, applying the most suitable prompts or ML techniques in the right context. + +With these goals in mind, our first research use case in May focused on query generation. We learned quickly that with minimal data and prompt engineering, we could chain a series of prompts to transform raw Elastic events into EQL queries. + +![Figure 2: Query Generation POC](/assets/images/accelerating-elastic-detection-tradecraft-with-llms/image44.gif) +Figure 2: Query Generation POC + +For experimentation purposes, we simulated suspicious activity using our [Red Team Automation (RTA)](https://github.com/elastic/detection-rules/tree/main/rta) scripts and captured the endpoint activity in the SIEM through the Elastic Agent. Figure 2 displays sample events from the Elastic stack, exported to gold.json test files, that included the essential event fields for query generation. + +We then asked GPT to analyze the event collection covering the RTA execution time window and focus on events with suspicious behavior. In our POC, the prompt asked us to pinpoint key values linked to potential anomalies. We then followed with subsequent prompts to chunk the events and summarize all of the activity. Based on all the summaries, we asked GPT to generate a list of indicators, without keying on specific values. With this short list of suspicious behaviors, we then asked GPT to generate the query. A significant advantage of our long-term open-source development is that GPT-related models are familiar with Elastic content, and so we benefited by not having to overfit our prompts. + +Even though going from raw data to an EQL query was conceptually straightforward, we still encountered minor hiccups like service availability with Azure OpenAI. It was relatively cheap, in what we estimated cost us around $160 in a week to use the OpenAI and Azure OpenAI inference and embedding APIs. We also explored using the GCP Vertex AI Workbench to facilitate collaborative work on Jupyter notebooks, but the complexity of using the available open source (OSS) models made them challenging to use during the short ONWeek. + +![Figure 3: May 2023 ONWeek Major Outcomes](/assets/images/accelerating-elastic-detection-tradecraft-with-llms/image2.png) +Figure 3: May 2023 ONWeek Major Outcomes + +We used ONWeek to mature our roadmap like expanding beyond in-memory, library-based vector search implementations to more performant, scalable, and production-ready data stores of our detection-rules content in Elasticsearch. Based on our initial results, we understood the potential and viability of integrating GenAI into the analyst workflow (e.g. allowing event time-window selection, query generation, and timeline addition). Based on these early wins, we put on our internal roadmap plans to pursue further LLM R&D and decided to tackle one of our internal productivity workflows. + +## A New Horizon: Generating Investigation Guides + +Over the years, Elastic Security Labs has matured its content. Starting in 2020 by adding the Investigation Guide Security feature, then standardizing those guides in 2021. By 2023, with over 900 [rules](https://github.com/elastic/detection-rules/tree/main/rules) in place, we are actively seeking an efficient way to generate highly accurate, detailed, and standardized guides for all 900+ pre-built rules. + +Melding traditional ML approaches (like similarity vector search) with our prompt engineering special sauce, our team created a new prototype centered around investigation guide generation called Rulecraft. Now, with just a rule ID in hand, our rule authors can generate a baseline investigation guide solution in mere minutes! + +![Figure 4: Sample Investigation Guide](/assets/images/accelerating-elastic-detection-tradecraft-with-llms/image3.png) +Figure 4: Sample Investigation Guide + +In this initial exploration, we supplied detection rules, but limited input to a few fields from the rules like the description and name of GPT. We also attempted to supply the query, but it appeared to overfit the expected outcome we desired. Initially, we provided a simple prompt with these fields to evaluate how well GPT could generate a decent investigation guide with minimal effort. As we explored further, it became evident that we could benefit from chaining multiple prompts akin to what we did during the EQL query generation experiment. So we spent time creating prompts tailored to distinct sections of the investigation guide. Segmenting the prompts not only granted us greater flexibility but also addressed areas where GPT faltered, such as the "Related Rules" section, where GPT tended to hallucinate most. At times like this, we used traditional ML methods like similarity search and integrated our rules into a vector database for enhanced context. + +Next, we identified opportunities to inject additional context into specific sections. To ensure uniformity across our guides, we curated a library of approved content and language for each segment. This library then guided GPT in generating and formatting responses similar to our established standard messages. We then compared GenAI-produced guides with their manually crafted counterparts to identify other formatting discrepancies, general errors introduced by GPT, and even broader issues with our prompts. + +Based on these findings, we chose to improve our generated content by adjusting the prompts instead of using post-processing techniques like string formatting. While the automated investigation guides aren't perfect, they offer our detection engineers a solid starting place. In the past, investigation guides have enhanced our PR peer review process by providing the reviewer with more context as the rules expected behavior. We now can generate the base guide, tune it, and add more detail as needed by the detection engineer instead of starting from scratch. + +To bring this capability directly to our detection engineers, we integrated Rulecraft into a GitHub action workflow, so they can generate guides on-demand. We also produced the additional 650+ guides in a mere 13 hours—a task that would traditionally span months. The automation allows us to make small tweaks and quickly regenerate base content for rules missing investigation guides. Again, these guides are still subject to our stringent internal review, but the time and effort saved by leveraging GenAI for our preliminary drafts is incredible. + +## Charting the Future: Next Steps + +Our research and development journey continues, with a central focus on refining our approach to content generation with LLMs and more thoroughly validating our results. Here’s a short list of our priorities now that we’ve explored the viability and efficacy of integrating LLMs into our detection engineering workflow: + - Compare proprietary models with the latest open-source models + - Further refine our experimentation process including event filtering, prompt optimization, and exploring various model parameters + - Create a test suite to validate our results and prevent regressions. + - Seamlessly integrate our R&D advancements into the [Elastic AI Assistant](https://www.elastic.co/blog/open-security-impact-elastic-ai-assistant). + +Overall, we want to dramatically increase our investigation guide coverage and reduce the time taken to craft these guides from the ground up. Each investigation guide provides analysts with detailed, step-by-step instructions and queries for triaging alerts. With a customer-first mentality at the forefront of our [source code](https://www.elastic.co/about/our-source-code), we aim to elevate the analyst experience with more investigation guides of even higher quality, translating into less time spent by our customers on FP analysis and alert triaging. + +## Summary +Keeping in spirit with our open innovation and transparency, Elastic Security Labs has begun our generative AI voyage to enhance the productivity of our threat detection processes. Our efforts continue to evolve and incorporate prompt engineering and traditional ML approaches on a case-by-case basis, resulting in more R&D proof-of-concepts like “LetmeaskGPT” and "Rulecraft". The latter POC has significantly reduced the time required to craft baseline guides, improve the analyst experience, and reduce false positive analyses. There’s so much more to do and we want to include you on our journey! While we've made strides, our next steps include further refinement, developing a framework to rigorously validate our results, and exploring opportunities to operationalize our R&D, ensuring we remain at the forefront of security advancements. + +We’re always interested in hearing use cases and workflows like these, so as always, reach out to us via [GitHub issues](https://github.com/elastic/detection-rules/issues), chat with us in our [community Slack](http://ela.st/slack), and ask questions in our [Discuss forums](https://discuss.elastic.co/c/security/endpoint-security/80)! + +Also, feel free to check out these additional resources to learn more about how we’re bringing the latest AI capabilities to the hands of the analyst: + - Learn how to responsibly use [ChatGPT with Elasticsearch](https://www.elastic.co/blog/chatgpt-elasticsearch-openai-meets-private-data) + - See the new Elastic [AI Assistant](https://www.elastic.co/blog/introducing-elastic-ai-assistant) — the open, generative AI sidekick powered by ESRE and [get setup](https://www.elastic.co/guide/en/security/current/security-assistant.html#set-up-ai-assistant) diff --git a/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/advanced_techniques_used_in_malaysian_focused_apt_campaign.mdx b/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/advanced_techniques_used_in_malaysian_focused_apt_campaign.mdx new file mode 100644 index 0000000000000..0c24f667d04e6 --- /dev/null +++ b/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/advanced_techniques_used_in_malaysian_focused_apt_campaign.mdx @@ -0,0 +1,238 @@ +--- +title: "A close look at the advanced techniques used in a Malaysian-focused APT campaign" +slug: "advanced-techniques-used-in-malaysian-focused-apt-campaign" +date: "2022-06-22" +description: "Our Elastic Security research team has focused on advanced techniques used in a Malaysian-focused APT campaign. Learn who’s behind it, how the attack works, observed MITRE attack® techniques, and indicators of compromise." +author: + - slug: samir-bousseaden + - slug: daniel-stepanic + - slug: elastic-security-intelligence-analytics-team +image: "blog-thumb-castle-tower.jpg" +category: + - slug: campaigns +--- + +The Elastic Security Intelligence & Analytics Team researches adversary innovations of many kinds, and has recently focused on an activity group that leveraged remote templates, VBA code evasion, and DLL side-loading techniques. Based on code similarity and shared tactics, techniques, and procedures (TTPs), the team assessed this activity to be possibly linked to a Chinese-based group known as APT40, or Leviathan. The group’s campaign appears to target Malaysian government officials with a lure regarding the 2020 Malaysian political crisis. + +## Anatomy of the attack + +![Figure 1: Original image](/assets/images/advanced-techniques-used-in-malaysian-focused-apt-campaign/1-leviathan-apt-blog-original-image.jpg) + +![Figure 2: Lure document image](/assets/images/advanced-techniques-used-in-malaysian-focused-apt-campaign/2-leviathan-apt-blog-lure-document-image.jpg) + +To initiate their advanced persistent threat (APT) campaign, the group likely delivered a Microsoft Word document as a phishing lure attachment. The image used in the lure (Figure 2) appears to be crafted from a broadcast announcement shared by a Malaysian blogger (Figure 1). The lure image includes the same broadcast time, but the date and speech topic are removed. Once this attachment is opened, a decoy document is presented while behind the scenes, taking the following actions: + +- The lure document downloads the remote template RemoteLoad.dotm +- The remote template executes VBA macro code +- The VBA macro code unpacks and executes two embedded base64-encoded DLLs (sl1.tmp and sl2.tmp) to c:\users\public\ + +This technique is known as template injection, which you may recall from our [Playing defense against Gamaredon Group blog post](https://www.elastic.co/blog/playing-defense-against-gamaredon-group). This an effective approach used by adversaries to bypass perimeter controls such as email gateways. + +![Figure 4: Obfuscation of MZ/PE header base64](/assets/images/advanced-techniques-used-in-malaysian-focused-apt-campaign/4-leviathan-apt-blog-obfuscation.jpg) + +Both embedded DLLs (sl1.tmp and sl2.tmp) are similar and export the same function names: RCT and RCP. The first DLL (sl1.tmp) is used to download a benign executable called LogiMailApp.exe and an associated library LogiMail.dll, and the second DLL (sl2.tmp) is used to execute LogiMailApp.exe, which automatically attempts to execute LogiMail.dll due to an inherent DLL search order vulnerability we’ll cover shortly. + +| | | | | | +| --------------- | --------- | ------------ | -------------------------------- | ------------------------- | +| File name | File type | Size (bytes) | MD5 | Compile time | +| LogiMailApp.exe | Win32 EXE | 311656 | 850a163ce1f9cff0367854038d8cfa7e | 2012-09-26 22:13:13+00:00 | +| LogiMail.dll | Win32 DLL | 105984 | b5a5dc78fb392fae927e9461888f354d | 2020-06-03 04:08:29+00:00 | +| sl1.tmp | Win32 DLL | 3072 | ccbdda7217ba439dfb6bbc6c3bd594f8 | 2019-11-29 17:15:29+00:00 | +| sl2.tmp | Win32 DLL | 3072 | dbfa006d64f39cde78b0efda1373309c | 2019-11-29 21:23:44+00:00 | + +_Table 1: Dropped files metadata_ + +![Figure 5: Download and execution of LogiMailApp.exe and LogiMail.dll](/assets/images/advanced-techniques-used-in-malaysian-focused-apt-campaign/5-leviathan-apt-blog-download-execution.jpg) + +This implementation stood out to our researchers due to a behavioral idiosyncrasy: + +- The Microsoft Office application winword.exe loads sl1.tmp and sl2.tmp DLLs uses the LoadLibraryA method, which is moderately rare +- These DLLs run explicit commands or install a payload from a URL using the CallWindowProcA method, which appears to be exceptionally rare +- Both DLLs are deleted after execution + +![Figure 6: Download and execution module deletion](/assets/images/advanced-techniques-used-in-malaysian-focused-apt-campaign/6-leviathan-apt-blog-module.jpg) + +## Embedded DLLs + +The embedded DLLs, sl1.tmp and sl2.tmp, have very limited functionality — exporting the RCP and RCT functions. The RCP function implements the WinExec method to execute commands where the RCT function uses the URLDownloadToFileA method to download a file from a specified URL. + +![Figure 7: Exported functions – RCP and RCT](/assets/images/advanced-techniques-used-in-malaysian-focused-apt-campaign/7-leviathan-apt-blog-exported-functions.jpg) + +## DLL side-loading a backdoor + +LogiMailApp.exe, which is downloaded by sl1.tmp and executed by sl2.tmp, is vulnerable to a form of DLL search-order hijacking called side-loading, which automatically searches for and executes LogiMail.dll if found in the same directory. Forms of DLL search-order hijacking can be used with many third-party software applications. In this case, search-order hijacking was used to load a backdoor that exports the following notable functions: + +![Figure 8: LogiMail.dll exports table](/assets/images/advanced-techniques-used-in-malaysian-focused-apt-campaign/8-leviathan-apt-blog-logimail-exports.jpg) + +![Figure 9: LogiMailApp.exe – Logitech camera software](/assets/images/advanced-techniques-used-in-malaysian-focused-apt-campaign/9-leviathan-apt-blog-logitech-software.jpg) + +![Figure 10: LogiMail.dll side-loading](/assets/images/advanced-techniques-used-in-malaysian-focused-apt-campaign/10-leviathan-apt-blog-side-loading.jpg) + +The adversary-created binary LogiMail.dll exports the function DllGetClassObject that contains critical logic for the execution flow of this sample: + +1. Download an AES-encrypted second stage object to %TEMP%\~liseces1.pcs +2. Derive a 128-bit AES key and initialization vector from SHA256 of a hardcoded string +3. Read and decrypt %TEMP%\~liseces1.pcs in memory using the ReadFile and CryptDecrypt functions +4. Delete %TEMP%\~liseces1.pcs from disk + +![Figure 11: Encrypted URL and hardcoded key](/assets/images/advanced-techniques-used-in-malaysian-focused-apt-campaign/11-leviathan-apt-blog-encrypted-url.jpg) + +![Figure 12: Decrypted second stage URL and temp staging file](/assets/images/advanced-techniques-used-in-malaysian-focused-apt-campaign/12-leviathan-apt-blog-decrypted-second-stage.jpg) + +![Figure 13: Second stage download, in-memory decryption, execution, and file deletion](/assets/images/advanced-techniques-used-in-malaysian-focused-apt-campaign/13-leviathan-apt-blog-second-stage-download.jpg) + +## Second stage backdoor + +The decrypted second stage backdoor is mapped into memory and then its original entry point (OEP) is called, thus bypassing successful detections based on file system scanning. + +![Figure 14: LogiMail.dll — Resolving needed functions to map second stage PE into memory](/assets/images/advanced-techniques-used-in-malaysian-focused-apt-campaign/14-leviathan-apt-blog-resolving-needed-functions.jpg) + +![Figure 15: The second stage implant mapped in LogiMailApp.exe memory](/assets/images/advanced-techniques-used-in-malaysian-focused-apt-campaign/15-leviathan-apt-blog-second-stage-mapped.jpg) + +Both the payload staging server and the second stage infrastructure use dynamic DNS: + +![Figure 16: C2 HTTP POST request to /postlogin](/assets/images/advanced-techniques-used-in-malaysian-focused-apt-campaign/16-leviathan-apt-blog-c2.jpg) + +This payload supports the following capabilities: + +- Basic anti-debug checks +- System and user discovery +- Execution via command line +- File discovery, upload, and download +- Persistence via run registry +- Encrypt C2 traffic using same AES key + +![Figure 17: System and user discovery](/assets/images/advanced-techniques-used-in-malaysian-focused-apt-campaign/17-leviathan-apt-blog-system-discovery.jpg) + +![Figure 18: Execution via command-line](/assets/images/advanced-techniques-used-in-malaysian-focused-apt-campaign/18-leviathan-apt-blog-execution-command-line.jpg) + +![Figure 19: File discovery, upload, and download](/assets/images/advanced-techniques-used-in-malaysian-focused-apt-campaign/19-leviathan-apt-blog-file-discovery.jpg) + +## Possible APT40/Leviathan connection + +Earlier in the year, the Malaysian Computer Emergency Response Team (MyCERT) issued an [advisory](https://www.mycert.org.my/portal/advisory?id=MA-774.022020) related to espionage activity targeting their country. The report listed different TTPs and included multiple samples and other technical indicators that align with a threat group known as APT40/Leviathan. + +At a high level, this sample follows the continued trend of targeting Malaysian victims using specific TTPs such as remote templates, employing macros, using DLL side-loading techniques, and leveraging an in-memory implant with dynamic DNS for command and control. More specifically, the second stage implant from this lure shares unique strings and URL references and contains similar functionality that correlates with the previous reporting for APT40/Leviathan. With these similarities, our Intelligence & Analytics Team assesses with moderate confidence that this activity is linked to APT40/Leviathan. + +Implant String Similarities with MyCERT Sample: + +- /list_direction +- /post_document +- /post_login +- Open Remote File %s Failed For: %s +- Open Pipe Failed %s +- Download Read Path Failed %s +- %02X-%02X-%02X-%02X-%02X-%02X +- Software\Microsoft\Windows\CurrentVersion\Run +- ntkd + +![](/assets/images/advanced-techniques-used-in-malaysian-focused-apt-campaign/20-leviathan-apt-blog-shared-strings.jpg) + +![Figure 20: Shared strings with MyCERT sample - 8a133a382499e08811dceadcbe07](/assets/images/advanced-techniques-used-in-malaysian-focused-apt-campaign/21-leviathan-apt-blog-shared-strings-2.jpg) + +## Conclusion + +In this post, we highlighted a recent sample that most likely represents the work of a highly organized adversary. Activity groups like this are significant for everyone to take notice of, if only because they represent a higher maturity level of post-exploit innovation. Their cutting edge TTPs today end up being everyone’s run of the mill tomorrow; it’s important to learn from these events. + +We hope that by sharing some of these insights, we can help raise awareness and continue to focus on protecting the world's data from attack. To enable organizations further, we’ve added all the observed MITRE ATT&CK® techniques and indicators of compromise (IoCs) below. + +### MITRE ATT&CK® techniques + +- [T1193 - Spearphishing Attachment](https://attack.mitre.org/techniques/T1193/) +- [T1221 - Template Injection](https://attack.mitre.org/techniques/T1221/) +- [T1060 - Registry Run Keys / Startup Folder](https://attack.mitre.org/techniques/T1060/) +- [T1073 - DLL Side-Loading](https://attack.mitre.org/techniques/T1073/) +- [T1129 - Execution through Module Load](https://attack.mitre.org/techniques/T1129/) +- [T1055 - Process Injection](https://attack.mitre.org/techniques/T1055/) +- [T1107 - File Deletion](https://attack.mitre.org/techniques/T1107/) +- [T1140 - Deobfuscate/Decode Files or Information](https://attack.mitre.org/techniques/T1140/) +- [T1059 - Command-Line Interface](https://attack.mitre.org/techniques/T1059/) + +### Indicators of Compromise (IOCs) + +#### File names and paths + +``` +Bubar Parlimen.zip +Bubar Parlimen.docx +RemoteLoad.dotm +C:\Users\Public\sl1.tmp +C:\Users\Public\sl2.tmp +C:\Users\*\AppData\Local\Temp\~liseces1.pcs +C:\Users\*\AppData\Local\Microsoft\Office\LogiMailApp.exe +C:\Users\*\AppData\Local\Microsoft\Office\LogiMail.dll +``` + +#### Registry keys + +``` +HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run\ntkd +``` + +#### URLs + +``` +hxxps[:]//armybar[.]hopto[.]org/LogiMail.dll +hxxps[:]//armybar[.]hopto[.]org/LogiMailApp[.]exe +hxxps[:]//armybar[.]hopto[.]org/Encrypted +hxxp[:]//tomema.myddns[.]me/postlogin +hxxp[:]//tomema[.]myddns[.]me/list_direction +hxxp[:]//tomema[.]myddns[.]me/post_document +``` + +#### IPs + +``` +104[.]248[.]148[.]156 +139[.]59[.]31[.]188 +``` + +#### HTTPS certificate + +``` +74b5e317527c93539dbaaf84d6a61da92a56012a +``` + +#### Hashes + +``` +523cbdaf31ddc920e5b6c873f3ab42fb791fb4c9d1f4d9e6a7f174105d4f72a1 +ab541df861c6045a17006969dac074a7d300c0a8edd0a5815c8b871b62ecdda7 +145daf50aefb7beec32556fd011e10c9eaa71e356649edfce4404409c1e8fa30 +93810c5fd9a287d85c182d2ad13e7d30f99df76e55bb40e5bc7a486d259810c8 +925f404b0207055f2a524d9825c48aa511199da95120ed7aafa52d3f7594b0c9 +feca9ad5058bc8571d89c9d5a1eebce09e709cc82954f8dce1564e8cc6750a77 +06a4246be400ad0347e71b3c4ecd607edda59fbf873791d3772ce001f580c1d3 +77ef350639b767ce0a748f94f723a6a88609c67be485b9d8ff8401729b8003d2 +``` + +### YARA + +``` +rule APT_APT40_Implant_June2020 { + meta: + version = "1.0" + author = "Elastic Security" + date_added = "2020-06-19" + description = "APT40 second stage implant" + strings: + $a = "/list_direction" fullword wide + $b = "/post_document" fullword wide + $c = "/postlogin" fullword wide + $d = "Download Read Path Failed %s" fullword ascii + $e = "Open Pipe Failed %s" fullword ascii + $f = "Open Remote File %s Failed For: %s" fullword ascii + $g = "Download Read Path Failed %s" fullword ascii + $h = "\\cmd.exe" fullword wide + condition: + all of them +} +``` + +### References + +- [https://www.mycert.org.my/portal/advisory?id=MA-774.022020](https://www.mycert.org.my/portal/advisory?id=MA-774.022020) + +- [https://prezi.com/view/jGyAzyy5dTOkDrtwsJi5/](https://prezi.com/view/jGyAzyy5dTOkDrtwsJi5/) +- [https://www.fireeye.com/blog/threat-research/2019/03/apt40-examining-a-china-nexus-espionage-actor.html](https://www.fireeye.com/blog/threat-research/2019/03/apt40-examining-a-china-nexus-espionage-actor.html) +- [https://malpedia.caad.fkie.fraunhofer.de/details/win.dadstache](https://malpedia.caad.fkie.fraunhofer.de/details/win.dadstache) diff --git a/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/an_elastic_approach_to_large_scale_dynamic_malware_analysis.mdx b/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/an_elastic_approach_to_large_scale_dynamic_malware_analysis.mdx new file mode 100644 index 0000000000000..4d4c84de5a7c1 --- /dev/null +++ b/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/an_elastic_approach_to_large_scale_dynamic_malware_analysis.mdx @@ -0,0 +1,232 @@ +--- +title: "An Elastic approach to large-scale dynamic malware analysis" +slug: "an-elastic-approach-to-large-scale-dynamic-malware-analysis" +date: "2023-07-31" +description: "This research reveals insights into some of the large-scale malware analysis performed by Elastic Security Labs, and complements research related to the Detonate framework." +author: +- slug: ruben-groenewoud +- slug: remco-sprooten +image: "blog-thumb-steel-engine.jpg" +category: +--- +## Introduction + +In previous publications, we have written about Detonate: how we built it and how we use it within Elastic for malware analysis. This publication delves deeper into using Detonate for dynamic large-scale malware analysis. + +At a high level, Detonate runs malware and other potentially malicious software in a controlled (i.e., sandboxed) environment where the full suite of Elastic Security capabilities are enabled. For more information about Detonate, check out [Click, Click… Boom! Automating Protections Testing with Detonate](https://www.elastic.co/security-labs/click-click-boom-automating-protections-testing-with-detonate). + +A significant portion of the data generated during execution consists of benign and duplicate information. When conducting dynamic malware analysis on a large scale, managing the vast amount of low-value data is a considerable challenge. To address it, we took advantage of several Elastic ingest pipelines, which we leveraged to effectively filter out noise from our datasets. This application of ingest pipelines enabled us to conveniently analyze our large volumes of malware data and identify several malicious behaviors that we were already interested in. + +This research examines the concept of ingest pipelines, exploring their different types and applications, and how to implement them. We will then walk through a comprehensive workflow incorporating these ingest pipelines. We will discuss our scripts and the methods that we created in order to automate the entire process. Finally, we will present our results and discuss how the workflow shared in this publication can be leveraged by others to obtain similar outcomes. + +### Overview + +In order to accomplish our large-scale malware analysis goals, we required effective data management. An overview of the chained ingest pipelines and processors that we built is shown below: + +![Ingest pipeline process overview](/assets/images/an-elastic-approach-to-large-scale-dynamic-malware-analysis/image1.png) + +In summary, we fingerprint known good binaries and store those fingerprints in an enrich index. We do the same thing when we detonate malware or an unknown binary, using a comparison of those fingerprints to quickly filter out low-value data. + +### Ingest pipelines + +[Ingest pipelines](https://www.elastic.co/guide/en/elasticsearch/reference/current/ingest.html) are a powerful feature that allows you to preprocess and transform data before indexing it into Elasticsearch. They provide a way to perform various actions on incoming documents, such as enriching the data, modifying fields, extracting information, or applying data normalization. Ingest pipelines can be customized to meet specific data processing requirements. Our objective was to create a pipeline that differentiates known benign documents from a dataset containing both benign and malicious records. We ingested large benign and malicious datasets into separate namespaces and built pipelines to normalize the data, calculate fingerprints, and add a specific label based on certain criteria. This label helps differentiate between known benign and unknown data. + +### Normalization + +Normalization is the process of organizing and transforming data into a consistent and standardized format. When dealing with lots of different data, normalization becomes important to ensure consistency, improve search and analysis capabilities, and enable efficient data processing. + +The goal is to make sure documents with unique identifiers are no longer unique. For example, we remove the unique 6-character filename of the Elastic Agent in the " `/opt/Elastic/Agent/data/`" directory after installation. This ensures data from different Elastic Agents can be fully comparable, leading to more filtering opportunities in later pipeline phases. + +To accomplish this, we leveraged the [gsub pipeline](https://www.elastic.co/guide/en/elasticsearch/reference/current/gsub-processor.html). It allowed us to apply regex-based transformations to fields within the data pipeline. We performed pattern matching and substitution operations to normalize event data, such as removing special characters, converting text to lowercase, or replacing certain patterns with standardized values. + +By analyzing our dataset, we discovered a set of candidates that would require normalization, and created a simple Python script to generate a list of gsub processors based on the matching value and the replacement value. The script that we leveraged can be found on [GitHub](https://github.com/elastic/labs-releases/tree/main/tools/malware_research). Using the output of the script, we can leverage dev tools to create a pipeline containing the generated gsub processors. + +Prior to utilizing the normalization pipeline, documents would contain random 6 character strings for every single Elastic agent. An example is displayed below. + +![Document before normalization](/assets/images/an-elastic-approach-to-large-scale-dynamic-malware-analysis/image6.png) + +After ingesting and manipulating the documents through the normalization pipeline, the result looks like the following. + +![Document after normalization](/assets/images/an-elastic-approach-to-large-scale-dynamic-malware-analysis/image13.png) + +When all documents are normalized, we can continue with the fingerprint calculation process. + +### Fingerprint calculation + +Fingerprint calculations are commonly used to generate a unique identifier for documents based on their content. The [fingerprint ingest pipeline](https://www.elastic.co/guide/en/elasticsearch/reference/current/fingerprint-processor.html) provides a convenient way to generate such identifiers by computing a hash value based on the specified fields and options, allowing for efficient document deduplication and comparison. The pipeline offers various options, including algorithms (such as MD5 or SHA-1), target fields for storing the generated fingerprints, and the ability to include or exclude specific fields in the calculation. + +We needed to calculate the fingerprints of documents ingested into Elasticsearch from several sources and integrations such as endpoint, [auditd manager](https://docs.elastic.co/integrations/auditd_manager), packetbeat, [file integrity monitoring](https://docs.elastic.co/integrations/fim) etc. To calculate the fingerprints, we first needed to specify which fields we wanted to calculate them for. Because different data sources use different fields, it was important to create separate processors for each data type. For our use case, we ended up creating a different fingerprint processor for the following set of event categories: + +![Gsub ingest processor](/assets/images/an-elastic-approach-to-large-scale-dynamic-malware-analysis/image20.jpg) + +By specifying a condition we ensure that each processor only runs on its corresponding dataset. + +![Event filter example](/assets/images/an-elastic-approach-to-large-scale-dynamic-malware-analysis/image21.jpg) + +The included fields to these processors are of the utmost importance, as they can indicate if a field is less static than expected or if an empty field could result in a non-functional pipeline. For example, when working with network data, it might initially make sense to include protocol, destination ip, destination port, source ip and source port. But this will lead to too much noise in the pipeline, as the socket that is opened on a system will be opened on an ephemeral source port, which will result in many unique fingerprints for otherwise identical network traffic. Some fields that may be subject to change relate to file sizes, version numbers, or specific text fields that are not being parsed. Normalization sometimes preserves fields that aren't useful for fingerprinting, and the more specific the fingerprint the less useful it tends to be. Fingerprinting by file hash illustrates this, while adding an empty space to the file causes a new hash to be calculated, this would break an existing hash-based fingerprint of the file. + +Field selection is a tedious process but vital for good results. For a specific integration, like auditd manager, we can find the [exported fields](https://github.com/elastic/integrations/tree/main/packages/auditd_manager) on [GitHub](https://github.com/elastic/integrations/tree/main/packages) and pick the ones that seem useful for our purposes. An example of the processor that we used for `auditd\_manager` can be found in the image below. + +![Example of the event's fingerprint fields used for the calculation.](/assets/images/an-elastic-approach-to-large-scale-dynamic-malware-analysis/image12.png) + +### Enrichment process + +The [enrich ingest pipeline](https://www.elastic.co/guide/en/elasticsearch/reference/current/enrich-processor.html) is used for enriching incoming documents with additional information from external data sources. It allows you to enrich your data by performing lookups against an index or data set, based on specific criteria. Common use cases for the enrich ingest pipeline include augmenting documents with data from reference datasets (such as geolocation or customer information) and enriching logs with contextual information (like threat intelligence labels). + +For this project we leveraged enrich pipelines to add a unique identifier to the ingested document if it met certain criteria described within an enrich policy. To accomplish this, we first ingested a large and representative batch of benign data using a combination of normalization and fingerprint calculation pipelines. When the ingestion was completed, we set up several [enrich policies](https://www.elastic.co/guide/en/elasticsearch/reference/current/ingest-enriching-data.html) through the [execute enrich policy API](https://www.elastic.co/guide/en/elasticsearch/reference/current/execute-enrich-policy-api.html). The execution of these enrich policies will create a set of new .enrich-\* system indices. The results stored within these indices will later be used by the pipelines used to ingest mixed (benign and malicious) data. + +This will make more sense with an example workflow. To leverage the enrich ingest pipeline, we first need to create enrich policies. As we are dealing with different data sources - meaning network data looks very different from auditd manager data - we will have to create one enrich policy per data type. In our enrich policy we may use a query to specify which documents we want to include in our enrich index and which ones we want to exclude. An example enrich policy that should add all auditd manager data to the enrich index, other than the data matching three specific match phrases, is displayed below. + +![Creation of the enrich policy](/assets/images/an-elastic-approach-to-large-scale-dynamic-malware-analysis/image14.jpg) + +We are leveraging the “fingerprint” field which is calculated in the fingerprint processor as our match field. This will create an index filled with benign fingerprints to be used as the enriching index within the enrich pipeline. + +After creating this policy, we have to execute it for it to read the matching index, read the matching field, query for inclusions and exclusions, and create the new .enrich-\* system index. We do this by executing a POST request to the \_execute API. + +![Example API request to execute the enrich policy](/assets/images/an-elastic-approach-to-large-scale-dynamic-malware-analysis/image18.jpg) + +We set wait_for_completion=false to make sure that the policy doesn’t time out. This might occur if the dataset is too large. When we navigate to index management and include hidden indices, we can see that the index is created successfully. + +![The newly created enrich-* system index](/assets/images/an-elastic-approach-to-large-scale-dynamic-malware-analysis/image16.jpg) + +We now have a list of known benign fingerprints, which we will use within our enrich pipeline to filter our mixed dataset with. Our enrich pipeline will once again use a condition to differentiate between data sources. An overview of our enrich processors is displayed below. + +![Enrich ingest pipeline](/assets/images/an-elastic-approach-to-large-scale-dynamic-malware-analysis/image8.jpg) + +Focusing on the auditd manager, we built an enrich processor using the condition field to check if the document's dataset is auditd_manager.auditd. If it matches, we reference the enrich policy we created for that dataset. Using the fingerprint field, we match and enrich incoming documents. If the fingerprint is known within the enrich indices we created, we add the "enrich_label" field with the fingerprint to the document. See the processor below. + +![Configuration example](/assets/images/an-elastic-approach-to-large-scale-dynamic-malware-analysis/image7.png) + +Once a document originating from the auditd_manager.auditd dataset comes through, the enrich processor is executed, and this finally executes a [script processor](https://www.elastic.co/guide/en/elasticsearch/reference/current/script-processor.html). The script processor allows us to run inline or stored scripts on incoming documents. We leverage this functionality to read each document in the pipeline, check whether the “enrich_label” field was added; and if this is the case, we set a new boolean field called “known_benign” to true and remove the “enrich_label” and “enriched_fingerprint” fields. If the document does not contain the “enrich_label” field, we set “known\_benign” to false. This allows us to easily filter our mixed dataset in Kibana. + +![Script processor](/assets/images/an-elastic-approach-to-large-scale-dynamic-malware-analysis/image3.jpg) + +When using the “test pipeline” feature by adding a document that contains the “enrich_label”, we can see that the “fingerprint” and the “known_benign” fields are set. + +![Testing the pipeline with a benign document](/assets/images/an-elastic-approach-to-large-scale-dynamic-malware-analysis/image22.jpg) + +For documents that do not contain “enrich\_label”, just the fingerprint is set. + +Working with these enrich policies requires some setup, but once they are well structured they can truly filter out a lot of noise. Because doing this manually is a lot of work, we created some simple Python scripts to somewhat automate this process. We will go into more detail about how to automate the creation of these enrich policies, their execution, the creation of the enrich pipeline and more shortly. + +#### Ingest pipeline chaining + +The [pipeline ingest pipeline](https://www.elastic.co/guide/en/elasticsearch/reference/current/pipeline-processor.html) provides a way to chain multiple ingest pipelines. By chaining pipelines, we create a sequence of operations that collectively shapes the incoming data in the form that we want, facilitating our needs for data normalization, fingerprint calculation, and data enrichment. + +In our work with Detonate, we ended up creating two ingest pipelines. The first will process benign data, which consists of a normalization pipeline and a fingerprint calculation pipeline. The next will process malicious data, consisting of a normalization, fingerprint calculation, and enrichment pipeline. An example of this would be the following: + +![Pipeline ingest pipeline](/assets/images/an-elastic-approach-to-large-scale-dynamic-malware-analysis/image15.jpg) + +With the pipelines in place, we need to ensure that they are actually being used when ingesting data. To accomplish this, we leverage component templates. + +### Component templates + +[Component templates](https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-component-template.html) are reusable configurations that define the settings and mappings for specific types of Elasticsearch components. They provide a convenient way to define and manage consistent configurations across multiple components, simplifying the management and maintenance of resources. + +When you first start using any fleet integrations, you would notice that a lot of component templates are created by default. These are also tagged as "managed", meaning that you can't change the configuration. + +![Component template overview](/assets/images/an-elastic-approach-to-large-scale-dynamic-malware-analysis/image24.png) + +In order to accommodate users that want to post process events that are ingested via the fleet managed agent, all index templates call out to a final component template whose name ends in `@custom`. + +![Custom component template overview](/assets/images/an-elastic-approach-to-large-scale-dynamic-malware-analysis/image9.png) + +The settings you put in these components will never be changed by updates. In our use case, we use these templates to add a mapping for the enrichment fields. Most of the data that is ingested via the fleet and its integrations will go through an ingest pipeline. These pipelines will follow the same pattern in order to accommodate user customizations. Take for example the following ingest pipeline: + +![Example of fleet manager component template](/assets/images/an-elastic-approach-to-large-scale-dynamic-malware-analysis/image23.jpg) + +We can see that it is managed by fleet and it is tied to a specific version (e.g. 8.8.0) of the integration. The processor will end by calling the `@custom` pipeline, and ignore it if it doesn't exist. + +We want to add our enrichment data to the documents using the enrichment pipelines we described in the previous section. This can now simply be done by creating the `@custom` pipeline and having that call out to the enrichment pipeline. + +![Example of the created custom ingest pipeline](/assets/images/an-elastic-approach-to-large-scale-dynamic-malware-analysis/image5.jpg) + +### Automating the process + +In order to create the gsub processors, ingest pipelines, and enrich policies, we had to use three Python scripts. In the next section we will showcase these scripts. If you choose to integrate these scripts, remember that you will need to adjust them to match your own environment in order to make them work. + +#### Creating the gsub ingest pipelines + +In order to create a gsub pipeline that will replace the given random paths by static ones we used a Python [script](https://github.com/elastic/labs-releases/blob/main/tools/malware_research/gsub_pipeline_json_object.py) that takes several fields and patterns as an input, and prints out a json object which can be used by the pipeline creation API. + +#### Create Custom Pipelines + +After setting up the gsub pipeline, we leveraged [a second Python script](https://github.com/elastic/labs-releases/blob/main/tools/malware_research/custom_pipelines.py) that searches for all fleet managed configurations that call an @custom ingest pipeline. It will then create the appropriate pipeline, after which all the custom pipelines will be pointing to the `process_local_events` pipeline. + +#### Generate Enrichment Processors + +Finally, we created a [third](https://github.com/elastic/labs-releases/blob/main/tools/malware_research/enrich_policy_setup.py) Python script that will handle the creation of enrichment processors in four steps. + +1. `The cleanup process` : While an enrichment processor is used in an ingest pipeline it cannot be deleted. During testing and development we simply delete and recreate the ingest pipeline. This is of course not recommended for production environments. +2. `Create enrich policies` : The script will create every individual policy. +3. `Execute the policies` : This will start the process of creating the hidden enrichment system index. Note that the execution of the policy will take longer than the execution of the script as it will not wait for the completion of the command. Elastic will create the enrichment index in the background. +4. `Re-create the ingest pipeline` : After the enrich policy has been updated, we can now re-create the ingest pipeline that uses the enrichments. + +After executing these three scripts, the whole setup is completed, and malicious data can be ingested into the correct namespace. + +### Results and limitations + +Our benign dataset includes 53,267,892 documents generated by executing trusted binaries on a variety of operating systems and collecting events from high-value data sources. Using this normalized benign dataset, we calculated the fingerprints and created the enrich policies per data type. + +With this setup in place, we detonated 332 samples. After removing the Elastic agent metrics and endpoint alerts from the datasets, we ended up with a mixed dataset containing a total number of 41,710,279 documents. + +![Results prior to filtering on known_benign = false](/assets/images/an-elastic-approach-to-large-scale-dynamic-malware-analysis/image17.jpg) + +After setting “known\_benign” to false, we end up with 1,321,949 documents. This is a decrease of 96.83% in document count. + +![Results after filtering on known_benign = false](/assets/images/an-elastic-approach-to-large-scale-dynamic-malware-analysis/image4.png) + +The table below presents an overview of each data source and its corresponding number of documents before and after filtering on our “known\_benign” field. + +![Results of filtering out benign data](/assets/images/an-elastic-approach-to-large-scale-dynamic-malware-analysis/Screenshot_2023-07-27_at_11.08.25_AM.jpg) + +We can see that we managed to successfully filter most data sources by a decent percentage. Additionally, the numbers presented in the “after” column include malicious data that we do want to capture. For example, amongst the different malware samples several included ransomware - which tends to create a lot of file events. Also, all of the http traffic originated from malware samples trying to connect to their C2’s. The auditd\_manager and fim.event datasets include a lot of the syscalls and file changes performed by the samples. + +While building out this pipeline, several lessons were learnt. First of all, as mentioned before, if you add one wrong field to the fingerprint calculation the whole dataset might end up generating lots of noise. This can be seen by adding the source.port to the packetbeat fingerprint calculation, resulting in the endpoint.events.network and all network\_traffic-\* datasets to increase drastically. + +The second lesson we learned: it is not only important to have a representative dataset, but it is also important to have a large dataset. These two go hand in hand, but we learnt that having a small dataset or a dataset that does not generate very similar behavior to the dataset that will be ingested later, will cause the pipelines to be less than half as effective. + +Finally, some data sources are better suited for this filtering approach than others. For example, when dealing with `system.syslog` and `system.auth` events, most of the fields within the document (except the message field) are always the same. As we cannot use this approach for unstructured data, such as plain text fields, our filter would filter out 99% of the events when just looking at the remaining fields. + +### Visualizing results + +Kibana offers many great options to visualize large datasets. We chose to leverage the Lens functionality within Kibana to search through our malicious dataset. By setting `known\_benign` to false, setting `count of fingerprint` as a metric, and sorting by ascending order, we can right away see different malware samples execute different tasks. Examples of file events is shown below. + +![Using Lens to visualize malicious file events](/assets/images/an-elastic-approach-to-large-scale-dynamic-malware-analysis/image2.png) + +Within this table, we can see - suspicious files being created in the `/dev/shm/` directory - “ `HOW_TO_DECRYPT.txt` ” file creations indicating the creation of a ransom message - Files being changed to contain new random file extensions, indicating the ransomware encryption process. + +When looking into file integrity monitoring events, we can also very easily distinguish benign events from malicious events by applying the same filter. + +![Using Lens to visualize malicious symlink events](/assets/images/an-elastic-approach-to-large-scale-dynamic-malware-analysis/image10.jpg) + +Right away we notice the creation of a symlink for a `linux.service` and `bot.service` , and several run control symlinks to establish persistence onto the system. + +Looking at network connections, we can see `connection\_attempted` events from malicious samples to potential C2 servers on several uncommon ports. + +![Using Lens to visualize malicious network connections](/assets/images/an-elastic-approach-to-large-scale-dynamic-malware-analysis/image19.jpg) + +Finally, looking at auditd manager syscall events, we can see the malware opening files such as cmdline and maps and attempting to change the permissions of several files. + +![Using Lens to visualize malicious syscalls](/assets/images/an-elastic-approach-to-large-scale-dynamic-malware-analysis/image11.png) + +Overall, in our opinion the data cleaning results are very promising and allow us to more efficiently conduct dynamic malware analysis on a large scale. The process can always be further optimized, so feel free to take advantage of our approach and fine tune it to your specific needs. + +## Beyond Dynamic Malware Analysis + +In the previous sections we described our exact use case for leveraging fingerprint and enrich ingest pipelines. Other than malware analysis, there are many other fields that can reap the benefits of a workflow similar to the one outlined above. Several of these applications and use cases are described below: + +- Forensics and Security: Fingerprinting can be employed in digital forensics and security investigations to identify and link related artifacts or events. It helps in tracing the origin of data, analyzing patterns, and identifying potential threats or anomalies in log files, network traffic, or system events. Researchers over at Microsoft leveraged fuzzy hashing in [previous research](https://techcommunity.microsoft.com/t5/microsoft-security-experts-blog/fuzzy-hashing-logs-to-find-malicious-activity/ba-p/3786669) to detect malicious web shell traffic. +- Identity Resolution: Fingerprinting can be used to uniquely identify individuals or entities across different data sources. This is useful in applications like fraud detection, customer relationship management, and data integration, where matching and merging records based on unique identifiers is crucial. +- Data Deduplication: Fingerprinting can help identify and eliminate duplicate records or documents within a dataset. By comparing fingerprints, you can efficiently detect and remove duplicate entries, ensuring data integrity and improving storage efficiency. Readers interested in data deduplication use cases might find great value in pre-built tools such as [Logslash](https://blog.foxio.io/introducing-logslash-and-the-end-of-traditional-logging-2c6708b6fc1c) to achieve this goal. +- Content Management: Fingerprinting can be used in content management systems to detect duplicate or similar documents, images, or media files. It aids in content deduplication, similarity matching, and content-based searching by improving search accuracy and enhancing the overall user experience. +- Media Identification: Fingerprinting techniques are widely used in media identification and recognition systems. By generating unique fingerprints for audio or video content, it becomes possible to identify copyrighted material, detect plagiarism, or enable content recommendation systems based on media similarity. + +## Conclusion + +There are many different approaches to dynamic malware analysis. This blog post explored some of these options by leveraging the powerful capabilities offered by Elastic. Our aim was to both present a new method of dynamic malware analysis while at the same time broadening your understanding and knowledge of the built-in functionalities within Elastic. + +Elastic Security Labs is the threat intelligence branch of Elastic Security dedicated to creating positive change in the threat landscape. Elastic Security Labs provides publicly available research on emerging threats with an analysis of strategic, operational, and tactical adversary objectives, then integrates that research with the built-in detection and response capabilities of Elastic Security. + +Follow Elastic Security Labs on Twitter @elasticseclabs and check out our research at [www.elastic.co/security-labs/](http://www.elastic.co/security-labs/). + diff --git a/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/analysis_of_log4shell_cve_2021_45046.mdx b/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/analysis_of_log4shell_cve_2021_45046.mdx new file mode 100644 index 0000000000000..d9d8a93aa9720 --- /dev/null +++ b/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/analysis_of_log4shell_cve_2021_45046.mdx @@ -0,0 +1,66 @@ +--- +title: "Analysis of Log4Shell vulnerability & CVE-2021-45046" +slug: "analysis-of-log4shell-cve-2021-45046" +date: "2022-11-30" +description: "In this post, we cover next steps the Elastic Security team is taking for users to continue to protect themselves against CVE-2021-44228, or Log4Shell." +author: + - slug: jake-king +image: "photo-edited-12-e.jpg" +category: + - slug: security-research + - slug: vulnerability-updates +--- + +> _To understand how Elastic is currently assessing internal risk of this vulnerability in our products please see the advisory_[_here._](https://discuss.elastic.co/t/apache-log4j2-remote-code-execution-rce-vulnerability-cve-2021-44228-esa-2021-31/291476) +> +> _This document was updated on December 17, 2021 to reflect a revised CVSS score for CVE-2021-45046, and new findings by the community._ + +In recent days Log4Shell, or CVE-2021-44228, has dominated the news cycle in the world of information security and beyond. Elastic released an [advisory](https://discuss.elastic.co/t/apache-log4j2-remote-code-execution-rce-vulnerability-cve-2021-44228-esa-2021-31/291476?ultron=log4js-exploit&blade=announcement&hulk=email&mkt_tok=ODEzLU1BTS0zOTIAAAGBU8N1ZUOwzTcRbJCOiByHmeYiopMnarq-QPWBIyhPI3Vvsp6w-4q4PBbTGZ3fZ0sB75cpaUdOddA1k-6-yh3QwAicvJTgafdJWv_-9Cn2GoKLvsmt) detailing how Elastic products and users are impacted, and a [blog](https://www.elastic.co/blog/detecting-log4j2-with-elastic-security?ultron=log4js-exploit&blade=announcement&hulk=email&mkt_tok=ODEzLU1BTS0zOTIAAAGBU8N1ZDYRbFq2QZ4ZK8tc2IbDatArsdI6WGcA2M90g4v02svJeqCXFeZ23R4TjeYii4KBGAkqMBgWc5IkxYrmefgwZBanjGQh8v66drUymiVSQFvs) post describing how our users can leverage Elastic Security to help defend their networks. + +Many readers have further questions as to how we’re tracking this issue within Elastic Security, what our coverage is now, and what we’re expecting to do next. This post outlines a few details for our current status, and provides details regarding a new, related vulnerability: CVE-2021-45046. + +## Elastic Security response + +As you may imagine, the team has worked tirelessly to ensure that we’re developing detections for both active exploitation of the vulnerability, as well as post-compromise indicators, and will continue active development until further notice. + +We’re spending time focusing on detailed detections that better align with some of the emerging trends that adversaries are now taking advantage of as they have time to develop their attack strategies. And we’re not working in silence — those that may have had a chance to catch up on our [original post](https://www.elastic.co/blog/detecting-log4j2-with-elastic-security) a few days ago will be pleasantly surprised we’ve added further detections and hunting examples, and will continue to do so as we learn more with the community. + +Alongside the threat research and signature development, we’ve noted some interesting observations: + +- We noted several instances of [generic crypto miners](https://www.virustotal.com/gui/file/5b25db204b5cd5cc3193f4378dd270dced80da9d39874d8b6fdd75e97d2cc907/detection) for Linux being deployed that appeared to be related to exploitation of this CVE, but determined that they are benign true positives +- We’ve stopped at least eight different families of malware being deployed using the log4j exploit, indicating widespread adoption of the exploit by threats of all kinds +- While we are observing coverage across our full protection suite (such as behavior protection), it is noteworthy that our free basic-tier malware protection is successfully preventing initial access + +We will aim to keep users and readers apprised of findings, and hope to share additional observations in the wild as we see them. + +## A new contender: CVE-2021-45046 + +While we watch the CVE-2021-44228 (Log4Shell) vulnerability dominate the news cycles, a new contender, [CVE-2021-45046](https://nvd.nist.gov/vuln/detail/CVE-2021-45046), was accidentally introduced to Log4j2j version 2.15.0, allowing adversaries to invoke a Denial of Service, and a remote code execution condition through specially crafted payloads. Previous mitigations to avoid Information Disclosure vulnerabilities by setting the `log4j2.noFormatMsgLookup` state to `true` do not mitigate against this new finding, according to the CVE details. + +While initially CVE-2021-45046 carried a lower CVSS score of 3.7 due to the impact of the initially discovered condition that can be invoked, this was re-evaluated to a 9.0 indicating limited remote code execution was possible. The finding was shared on December 16, 2021 by [Alvaro Muñoz](https://twitter.com/pwntester/status/1471465662975561734), who identified that while the default setting formatMsgNoLookups was accurately set to true, there were alternative locations for lookups to take place. Technical details are still unfolding from the community, however the Log4j2 team shared the following message within their security updates: + +_The reason these measures are insufficient is that, in addition to the Thread Context attack vector mentioned above, there are still code paths in Log4j where message lookups could occur: known examples are applications that use Logger.printf("%s", userInput), or applications that use a custom message factory, where the resulting messages do not implement StringBuilderFormattable. There may be other attack vectors._ + +_The safest thing to do is to upgrade Log4j to a safe version, or remove the JndiLookup class from the log4j-core jar._ [_Reference here_](https://logging.apache.org/log4j/2.x/security.html) + +Given this new information, and readily available[POCs](https://twitter.com/marcioalm/status/1471740771581652995) available for exploitation, the Apache team has recommended those impacted upgrade to the latest, safe version of Log4j2, or alternatively remove the JndiLookup class from the log4j-core jar. + +Elastic Security has observed many threat actors and benign scanners leveraging this new methodology already in some edge environments, with payloads incorporating previous attack methodologies such as key extraction attempts and base64 encoded payloads: + +![A preview of the rapid acceleration of scanning attempts adopting this new vulnerability](/assets/images/analysis-of-log4shell-cve-2021-45046/scanning-attempts-vulnerability.jpg) + +We anticipate adding further details as we learn them, and thank the team at lunasec specifically for providing a [detailed, early summary](https://www.lunasec.io/docs/blog/log4j-zero-day-severity-of-cve-2021-45046-increased/) of this emerging situation, and of course, provide kudos to [Alvaro Muñoz](https://twitter.com/pwntester) of Github Security Lab for the findings. + +## Thank you (again!), from Elastic Security + +We want to thank all of the security teams across the globe for your tireless work this week. As we referenced before, openness and collaboration in the security community to safeguard all users is paramount when facing such a serious and pervasive vulnerability. + +Existing Elastic Security users can access these capabilities within the product. If you’re new to Elastic Security, take a look at our [Quick Start guides](https://www.elastic.co/training/elastic-security-quick-start) (bite-sized training videos to get you started quickly) or our [free fundamentals training courses](https://www.elastic.co/training/free#fundamentals). + +Get started with a [free 14-day trial of Elastic Cloud](https://cloud.elastic.co/registration). Or [download](https://www.elastic.co/downloads/) the self-managed version of the Elastic Stack for free. + +### References + +[https://logging.apache.org/log4j/2.x/security.html](https://logging.apache.org/log4j/2.x/security.html) + +[https://www.lunasec.io/docs/blog/log4j-zero-day-severity-of-cve-2021-45046-increased/](https://www.lunasec.io/docs/blog/log4j-zero-day-severity-of-cve-2021-45046-increased/) diff --git a/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/attack_chain_leads_to_xworm_and_agenttesla.mdx b/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/attack_chain_leads_to_xworm_and_agenttesla.mdx new file mode 100644 index 0000000000000..920df028a2376 --- /dev/null +++ b/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/attack_chain_leads_to_xworm_and_agenttesla.mdx @@ -0,0 +1,224 @@ +--- +title: "Attack chain leads to XWORM and AGENTTESLA" +slug: "attack-chain-leads-to-xworm-and-agenttesla" +date: "2023-04-10" +description: "Our team has recently observed a new malware campaign that employs a well-developed process with multiple stages. The campaign is designed to trick unsuspecting users into clicking on the documents, which appear to be legitimate." +author: + - slug: salim-bitam +image: "blog-thumb-coin-stacks.jpg" +category: + - slug: attack-pattern + - slug: malware-analysis +tags: + - xworm + - agenttesla +--- + +## Key Takeaways + +- Threat actors are deploying known malware using their own custom .NET loaders +- The threat actors employ simple and well-known tactics such as bypassing AMSI through patching and a basic custom .NET loader +- The threat actors are abusing legitimate free file hosting services + +## Preamble + +Our team has recently observed a new malware campaign that employs a well-developed process with multiple stages. The campaign is designed to trick unsuspecting users into clicking on the documents, which appear to be legitimate, but are in fact fake, the adversary leverages weaponized word documents to execute malicious PowerShell scripts, and also utilizes a custom obfuscated .NET loader to load various malware strains, including XWORM and AGENTTESLA. + +## RTF loader code analysis + +### Overview + +During a recent investigation, we discovered a malicious word document named `Card & Booking Details.docx`. This document has been designed with the intent to deceive the victim and includes two falsified scanned documents, namely a credit card and a passport. + +Upon opening the document, an RTF object hosted at `www.mediafire[.]com/file/79jzbqigitjp2v2/p2.rtf` is fetched. + +This RTF object contains a macro-enabled Excel object. When opened, this macro downloads an obfuscated powerShell script which in turn deploys different malware families. + +At the time of this writing, we have observed two distinct malware families, namely XWORM and AGENTTESLA, have been deployed through this execution chain. Both malware families mentioned above are loaded into the compromised system's memory by the same custom .NET loader. Once loaded, the malicious payload can carry out a range of functions, such as stealing sensitive data and executing commands on the compromised system. + +![Execution flow diagram](/assets/images/attack-chain-leads-to-xworm-and-agenttesla/image8.png) + +In this research post, we will walk through the initial execution of the malware and detail the capabilities we discovered. + +### Extracting the malicious VBA + +The RTF document contains multiple embedded objects, including an interesting one that caught our attention: `Excel.SheetMacroEnabled`. + +![Listing objects embedded in the RTF document](/assets/images/attack-chain-leads-to-xworm-and-agenttesla/image1.jpg) + +We can use [`rtfdumpy.py`](https://github.com/DidierStevens/DidierStevensSuite/blob/master/rtfdump.py), a script developed by Didier Stevens to analyze RTF files, to dump the object and [`olevba.py`](https://www.decalage.info/python/olevba), a script developed by Philippe Lagadec, to extract any embedded VBA scripts from an [OLE](https://en.wikipedia.org/wiki/Object_Linking_and_Embedding) object. The extracted VBA script shown below downloads and executes a malicious powershell script from `https://www.mediafire[.]com/file/xnqxmqlcj51501d/7000m.txt/file`. + +![Extracting the VBA script from the Excel sheet object](/assets/images/attack-chain-leads-to-xworm-and-agenttesla/image2.png) + +### Powershell script analysis + +The malicious PowerShell script is obfuscated using string substitution to evade detection and make analysis more difficult. + +![Powershell script obfuscated using string substitution](/assets/images/attack-chain-leads-to-xworm-and-agenttesla/image13.png) + +It contains additional powershell script blocks in hex format that will be deployed in the infected machine designed to prepare the environment by setting up persistence, bypassing AMSI, disabling Windows defender and creating a mechanism to update the malware. The ultimate objective is to install two .NET binaries, namely a loader and a payload (XWORM / AGENTTESLA). + +### Deleting the malicious document + +The malware starts by deleting the original Word document, first killing the process `Winword.exe` and then deleting all .DOCX files located in the default `Downloads` and `Desktop` folders of every user. This initial step shows the malware's destructive nature and how it can potentially harm the user's data. + +![Powershell command to delete the malicious word document](/assets/images/attack-chain-leads-to-xworm-and-agenttesla/image5.jpg) + +### Persistence + +The malware creates a directory in the path `C:\ProgramData\MinMinons` , which is used to store other Powershell scripts and binaries. The currently running Powershell script is then copied to `C:\ProgramData\MinMinons\Candlegraphy.\_\_\_`. + +Next, the malware deobfuscates the first embedded Powershell script which is used to create persistence. It first writes a JScript file that invokes the original Powershell script saved in `C:\ProgramData\MinMinons\Candlegraphy.\_\_\_` through the activeXObject shell, then a scheduled task named “MOperaChrome” is created to run the JScript file using the Microsoft signed [Windows Script Host (WSH) utility](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/wscript), `wscript.exe`. + +![Persistence through task scheduling](/assets/images/attack-chain-leads-to-xworm-and-agenttesla/image10.jpg) + +### AMSI bypass + +The second embedded powershell script is responsible for bypassing AMSI by patching the `amsiInitFailed` flag. In doing so, the initialization of AMSI fails, leading to the prevention of any scan being initiated for the ongoing process. Furthermore, the PowerShell script proceeds to disable the Microsoft Windows Defender service. + +![Disabling WinDefend service](/assets/images/attack-chain-leads-to-xworm-and-agenttesla/image5.jpg) + +### User creation + +The script creates a local administrator account named “System32” and adds it to the Remote Desktop Users group. This enables the attacker to log in via Remote Desktop Protocol (RDP). Next, the script disables the machine's firewall to allow inbound RDP connection attempts which aren’t filtered by edge controls. + +![Creating a backdoor user](/assets/images/attack-chain-leads-to-xworm-and-agenttesla/image9.jpg) + +### Malware update persistence + +The third embedded script stores a secondary JScript file, whose purpose is downloading a revised or updated version of the malware. This file is saved to a predetermined location at `C:\ProgramData\MinMinons\miguan.js`. Furthermore, a scheduled task with the name (“miguaned”) is created to execute the JScript file through `wscript.exe` , similar to the previously described task. + +The JScript creates an instance of `WScript.Shell` object by calling ActiveXObject with the following CLSID `{F935DC22-1CF0-11D0-ADB9-00C04FD58A0B}` which corresponds to Shell Object, then downloads from the URL `https://billielishhui.blogspot[.]com/atom.xml` the update powershell malware. + +![JScript script used for updating the malware](/assets/images/attack-chain-leads-to-xworm-and-agenttesla/image4.jpg) + +### .NET loader + +The custom DOTNET loader employs the [P/INVOKE technique](https://learn.microsoft.com/en-us/dotnet/standard/native-interop/pinvoke) to call the native Windows API and inject a payload into a signed microsoft binary via [process hollowing](https://attack.mitre.org/techniques/T1055/012/). + +The loader’s code employs various obfuscation techniques to hinder analysis, including the use of dead instruction, renamed symbols to make the code less readable and more confusion and encoded strings. Fortunately a tool like [de4dot](https://github.com/de4dot/de4dot) can be used to output a human-readable version of it. + +![.NET loader code obfuscation](/assets/images/attack-chain-leads-to-xworm-and-agenttesla/image12.jpg) + +The malware leverages the `LoadLibrary` and `GetProcAddress` APIs to access the required Windows APIs. To obscure the names of these APIs, the loader stores them in an encoded format within the binary file, utilizing a sequence of substitution and string reversal methods. + +![.NET loader string obfuscation](/assets/images/attack-chain-leads-to-xworm-and-agenttesla/image3.jpg) + +The loader then starts a process in a suspended state using `CreateProcessA` API. The following is the list of executables it uses as a host for it’s malicious code: + +- `C:\Windows\Microsoft.NET\Framework\v4.0.30319\RegSvcs.exe` +- `C:\Windows\Microsoft.NET\Framework\v2.0.50727\RegSvcs.exe` +- `C:\Windows\Microsoft.NET\Framework\v3.5\Msbuild.exe` + +These binaries are signed and trusted by the system and can evade detection by security software that relies on whitelisting system processes. It then uses `Zwunmapviewofsection` to unmap the memory of the target process, writes the payload to the suspended process and then resume the thread using `ResumeThread` API. + +### Final payload + +During our research we discovered that the threat actor has been deploying different payloads. Namely, we observed 2 families: XWORM and AGENTTESLA. + +XWORM has gained notoriety in the underground criminal marketplace due to its ability to employ sophisticated capabilities like virtualization and sandbox detection, used to avoid detection and support persistence within an infected system. + +Of particular concern is the fact that XWORM is readily available on the internet as a cracked version, with version 2.1 being especially prevalent. This highlights the dangers of underground cybercrime markets and the ease with which malicious actors can access and utilize powerful tools. + +Two different versions of the XWORM family were observed versions 2.2 and 3.1. The following is the configuration of a XWORM sample in plain text. + +![XWorm configuration](/assets/images/attack-chain-leads-to-xworm-and-agenttesla/image14.jpg) + +AGENTTESLA is a trojan and credential stealer written in .NET. While it first emerged in 2014, it is now among the most active and malicious software. AGENTTESLA is affordably priced and includes support from the developers, making it easily accessible to cybercriminals with limited technical skills. + +The sample we analyzed was heavily obfuscated, masqueraded as an AVG installer,and leverages discord for C2. It uploads stolen information to the attacker’s Discord channel via the following webhook: `https://discord[.]com/api/webhooks/1089956337733087274/uYNA_D8Ns1z9NZ3B1mGp0XXyGq-785KLGIfEAZsrz3TJd5fvOjXA927F7bUTTzbNT6Zk`. + +![Agent Tesla masquerading as an AVG installer](/assets/images/attack-chain-leads-to-xworm-and-agenttesla/image6.jpg) + +![The discord webhook extracted dynamically](/assets/images/attack-chain-leads-to-xworm-and-agenttesla/image7.png) + +## Observed adversary tactics and techniques + +Elastic uses the MITRE ATT&CK framework to document common tactics, techniques, and procedures that threats use. + +## Tactics + +Tactics represent the “why” of a technique or sub-technique. They represent the adversary’s tactical goals: the reason for performing an action. + +- [Initial access](https://attack.mitre.org/tactics/TA0001) +- [Execution](https://attack.mitre.org/tactics/TA0002) +- [Persistence](https://attack.mitre.org/tactics/TA0003) +- [Command and control](https://attack.mitre.org/tactics/TA0011) +- [Defense evasion](https://attack.mitre.org/tactics/TA0005) + +## Techniques/subtechniques + +Techniques and Subtechniques represent how an adversary achieves a tactical goal by performing an action. + +- [Process injection](https://attack.mitre.org/techniques/T1055/) +- [Indicator removal: File deletion](https://attack.mitre.org/techniques/T1070/004/) +- [Scheduled task/job: Scheduled task](https://attack.mitre.org/techniques/T1053/005/) +- [User Execution: Malicious File](https://attack.mitre.org/techniques/T1204/002/) +- [Phishing: Spearphishing Attachment](https://attack.mitre.org/techniques/T1566/001/) +- [Command and Scripting Interpreter: Powershell](https://attack.mitre.org/techniques/T1059/003/) +- [Obfuscated Files or Information](https://attack.mitre.org/techniques/T1027/) +- [Impair Defenses: Disable or Modify Tools](https://attack.mitre.org/techniques/T1629/003/) +- [Create Account](https://attack.mitre.org/techniques/T1136/) + +## Detection logic + +### YARA + +Elastic Security has created YARA rules to identify this activity. Below are YARA rules to identify XWORM and [AGENTTESLA](https://github.com/elastic/protections-artifacts/blob/main/yara/rules/Windows_Trojan_AgentTesla.yar) malware families. + +``` +rule Windows_Trojan_Xworm_732e6c12 { +meta: + author = "Elastic Security" + id = "732e6c12-9ee0-4d04-a6e4-9eef874e2716" + fingerprint = "afbef8e590105e16bbd87bd726f4a3391cd6a4489f7a4255ba78a3af761ad2f0" + creation_date = "2023-04-03" + last_modified = "2023-04-03" + os = "Windows" + arch = "x86" + category_type = "Trojan" + family = "Xworm" + threat_name = "Windows.Trojan.Xworm" + source = "Manual" + maturity = "Diagnostic" + reference_sample = "bf5ea8d5fd573abb86de0f27e64df194e7f9efbaadd5063dee8ff9c5c3baeaa2" + scan_type = "File, Memory" + severity = 100 + +strings: + $str1 = "startsp" ascii wide fullword + $str2 = "injRun" ascii wide fullword + $str3 = "getinfo" ascii wide fullword + $str4 = "Xinfo" ascii wide fullword + $str5 = "openhide" ascii wide fullword + $str6 = "WScript.Shell" ascii wide fullword + $str7 = "hidefolderfile" ascii wide fullword +condition: + all of them} + +rule Windows_Trojan_AgentTesla_d3ac2b2f { +meta: + author = "Elastic Security" + id = "d3ac2b2f-14fc-4851-8a57-41032e386aeb" + fingerprint = "cbbb56fe6cd7277ae9595a10e05e2ce535a4e6bf205810be0bbce3a883b6f8bc" + creation_date = "2021-03-22" + last_modified = "2022-06-20" + os = "Windows" + arch = "x86" + category_type = "Trojan" + family = "AgentTesla" + threat_name = "Windows.Trojan.AgentTesla" + source = "Manual" + maturity = "Diagnostic, Production" + reference_sample = "65463161760af7ab85f5c475a0f7b1581234a1e714a2c5a555783bdd203f85f4" + scan_type = "File, Memory" + severity = 100 + +strings: + $a1 = "GetMozillaFromLogins" ascii fullword + $a2 = "AccountConfiguration+username" wide fullword + $a3 = "MailAccountConfiguration" ascii fullword + $a4 = "KillTorProcess" ascii fullword + $a5 = "SmtpAccountConfiguration" ascii fullword + $a6 = "GetMozillaFromSQLite" ascii fullword +``` diff --git a/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/automating_security_protections_rapid_response_to_malware.mdx b/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/automating_security_protections_rapid_response_to_malware.mdx new file mode 100644 index 0000000000000..d26fbf2371e05 --- /dev/null +++ b/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/automating_security_protections_rapid_response_to_malware.mdx @@ -0,0 +1,48 @@ +--- +title: "Automating the Security Protections rapid response to malware" +slug: "automating-security-protections-rapid-response-to-malware" +date: "2023-03-01" +description: "See how we’ve been improving the processes that allow us to make updates quickly in response to new information and propagate those protections to our users, with the help of machine learning models." +author: + - slug: samantha-zeitlin +image: "blog-security-endpoint-720x420.png" +category: + - slug: machine-learning + - slug: detection-science +--- + +Cyber attacks on corporate networks were [up 50% in 2021](https://www.forbes.com/sites/chuckbrooks/2022/01/21/cybersecurity-in-2022--a-fresh-look-at-some-very-alarming-stats/?sh=675676ea6b61), and it’s [expected that 2022 will see more of the same](https://www.govtech.com/blogs/lohrmann-on-cybersecurity/the-top-22-security-predictions-for-2022). [Elastic Endpoint Security](https://www.elastic.co/endpoint-security/) includes a variety of protection layers to ensure maximum coverage against different types of malware. There have been a few examples recently of the need for [fast, accurate updates](https://www.elastic.co/blog/elastic-protects-against-data-wiper-malware-targeting-ukraine-hermeticwiper) of user environments in order to protect against the latest malware. Here at Elastic, we’ve been improving the processes that allow us to make updates quickly in response to new information and propagate those protections to our users. + +As part of our security solution, we use a machine learning model to help us detect malware based on known characteristics. Since machine learning is never perfect, we deploy supplemental artifacts, including lists of known file hashes that range from malicious to benign. There are two scenarios when we might need to update these lists, which we’ll cover here. Using these, teams can experience a much faster response to malware. + +[Related article: [Sandboxing anti-malware products for fun and profit](https://www.elastic.co/blog/sandboxing-anti-malware-products-for-fun-and-profit)] + +## Scenario 1: The model isn’t perfect + +This happens pretty rarely, since our model has True Negative rates of 99.8%. But no model is perfect, and our True Positive rates vary from 99% (which is great) down to 97.9%, due to noisy data — particularly large bursts of near-duplicates. In applying machine learning to cybersecurity, data drift is an ever-present challenge and part of what makes it such an interesting problem. + +There are a couple of ways we can find out if our model is doing the wrong thing: + +1. **User feedback.** + +A user sends us an email telling us that a piece of custom software is being flagged as malware, but is actually safe. + +2. **Telemetry data coming back from our model running on customers’ machines.** + +We look at the volume and velocity of alerts, using Elastic’s Anomaly Detection feature to let us know if there is a sudden spike from a particular file. We also use patterns to help us confirm if an alert is coming from a single noisy machine, a test cluster, or a legitimate threat. + +The advantage of using lists as a backstop to machine learning is that it’s a fast and easy way to make sure our customers are protected from new malware, as well as protecting them from unnecessary noise from false positives. + +## Scenario 2: New forms of malware appear + +We typically find out about new kinds of malware from either security news/community resources, or our own Security Intelligence and Analytics team identifying new kinds of malware. + +When this happens, we can easily deploy small changes to lists. We update the model separately, because that takes longer. + +We’ve been steadily adding more automation to make this process of deploying updated lists to customers smoother and faster, with the goal of making it easy for anyone on the team to create and deploy an update. We’ve also been working on making the process of updating the model easier and faster. + +## Threats yet discovered… + +The Elastic Security Intelligence and Analytics team continues to research and respond to groundbreaking threats in its mission to help Elastic customers and the broader security community. If you’re using [Elastic Security](https://www.elastic.co/security?utm_source=log4j+hub+blog&utm_medium=embed+link&utm_campaign=log4j_hub_blog&utm_id=log4j&utm_content=elastic+security) already, you can expect to see our latest findings in the newsfeed within the platform. We’ll also post our latest findings on [elastic.co/blog](https://www.elastic.co/blog). + +Ready to become part of the Elastic Security community and take advantage of the team’s leading threat research? Get started with a free [14-day trial of Elastic Cloud](https://cloud.elastic.co/registration?utm_source=log4j+hub+blog&utm_medium=embed+link&utm_campaign=log4j_hub_blog&utm_id=log4j&utm_content=trail) or [download](https://www.elastic.co/downloads/?utm_source=log4j+hub+blog&utm_medium=embed+link&utm_campaign=log4j_hub_blog&utm_id=log4j&utm_content=download) the self-managed version of the Elastic Stack for free. diff --git a/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/behind_the_scenes_global_threat_report.mdx b/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/behind_the_scenes_global_threat_report.mdx new file mode 100644 index 0000000000000..7a58953fb218a --- /dev/null +++ b/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/behind_the_scenes_global_threat_report.mdx @@ -0,0 +1,45 @@ +--- +title: "Behind the scenes: The making of a Global Threat Report" +slug: "behind-the-scenes-global-threat-report" +date: "2022-11-30" +description: "What was our approach and process for creating a global threat report?" +author: + - slug: mark-dufresne +image: "gtr-blog-image-720x420.jpg" +category: + - slug: reports +--- + +The first [Elastic Global Threat Report](https://www.elastic.co/explore/security-without-limits/global-threat-report) was published earlier this week. In it, you will learn about trends observed by our threat researchers, our predictions for what’s coming next, and some of our recommendations to operate securely in the face of today’s and tomorrow’s threats. If you haven’t read it yet, go [check it out](https://www.elastic.co/explore/security-without-limits/global-threat-report). + +As a technical leader in [Elastic Security](http://www.elastic.co/security), I'd like to reveal a small amount about what goes into reports like this one and why it’s significant. + +## Why did we do it? + +If you didn’t already know this, you know it now: Elastic is a security company. We are also different — we’re open and transparent. We share exactly how our detections and preventions work in the [protections-artifacts](https://github.com/elastic/protections-artifacts) and [detection-rules](https://github.com/elastic/detection-rules) repos. We’ve launched [Elastic Security Labs](https://www.elastic.co/security-labs/) and regularly publish our research, discoveries, and tools. Anyone can spin up a [trial](https://cloud.elastic.co/registration) and try all our features — no barriers, no sales BS. This report is another way we’re bringing transparency to you. We want to empower you by sharing what we know and what we think is coming, and we will continue to expand the scope of what we share in the coming months. + +## How'd we do it? + +Put simply, by analyzing a vast amount of data. Behind [Elastic Security Labs](http://www.elastic.co/security-labs) is a large team of malware and intelligence analysts, security engineers, researchers, data scientists, and other experts. This team builds and maintains all the protection features in Elastic’s security products: blocking malware, in-memory threats, ransomware, and other malicious behaviors. You name it, we do it. To do this effectively, we need visibility into how our features perform and what threats they’re coming in contact with. We get that visibility through anonymous telemetry shared with us by our users (as well as through research our team carries out on threat feeds and other public datasets). + +Our researchers are in the telemetry data daily. Usually, we are focused on the performance of particular features, eliminating false positives and adding protection against emergent techniques, some of which you can learn about in our [threat report](https://www.elastic.co/explore/security-without-limits/global-threat-report). This battle never ends, and we don’t anticipate that changing any time soon. + +## Why now? + +As our user base rapidly grew over the past year, we came to the conclusion that we now observe a significant percentage of all threats. Upon hitting that critical mass, we decided to peel off some of our best researchers to zoom out, analyze the totality of what we’ve seen, and determine if we had a story worth sharing. We felt we probably had something to contribute to the community’s collective understanding of the threat landscape, and as you read the report, we hope you agree that we were right to think that. + +## Diving deeper + +With that backdrop, I can share a bit more about how a report like this comes to be. Under the leadership of [Devon Kerr](https://twitter.com/_devonkerr_), we built an eight-week plan to analyze and summarize the telemetry coming in from our various features. All our event telemetry data lives in Elasticsearch, which makes for straightforward summarization and visualization. + +Data normalization was a significant challenge. This included filtering out excessively noisy endpoints so results aren’t skewed, ignoring data from test clusters, ignoring alerts for data which we later realized were false positives, pulling together signals from our full [Elastic Security](http://www.elastic.co/security) solution, and more. It wasn’t the most glamorous work in the world, but it was foundational to producing meaningful results at the end. We’ll plan for a couple weeks in this phase again next time — it will always be a significant lift. + +Once the data was in good shape, we extracted the meaning from raw aggregations of a massive number of events to determine insights worth sharing, which help us understand the present state of the threat landscape. In particular, we wanted to explain the most prevalent threats we're seeing and put them in context. These are patterns that ebb and flow throughout the year, making an annual overview particularly useful for spotting the threats making the biggest impact. This led to the various charts and statistics laid out in the report. It took us a couple weeks to settle on a list among the team. + +Next, we had to write. Devon, [Andy Pease](https://twitter.com/andythevariable), [Daniel Stepanic](https://twitter.com/DanielStepanic), and [Terrance DeJesus](https://twitter.com/_xDeJesus) did the heavy lifting here. Anyone who’s done technical writing knows how important clarity and conciseness are in delivering a message that can be understood by the general public. A few dozen pages came together in a way we’re proud of. Importantly, we partnered closely with [Dhrumil Patel](https://www.linkedin.com/in/pateldhrumil/), our product management lead, and [Jen Ellard,](https://twitter.com/jellard8) security product marketing lead, for the [Threat Report](https://www.elastic.co/explore/security-without-limits/global-threat-report) effort to make sure our points were clear and meaningful to our user base. + +All of that brought us to the end of our eight week plan to develop the report. By late August, we were largely pencils-down on the content but far from done. We’re lucky to have a team of designers at Elastic to help us transform a wall of text in a Google doc into a PDF with style and graphics to enhance meaning and help our conclusions and recommendations jump off the page. We knew that this process would take time, many drafts, and a lot of back and forth. Planning and executing this piece of the project took about as long as the data gathering, analysis, and writing. We learned a lot about how long it takes to go from completed draft to final copy and will involve our internal partners early and often in the process. + +## Tell us what you think + +We’d love to hear your feedback about the first [Elastic Global Threat Report](https://www.elastic.co/explore/security-without-limits/global-threat-report). More is on the way. We expect to make this an annual publication, and between now and then we’re hoping to deliver a more interactive version of this inaugural report. diff --git a/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/blister_configuration_extractor.mdx b/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/blister_configuration_extractor.mdx new file mode 100644 index 0000000000000..b205162f3ab5e --- /dev/null +++ b/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/blister_configuration_extractor.mdx @@ -0,0 +1,65 @@ +--- +title: "BLISTER Configuration Extractor" +slug: "blister-configuration-extractor" +date: "2022-12-06" +description: "Python script to extract the configuration and payload from BLISTER samples." +author: + - slug: elastic-security-labs +image: "tools-image.jpg" +category: + - slug: tools +tags: + - blister + - ref7890 +--- + +Python script to extract the configuration and payload from BLISTER samples. + +[Download blister-config-extractor.tar.gz](https://assets.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt9bce8a0e1a513bd5/62882db13b9b8554904a4baa/blister-config-extractor.tar.gz) + +## Getting Started + +This tool provides a Python module and command line tool that will extract configurations from the BLISTER malware loader and dump the results to screen. + +> For information on the BLISTER malware loader and campaign observations, check out our blog posts detailing this: +> +> - [BLISTER Campaign Analysis](https://www.elastic.co/security-labs/elastic-security-uncovers-blister-malware-campaign) +> - [BLISTER Malware Analysis](https://www.elastic.co/security-labs/blister-loader) + +### Docker + +We can easily run the extractor with Docker, first we need to build the image: + +``` +docker build . -t blister-config-extractor +``` + +Then we run the container with the **-v** flag to map a host directory to the docker container directory: + +``` +docker run -ti --rm -v \ +"$(pwd)/binaries":/binaries blister-config-extractor:latest -d /binaries/ + +``` + +We can either specify a single sample with **-f** option or a directory of samples with **-d**. + +![BLISTER configuration extrator output](/assets/images/blister-configuration-extractor/blister-configuration-extractor-image41.jpg) + +### Running it Locally + +As mentioned above, Docker is the recommended approach to running this project, however you can also run this locally. This project uses [Poetry](https://python-poetry.org/) to manage dependencies, testing, and metadata. If you have Poetry installed already, from this directory, you can simply run the following commands to run the tool. This will setup a virtual environment, install the dependencies, activate the virtual environment, and run the console script. + +``` +poetry lock +poetry install +poetry shell +blister-config-extractor -h + +``` + +Once that works, you can do the same sort of things as mentioned in the Docker instructions above. + +## References + +- Customised Rabbit cipher implementation based on [Rabbit-Cipher](https://github.com/Robin-Pwner/Rabbit-Cipher/) diff --git a/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/blister_loader.mdx b/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/blister_loader.mdx new file mode 100644 index 0000000000000..0177776226a23 --- /dev/null +++ b/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/blister_loader.mdx @@ -0,0 +1,471 @@ +--- +title: "BLISTER Loader" +slug: "blister-loader" +date: "2023-04-13" +description: "The BLISTER loader continues to be actively used to load a variety of malware." +author: + - slug: cyril-francois + - slug: daniel-stepanic + - slug: salim-bitam +image: "blog-thumb-power-lines.jpg" +category: + - slug: malware-analysis +tags: + - blister + - malware +--- + +## Key Takeaways + +- BLISTER is a loader that continues to stay under the radar, actively being used to load a variety of malware including clipbankers, information stealers, trojans, ransomware, and shellcode +- In-depth analysis shows heavy reliance of Windows Native API’s, several injection capabilities, multiple techniques to evade detection, and counter static/dynamic analysis +- Elastic Security is providing a configuration extractor that can be used to identify key elements of the malware and dump the embedded payload for further analysis +- 40 days after the initial reporting on the BLISTER loader by Elastic Security, we observed a change in the binary to include additional architectures. This shows that this is an actively developed tool and the authors are watching defensive countermeasures + +> For information on the BLISTER malware loader and campaign observations, check out our blog post and configuration extractor detailing this: +> +> - [BLISTER Campaign Analysis](https://www.elastic.co/security-labs/elastic-security-uncovers-blister-malware-campaign) +> - [BLISTER Configuration Extractor](https://www.elastic.co/security-labs/blister-configuration-extractor) + +## Overview + +The Elastic Security team has continually been monitoring the BLISTER loader since our initial [release](https://www.elastic.co/blog/elastic-security-uncovers-blister-malware-campaign) at the end of last year. This family continues to remain largely unnoticed, with low detection rates on new samples. + +![Example of BLISTER loader detection rates](/assets/images/blister-loader/blister-loader-image37.jpg) + +A distinguishing characteristic of BLISTER’s author is their method of tampering with legitimate DLLs to bypass static analysis. During the past year, Elastic Security has observed the following legitimate DLL’s patched by BLISTER malware: + +| Filename | Description | +| -------------- | ------------------------------------------------------------------ | +| dxgi.dll | DirectX Graphics Infrastructure | +| WIAAut.DLL | WIA Automation Layer | +| PowerCPL.DLL | Power Options Control Panel | +| WIMGAPI.DLL | Windows Imaging Library | +| rdpencom.dll | RDPSRAPI COM Objects | +| colorui.dll | Microsoft Color Control Panel. | +| termmgr.dll | Microsoft TAPI3 Terminal Manager | +| libcef.dll | Chromium Embedded Framework (CEF) Dynamic Link Library | +| CEWMDM.DLL | Windows CE WMDM Service Provider | +| intl.dll | LGPLed libintl for Windows NT/2000/XP/Vista/7 and Windows 95/98/ME | +| vidreszr.dll | Windows Media Resizer | +| sppcommdlg.dll | Software Licensing UI API | + +Due to the way malicious code is embedded in an otherwise benign application, BLISTER may be challenging for technologies that rely on some forms of machine learning. Combined with code-signing defense evasion, BLISTER appears designed with security technologies in mind. + +Our research shows that BLISTER is actively developed and has been [linked](https://www.trendmicro.com/en_us/research/22/d/Thwarting-Loaders-From-SocGholish-to-BLISTERs-LockBit-Payload.html?utm_source=trendmicroresearch&utm_medium=smk&utm_campaign=0422_Socgholish) in public reporting to [LockBit](https://malpedia.caad.fkie.fraunhofer.de/details/win.lockbit) ransomware and the [SocGholish](https://redcanary.com/threat-detection-report/threats/socgholish/) framework; in addition, Elastic has also observed BLISTER in relation to the following families: [Amadey](https://malpedia.caad.fkie.fraunhofer.de/details/win.amadey), [BitRAT](https://malpedia.caad.fkie.fraunhofer.de/details/win.bit_rat), [Clipbanker](https://malpedia.caad.fkie.fraunhofer.de/details/win.clipbanker), [Cobalt Strike](https://malpedia.caad.fkie.fraunhofer.de/details/win.cobalt_strike), [Remcos](https://malpedia.caad.fkie.fraunhofer.de/details/win.remcos), and [Raccoon](https://malpedia.caad.fkie.fraunhofer.de/details/win.raccoon) along with others. + +In this post, we will explain how BLISTER continues to operate clandestinely, highlight the loader’s core capabilities (injection options, obfuscation, and anti-analysis tricks) as well as provide a configuration extractor that can be used to dump BLISTER embedded payloads. + +Consider the following [sample](https://www.virustotal.com/gui/file/afb77617a4ca637614c429440c78da438e190dd1ca24dc78483aa731d80832c2) representative of BLISTER for purposes of this analysis. This sample was also used to develop the initial BLISTER family YARA signature, the configuration extraction script, and evaluate tools against against unknown x32 and x64 BLISTER samples. + +## Execution Flow + +The execution flow consists of the following phases: + +- Deciphering the second stage +- Retrieving configuration and packed payload +- Payload unpacking +- Persistence mechanisms +- Payload injection + +### Launch / Entry Point + +During the first stage of the execution flow, BLISTER is embedded in a legitimate version of the [colorui.dll](https://www.virustotal.com/gui/file/1068e40851b243a420cb203993a020d0ba198e1ec6c4d95f0953f81e13046973/details) library. The threat actor, with a previously achieved foothold, uses the Windows built-in rundll32.exe utility to load BLISTER by calling the export function **LaunchColorCpl** : + +``` +Rundll32 execution arguments + +rundll32.exe "BLISTER.dll,LaunchColorCpl" +``` + +The image below demonstrates how BLISTER’s DLL is modified, noting that the export start is patched with a function call (line 17) to the malware entrypoint. + +![Export of Patched BLISTER DLL](/assets/images/blister-loader/blister-loader-image13.jpg) + +If we compare one of these malicious loaders to the original DLL they masquerade as, we can see where the patch was made, the function no longer exists: + +![Export of Original DLL Used by BLISTER](/assets/images/blister-loader/blister-loader-image11.jpg) + +### Deciphering Second Stage + +BLISTER’s second stage is ciphered in its [resource section](https://docs.microsoft.com/en-us/windows/win32/debug/pe-format#the-rsrc-section) (.rsrc). + +The deciphering routine begins with a loop based sleep to evade detection: + +![Initial Sleep Mechanism](/assets/images/blister-loader/blister-loader-image35.jpg) + +BLISTER then enumerates and hashes each export of ntdll, comparing export names against loaded module names; searching specifically for the **NtProtectVirtualMemory** API: + +![API Hash](/assets/images/blister-loader/blister-loader-image40.jpg) + +Finally, it looks for a memory region of 100,832 bytes by searching for a specific memory pattern, beginning its search at the return address and leading us in the .rsrc section. When found, BLISTER performs an eXclusive OR (XOR) operation on the memory region with a four-byte key, sets it’s page protection to PAGE_EXECUTE_READ with a call to NtProtectVirtualMemory, and call its second stage entry point with the deciphering key as parameter: + +![Memory Tag & Memory Region Setup](/assets/images/blister-loader/blister-loader-image49.jpg) + +### Obfuscation + +BLISTER’s second-stage involves obfuscating functions, scrambling their control flow by splitting their basic blocks with unconditional jumps and randomizing basic blocks’ locations. An example of which appears below. + +![Function’s Control Flow Scrambling](/assets/images/blister-loader/blister-loader-image6.jpg) + +BLISTER inserts junk code into basic blocks as yet another form of defense evasion, as seen below. + +![Junk Code Insertion](/assets/images/blister-loader/blister-loader-image30.jpg) + +### Retrieving Configuration and Packed Payload + +BLISTER uses the previous stage’s four-byte key to locate and decipher its configuration. + +The routine begins by searching its memory, beginning at return address, for its four-byte key XORed with a hardcoded value as memory pattern: + +![Memory pattern search loop](/assets/images/blister-loader/blister-loader-image24.jpg) + +When located, the 0x644 byte configuration is copied and XOR-decrypted with the same four-byte key: + +![Config decryption](/assets/images/blister-loader/blister-loader-image45.jpg) + +Finally, it returns a pointer to the beginning of the packed PE, which is after the 0x644 byte blob: + +![Pointer return to packed PE](/assets/images/blister-loader/blister-loader-image58.jpg) + +See the [configuration structure](https://www.elastic.co/security-labs/blister-loader#configuration-structure) in the appendix. + +### Time Based Anti Debug + +After loading the configuration, and depending if the **kEnableSleepBasedAntiDebug** flag (0x800) is set, BLISTER calls its time-based anti-debug function: + +![Check configuration for Sleep function](/assets/images/blister-loader/blister-loader-image60.jpg) + +This function starts by creating a thread with the Sleep Windows function as a starting address and 10 minutes as the argument: + +![Sleep function (600000 ms / 10 minutes)](/assets/images/blister-loader/blister-loader-image26.jpg) + +The main thread will sleep using **NtDelayExecution** until the sleep thread has exited: + +![NtDelayExecution used with Sleep function](/assets/images/blister-loader/blister-loader-image8.jpg) + +Finally the function returns 0 when the sleep thread has run at least for 9 1/2 minutes: + +![Condition to end sleep thread](/assets/images/blister-loader/blister-loader-image57.jpg) + +If not, the function will return 1 and the process will be terminated: + +![Process termination on sleep function if error](/assets/images/blister-loader/blister-loader-image16.jpg) + +### Windows API + +#### Blister’s GetModuleHandle + +BLISTER implements its own **GetModuleHandle** to evade detection, the function takes the library name hash as a parameter, iterates over the process [PEB LDR](https://docs.microsoft.com/en-us/windows/win32/api/winternl/ns-winternl-peb_ldr_data)’s modules and checks the hashed module’s name against the one passed in the parameter: + +![Function used to verify module names](/assets/images/blister-loader/blister-loader-image18.jpg) + +#### Blister’s GetProcAddress + +BLISTER’s **GetProcAddress** takes the target DLL and the export hash as a parameter, it also takes a flag that tells the function that the library is 64 bits. + +The DLL can be loaded or mapped then the function iterates over the DLL’s export function names and compares their hashes with the ones passed in the parameter: + +![BLISTER’s GetProcAddress hash checking dll’s exports](/assets/images/blister-loader/blister-loader-image3.jpg) + +If the export is found, and its virtual address isn’t null, it is returned: + +![Return export virtual address](/assets/images/blister-loader/blister-loader-image48.jpg) + +Else the DLL is **LdrLoaded** and BLISTER’s **GetProcAddress** is called again with the newly loaded dll: + +![LdrLoad the DLL and call GetProcAddress again](/assets/images/blister-loader/blister-loader-image19.jpg) + +#### Library Manual Mapping + +BLISTER manually maps a library using **NtCreateFile** in order to open a handle on the DLL file: + +![NtCreateFile used within mapping function](/assets/images/blister-loader/blister-loader-image56.jpg) + +Next it creates a section with the handle by calling **NtCreateSection** with the **SEC_IMAGE** attribute which tells Windows to loads the binary as a PE: + +![NtCreateSection used within mapping function](/assets/images/blister-loader/blister-loader-image31.jpg) + +_NtCreateSection used within mapping function_ + +Finally it maps the section with **NtMapViewOfSection** : + +![NtMapViewofSection used within mapping function](/assets/images/blister-loader/blister-loader-image36.jpg) + +#### x32/x64 Ntdll Mapping + +Following the call to its anti-debug function, BLISTER manually maps 32 bit and 64 bit versions of NTDLL. + +It starts by mapping the x32 version: + +![32 bit NTDLL mapping](/assets/images/blister-loader/blister-loader-image43.jpg) + +Then it disables [SysWOW64 redirection](https://docs.microsoft.com/en-us/windows/win32/winprog64/file-system-redirector): + +![SysWOW64 disabled](/assets/images/blister-loader/blister-loader-image17.jpg) + +And then maps the 64 bit version: + +![64 bit NTDLL mapping](/assets/images/blister-loader/blister-loader-image50.jpg) + +Then if available, the mapped libraries will be used with the **GetProcAddress** function, i.e: + +![Mapped libraries using GetProcAddress](/assets/images/blister-loader/blister-loader-image7.jpg) + +#### LdrLoading Windows Libraries and Removing Hooks + +After mapping 32 and 64 bit **NTDLL** versions BLISTER will **LdrLoad** several Windows libraries and remove potential hooks: + +![Function used to load Windows libraries and remove hooks](/assets/images/blister-loader/blister-loader-image5.jpg) + +First, it tries to convert the hash to the library name by comparing the hash against a fixed list of known hashes: + +![Hash comparison](/assets/images/blister-loader/blister-loader-image22.jpg) + +If the hash is found BLISTER uses the **LdrLoad** to load the library: + +![Leveraging LdrLoad to load DLL](/assets/images/blister-loader/blister-loader-image53.jpg) + +Then BLISTER searches for the corresponding module in its own process: + +![Searching for module in own process](/assets/images/blister-loader/blister-loader-image15.jpg) + +And maps a fresh copy of the library with the module’s **FullDllName** : + +![Retrieving Module’s FullDllName](/assets/images/blister-loader/blister-loader-image10.jpg) + +![Manual Mapping function](/assets/images/blister-loader/blister-loader-image55.jpg) + +BLISTER then applies the relocation to the mapped library with the loaded one as the base address for the relocation calculation: + +![Performing relocation](/assets/images/blister-loader/blister-loader-image59.jpg) + +Next BLISTER iterates over each section of the loaded library to see if the section is executable: + +![Checking executable sections](/assets/images/blister-loader/blister-loader-image42.jpg) + +If the section is executable, it is replaced with the mapped one, thus removing any hooks: + +![Section replacement](/assets/images/blister-loader/blister-loader-image47.jpg) + +#### x64 API Call + +BLISTER can call 64-bit library functions through the use of special 64-bit function wrapper: + +![BLISTER utilizing 64-bit function library caller](/assets/images/blister-loader/blister-loader-image29.jpg) + +![64-bit function library caller](/assets/images/blister-loader/blister-loader-image54.jpg) + +To make this call BLISTER switches between 32-bit to 64-bit code using the old Heaven’s Gate [technique](https://blog.talosintelligence.com/2019/07/rats-and-stealers-rush-through-heavens.html): + +![Observed Heaven’s Gate byte sequences](/assets/images/blister-loader/blister-loader-image51.jpg) + +![Heaven’s Gate - Transition to 64 bit mode](/assets/images/blister-loader/blister-loader-image20.jpg) + +![Heaven’s Gate - Transition to 32 bit mode](/assets/images/blister-loader/blister-loader-image21.jpg) + +## Unpacking Payload + +During the unpacking process of the payload, the malware starts by allocating memory using **NtAllocateVirtualMemory** and passing in configuration information. A memcpy function is used to store a copy of encrypted/compressed payload in a buffer for next stage (decryption). + +![Unpacking BLISTER payload](/assets/images/blister-loader/blister-loader-image2.jpg) + +### Deciphering + +BLISTER leverages the Rabbit stream [cipher](), passing in the previously allocated buffer containing the encrypted payload, the compressed data size along with the 16-byte deciphering key and 8-byte IV. + +![Decipher function using the Rabbit cipher](/assets/images/blister-loader/blister-loader-image1.jpg) + +![Observed Rabbit Cipher Key and IV inside memory](/assets/images/blister-loader/blister-loader-image23.jpg) + +### Decompression + +After the decryption stage, the payload is then decompressed using **RtlDecompressBuffer** with the LZNT1 compression format. + +![Decompression function using LZNT1](/assets/images/blister-loader/blister-loader-image9.jpg) + +## Persistence Mechanism + +To achieve persistence, BLISTER leverages Windows shortcuts by creating an LNK file inside the Windows startup folder. It creates a new directory using the **CreateDirectoryW** function with a unique hardcoded string found in the configuration file such as: C:\ProgramData`UNIQUE STRING\\>` + +BLISTER then copies C:\System32\rundll32.exe and itself to the newly created directory and renames the files to UNIQUE STRING\\>.exe and UNIQUE STRING\\>.dll, respectively. + +BLISTER uses the **CopyModuleIntoFolder** function and the **IFileOperation** Windows **COM** interface for [bypassing UAC](https://www.elastic.co/security-labs/exploring-windows-uac-bypasses-techniques-and-detection-strategies) when copying and renaming the files: + +![BLISTER function used to copy files](/assets/images/blister-loader/blister-loader-image46.jpg) + +The malware creates an LNK file using **IShellLinkW COM** interface and stores it in `C:\Users\\AppData\Roaming\Microsft\Windows\Start Menu\Startup as UNIQUE STRING\\>.lnk` + +![Mapping shortcut to BLISTER with arguments](/assets/images/blister-loader/blister-loader-image25.jpg) + +The LNK file is set to run the export function **LaunchColorCpl** of the newly copied malware with the renamed instance of rundll32. C:\ProgramData\UNIQUE STRING\\>\UNIQUE STRING\\>.exe C:\ProgramData\UNIQUE STRING\\>\UNIQUE STRING\\>.dll,LaunchColorCpl + +## Injecting Payload + +BLISTER implements 3 different injection techniques to execute the payload according to the configuration flag: + +![BLISTER injection techniques by config flag](/assets/images/blister-loader/blister-loader-image27.jpg) + +### Shellcode Execution + +After decrypting the shellcode, BLISTER is able to inject it to a newly allocated read write memory region with **NtAllocateVirtualMemory** API, it then copies the shellcode to it and it sets the memory region to read write execute with **NtProtectVirtualMemory** and then executes it. + +![Execute shellcode function](/assets/images/blister-loader/blister-loader-image28.jpg) + +### Own Process Injection + +BLISTER can execute DLL or Executable payloads reflectively in its memory space. It first creates a section with **NtCreateSection** API. + +![RunPE function](/assets/images/blister-loader/blister-loader-image39.jpg) + +BLISTER then tries to map a view on the created section at the payload’s preferred base address. In case the preferred address is not available and the payload is an executable it will simply map a view on the created section at a random address and then do relocation. + +![Check for conflicting addresses](/assets/images/blister-loader/blister-loader-image34.jpg) + +Conversly, if the payload is a DLL, it will first unmap the memory region of the current process image and then it will map a view on the created section with the payload’s preferred address. + +![DLL unmapping](/assets/images/blister-loader/blister-loader-image33.jpg) + +BLISTER then calls a function to copy the PE headers and the sections. + +![Copying over PE/sections](/assets/images/blister-loader/blister-loader-image12.jpg) + +Finally, BLISTER executes the loaded payload in memory starting from its entry point if the payload is an executable. In case the payload is a DLL, it will find its export function according to the hash in the config file and execute it. + +### Process Hollowing + +BLISTER is able to perform [process hollowing](https://attack.mitre.org/techniques/T1055/012/) in a remote process: + +First, there is an initial check for a specific module hash value (0x12453653), if met, BLISTER performs process hollowing against the Internet Explorer executable. + +![Internet Explorer option for process hollowing](/assets/images/blister-loader/blister-loader-image32.jpg) + +If not, the malware performs remote process hollowing with **Werfault.exe**. BLISTER follows standard techniques used for process hollowing. + +![Process hollowing function](/assets/images/blister-loader/blister-loader-image44.jpg) + +There is one path within this function: if certain criteria are met matching Windows OS versions and build numbers the hollowing technique is performed by dropping a temporary file on disk within the **AppData** folder titled **Bg.Agent.ETW** with an explicit extension. + +![Compatibility Condition check](/assets/images/blister-loader/blister-loader-image52.jpg) + +![Compatibility Condition function](/assets/images/blister-loader/blister-loader-image14.jpg) + +![Temporary file used to store payload](/assets/images/blister-loader/blister-loader-image4.jpg) + +The malware uses this file to read and write malicious DLL to this file. Werfault.exe is started by BLISTER and then the contents of this temporary DLL are loaded into memory into the Werfault process and the file is shortly deleted after. + +![Procmon output of compatibility function](/assets/images/blister-loader/blister-loader-image38.jpg) + +## Configuration Extractor + +Automating the configuration and payload extraction from BLISTER is a key aspect when it comes to threat hunting as it gives visibility of the campaign and the malware deployed by the threat actors which enable us to discover new unknown samples and Cobalt Strike instances in a timely manner. + +Our extractor uses a [Rabbit stream cipher implementation](https://github.com/Robin-Pwner/Rabbit-Cipher) and takes either a directory of samples with **-d** option or **-f** for a single sample, + +![Config extractor output](/assets/images/blister-loader/blister-loader-image41.jpg) + +To enable the community to further defend themselves against existing and new variants of the BLISTER loader, we are making the configuration extractor open source under the Apache 2 License. The configuration extractor documentation and binary download can be accessed [here](https://www.elastic.co/security-labs/blister-configuration-extractor). + +## Conclusion + +BLISTER continues to be a formidable threat, punching above its own weight class, distributing popular malware families and implants leading to major compromises. Elastic Security has been tracking BLISTER for months and we see no signs of this family slowing down. + +From reversing BLISTER, our team was able to identify key functionality such as different injection methods, multiple techniques for defense evasion using anti-debug/anti-analysis features and heavy reliance on Windows Native API’s. We also are releasing a configuration extractor that can statically retrieve actionable information from BLISTER samples as well as dump out the embedded payloads. + +## Appendix + +### Configuration Structure + +``` +BLISTER configuration structure + +struct Config { + uint16_t flag; + uint32_t payload_export_hash; + wchar_t w_payload_filename_and_cmdline[783]; + size_t compressed_data_size; + size_t uncompressed_data_size; + uint8_t pe_deciphering_key[16]; + uint8_t pe_deciphering_iv[8]; +}; + +``` + +### Configuration’s Flags + +``` +BLISTER configuration files + +enum Config::Flags { + kDoPersistance = 0x1, + kOwnProcessReflectiveInjectionMethod = 0x2, + kOwnProcessHollowingMethod = 0x8, + kRemoteProcessHollowingMethod = 0x10, + kExecutePayloadExport = 0x20, + kExecuteShellcodeMethod = 0x40, + kInjectWithCmdLine = 0x80, + kSleepAfterInjection = 0x100, + kEnableSleepBasedAntiDebug = 0x800, +}; +``` + +### Hashing Algorithm + +``` +BLISTER hashing algorithm + +uint32_t HashLibraryName(wchar_t *name) { + uint32_t name {0}; + while (*name) { + hash = ((hash >> 23) | (hash << 9)) + *name++; + } + return hash ; +} +``` + +### Indicators + +| Indicator | Type | Note | +| ---------------------------------------------------------------- | ------ | ----------- | +| afb77617a4ca637614c429440c78da438e190dd1ca24dc78483aa731d80832c2 | SHA256 | BLISTER DLL | + +## YARA Rule + +This updated YARA rule has shown a 13% improvement in detection rates. + +``` +BLISTER YARA rule + +rule Windows_Trojan_BLISTER { + meta: + Author = "Elastic Security" + creation_date = "2022-04-29" + last_modified = "2022-04-29" + os = "Windows" + arch = "x86" + category_type = "Trojan" + family = "BLISTER" + threat_name = "Windows.Trojan.BLISTER" + description = "Detects BLISTER loader." + reference_sample = "afb77617a4ca637614c429440c78da438e190dd1ca24dc78483aa731d80832c2" + + strings: + $a1 = { 8D 45 DC 89 5D EC 50 6A 04 8D 45 F0 50 8D 45 EC 50 6A FF FF D7 } + $a2 = { 75 F7 39 4D FC 0F 85 F3 00 00 00 64 A1 30 00 00 00 53 57 89 75 } + $a3 = { 78 03 C3 8B 48 20 8B 50 1C 03 CB 8B 78 24 03 D3 8B 40 18 03 FB 89 4D F8 89 55 E0 89 45 E4 85 C0 74 3E 8B 09 8B D6 03 CB 8A 01 84 C0 74 17 C1 C2 09 0F BE C0 03 D0 41 8A 01 84 C0 75 F1 81 FA B2 17 EB 41 74 27 8B 4D F8 83 C7 02 8B 45 F4 83 C1 04 40 89 4D F8 89 45 F4 0F B7 C0 3B 45 E4 72 C2 8B FE 8B 45 04 B9 } + $b1 = { 65 48 8B 04 25 60 00 00 00 44 0F B7 DB 48 8B 48 ?? 48 8B 41 ?? C7 45 48 ?? ?? ?? ?? 4C 8B 40 ?? 49 63 40 ?? } + $b2 = { B9 FF FF FF 7F 89 5D 40 8B C1 44 8D 63 ?? F0 44 01 65 40 49 2B C4 75 ?? 39 4D 40 0F 85 ?? ?? ?? ?? 65 48 8B 04 25 60 00 00 00 44 0F B7 DB } + condition: + any of them +} +``` + +## References + +- [https://www.elastic.co/blog/elastic-security-uncovers-blister-malware-campaign](https://www.elastic.co/blog/elastic-security-uncovers-blister-malware-campaign) +- [https://www.trendmicro.com/en_us/research/22/d/Thwarting-Loaders-From-SocGholish-to-BLISTERs-LockBit-Payload.html](https://www.trendmicro.com/en_us/research/22/d/Thwarting-Loaders-From-SocGholish-to-BLISTERs-LockBit-Payload.html?utm_source=trendmicroresearch&utm_medium=smk&utm_campaign=0422_Socgholish) +- [https://redcanary.com/threat-detection-report/threats/socgholish/](https://redcanary.com/threat-detection-report/threats/socgholish/) + +## Artifacts + +Artifacts are also available for [download](https://assets.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blte5a55b99e66b4794/628e88d91cd65960bcff2862/blister-indicators.zip) in both ECS and STIX format in a combined zip bundle. diff --git a/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/bpfdoor_configuration_extractor.mdx b/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/bpfdoor_configuration_extractor.mdx new file mode 100644 index 0000000000000..c548827c211f6 --- /dev/null +++ b/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/bpfdoor_configuration_extractor.mdx @@ -0,0 +1,96 @@ +--- +title: "BPFDoor Configuration Extractor" +slug: "bpfdoor-configuration-extractor" +date: "2022-12-06" +description: "Configuration extractor to dump out hardcoded passwords with BPFDoor." +author: + - slug: elastic-security-labs +image: "tools-image.jpg" +category: + - slug: tools +tags: + - bpfdoor +--- + +Configuration extractor to dump out hardcoded passwords with BPFDoor. + +[Download bpfdoor-config-extractor.tar.gz](https://assets.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt3f57100ade3473c5/62882ccdb4fa6b61ed70ba87/bpfdoor-config-extractor.tar.gz) + +## Overview + +This tool provides a Python module and command line tool that will extract passwords from BPFDoor samples. + +> The Elastic Security Team has released an indepth analysis of the BPFDoor malware and created an additional tool that will scan for BPFDoor infected hosts. +> +> - [BPFDoor analysis](https://bookish-bassoon-c37be003.pages.github.io/intelligence/2022/05/04.bpfdoor/article/) +> - [BPFDoor scanner](https://www.elastic.co/security-labs/bpfdoor-scanner) + +## Getting Started + +### Docker + +We can easily run the extractor with Docker, first we need to build the image. + +``` +Building the BPFDoor Docker image + +docker build . -t bpfdoor-extractor +``` + +Then we run the container with the **-v** flag to map a host directory to the Docker container directory that contains the BPFDoor samples. + +``` +Running the BPFDoor Docker container + +docker run -ti --rm -v $(pwd)/binaries:/binaries \ + bpfdoor-extractor:latest -d /binaries/ +``` + +We can either specify a single sample with **-f** option or a directory of samples with **-d** + +``` +BPFDoor Configuration Extractor help output + +docker run -ti --rm bpfdoor-extractor:latest -h + +Author: Elastic Security (MARE) + +______ ______ ______ ______ +| ___ \| ___ \| ___|| _ \ +| |_/ /| |_/ /| |_ | | | | ___ ___ _ __ +| ___ \| __/ | _| | | | |/ _ \ / _ \ | '__| +| |_/ /| | | | | |/ /| (_) || (_) || | +\____/ \_| \_| |___/ \___/ \___/ |_| + _____ __ _ _____ _ _ +/ __ \ / _|(_) | ___| | | | | +| / \/ ___ _ __ | |_ _ __ _ | |__ __ __| |_ _ __ __ _ ___ | |_ ___ _ __ +| | / _ \ | '_ \ | _|| | / _` | | __|\ \/ /| __|| '__|/ _` | / __|| __|/ _ \ | '__| +| \__/\| (_) || | | || | | || (_| | | |___ > < | |_ | | | (_| || (__ | |_| (_) || | + \____/ \___/ |_| |_||_| |_| \__, | \____//_/\_\ \__||_| \__,_| \___| \__|\___/ |_| + __/ | + |___/ + + +usage: bpfdoor-extractor [-h] (-f FILENAME | -d DIRNAME) + +options: + -h, --help show this help message and exit + -f FILENAME, --file FILENAME + File + -d DIRNAME, --dir DIRNAME + Directory + +``` + +### Running it Locally + +As mentioned above, Docker is the recommended approach to running this project, however you can also run this locally. This project uses [Poetry](https://python-poetry.org/) to manage dependencies, testing, and metadata. If you have Poetry installed already, from this directory, you can simply run the following commands to run the tool. This will setup a virtual environment, install the dependencies, activate the virtual environment, and run the console script. + +``` +poetry lock +poetry install +poetry shell +bpfdoor-extractor --help +``` + +Once that works, you can do the same sort of things as mentioned in the Docker instructions above. diff --git a/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/bpfdoor_scanner.mdx b/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/bpfdoor_scanner.mdx new file mode 100644 index 0000000000000..529435d350f82 --- /dev/null +++ b/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/bpfdoor_scanner.mdx @@ -0,0 +1,105 @@ +--- +title: "BPFDoor Scanner" +slug: "bpfdoor-scanner" +date: "2022-12-06" +description: "Python script to identify hosts infected with the BPFDoor malware." +author: + - slug: elastic-security-labs +image: "tools-image.jpg" +category: + - slug: tools +tags: + - bpfdoor +--- + +Python script to identify hosts infected with the BPFDoor malware. + +[Download bpfdoor-scanner.tar.gz](https://assets.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltae9bafece9048014/62882b50dcc93261eccb04e2/bpfdoor-scanner.tar.gz) + +## Getting Started + +This tool provides a Python script to identify hosts that are infected with the BPFDoor malware. + +> The Elastic Security Team has released an indepth analysis of the BPFDoor malware and created an additional tool that will extract configurations from BPFDoor malware samples. +> +> - [BPFDoor analysis](https://bookish-bassoon-c37be003.pages.github.io/intelligence/2022/05/04.bpfdoor/article/) +> - [BPFDoor configuration extractor](https://www.elastic.co/security-labs/bpfdoor-configuration-extractor) + +### Permissions + +On Linux (and thus in a container), the tool requires the following permissions: + +- CAP_NET_BIND_SERVICE +- CAP_NET_RAW + +On any \*NIX host, running the script with sudo will get you what you need. As long as you don’t strip the privileges listed for your container and you publish the UDP port you intend to receive on, you should be set. + +### Docker + +We can easily run the scanner with Docker, first we need to build the image: + +``` +Building the BPFDoor scanner Docker image + +docker build . -t bpfdoor-scanner +``` + +## Usage + +Once you’be built the Docker iamge, we can run the container to get a list of the options. + +``` +Runing the BPFDoor container + +docker run -ti --rm bpfdoor-scanner:latest --help + +Usage: bpfdoor-scanner [OPTIONS] + + Sends a discovery packet to suspected BPFDoor endpoints. + + Example usage: + + sudo ./bpfdoor-scanner --target-ip 1.2.3.4 + + Sends a packet to IP 1.2.3.4 using the default target port 68/UDP (tool + listens on all ports) using the default interface on this host and listens + on port 53/UDP to masquerade as traffic. + + NOTE: Elevated privileges are required for source ports < 1024. + +Options: + --target-ip TEXT [required] + --target-port INTEGER [default: 68] + --source-ip TEXT IP for target to respond to and attempt to bind + locally [default: 172.17.0.3] + --source-port INTEGER Local port to listen on for response [default: 53] + --timeout INTEGER Number of seconds to wait for response [default: 5] + -v, --verbose Show verbose output + -d, --debug Show debug output + --version + --help Show this message and exit. +``` + +The minimum required option is just --target-ip. The rest have defaults. For running in a container, you’ll want to publish the return port (defaults to 53) and specify --source-ip of the host interface you wish to use. In the following example, the IP 192.168.100.10 is the interface on my host that will receive the packet. + +``` +Example running the BPFDoor scanner + +docker run -ti --publish 53:53/udp --rm bpfdoor-scanner:latest \ + --target-ip 192.168.32.18 --source-ip 192.168.100.10 +``` + +## Running Locally + +As mentioned above, Docker is the recommended approach to running this project, however you can also run this locally. This project uses [Poetry](https://python-poetry.org/) to manage dependencies, testing, and metadata. If you have Poetry installed already, from this directory, you can simply run the following commands to run the tool. This will setup a virtual environment, install the dependencies, activate the virtual environment, and run the console script. + +``` +Running BPFDoor scanner locally + +poetry lock +poetry install +poetry shell +sudo bpfdoor-scanner --help +``` + +Once that works, you can do the same sort of things as mentioned in the Docker instructions above. diff --git a/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/bughatch_malware_analysis.mdx b/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/bughatch_malware_analysis.mdx new file mode 100644 index 0000000000000..94ccb7e375c5b --- /dev/null +++ b/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/bughatch_malware_analysis.mdx @@ -0,0 +1,528 @@ +--- +title: "BUGHATCH Malware Analysis" +slug: "bughatch-malware-analysis" +date: "2022-09-09" +subtitle: "Malware analysis of the BUGHATCH downloader." +description: "Elastic Security has performed a deep technical analysis of the BUGHATCH malware. This includes capabilities as well as defensive countermeasures." +author: + - slug: salim-bitam +image: "libraries-edev-ops-1680x980.jpg" +category: + - slug: malware-analysis +tags: + - bughatch + - cuba + - ref9019 +--- + +## Key takeaways + +- Elastic Security Labs is releasing a BUGHATCH malware analysis report from a recent [campaign](https://www.elastic.co/security-labs/cuba-ransomware-campaign-analysis) +- This report covers detailed code analysis, network communication protocols, command handling, and observed TTPs +- From this research we produced a [YARA rule](https://github.com/elastic/protections-artifacts/blob/main/yara/rules/Windows_Trojan_Bughatch.yar) to detect the BUGHATCH downloader + +## Preamble + +BUGHATCH is an implant of a custom C2 deployed during the CUBA ransomware campaigns we observed in February of 2022, this tool was most likely built by the threat actor themselves as it was not used previously. + +BUGHATCH is capable of downloading and executing commands and arbitrary code, it gives the operator the freedom to execute payloads with different techniques like reflection, shellcode execution, system command execution, and so on. The samples we have seen were not obfuscated and were deployed using a custom obfuscated in-memory dropper written in PowerShell and referred to as [TERMITE by Mandiant](https://www.mandiant.com/resources/unc2596-cuba-ransomware). + +In this document, we will go through the execution flow of BUGHATCH highlighting its functionalities and code execution techniques, a YARA rule and the MITRE ATT&CK mapping can be found in the appendix. + +In this analysis we will describe the following: + +- Token adjustment +- Information collection +- Threading and thread synchronization +- Network communication protocol +- Command handling + +> For information on the CUBA ransomware campaign and associated malware analysis, check out our blog posts detailing this: +> +> - [CUBA Ransomware Campaign](https://www.elastic.co/security-labs/cuba-ransomware-campaign-analysis) +> - [CUBA Malware Analysis](https://www.elastic.co/security-labs/cuba-ransomware-malware-analysis) + +## Static analysis + +| | | +| ------------ | ---------------------------------------------------------------- | --- | +| SHA256 | F1325F8A55164E904A4B183186F44F815693A008A9445D2606215A232658C3CF | +| File Size | 35840 bytes | +| File Type: | Win32 executable | +| Signed? | No | +| Packer? | No | +| Compiler | Visual Studio 2017 - 15.5.0 preview 2 | +| Compile Time | Sun Feb 06 21:05:18 2022 | UTC | +| Entropy | 6.109 | + +### Sections + +| | | | | | | +| ------ | -------------- | ------------ | -------- | ------- | -------------------------------- | +| Name | VirtualAddress | Virtual Size | Raw Size | Entropy | MD5 | +| .text | 0x1000 | 0x6000 | 0x5400 | 5.933 | A6E30CCF838569781703C943F18DC3F5 | +| .rdata | 0x7000 | 0x3000 | 0x2A00 | 6.217 | 9D9AD1251943ECACE81644A7AC320B3C | +| .data | 0xA000 | 0x1000 | 0x400 | 1.163 | B983B8EB258220628BE2A88CA44286B4 | +| .reloc | 0xB000 | 0x424 | 0x600 | 5.235 | 39324A58D79FC5B8910CBD9AFBF1A6CB | + +## Code analysis + +BUGHATCH is an in-memory implant loaded by an obfuscated PowerShell script that decodes and executes an embedded shellcode blob in its allocated memory space using common Windows APIs ( **VirtualAlloc** , **CreateThread, WaitForSingleObject** ). + +The PowerShell loader uses inline C# to load APIs needed for shellcode injection as seen in the following pseudocode. + +![Pseudocode PowerShell inline C#](/assets/images/bughatch-malware-analysis/image12.jpg) + +The PowerShell script is obfuscated with random functions and variable names and contains the shellcode in a reverse-Base64 format. + +![Pseudocode embedded shellcode in Base64 format](/assets/images/bughatch-malware-analysis/image10.png) + +The script first decodes the reverse-Base64 encoded data, then allocates a memory region with **VirtualAlloc** before copying the shellcode into it. Finally, the script executes the shellcode by creating a new thread with the **CreateThread** API. + +![Pseudocode PowerShell creates a new thread to execute the shellcode](/assets/images/bughatch-malware-analysis/image38.jpg) + +The shellcode downloads another shellcode blob and the encrypted PE implant from the C2 server, this second shellcode decrypts and reflectively loads the PE malware. + +This section dives deeper into the BUGHATCH execution flow, threading and encryption implementation, communication protocol with C2, and finally supported commands and payload execution techniques implemented. + +The following is a diagram summarizing the execution flow of the implant: + +![Execution flow diagram of BUGHATCH](/assets/images/bughatch-malware-analysis/image16.png) + +![Pseudocode of the main function](/assets/images/bughatch-malware-analysis/image15.jpg) + +### Token adjustment + +The implant starts by elevating permissions using the **SeDebugPrivilege** method, enabling the malware to access and read the memory of other processes. It leverages common Windows APIs to achieve this as shown in the pseudocode below: + +![](/assets/images/bughatch-malware-analysis/image20.jpg) + +### Information collection + +The malware collects host-based information used to fingerprint the infected system, this information will be stored in a custom structure that will be 2-byte XOR encrypted and sent to the C2 server in an HTTP POST request. + +The following lists the collected information: + +- Current value of the performance counter +- Network information +- System information +- Token information +- Domain and Username of the current process +- Current process path + +#### Current value of the performance counter + +Using the **QueryPerformanceCounter** API, it collects the amount of time since the system was last booted. This value will be used to compute the 2-byte XOR encryption key to encrypt communications between the implant and the C2 server, a detailed analysis of the encryption implementation will follow. + +![Pseudocode QueryPerformanceCounter function](/assets/images/bughatch-malware-analysis/image42.jpg) + +#### Network information + +It collects the addresses of network interfaces connected to the infected machine by using the **GetIpAddrTable** Windows API. + +![Pseudocode collecting interface addresses](/assets/images/bughatch-malware-analysis/image22.jpg) + +#### System information + +BUGHATCH collects key system information which includes: + +- Windows major release, minor release, and build number +- Processor architecture (either 32-bit or 64-bit) +- Computer name + +![Pseudocode collecting system information](/assets/images/bughatch-malware-analysis/image18.jpg) + +#### Token information + +The agent proceeds to collect the current process token group membership, it invokes the **AllocateAndInitializeSid** API followed by the **CheckTokenMembership** API, concatenating the [SDDL SID strings](https://docs.microsoft.com/en-us/windows/win32/secauthz/sid-strings) for every group the process token is part of. While not unique to BUGHATCH, this is detected by Elastic's [Enumeration of Privileged Local Groups Membership](https://www.elastic.co/guide/en/security/current/enumeration-of-privileged-local-groups-membership.html) detection rule. + +![Pseudocode collecting token group membership information](/assets/images/bughatch-malware-analysis/image29.jpg) + +#### Domain and username of the current process + +The malware opens a handle to the current process with **OpenProcessToken** and gets the structure that contains the user account of the token with **GetTokenInformation**. It then retrieves the username and domain of the user account with the **LookupAccountSidW** API and concatenates the 2 strings in the following format: **DOMAIN\USERNAME**. + +![](/assets/images/bughatch-malware-analysis/image14.jpg) + +#### Current process path + +Finally, it collects the current process path with **GetModuleFileNameW**. The malware then encrypts the entire populated structure with a simple 2-byte XOR algorithm, this encryption implementation is detailed later in the report. + +## Threading and thread synchronization + +The implant is multithreaded; it uses two different linked lists, one is filled with the commands received from the C2 server and the other is filled with the output of the commands executed. + +It spawns 5 worker threads, each handling a command received from the C2 server by accessing the appropriate linked list using the **CriticalSection** object. The main process’ thread also retrieves the command's output from the second linked list using the **CriticalSection** object for synchronization purposes, to avoid any race conditions. + +![Pseudocode of the thread creation function](/assets/images/bughatch-malware-analysis/image45.jpg) + +## Network communication protocol + +In this section we will detail: + +- Base communication protocol +- Encryption implementation + +The implant we analyzed uses HTTP(S) for communications. On top of the SSL encryption of the protocol, the malware and C2 encrypt the data with a 2-byte XOR key computed by the malware for each new session. The values to compute the 2-byte XOR key are prepended at the beginning of the base protocol packet which the server extracts to decrypt/encrypt commands. + +When launched, the malware will first send an HTTP POST request to the C2 server containing all the collected information extracted from the victim’s machine, the C2 then responds with the operator’s command if available, or else the agent sleeps for 60 seconds. After executing the command and only if the output of the executed command is available, the malware will send a POST request containing both the collected information and the command’s output, otherwise, it sends the collected information and waits for new commands. + +![Example of an implant HTTP POST request to an emulated C2 server](/assets/images/bughatch-malware-analysis/image32.png) + +### Base communication protocol + +The author(s) of BUGHATCH implemented a custom network protocol, the following is the syntax that the agent and server use for their communication: + +![BUGHATCH agent and server communications](/assets/images/bughatch-malware-analysis/BugHatchanalysisreport_html.jpg) + +- **XOR key values:** The values to compute the 2-byte XOR encryption key used to encrypt the rest of the data +- **Separator:** A static value ( **0x389D3AB7** ) that separates **Msg** chunks, example: the server can send different instructions in the same HTTP request separated by the **Separator** +- **Chunk length:** Is the length of the **Msg** , **Separator** and **Chunk length** +- **Msg:** Is the message to be sent, the message differs from the agent to the server. + +We will dive deeper into the encapsulation of the **Msg** for both the agent and the server. + +![Pseudocode extracting commands according to the separator value](/assets/images/bughatch-malware-analysis/image40.jpg) + +### Encryption implementation + +The malware uses 2-byte XOR encryption when communicating with the C&C server; a 2-byte XOR key is generated and computed by the implant for every session with the C2 server. + +The agent uses two DWORD values returned by **QueryPerformanceCounter** API as stated earlier, it then computes a 2-byte XOR key by XOR-encoding the DWORD values and then multiplying and adding hardcoded values. The following is a Python pseudocode of how the KEY is computed: + +``` +tmp = (PerformanceCount[0] ^ PerformanceCount[1]) & 0xFFFFFFFF +XorKey = (0x343FD * tmp + 0x269EC3)& 0xFFFFFFFF +XorKey = p16(XorKey >> 16).ljust(2, b'\x00') +``` + +![Pseudocode of the encryption implementation](/assets/images/bughatch-malware-analysis/image9.jpg) + +## Command handling + +In this section, we will dive deeper into the functionalities implemented in the agent and their respective **Msg** structure that will be encapsulated in the base communication protocol structure as mentioned previously. + +Once the working threads are started, the main thread will continue beaconing to the C2 server to retrieve commands. The main loop is made up of the following: + +- Send POST request +- Decrypt the received command and add it to the linked list +- Sleep for 60 seconds + +A working thread will first execute the **RemoveEntryRecvLinkedList** function that accesses and retrieves the data sent by the C2 server from the linked list. + +![Pseudocode retrieves data sent by the C2](/assets/images/bughatch-malware-analysis/image43.jpg) + +The thread will then de-encapsulate the data received from the C2 and extract the **Msg(Command)**. The malware implements different functionalities according to a command flag, the table below illustrates the functionalities of each command: + +| | | +| ------------ | --------------------------------------------------------------------- | +| Command FLAG | Description | +| 1 | Group functions related to code and command execution | +| 2 | Group functions related to utilities like impersonation and migration | +| 3 | Process injection of a PE file in a suspended child process | + +### Command 1 + +This command gives access to functionalities related to payload execution, from DLL to PE executable to PowerShell and cmd scripts. + +Some of the sub-commands use pipes to redirect the standard input/output of the child process, which enables the attacker to execute payloads and retrieve its output, for example, PowerShell or Mimikatz, etc… + +The following is the list of sub commands: + +| | | | +| ---------------- | --------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | +| Sub Command Flag | Function Name | Functionality description | +| 2 | ReflectivelyExecutePERemote | Reflectively loads PE files in a child process and redirects its standard input output, the output will be sent to the operator C2 server | +| 3 | DropPEDiskExecute | Drops a PE file to disk and executes it, the execution output is then sent to the operator’s C2 server | +| 4 | SelfShellcodeExecute | Executes a shellcode in the same process | +| 5 | RemoteShellcodeExecute | Executes a shellcode in a suspended spawned child process | +| 6 | ExecuteCmd | Executes a CMD script/command | +| 7 | ExecutePowershell | Executes a Powershell script/command | +| 9 | ReflectivelyLoadDllRemote | Executes a DLL reflectively in a remote process using CreateRemoteThread API | + +The following is the structure that is used by the above commands: + +``` +struct ExecutePayloadCommandStruct +{ + DWORD commandFlag; + DWORD field_0; + DWORD subCommandFlag_1; + DWORD readPipeTimeOut_2; + DWORD payloadSize_3; + DWORD commandLineArgumentSize_4; + DWORD STDINDataSize_5; + CHAR payload_cmdline_stdin[n]; +}; +``` + +- **commandFlag:** Indicates the command +- **subCommandFlag:** Indicates the subcommand +- **readPipeTimeOut:** Indicates the timeout for reading the output of child processes from a pipe +- **payloadSize:** Indicates the payload size +- **commandLineArgumentSize:** Indicates length of the command line arguments when executing the payload, example a PE binary +- **STDINDataSize:** Indicates the length of the standard input data that will be sent to the child process +- **Payload_cmdline_stdin:** Can contain the payload PE file for example, its command line arguments and the standard input data that will be forwarded to the child process, the malware knows the beginning and end of each of these using their respective length. + +#### ReflectivelyExecutePERemote + +The agent reflectively loads PE binaries in the memory space of a created process in a suspended state (either **cmd.exe** or **svchost.exe** ). The agent leverages [anonymous (unnamed) pipes](https://docs.microsoft.com/en-us/windows/win32/ipc/anonymous-pipes) within Windows to redirect the created child process's standard input and output handles. It first creates an anonymous pipe that will be used to retrieve the output of the created process, then the pipe handles are specified in the **STARTUPINFO** structure of the child process. + +![Pseudocode for anonymous pipe creation](/assets/images/bughatch-malware-analysis/image41.jpg) + +After creating the suspended process, the malware allocates a large memory block to write shellcode and a XOR encrypted PE file. + +The shellcode will 2-byte XOR decrypt and load the embedded PE similar to ( **Command 3** ). This command can load 64bit and 32bit binaries, each architecture has its own shellcode PE loader, after injecting the shellcode it will point the instruction pointer of the child process’s thread to the shellcode and resume the thread. + +![Pseudocode of Reflective Loading PE into child processes](/assets/images/bughatch-malware-analysis/image2.jpg) + +The following is an example of a packet captured from our custom emulated C2 server, we can see the structure discussed earlier on the left side and the packet bytes on the right side, for each command implemented in the malware, a packet example will be given. + +![Example of a ReflectivelyExecutePERemote command received from an emulated C2](/assets/images/bughatch-malware-analysis/image7.png) + +#### DropPEDiskExecute + +With this subcommand, the operator can drop a PE file on disk and execute it. The agent has 3 different implementations depending on the PE file type, GUI Application, CUI (Console Application), or a DLL. + +For CUI binaries, the malware first generates a random path in the temporary folder and writes the PE file to it using **CreateFileA** and **WriteFile** API. + +![Pseudocode writing payload to disk](/assets/images/bughatch-malware-analysis/image39.jpg) + +It then creates a process of the dropped binary file as a child process by redirecting its standard input and output handles; after execution of the payload the output is sent to the operator’s C2 server. + +For GUI PE binaries, the agent simply writes it to disk and executes it directly with **CreateProcessA** API. + +And lastly, for DLL PE files, the malware first writes the DLL to a randomly generated path in the temporary folder, then uses **c:\windows\system32\rundll32.exe** or **c:\windows\syswow64\rundll32.exe** (depending on the architecture of the DLL) to run either an exported function specified by the operator or the function **start** if no export functions were specified. + +![Pseudocode running the payload dropped by DropPEDiskExecute function](/assets/images/bughatch-malware-analysis/image1.jpg) + +![Example of a SelfShellcodeExecute command received from an emulated C2](/assets/images/bughatch-malware-analysis/image34.png) + +#### SelfShellcodeExecute + +This subcommand tasks the agent to execute shellcode in its own memory space by allocating a memory region using **VirtualAlloc** API and then copying the shellcode to it, the shellcode is executed by creating a thread using **CreateThread** API. + +![Pseudocode of SelfShellcodeExecute command](/assets/images/bughatch-malware-analysis/image37.jpg) + +![Example of a SelfShellcodeExecute command received from an emulated C2](/assets/images/bughatch-malware-analysis/image35.jpg) + +#### RemoteShellcodeExecute + +This sub-command can be used to execute a 32-bit or a 64-bit position independent shellcode in another process memory space. + +Similarly to the **SpawnAgent** subcommand, the malware creates a suspended **svchost.exe** process with **CreateProcessA** API, allocates a memory region for the shellcode sent by the C2 server with **VirtualAllocEx** , and writes to it with **WriteProcessMemory** , it then sets the suspended thread instruction pointer to point to the injected shellcode with **SetThreadContext** and finally it will resume the thread with **ResumeThread** to execute the payload. + +![Pseudocode writes shellcode to remote process](/assets/images/bughatch-malware-analysis/image26.jpg) + +![Pseudocode set EIP of child process using SetThreadContext](/assets/images/bughatch-malware-analysis/image13.jpg) + +![Example of a RemoteShellcodeExecute command received from an emulated C2](/assets/images/bughatch-malware-analysis/image23.jpg) + +#### ExecuteCmd and ExecutePowershell + +An operator can execute PowerShell scripts or CMD scripts in the infected machine, the malware can either write the script to a file in the temporary folder with a randomly generated name as follow: **`TEMP.PS1`** for PowerShell or **`TEMP.CMD`** for a Command shell. The malware then passes parameters to it if specified by the malicious actor and executes it, the malware uses named pipes to retrieve the output of the PowerShell process. + +![Pseudocode of ExecuteCmd command](/assets/images/bughatch-malware-analysis/image30.jpg) + +![Example of an ExecutePowershell command received from an emulated C2](/assets/images/bughatch-malware-analysis/image8.jpg) + +#### ReflectivelyLoadDllRemote + +Execute reflectively a 32-bit or 64-bit DLL in a process created in a suspended state, the following summarizes the execution flow: + +- Check if the PE file is a 32 or 64-bit DLL +- Create a suspended **svchost.exe** process +- Allocate memory for the DLL and the parameter for the DLL if specified by the C2 command with the **VirtualAllocEx** API +- Write to the remotely allocated memory withthe **WriteProcessMemory** API the DLL and the parameter if specified +- Create a remote thread to execute the injected DLL with the **CreateRemoteThread** API + +![Pseudocode of a ReflectivelyLoadDllRemote command](/assets/images/bughatch-malware-analysis/image19.jpg) + +![Example of a ReflectivelyLoadDllRemote command received from an emulated C2](/assets/images/bughatch-malware-analysis/image34.png) + +### Command 2 + +The command 2 has multiple sub functionalities as shown in the command table above, according to a subCommandFlag the malware can do 6 different operations as follows: + +| | | | +| ---------------- | --------------------- | ---------------------------- | +| Sub Command Flag | Function Name | Functionality description | +| 1 | ExitProcess | Exit process | +| 2 | SelfDeleteExitProcess | Self delete and exit process | +| 3 | SpawnAgent64 | Spawn 64-bit agent | +| 4 | SpawnAgent32 | Spawn 32-bit agent | +| 0x1001 | ImpersonateToken | Impersonate explorer | +| 0x1002 | MigrateC2 | Change C2 config | + +The following is the structure that is used by the above commands: + +``` +struct ImpersonateReplicateStruct +{ + int subCommandFlag; + int impersonateExplorerToken; + char padding[16]; + __int16 isParameterSet; + WCHAR w_parameters[n]; +}; +``` + +#### ExitProcess + +Calls the **ExitProcess(0)** API to terminate. + +![Example of an ExitProcess command received from an emulated C2](/assets/images/bughatch-malware-analysis/image25.png) + +#### SelfDeleteExitProcess + +The agent gets the PATH of the current process with **GetModuleFileNameA** and then executes the following command to self-delete: **cmd.exe /c del FILEPATH \\>\\> NUL** using **CreateProcessA** then simply exit the process with **ExitProcess(0)**. + +![Example of a SelfDeleteExitProcess command received from an emulated C2](/assets/images/bughatch-malware-analysis/image17.png) + +#### SpawnAgent64 and SpawnAgent32 + +When subcommands 3 or 4 are specified, the malware will spawn another agent on the same machine depending on the subcommand sent by the C2, as shown in the table above. + +The malware first retrieves the C2 IP address embedded in it, it will then do an HTTP GET request to download a packed agent in shellcode format, in the sample we analyzed **/Agent32.bin** URI is for the 32-bit agent, and **/Agent64.bin** is for 64-bit the agent. + +![Pseudocode spawning another agent](/assets/images/bughatch-malware-analysis/image33.jpg) + +The malware then creates a suspended **svchost.exe** process with **CreateProcessA** API, writes the agent shellcode to the process, sets its instruction pointer to point to the injected shellcode with **SetThreadContext** , and finally it will resume the thread with **ResumeThread** to execute the injected payload. + +![Example of a SpawnAgent32 command received from an emulated C2](/assets/images/bughatch-malware-analysis/image5.png) + +#### ImpersonateToken + +This subcommand is specific to process tokens; an attacker can either impersonate the **explorer.exe** token or create a token from credentials (Domain\Username, Password) sent by the C2 to spawn another instance of the current process. + +![Pseudocode ImpersonateToken command](/assets/images/bughatch-malware-analysis/image44.jpg) + +It will first check if the current process is a local system account or local service account or network service account by testing whether the given process token is a member of the group with the specified RID ( **SECURITY_LOCAL_SYSTEM_RID** , **SECURITY_LOCAL_SERVICE_RID** , **SECURITY_NETWORK_SERVICE_RID** ) respectively. + +![Pseudocode check token group membership](/assets/images/bughatch-malware-analysis/image36.jpg) + +Then depending if the operator specified credentials or not, the malware will first call **LogonUserW** with the Domain\User and password to create a token then it will spawn another instance of the current process with this token. + +![Pseudocode LogonUserW to create a token](/assets/images/bughatch-malware-analysis/image24.jpg) + +If not, the implant will impersonate the **explore.exe** process by duplicating its token with **DuplicateTokenEx** and then spawn the current process with the duplicated token if no credentials are specified. + +![Example of an ImpersonateToken command received from an emulated C2](/assets/images/bughatch-malware-analysis/image21.png) + +#### MigrateC2 + +The operator can migrate the implant to another C2 server by specifying the subcommand **0x1001** with the IP address of the new C2. + +![Pseudocode migrating the implant](/assets/images/bughatch-malware-analysis/image4.jpg) + +![Example of a MigrateC2 command received from an emulated C2](/assets/images/bughatch-malware-analysis/image31.png) + +### Command 3 + +When command 3 is received the malware will reflectively load a PE file embedded as payload in the C&C request in another process's memory space, the following is an overview of the execution: + +- Determine the type and architecture of the PE file +- Create a suspended process +- Allocate a large memory in the suspended process +- Write a shellcode in the allocated memory that will locate, decrypt and reflectively load the PE file +- 2-byte XOR encrypt the PE file and append it after the shellcode +- Set the EIP context of the suspended process to execute the shellcode + +The shellcode will then reflectively load the PE file + +![Pseudocode for Command 3's main logic](/assets/images/bughatch-malware-analysis/image6.jpg) + +The agent first parses the PE file received from the C2 server to determine the type and architecture of the PE file. + +![Pseudocode determines the PE file architecture](/assets/images/bughatch-malware-analysis/image28.jpg) + +And according to this information, a Windows signed executable will be chosen to inject into. + +If the PE file is CUI (Console User Interface), the malware will choose **cmd.exe** , however, if it is GUI (Graphical User Interface) or a DLL PE file it will choose **svchost.exe**. + +![Options for malware to inject into](/assets/images/bughatch-malware-analysis/image11.jpg) + +The malware will then create a suspended process with **CreateProcessA** API (either **cmd.exe** or **svchost.exe** ) and allocate a large amount of memory with **VirtualAllocEx** in the created process, it will then copy a position independent shellcode stored in the **.rdata** section to the newly allocated memory that is responsible for locating according to a specific tag the appended PE file, decrypt it and reflectively load it in memory. + +Then it appends after the shellcode a 12 bytes structure composed of a tag, the size of the PE file, and a 2-byte XOR key. + +It will then 2-byte XOR encrypt the PE file and append it after the structure, the following is an overview of the written data to the allocated memory: + +| | | | | | +| --------- | --- | ------- | -------------- | ---------------------------- | +| SHELLCODE | TAG | PE SIZE | 2-byte XOR KEY | 2-byte XOR encrypted PE file | + +![Pseudocode write shellcode and PE to child process](/assets/images/bughatch-malware-analysis/image27.jpg) + +The agent will then set the thread context with **SetThreadContext** and point the instruction pointer of the suspended process to the shellcode then it will simply resume the execution with **ResumeThread**. + +The shellcode will first locate the 2-byte XOR encrypted PE file according to the tag value ( **0x80706050** ), it will then 2-byte XOR decrypt it and load it reflectively on the same process memory. + +## Observed adversary tactics and techniques + +Elastic uses the MITRE ATT&CK framework to document common tactics, techniques, and procedures that advanced persistent threats use against enterprise networks. + +### Tactics + +Tactics represent the why of a technique or sub-technique. It is the adversary’s tactical goal: the reason for performing an action. + +- [Execution](https://attack.mitre.org/tactics/TA0002) +- [Collection](https://attack.mitre.org/tactics/TA0009) +- [Command and Control](https://attack.mitre.org/tactics/TA0011) +- [Exfiltration](https://attack.mitre.org/tactics/TA0010) + +### Techniques / sub techniques + +Techniques and Sub techniques represent how an adversary achieves a tactical goal by performing an action. + +- [Command and Scripting Interpreter: Windows Command Shell](https://attack.mitre.org/techniques/T1059/003/) +- [Encrypted Channel: Asymmetric Cryptography](https://attack.mitre.org/techniques/T1573/002/) +- [Encrypted Channel: Symmetric Cryptography](https://attack.mitre.org/techniques/T1573/001/) +- [Exfiltration Over C2 Channel](https://attack.mitre.org/techniques/T1041/) +- [Automated Collection](https://attack.mitre.org/techniques/T1119/) +- [Native API](https://attack.mitre.org/techniques/T1106/) + +## Detections + +### Detection rules + +The following detection rule was observed during the analysis of the BUGHATCH sample. This rule is not exclusive to BUGHATCH activity. + +- [Enumeration of Privileged Local Groups Membership](https://www.elastic.co/guide/en/security/current/enumeration-of-privileged-local-groups-membership.html#enumeration-of-privileged-local-groups-membership) + +### YARA rule + +Elastic Security has created a [YARA rule](https://github.com/elastic/protections-artifacts/blob/main/yara/rules/Windows_Trojan_Bughatch.yar) to identify this activity. + +``` +rule Windows_Trojan_BUGHATCH { + meta: + author = “Elastic Security” + creation_date = "2022-05-09" + last_modified = "2022-06-09" + license = “Elastic License v2” + os = "Windows" + arch = "x86" + category_type = "Trojan" + family = "BUGHATCH" + threat_name = "Windows.Trojan.BUGHATCH" + reference_sample = "b495456a2239f3ba48e43ef295d6c00066473d6a7991051e1705a48746e8051f" + + strings: + $a1 = { 8B 45 ?? 33 D2 B9 A7 00 00 00 F7 F1 85 D2 75 ?? B8 01 00 00 00 EB 33 C0 } + $a2 = { 8B 45 ?? 0F B7 48 04 81 F9 64 86 00 00 75 3B 8B 55 ?? 0F B7 42 16 25 00 20 00 00 ?? ?? B8 06 00 00 00 EB ?? } + $a3 = { 69 4D 10 FD 43 03 00 81 C1 C3 9E 26 00 89 4D 10 8B 55 FC 8B 45 F8 0F B7 0C 50 8B 55 10 C1 EA 10 81 E2 FF FF 00 00 33 CA 8B 45 FC 8B 55 F8 66 89 0C 42 } + $c1 = "-windowstyle hidden -executionpolicy bypass -file" + $c2 = "C:\\Windows\\SysWOW64\\WindowsPowerShell\\v1.0\\powershell.exe" + $c3 = "ReflectiveLoader" + $c4 = "\\Sysnative\\" + $c5 = "TEMP%u.CMD" + $c6 = "TEMP%u.PS1" + $c7 = "\\TEMP%d.%s" + $c8 = "NtSetContextThread" + $c9 = "NtResumeThread" + + condition: + any of ($a*) or 6 of ($c*) +} +``` diff --git a/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/click_click_boom_automating_protections_testing_with_detonate.mdx b/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/click_click_boom_automating_protections_testing_with_detonate.mdx new file mode 100644 index 0000000000000..ed971a348128f --- /dev/null +++ b/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/click_click_boom_automating_protections_testing_with_detonate.mdx @@ -0,0 +1,67 @@ +--- +title: "Click, Click… Boom! Automating Protections Testing with Detonate" +slug: "click-click-boom-automating-protections-testing-with-detonate" +date: "2023-05-04" +description: "To automate this process and test our protections at scale, we built Detonate, a system that is used by security research engineers to measure the efficacy of our Elastic Security solution in an automated fashion." +author: + - slug: jessica-david + - slug: hez-carty + - slug: sergey-polzunov +image: "blog-thumb-tools-various.jpg" +category: + - slug: tools + - slug: security-research + - slug: detection-science +tags: + - detonate +--- + +## Preamble + +Imagine you are an Endpoint artifact developer. After you put in the work to ensure protection against conventional shellcode injections or ransomware innovations, how do you know it actually works before you send it out into the world? + +First, you set up your end-to-end system, which involves setting up several services, the infrastructure, network configuration, and more. Then, you run some malware; the data you collect answers questions about performance and efficacy, and may be an important research resource in the future. After you spend a day testing and gathering your results, you may want to run several hundred hashes over multiple kinds of operating systems and machine types, a daunting task if done entirely manually. + +To automate this process and test our protections at scale, we built Detonate, a system that is used by security research engineers to measure the efficacy of our Elastic Security solution in an automated fashion. Our goal is to have it take security researchers only a couple of clicks to test our protections against malware. (Thus: click, click… boom!) + +In this series of posts, we’ll: - Introduce Detonate and why we built it - Explore how Detonate works and the technical implementation details - Describe case studies on how our teams use it at Elastic - Discuss opening our efficacy testing to the community to help the world protect their data from attack + +Interested in other posts on Detonate? Check out [Part 2 - Into The Weeds: How We Run Detonate](https://www.elastic.co/security-labs/into-the-weeds-how-we-run-detonate) where we break down how Detonate works and dive deeper into the technical implementation. + +## What is Detonate? + +At a high level, Detonate runs malware and other potentially malicious software in a controlled (i.e., sandboxed) environment where the full suite of Elastic Security capabilities are enabled. Detonate accepts a file hash (usually a SHA256) and performs the following actions: + +- Prepares all files needed for detonation, including the malicious file +- Provisions a virtual machine (VM) instance in a sandboxed environment, with limited connectivity to the outside world +- Waits until file execution completes; this happens when, for example, an execution result file is found or the VM instance is stopped or older than a task timeout +- Stops the running VM instance (if necessary) and cleans up the sandboxed environment +- Generates an event summary based on telemetry and alerts produced during detonation + +The results of these detonations are made available to the team for research and development purposes. By post-processing the logs, events, and alerts collected during detonation, we can enrich them with third-party intelligence and other sources to evaluate the efficacy of new and existing Elastic Security protection features. + +## What does it help us with? + +### Measuring Efficacy + +To build the best EPP on the market, we have to continuously measure the effectiveness of our product against the latest threats. Detonate is used to execute many tens of thousands of samples every month from our data feeds. Gaps in coverage are automatically identified and used to prioritize improvements to our protections. + +### Supporting existing protections + +Many of our protections have associated artifacts (such as machine learning models and rule definitions) which receive regular updates. These updates need testing to ensure we identify and remediate regressions before they end up in a user’s environment. + +Detonate provides a framework and suite of tools to automate the analysis involved in this testing process. By leveraging a corpus of hashes with known good and bad software, we can validate our protections before they are deployed to users. + +### Threat research + +Some of our security researchers scour the internet daily for new and emerging threats. By giving them an easy-to-use platform to test malicious software they find in the wild, we better understand how Elastic Security defends against those threats or if we need to update our protections. + +### Evaluating new protections + +In addition to testing existing protections, new protections run the risk of adverse interactions with our existing suite of layered capabilities. A new protection may be easily tested on its own, but tests may hide unintended interactions or conflicts with existing protections. Detonate provides a way for us to customize the configuration of the Elastic Stack and individual protections to more easily find and identify such conflicts earlier in development. + +## What’s next? + +In this publication, we introduced Detonate & what we use it for at Elastic. We discussed the benefits it provides our team when assessing the performance of our security artifacts. + +Now that you know what it is, we will break down how Detonate works. In our next post, we’ll dive deeper into the technical implementation of Detonate and how we’re able to create this sandboxed environment in practice. diff --git a/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/cloud_monitoring_and_detection_with_elastic_security.mdx b/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/cloud_monitoring_and_detection_with_elastic_security.mdx new file mode 100644 index 0000000000000..3ce3719c061ec --- /dev/null +++ b/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/cloud_monitoring_and_detection_with_elastic_security.mdx @@ -0,0 +1,193 @@ +--- +title: "Security operations: Cloud monitoring and detection with Elastic Security" +slug: "cloud-monitoring-and-detection-with-elastic-security" +date: "2022-11-30" +description: "As companies migrate to cloud, so too do opportunist adversaries. That's why our Elastic Security team members have created free detection rules for protecting users' cloud platforms like AWS and Okta. Learn more in this blog post." +author: + - slug: brent-murphy + - slug: david-french + - slug: elastic-security-intelligence-analytics-team +image: "blog-thumb-network-attack-map.jpg" +category: +--- + +As many organizations have migrated their infrastructure, applications, and data to cloud offerings, adversaries have extended their operational capabilities in cloud environments to achieve their mission — whether that means stealing intellectual property, disrupting business operations, or holding an organization's data for ransom. In order to protect our users' data from attack, the Elastic Security Intelligence & Analytics Team researches and develops [rules](https://www.elastic.co/blog/elastic-security-opens-public-detection-rules-repo) to detect attacker behavior in the cloud _and_ on the endpoint. + +In this post, we'll discuss cloud monitoring and detection-related challenges security operations teams face, and why attacks against cloud environments are often successful. We will share details on our free cloud detection rules (including many new ones released in [Elastic Security 7.9](https://www.elastic.co/blog/whats-new-elastic-security-7-9-0-free-endpoint-security)) and show how they can help [Elastic Security](https://www.elastic.co/security) users. + +We'll also explain how Elastic can ingest logs from a wide variety of cloud platforms and how the Elastic Common Schema (ECS) makes searching, monitoring, and detection easy for defenders. + +## Cloud monitoring and detection challenges + +Security teams typically encounter one or more of the following challenges when they're asked to monitor, detect, and respond to threats in their organization's cloud environments: + +- **Resource constraints:** It can take a considerable amount of time to learn and understand cloud technologies and their ever-changing data sources. Many security operations teams do not have the resources to allocate to this ongoing effort. +- **Understanding of adversary tradecraft:** Attacker behavior on well-known platforms such as Windows has been researched extensively and shared with the security community. Security teams may not have an in-depth understanding of how adversaries operate in cloud environments or the ability to provision a test environment to practice offensive and defensive techniques to protect their organization. +- **Blind spots:** For effective monitoring and detection, the data available to security practitioners must be relevant, accurate, and timely. Cloud logs shipped to a SIEM can be used for detection and response as long as the security team can depend on the quality of the data. +- **Data normalization:** Most cloud platforms have their own log categories and event schema. Normalizing logs into a common schema is not a trivial or one-off task. Some security teams, for example, have several different field names for a hostname across their data sources indexed in their SIEM. Without a normalized and documented schema, it can be difficult for analysts — especially less experienced ones — to write search queries and correlate events across data sources effectively. + +## Ingesting and searching cloud logs with Elastic + +Elastic has a large collection of Filebeat [modules](https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-modules.html) that can be used to simplify the collection, parsing, and visualization of many diverse log formats into a common schema — including cloud platforms such as [Amazon Web Services (AWS)](https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-aws.html), [Azure](https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-azure.html), [Okta](https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-okta.html), and [Office 365](https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-o365.html). Rapid development of new Filebeat modules is an ongoing process. + +The [Elastic Common Schema](https://www.elastic.co/guide/en/ecs/current/ecs-reference.html) (ECS) defines a common set of fields for ingesting logs from a connected data source (e.g., AWS/Okta) into Elasticsearch. Log data is normalized into a format where the various field names can be used in queries to correlate behavior across data sources. This is useful to security and IT operations teams for a number of reasons. + +Practitioners and administrators do not need to spend countless hours transforming or normalizing their ingested logs so that the field names follow their own common schema. Managing a schema like this yourself is no small undertaking and is a continuous effort. Elastic manages ECS (saving users time and resources) so that security teams can rely on a common set of field names to search their data quickly and efficiently. + +End users can rely on using the same field names in their queries when searching across multiple data sources, which presents the following advantages: + +- Having a consistent schema for searching saves security analysts time and lowers the barrier to entry for new analysts. Analysts don't have to learn or remember all of the different field names and their purpose for each data source. +- Analysts can correlate events across data sources such as endpoint, proxy, and firewall, which helps them ask questions of their data more efficiently and make sound decisions during an investigation, incident, or hunt. +- It's easy for analysts to produce a timeline or build a visualization of the activity that occurred. + +## Detecting attackers operating in cloud environments + +The Elastic Security Intelligence & Analytics Team's research into adversary tradecraft leads to new detection features like rules and machine learning jobs — capabilities that enable small security teams to have an outsized impact. Security features like these increase the cost of an attack for adversaries. Elastic Security users can expect to see a continued focus on increasing the cost of cloud attacks. + +In the remainder of this blog post, we'll simulate attack techniques against AWS and Okta cloud environments. We'll review the alerts that are generated by the suspicious activity and how an analyst can perform initial triage and complete their investigation using Elastic Security. We will also demonstrate how analysts can add exceptions to detection rules in order to filter benign events and continue to alert on suspicious behavior. + +## Monitoring AWS CloudTrail logs to detect suspicious behavior + +As organizations migrate to or provision new infrastructure in cloud platforms like AWS, they face the common challenges that we described earlier. Fortunately, Elastic Security has a [strong variety of AWS rules](https://github.com/elastic/detection-rules/tree/main/rules/aws), available for [free in 7.9](https://www.elastic.co/blog/whats-new-elastic-security-7-9-0-free-endpoint-security) to detect suspicious behaviors in an AWS environment. + +The Filebeat [module](https://www.elastic.co/guide/en/beats/filebeat/master/filebeat-module-aws.html) for AWS helps you easily ship CloudTrail, Simple Storage Service (S3), Elastic Load Balancing (ELB), and virtual private cloud (VPC) flow logs to Elasticsearch for monitoring and detection in Elastic Security. Let's walk through an attack and defense scenario utilizing CloudTrail data. [CloudTrail](https://aws.amazon.com/cloudtrail/) provides event history of your AWS account activity, including actions taken through the AWS Management Console, AWS software development kits (SDKs), command line tools, and other AWS services. This event history can help simplify security detection, analysis, and investigations. + +Many attacks against AWS start with an attacker obtaining an access key and/or the secret access key details. These keys may be harvested in a variety of ways, including through phishing, a data breach, GitHub repositories, screenshots, error messages, snapshot data, or simply poor key management practices. By obtaining these keys, an attacker can take a variety of actions against your AWS infrastructure. + +Let's walk through one of the many potential attack scenarios that could play out. In the following example, the adversary enumerates the trails and monitoring capabilities that have been configured for the AWS account. They follow up on this activity by disabling a trail and a configuration recorder in an attempt to evade detections and then proceed to harvest secrets. + +### Simulating adversary behavior in AWS + +In this demonstration, we'll use [Pacu](https://github.com/RhinoSecurityLabs/pacu) to perform our attack. Pacu is a popular framework for exploiting AWS infrastructure, developed and maintained by Rhino Security Labs. Pacu is modular, similar to other exploitation frameworks like Metasploit and Koadic, and enables attackers to exploit configuration flaws within an AWS account. Attackers can use Pacu to check if the required permissions are assigned to the compromised account before attempting to execute a module. This can be helpful from an attacker's perspective to not create unnecessary noise and logs, and draw additional attention from defenders by running modules that will ultimately fail. + +The attacker begins by enumerating services using the detection\_\_enum_services module to determine what logging and monitoring services are enabled for the AWS account. + +![Figure 1 - Enumerating services using Pacu’s detection__enum_services module ](/assets/images/cloud-monitoring-and-detection-with-elastic-security/1-enumerating-services-blog-secops-cloud-platform-monitoring.jpg) + +The attacker discovered eight trails, as well as ten configuration rules, a recorder, and a delivery channel. Essentially, the enumeration script is querying certain AWS API calls to list or describe relevant information about the environment. By reviewing the [code](https://github.com/RhinoSecurityLabs/pacu/blob/master/modules/detection__enum_services/main.py) of the module, we can see the targeted APIs: + +``` +DescribeSubscription +GetSubscriptionState +DescribeTrails +ListDetectors +DescribeConfigRules +DescribeConfigurationRecorders +DescribeConfigurationRecorderStatus +DescribeDeliveryChannels +DescribeDeliveryChannelStatus +DescribeConfigurationAggregators +DescribeAlarms +DescribeFlowLogs +``` + +After the attacker determines which services are running, their next logical step may be to interrupt logging and monitoring by disabling a trail, alarm, detector, or recorder in an attempt to evade detection. To accomplish this objective, we'll use a different module called detection\_\_disruption to disable a trail called brentlog, and stop the configuration recorder named default. + +![Figure 2 - Disabling a trail and stopping a configuration recorder using Pacu’s detection__disruption module ](/assets/images/cloud-monitoring-and-detection-with-elastic-security/2-disabling-trail-blog-secops-cloud-platform-monitoring.jpg) + +At this point, with trail logging suspended and the configuration recorder turned off from tracking changes to resources, the attacker may want to check if there are any credentials, API keys, or tokens available in [Secrets Manager](https://aws.amazon.com/about-aws/whats-new/2018/04/introducing-aws-secrets-manager/#:~:text=AWS%20Secrets%20Manager%20is%20a,other%20secrets%20throughout%20their%20lifecycle.) and if so, collect them. In this scenario, the attacker uses the enum_secrets module and finds one secret in the directory, /sessions/brent/downloads/secrets/secrets_manager. Harvesting these secrets could help the adversary achieve lateral movement and/or privilege escalation. + +![Figure 3 - Searching for AWS secrets using Pacu's enum__secrets module](/assets/images/cloud-monitoring-and-detection-with-elastic-security/3-searching-aws-blog-secops-cloud-platform-monitoring.jpg) + +![Figure 4 - Viewing the AWS secret after its discovery](/assets/images/cloud-monitoring-and-detection-with-elastic-security/4-viewing-aws-blog-secops-cloud-platform-monitoring.jpg) + +We'll stop our fictitious attack scenario here, but if you're curious to learn what the attacker could do next, the following Google search will return some examples: intitle:"AWS" intext:("attack" | "breach"). In the next section, we'll look at what this behavior looks like from a defender's perspective and how Elastic Security can be used to detect this behavior. + +### Detecting and investigating the suspicious behavior in AWS + +While monitoring the usage of the previously mentioned APIs, it can be difficult to distinguish benign activity from suspicious behavior, such as an attacker enumerating an environment. In production environments, monitoring for calls to these APIs can be noisy, as the behavior is quite common. To help find this rare and potentially suspicious behavior, and in addition to the AWS detection rules we have available, we've released [machine learning](https://github.com/elastic/detection-rules/tree/main/rules/ml) jobs in 7.9 specifically for AWS CloudTrail that help identify outliers, such as patterns of unusual activity that are hard to find using conventional detection rules. + +Looking at our detections page from the previous attack, we can see multiple alerts were triggered. Our free built-in detection rules identified the techniques of _suspending a trail_, _stopping a configuration recorder_, and _grabbing sensitive information from the secrets manager_. The other alerts are from the machine learning jobs of [_Unusual Country For an AWS Command_](https://www.elastic.co/guide/en/security/7.9/unusual-city-for-an-aws-command.html) and [_Unusual AWS Command for a User_](https://www.elastic.co/guide/en/security/master/unusual-aws-command-for-a-user.html) which identify a geolocation (country) that is unusual for the command or a user context that does not normally use the command. + +![Figure 5 - Viewing the detection alerts in Elastic Security](/assets/images/cloud-monitoring-and-detection-with-elastic-security/5-viewing-detection-alerts-blog-secops-cloud-platform-monitoring.jpg) + +If we pivot into one of the machine learning alerts, we can see a description of what it detected, along with a built-in investigation guide to walk an analyst through a potential workflow when analyzing an unusual CloudTrail event. + +![Figure 6 - Viewing the details of a machine learning alert](/assets/images/cloud-monitoring-and-detection-with-elastic-security/6-machine-learning-alert-blog-secops-cloud-platform-monitoring.jpg) + +![Figure 7 - Viewing the investigation notes for an unusual CloudTrail event](/assets/images/cloud-monitoring-and-detection-with-elastic-security/7-viewing-investigation-notes-blog-secops-cloud-platform-monitoring.png) + +Let's also take a look at the details in the Timeline view from the [_AWS Configuration Recorder Stopped_](https://www.elastic.co/guide/en/security/master/aws-configuration-recorder-stopped.html) alert. The fields I'm particularly interested in are the API call, user agent string, user identity type, request parameters, and the raw text of the entire event. + +![Figure 8 - Analyzing the alert details in the Timeline](/assets/images/cloud-monitoring-and-detection-with-elastic-security/8-alert-details-timeline-blog-secops-cloud-platform-monitoring.png) + +By analyzing the alert, we're able to quickly determine: + +| | | +| ------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Field | Description | +| event.action | Tells us the AWS API call that was made, StopConfigurationRecorder | +| request_parameters | Gives us the details about what was sent in the request, in our case, the configuration recorder name, default | +| user.name | Informs us as to who made the request, pacu | +| user_identity.type | Contains details about the type of Identity and Access Management (IAM) identity. In our case, an IAMUser. Root is another user identity type we have built in rules for. | +| user_agent | The value of the HTTP User-Agent header. User agent strings can be easily modified, but if an account typically uses the AWS Java SDK for their API calls, and it changes, then the detection of the anomalous user agent string can be a quick win. | +| event.original | Gives us the raw alert details | + +_Table 1 - Analysis of alert fields_ + +After analyzing the alert, we can start to piece together the events and look at what actions the user took just before our alerts fired (and afterwards as applicable). Again, we can spot the attackers enumeration here as well. + +![Figure 9 - Viewing event history for the user Pacu in the Timeline ](/assets/images/cloud-monitoring-and-detection-with-elastic-security/9-event-history-blog-secops-cloud-platform-monitoring.png) + +We may also want to search our environment for specific API calls to see if they were invoked by other users or hosts, from different IPs, or at other time frames that would be suspicious in our environment. + +![Figure 10 - Viewing API call history for the StopConfigurationRecorder API in the Timeline ](/assets/images/cloud-monitoring-and-detection-with-elastic-security/10-api-history-blog-secops-cloud-platform-monitoring.png) + +We can also create a visualization to look for the least common API calls in our environment and pivot from there. For AWS, the API calls are in the event.action field. + +![Figure 11 - Using a visualization to look for least common API calls in our environment ](/assets/images/cloud-monitoring-and-detection-with-elastic-security/11-visualization-api-calls-blog-secops-cloud-platform-monitoring.png) + +As demonstrated, our free built-in rules for AWS can detect this activity as well as a number of other potential attack scenarios. We've opened up our [rules repository](https://github.com/elastic/detection-rules) and encourage you to have a look and learn how to [contribute](https://github.com/elastic/detection-rules#how-to-contribute) if interested. + +## Detecting suspicious behavior in Okta logs + +[Okta single sign-on (SSO)](https://www.okta.com/products/single-sign-on/) is a cloud solution that allows users to log into a variety of systems in their organization via a centralized process using a single user account. Informing end users that they only have to remember one username and password instead of ten or more reduces the risk that they'll adopt poor password hygiene and enables system administrators to enforce stronger password policies. Further, multi-factor authentication (MFA) policies can be configured in Okta, which raises the barriers to entry for attackers. Many attackers will simply move on to look for an easier target when they discover that MFA is enforced for their target's network or user account. + +While SSO solutions can provide a convenient user experience and reduce cybersecurity risk for an organization, these centralized systems that offer a type of skeleton key to many systems and applications are often an attractive target for attackers. For example, if an adversary manages to harvest an Okta administrator's credentials or API token, they could attempt to perform any of the actions in the non-exhaustive list below: + +- Modify or disable MFA policies for one or more applications in order to weaken their victim's security controls. +- Create new user accounts or API tokens to maintain persistence in their target's environment and attempt to “blend in” and evade detection. +- Modify, delete, or deactivate an Okta network zone to loosen the restrictions on which geolocation users or administrators can login from. +- Delete or disable an application or other configuration to create a Denial-of-Service (DoS) condition and impact a company's business operations. + +To enable security teams to monitor their Okta environment for suspicious activity, our [Okta Filebeat module](https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-okta.html) can pull [Okta System Log](https://developer.okta.com/docs/reference/api/system-log/) events and ship them to Elasticsearch to be indexed. Okta's System Log records events related to an organization in order to provide an audit trail that can be used to understand platform activity. The Elastic Security Intelligence & Analytics Team has [free rules](https://github.com/elastic/detection-rules/tree/main/rules/okta) to detect suspicious activity in Okta logs and will continue adding more in future. + +In the following example, imagine that an adversary has harvested an API token after gaining initial access to an organization's network. The API token has administrator privileges and the adversary executes some actions in their target's Oka environment: + +- Create a new user account and assign administrative permissions to it in order to maintain a presence in the target environment should the security team discover that the current API token is compromised +- Deactivate a sign-on policy in order to weaken the target's security controls +- Disable a network zone to enable attackers to authenticate from any geographical location during their intrusion + +The Okta Filebeat module was configured to ship Okta System Log events to Elasticsearch and our Okta rules were activated in Elastic Security. The suspicious activity triggered three alerts shown in Figure 12 below. + +![Figure 12 - Okta alerts in Elastic Security generated by suspicious activity](/assets/images/cloud-monitoring-and-detection-with-elastic-security/12-okta-alerts-blog-secops-cloud-platform-monitoring.png) + +Clicking on one of the alerts allows the analyst to review more information about the rule, including the description of the behavior that the rule detects, severity and risk scores, and the associated MITRE ATT&CK® tactic and technique. The analyst can scroll further down the page and begin to investigate the alert in Timeline. + +To learn more how Elastic supports ATT&CK, see our presentation: [How to Plan and Execute a Hunt](https://youtu.be/2Hh5spqA6bw). + +![Figure 13 - Viewing a rule's information and settings](/assets/images/cloud-monitoring-and-detection-with-elastic-security/13-rule-information-blog-secops-cloud-platform-monitoring.png) + +Security practitioners know that every organization's network is different. Behavior that looks suspicious in one environment may be benign in another. To help security teams find the proverbial “signal in the noise,” users can add exceptions to their detection rules to filter benign events and continue to alert on suspicious events. Figure 14 shows an exception being added to an Okta rule. + +![Figure 14 - Adding an exception to a rule in Elastic Security](/assets/images/cloud-monitoring-and-detection-with-elastic-security/14-adding-exception-blog-secops-cloud-platform-monitoring.jpg) + +We've also introduced the "threshold" rule type. Threshold rules aggregate query results and generate an alert when the number of matched events exceeds a certain threshold. The example rule below will generate an alert when 25 Okta user authentication failures occur from a single source IP address. This can be indicative of a brute force or password spraying attack. + +![Figure 15 - Reviewing a threshold rule configured to detect an Okta brute force attack](/assets/images/cloud-monitoring-and-detection-with-elastic-security/15-okta-brute-force-blog-secops-cloud-platform-monitoring.png) + +Viewing an alert generated by a threshold rule in the Timeline allows an analyst to review the events that triggered the rule and begin their triage process or investigation. + +![Figure 16 - Reviewing an alert from a failed Okta authentication threshold rule in Timeline](/assets/images/cloud-monitoring-and-detection-with-elastic-security/16-reviewing-alert-blog-secops-cloud-platform-monitoring.png) + +## Conclusion + +According to Verizon's latest [Data Breach Investigations Report](https://enterprise.verizon.com/resources/reports/dbir/), cloud assets were involved in 24% of the report's 3,950 data breaches reviewed last year. As organizations continue to migrate their data and business operations to the cloud, we can expect this number to increase. + +In this blog post, we discussed some of the challenges that security teams face when attempting to monitor for, detect, and investigate suspicious behavior in their organization's cloud environments. We walked through some practical examples on how attackers operate in cloud environments and how Elastic Security can detect those techniques. + +The Elastic Security Intelligence & Analytics Team researches adversary tradecraft and develops new detection rules and machine learning jobs for multiple platforms including cloud. Our users can expect to see our continued focus on increasing the cost of cloud attacks. + +Configuring our [Filebeat modules](https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-modules.html) to ship logs to Elasticsearch and enable detection rules in Elastic Security is easy. Our [free detection rules](https://github.com/elastic/detection-rules) help security teams monitor those logs and detect suspicious behavior, regardless of the size of their team. Elastic Security enables analysts to triage and investigate those alerts quickly and efficiently. + +If you're interested in learning more about Elastic Security, you can [download it for free](https://www.elastic.co/security) or sign up for a free 14-day trial of [Elastic Cloud](https://www.elastic.co/cloud/). diff --git a/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/cobalt_strike_beacon_extractor.mdx b/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/cobalt_strike_beacon_extractor.mdx new file mode 100644 index 0000000000000..04a962656507c --- /dev/null +++ b/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/cobalt_strike_beacon_extractor.mdx @@ -0,0 +1,125 @@ +--- +title: "Cobalt Strike Beacon Extractor" +slug: "cobalt-strike-beacon-extractor" +date: "2022-12-06" +description: "Python script that collects Cobalt Strike memory data generated by security events from an Elasticsearch cluster, extracts the configuration from the CS beacon, and writes the data back to Elasticsearch." +author: + - slug: elastic-security-labs +image: "tools-image.jpg" +category: + - slug: tools +tags: + - cobaltstrike +--- + +Python script that collects Cobalt Strike memory data generated by security events from an Elasticsearch cluster, extracts the configuration from the CS beacon, and writes the data back to Elasticsearch. + +[Download cobalt-strike-extractor.tar.gz](https://assets.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltdbc4f9f2366d2f06/628829603b9b8554904a4ba2/cobalt-strike-extractor.tar.gz) + +## Overview + +This tool provides a Python module and command line tool that will search Elastic Endpoint alert data for detections of Cobalt Strike and the extracted memory data. When present, this tool will extract the implant configuration using the [cobaltstrike-config-extractor](https://github.com/strozfriedberg/cobaltstrike-config-extractor). The information is then normalized into an ECS-formatted JSON document and indexed into an Elasticsearch cluster or output to the terminal as JSON. + +> For help on creating Fleet policies to collect and analyze Cobalt Strike beacons in the Elastic Stack, check out our blog posts detailing this: +> +> - [Collecting Colbalt Strike beacons](https://www.elastic.co/security-labs/collecting-cobalt-strike-beacons-with-the-elastic-stack) +> - [Extracting Cobalt Strike beacon configurations](https://www.elastic.co/security-labs/extracting-cobalt-strike-beacon-configurations) + +## Getting Started + +### Docker + +The recommended and easiest way to get going is to use Docker. From the directory this README is in, you can build a local container. + +``` +docker build . -t cobalt-strike-extractor +``` + +Next, make a copy of config.reference.yml and name it config.local.yml and edit for your environment. A minimal config looks like the example below. The input and output could use the same values, but you can optionally push it to a different cluster for analysis. + +``` +## Using an Elastic Cloud instance (this is a randomly generated example) +input.elasticsearch: + enabled: True + cloud.id: security-cluster:dXMtd2VzdDEuZ2NwLmNsb3VkLmVzLmlvJGU0MWU1YTc3YmRjNzY2OTY0MDg2NjIzNDA5NzFjNjFkJDdlYjRlYTJkMzJkMTgzYTRiMmJkMjlkNTNjODhjMjQ4 + cloud.auth: elastic: + +## Default output will use localhost:9092, see reference config +output.elasticsearch: + enabled: True + username: elastic + password: + +``` + +Now, run the container, passing in our local configuration. The -v flag here will add informational messages to the log output. Here, it tells us how many documents were successfully parsed and written. + +``` +docker run -ti --rm -v "$(pwd)/config.local.yml:/config.yml" \ + cobalt-strike-extractor:latest -c /config.yml -v + +``` + +_Output_: + +``` +[2022-01-10T21:33:31.493][INFO] Setting up input/output +[2022-01-10T21:33:31.493][INFO] Connecting to Elasticsearch for input +[2022-01-10T21:33:31.493][INFO] Successfully connected to Elasticsearch for input +[2022-01-10T21:33:31.834][INFO] Connecting to Elasticsearch for output +[2022-01-10T21:33:31.835][INFO] Successfully connected to Elasticsearch for output +[2022-01-10T21:33:33.030][WARNING] Could not parse source as PE file (DOS Header magic not found.) +[2022-01-10T21:33:33.078][WARNING] CobaltStrike Beacon config not found: +[2022-01-10T21:33:33.093][WARNING] Could not parse source as PE file (DOS Header magic not found.) +[2022-01-10T21:33:33.096][WARNING] CobaltStrike Beacon config not found: +[2022-01-10T21:33:33.097][WARNING] Could not parse source as PE file (DOS Header magic not found.) +[2022-01-10T21:33:33.097][WARNING] CobaltStrike Beacon config not found: +[2022-01-10T21:33:33.097][WARNING] Could not parse source as PE file (DOS Header magic not found.) +[2022-01-10T21:33:33.098][WARNING] CobaltStrike Beacon config not found: +[2022-01-10T21:33:33.186][WARNING] Could not parse source as PE file (DOS Header magic not found.) +[2022-01-10T21:33:33.191][WARNING] CobaltStrike Beacon config not found: +[2022-01-10T21:33:33.461][WARNING] Could not parse source as PE file (DOS Header magic not found.) +[2022-01-10T21:33:33.516][WARNING] CobaltStrike Beacon config not found: +[2022-01-10T21:33:33.927][INFO] Wrote 2 docs to Elasticsearch + +``` + +The [WARNING] messages here are to be expected. These are simply source documents that didn’t contain the configuration information. + +#### Filter by time + +To limit the search by time frame, you can add the --since argument, which takes either an ISO-formatted date time string or you can use [Elastic date math](https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-range-query.html#ranges-on-dates). For example, to limit search to the last 30 days, you can do the following. + +``` +docker run -ti --rm -v "$(pwd)/config.local.yml:/config.yml" \ + cobalt-strike-extractor:latest --since "now-30d/d" -c config.local.yml + +``` + +#### Pipe output to other tools + +Lastly, you can pipe the output to other commands, such as jq to do local analysis. You can also override the configuration file values using environment variables. + +``` +docker run -i --rm -a stdin -a stdout -a stderr \ + -v "$(pwd)/config.local.yml:/config.yml" \ + -e "OUTPUT_ELASTICSEARCH_ENABLED=False" \ + -e "OUTPUT_CONSOLE_ENABLED=True" cobalt-strike-extractor:latest -c /config.yml -q | jq '.cobaltstrike.server.hostname' + +``` + +In the example above, we disabled the Elasticsearch output and enabled the Console output using environment variables. We made the output more quiet using the -q flag (hiding the warnings). Then, we used jq to just pull out the “hostname” value of the configuration. + +### Running it Locally + +As mentioned above, Docker is the recommended approach to running this project, however you can also run this locally. This project uses [Poetry](https://python-poetry.org/) to manage dependencies, testing, and metadata. If you have Poetry installed already, from this directory, you can simply run the following commands to run the tool. This will setup a virtual environment, install the dependencies, activate the virtual environment, and run the console script. + +``` +poetry lock +poetry install +poetry shell +cobalt-strike-extractor --help + +``` + +Once that works, you can do the same sort of things as mentioned in the Docker instructions above. diff --git a/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/collecting_and_operationalizing_threat_data_from_the_mozi_botnet.mdx b/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/collecting_and_operationalizing_threat_data_from_the_mozi_botnet.mdx new file mode 100644 index 0000000000000..ed450681a168b --- /dev/null +++ b/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/collecting_and_operationalizing_threat_data_from_the_mozi_botnet.mdx @@ -0,0 +1,450 @@ +--- +title: "Collecting and operationalizing threat data from the Mozi botnet" +slug: "collecting-and-operationalizing-threat-data-from-the-mozi-botnet" +date: "2022-06-02" +description: "The Mozi botnet is an ongoing malware campaign targeting unsecured and vulnerable networking devices. This post will showcase the analyst journey of collecting, analyzing, and operationalizing threat data from the Mozi botnet." +author: + - slug: andrew-pease + - slug: seth-goodwin + - slug: derek-ditch + - slug: daniel-stepanic +image: "blog-thumb-mozi-botnet.jpg" +category: + - slug: security-research +--- + +Detecting and preventing malicious activity such as botnet attacks is a critical area of focus for threat intel analysts, security operators, and threat hunters. Taking up the Mozi botnet as a case study, this blog post demonstrates how to use open source tools, analytical processes, and the Elastic Stack to perform analysis and enrichment of collected data irrespective of the campaign. This will allow you to take the lessons and processes outlined below to your organization and apply them to your specific use cases. + +The Mozi botnet has been leveraging vulnerable Internet of Things (IoT) devices to launch campaigns that can take advantage of the force multiplication provided by a botnet (Distributed Denial of Service (DDoS), email spam, brute-force, password spraying, etc.). Mozi was [first reported](https://blog.netlab.360.com/mozi-another-botnet-using-dht/) by the research team at 360Netlab in December 2019 and has continued to make up a large portion of IoT network activity across the Internet-at-large. + +As reported by 360Netlab, the botnet spreads via the use of weak and default remote access passwords for targeted devices as well as through multiple public exploits. The Mozi botnet communicates using a Distributed Hash Table (DHT) which records the contact information for other nodes in the botnet. This is the same serverless mechanism used by file sharing peer-to-peer (P2P) clients. Once the malware has accessed a vulnerable device, it executes the payload and subsequently joins the Mozi P2P network. The newly infected device listens for commands from controller nodes and also attempts to infect other vulnerable devices. + +Mozi targets multiple IoT devices and systems, mainly focused on Small Office Home Office (SOHO) networking devices, Internet-connected audio visual systems, and theoretically any 32-bit ARM device. + +## Collection + +When performing data analysis, the more data that you have, the better. Analysis of malware campaigns are no different. With a paid subscription to VirusTotal, you can collect huge amounts of data for analysis, but we wanted an approach for independent researchers or smaller organizations that may not have this premium service. To do that, we decided to keep to our roots at Elastic and leverage open source datasets to avoid a paywall that could prevent others from using our processes. + +To begin, we started with a handful of [Mozi samples](https://threatfox.abuse.ch/browse.php?search=tag%3Amozi) collected from [ThreatFox](https://threatfox.abuse.ch/). ThreatFox is an open source platform from [Abuse.ch](https://abuse.ch) with the goal of sharing malware indicators with the security research community. + +Using cURL, we queried the ThreatFox API for the Mozi tag. This returned back JSON documents with information about the malware sample, based on the tagged information. + +``` +curl -X POST https://threatfox-api.abuse.ch/api/v1/ -d '{ "query": "taginfo", "tag": "Mozi", "limit": 1 }' +``` + +_Code block 1 - cURL request to ThreatFox API_ + +- -X POST - change the cURL HTTP method from GET (default) to POST as we’re going to be sending data to the ThreatFox API +- `https://threatfox-api.abuse.ch/api/v1/` - this is the ThreatFox API endpoint +- -d - this is denoting that we’re going to be sending data +- query: taginfo - the type of query that we’re making, taginfo in our example +- tag: Mozi - the tag that we’ll be searching for, “Mozi” in our example +- limit: 1 - the number of results to return, 1 result in our example, but you can return up to 1000 results + +This returned the following information: + +``` +{ + "query_status": "ok", + "data": [ + { + "id": "115772", + "ioc": "nnn.nnn.nnn.nnn:53822", + "threat_type": "botnet_cc", + "threat_type_desc": "Indicator that identifies a botnet command&control server (C&C)", + "ioc_type": "ip:port", + "ioc_type_desc": "ip:port combination that is used for botnet Command&control (C&C)", + "malware": "elf.mozi", + "malware_printable": "Mozi", + "malware_alias": null, + "malware_malpedia": "https:\/\/malpedia.caad.fkie.fraunhofer.de\/details\/elf.mozi", + "confidence_level": 75, + "first_seen": "2021-06-15 08:22:52 UTC", + "last_seen": null, + "reference": "https:\/\/bazaar.abuse.ch\/sample\/832fb4090879c1bebe75bea939a9c5724dbf87898febd425f94f7e03ee687d3b\/", + "reporter": "abuse_ch", + "tags": [ + "Mozi" + ] + } + ] +``` + +_Code block 2 - Response from ThreatFox API_ + +Now that we have the file hashes of several samples, we can download the samples using the Malware Bazaar API. Malware Bazaar is another open source platform provided by Abuse.ch. While ThreatFox is used to share contextual information about indicators, Malware Bazaar allows for the actual collection of malware samples (among other capabilities). + +Just like with ThreatFox, we’ll use cURL to interact with the Malware Bazaar API, but this time to download the actual malware samples. Of note, the Malware Bazaar API can be used to search for samples using a tag (“Mozi”, in our example), similar to how we used the ThreatFox API. The difference is that the ThreatFox API returns network indicators that we’ll use later on for data enrichment. + +``` +curl -X POST https://mb-api.abuse.ch/api/v1 -d 'query=get_file&sha256_hash=832fb4090879c1bebe75bea939a9c5724dbf87898febd425f94f7e03ee687d3b' -o 832fb4090879c1bebe75bea939a9c5724dbf87898febd425f94f7e03ee687d3b.raw +``` + +_Code block 3 - cURL request to Malware Bazaar API_ + +- -X POST - change the cURL HTTP method from GET (default) to POST as we’re going to be sending data to the Malware Bazaar API +- `https://mb-api.abuse.ch/api/v1` - this is the Malware Bazaar API endpoint +- -d - this is denoting that we’re going to be sending data +- query: get_file - the type of query that we’re making, get_file in our example +- sha256_hash - the SHA256 hash we’re going to be collecting, “832fb4090879c1bebe75bea939a9c5724dbf87898febd425f94f7e03ee687d3b” in our example +- -o - the file name we’re going to save the binary as + +This will save a file locally named 832fb4090879c1bebe75bea939a9c5724dbf87898febd425f94f7e03ee687d3b.raw. We want to make a raw file that we’ll not modify so that we always have an original sample for archival purposes. This downloads the file as a Zip archive. The passphrase to extract the archive is infected. This will create a local file named 832fb4090879c1bebe75bea939a9c5724dbf87898febd425f94f7e03ee687d3b.elf. Going forward, we’ll use a shorter name for this file, truncated-87d3b.elf, for readability. + +### Unpacking + +Now that we have a few samples to work with we can look at ripping out strings for further analysis. Once in our analysis VM we took a stab at running [Sysinternals Strings](https://docs.microsoft.com/en-us/sysinternals/downloads/strings) over our sample: + +``` +$ strings truncated-87d3b.elf +ELF +*UPX! +ELF +$Bw +(GT +... +``` + +_Code block 3 - Strings output from the packed Mozi sample_ + +Right away we see that we have a [UPX](https://upx.github.io/) packed ELF binary from the “ELF” and “UPX!” text. UPX is a compression tool for executable files, commonly known as “packing”. So the next logical step is to decompress the ELF file with the UPX program. To do that, we’ll run upx with the -d switch. + +``` +$ upx -d truncated-87d3b.elf + Ultimate Packer for eXecutables + Copyright (C) 1996 - 2020 +UPX 3.96w Markus Oberhumer, Laszlo Molnar & John Reiser Jan 23rd 2020 + File size Ratio Format Name + -------------------- ------ ----------- ----------- +upx.exe : upx: truncated-87d3b.elf : CantUnpackException: p_info corrupted +``` + +_Code block 4 - UPX output from corrupted Mozi sample_ + +Another road-block: the p_info section of the file appears to be corrupted. p_info is the sum of two sections from a file, p_blocksize and p_filesize . After a quick search for the error message, we landed on a [CUJOAI Anti-Unpacking blog](https://cujo.com/upx-anti-unpacking-techniques-in-iot-malware/) explaining the header corruptions commonly used in IoT malware to disrupt automated analysis tools. + +Using this information, we cracked open our binary in [xxd](https://linux.die.net/man/1/xxd), a HEX dumper, to see which corruption we were dealing with. As described in the CUJOAI blog, the p_info blocks represent the sum of the p_filesize blocks and the p_blocksize blocks. This section begins with the 8 bytes after the UPX! text, and has been overwritten with zeros (the 8 bytes starting at 0x84 ). + +``` +$ xxd truncated-87d3b.elf +00000000: 7f45 4c46 0101 0161 0000 0000 0000 0000 .ELF...a........ +00000010: 0200 2800 0100 0000 1057 0200 3400 0000 ..(......W..4... +00000020: 0000 0000 0202 0000 3400 2000 0200 2800 ........4. ...(. +00000030: 0000 0000 0100 0000 0000 0000 0080 0000 ................ +00000040: 0080 0000 0de0 0100 0de0 0100 0500 0000 ................ +00000050: 0080 0000 0100 0000 b07a 0000 b0fa 0600 .........z...... +00000060: b0fa 0600 0000 0000 0000 0000 0600 0000 ................ +00000070: 0080 0000 10f1 8f52 5550 5821 1c09 0d17 .......RUPX!.... +00000080: 0000 0000 0000 0000 0000 0000 9400 0000 ................ +00000090: 5e00 0000 0300 0000 f97f 454c 4601 7261 ^.........ELF.ra +000000a0: 000f 0200 28dd 0001 0790 b681 0334 ee07 ....(........4.. +000000b0: ec28 04db 1302 0bfb 2000 031b be0a 0009 .(...... ....... +... +``` + +_Code block 5 - HEX view of the corrupted Mozi sample_ + +The CUJOAI blog states that if you manually update the values of the p_filesize blocks and the p_blocksize blocks with the value of the p_info, this will fix the corruption issue. Below we can see the p_info section in HEX, and we can use that to manually update the p_filesize and p_blocksize sections, which will allow us to unpack the binary (the 4 bytes starting at 0x1e110). + +``` +$ xxd truncated-87d3b.elf +... +0001e0c0: 1914 a614 c998 885d 39ec 4727 1eac 2805 .......]9.G'..(. +0001e0d0: e603 19f6 04d2 0127 52c9 9b60 00be 273e .......'R..`..'> +0001e0e0: c00f 5831 6000 0000 0000 90ff 0000 0000 ..X1`........... +0001e0f0: 5550 5821 0000 0000 5550 5821 0d17 0308 UPX!....UPX!.... +0001e100: 5199 6237 591c 321c d001 0000 b800 0000 Q.b7Y.2......... +0001e110: 7c2a 0400 5000 0011 8000 0000 |*..P....... +``` + +_Code block 6 - p_info HEX data from the corrupted Mozi sample_ + +First, let’s open the file with Vim. As we can see, it is just a UPX file as denoted by the UPX!. + +``` +$ vim truncated-87d3b.elf +^?ELF^A^A^Aa^@^@^@^@^@^@^@^@^B^@(^@^A^@^@^@^PW^B^@4^@^@^@^@^@^@^@^B^B^@^@4^@ ^@^B^@(^@^@^@^@^@^A^@^@^@^@^@^@^@^@<80>^@^@^@<80>^@^@^Mà^A^@^Mà^A^@^E^@^@^@^@<80>^@^@^A^@^@^@°z^@^@°ú^F^@°ú^F^@^@^@^@^@^@^@^@^@^F^@^@^@^@<80>^@^@^Pñ<8f>RUPX!^\ +``` + +_Code block 7 - Corrupted Mozi sample in Vim_ + +Using the xxd plugin for Vim, we can convert this to HEX so that we can make our modifications. This is achieved by typing :%!xxd, which will show us the HEX output for the file. + +``` +00000000: 7f45 4c46 0101 0161 0000 0000 0000 0000 .ELF...a........ +00000010: 0200 2800 0100 0000 1057 0200 3400 0000 ..(......W..4... +00000020: 0000 0000 0202 0000 3400 2000 0200 2800 ........4. ...(. +00000030: 0000 0000 0100 0000 0000 0000 0080 0000 ................ +00000040: 0080 0000 0de0 0100 0de0 0100 0500 0000 ................ +00000050: 0080 0000 0100 0000 b07a 0000 b0fa 0600 .........z...... +00000060: b0fa 0600 0000 0000 0000 0000 0600 0000 ................ +00000070: 0080 0000 10f1 8f52 5550 5821 1c09 0d17 .......RUPX!.... +00000080: 0000 0000 0000 0000 0000 0000 9400 0000 ................ +00000090: 5e00 0000 0300 0000 f97f 454c 4601 7261 ^.........ELF.ra +000000a0: 000f 0200 28dd 0001 0790 b681 0334 ee07 ....(........4.. +000000b0: ec28 04db 1302 0bfb 2000 031b be0a 0009 .(...... ....... +``` + +_Code block 8 - Corrupted Mozi sample in Vim with XXD plugin_ + +Next, we can just update bytes 0x84 - 0x8b(that we identified as having the zero’d out p_filesize and p_blocksize) with the HEX value for p_info (7c2a 0400). + +``` +00000080: 0000 0000 7c2a 0400 7c2a 0400 9400 0000 ....|*..|*...... +``` + +_Code block 9 - Updated p_filesize and p_blocksize HEX values_ + +Let’s reset the file back using :%!xxd -r, save the file and exit Vim (:wq). + +Finally, let’s try to unpack the file now that we’ve manually adjusted the HEX values. + +``` +$ upx -d truncated-87d3b.elf + Ultimate Packer for eXecutables + Copyright (C) 1996 - 2020 +UPX 3.96 Markus Oberhumer, Laszlo Molnar & John Reiser Jan 23rd 2020 + File size Ratio Format Name + -------------------- ------ ----------- ----------- + 273020 <- 123165 45.11% linux/arm truncated-87d3b.elf +Unpacked 1 file. +``` + +_Code block 10 - Successfully unpacked Mozi sample_ + +We now have successfully unpacked the file. Let’s check to see what kind of file this is now by using the file command. + +``` +$ file truncated-87d3b.elf +truncated-87d3b.elf: ELF 32-bit LSB executable, ARM, version 1 (ARM), statically linked, stripped +``` + +_Code block 11 - File type identification of the Mozi sample_ + +Now, we can again use the strings command to see if there is any useful information that we can use (truncated for readability). + +``` +$ strings truncated-87d3b.elf +... +iptables -I OUTPUT -p udp --source-port %d -j ACCEPT +iptables -I PREROUTING -t nat -p udp --destination-port %d -j ACCEPT +iptables -I POSTROUTING -t nat -p udp --source-port %d -j ACCEPT +iptables -I INPUT -p udp --dport %d -j ACCEPT +iptables -I OUTPUT -p udp --sport %d -j ACCEPT +iptables -I PREROUTING -t nat -p udp --dport %d -j ACCEPT +iptables -I POSTROUTING -t nat -p udp --sport %d -j ACCEPT +0.0.0.0 +[idp] +This node doesn't accept announces +v2s +dht.transmissionbt.com:6881 +router.bittorrent.com:6881 +router.utorrent.com:6881 +bttracker.debian.org:6881 +nnn.nnn.nnn.nnn:6881 +abc.abc.abc.abc:6881 +xxx.xxx.xxx.xxx:6881 +yyy.yyy.yyy.yyy:6881 +NfZ +Oo~Mn +g5= +N]% +Range: bytes= +User-Agent: +... +``` + +_Code block 12 - Strings output from the unpacked Mozi sample_ + +Running Strings, we can see, among other things, network indicators and changes to the local firewall, iptables. There is a lot of great information in this file that we can now review which can be used to search for infected devices. + +Next, let’s enrich the ThreatFox data, store it in Elasticsearch, and visualize it with Kibana. + +## Storing threat data in the Elastic Stack + +Looking at what we’ve collected so far, we have rich threat data provided by ThreatFox that includes both network and file information. Additionally, we have actual malware samples collected from Malware Bazaar. Finally, we have performed static file analysis on the malware to identify additional indicators that could be of use. + +For the next steps, we’re going to parse the data from ThreatFox and store that in the Elastic Stack so that we can leverage Kibana to visualize data to identify clusters of activity. + +## Create the Ingest Node Pipeline + +We're going to create an Ingest Node Pipeline to transform the data from ThreatFox into enriched Elasticsearch data. When making a pipeline, it's useful to make a table to lay out what we're going to do. + +| | | +| ---------------------------- | --------------------------------------------------------------- | +| ThreatFox field | ECS-style field | +| id | event.id | +| ioc | threat.indicator.ip and threat.indicator.port | +| threat_type | threat.software.type | +| threat_type_desc | threat.indicator.description | +| ioc_type | threat.indicator.type. Set threat.indicator.type to "ipv4-addr" | +| malware | threat.software.name | +| malware_printable | threat.threatfox.malware_printable | +| malware_alias | threat.software.alias (if non-null) | +| malware_malpedia | threat.software.reference | +| confidence_level | threat.indicator.confidence | +| first_seen | threat.indicator.first_seen | +| last_seen | threat.indicator.last_seen | +| reference | event.reference | +| reporter | event.provider | +| tags | tags | +| `` | threat.indicator.geo. Enriched by our geoip processor. | +| `` | file.hash.sha256 and related.hash | +| `` | related.ip | + +_Table 1 - Elasticsearch Ingest Node Pipeline for ThreatFox data_ + +To create the pipeline, go to **Kibana Stack Management** -> **Ingest Node Pipelines** , then click **Create pipeline**. + +![Figure 1 - Creating Ingest Node Pipeline for ThreatFox data](/assets/images/collecting-and-operationalizing-threat-data-from-the-mozi-botnet/blog-mozi-botnet-1.jpg) + +Next, we’ll give our pipeline a name, optionally a version, and a description. + +From this view you can manually add processors and configure them to your liking. To give you a head start, we've provided the [ThreatFox pipeline definition here](https://github.com/elastic/examples/blob/master/blog/mozin-about/ingest-node-pipeline.json) you can paste in. + +Click **Import processors** and paste the contents of this pipeline definition: [pipeline.json](https://github.com/elastic/examples/blob/master/blog/mozin-about/ingest-node-pipeline.json). + +When you click **Load and overwrite** , you'll have each processor listed there as we've configured it. From here you can tweak it to your needs, or just scroll down and click **Create pipeline**. + +![Figure 2 - Ingest Node Processors for ThreatFox data](/assets/images/collecting-and-operationalizing-threat-data-from-the-mozi-botnet/blog-mozi-botnet-2.jpg) + +Alternatively, if you’d like to use a turnkey approach, the [collection.sh](https://github.com/elastic/examples/blob/master/blog/mozin-about/collection.sh) script will allow you to collect the ThreatFox Mozi data, create the Elasticsearch ingest pipeline, the indicators Index, the Index Pattern, and send the data from ThreatFox directly into Elasticsearch. + +``` +$ git clone https://github.com/elastic/examples +$ cd examples/blog/mozin-about +$ sh collection.sh +``` + +_Code block 13 - Using the Mozi sample collection script_ + +Using the provided collection script, we can see the Threat Fox data is converted into the Elastic Common Schema (ECS) and sent to Elasticsearch for analysis. + +