Loading malware…
TextShell is a malware packer/obfuscator used as the first stage in the OysterLoader infection chain. Reporting describes OysterLoader as a multi-stage C++ loader also known as Broomstick and CleanUp, active since mid-2024 and associated with campaigns leading to Rhysida ransomware deployment; it has also been used to deliver Vidar and has been reported in some cases alongside Gootloader-driven distribution. TextShell’s role is to load hidden code directly into memory and hand off execution to later OysterLoader stages. Observed behavior includes allocating executable memory, copying encrypted or embedded next-stage data in small blocks, dynamically resolving Windows APIs via custom hashing, and using API hammering with large numbers of benign DLL/API calls to hinder heuristic detection, sandboxing, and reverse engineering. It also performs anti-debugging via IsDebuggerPresent and may enter an infinite loop if a debugger is detected. In the documented four-stage chain, TextShell precedes a shellcode stage that uses bespoke LZMA decompression and relocation fixups, followed by a downloader that performs environment checks and creates a mutex, and a final stage that drops a DLL and installs a scheduled task for persistence. High-confidence indicators and downstream artifacts mentioned in the reporting for the broader OysterLoader chain include the mutex h6p#dx!&fse?%AS!, a scheduled task invoking rundll32.exe DllRegisterServer on a dropped DLL such as COPYING3.dll in %APPDATA%, and C2 infrastructure including endpoints such as /reg, /login, /api/v2/init, and /api/v2/facade, with hardcoded servers including 85.239.53[.]66, 51.222.96[.]108, and 135.125.241[.]45.
Mallory pivots from this family to the IOCs, detections, and named campaigns that touch your stack, and pages you when something new lands.
20 distinct techniques documented for this family, organized by ATT&CK tactic.
Stage 1: A packer known as TextShell that loads obfuscated shellcode into memory Stage 2: Custom shellcode that decompresses the core payload using a modified LZMA routine
Stage 1: A packer known as TextShell that loads obfuscated shellcode into memory
Stage 1: A packer known as TextShell that loads obfuscated shellcode into memory
Stage 1: A packer known as TextShell that loads obfuscated shellcode into memory
The packer also embedded a simple anti-debug trap... Besides, the first stage employs common techniques such API hammering and dynamic API resolution.
The report outlines four stages: a packed obfuscator (TextShell), a shellcode layer that inflates content with LZMA
Dynamic API resolution often implemented through custom hashing algorithms is a widespread technique in modern malware... the packer is no exception: it relies on dynamically imported APIs, but each sample uses a slightly different hashing algorithm.
The malware is distributed mainly through fake websites that copy legitimate software. It is disguised as a software installer and serves as a MicroSoft Installer (MSI). The MSI is often signed to appear benign.
Stage 1: A packer known as TextShell that loads obfuscated shellcode into memory
The report outlines four stages: a packed obfuscator (TextShell), a shellcode layer that inflates content with LZMA...
The code of the initial stage is full of useless API calls to legitimate DLL, the objectives being to avoid execution in particular environments... Mislead sandboxes... The main function uses EnumProcess to count the number of running processes, if the count is below 60, the malware exits.
The first stage, known as TextShell, employs API call flooding ... specifically designed to evade heuristic detection systems, confuse sandbox analysis environments, and hinder reverse engineering efforts.
The code of the initial stage is full of useless API calls to legitimate DLL, the objectives being to avoid execution in particular environments... Mislead sandboxes... The main function uses EnumProcess to count the number of running processes, if the count is below 60, the malware exits.
More sophisticated command-and-control and obfuscation tactics have been integrated into the OysterLoader malware... Multiple environment checks are then conducted by an intermediate downloader, which also begins C2 communications... the malware has since pivoted to sending an empty GET request to /api/v2/init, where a fingerprint is also submitted, before beaconing to an assigned endpoint.
3 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.
A packed obfuscator stage within the OysterLoader infection chain.
A packer used as the first stage of the OysterLoader infection chain to load hidden code into memory and help evade detection.
A malware component used as the initial packer/obfuscator stage in the OysterLoader infection chain, responsible for loading the next stage from shuffled data in memory while using noisy API calls and anti-debugging to hinder analysis.
Match every observed IP, domain, and hash against your live telemetry.
Named campaigns wielding this family, with evidence pinned to each claim.
CVEs this family uses for access and lateral movement.
YARA, Sigma, Snort, and vendor rules, auto-deployed to your SIEM.
Every documented technique, ranked by evidence weight.
Reddit, Mastodon, and CTI community discussion around this family.