Loading story…
A researcher published a proof-of-concept showing Linux shellcode delivered over an acoustic channel and executed by a receiver that demodulates audio with the Goertzel algorithm. The scheme uses frequency-shift keying at 300 baud, mapping bits to 2200 Hz and 1200 Hz tones, while a Python transmitter wraps the payload in a frame containing a 5-byte preamble, a 16-bit big-endian length field, the payload, and a 1-byte XOR checksum to improve synchronization and integrity.
On the receiving side, a C program records 6 seconds of 48 kHz, 16-bit mono audio through ALSA, brute-forces 16 sample offsets to recover alignment, scans for the preamble, reconstructs the payload, and verifies the checksum before allocating RWX memory with mmap to run the recovered shellcode. The demonstration was presented as educational research into more reliable acoustic payload transfer in noisy environments, with the author also noting future work to hide shellcode as frequency-domain coefficients to reduce memory visibility to EDR tools.
See real exploitation activity before you spend the cycle.
3 events from the most recent confirmed update back to the earliest known activity.
A follow-up blog post detailed fixes for two reliability issues in the acoustic Bell 202 FSK receiver: bit straddling from unsynchronized sampling boundaries and ALSA buffer overruns. The updated PoC used 0.1-second chunked audio capture with EPIPE recovery, brute-force sub-bit alignment scanning, and then decoded and executed Linux x86_64 shellcode recovered from audio.
A blog post published an educational proof of concept for delivering and executing Linux shellcode over an acoustic FSK channel. The write-up described framing and synchronization improvements, Goertzel-based demodulation, checksum validation, and execution of the recovered payload from RWX memory.
A new part of the educational PoC series showed how to embed a Bell 202 FSK data stream into music, encode it as MP3, and recover the transmitted frame on the receiving side despite compression and playback/capture clock drift. The write-up also described receiver changes for coarse offset search, symbol-clock recovery, repeated-frame handling, and checksum-failure recovery, while noting the technique is not an MP3 parser exploit and requires a separate listening receiver.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
See real exploitation activity behind this advisory so you can triage it against everything else in the queue.
6 references tracked. Mallory keeps watching after this page renders.
malware.news
Open sourcemalware.news
Open sourcecocomelonc.github.io
Open sourcemalware.news
Open sourcegithub.com
Open sourcecocomelonc.github.io
Open sourceMap indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
Researchers at the Hong Kong University of Science and Technology (Guangzhou) and Hong Kong Polytechnic University disclosed **InjectEave**, an active electromagnetic side-channel technique that recovers audio played through wired and wireless headphones from up to 30 meters away, including through concrete walls. Instead of relying on weak passive emissions, an attacker transmits a tuned RF carrier that nonlinear components—such as amplifiers, ADCs, and power converters—mix with low-frequency audio signals, causing the audio to be re-emitted on a measurable carrier; the demonstrations used commercially available SDR equipment. The researchers also observed injection-induced leakage from smart-home power consumption and analog sensor inputs. In a closed-loop scenario involving a Flyingvoice VoIP landline, they combined eavesdropping with AI voice cloning and synthesized-audio injection, demonstrating both confidentiality and integrity risks. The findings identify analog circuitry and connected-device wiring as an attack surface that can bypass protections aimed at digital communications and may not be fully addressed by conventional cryptography or ordinary EM shielding.
Sep 8, 2026Trellix reported a Linux malware campaign that delivers **VShell** through a spam email carrying a RAR archive whose malicious logic is embedded in a crafted filename rather than the file's contents. The attack is triggered when unsafe shell scripting patterns interpret that filename through expansion and commands such as `eval`, `echo`, `printf`, or logging routines, causing a Base64-decoded Bash downloader to run. The downloader fingerprints the victim's CPU architecture, retrieves an ELF loader from `47.98.194.60`, and attempts stealthy execution with `nohup` from writable directories. The ELF loader then contacts a hardcoded command-and-control server, receives an XOR-encrypted payload using key `0x99`, decrypts it in memory, and launches the final malware with `fexecve()` while disguising itself as a kernel worker thread such as `[kworker/0:2]`. Trellix said the initial stage aligns with **Snowlight** dropper activity and identified the final payload as **VShell**, a Go-based Linux backdoor linked primarily to Chinese APT operations. The infection chain is notable for remaining effectively fileless after download, supporting multiple CPU architectures, and evading defenses that do not inspect filenames or in-memory execution behavior.
Jun 29, 2026
Multiple security researchers published detailed analyses of **Cobalt Strike** loaders, shellcode, and beacon traffic, showing how attackers continue to wrap the framework in diverse delivery chains including malicious DLLs, `.hta` files, `.vbs` scripts, CACTUSTORCH payloads, and Nim-based stagers. Across the samples, the loaders commonly used `VirtualAlloc`, `VirtualProtect`, `CreateThread`, `WriteProcessMemory`, and WinINet APIs, while shellcode was frequently hidden with XOR, Base64, 3DES, or custom obfuscation and then resolved APIs dynamically through PEB traversal and **ROR13-style API hashing**. Reported command-and-control indicators included `116.62[.]138.47`, `195.211.98[.]91`, `51.79.49[.]174:443`, and `42.193.229.33:12342`, with several samples using legacy Internet Explorer-style user agents and HTTP downloader or reverse-beacon behavior. The reporting also highlighted defender opportunities in memory and configuration analysis rather than static signatures alone. Analysts demonstrated extracting decrypted shellcode with hardware breakpoints, entropy-guided reverse engineering in Ghidra, and emulation in SpeakEasy, while other work showed how to recover or decrypt **Beacon** metadata and task traffic from leaked RSA keys or process memory. Additional hunting indicators included the named pipe pattern `\\.\pipe\MSSE-%d-server`, suspicious execution chains such as `mshta.exe` spawning child processes, and memory artifacts such as decoded payload stages, page-permission changes, and writable-memory key material. Together, the research shows that although Cobalt Strike payloads are heavily obfuscated and delivered through varied loaders, their in-memory behavior, decryption routines, and beacon communications remain practical points for detection and investigation.
Aug 15, 2026