From 854b382c72bf991d7dae1194cefdaf0cfac7363a Mon Sep 17 00:00:00 2001 From: Tiago Costa Date: Wed, 11 Dec 2024 22:08:54 +0000 Subject: [PATCH 01/12] skip flaky suite (#203632) --- .../trial_license_complete_tier/bootstrap_prebuilt_rules.ts | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/x-pack/test/security_solution_api_integration/test_suites/detections_response/rules_management/prebuilt_rules/management/trial_license_complete_tier/bootstrap_prebuilt_rules.ts b/x-pack/test/security_solution_api_integration/test_suites/detections_response/rules_management/prebuilt_rules/management/trial_license_complete_tier/bootstrap_prebuilt_rules.ts index 97287ef0cdb93..a437561ef0a04 100644 --- a/x-pack/test/security_solution_api_integration/test_suites/detections_response/rules_management/prebuilt_rules/management/trial_license_complete_tier/bootstrap_prebuilt_rules.ts +++ b/x-pack/test/security_solution_api_integration/test_suites/detections_response/rules_management/prebuilt_rules/management/trial_license_complete_tier/bootstrap_prebuilt_rules.ts @@ -18,7 +18,8 @@ export default ({ getService }: FtrProviderContext): void => { const supertest = getService('supertest'); const securitySolutionApi = getService('securitySolutionApi'); - describe('@ess @serverless @skipInServerlessMKI Bootstrap Prebuilt Rules', () => { + // FLAKY: https://github.com/elastic/kibana/issues/203632 + describe.skip('@ess @serverless @skipInServerlessMKI Bootstrap Prebuilt Rules', () => { beforeEach(async () => { await deletePrebuiltRulesFleetPackage(supertest); await deleteEndpointFleetPackage(supertest); From 68dbe2b50939d3dcd36cda79de06b8587373f2a5 Mon Sep 17 00:00:00 2001 From: Tiago Costa Date: Wed, 11 Dec 2024 22:11:43 +0000 Subject: [PATCH 02/12] skip flaky suite (#203916) --- .../test/security_solution_endpoint/apps/integrations/index.ts | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/x-pack/test/security_solution_endpoint/apps/integrations/index.ts b/x-pack/test/security_solution_endpoint/apps/integrations/index.ts index 037ee3d60ec3e..e2f60c3400e98 100644 --- a/x-pack/test/security_solution_endpoint/apps/integrations/index.ts +++ b/x-pack/test/security_solution_endpoint/apps/integrations/index.ts @@ -12,7 +12,8 @@ import { FtrProviderContext } from '../../configs/ftr_provider_context'; export default function (providerContext: FtrProviderContext) { const { loadTestFile, getService, getPageObjects } = providerContext; - describe('integrations', function () { + // FLAKY: https://github.com/elastic/kibana/issues/203916 + describe.skip('integrations', function () { const ingestManager = getService('ingestManager'); const log = getService('log'); const endpointTestResources = getService('endpointTestResources'); From 4cf0aafe58bfca9f94119bebdbc2a53707b9dffb Mon Sep 17 00:00:00 2001 From: Tiago Costa Date: Wed, 11 Dec 2024 22:14:54 +0000 Subject: [PATCH 03/12] skip flaky suite (#180401) --- .../test/security_solution_endpoint/apps/integrations/index.ts | 1 + 1 file changed, 1 insertion(+) diff --git a/x-pack/test/security_solution_endpoint/apps/integrations/index.ts b/x-pack/test/security_solution_endpoint/apps/integrations/index.ts index e2f60c3400e98..5024b6d16739b 100644 --- a/x-pack/test/security_solution_endpoint/apps/integrations/index.ts +++ b/x-pack/test/security_solution_endpoint/apps/integrations/index.ts @@ -13,6 +13,7 @@ export default function (providerContext: FtrProviderContext) { const { loadTestFile, getService, getPageObjects } = providerContext; // FLAKY: https://github.com/elastic/kibana/issues/203916 + // FLAKY: https://github.com/elastic/kibana/issues/180401 describe.skip('integrations', function () { const ingestManager = getService('ingestManager'); const log = getService('log'); From ccb0cba1cb5a11071c4e11f55308c5b04058eca6 Mon Sep 17 00:00:00 2001 From: Tiago Costa Date: Wed, 11 Dec 2024 22:18:21 +0000 Subject: [PATCH 04/12] skip flaky suite (#203906) --- .../response_actions/trial_license_complete_tier/execute.ts | 1 + 1 file changed, 1 insertion(+) diff --git a/x-pack/test/security_solution_api_integration/test_suites/edr_workflows/response_actions/trial_license_complete_tier/execute.ts b/x-pack/test/security_solution_api_integration/test_suites/edr_workflows/response_actions/trial_license_complete_tier/execute.ts index 13afbf6e4551c..7a71ca51bbf59 100644 --- a/x-pack/test/security_solution_api_integration/test_suites/edr_workflows/response_actions/trial_license_complete_tier/execute.ts +++ b/x-pack/test/security_solution_api_integration/test_suites/edr_workflows/response_actions/trial_license_complete_tier/execute.ts @@ -23,6 +23,7 @@ export default function ({ getService }: FtrProviderContext) { const utils = getService('securitySolutionUtils'); // @skipInServerlessMKI - this test uses internal index manipulation in before/after hooks + // FLAKY: https://github.com/elastic/kibana/issues/203906 describe('@ess @serverless @skipInServerlessMKI Endpoint `execute` response action', function () { let indexedData: IndexedHostsAndAlertsResponse; let agentId = ''; From 577ef54b7e16c6b8178bd15088d0e9ceaf4017df Mon Sep 17 00:00:00 2001 From: Tiago Costa Date: Wed, 11 Dec 2024 22:19:18 +0000 Subject: [PATCH 05/12] skip flaky suite (#203908) --- .../trial_license_complete_tier/policy_response.ts | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/x-pack/test/security_solution_api_integration/test_suites/edr_workflows/policy_response/trial_license_complete_tier/policy_response.ts b/x-pack/test/security_solution_api_integration/test_suites/edr_workflows/policy_response/trial_license_complete_tier/policy_response.ts index f3f49ffbc7c1f..3442b3016c57a 100644 --- a/x-pack/test/security_solution_api_integration/test_suites/edr_workflows/policy_response/trial_license_complete_tier/policy_response.ts +++ b/x-pack/test/security_solution_api_integration/test_suites/edr_workflows/policy_response/trial_license_complete_tier/policy_response.ts @@ -13,7 +13,8 @@ export default function ({ getService }: FtrProviderContext) { const utils = getService('securitySolutionUtils'); const endpointTestresources = getService('endpointTestResources'); - describe('@ess @serverless @skipInServerlessMKI Endpoint policy response api', function () { + // FLAKY: https://github.com/elastic/kibana/issues/203908 + describe.skip('@ess @serverless @skipInServerlessMKI Endpoint policy response api', function () { let adminSupertest: TestAgent; before(async () => { From 23c72afd1c86088262b13c7778a8cb05c7b6b55c Mon Sep 17 00:00:00 2001 From: Tiago Costa Date: Wed, 11 Dec 2024 22:20:39 +0000 Subject: [PATCH 06/12] skip flaky suite (#203909) --- .../trial_license_complete_tier/endpoint_authz.ts | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/x-pack/test/security_solution_api_integration/test_suites/edr_workflows/authentication/trial_license_complete_tier/endpoint_authz.ts b/x-pack/test/security_solution_api_integration/test_suites/edr_workflows/authentication/trial_license_complete_tier/endpoint_authz.ts index df2f55ccb8d04..2a89d7aa714ce 100644 --- a/x-pack/test/security_solution_api_integration/test_suites/edr_workflows/authentication/trial_license_complete_tier/endpoint_authz.ts +++ b/x-pack/test/security_solution_api_integration/test_suites/edr_workflows/authentication/trial_license_complete_tier/endpoint_authz.ts @@ -40,7 +40,8 @@ export default function ({ getService }: FtrProviderContext) { } // @skipInServerlessMKI - this test uses internal index manipulation in before/after hooks // @skipInServerlessMKI - if you are removing this annotation, make sure to add the test suite to the MKI pipeline in .buildkite/pipelines/security_solution_quality_gate/mki_periodic/mki_periodic_defend_workflows.yml - describe('@ess @serverless @skipInServerlessMKI When attempting to call an endpoint api', function () { + // FLAKY: https://github.com/elastic/kibana/issues/203909 + describe.skip('@ess @serverless @skipInServerlessMKI When attempting to call an endpoint api', function () { let indexedData: IndexedHostsAndAlertsResponse; let actionId = ''; let agentId = ''; From e88b366c2844cf1a286f61a5f5cbedb65fb896bd Mon Sep 17 00:00:00 2001 From: Tiago Costa Date: Wed, 11 Dec 2024 22:22:04 +0000 Subject: [PATCH 07/12] skip flaky suite (#203910) --- .../authentication/trial_license_complete_tier/endpoint_authz.ts | 1 + 1 file changed, 1 insertion(+) diff --git a/x-pack/test/security_solution_api_integration/test_suites/edr_workflows/authentication/trial_license_complete_tier/endpoint_authz.ts b/x-pack/test/security_solution_api_integration/test_suites/edr_workflows/authentication/trial_license_complete_tier/endpoint_authz.ts index 2a89d7aa714ce..56b3328112e7c 100644 --- a/x-pack/test/security_solution_api_integration/test_suites/edr_workflows/authentication/trial_license_complete_tier/endpoint_authz.ts +++ b/x-pack/test/security_solution_api_integration/test_suites/edr_workflows/authentication/trial_license_complete_tier/endpoint_authz.ts @@ -41,6 +41,7 @@ export default function ({ getService }: FtrProviderContext) { // @skipInServerlessMKI - this test uses internal index manipulation in before/after hooks // @skipInServerlessMKI - if you are removing this annotation, make sure to add the test suite to the MKI pipeline in .buildkite/pipelines/security_solution_quality_gate/mki_periodic/mki_periodic_defend_workflows.yml // FLAKY: https://github.com/elastic/kibana/issues/203909 + // FLAKY: https://github.com/elastic/kibana/issues/203910 describe.skip('@ess @serverless @skipInServerlessMKI When attempting to call an endpoint api', function () { let indexedData: IndexedHostsAndAlertsResponse; let actionId = ''; From ebd415bcf3ffa9e951433cc5d515102d09f66939 Mon Sep 17 00:00:00 2001 From: Tiago Costa Date: Wed, 11 Dec 2024 22:24:41 +0000 Subject: [PATCH 08/12] skip flaky suite (#203893) --- .../spaces/trial_license_complete_tier/space_awareness.ts | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/x-pack/test/security_solution_api_integration/test_suites/edr_workflows/spaces/trial_license_complete_tier/space_awareness.ts b/x-pack/test/security_solution_api_integration/test_suites/edr_workflows/spaces/trial_license_complete_tier/space_awareness.ts index 9c83451111f95..e32e76e6b741e 100644 --- a/x-pack/test/security_solution_api_integration/test_suites/edr_workflows/spaces/trial_license_complete_tier/space_awareness.ts +++ b/x-pack/test/security_solution_api_integration/test_suites/edr_workflows/spaces/trial_license_complete_tier/space_awareness.ts @@ -24,7 +24,8 @@ export default function ({ getService }: FtrProviderContext) { const kbnServer = getService('kibanaServer'); const log = getService('log'); - describe('@ess @serverless @skipInServerlessMKI Endpoint management space awareness support', function () { + // FLAKY: https://github.com/elastic/kibana/issues/203893 + describe.skip('@ess @serverless @skipInServerlessMKI Endpoint management space awareness support', function () { let adminSupertest: TestAgent; let dataSpaceA: Awaited>; let dataSpaceB: Awaited>; From 366c939a97a5b0c1adc7d102657746b55ae2b6ed Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Patryk=20Kopyci=C5=84ski?= Date: Thu, 12 Dec 2024 01:13:45 +0100 Subject: [PATCH 09/12] [Security Gen AI] Update Security Labs content (#203943) ## Summary Updates Security Assistant Security Labs knowledge base to the latest as of Dec 11, 2024 --- .../security_labs/cups_overflow.md | 11 +- .../security_labs/elastic_releases_debmm.md | 8 +- .../elevate_your_threat_hunting.md | 226 ++++++++++ .../exploring_aws_sts_assumeroot.md | 363 +++++++++++++++ .../security_labs/false_file_immutability.md | 50 +-- ...tims_using_defense_evasion_bag_o_tricks.md | 19 +- .../globally_distributed_stealers.md | 2 +- .../inital_research_of_jokerspy.md | 5 - ...0days_insights_and_detection_strategies.md | 4 +- .../security_labs/katz_and_mouse_game.md | 414 ++++++++++++++++++ ...formation_theft_keylogger_protection_jp.md | 2 +- ...ing_security_integrating_amazon_bedrock.md | 237 ++++++++++ .../security_labs/tricks_and_treats.md | 141 ++++++ ...e_around_the_dance_floor_with_pipedance.md | 2 +- 14 files changed, 1438 insertions(+), 46 deletions(-) create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/elevate_your_threat_hunting.md create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/exploring_aws_sts_assumeroot.md create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/katz_and_mouse_game.md create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/streamlining_security_integrating_amazon_bedrock.md create mode 100644 x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/tricks_and_treats.md diff --git a/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/cups_overflow.md b/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/cups_overflow.md index 2be741a88b697..aac67e6329fb8 100644 --- a/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/cups_overflow.md +++ b/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/cups_overflow.md @@ -23,6 +23,15 @@ tags: - CVE-2024-47177 --- +## Update October 2, 2024 + +The following packages introduced out-of-the-box (OOTB) rules to detect the exploitation of these vulnerabilities. Please check your "Prebuilt Security Detection Rules" integration versions or visit the [Downloadable rule updates](https://www.elastic.co/guide/en/security/current/prebuilt-rules-downloadable-updates.html) site. + +- Stack Version 8.15 - Package Version 8.15.6+ +- Stack Version 8.14 - Package Version 8.14.12+ +- Stack Version 8.13 - Package Version 8.13.18+ +- Stack Version 8.12 - Package Version 8.12.23+ + ## Key takeaways * On September 26, 2024, security researcher Simone Margaritelli (@evilsocket) disclosed multiple vulnerabilities affecting the `cups-browsed`, `libscupsfilters`, and `libppd` components of the CUPS printing system, impacting versions \<= 2.0.1. @@ -232,4 +241,4 @@ We expect more to be revealed as the initial disclosure was labeled part 1. Ulti * [https://www.cve.org/CVERecord?id=CVE-2024-47176](https://www.cve.org/CVERecord?id=CVE-2024-47176) * [https://www.cve.org/CVERecord?id=CVE-2024-47177](https://www.cve.org/CVERecord?id=CVE-2024-47177) -*The release and timing of any features or functionality described in this post remain at Elastic's sole discretion. Any features or functionality not currently available may not be delivered on time or at all.* \ No newline at end of file +*The release and timing of any features or functionality described in this post remain at Elastic's sole discretion. Any features or functionality not currently available may not be delivered on time or at all.* diff --git a/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/elastic_releases_debmm.md b/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/elastic_releases_debmm.md index e0348caa59269..883b84f1eb441 100644 --- a/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/elastic_releases_debmm.md +++ b/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/elastic_releases_debmm.md @@ -434,7 +434,7 @@ Covering non-commodity malware (APTs, zero-days, etc.) and emerging threats (new The expert tier focuses on advanced automation, seamless integration with other security tools, and continuous improvement through regular updates and external collaboration. While proactive threat hunting is essential for maintaining a solid security posture, it complements the ruleset management process by identifying new patterns and insights that can be incorporated into detection rules. Teams implement sophisticated automation for rule updates, ensuring continuous integration of advanced detections. At Elastic, our team is constantly refining our rulesets through daily triage, regular updates, and sharing [threat hunt queries](https://github.com/elastic/detection-rules/tree/main/hunting) in our public GitHub repository to help the community improve their detection capabilities. -![DEBMM - Tier 4](/assets/images/elastic-releases-debmm/image7.png "DEBMM - Tier 4") +![DEBMM - Tier 4](/assets/images/elastic-releases-debmm/image1.png "DEBMM - Tier 4") ##### Criteria @@ -480,11 +480,11 @@ Once you understand the DEBMM and its tiers, you can begin applying it to assess The following steps will guide you through the process: -**1. Audit Your Current Maturity Tier**: Evaluate your existing detection rulesets against the criteria outlined in the DEBMM. Identify your rulesets' strengths, weaknesses, and most significant risks to help determine your current maturity tier. For more details, see the [Example Questionnaire](#Example-Questionnaire). +**1. Audit Your Current Maturity Tier:** Evaluate your existing detection rulesets against the criteria outlined in the DEBMM. Identify your rulesets' strengths, weaknesses, and most significant risks to help determine your current maturity tier. For more details, see the [Example Questionnaire](#Example-Questionnaire). -**2. Understand the Scope of Effort: **Recognize the significant and sustained effort required to move from one tier to the next. As teams progress through the tiers, the complexity and depth of activities increase, requiring more resources, advanced skills, and comprehensive strategies. For example, transitioning from Tier 1 to Tier 2 involves systematic rule tuning and detailed gap analysis, while advancing to Tier 3 and Tier 4 requires robust external validation processes, proactive threat hunting, and sophisticated automation. +**2. Understand the Scope of Effort:** Recognize the significant and sustained effort required to move from one tier to the next. As teams progress through the tiers, the complexity and depth of activities increase, requiring more resources, advanced skills, and comprehensive strategies. For example, transitioning from Tier 1 to Tier 2 involves systematic rule tuning and detailed gap analysis, while advancing to Tier 3 and Tier 4 requires robust external validation processes, proactive threat hunting, and sophisticated automation. -**3. Set Goals for Progression: **Define specific goals for advancing to the next tier. Use the qualitative and quantitative measures to set clear objectives for each criterion. +**3. Set Goals for Progression:** Define specific goals for advancing to the next tier. Use the qualitative and quantitative measures to set clear objectives for each criterion. **4. Develop a Roadmap:** Create a detailed plan outlining the actions needed to achieve the goals. Include timelines, resources, and responsible team members. Ensure foundational practices from lower tiers are consistently applied as you progress while identifying opportunities for quick wins or significant impact by first addressing the most critical and riskiest areas for improvement. diff --git a/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/elevate_your_threat_hunting.md b/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/elevate_your_threat_hunting.md new file mode 100644 index 0000000000000..dcf4e4839bbf9 --- /dev/null +++ b/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/elevate_your_threat_hunting.md @@ -0,0 +1,226 @@ +--- +title: "Elevate Your Threat Hunting with Elastic" +slug: "elevate-your-threat-hunting" +date: "2024-10-18" +description: "Elastic is releasing a threat hunting package designed to aid defenders with proactive detection queries to identify actor-agnostic intrusions." +author: + - slug: terrance-dejesus + - slug: mika-ayenson + - slug: samir-bousseaden + - slug: justin-ibarra +image: "elevate-your-threat-hunting.jpg" +category: + - slug: security-operations +tags: + - threat hunting +--- + +We are excited to announce a new resource in the Elastic [Detection Rules](https://github.com/elastic/detection-rules) repository: a collection of hunting queries powered by various Elastic query languages! + +These hunting queries can be found under the [Hunting](https://github.com/elastic/detection-rules/tree/main/hunting) package. This initiative is designed to empower our community with specialized threat hunting queries and resources across multiple platforms, complementing our robust SIEM and EDR ruleset. These are developed to be consistent with the paradigms and methodologies we discuss in the Elastic [Threat Hunting guide](https://www.elastic.co/security/threat-hunting). + +## Why Threat Hunting? + +Threat hunting is a proactive approach to security that involves searching for hidden threats that evade conventional detection solutions while assuming breach. At Elastic, we recognize the importance of threat hunting in strengthening security defenses and are committed to facilitating this critical activity. + +While we commit a substantial amount of time and effort towards building out resilient detections, we understand that alerting on malicious behavior is only one part of an effective overall strategy. Threat hunting moves the needle to the left, allowing for a more proactive approach to understanding and securing the environment. + +The idea is that the rules and hunt queries will supplement each other in many ways. Most hunts also serve as great pivot points once an alert has triggered, as a powerful means to ascertain related details and paint a full picture. They are just as useful when it comes to triaging as proactively hunting. + +Additionally, we often find ourselves writing resilient and robust logic that just doesn’t meet the criteria for a rule, whether it is too noisy or not specific enough. This will serve as an additional means to preserve the value of these research outcomes in the form of these queries. + +## What We Are Providing + +The new Hunting package provides a diverse range of hunting queries targeting all the same environments as our rules do, and potentially even more, including: + +* Endpoints (Windows, Linux, macOS) +* Cloud (CSPs, SaaS providers, etc.) +* Network +* Large Language Models (LLM) +* Any other Elastic [integration](https://www.elastic.co/integrations) or datasource that adds value + +These queries are crafted by our security experts to help you gather initial data that is required to test your hypothesis during your hunts. These queries also include names and descriptions that may be a starting point for your hunting efforts as well. All of this valuable information is then stored in an index file (both YAML and Markdown) for management, ease-of-use and centralizing our collection of hunting queries. + +### Hunting Package + +The Hunting package has also been made to be its own module within Detection Rules with a few simple commands for easy management and searching throughout the catalogue of hunting queries. Our goal is not to provide an out-of-the-box hunting tool, but rather a foundation for programmatically managing and eventually leveraging these hunting queries. + +Existing Commands: + +**Generate Markdown** - Load TOML files or path of choice and convert to Markdown representation in respective locations. +![](/assets/images/elevate-your-threat-hunting/image6.png "") + +**Refresh Index** - Refresh indexes from the collection of queries, both YAML and Markdown. +![](/assets/images/elevate-your-threat-hunting/image4.png "") + +**Search** - Search for hunting queries based on MITRE tactic, technique or subtechnique IDs. Also includes the ability to search per data source. +![](/assets/images/elevate-your-threat-hunting/image5.png "") + +**Run Query** - Run query of choice against a particular stack to identify hits (requires pre-auth). Generates a search link for easy pivot. +![](/assets/images/elevate-your-threat-hunting/image8.png "") + +**View Hunt**- View a hunting file in TOML or JSON format. +![](/assets/images/elevate-your-threat-hunting/image7.png "") + +**Hunt Summary**- Generate count statistics based on breakdown of integration, platform, or language +![](/assets/images/elevate-your-threat-hunting/image2.png "") + +## Benefits of these Hunt Queries + +Each hunting query will be saved in its respective TOML file for programmatic use, but also have a replicated markdown file that serves as a quick reference for manual tasks or review. We understand that while automation is crucial to hunting maturity, often hunters may want a quick and easy copy-paste job to reveal events of interest. Our collection of hunt queries and CLI options offers several advantages to both novice and experienced threat hunters. Each query in the library is designed to serve as a powerful tool for detecting hidden threats, as well as offering additional layers of investigation during incident response. + +* Programmatic and Manual Flexibility: Each query is structured in a standardized TOML format for programmatic use, but also offers a Markdown version for those who prefer manual interaction. +* Scalable queries: Our hunt queries are designed with scalability in mind, leveraging the power of Elastic’s versatile and latest query languages such as ES|QL. This scalability ensures that you can continuously adapt your hunting efforts as your organization’s infrastructure grows, maintaining high levels of visibility and security. +* Integration with Elastic’s Product: These queries integrate with the Elastic Stack and our automation enables you to test quickly, enabling you to pivot through Elastic’s Security UI for deeper analysis. +* Diverse Query Types Available: Out hunt queries support a wide variety of query languages, including KQL, EQL, ES|QL, OsQuery, and YARA, making them adaptable across different data sources and environments. Whether hunting across endpoints, cloud environments, or specific integrations like Okta or LLMs, users can leverage the right language for their unique needs. +* Extended Coverage for Elastic Prebuilt Rules: While Elastic’s prebuilt detection rules offer robust coverage, there are always scenarios where vendor detection logic may not fully meet operational needs due to the specific environment or nature of the threat. These hunting queries help to fill in those gaps by offering broader and more nuanced coveraged, particularly for behaviors that don’t nearly fit into rule-based detections. +* Stepping stone for hunt initialization or pivoting: These queries serve as an initial approach to kickstart investigations or pivot from initial findings. Whether used proactively to identify potential threats or reactively to expand upon triggered alerts, these queries can provide additional context and insights based on threat hunter hypothesis and workflows. +* MITRE ATT&CK Alignment: Every hunt query includes MITRE ATT&CK mappings to provide contextual insight and help prioritize the investigation of threats according to threat behaviors. +* Community and Maintenance: This hunting module lives within the broader Elastic Detection Rules repository, ensuring continual updates alongside our prebuilt rules. Community contributions also enable our users to collaborate and expand unique ways to hunt. + +As we understand the fast-paced nature of hunting and need for automation, we have included searching capabilities and a run option to quickly identify if you have matching results from any hunting queries in this library. + +## Details of Each Hunting Analytic + +Each hunting search query in our repository includes the following details to maximize its effectiveness and ease of use: + +* **Data Source or Integration**: The origin of the data utilized in the hunt. +* **Name**: A descriptive title for the hunting query. +* **Hypothesis**: The underlying assumption or threat scenario the hunt aims to investigate. This is representated as the description. +* **Query(s)**: Provided in one of several formats, including ES|QL, EQL, KQL, or OsQuery. +* **Notes**: Additional information on how to pivot within the data, key indicators to watch for, and other valuable insights. +* **References**: Links to relevant resources and documentation that support the hunt. +* **Mapping to MITRE ATT&CK**: How the hunt correlates to known tactics, techniques, and procedures in the MITRE ATT&CK framework. + +![](/assets/images/elevate-your-threat-hunting/image9.png "") + +For those who prefer a more hands-on approach, we also provide TOML files for programmatic consumption. Additionally, we offer an easy converter to Markdown for users who prefer to manually copy and paste the hunts into their systems. + +### Hunting Query Creation Example: + +In the following example, we will explore a basic hunting cycle for the purpose of creating a new hunting query that we want to use in later hunting cycles. Note that this is an oversimplified hunting cycle that may require several more steps in a real-world application. + +**Hypothesis**: We assume that a threat adversary (TA) is targeting identity providers (IdPs), specifically Okta, by compromising cloud accounts by identifying runtime instances in CI/CD pipelines that use client credentials for authentication with Okta’s API. Their goal is to identify unsecure credentials, take these and obtain an access token whose assumed credentials are tied to an Okta administrator. + +**Evidence**: We suspect that in order to identify evidence of this, we need Okta system logs that report API activity, specifically any public client app sending access token requests where the grant type provided are client credentials. We also suspect that because the TA is unaware of the mapped OAuth scopes for this application, that when the access token request is sent, it may fail due to the incorrect OAuth scopes being explicitly sent. We also know that demonstrating proof-of-possession (DPoP) is not required for our client applications during authentication workflow because doing so would be disruptive to operations so we prioritize operability over security. + +Below is the python code used to emulate the behavior of attempting to get an access token with stolen client credentials where the scope is `okta.trustedOrigins.manage` so the actor can add a new cross-origins (CORS) policy and route client authentication through their own server. + +``` +import requests + +okta_domain = "TARGET_DOMAIN" +client_id = "STOLEN_CLIENT_ID" +client_secret = "STOLEN_CLIENT_CREDENTIALS" + +# Prepare the request +auth_url = f"{okta_domain}/oauth2/default/v1/token" +auth_data = { + "grant_type": "client_credentials", + "scope": "okta.trustedOrigins.manage" +} +auth_headers = { + "Accept": "application/json", + "Content-Type": "application/x-www-form-urlencoded", + "Authorization": f"Basic {client_id}:{client_secret}" +} +# Make the request +response = requests.post(auth_url, headers=auth_headers, data=auth_data) + +# Handle the response +if response.ok: + token = response.json().get("access_token") + print(f"Token: {token}") +else: + print(f"Error: {response.text}") +``` + +Following this behavior, we formulate a query as such for hunting where we filter out some known client applications like DataDog and Elastic’s Okta integrations. + +``` +from logs-okta.system* +| where @timestamp > NOW() - 7 day +| where + event.dataset == "okta.system" + + // filter on failed access token grant requests where source is a public client app + and event.action == "app.oauth2.as.token.grant" + and okta.actor.type == "PublicClientApp" + and okta.outcome.result == "FAILURE" + + // filter out known Elastic and Datadog actors + and not ( + okta.actor.display_name LIKE "Elastic%" + or okta.actor.display_name LIKE "Datadog%" + ) + + // filter for scopes that are not implicitly granted + and okta.outcome.reason == "no_matching_scope" +``` + +As shown below, we identify matching results and begin to pivot and dive deeper into this investigation, eventually involving incident response (IR) and escalating appropriately. + +![](/assets/images/elevate-your-threat-hunting/image10.png "") + +During our after actions report (AAR), we take note of the query that helped identify these compromised credentials and decide to preserve this as a hunting query in our forked Detection Rules repository. It doesn’t quite make sense to create a detection rule based on the fidelity of this and knowing the constant development work we do with custom applications that interact with the Okta APIs, therefore we reserve it as a hunting query. + +Creating a new hunting query TOML file in the `hunting/okta/queries` package, we add the following information: + +``` +author = "EvilC0rp Defenders" +description = """Long Description of Hunt Intentions""" +integration = ["okta"] +uuid = "0b936024-71d9-11ef-a9be-f661ea17fbcc" +name = "Failed OAuth Access Token Retrieval via Public Client App" +language = ["ES|QL"] +license = "Apache License 2.0" +notes = [Array of useful notes from our investigation] +mitre = ['T1550.001'] +query = [Our query as shown above] +``` + +With the file saved we run `python -m hunting generate-markdown FILEPATH` to generate the markdown version of it in `hunting/okta/docs/`. + +![](/assets/images/elevate-your-threat-hunting/image1.png "") + +Once saved, we can view our new hunting content by using the `view-rule` command or search for it by running the `search` command, specifying Okta as the data source and [T1550.001](https://attack.mitre.org/techniques/T1550/001/) as the subtechnique we are looking for. + +![](/assets/images/elevate-your-threat-hunting/image7.png "") + +![](/assets/images/elevate-your-threat-hunting/image5.png "") + +Last but not least, we can check that the query runs successfully by using the `run-query` command as long as we save a `.detection-rules-cfg-yaml` file with our Elasticsearch authentication details, which will tell us if we have matching results or not. + +![](/assets/images/elevate-your-threat-hunting/image8.png "") + +Now we can refresh our hunting indexes with the `refresh-index` command and ensure that our markdown file has been created. + +![](/assets/images/elevate-your-threat-hunting/image11.png "") + +## How We Plan to Expand + +Our aim is to continually enhance the Hunting package with additional queries, covering an even wider array of threat scenarios. We will update this resource based on: + +* **Emerging Threats**: Developing new queries as new types of cyber threats arise. +* **Community Feedbac**k: Incorporating suggestions and improvements proposed by our community. +* **Fill Gaps Where Traditional alerting Fails**: While we understand the power of our advanced SIEM and EDR, we also understand how some situations favor hunting instead. +* **Longevity and Maintenance**: Our hunting package lives within the very same repository we actively manage our out-of-the-box (OOTB) prebuilt detection rules for the Elastic SIEM. As a result, we plan to routinely add and update our hunting resources. +* **New Features**: Develop new features and commands to aid users with the repository of their hunting efforts. + +Our expansion would not be complete without sharing to the rest of the community in an effort to provide value wherever possible. The adoption of these resources or even paradigms surrounding threat scenarios is an important effort by our team to help hunting efforts. + +Lastly, we acknowledge and applaud the existing hunting efforts done or in-progress by our industry peers and community. We also acknowledge that maintaining such a package of hunting analytics and/or queries requires consistency and careful planning. Thus this package will receive continued support and additional hunting queries added over time, often aligning with our detection research efforts or community submissions! + +## Get Involved + +Explore the Hunting resources, utilize the queries and python package, participate in our community discussion forums to share your experiences and contribute to the evolution of this resource. Your feedback is crucial for us to refine and expand our offerings. + +* [Detection Rules Community Slack Channel](https://elasticstack.slack.com/archives/C016E72DWDS) +* Hunting “[Getting Started](https://github.com/elastic/detection-rules/tree/main/hunting)” Doc +* [Elastic Security Labs](https://twitter.com/elasticseclabs) on X + +## Conclusion + +With the expansion of these hunting resources, Elastic reaffirms its commitment to advancing cybersecurity defenses. This resource is designed for both experienced threat hunters and those new to the field, providing the tools needed to detect and mitigate sophisticated cyber threats effectively. + +Stay tuned for more updates, and happy hunting! \ No newline at end of file diff --git a/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/exploring_aws_sts_assumeroot.md b/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/exploring_aws_sts_assumeroot.md new file mode 100644 index 0000000000000..b00b2cc5938a4 --- /dev/null +++ b/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/exploring_aws_sts_assumeroot.md @@ -0,0 +1,363 @@ +--- +title: "Exploring AWS STS AssumeRoot" +subtitle: "AssumeRoot Abuse and Detection Strategies in AWS Organizations" +slug: "exploring-aws-sts-assumeroot" +date: "2024-12-09" +description: "Explore AWS STS AssumeRoot, its risks, detection strategies, and practical scenarios to secure against privilege escalation and account compromise using Elastic's SIEM and CloudTrail data." +author: + - slug: terrance-dejesus +image: "Security Labs Images 20.jpg" +category: + - slug: security-research +--- + +## Preamble + +Welcome to another installment of AWS detection engineering with Elastic. This article will dive into the new AWS [Security Token Service](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html) (STS) API operation, [AssumeRoot](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoot.html), simulate some practical behavior in a sandbox AWS environment, and explore detection capabilities within Elastic’s SIEM. + +What to expect from this article: + +* Basic insight into AWS STS web service +* Insight into STS’ AssumeRoot API operation +* Threat scenario using AssumeRoot with Terraform and Python code +* Detection and hunting opportunities for potential AssumeRoot abuse + +## Understanding AWS STS and the AssumeRoot API + +AWS Security Token Service (STS) is a web service that enables users, accounts, and roles to request temporary, limited-privilege credentials. For IAM users, their accounts are typically registered in AWS Identity and Access Management (IAM), where either a login profile is attached for accessing the console or access keys, and secrets are created for programmatic use by services like Lambda, EC2, and others. + +While IAM credentials are persistent, [**STS credentials**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html#sts-regionalization) are temporary. These credentials \- comprising an access key, secret key, and session token \- are granted upon request and are valid for a specific period. Requests are typically sent to the global `sts.amazonaws.com` endpoint, which responds with temporary credentials for a user or role. These credentials can then be used to access other AWS services on behalf of the specified user or role, as long as the action is explicitly allowed by the associated permission policy. + +This process is commonly known as assuming a role, executed via the [`AssumeRole`](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) API. It is frequently used in AWS environments and organizations for various scenarios. For example: + +* An EC2 instance with an attached role will automatically use `AssumeRole` to retrieve temporary credentials for API requests. +* Similarly, Lambda functions often invoke `AssumeRole` to authenticate and perform their designated actions. + +Although `AssumeRole` is incredibly useful, it can pose a risk if roles are over-permissioned by the organization. Misconfigured policies with excessive permissions can allow adversaries to abuse these roles, especially in environments where the [Principle of Least Privilege](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_permissions_least_privileges.html) (PoLP) is not strictly enforced. Note that the security risks associated with AssumeRole are typically attributed to misconfigurations or not following best security practices by organizations. These are not the result of AssumeRole or even AssumeRoot development decisions. + +### Introduction to AssumeRoot + +AWS recently introduced the `AssumeRoot` API operation to STS. Similar to `AssumeRole`, it allows users to retrieve temporary credentials \- but specifically for the [root user](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html) of a member account in an AWS organization. + +### What Are Member Accounts? + +In AWS, [member accounts](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_access.html) are separate accounts within an organization that have their own IAM users, services, and roles. These accounts are distinct from the management account, but they still fall under the same organizational hierarchy. Each AWS organization is created with a unique root account tied to the email address used during its setup. Similarly, every member account requires a root user or email address at the time of its creation, effectively establishing its own root identity. + +### How Does AssumeRoot Work? + +When a privileged user in the management account needs root-level privileges for a member account, they can use the `AssumeRoot` API to retrieve temporary credentials for the member account's root user. Unlike `AssumeRole`, where the target principal is a user ARN, the target principal for `AssumeRoot` is the member account ID itself. Additionally, a task policy ARN must be specified, which defines the specific permissions allowed with the temporary credentials. + +Here are the available task policy ARNs for `AssumeRoot`: + +* [IAMAuditRootUserCredentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/security-iam-awsmanpol.html#security-iam-awsmanpol-IAMAuditRootUserCredentials) +* [IAMCreateRootUserPassword](https://docs.aws.amazon.com/IAM/latest/UserGuide/security-iam-awsmanpol.html#security-iam-awsmanpol-IAMCreateRootUserPassword) +* [IAMDeleteRootUserCredentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/security-iam-awsmanpol.html#security-iam-awsmanpol-IAMDeleteRootUserCredentials) +* [S3UnlockBucketPolicy](https://docs.aws.amazon.com/IAM/latest/UserGuide/security-iam-awsmanpol.html#security-iam-awsmanpol-S3UnlockBucketPolicy) +* [SQSUnlockQueuePolicy](https://docs.aws.amazon.com/IAM/latest/UserGuide/security-iam-awsmanpol.html#security-iam-awsmanpol-SQSUnlockQueuePolicy) + +### Potential Abuse of Task Policies + +While these predefined task policies limit what can be done with `AssumeRoot`, their scope can still be theoretically abused in the right circumstances. For example: + +* **IAMCreateRootUserPassword**: This policy grants the [`iam:CreateLoginProfile`](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateLoginProfile.html) permission, allowing the creation of a login profile for a user that typically doesn't require console access. If an adversary gains access to programmatic credentials, they could create a login profile and gain console access to the account that is more persistent. +* **IAMDeleteRootUserCredentials**: This policy allows the deletion of root credentials, but also grants permissions like [`iam:ListAccessKeys`](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListAccessKeys.html) and [`iam:ListMFADevices`](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListMFADevices.html). These permissions could help an adversary gather critical information about access credentials or MFA configurations for further exploitation. + +## AssumeRoot in Action + +Now that we understand how AssumeRoot works at a high level, how it differs from AssumeRole, and the potential risks associated with improper security practices, let’s walk through a practical scenario to simulate its usage. It should be noted that this is one of many potential scenarios where AssumeRoot may or could be abused. As of this article's publication, no active abuse has been reported in the wild, as expected with a newer AWS functionality. + +Below is a simple depiction of what we will accomplish in the following sections: + +![AssumeRoot scenario workflow](/assets/images/exploring-aws-sts-assumeroot/image3.png) + +Before diving in, it’s important to highlight that we’re using an admin-level IAM user configured as the default profile for our local AWS CLI. This setup enables us to properly configure the environment using [Terraform](https://developer.hashicorp.com/terraform) and simulate potential threat scenarios in AWS for detection purposes. + +### Member Account Creation + +The first step is to enable centralized root access for member accounts, as outlined in the [AWS documentation](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts.html). Centralized root access allows us to group all AWS accounts into a single organization, with each member account having its own root user. + +Next, we manually create a member account within our organization through the Accounts section in the AWS Management Console. For this scenario, the key requirement is to note the member account ID, a unique 12-digit number. For our example, we’ll assume this ID is `000000000001` and name it *AWSAssumeRoot*. Centralized management of AWS accounts is a common practice for organizations that may separate different operational services into separate AWS accounts but want to maintain centralized management. + +![AWS console showing management account and member account *AWSAssumeRoot*](/assets/images/exploring-aws-sts-assumeroot/image4.png) + +We also add the member account as the [delegated administrator](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_delegate_policies.html) for centralized root access as well, which allows that root member account to have centralized root access for any other member accounts of the organization. + +While we won’t cover it in depth, we have also enabled the new [Resource control policies](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html) (RCPs) within Identity and Access Management (IAM), which will allow central administration over permissions granted to resources within accounts in our organization, but by default, the *RCPFullAWSAccess* policy allows all permissions to all services for all principals and is attached directly to root. + +### Environment Setup + +For our simulation, we use Terraform to create an overly permissive IAM user named compromised\_user. This user is granted the predefined [AdministratorAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AdministratorAccess.html) policy, which provides admin-level privileges. Additionally, we generated an access key for this user while intentionally omitting a login profile to reflect a typical setup where credentials are used programmatically. This is not an uncommon practice, especially in developer environments. + +Below is the `main.tf` configuration used to create the resources: + +``` +provider "aws" { + region = var.region +} + +data "aws_region" "current" {} + +# Create an IAM user with AdministratorAccess (simulated compromised user) +resource "aws_iam_user" "compromised_user" { + name = "CompromisedUser" +} + +# Attach AdministratorAccess Policy to the compromised user +resource "aws_iam_user_policy_attachment" "compromised_user_policy" { + user = aws_iam_user.compromised_user.name + policy_arn = "arn:aws:iam::aws:policy/AdministratorAccess" +} + +# Create access keys for the compromised user +resource "aws_iam_access_key" "compromised_user_key" { + user = aws_iam_user.compromised_user.name +} +``` + +We also define an `outputs.tf` file to capture key details about the environment, such as the region, access credentials, and the user ARN: + +``` +output "aws_region" { + description = "AWS Region where the resources are deployed" + value = var.region +} + +output "compromised_user_access_key" { + value = aws_iam_access_key.compromised_user_key.id + sensitive = true + description = "Access key for the compromised IAM user" +} + +output "compromised_user_secret_key" { + value = aws_iam_access_key.compromised_user_key.secret + sensitive = true + description = "Secret key for the compromised IAM user" +} + +output "compromised_user_name" { + value = aws_iam_user.compromised_user.name + description = "Name of the compromised IAM user" +} + +output "compromised_user_arn" { + value = aws_iam_user.compromised_user.arn + description = "ARN of the compromised IAM user" +} +``` + +Once we run `terraform apply`, the configuration creates a highly permissive IAM user (`compromised_user`) with associated credentials. These credentials simulate those that an adversary might obtain for initial access or escalating privileges. + +This is one of the first hurdles for an adversary, collecting valid credentials. In today’s threat landscape information stealer malware and phishing campaigns are more common than ever, aimed at obtaining credentials that can be sold or used for lateral movement. While this is a hurdle, the probability of compromised credentials for initial access is high \- such as those with [SCATTERED SPIDER](https://www.cisa.gov/sites/default/files/2023-11/aa23-320a_scattered_spider_0.pdf) and [SCARLETEEL](https://sysdig.com/blog/scarleteel-2-0/). + +![](/assets/images/exploring-aws-sts-assumeroot/image1.png) + +### Establish an STS Client Session with Stolen Credentials + +The next step is to establish an STS client session using the compromised credentials (`compromised_user` access key and secret key). This session allows the adversary to make requests to AWS STS on behalf of the compromised user. + +Here’s the Python code to establish the STS client using the [AWS Boto3 SDK](https://aws.amazon.com/sdk-for-python/) (the AWS SDK used to create, configure, and manage AWS services, such as Amazon EC2 and Amazon S3). This Python code is used to create the STS client with stolen IAM user credentials: + +``` + sts_client = boto3.client( + "sts", + aws_access_key_id=compromised_access_key, + aws_secret_access_key=compromised_secret_key, + region_name=region, + endpoint_url=f'https://sts.{region}.amazonaws.com' + ) + ``` + +![Terminal output when creating STS client with stolen IAM user credentials](/assets/images/exploring-aws-sts-assumeroot/image7.png) + +**Note:** During testing, we discovered that the `endpoint_url` must explicitly point to `https://sts..amazonaws.com`. Omitting this may result in an `InvalidOperation` error when attempting to invoke the `AssumeRoot` API. + +This STS client session forms the foundation for simulating an adversary's actions as we have taken compromised credentials and initiated our malicious actions. + +### Assume Root for Member Account on Behalf of Compromised User + +After establishing an STS client session as the compromised user, we can proceed to call the AssumeRoot API. This request allows us to assume the root identity of a member account within an AWS Organization. For the request, the TargetPrincipal is set to the member account ID we obtained earlier, the session duration is set to 900 seconds (15 minutes), and the TaskPolicyArn is defined as `IAMCreateRootUserPassword`. This policy scopes the permissions to actions related to creating or managing root login credentials. + +A notable permission included in this policy is [`CreateLoginProfile`](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateLoginProfile.html), which enables the creation of a login password for the root user. This allows access to the AWS Management Console as the root user. + +Below is the Python code to assume root of member account `000000000001`, with permissions scoped by *IAMCreateRootUserPassword*. + +``` +response = sts_client.assume_root( + TargetPrincipal=member_account_id, + DurationSeconds=900, + TaskPolicyArn={"arn": "arn:aws:iam::aws:policy/root-task/IAMCreateRootUserPassword"}, +) +root_temp_creds = response["Credentials"] +``` + +If the AssumeRoot request is successful, the response provides temporary credentials (`root_temp_creds`) for the root account of the target member. These credentials include an access key, secret key, and session token, enabling temporary root-level access for the duration of the session. + +![Terminal output showing AssumeRoot with IAMCreateRootUserPassword for AWSAssumeRoot member account +](/assets/images/exploring-aws-sts-assumeroot/image6.png) + +### Creating a Login Profile for the Member Root Account + +With temporary root credentials in hand, the next step is to establish an authenticated IAM client session as the root user of the member account. Using this session, we can call the `create_login_profile()` method. This method allows us to assign a login password to the root user, enabling console access. + +The following Python code establishes an authenticated IAM client and creates a login profile: + +``` +iam_client = boto3.client( + "iam", + aws_access_key_id=root_temp_creds["AccessKeyId"], + aws_secret_access_key=root_temp_creds["SecretAccessKey"], + aws_session_token=root_temp_creds["SessionToken"], +) + +response = iam_client.create_login_profile() +``` + +It’s worth noting that the `create_login_profile()` method requires no explicit parameters for the root user, as it acts on the credentials of the currently authenticated session. In this case, it will apply to the root user of the member account. + +![Terminal output showing IAM client established as Root member account and CreateLoginProfile request](/assets/images/exploring-aws-sts-assumeroot/image5.png) + + +### Reset the Administrator Password and Login to the AWS Console + +At this stage, we’re nearly complete\! Let’s recap the progress so far: + +1. Using compromised IAM user credentials, we established an STS session to assume the identity of an overly permissive user. +2. Leveraging this session, we assumed the identity of the root user of a target member account, acquiring temporary credentials scoped to the `IAMCreateRootUserPassword` task policy. +3. With these temporary root credentials, we established an IAM client session and successfully created a login profile for the root user. + +The final step involves resetting the root user password to gain permanent access to the AWS Management Console. To do this, visit the AWS console login page and attempt to log in as the root user. Select the “Forgot Password” option to initiate the password recovery process. This will prompt a CAPTCHA challenge, after which a password reset link is sent to the root user’s email address. This would be the third roadblock for an adversary as they would need access to the root user’s email inbox to continue with the password reset workflow. It should be acknowledged that if *CreateLoginProfile* is called, you can specify the password for the user and enforce a “password reset required”. However, this is not allowed for root accounts by default, and for good reason by AWS. Unlike the first hurdle of having valid credentials, access to a user’s inbox may prove more difficult and less likely, but again, with enough motivation and resources, it is still possible. + +![Password recovery request from AWS sign-in for root](/assets/images/exploring-aws-sts-assumeroot/image2.png) + +After selecting the password reset link, you can set a new password for the root user. This step provides lasting access to the console as the root user. Unlike the temporary credentials obtained earlier, this access is no longer limited by the session duration or scoped permissions of the IAMCreateRootUserPassword policy, granting unrestricted administrative control over the member account. + +![Successful login as root for AWSAssumeRoot member account](/assets/images/exploring-aws-sts-assumeroot/image8.png) + +**Before moving on, if you followed along and tried this in your environment, we want to gently remind you to use Terraform to remove testing resources** using the terraform destroy command in the same folder where you initialized and deployed the resources. + +## Detection and Hunting Opportunities + +While exploring cloud features and APIs from an adversary's perspective is insightful, our ultimate responsibility lies in detecting and mitigating malicious or anomalous behavior, alerting stakeholders, and responding effectively. Also, while such a scenario has not been publicly documented in the wild, we should not wait to be a victim either and be reactive, hence the reason for our whitebox scenario. + +The following detection and hunting queries rely on AWS CloudTrail data ingested into the Elastic Stack using the [AWS integration](https://www.elastic.co/docs/current/integrations/aws). If your environment differs, you may need to adjust these queries for custom ingestion processes or adapt them for a different SIEM or query tool. + +**Note:** Ensure that AWS CloudTrail is enabled for all accounts in your organization to provide comprehensive visibility into activity across your AWS environment. You may also need to enable the specific trail used for monitoring across the entire organization so all member accounts are observed properly. + +### Hunting \- Unusual Action for IAM User Access Key + +This query identifies potentially compromised IAM access keys that are used to make unusual API calls. It sorts the results in ascending order to surface less frequent API calls within the last two weeks. This query can be adjusted to account for different API calls or include other CloudTrail-specific fields. + +Hunting Query: [AWS IAM Unusual AWS Access Key Usage for User](https://github.com/elastic/detection-rules/blob/7b88b36d294407cc1ea2ab1b0acbbbf3104162a9/hunting/aws/docs/iam_unusual_access_key_usage_for_user.md) + +MITRE ATT\&CK: + +* T1078.004 \- [Valid Accounts: Cloud Accounts](https://attack.mitre.org/techniques/T1078/004/) + +Language: ES|QL + +``` +FROM logs-aws.cloudtrail* +| WHERE @timestamp > now() - 14 day +| WHERE + event.dataset == "aws.cloudtrail" + and event.outcome == "success" + and aws.cloudtrail.user_identity.access_key_id IS NOT NULL + and aws.cloudtrail.resources.arn IS NOT NULL + and event.action NOT IN ("GetObject") +| EVAL daily_buckets = DATE_TRUNC(1 days, @timestamp) +| STATS + api_counts = count(*) by daily_buckets, aws.cloudtrail.user_identity.arn, aws.cloudtrail.user_identity.access_key_id, aws.cloudtrail.resources.arn, event.action +| WHERE api_counts < 2 +| SORT api_counts ASC +``` + +### Detection \- Unusual Assume Root Action by Rare IAM User + +Detection Rule: [AWS STS AssumeRoot by Rare User and Member Account](https://github.com/elastic/detection-rules/blob/main/rules/integrations/aws/privilege_escalation_sts_assume_root_from_rare_user_and_member_account.toml) + +This query identifies instances where the `AssumeRoot` API call is made by an IAM user ARN and member account that have not performed this action in the last 14 days. This anomaly-based detection uses Elastic’s [New Terms](https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-new-terms-rule) detection rule. + +* The `aws.cloudtrail.user_identity.arn` field identifies the source IAM user from the management AWS account. +* The `aws.cloudtrail.resources.account_id` field reflects the target member account. + +MITRE ATT\&CK: + +* T1548.005 \- [Temporary Elevated Cloud Access](https://attack.mitre.org/techniques/T1548/005/) +* T1098.003 \- [Additional Cloud Roles](https://attack.mitre.org/techniques/T1098/003/) + +Language: KQL + +``` +event.dataset: "aws.cloudtrail" + and event.provider: "sts.amazonaws.com" + and event.action: "AssumeRoot" + and event.outcome: "success" +``` + +New Term Fields: +If any combination of these fields has not been seen executing AssumeRoot within the last 14 days, an alert is generated. + +* `aws.cloudtrail.user_identity.arn` +* `aws.cloudtrail.resources.account_id` + +### Detection \- Self-Created Login Profile for Root Member Account + +This query detects instances where a login profile is created for a root member account by the root account itself, potentially indicating unauthorized or anomalous behavior. + +Detection Rule: [AWS IAM Login Profile Added for Root](https://github.com/elastic/detection-rules/blob/4374128458d116211d5d22993b6d87f6c82a30a0/rules/integrations/aws/persistence_iam_create_login_profile_for_root.toml) + +MITRE ATT\&CK: + +* T1098.003 \- [Account Manipulation: Additional Cloud Roles](https://attack.mitre.org/techniques/T1098/003/) +* T1548.005 \- [Abuse Elevation Control Mechanism: Temporary Elevated Cloud Access](https://attack.mitre.org/techniques/T1548/005/) +* T1078.004 \- [Valid Accounts: Cloud Accounts](https://attack.mitre.org/techniques/T1078/004/) + +Language: ES|QL + +``` +FROM logs-aws.cloudtrail* +| WHERE + // filter for CloudTrail logs from IAM + event.dataset == "aws.cloudtrail" + and event.provider == "iam.amazonaws.com" + // filter for successful CreateLoginProfile API call + and event.action == "CreateLoginProfile" + and event.outcome == "success" + // filter for Root member account + and aws.cloudtrail.user_identity.type == "Root" + // filter for an access key existing which sources from AssumeRoot + and aws.cloudtrail.user_identity.access_key_id IS NOT NULL + // filter on the request parameters not including UserName which assumes self-assignment + and NOT TO_LOWER(aws.cloudtrail.request_parameters) LIKE "*username*" +| keep + @timestamp, + aws.cloudtrail.request_parameters, + aws.cloudtrail.response_elements, + aws.cloudtrail.user_identity.type, + aws.cloudtrail.user_identity.arn, + aws.cloudtrail.user_identity.access_key_id, + cloud.account.id, + event.action, + source.address + source.geo.continent_name, + source.geo.region_name, + source.geo.city_name, + user_agent.original, + user.id +``` + +These detections are specific to our scenario, however, are not fully inclusive regarding all potential AssumeRoot abuse. If you choose to explore and discover some additional hunting or threat detection opportunities, feel free to share in our [Detection Rules](https://github.com/elastic/detection-rules) repository or the [Threat Hunting](https://github.com/elastic/detection-rules/tree/main/hunting) library of ours. + +## Hardening Practices for AssumeRoot Use + +AWS [documentation](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) contains several important considerations for best security practices regarding IAM, STS, and many other services. However, cloud security is not a “one size fits all” workflow and security practices should be tailored to your environment, risk-tolerance, and more. + +**Visibility is Key:** If you can’t see it, you can’t protect it. Start by enabling CloudTrail with organization-wide trails to log activity across all accounts. Focus on capturing IAM and STS operations for insights into access and permission usage. Pair this with Security Hub for continuous monitoring and tools like Elastic or GuardDuty to hunt for unusual AssumeRoot actions. + +**Lock Down AssumeRoot Permissions:** Scope AssumeRoot usage to critical tasks only, like audits or recovery, by restricting task policies to essentials like IAMAuditRootUserCredentials. Assign these permissions to specific roles in the management account and keep those roles tightly controlled. Regularly review and remove unnecessary permissions to maintain the PLoP. + +**MFA and Guardrails for Root Access:** Enforce MFA for all users, especially those with access to AssumeRoot. Use AWS Organizations to disable root credential recovery unless absolutely needed and remove unused root credentials entirely. RCPs can help centralize and tighten permissions for tasks involving AssumeRoot or other sensitive operations. + +# Conclusion + +We hope this article provides valuable insight into AWS’ AssumeRoot API operation, how it can be abused by adversaries, and some threat detection and hunting guidance. Abusing AssumeRoot is one of many living-off-the-cloud (LotC) techniques that adversaries have the capability to target, but we encourage others to explore, research, and share their findings accordingly with the community and AWS. \ No newline at end of file diff --git a/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/false_file_immutability.md b/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/false_file_immutability.md index 17830f2f3dab7..94d14462751a7 100644 --- a/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/false_file_immutability.md +++ b/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/false_file_immutability.md @@ -11,12 +11,12 @@ category: - slug: vulnerability-updates --- -# Introduction +## Introduction This article will discuss a previously-unnamed vulnerability class in Windows, showing how long-standing incorrect assumptions in the design of core Windows features can result in both undefined behavior and security vulnerabilities. We will demonstrate how one such vulnerability in the Windows 11 kernel can be exploited to achieve arbitrary code execution with kernel privileges. -# Windows file sharing +## Windows file sharing When an application opens a file on Windows, it typically uses some form of the Win32 [**CreateFile**](https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-createfilew) API. @@ -43,7 +43,7 @@ Sharing isn’t mandatory. Callers can pass a share mode of zero to obtain exclu > An open file that is not shared (dwShareMode set to zero) cannot be opened again, either by the application that opened it or by another application, until its handle has been closed. This is also referred to as exclusive access. -## Sharing enforcement +### Sharing enforcement In the kernel, sharing is enforced by filesystem drivers. As a file is opened, it’s the responsibility of the filesystem driver to call [**IoCheckShareAccess**](https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/wdm/nf-wdm-iocheckshareaccess) or [**IoCheckLinkShareAccess**](https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/wdm/nf-wdm-iochecklinkshareaccess) to see whether the requested **DesiredAccess**/**ShareMode** tuple is compatible with any existing handles to the file being opened. [NTFS](https://learn.microsoft.com/en-us/windows-server/storage/file-server/ntfs-overview) is the primary filesystem on Windows, but it’s closed-source, so for illustrative purposes we’ll instead look at Microsoft’s FastFAT sample code performing [the same check](https://github.com/Microsoft/Windows-driver-samples/blob/622212c3fff587f23f6490a9da939fb85968f651/filesys/fastfat/create.c#L6822-L6884). Unlike an IDA decompilation, it even comes with comments! @@ -119,7 +119,7 @@ if (FlagOn(*DesiredAccess, FILE_WRITE_DATA) || DeleteOnClose) { Another way to think of this check is that **ZwMapViewOfSection(SEC_IMAGE)** implies no-write-sharing as long as the view exists. -# Authenticode +## Authenticode The [Windows Authenticode Specification](https://download.microsoft.com/download/9/c/5/9c5b2167-8017-4bae-9fde-d599bac8184a/authenticode_pe.docx) describes a way to employ cryptography to “sign” PE files. A “digital signature” cryptographically attests that the PE was produced by a particular entity. Digital signatures are tamper-evident, meaning that any material modification of signed files should be detectable because the digital signature will no longer match. Digital signatures are typically appended to the end of PE files. @@ -128,7 +128,7 @@ The [Windows Authenticode Specification](https://download.microsoft.com/download Authenticode can’t apply traditional hashing (e.g. **sha256sum**) in this case, because the act of appending the signature would change the file’s hash, breaking the signature it just generated. Instead, the Authenticode specification describes an algorithm to skip specific portions of the PE file that will be changed during the signing process. This algorithm is called **authentihash**. You can use authentihash with any hashing algorithm, such as SHA256. When a PE file is digitally signed, the file’s authentihash is what’s actually signed. -## Code integrity +### Code integrity Windows has a few different ways to validate Authenticode signatures. User mode applications can call [**WinVerifyTrust**](https://learn.microsoft.com/en-us/windows/win32/api/wintrust/nf-wintrust-winverifytrust) to validate a file’s signature in user mode. The Code Integrity (CI) subsystem, residing in ```ci.dll```, validates signatures in the kernel. If [Hypervisor-Protected Code Integrity](https://learn.microsoft.com/en-us/windows-hardware/drivers/bringup/device-guard-and-credential-guard) is running, the Secure Kernel employs ```skci.dll``` to validate Authenticode. This article will focus on Code Integrity (```ci.dll```) in the regular kernel. @@ -148,7 +148,7 @@ User Mode Code Integrity (UMCI): KMCI and UMCI implement different policies for different scenarios. For example, the policy for Protected Processes is different from that of INTEGRITYCHECK. -# Incorrect assumptions +## Incorrect assumptions Microsoft [documentation](https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-createfilea) implies that files successfully opened without write sharing can’t be modified by another user or process. @@ -176,7 +176,7 @@ If those paged-out pages are later touched, the CPU will issue a page fault and Note the following exception: The memory manager may treat PE-relocated pages as unmodified, dynamically reapplying relocations during page faults. -## Page hashes +### Page hashes Page hashes are a list of hashes of each 4KB page within a PE file. Since pages are 4KB, page faults typically occur on 4KB of data at a time. Full Authenticode verification requires the entire contiguous PE file, which isn’t available during a page fault. Page hashes allow the MM to validate hashes of individual pages during page faults. @@ -187,7 +187,7 @@ CI can also compute them on-the-fly during signature validation, a mechanism we Page hashes are not free - they use CPU and slow down page faults. They’re not used in most cases. -# Attacking code integrity +## Attacking code integrity Imagine a scenario where a ransomware operator wants to ransom a hospital, so they send a phishing email to a hospital employee. The employee opens the email attachment and enables macros, running the ransomware. The ransomware employs a UAC bypass to immediately elevate to admin, then attempts to terminate any security software on the system so it can operate unhindered. Anti-Malware services run as [Protected Process Light](https://learn.microsoft.com/en-us/windows/win32/services/protecting-anti-malware-services-) (PPL), protecting them from tampering by malware with admin rights, so the ransomware can’t terminate the Anti-Malware service. @@ -202,7 +202,7 @@ When a network redirector is in use, the server on the other end of the pipe nee An attacker can employ a network redirector to modify a PPL’s DLL server-side, bypassing sharing restrictions. This means that PEs backing an executable image section are incorrectly assumed to be immutable. This is a class of vulnerability that we are calling **False File Immutability** (FFI). -## Paging exploitation +### Paging exploitation If an attacker successfully exploits False File Immutability to inject code into an in-use PE, wouldn’t page hashes catch such an attack? The answer is: sometimes. If we look at the following table, we can see that page hashes are enforced for kernel drivers and Protected Processes, but not for PPL, so let’s pretend we’re an attacker targeting PPL. @@ -219,7 +219,7 @@ Last year at Black Hat Asia 2023 ([abstract](https://www.blackhat.com/asia-23/br Alongside the presentation, we released the [PPLFault exploit](https://github.com/gabriellandau/PPLFault) which demonstrates the vulnerability by dumping the memory of an otherwise-protected PPL. We also released the GodFault exploit chain, which combines the PPLFault Admin-to-PPL exploit with the AngryOrchard PPL-to-kernel exploit to achieve full read/write control of physical memory from user mode. We did this to motivate Microsoft to take action on a vulnerability that MSRC [declined to fix](https://www.elastic.co/security-labs/forget-vulnerable-drivers-admin-is-all-you-need) because it did not meet their [servicing criteria](https://www.microsoft.com/en-us/msrc/windows-security-servicing-criteria). Thankfully, the Windows Defender team at Microsoft stepped up, [releasing a fix](https://x.com/GabrielLandau/status/1757818200127946922) in February 2024 that enforces dynamic page hashes for executable images loaded over network redirectors, breaking PPLFault. -# New research +## New research Above, we discussed Authenticode signatures embedded within PE files. In addition to embedded signatures, Windows supports a form of detached signature called a [security catalog](https://learn.microsoft.com/en-us/windows-hardware/drivers/install/catalog-files). Security catalogs (.cat files) are essentially a list of signed authentihashes. Every PE with an authentihash in that list is considered to be signed by that signer. Windows keeps a large collection of catalog files in ```C:\Windows\System32\CatRoot``` which CI loads, validates, and caches. @@ -240,7 +240,7 @@ Breaking this down, we see a few key insights. First, **ZwCreateSection(SEC_COMM Next, the file is opened without **FILE_SHARE_WRITE**, meaning write sharing is denied. This is intended to prevent modification of the security catalog during processing. However, as we have shown above, this is a bad assumption and another example of False File Immutability. It should be possible, in theory, to perform a PPLFault-style attack on security catalog processing. -## Planning the attack +### Planning the attack ![](/assets/images/false-file-immutability/image11.png) @@ -254,7 +254,7 @@ The general flow of the attack is as follows: 7. CI finds the malicious driver’s authentihash in the catalog and loads the driver. At this point, the attacker has achieved arbitrary code execution in the kernel. -## Implementation and considerations +### Implementation and considerations The plan is to use a PPLFault-style attack, but there are some important differences in this situation. PPLFault used an [opportunistic lock](https://learn.microsoft.com/en-us/windows/win32/fileio/opportunistic-locks) (oplock) to deterministically freeze the victim process’s initialization. This gave the attacker time to switch over to the payload and flush the system working set. Unfortunately, we couldn’t find any good opportunities for oplocks here. Instead, we’re going to pursue a probabilistic approach: rapidly toggling the security catalog between the malicious and benign versions. @@ -279,14 +279,14 @@ The attacker wins if CI validates a benign catalog then parses a malicious one. ![Code Integrity validating a benign catalog, then parsing a malicious one](/assets/images/false-file-immutability/image20.png) -## Exploit demo +### Exploit demo We named the exploit **ItsNotASecurityBoundary** as an homage to MSRC's [policy](https://www.microsoft.com/en-us/msrc/windows-security-servicing-criteria) that "Administrator-to-kernel is not a security boundary.” The code is in GitHub [here](https://github.com/gabriellandau/ItsNotASecurityBoundary). Demo video [here](https://drive.google.com/file/d/13Uw38ZrNeYwfoIuD76qlLgyXP8kRc8Nz/view?usp=sharing). -# Understanding these vulnerabilities +## Understanding these vulnerabilities In order to properly defend against these vulnerabilities, we first need to understand them better. @@ -311,7 +311,7 @@ First, the attacking client sets a packet’s structure’s length field to 16 b Double-read vulnerabilities frequently apply to shared-memory scenarios. They commonly occur in drivers that operate on user-writable buffers. Due to False File Immutability, developers need to be aware that their scope is actually much wider, and includes all files writable by attackers. Denying write sharing does not necessarily prevent file modification. -## Affected Operations +### Affected Operations What types of operations are affected by False File Immutability? @@ -322,7 +322,7 @@ What types of operations are affected by False File Immutability? | Regular I/O | **ReadFile** **ZwReadFile** | 1. Avoid double reads\ 2. Copy the file to a heap buffer before processing | -## What else could be vulnerable? +### What else could be vulnerable? Looking for potentially-vulnerable calls to **ZwMapViewOfSection** in the NT kernel yields quite a few interesting functions: @@ -339,27 +339,27 @@ Looking outside of the NT kernel, we can find other drivers to investigate: ![Potentially-vulnerable uses of **ZwMapViewOfSection** in Windows 11 kernel drivers](/assets/images/false-file-immutability/image1.png) -## Don’t forget about user mode +### Don’t forget about user mode We’ve mostly been discussing the kernel up to this point, but it’s important to note that any user mode application that calls **ReadFile**, **MapViewOfFile**, or **LoadLibrary** on an attacker-controllable file, denying write sharing for immutability, may be vulnerable. Here’s a few hypothetical examples. -### MapViewOfFile +#### MapViewOfFile Imagine an application that is split into two components - a low-privileged worker process with network access, and a privileged service that installs updates. The worker downloads updates and stages them to a specific folder. When the privileged service sees a new update staged, it first validates the signature before installing the update. An attacker could abuse FFI to modify the update after the signature check. -### ReadFile +#### ReadFile Since files are subject to double-read vulnerabilities, anything that parses complex file formats may be vulnerable, including antivirus engines and search indexers. -### LoadLibrary +#### LoadLibrary Some applications rely on UMCI to prevent attackers from loading malicious DLLs into their processes. As we’ve shown with PPLFault, FFI can defeat UMCI. -# Stopping the exploit +## Stopping the exploit Per their official servicing guidelines, MSRC won’t service Admin -> Kernel vulnerabilities by default. In this parlance, servicing means “fix via security update.” This type of vulnerability, however, allows malware to bypass [AV Process Protections](https://learn.microsoft.com/en-us/windows/win32/services/protecting-anti-malware-services-), leaving AV and EDR vulnerable to instant-kill attacks. @@ -376,7 +376,7 @@ As mentioned above in the Affected Operations section, applications can mitigate An alternative mitigation strategy to break these types of exploits is to pin the pages of the file mapping into physical memory using an API such as **MmProbeAndLockPages**. This prevents eviction of those pages when the attacker empties the working set. -## End-user detection and mitigation +### End-user detection and mitigation Fortunately, there is a way for end-users to mitigate this exploit without changes from Microsoft – Hypervisor Protected Code Integrity (HVCI). If HVCI is enabled, CI.dll doesn’t do catalog parsing at all. Instead, it sends the catalog contents to the Secure Kernel, which runs in a separate virtual machine on the same host. The Secure Kernel stores the received catalog contents in its own heap, from which signature validation and parsing are performed. Just like with the **ExAllocatePool** mitigation described above, the exploit is mitigated because file changes have no effect on the heap copy. @@ -387,7 +387,7 @@ The probabilistic nature of this attack means that there are likely many failed ![**Microsoft-Windows-CodeIntegrity/Operational** event log showing an invalid security catalog](/assets/images/false-file-immutability/image4.png) -# Disclosure +## Disclosure The disclosure timeline is as follows: - 2024-02-14: We reported ItsNotASecurityBoundary and FineButWeCanStillEasilyStopIt to MSRC as VULN-119340, suggesting **ExAllocatePool** and **MmProbeAndLockPages** as simple low-risk fixes @@ -397,7 +397,7 @@ The disclosure timeline is as follows: - 2024-06-14: MSRC closed the case, stating "We have completed our investigation and determined that the case doesn't meet our bar for servicing at this time. As a result, we have opened a next-version candidate bug for the issue, and it will be evaluated for upcoming releases. Thanks, again, for sharing this report with us." -# Fixing Code Integrity +## Fixing Code Integrity Looking at the original implementation of **CI!I_MapAndSizeDataFile**, we can see the legacy code calling **ZwCreateSection** and **ZwMapViewOfSection**: @@ -408,7 +408,7 @@ Contrast that with the new **CI!CipMapAndSizeDataFileWithMDL**, which follows th ![The new **CI!CipMapAndSizeDataFileWithMDL** has a mitigation](/assets/images/false-file-immutability/image3.png) -# Summary and conclusion +## Summary and conclusion Today we discussed and named a bug class: **False File Immutability**. We are aware of two public exploits that leverage it, PPLFault and ItsNotASecurityBoundary. diff --git a/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/ghostpulse_haunts_victims_using_defense_evasion_bag_o_tricks.md b/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/ghostpulse_haunts_victims_using_defense_evasion_bag_o_tricks.md index a96832f5de73c..21392357f1322 100644 --- a/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/ghostpulse_haunts_victims_using_defense_evasion_bag_o_tricks.md +++ b/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/ghostpulse_haunts_victims_using_defense_evasion_bag_o_tricks.md @@ -10,8 +10,15 @@ image: "photo-edited-05@2x.jpg" category: - slug: attack-pattern - slug: malware-analysis +tags: + - ghostpulse + - ref8207 --- +## Update + +In October 2024, we released an update to stage 2 of GHOSTPULSE that includes new evasion techniques. You can check it out [here](https://www.elastic.co/security-labs/tricks-and-treats). + ## Preamble Elastic Security Labs has observed a campaign to compromise users with signed [MSIX](https://learn.microsoft.com/en-us/windows/msix/overview) application packages to gain initial access. The campaign leverages a stealthy loader we call GHOSTPULSE which decrypts and injects its final payload to evade detection. @@ -71,7 +78,7 @@ Next, GHOSTPULSE builds an Import Address Table (IAT) incorporating essential AP ![Stage 1 hashing algorithm](/assets/images/ghostpulse-haunts-victims-using-defense-evasion-bag-o-tricks/image13.png) -``` +``` python # Python code used for API hashing def calculate_api_name_hash(api_name): value = 0 @@ -82,7 +89,7 @@ def calculate_api_name_hash(api_name): Below is the Stage 1 IAT structure reconstructed from the GHOSTPULSE malware sample, provided for reference: -``` +``` c struct core_stage1_IAT { void *kernel32_LoadLibraryW; @@ -124,7 +131,7 @@ It then proceeds with its operation by reading and parsing the file named `hando The initial phase involves identifying the commencement of the encrypted data by searching for the IDAT string in the file, which is followed by a distinctive 4-byte tag value. If the tag corresponds to the value stored in the malware's configuration, the malware extracts the bytes of the encrypted blob. The initial structure is as follows: -``` +``` c struct initial_idat_chunk { DWORD size_of_chunk; @@ -145,7 +152,7 @@ struct initial_idat_chunk In the second step, the malware locates the next occurrence of IDAT and proceeds to extract the encrypted chunks that follow it which has the following format: -``` +``` c struct next_idat_chunk { DWORD size_of_chunk; @@ -174,7 +181,7 @@ This technique is known as “module stomping”. The following image shows the Stage 2 initiates by constructing a new IAT structure and utilizing the CRC32 algorithm as the API name hashing mechanism. The following is the IAT structure of stage 2: -``` +``` c struct core_stage2_IAT { void *kernel32_module; @@ -244,7 +251,7 @@ Concerning NT functions, the malware reads the ntdll.dll library from disk and w The following is the structure used by the malware to store NT API offsets: -``` +``` c struct __unaligned __declspec(align(4)) core_stage2_nt_offsets_table { __int64 ntdll_module; diff --git a/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/globally_distributed_stealers.md b/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/globally_distributed_stealers.md index 65a42ae95c13b..5a452164b6a10 100644 --- a/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/globally_distributed_stealers.md +++ b/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/globally_distributed_stealers.md @@ -181,7 +181,7 @@ To fully leverage detection capabilities listed below for these threats with Ela - [Connection to WebService by an Unsigned Binary](https://github.com/elastic/protections-artifacts/blob/main/behavior/rules/command_and_control_connection_to_webservice_by_an_unsigned_binary.toml) - [Connection to WebService by a Signed Binary Proxy](https://github.com/elastic/protections-artifacts/blob/main/behavior/rules/command_and_control_connection_to_webservice_by_a_signed_binary_proxy.toml) - - [Suspicious DNS Query from Mounted Virtual Disk](https://github.com/elastic/endpoint-rules/blob/main/rules/command_and_control_execution_wevsvc_from_virtual_disk.toml) + - [Suspicious DNS Query from Mounted Virtual Disk](https://github.com/elastic/protections-artifacts/blob/main/behavior/rules/windows/command_and_control_suspicious_dns_query_from_mounted_virtual_disk.toml) - [Suspicious Access to Web Browser Credential Stores](https://github.com/elastic/protections-artifacts/blob/main/behavior/rules/credential_access_suspicious_access_to_web_browser_credential_stores.toml) - [Web Browser Credential Access via Unsigned Process](https://github.com/elastic/protections-artifacts/blob/main/behavior/rules/credential_access_web_browser_credential_access_via_unsigned_process.toml) - [Access to Browser Credentials from Suspicious Memory](https://github.com/elastic/protections-artifacts/blob/main/behavior/rules/credential_access_access_to_browser_credentials_from_suspicious_memory.toml) diff --git a/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/inital_research_of_jokerspy.md b/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/inital_research_of_jokerspy.md index 4adcfcecaa03a..12c65e414ddd5 100644 --- a/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/inital_research_of_jokerspy.md +++ b/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/inital_research_of_jokerspy.md @@ -173,11 +173,6 @@ Techniques and Sub techniques represent how an adversary achieves a tactical goa ## Detection logic -### Prevention - -- [Non-Native Dylib Extracted into Suspicious Directory](https://github.com/elastic/endpoint-rules/blob/1006a4d9a3d95e35149a3640fadf68a32c02afa9/rules/execution_dylib_extracted_to_new_directory.toml#L10) -- [Potential Privilege Escalation via TCC bypass with fake TCC.db](https://github.com/elastic/protections-artifacts/blob/main/behavior/rules/privilege_escalation_potential_privilege_escalation_via_tcc_bypass_with_fake_tcc.db.toml) - ### YARA Elastic Security has created YARA rules to identify this activity. Below are YARA rules to identify the JOKERSPY backdoor and SwiftBelt tool. diff --git a/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/itw_windows_lpe_0days_insights_and_detection_strategies.md b/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/itw_windows_lpe_0days_insights_and_detection_strategies.md index 3a0ef112df819..7801e7762e00e 100644 --- a/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/itw_windows_lpe_0days_insights_and_detection_strategies.md +++ b/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/itw_windows_lpe_0days_insights_and_detection_strategies.md @@ -137,7 +137,7 @@ process.name :"dwm.exe" and user.id:S-1-5-90-0-* and ![DWM dropping reflective DLL to disk post exploit execution](/assets/images/itw-windows-lpe-0days-insights-and-detection-strategies/image5.png) -Below is a [detection](https://github.com/elastic/endpoint-rules/blob/20833cbeaac4284ecf9818b44438bda4bc3cae18/rules/privilege_escalation_logonui_dcomp.toml) EQL query that looks for the LogonUI DLL load hijack: +Below is a [detection](https://github.com/elastic/protections-artifacts/blob/main/behavior/rules/windows/privilege_escalation_potential_privilege_escalation_via_logonui.toml) EQL query that looks for the LogonUI DLL load hijack: ``` library where process.executable : "?:\\Windows\\System32\\LogonUI.exe" and @@ -282,7 +282,7 @@ api where process.pid != 4 and process.Ext.api.name : "WriteProcessMemory" process.Ext.api.parameters.address > 281474976710655 ``` -Here is an example of these [alerts](https://github.com/elastic/endpoint-rules/blob/20833cbeaac4284ecf9818b44438bda4bc3cae18/rules/privilege_escalation_api_kernel_address_space.toml) triggering on exploits leveraging this primitive: +Here is an example of these [alerts](https://github.com/elastic/protections-artifacts/blob/main/behavior/rules/windows/privilege_escalation_suspicious_kernel_mode_address_manipulation.tom) triggering on exploits leveraging this primitive: ![Detection of PreviousMode abuse](/assets/images/itw-windows-lpe-0days-insights-and-detection-strategies/image7.png) diff --git a/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/katz_and_mouse_game.md b/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/katz_and_mouse_game.md new file mode 100644 index 0000000000000..b9db8c5a904ad --- /dev/null +++ b/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/katz_and_mouse_game.md @@ -0,0 +1,414 @@ +--- +title: "Katz and Mouse Game: MaaS Infostealers Adapt to Patched Chrome Defenses" +slug: "katz-and-mouse-game" +date: "2024-10-28" +description: "Elastic Security Labs breaks down bypass implementations from the infostealer ecosystem’s reaction to Chrome 127's Application-Bound Encryption scheme." +author: + - slug: jia-yu-chan + - slug: salim-bitam + - slug: daniel-stepanic + - slug: samir-bousseaden + - slug: cyril-francois + - slug: seth-goodwin +image: "Security Labs Images 2.jpg" +category: + - slug: malware-analysis +tags: + - infostealer + - chrome + - cookie + - VIDAR + - STEALC + - LUMMA + - METASTEALER + - PHEMEDRONE + - XENOSTEALER +--- + +# Introduction + +In July, Google [announced](https://security.googleblog.com/2024/07/improving-security-of-chrome-cookies-on.html) a new protection mechanism for cookies stored within Chrome on Windows, known as Application-Bound Encryption. There is no doubt this security implementation has raised the bar and directly impacted the malware ecosystem. After months with this new feature, many infostealers have written new code to bypass this protection (as the Chrome Security Team predicted) in order to stay competitive in the market and deliver capabilities that reliably retrieve cookie data from Chrome browsers. + +Elastic Security Labs has been tracking a subset of this activity, identifying multiple techniques used by different malware families to circumvent App-Bound Encryption. While the ecosystem is still evolving in light of this pressure, our goal is to share technical details that help organizations understand and defend against these techniques. In this article, we will cover the different methods used by the following infostealer families: + + - STEALC/VIDAR + - METASTEALER + - PHEMEDRONE + - XENOSTEALER + - LUMMA + +# Key takeaways + + - Latest versions of infostealers implement bypasses around Google’s recent cookie protection feature using Application-Bound Encryption + - Techniques include integrating offensive security tool ChromeKatz, leveraging COM to interact with Chrome services and decrypt the app-bound encryption key, and using the remote debugging feature within Chrome + - Defenders should actively monitor for different cookie bypass techniques against Chrome on Windows in anticipation of future mitigations and bypasses likely to emerge in the near- to mid-term + - Elastic Security provides mitigations through memory signatures, behavioral rules, and hunting opportunities to enable faster identification and response to infostealer activity + +# Background + +Generically speaking, cookies are used by web applications to store visitor information in the browser the visitor uses to access that web app. This information helps the web app track that user, their preferences, and other information from location to location– even across devices. + +The authentication token is one use of the client-side data storage structures that enables much of how modern web interactivity works. These tokens are stored by the browser after the user has successfully authenticated with a web application. After username and password, after multifactor authentication (MFA) via one-time passcodes or biometrics, the web application “remembers” your browser is you via the exchange of this token with each subsequent web request. + +A malicious actor who gets access to a valid authentication token can reuse it to impersonate the user to that web service with the ability to take over accounts, steal personal or financial information, or perform other actions as that user such as transfer financial assets. + +Cybercriminals use infostealers to steal and commoditize this type of information for their financial gain. + +## Google Chrome Cookie Security + +Legacy versions of Google Chrome on Windows used the Windows native [Data Protection API](https://learn.microsoft.com/en-us/dotnet/standard/security/how-to-use-data-protection) (DPAPI) to encrypt cookies and protect them from other user contexts. This provided adequate protection against several attack scenarios, but any malicious software running in the targeted user’s context could decrypt these cookies using the DPAPI methods directly. Unfortunately, this context is exactly the niche that infostealers often find themselves in after social engineering for initial access. The DPAPI scheme is now [well known to attackers](https://posts.specterops.io/operational-guidance-for-offensive-user-dpapi-abuse-1fb7fac8b107) with several attack vectors; from local decryption using the API, to stealing the masterkey and decrypting remotely, to abusing the domain-wide backup DPAPI key in an enterprise environment. + +With the release of Chrome 127 in July 2024, Google [implemented](https://developer.chrome.com/release-notes/127) Application-Bound Encryption of browser data. This mechanism directly addressed many common DPAPI attacks against Windows Chrome browser data–including cookies. It does this by storing the data in encrypted datafiles, and using a service running as SYSTEM to verify any decryption attempts are coming from the Chrome process before returning the key to that process for decryption of the stored data. + +![Chrome 127 Application-Bound Encryption Scheme. Source: https://security.googleblog.com/2024/07/improving-security-of-chrome-cookies-on.html](/assets/images/katz-and-mouse-game/image5.png) + + + +While it is our view that this encryption scheme is not a panacea to protect all browser data (as the Chrome Security Team acknowledges in their release) we do feel it has been successful in driving malware authors to TTPs that are more overtly malicious, and easier for defenders to identify and respond to. + +# Stealer Bypass Techniques, Summarized + +The following sections will describe specific infostealer techniques used to bypass Google’s App-Bound Encryption feature as observed by Elastic. Although this isn’t an exhaustive compilation of bypasses, and development of these families is ongoing, they represent an interesting dynamic within the infostealer space showing how malware developers responded to Google’s recently updated security control. The techniques observed by our team include: + + - Remote debugging via Chrome’s DevTools Protocol + - Reading process memory of Chrome network service process (ChromeKatz and ```ReadProcessMemory``` (RPM)) + - Elevating to ```SYSTEM``` then decrypting ```app_bound_encryption_key``` with the ```DecryptData``` method of ```GoogleChromeElevationService``` through COM + +![Timeline of events](/assets/images/katz-and-mouse-game/image30.png) + +## STEALC/VIDAR + +Our team observed new code introduced to STEALC/VIDAR related to the cookie bypass technique around September 20th. These were atypical samples that stood out from previous versions and were implemented as embedded 64-bit PE files along with conditional checks. Encrypted values in the SQLite databases where Chrome stores its data are now prefixed with v20, indicating that the values are now encrypted using application-bound encryption. + +> [STEALC](https://malpedia.caad.fkie.fraunhofer.de/details/win.stealc) was introduced in 2023 and was developed with “heavy inspiration” from other more established stealers such as [RACOON](https://malpedia.caad.fkie.fraunhofer.de/details/win.raccoon) and [VIDAR](https://malpedia.caad.fkie.fraunhofer.de/details/win.vidar). STEALC and VIDAR have continued concurrent development, and in the case of App-Bound Encryption bypasses have settled on the same implementation. + +During the extraction of encrypted data from the databases the malware checks for this prefix. If it begins with ```v20```, a child process is spawned using the embedded PE file in the ```.data``` section of the binary. This program is responsible for extracting unencrypted cookie values residing in one of Chrome's child processes. + +![Embedded PE file](/assets/images/katz-and-mouse-game/image2.png) + +This embedded binary creates a hidden desktop via ```OpenDesktopA``` / ```CreateDesktopA``` then uses ```CreateToolhelp32Snapshot``` to scan and terminate all ```chrome.exe``` processes. A new ```chrome.exe``` process is then started with the new desktop object. Based on the installed version of Chrome, the malware selects a signature pattern for the Chromium feature [CookieMonster](https://www.chromium.org/developers/design-documents/network-stack/cookiemonster/), an internal component used to manage cookies. + +![Signature pattern for ```CookieMonster```](/assets/images/katz-and-mouse-game/image38.png) + +We used the [signature patterns](https://github.com/Meckazin/ChromeKatz/blob/9152004174e9a0b2d092c70ebc75efbf80fa1098/CookieKatz/Main.cpp#L123) to pivot to existing code developed for an offensive security tool called [ChromeKatz](https://github.com/Meckazin/ChromeKatz). At this time, the patterns have been removed from the ChromeKatz repository and replaced with a new technique. Based on our analysis, the malware author appears to have reimplemented ChromeKatz within STEALC in order to bypass the app-bound encryption protection feature. + +Once the malware identifies a matching signature, it enumerates Chrome’s child processes to check for the presence of the ```--utility-sub-type=network.mojom.NetworkService``` command-line flag. This flag indicates that the process is the network service responsible for handling all internet communication. It becomes a prime target as it holds the sensitive data the attacker seeks, as described in MDSec’s [post](https://www.mdsec.co.uk/2021/01/breaking-the-browser-a-tale-of-ipc-credentials-and-backdoors/). It then returns a handle for that specific child process. + +![Enumerating for Chrome’s network service](/assets/images/katz-and-mouse-game/image37.png) + +Next, it enumerates each module in the network service child process to find and retrieve the base address and size of ```chrome.dll``` loaded into memory. STEALC uses [```CredentialKatz::FindDllPattern```](https://github.com/Meckazin/ChromeKatz/blob/767047dcf8f53c70be5e3e0859c5eee3f129d758/CredentialKatz/Memory.cpp#L280) and [```CookieKatz::FindPattern```](https://github.com/Meckazin/ChromeKatz/blob/767047dcf8f53c70be5e3e0859c5eee3f129d758/CookieKatz/Memory.cpp#L435) to locate the CookieMonster instances. There are 2 calls to ```CredentialKatz::FindDllPattern```. + +![Calls to ```CredentialKatz::FindDllPattern```](/assets/images/katz-and-mouse-game/image17.png) + +In the first call to ```CredentialKatz::FindDllPattern```, it tries to locate one of the signature patterns (depending on the victim’s Chrome version) in ```chrome.dll```. Once found, STEALC now has a reference pointer to that memory location where the byte sequence begins which is the function ```net::CookieMonster::~CookieMonster```, destructor of the ```CookieMonster``` class. + +![Byte sequence for ```net::CookieMonster::~CookieMonster``` found in ```chrome.dll```](/assets/images/katz-and-mouse-game/image14.png) + +The second call to ```CredentialKatz::FindDllPattern``` passes in the function address for ```net::CookieMonster::~CookieMonster(void)``` as an argument for the byte sequence search, resulting in STEALC having a pointer to ```CookieMonster```’s Virtual Function Pointer struct. + +![```CookieMonster```’s vtable in ```chrome.dll```](/assets/images/katz-and-mouse-game/image19.png) + +The following method used by STEALC is again, identical to ChromeKatz, where it locates ```CookieMonster``` instances by scanning memory chunks in the ```chrome.dll``` module for pointers referencing the ```CookieMonster``` vtable. Since the vtable is a constant across all objects of a given class, any ```CookieMonster``` object will have the same vtable pointer. When a match is identified, STEALC treats the memory location as a ```CookieMonster``` instance and stores its address in an array. + +![Using ```CookieKatz::FindPattern``` to locate ```CookieMonster``` instances](/assets/images/katz-and-mouse-game/image16.png) + +For each identified ```CookieMonster``` instance, STEALC accesses the internal ```CookieMap``` structure located at an offset of ```+0x30```, and which is a binary tree. Each node within this tree contains pointers to ```CanonicalCookieChrome``` structures. ```CanonicalCookieChrome``` structures hold unencrypted cookie data, making it accessible for extraction. STEALC then initiates a tree traversal by passing the first node into a dedicated traversal function. + +![Initiating ```CookieMap``` tree traversal for each ```CookieMonster``` instance found](/assets/images/katz-and-mouse-game/image20.png) + +For each node, it calls ```ReadProcessMemory``` to access the ```CanonicalCookieChrome``` structure from the target process’s memory, then further processing it in ```jy::GenerateExfilString```. + +![```CookieMap``` traversal subroutine](/assets/images/katz-and-mouse-game/image31.png) + +STEALC formats the extracted cookie data by converting the expiration date to UNIX format and verifying the presence of the ```HttpOnly``` and ```Secure``` flags. It then appends details such as the cookie's name, value, domain, path, and the ```HttpOnly``` and ```Secure``` into a final string for exfiltration. [```OptimizedString```](https://github.com/Meckazin/ChromeKatz/blob/9152004174e9a0b2d092c70ebc75efbf80fa1098/CookieKatz/Memory.cpp#L10) structs are used in place of strings, so string values can either be the string itself, or if the string length is greater than 23, it will point to the address storing the string. + +![Constructing string for data exfiltration](/assets/images/katz-and-mouse-game/image23.png) + +## METASTEALER + +[METASTEALER](https://malpedia.caad.fkie.fraunhofer.de/details/win.metastealer), first observed in 2022, recently upgraded its ability to steal Chrome data, bypassing Google’s latest mitigation efforts. On September 30th, the malware authors announced this update via their Telegram channel, highlighting its enhanced capability to extract sensitive information, including cookies, despite the security changes in Chrome's version ```129+```. + +![METASTEALER announcement and translation](/assets/images/katz-and-mouse-game/image26.png) + +![source: https://x.com/g0njxa/status/1840761619686568319/](/assets/images/katz-and-mouse-game/image28.png) + +The [first sample](https://www.virustotal.com/gui/file/973a9056040af402d6f92f436a287ea164fae09c263f80aba0b8d5366ed9957a) observed in the wild by our team was discovered on September 30th, the same day the authors promoted the update. Despite claims that the malware operates without needing ```Administrator``` privileges, our testing revealed it does require elevated access, as it attempts to impersonate the ```SYSTEM``` token during execution. + +![Code comparison between an old and a new version of the family](/assets/images/katz-and-mouse-game/image11.png) + +As shown in the screenshots above, the ```get_decryption``` method now includes a new Boolean parameter. This value is set to ```TRUE``` if the encrypted data (cookie) begins with the ```v20``` prefix, indicating that the cookie is encrypted using Chrome's latest encryption method. The updated function retains backward compatibility, still supporting the decryption of cookies from older Chrome versions if present on the infected machine. + +The malware then attempts to access the ```Local State``` or ```LocalPrefs.json``` files located in the Chrome profile directory. Both files are JSON formatted and store encryption keys (```encrypted_key```) for older Chrome versions and ```app_bound_encrypted_key``` for newer ones. If the flag is set to ```TRUE```, the malware specifically uses the ```app_bound_encrypted_key``` to decrypt cookies in line with the updated Chrome encryption method. + +![```app_bound_encrypted_key``` extracted from Chrome json file](/assets/images/katz-and-mouse-game/image13.png) + +In this case, the malware first impersonates the ```SYSTEM``` token using a newly introduced class called ```ContextSwitcher```. + +![New class for TOKEN impersonation](/assets/images/katz-and-mouse-game/image35.png) + +It then decrypts the key by creating an instance via the COM of the Chrome service responsible for decryption, named ```GoogleChromeElevationService```, using the CLSID ```708860E0-F641-4611-8895-7D867DD3675B```. Once initialized, it invokes the [```DecryptData```](https://github.com/chromium/chromium/blob/225f82f8025e4f93981310fd33daa71dc972bfa9/chrome/elevation_service/elevator.cc#L155) method to decrypt the ```app_bound_encrypted_key``` key which will be used to decrypt the encrypted cookies. + +![New class ```ComInvoker``` to invoke methods from ```GoogleChromeElevationService``` service](/assets/images/katz-and-mouse-game/image8.png) + +METASTEALER employs a technique similar to the one demonstrated in a [gist](https://gist.github.com/snovvcrash/caded55a318bbefcb6cc9ee30e82f824) shared [on X](https://x.com/snovvcrash/status/1839715912812802162) on September 27th, which may have served as inspiration for the malware authors. Both approaches leverage similar methods to bypass Chrome's encryption mechanisms and extract sensitive data. + +## PHEMEDRONE + +This [open-source stealer](https://malpedia.caad.fkie.fraunhofer.de/details/win.phemedrone_stealer) caught the world’s attention earlier in the year through its usage of a Windows SmartScreen vulnerability (CVE-2023-36025). While its development is still occurring on Telegram, our team found a recent [release](https://www.virustotal.com/gui/file/1067d27007ea862ddd68e90ef68b6d17fa18f9305c09f72bad04d00102a60b8c) (2.3.2) submitted at the end of September including new cookie grabber functionality for Chrome. + +![```README.txt``` within PHEMEDRONE project](/assets/images/katz-and-mouse-game/image10.png) + +The malware first enumerates the different profiles within Chrome, then performs a browser check using function (```BrowserHelpers.NewEncryption```) checking for the Chrome browser with a version greater than or equal to ```127```. + +![Chrome version verification in PHEMEDRONE](/assets/images/katz-and-mouse-game/image27.png) + +If the condition matches, PHEMEDRONE uses a combination of helper functions to extract the cookies. + +![High-level functions used cookie extraction in PHEMEDRONE](/assets/images/katz-and-mouse-game/image34.png) + +By viewing the ```ChromeDevToolsWrapper``` class and its different functions, we can see that PHEMEDRONE sets up a remote debugging session within Chrome to access the cookies. The default port (```9222```) is used along with window-position set to ```-2400```,```-2400``` which is set off-screen preventing any visible window from alerting the victim. + +![New Chrome process in remote debug mode](/assets/images/katz-and-mouse-game/image15.png) + +Next, the malware establishes a WebSocket connection to Chrome’s debugging interface making a request using deprecated Chrome DevTools Protocol method (```Network.getAllCookies```). + +![Chrome DevTools Protocol used to retrieve cookies](/assets/images/katz-and-mouse-game/image24.png) + +The cookies are then returned from the previous request in plaintext, below is a network capture showing this behavior: + +![Cookie data within network capture](/assets/images/katz-and-mouse-game/image32.png) + +## XENOSTEALER + +[XENOSTEALER](https://github.com/moom825/XenoStealer/) is an open-source infostealer hosted on GitHub. It appeared in July 2024 and is under active development at the time of this publication. Notably, the Chrome bypass feature was committed on September 26, 2024. + +The approach taken by XENOSTEALER is similar to that of METASTEALER. It first parses the JSON file under a given Chrome profile to extract the ```app_bound_encrypted_key```. However, the decryption process occurs within a Chrome process. To achieve this, XENOSTEALER launches an instance of ```Chrome.exe```, then injects code using a helper class called [```SharpInjector```](https://github.com/moom825/XenoStealer/blob/d1c7e242183a2c8582c179a1b546f0a5cdff5f75/XenoStealer/Injector/SharpInjector.cs), passing the encrypted key as a parameter. + +The injected code subsequently calls the ```DecryptData``` method from the ```GoogleChromeElevationService``` to obtain the decrypted key. + +![Source code of the injected code](/assets/images/katz-and-mouse-game/image29.png) + +## LUMMA + +In mid-October, the latest version of [LUMMA](https://malpedia.caad.fkie.fraunhofer.de/details/win.lumma) implemented a new method to bypass Chrome cookie protection, as reported by [@g0njxa](https://x.com/g0njxa). + +![](/assets/images/katz-and-mouse-game/image40.png) + +We analyzed a recent version of LUMMA, confirming that it managed to successfully recover the cookie data from the latest version of Google Chrome (```130.0.6723.70```). LUMMA first creates a visible Chrome process via ```Kernel32!CreateProcessW```. + +![Dump of ```CreateProcessW lpApplicationName``` parameter](/assets/images/katz-and-mouse-game/image3.png) + +This activity was followed up in the debugger with multiple calls to ```NtReadVirtualMemory``` where we identified LUMMA searching within the Chrome process for ```chrome.dll```. + +![LUMMA seeks ```chrome.dll``` in Chrome](/assets/images/katz-and-mouse-game/image7.png) + +Once found, the malware copies the ```chrome.dll``` image to its own process memory using ```NtReadVirtualMemory```. In a similar fashion to the ChromeKatz technique, Lumma leverages pattern scanning to target Chrome’s ```CookieMonster``` component. + +![Lumma’s pattern scanning](/assets/images/katz-and-mouse-game/image36.png) + +Lumma uses an obfuscated signature pattern to pinpoint the ```CookieMonster``` functionality: + +``` +3Rf5Zn7oFA2a????k4fAsdxx????l8xX5vJnm47AUJ8uXUv2bA0s34S6AfFA????kdamAY3?PdE????6G????L8v6D8MJ4uq????k70a?oAj7a3????????K3smA????maSd?3l4 +``` + +Below is the YARA rule after de-obfuscation: + +``` +rule lumma_stealer +{ + meta: + author = "Elastic Security Labs" + strings: + $lumma_pattern = { 56 57 48 83 EC 28 89 D7 48 89 CE E8 ?? ?? ?? ?? 85 FF 74 08 48 89 F1 E8 ?? ?? ?? ?? 48 89 F0 48 83 C4 28 5F 5E C3 CC CC CC CC CC CC CC CC CC CC 56 57 48 83 EC 38 48 89 CE 48 8B 05 ?? ?? ?? ?? 48 31 E0 48 89 44 24 ?? 48 8D 79 ?? ?? ?? ?? 28 E8 ?? ?? ?? ?? 48 8B 46 20 48 8B 4E 28 48 8B 96 ?? ?? ?? ?? 4C 8D 44 24 ?? 49 89 10 48 C7 86 ?? ?? ?? ?? ?? ?? ?? ?? 48 89 FA FF 15 ?? ?? ?? ?? 48 8B 4C 24 ?? 48 31 E1} + condition: + all of them +} +``` + +After decoding and searching for the pattern in ```chrome.dll```, this leads to the ```CookieMonster``` destructor ([```net::CookieMonster::~CookieMonster```](https://chromium.googlesource.com/chromium/src/net/+/master/cookies/cookie_monster.cc#657)). + +![Lumma pattern match on ```CookieMonster```](/assets/images/katz-and-mouse-game/image25.png) + +The cookies are then identified in memory and dumped out in clear text from the Chrome process. + +![LUMMA dumping the cookie in clear text from Chrome](/assets/images/katz-and-mouse-game/image21.png) + +Once completed, LUMMA sends out the cookies along with the other requested data as multiple zip files (xor encrypted and base64 encoded) to the C2 server. + +![Received stolen cookies on the C2 side](/assets/images/katz-and-mouse-game/image12.png) + +# Detection + +Below are the following behavioral detections that can be used to identify techniques used by information stealers: + + - [Web Browser Credential Access via Unusual Process](https://github.com/elastic/protections-artifacts/blob/da25aa57994ee265583227dbe6fe02261b65415c/behavior/rules/windows/credential_access_web_browser_credential_access_via_unusual_process.toml#L8) + - [Web Browser Credential Access via Unsigned Process](https://github.com/elastic/protections-artifacts/blob/da25aa57994ee265583227dbe6fe02261b65415c/behavior/rules/windows/credential_access_web_browser_credential_access_via_unsigned_process.toml#L8) + - [Access to Browser Credentials from Suspicious Memory](https://github.com/elastic/protections-artifacts/blob/da25aa57994ee265583227dbe6fe02261b65415c/behavior/rules/windows/credential_access_access_to_browser_credentials_from_suspicious_memory.toml#L8) + - [Failed Access Attempt to Web Browser Files](https://github.com/elastic/protections-artifacts/blob/da25aa57994ee265583227dbe6fe02261b65415c/behavior/rules/windows/credential_access_failed_access_attempt_to_web_browser_files.toml#L8) + - [Browser Debugging from Unusual Parent](https://github.com/elastic/protections-artifacts/blob/da25aa57994ee265583227dbe6fe02261b65415c/behavior/rules/windows/credential_access_browser_debugging_from_unusual_parent.toml#L3) + - [Potential Browser Information Discovery](https://github.com/elastic/protections-artifacts/blob/da25aa57994ee265583227dbe6fe02261b65415c/behavior/rules/windows/discovery_potential_browser_information_discovery.toml#L8) + +Additionally, the following queries can be used for hunting diverse related abnormal behaviors: + +## Cookies access by an unusual process + +This query uses file open events and aggregate accesses by process, then looks for ones that are observed in unique hosts and with a low total access count: + +``` sql +FROM logs-endpoint.events.file-default* +| where event.category == "file" and event.action == "open" and file.name == "Cookies" and file.path like "*Chrome*" +| keep file.path, process.executable, agent.id +| eval process_path = replace(to_lower(process.executable), """c:\\users\\[a-zA-Z0-9\.\-\_\$]+\\""", "c:\\\\users\\\\user\\\\") +| stats agents_count = COUNT_DISTINCT(agent.id), access_count= count(*) by process_path +| where agents_count <= 2 and access_count <=2 +``` + +Below example of matches from diverse information stealers including the updated ones with new Chrome cookies stealing capabilities: + +![ES|QL query results for suspicious browser cookies file access](/assets/images/katz-and-mouse-game/image22.png) + +METASTEALER behavior tends to first terminate all running chrome instances then calls [```CoCreateInstance```](https://learn.microsoft.com/en-us/windows/win32/api/combaseapi/nf-combaseapi-cocreateinstance) to instantiate the Google Chrome [elevation service](https://chromium.googlesource.com/chromium/src/+/main/chrome/elevation_service/), this series of events can be expressed with the following EQL query: + +``` sql +sequence by host.id with maxspan=1s +[process where event.action == "end" and process.name == "chrome.exe"] with runs=5 +[process where event.action == "start" and process.name == "elevation_service.exe"] +``` + +![EQL query results for suspicious browser termination](/assets/images/katz-and-mouse-game/image4.png) + +The previous hunt indicates suspicious agents but doesn't identify the source process. By [enabling registry object access auditing through event 4663](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4663) on the Chrome Elevation service CLSID registry key ```{708860E0-F641-4611-8895-7D867DD3675B}```, we can detect unusual processes attempting to access that key: + +![Google Chrome Elevation COM registry access](/assets/images/katz-and-mouse-game/image9.png) + +``` sql +FROM logs-system.security-default* | where event.code == "4663" and winlog.event_data.ObjectName == "\\REGISTRY\\MACHINE\\SOFTWARE\\Classes\\CLSID\\{708860E0-F641-4611-8895-7D867DD3675B}" and not winlog.event_data.ProcessName in ("C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe", "C:\\Program Files (x86)\\Google\\Chrome\\Application\\chrome.exe") and not winlog.event_data.ProcessName like "C:\\\\Program Files\\\\Google\\\\Chrome\\\\Application\\\\*\\\\elevation_service.exe" | stats agents_count = COUNT_DISTINCT(agent.id), access_count= count(*) by winlog.event_data.ProcessName | where agents_count <= 2 and access_count <=2 +``` + +Below is an example of matches on the METASTEALER malware while calling ```CoCreateInstance (CLSID_Elevator)```: + +![ES|QL query results for suspicious access to chrome elevation service registry](/assets/images/katz-and-mouse-game/image39.png) + +The [PHEMEDRONE](https://malpedia.caad.fkie.fraunhofer.de/details/win.phemedrone_stealer) stealer uses the [known](https://posts.specterops.io/hands-in-the-cookie-jar-dumping-cookies-with-chromiums-remote-debugger-port-34c4f468844e) browser debugging method to collect cookies via Chromium API, this can be observed in the following screenshot where we can see an instance of NodeJs communicating with a browser instance with debugging enabled over port ```9222```: + +![PHEMEDRONE - network connection to chrome over port ```9222```](/assets/images/katz-and-mouse-game/image33.png) + +The following EQL query can be used to look for unusual processes performing similar behavior: + +``` sql +sequence by host.id, destination.port with maxspan=5s +[network where event.action == "disconnect_received" and + network.direction == "ingress" and + process.executable in~ ("C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe", +"C:\\Program Files\\Microsoft\\Edge\\Application\\msedge.exe") and + source.address like "127.*" and destination.address like "127.*"] +[network where event.action == "disconnect_received" and network.direction == "egress" and not + process.executable in~ ("C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe", +"C:\\Program Files\\Microsoft\\Edge\\Application\\msedge.exe") and source.address like "127.*" and destination.address like "127.*"] +``` + +![EQL query results for browser debugging activity](/assets/images/katz-and-mouse-game/image1.png) + +## Chrome Browser Spawned from an Unusual Parent + +The STEALC sample that uses ChromeKatz implementation spawns an instance of Google Chrome to load the user default profile, while looking for normal parent executables, it turns out it’s limited to Chrome signed parents and Explorer.exe, the following ES|QL query can be used to find unusual parents: + +``` sql +FROM logs-endpoint.events.process-* +| where event.category == "process" and event.type == "start" and to_lower(process.name) == "chrome.exe" and process.command_line like "*--profile-directory=Default*" +| eval process_parent_path = replace(to_lower(process.parent.executable), """c:\\users\\[a-zA-Z0-9\.\-\_\$]+\\""", "c:\\\\users\\\\user\\\\") +| stats agents_count = COUNT_DISTINCT(agent.id), total_executions = count(*) by process_parent_path +| where agents_count == 1 and total_executions <= 10 +``` + +![ES|QL query results for chrome browser spawned from an unusual parent](/assets/images/katz-and-mouse-game/image18.png) + +## Untrusted Binaries from Chrome Application folder + +Since the Chrome elevation service [trusts](https://github.com/chromium/chromium/blob/main/chrome/elevation_service/caller_validation.cc#L33-L56) binaries running from the Chrome ```program files``` folder, the following queries can be used to hunt for unsigned or untrusted binaries executed or loaded from there: + +### Unsigned DLLs loaded from google chrome application folder + +``` sql +FROM logs-endpoint.events.library* +| where event.category == "library" and event.action == "load" and to_lower(dll.path) like "c:\\\\program files\\\\google\\\\chrome\\\\application\\\\*" and not (dll.code_signature.trusted == true) +| keep process.executable, dll.path, dll.hash.sha256, agent.id +| stats agents_count = COUNT_DISTINCT(agent.id), total_executions = count(*) by process.executable, dll.path, dll.hash.sha256 +| where agents_count == 1 and total_executions <= 10 +``` + +### Unsigned executable launched from google chrome application folder + +``` sql +FROM logs-endpoint.events.process* +| where event.category == "library" and event.type == "start" and (to_lower(process.executable) like "c:\\\\program files\\\\google\\\\chrome\\\\application\\\\*" or to_lower(process.executable) like "c:\\\\scoped_dir\\\\program files\\\\google\\\\chrome\\\\application\\\\*") +and not (process.code_signature.trusted == true and process.code_signature.subject_name == "Goole LLC") +| keep process.executable,process.hash.sha256, agent.id +| stats agents_count = COUNT_DISTINCT(agent.id), total_executions = count(*) by process.executable, process.hash.sha256 +| where agents_count == 1 and total_executions <= 10 +``` + +![ES|QL query results for malicious DLL loaded by Chrome](/assets/images/katz-and-mouse-game/image6.png) + +# Conclusion + +Google has raised the bar implementing new security controls to protect cookie data within Chrome. As expected, this has caused malware developers to develop or integrate their own bypasses. We hope Google will continue to innovate to provide stronger protection for user data. + +Organizations and defenders should consistently monitor for unusual endpoint activity. While these new techniques may be successful, they are also noisy and detectable with the right security instrumentation, processes, and personnel. + +## Stealer Bypasses and MITRE ATT&CK + +Elastic uses the [MITRE ATT&CK](https://attack.mitre.org/) framework to document common tactics, techniques, and procedures that 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. + + - [Credential Access](https://attack.mitre.org/tactics/TA0006/) + - [Defense Evasion](https://attack.mitre.org/tactics/TA0005/) + - [Discovery](https://attack.mitre.org/tactics/TA0007/) + - [Execution](https://attack.mitre.org/tactics/TA0002/) + +### Techniques + +Techniques represent how an adversary achieves a tactical goal by performing an action. + + - [Steal Web Session Cookie](https://attack.mitre.org/techniques/T1539/) + - [Process Injection](https://attack.mitre.org/techniques/T1055/) + - [Credentials from Password Stores](https://attack.mitre.org/techniques/T1555/) + - [System Information Discovery](https://attack.mitre.org/techniques/T1082/) + - [Process Discovery](https://attack.mitre.org/techniques/T1057/) + - [Inter-Process Communication: Component Object Model](https://attack.mitre.org/techniques/T1559/001/) + +## YARA + +Elastic Security has created YARA rules to identify this activity. + + - [Windows.Trojan.Stealc](https://github.com/elastic/protections-artifacts/blob/main/yara/rules/Windows_Trojan_Stealc.yar) + - [Windows.Infostealer.PhemedroneStealer](https://github.com/elastic/protections-artifacts/blob/main/yara/rules/Windows_Infostealer_PhemedroneStealer.yar) + - [Windows.Trojan.MetaStealer](https://github.com/elastic/protections-artifacts/blob/main/yara/rules/Windows_Trojan_MetaStealer.yar) + - [Windows.Trojan.Xeno](https://github.com/elastic/protections-artifacts/blob/main/yara/rules/Windows_Trojan_Xeno.yar) + - [Windows.Trojan.Lumma](https://github.com/elastic/protections-artifacts/blob/main/yara/rules/Windows_Trojan_Lumma.yar) + - [Windows.Infostealer.Generic](https://github.com/elastic/protections-artifacts/blob/main/yara/rules/Windows_Infostealer_Generic.yar) + +## Observations + +All observables are also available for [download](https://github.com/elastic/labs-releases/tree/main/indicators/app-bound_bypass) in both ECS and STIX format. + +The following observables were discussed in this research. + +| Observable | Type | Name | Reference | +|-----|-----|-----|-----| +| 27e4a3627d7df2b22189dd4bebc559ae1986d49a8f4e35980b428fadb66cf23d | SHA-256 | num.exe | STEALC | +| 08d9d4e6489dc5b05a6caa434fc36ad6c1bd8c8eb08888f61cbed094eac6cb37 | SHA-256 | HardCoreCrack.exe | PHEMEDRONE | +| 43cb70d31daa43d24e5b063f4309281753176698ad2aba9c557d80cf710f9b1d | SHA-256 | Ranginess.exe | METASTEALER | +| 84033def9ffa70c7b77ce9a7f6008600c0145c28fe5ea0e56dfafd8474fb8176 | SHA-256 | | LUMMA | +| b74733d68e95220ab0630a68ddf973b0c959fd421628e639c1b91e465ba9299b | SHA-256 | XenoStealer.exe | XENOSTEALER | + + +## References +The following were referenced throughout the above research: + + - [https://developer.chrome.com/release-notes/127](https://developer.chrome.com/release-notes/127) +- [https://security.googleblog.com/2024/07/improving-security-of-chrome-cookies-on.html](https://security.googleblog.com/2024/07/improving-security-of-chrome-cookies-on.html) diff --git a/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/protecting_your_devices_from_information_theft_keylogger_protection_jp.md b/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/protecting_your_devices_from_information_theft_keylogger_protection_jp.md index 7c239d1f48127..6bfc447cff63c 100644 --- a/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/protecting_your_devices_from_information_theft_keylogger_protection_jp.md +++ b/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/protecting_your_devices_from_information_theft_keylogger_protection_jp.md @@ -1,7 +1,7 @@ --- title: "情報窃取から端末を守る" slug: "protecting-your-devices-from-information-theft-keylogger-protection-jp" -date: "2020-05-30" +date: "2024-05-30" subtitle: "Windows APIの挙動を用いたキーロガー検知" description: "本記事ではElastic Securityにおいて、エンドポイント保護を担っているElastic Defendに今年(バージョン8.12より)新たに追加された、キーロガーおよびキーロギング検出機能について紹介します。" author: diff --git a/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/streamlining_security_integrating_amazon_bedrock.md b/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/streamlining_security_integrating_amazon_bedrock.md new file mode 100644 index 0000000000000..9ba2b033a851e --- /dev/null +++ b/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/streamlining_security_integrating_amazon_bedrock.md @@ -0,0 +1,237 @@ +--- +title: "Streamlining Security: Integrating Amazon Bedrock with Elastic" +slug: "streamlining-security-integrating-amazon-bedrock" +date: "2024-11-14" +description: "This article will guide you through the process of setting up the Amazon Bedrock integration and enabling Elastic's prebuilt detection rules to streamline your security operations." +author: + - slug: shashank-k-s +image: "Security Labs Images 36.jpg" +category: + - slug: security-research +--- + +# Preamble + +In the ever-evolving landscape of cloud computing, maintaining robust security while ensuring compliance is a critical challenge for organizations of all sizes. As businesses increasingly adopt the cloud, the complexity of managing and securing data across various platforms grows exponentially. + +[Amazon Bedrock](https://docs.aws.amazon.com/bedrock/latest/userguide/what-is-bedrock.html), with its powerful foundation of machine learning and AI services, offers a scalable, secure environment for organizations to develop and deploy intelligent applications. However, to fully harness the potential of these innovations, it’s essential to implement a streamlined approach to security and compliance. + +Integrating Elastic with Amazon Bedrock can significantly enhance security monitoring and compliance management within your cloud environment. This integration leverages Elastic’s search, observability, and security capabilities to optimize how you manage and secure applications and data hosted on Amazon Bedrock. + +Elastic’s [security information and event management (SIEM) capabilities](https://www.elastic.co/security/siem) can be used to analyze logs and monitor events generated by applications running on Amazon Bedrock. This allows for the detection of potential security threats in real-time and automated response actions to mitigate risks. + +This article will guide you through the process of setting up Amazon Bedrock integration and enabling our prebuilt detection rules to streamline your security operations. We will cover the following key aspects: + + 1. **Prerequisites for Elastic Amazon Bedrock Integration:** Understanding the core requirements for setting up Elastic Amazon Bedrock integration for cloud security. + 2. **Setting Up Amazon Bedrock Integration**: Step-by-step instructions to set up Amazon Bedrock in your existing AWS infrastructure. + 3. **Enabling Prebuilt Security Rules**: How to leverage [prebuilt rules](https://www.elastic.co/guide/en/security/current/rules-ui-management.html) to detect high-confidence policy violations and other security threats. + 4. **Exploring High-Confidence Misconduct Blocks Detection:** An in-depth look at a specific prebuilt rule designed to detect high-confidence misconduct blocks within Amazon Bedrocklogs. + 5. **Demonstrate an Exploit Case Scenario for Amazon Bedrock:** Using a sample python script to simulate interactions with an Amazon Bedrock model for testing exploit scenarios that could trigger Elastic prebuilt detection rules. + +# Prerequisites for Elastic Amazon Bedrock Integration + +## Elastic Integration for Amazon Bedrock + +The Amazon Bedrock integration collects Amazon Bedrock model invocation logs and runtime metrics with Elastic Agent. For a deeper dive on the integration, documentation can be found in our [documentation.](https://www.elastic.co/docs/current/integrations/aws_bedrock) + +Below are the list of prerequisites to have a complete and successful configuration of Amazon Bedrock Elastic Integration: + + * AWS Account Setup + * Elastic Cloud Requirements + * Terraform (Optional) + +### AWS Account Setup + + * **Active AWS Account**: Ensure you have an active AWS account with the appropriate permissions to deploy and manage resources on Amazon Bedrock. + * **Amazon Bedrock Setup**: Confirm that Amazon Bedrock is correctly configured and operational within your AWS environment. This includes setting up AI models, datasets, and other resources necessary for your applications. Refer to [Getting started with Amazon Bedrock](https://docs.aws.amazon.com/bedrock/latest/userguide/getting-started.html) for additional information on the setup. + * **IAM Roles and Permissions**: Create or configure Identity and Access Management (IAM) roles with the necessary permissions to allow Elastic to access Amazon Bedrock resources. These roles should have sufficient privileges to read logs, metrics, and traces from AWS services. Additional details of the requirements can be found in our [AWS documentation](https://www.elastic.co/docs/current/integrations/aws#requirements). + +### Elastic Cloud Requirements + +| [Version](https://www.elastic.co/docs/current/integrations/aws_bedrock#changelog) | 0.7.0 (Beta) | +| :---- | :---- | +| **Compatible Kibana version(s)** | 8.13.0 or higher for integration version 0.2.0 and above. Minimum Kibana Version 8.12.0 | +| [**Supported Serverless project types**](https://www.elastic.co/docs/current/integrations/serverless/support) | Security Observability | +| [**Subscription level**](https://www.elastic.co/subscriptions) | Basic | +| [**Level of support**](https://www.elastic.co/docs/current/integrations/support) | Elastic | + +**Note:** Since the integration is in Beta Release Stage, please enable ***Display Beta Integrations in the browse integration section of the Management pane in your Elastic stack.*** + +![](/assets/images/streamlining-security-integrating-amazon-bedrock/image1.png) + +### Terraform + +[Terraform](https://www.terraform.io/) is an open source infrastructure-as-code (IaC) tool created by HashiCorp that allows you to define, provision, and manage cloud and on-premises infrastructure in a consistent and repeatable way. + +This is an optional step, but good to have as the next sections of the article we use this tool to set up the required AWS Infrastructure. Deep dive on installation and docs can be found [here](https://developer.hashicorp.com/terraform/tutorials/aws-get-started/install-cli). + +# Setting Up Amazon Bedrock Integration + +In this section of the article, we will walk through the steps to set up Amazon Bedrock integration with Elastic in two parts: + + 1. **Setting Up AWS Infrastructure with Terraform**: In this section, we'll walk through the steps to set up an AWS infrastructure using Terraform. We'll create an S3 bucket, an EC2 instance with the necessary IAM roles and policies to access the S3 bucket, and configure security groups to allow SSH access. This setup is ideal for scenarios where you need an EC2 instance to interact with S3, such as for data processing or storage. + 2. **Elastic Agent and Integration Setup**: In this section, we'll walk through the steps to install Elastic Agent on the AWS EC2 instance and Configure the Amazon Bedrock Integration. + +### Setting Up AWS Infrastructure with Terraform + +The high-level configuration process will involve the following steps: + + 1. Configuring ```providers.tf``` + 2. Configuring ```variables.tf``` + 3. Configuring ```outputs.tf``` + 4. Configuring ```main.tf``` + +The ```providers.tf``` file typically contains the configuration for any Terraform providers you are using in your project. In our example, it includes the configuration for the AWS provider. Here is the [sample content](https://gist.github.com/shashank-elastic/290218cd4e787f65fbcbfd6423a0ca85#file-providers-tf) of our ```providers.tf``` file. The ```profile``` mentioned in the ```providers.tf``` should be configured in the user’s space of the AWS credentials file ```(~/.aws/credentials)```. Refer to [Configuration and credential file settings \- AWS Command Line Interface](https://docs.aws.amazon.com/cli/v1/userguide/cli-configure-files.html#cli-configure-files-format-profile), which is also highlighted in the credential section of Elastic’s [AWS documentation](https://www.elastic.co/docs/current/integrations/aws#aws-credentials). + +The ```variables.tf``` file contains the variable definitions used throughout your Terraform configuration. For our scenario, it includes the definition for the aws\_region and resource\_labels. Here is the [sample content](https://gist.github.com/shashank-elastic/290218cd4e787f65fbcbfd6423a0ca85#file-variables-tf) of our ```variables.tf``` file. + +The ```outputs.tf``` file typically contains the output definitions for your Terraform configuration. These outputs can be used to display useful information after your infrastructure is provisioned. Here is the [sample content](https://gist.github.com/shashank-elastic/290218cd4e787f65fbcbfd6423a0ca85#file-outputs-tf) of our ```outputs.tf``` file + +The ```main.tf``` file typically contains the collection of all of these resources such as data sources, S3 bucket and bucket policy, Amazon Bedrock Model Invocation Log configuration, SQS Queue configuration, IAM Role and Policies required by the EC2 instance that would install Elastic Agent and stream logs and Amazon Bedrock Guardrail configuration. Here is the [sample content](https://gist.github.com/shashank-elastic/290218cd4e787f65fbcbfd6423a0ca85#file-main-tf) of our ```main.tf``` file. + +Once the ```main.tf``` is configured according to the requirements we can then initialize, plan and apply the terraform configuration. + +``` +terraform init // initializes the directory and sets up state files in backend +terraform plan // command creates an execution plan +terraform apply // command applies the configuration aka execution step +``` + +To tear down the infrastructure that terraform has previously created one can use the ```terraform destroy``` command. + +Once the infrastructure setup is completed, necessary resource identifiers are provided via ```outputs.tf.``` We can conduct a basic verification of the infrastructure created using the following steps: + + 1. Verify the S3 Bucket created from the Terraform, one can either use aws cli command reference [list-buckets — AWS CLI 1.34.10 Command Reference](https://docs.aws.amazon.com/cli/latest/reference/s3api/list-buckets.html) or navigate via AWS console to verify the same. 2. Verify the SQS Queue created from the terraform, one can either use aws cli command reference [list-queues — AWS CLI 1.34.10 Command Reference](https://docs.aws.amazon.com/cli/latest/reference/sqs/list-queues.html) or navigate via AWS console to verify the same. + 3. Verify the EC2 Instance created from the AWS console and connect to the ec2-instance via [Connect using EC2 Instance Connect \- Amazon Elastic Compute Cloud](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-connect-methods.html#ec2-instance-connect-connecting-console) and run ```aws s3 ls example-bucket-name``` to check if the instance has access to the created S3 bucket. + 4. Verify the Amazon Bedrock Guardrail created from the Terraform, once can either use Amazon Bedrock API [ListGuardrails \- Amazon Bedrock](https://docs.aws.amazon.com/bedrock/latest/APIReference/API_ListGuardrails.html) or navigate via AWS console to verify the same. + +### Setting Up Elastic Agent and Integration Setup + +To install Elastic Agent on the AWS EC2 instance and configure the Amazon Bedrock integration, create an agent policy using the guided steps in [Elastic Agent policies | Fleet and Elastic Agent Guide \[8.15\]](https://www.elastic.co/guide/en/fleet/current/agent-policy.html). Then log into to the ec2-instance created in the infrastructure setup steps via [Connect using EC2 Instance Connect \- Amazon Elastic Compute Cloud](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-connect-methods.html#ec2-instance-connect-connecting-console), and install the elastic agent using the guided steps in [Install Elastic Agents | Fleet and Elastic Agent Guide \[8.15\]](https://www.elastic.co/guide/en/fleet/current/elastic-agent-installation.html). During the agent installation, remember to select the agent policy created at the beginning of this setup process and use the relevant agent installation method depending on the instance created. Finally, ensure the agent is properly configured and there is incoming data from the agent. + +To configure the Amazon Bedrock integration in the newly-created policy, add the Amazon Bedrock integration using the guided steps: [Add an Elastic Agent integration to a policy](https://www.elastic.co/guide/en/fleet/current/add-integration-to-policy.html). Enable Beta Integrations to use Amazon Bedrock integration as displayed in the image below. + +![](/assets/images/streamlining-security-integrating-amazon-bedrock/image4.png) + +Configure the Integration with AWS Access Keys to access the AWS account where Amazon Bedrock is configured. Use the Collect Logs from S3 bucket and specify the Bucket ARN created in the setup step. Please note to use either the S3 Bucket or the SQS Queue URL during the setup and *not both*. Add this integration to the existing policy where the ec2-instance is configured. + +![](/assets/images/streamlining-security-integrating-amazon-bedrock/image8.png) + +### Verify Amazon Bedrock Model Invocation Log Ingestions + +Once the Elastic Agent and integration setup is completed, we can conduct a basic verification of the integration to determine if the logs are being ingested as expected by using the following example API call: + +``` +aws bedrock-runtime converse \ +--model-id "anthropic.claude-3-5-sonnet-20240620-v1:0" \ +--messages '[{"role":"user","content":[{"text":"Hello "}]}]' \ +--inference-config '{"maxTokens":2000,"stopSequences":[],"temperature":1,"topP":0.999}' \ +--additional-model-request-fields '{"top_k":250}' \ +--region us-east-1 +``` + +The example API call assumes a working setup with aws cli and there is access for the foundational model [Anthropic Claude Messages API \- Amazon Bedrock](https://docs.aws.amazon.com/bedrock/latest/userguide/model-parameters-anthropic-claude-messages.html). If the user does not have access to the model one can simply request access for models from the model-access page as suggested in [Access Amazon Bedrock foundation models](https://docs.aws.amazon.com/bedrock/latest/userguide/model-access.html), or we can optionally change the API call to any existing model the user can access. + +On successful execution of the above API call, the Amazon Bedrock Model invocation logs are populated and in Kibana ```logs-aws_bedrock.invocation-default``` should be populated with those invocation logs. We can use the following simple ES|QL query to return recently ingested events. + +``` +from logs-aws_bedrock.invocation-* | LIMIT 10 +``` + +# Enable Prebuilt Detection Rules + +To enable prebuilt detection rules, first login to the elastic instance and from the left pane navigation navigate to Security → Rules → Detection rules (SIEM). Filter for “Data Source: Amazon Bedrock” from the tags section. + +Enable the available prebuilt rules. For prebuilt rules, the Setup information contains a helper guide to setup AWS Guardrails for Amazon Bedrock, which is accomplished in the [Setting Up AWS Infrastructure with Terraform](?tab=t.0#bookmark=id.5wbf10usmxhz) step if the example is followed correctly and the terraform has the Amazon Bedrock Guardrail configuration. Please note this setup is vital for some of the rules to generate alerts–we need to ensure the guardrail is set up accordingly if skipped in the infrastructure setup stage. + +![](/assets/images/streamlining-security-integrating-amazon-bedrock/image3.png) + +# Exploring High-Confidence Misconduct Blocks Detection + +Let’s simulate a real world scenario in which a user queries a topic denied to the Amazon Bedrock model. Navigate to the Amazon Bedrock section in the Amazon UI Console, and use the left navigation pane to navigate to the Guardrails subsection under Safeguards. Use the sample guardrail created during our setup instructions for this exercise, and use the test option to run a model invocation with the guardrails and query the denied topic configured. + +![](/assets/images/streamlining-security-integrating-amazon-bedrock/image6.png) + +Repeat the query at least 6 times as the prebuilt rule is designed to alert on greater than 5 high confidence blocks. When the Alert schedule runs, we can see an alert populate for ```Unusual High Confidence Misconduct Blocks Detected.``` + +![](/assets/images/streamlining-security-integrating-amazon-bedrock/image7.png) + +# Demonstrate an Exploit Case Scenario for Amazon Bedrock + +To simulate an Amazon Bedrock Security bypass, we need an exploit simulation script to interact with Amazon Bedrock models. The exploit script example we provide simulates the following attack pattern: + + * Attempts multiple successive requests to use denied model resources within AWS Bedrock + * Generates multiple successive validation exception errors within Amazon Bedrock + * User consistently generates high input token counts, submits numerous requests, and receives large responses that mimic patterns of resource exhaustion + * Combines repeated high-confidence 'BLOCKED' actions coupled with specific violation codes such as 'MISCONDUCT', indicating persistent misuse or attempts to probe the model's ethical boundaries + +```py +class BedrockModelSimulator: + def __init__(self, profile_name, region_name): + // Create a Boto3 Session Client for Ineration + def generate_args_invoke_model(self, model_id, user_message, tokens): // Generate Model Invocation parameters + guardrail_id = <> + guardrail_version = <> + + guardrail_config = { + "guardrailIdentifier": guardrail_id, + "guardrailVersion": guardrail_version, + "trace": "enabled" + } + conversation = [ + { + "role": "user", + "content": [{"text": user_message}], + } + ] + inference_config = {"maxTokens": tokens, "temperature": 0.7, "topP": 1} + additional_model_request_fields = {} + + kwargs = { + "modelId": model_id, + "messages": conversation, + "inferenceConfig": inference_config, + "additionalModelRequestFields": additional_model_request_fields + "guardrailConfig" : guardrail_config + } + return kwargs + + def invoke_model(self, invocation_arguments): + for _ in range(count): + try: + // Invoke Model With right invocation_arguments + except ClientError as e: + // Error meesage + +def main(): + profile_name = <> + region_name = 'us-east-1' + denied_model_id = // Use a denied model + denied_model_user_message = // Sample Message + available_model_id = // Use an available model + validation_exception_user_message = // Sample Message + resource_exploit_user_message = // A very big message for resource exhuastion + denied_topic_user_message = // Sample Message that can query denied topic configured + simulator = BedrockModelSimulator(profile_name, region_name) + denied_model_invocation_arguments = simulator.generate_args_invoke_model(denied_model_id, denied_model_user_message, 200) + simulator.invoke_model(denied_model_invocation_arguments) + validation_exception_invocation_arguments = simulator.generate_args_invoke_model(available_model_id, validation_exception_user_message, 6000) + simulator.invoke_model(validation_exception_invocation_arguments) + resource_exhaustion_invocation_arguments = simulator.generate_args_invoke_available_model(available_model_id, resource_exploit_user_message, 4096) + simulator.invoke_model(resource_exhaustion_invocation_arguments) + denied_topic_invocation_arguments = simulator.generate_args_invoke_available_model_guardrail(available_model_id, denied_topic_user_message, 4096) + simulator.invoke_model(denied_topic_invocation_arguments) + +if __name__ == "__main__": + main() +``` + +**Note:** The GUARDRAIL\_ID and GUARDRAIL\_VERSION can be found in ```outputs.tf``` + +When executed in a controlled environment, the provided script simulates an exploit scenario that would generate detection alerts in Elastic Security. When analyzing these alerts using the Elastic Attack Discovery feature, the script creates attack chains that show the relationships between various alerts, giving analysts a clear understanding of how multiple alerts might be part of a larger attack. + +![](/assets/images/streamlining-security-integrating-amazon-bedrock/image2.png) + +# Conclusion + +Integrating Elastic with Amazon Bedrock empowers organizations to maintain a secure and compliant cloud environment while maximizing the benefits of AI and machine learning. By leveraging Elastic’s advanced security and observability tools, businesses can proactively detect threats, automate compliance reporting, and gain deeper insights into their cloud operations. Increasingly, enterprises rely on opaque data sources and technologies to reveal the most serious threats-- our commitment to transparent security is evident in our open artifacts, integrations, and source code. \ No newline at end of file diff --git a/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/tricks_and_treats.md b/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/tricks_and_treats.md new file mode 100644 index 0000000000000..d7a98fe2b7258 --- /dev/null +++ b/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/tricks_and_treats.md @@ -0,0 +1,141 @@ +--- +title: "Tricks and Treats: GHOSTPULSE’s new pixel-level deception" +slug: "tricks-and-treats" +date: "2024-10-19" +description: "The updated GHOSTPULSE malware has evolved to embed malicious data directly within pixel structures, making it harder to detect and requiring new analysis and detection techniques." +author: + - slug: salim-bitam +image: "tricks-and-treats.jpg" +category: + - slug: malware-analysis +tags: + - ghostpulse + - lummastealer + - ref8207 +--- + +## Update + +This research covers an update to stage 2 of GHOSTPULSE, [originally disclosed](https://www.elastic.co/security-labs/ghostpulse-haunts-victims-using-defense-evasion-bag-o-tricks#stage-2) by Elastic Security Labs in October 2023. + +## Key takeaways + +1. GHOSTPULSE has shifted from using the IDAT chunk of PNG files to embedding its encrypted configuration and payload within the pixel structure. +1. Recent campaigns involve tricking victims with creative social engineering techniques, such as CAPTCHA validations that trigger malicious commands through Windows keyboard shortcuts. +1. Elastic Security has enhanced its YARA rules and updated the configuration extractor tool to detect and analyze both the old and new versions of GHOSTPULSE. + +## Preamble + +The GHOSTPULSE malware family (also known as HIJACKLOADER or IDATLOADER) has continuously evolved since its discovery in 2023, evading detection with increasingly developed techniques. + +In its earlier iterations, GHOSTPULSE abused the IDAT chunk of PNG files to hide malicious payloads, as detailed in a [previous article from Elastic Security Labs](https://www.elastic.co/security-labs/ghostpulse-haunts-victims-using-defense-evasion-bag-o-tricks). However, recent analysis has uncovered a significant change in its algorithm. Instead of extracting the payload from the IDAT chunk, the latest version of GHOSTPULSE now parses the pixels of the image to retrieve its configuration and payload. This new approach involves embedding malicious data directly within the pixel structure. + +In this research publication, we’ll explore this new pixel-based algorithm and compare it with the previous IDAT chunk technique with updated detection rules. + +## Introduction + +Recently, we've observed several campaigns involving LUMMA STEALER using GHOSTPULSE as its loader, a topic also explored by [HarfangLab](https://harfanglab.io/insidethelab/hijackloader-abusing-genuine-certificates/). These campaigns stand out due to their [creative social engineering tactics](https://www.secureworks.com/blog/fake-human-verification-prompt-delivers-infostealers). Victims are tricked into validating a CAPTCHA, but the website instructs them to execute a series of Windows keyboard shortcuts instead of the usual process. These shortcuts trigger a command copied to the clipboard by malicious JavaScript. This leads to a PowerShell script being executed, initiating the infection chain by downloading and executing a GHOSTPULSE payload. + +![Social engineer lure website](/assets/images/tricks-and-treats/image1.png "Lure website") + +In previous versions of GHOSTPULSE, it was delivered as part of a multi-file package. This package typically contained a benign executable, an infected DLL loaded by the executable, and a PNG file storing the encrypted configuration. + +However, in the latest version, GHOSTPULSE has streamlined its deployment. Now, the entire package consists of a single file—a benign but compromised executable that includes the PNG file within its resources section. + +![Large embedded PNG file in the resources section](/assets/images/tricks-and-treats/image2.png "Large embedded PNG file in the resources section") + +## Technical analysis + +The updated second stage of the malware retains much of its previous structure, including using the same hashing algorithm for resolving Windows API names. However, the most significant change is in how the malware now locates its configuration, which holds both the payload and critical instructions for its deployment. + +The following is a screenshot showing the pseudocode of both implementations: + +![Pseudocode code comparison between old and new algorithm](/assets/images/tricks-and-treats/image4.png "Pseudocode code comparison between old and new algorithm") + +In earlier versions, GHOSTPULSE would parse a PNG file for an encrypted data blob, which was divided into chunks and stored sequentially. The malware’s parsing process was straightforward: it would search for a specific marker within the file—in this case, the IDAT string. Once found, the malware would check for a 4-byte tag that followed the string. The encrypted chunk would be extracted if this tag matched the expected value. This process continues for every occurrence of the IDAT string that comes after until the full encrypted payload is collected. + +In the new version, the encrypted configuration is stored in the pixels of the image. The malware constructs a byte array by extracting each pixel's `RED`, `GREEN`, and `BLUE` (RGB) values sequentially using standard Windows APIs from the [GdiPlus(GDI+)](https://learn.microsoft.com/en-us/windows/win32/gdiplus/-gdiplus-gdi-start) library. Once the byte array is built, the malware searches for the start of a structure that contains the encrypted GHOSTPULSE configuration, including the XOR key needed for decryption. It does this by looping through the byte array in 16-byte blocks. For each block, the first 4 bytes represent a CRC32 hash, and the next 12 bytes are the data to be hashed. The malware computes the CRC32 of the 12 bytes and checks if it matches the hash. If a match is found, it extracts the offset of the encrypted GHOSTPULSE configuration, its size, and the 4-byte XOR key, and then XOR decrypts it. + +The following diagram provides a visual breakdown of this process: + +![](/assets/images/tricks-and-treats/image5.png) + +## Updated configuration extractor + +Based on these findings, we have updated our configuration extractor to support both versions of GHOSTPULSE. This tool takes a PNG file as input and outputs the embedded payload. You can find the updated tool in our [labs-releases repository](https://github.com/elastic/labs-releases/tree/main/tools/ghostpulse). + +![](/assets/images/tricks-and-treats/image3.png) + +## Detecting GHOSTPULSE with YARA + +The original [GHOSTPULSE YARA](https://github.com/elastic/protections-artifacts/blob/main/yara/rules/Windows_Trojan_GhostPulse.yar) rule still prevents the final stage of an infection and is built into Elastic Defend. The updated sample can be detected using the following YARA rules and will be included with Elastic Defend in a future release. + +Elastic Security has updated the GHOSTPULSE YARA rules to identify this activity: + +``` +rule Windows_Trojan_GHOSTPULSE_1 { + meta: + author = "Elastic Security" + creation_date = "2024-10-15" + last_modified = "2024-10-15" + os = "Windows" + arch = "x86" + category_type = "Trojan" + family = "GHOSTPULSE" + threat_name = "Windows.Trojan.GHOSTPULSE" + license = "Elastic License v2" + + strings: + $stage_1 = { 49 63 D0 42 8B 0C 0A 41 03 CA 89 0C 1A 8B 05 ?? ?? ?? ?? 44 03 C0 8B 05 ?? ?? ?? ?? 44 3B C0 } + $stage_2 = { 48 89 01 48 8B 84 24 D8 00 00 00 48 8B 4C 24 78 8B 49 0C 89 08 C7 44 24 44 00 00 00 00 } + + condition: + any of them +} + +rule Windows_Trojan_GHOSTPULSE_2 { + meta: + author = "Elastic Security" + creation_date = "2024-10-10" + last_modified = "2024-10-10" + os = "Windows" + arch = "x86" + category_type = "Trojan" + family = "GHOSTPULSE" + threat_name = "Windows.Trojan.GHOSTPULSE" + license = "Elastic License v2" + + strings: + $a1 = { 48 83 EC 18 C7 04 24 00 00 00 00 8B 04 24 48 8B 4C 24 20 0F B7 04 41 85 C0 74 0A 8B 04 24 FF C0 89 04 24 EB E6 C7 44 24 08 00 00 00 00 8B 04 24 FF C8 8B C0 48 8B 4C 24 20 0F B7 04 41 83 F8 5C } + + condition: + all of them +} +``` + +## Conclusion + +In summary, the GHOSTPULSE malware family has evolved since its release in 2023, with this recent update marking one of the most significant changes. + +As attackers continue to innovate, defenders must adapt by utilizing updated tools and techniques to mitigate these threats effectively. We are excited to share our newly developed configuration extractor tool, designed to analyze the older and newer versions of GHOSTPULSE. This tool empowers researchers and cybersecurity professionals by providing enhanced capabilities for understanding and combating these evolving threats. As the landscape of cyber threats changes, collaboration, and innovation remain essential for effective protection. + +## Observations + +All observables are also available for [download](https://github.com/elastic/labs-releases/tree/main/indicators/ghostpulse) in both ECS and STIX format. + +The following observables were discussed in this research. + +| Observable | Type | Name | Reference | +|------------------------------------------------------------------|-------------|-----------------|------------------------------------------| +| `57ebf79c384366162cb0f13de0de4fc1300ebb733584e2d8887505f22f877077` | SHA-256 | `Setup.exe` | GHOSTPULSE sample | +| `b54d9db283e6c958697bfc4f97a5dd0ba585bc1d05267569264a2d700f0799ae` | SHA-256 | `Setup_light.exe` | GHOSTPULSE sample | +| `winrar01.b-cdn[.]net` | domain-name | | Infrastructure hosting GHOSTPULSE sample | +| `reinforcenh[.]shop` | domain-name | | LUMMASTEALER C2 | +| `stogeneratmns[.]shop` | domain-name | | LUMMASTEALER C2 | +| `fragnantbui[.]shop` | domain-name | | LUMMASTEALER C2 | +| `drawzhotdog[.]shop` | domain-name | | LUMMASTEALER C2 | +| `vozmeatillu[.]shop` | domain-name | | LUMMASTEALER C2 | +| `offensivedzvju[.]shop` | domain-name | | LUMMASTEALER C2 | +| `ghostreedmnu[.]shop` | domain-name | | LUMMASTEALER C2 | +| `gutterydhowi[.]shop` | domain-name | | LUMMASTEALER C2 | +| `riderratttinow[.]shop` | domain-name | | LUMMASTEALER C2 | \ No newline at end of file diff --git a/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/twice_around_the_dance_floor_with_pipedance.md b/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/twice_around_the_dance_floor_with_pipedance.md index 4775edad80247..1767d5edd4c94 100644 --- a/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/twice_around_the_dance_floor_with_pipedance.md +++ b/x-pack/plugins/elastic_assistant/server/knowledge_base/security_labs/twice_around_the_dance_floor_with_pipedance.md @@ -230,7 +230,7 @@ PIPEDANCE is designed to conduct covert operations using named pipes and has var ### Detection -- [Suspicious Windows Service Execution](https://github.com/elastic/endpoint-rules/blob/main/rules/privilege_escalation_suspicious_services_child.toml) +- [Suspicious Windows Service Execution](https://github.com/elastic/protections-artifacts/blob/main/behavior/rules/windows/privilege_escalation_suspicious_windows_service_execution.toml) - [NullSessionPipe Registry Modification](https://www.elastic.co/guide/en/security/current/nullsessionpipe-registry-modification.html) - [Potential Lateral Tool Transfer via SMB Share](https://www.elastic.co/guide/en/security/master/potential-lateral-tool-transfer-via-smb-share.html) From 95078b7350f90069d4ec0730969b2fe6796de2f9 Mon Sep 17 00:00:00 2001 From: Kibana Machine <42973632+kibanamachine@users.noreply.github.com> Date: Thu, 12 Dec 2024 11:51:02 +1100 Subject: [PATCH 10/12] skip failing test suite (#182448) --- .../tamper_protection/enabled/uninstall_agent_from_host.cy.ts | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/x-pack/plugins/security_solution/public/management/cypress/e2e/tamper_protection/enabled/uninstall_agent_from_host.cy.ts b/x-pack/plugins/security_solution/public/management/cypress/e2e/tamper_protection/enabled/uninstall_agent_from_host.cy.ts index 286be75f745b3..aea4ee91829c5 100644 --- a/x-pack/plugins/security_solution/public/management/cypress/e2e/tamper_protection/enabled/uninstall_agent_from_host.cy.ts +++ b/x-pack/plugins/security_solution/public/management/cypress/e2e/tamper_protection/enabled/uninstall_agent_from_host.cy.ts @@ -22,7 +22,8 @@ import { login } from '../../../tasks/login'; import { createEndpointHost } from '../../../tasks/create_endpoint_host'; import { deleteAllLoadedEndpointData } from '../../../tasks/delete_all_endpoint_data'; -describe( +// Failing: See https://github.com/elastic/kibana/issues/182448 +describe.skip( 'Uninstall agent from host when agent tamper protection is enabled', { tags: ['@ess'] }, () => { From c132b640650def00187d2735c69214d8257719bc Mon Sep 17 00:00:00 2001 From: Kibana Machine <42973632+kibanamachine@users.noreply.github.com> Date: Thu, 12 Dec 2024 11:51:35 +1100 Subject: [PATCH 11/12] skip failing test suite (#182451) --- .../tamper_protection/enabled/unenroll_agent_from_fleet.cy.ts | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/x-pack/plugins/security_solution/public/management/cypress/e2e/tamper_protection/enabled/unenroll_agent_from_fleet.cy.ts b/x-pack/plugins/security_solution/public/management/cypress/e2e/tamper_protection/enabled/unenroll_agent_from_fleet.cy.ts index 0915cd578adc1..48f9a59a26015 100644 --- a/x-pack/plugins/security_solution/public/management/cypress/e2e/tamper_protection/enabled/unenroll_agent_from_fleet.cy.ts +++ b/x-pack/plugins/security_solution/public/management/cypress/e2e/tamper_protection/enabled/unenroll_agent_from_fleet.cy.ts @@ -20,7 +20,8 @@ import { login } from '../../../tasks/login'; import { createEndpointHost } from '../../../tasks/create_endpoint_host'; import { deleteAllLoadedEndpointData } from '../../../tasks/delete_all_endpoint_data'; -describe( +// Failing: See https://github.com/elastic/kibana/issues/182451 +describe.skip( 'Unenroll agent from fleet when agent tamper protection is enabled', { tags: ['@ess'] }, () => { From 76f2351c4d95456f3934a7da7e461849cb446098 Mon Sep 17 00:00:00 2001 From: Kibana Machine <42973632+kibanamachine@users.noreply.github.com> Date: Thu, 12 Dec 2024 11:52:43 +1100 Subject: [PATCH 12/12] skip failing test suite (#203921) --- .../automated_response_actions.cy.ts | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/x-pack/plugins/security_solution/public/management/cypress/e2e/automated_response_actions/automated_response_actions.cy.ts b/x-pack/plugins/security_solution/public/management/cypress/e2e/automated_response_actions/automated_response_actions.cy.ts index 86e07e65e83ae..065a48f7cb3c4 100644 --- a/x-pack/plugins/security_solution/public/management/cypress/e2e/automated_response_actions/automated_response_actions.cy.ts +++ b/x-pack/plugins/security_solution/public/management/cypress/e2e/automated_response_actions/automated_response_actions.cy.ts @@ -20,7 +20,8 @@ import { createEndpointHost } from '../../tasks/create_endpoint_host'; import { deleteAllLoadedEndpointData } from '../../tasks/delete_all_endpoint_data'; import { enableAllPolicyProtections } from '../../tasks/endpoint_policy'; -describe( +// Failing: See https://github.com/elastic/kibana/issues/203921 +describe.skip( 'Automated Response Actions', { tags: ['@ess', '@serverless'],