Loading story…
Researchers analyzing a SystemBC malware sample found it was protected by VMProtect 3.6+, which used layered anti-analysis techniques to frustrate debugging and unpacking. The protection chain reportedly included multiple debugger-detection methods, direct system calls, Windows build-number validation through structures such as KUSER_SHARED_DATA, fresh NTDLL remapping, and syscall-number extraction designed to evade user-mode hooks. The sample also appeared to rely on well-known anti-debugging and evasion patterns documented in public research, including low-level checks associated with segment handling and other debugger-detection tricks.
The analysts said VMProtect also performed anti-virtualization checks using CPUID, trap-flag behavior, and firmware-table inspection, exposing artifacts left by some older VirtualBox environments. To bypass those defenses, they modified ScyllaHide to spoof additional version fields, hook more APIs, change section-mapping behavior, and suppress firmware-table results. Those countermeasures allowed them to debug and unpack the malware, revealing that the SystemBC payload had been packed a second time beneath the VMProtect layer.
Mallory correlates global threat intelligence with your attack surface — know if you’re exposed before adversaries strike.
2 events from the most recent confirmed update back to the earliest known activity.
Researchers examined a SystemBC malware sample protected with VMProtect 3.6 or later and documented anti-debugging, direct-syscall, fresh-NTDLL remapping, and VM-detection techniques used by the packer. After modifying ScyllaHide to spoof additional version fields, hook more APIs, alter section mapping, and suppress firmware-table results, they were able to debug and unpack the sample and found the payload was packed a second time.
The analysis notes that older VirtualBox versions exposed virtualization through a trap-flag bug that pointed the exception EIP to the wrong instruction. It states this issue was fixed in VirtualBox version 7.0.4.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
5 references tracked. Mallory keeps watching after this page renders.
cyber.wtf
Open sourceevasions.checkpoint.com
Open sourceanti-debug.checkpoint.com
Open sourcegeoffchappell.com
Open sourcemalwaretech.com
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.
Avast researchers detailed how **Visual Basic 6 (VB6) P-Code** remains a viable malware platform, publishing reverse-engineering work that maps the internals of the `msvbvm60.dll` runtime, expands understanding of the instruction set, and improves disassembly of the language’s proprietary bytecode. The research found that VB6 P-Code is far more complex than a simple 256-opcode model, with roughly **822 unique opcode handlers** after removing invalid and duplicate entries from a larger prefixed and unprefixed space. The work also documented variable-length instruction decoding, constant-pool structures, COM call resolution, and debugger-assisted analysis, while pointing to tools such as **VBDec** and **Semi-VBDecompiler** as practical references for analysts handling VB6-based malware. Separate papers showed how attackers could exploit those gaps in tooling by hiding payload data inside VB6 executables and by manipulating P-Code streams in ways that still execute correctly at runtime but can break static analysis. Demonstrated techniques included jumps over junk bytes, jumps into argument data, invalid instruction sequences, and binary storage in resources, appended data, strings, form properties, error line tables, and other VB6-specific structures. Avast also described a method for extracting and reusing VB6 malware functions outside their original host by initializing the runtime through `CreateIExprSrvObj`, preserving `RTMI/ProcDscInfo` metadata, and invoking routines through `ProcCallEngine`, enabling analysts to execute malware-derived P-Code such as decryptors without fully reimplementing the runtime.
Aug 15, 2026
Researchers published detailed reverse-engineering work on **FinFisher/FinSpy** spyware, showing how the surveillance tool hides its payload behind heavy anti-analysis protections and a proprietary virtual machine. ESET documented Windows samples that use complementary conditional-jump pairs after nearly every instruction to break disassembly, then decrypt and execute protected bytecode through a custom virtual CPU. The whitepaper describes how analysts can peel back those layers by reconstructing components such as `vm_start`, `vm_dispatcher`, `vm_context`, and `vm_handlers`, noting that the examined VM used **34 handlers** and could mix virtualized logic with native instructions when full virtualization was impractical. Additional reverse-engineering research expanded on that work by demonstrating how to simplify and devirtualize FinSpy bytecode into equivalent x86 logic. The analysis focused on removing instruction patterns tied to a dedicated **SCRATCH** register, replacing them with canonical VM forms or direct x86 operations, and decoding sequences that represented x86-style memory addressing and memory access. After those transformations, the remaining bytecode was reduced largely to branch and raw x86-related instructions, and the researcher also corrected an earlier interpretation of one opcode, concluding that a supposed `CRASH` instruction was actually an unconditional jump. Together, the findings show that FinFisher’s protections were built to frustrate reverse engineering and conceal configuration data and newer spyware capabilities.
Aug 14, 2026
Proofpoint researchers detailed how the **Nymaim** malware family uses an unusual encrypted configuration format built as compiled bytecode and executed by a custom virtual machine embedded in the malware. The analysis shows Nymaim has evolved from a ransomware-style screen locker and downloader into a more capable downloader with **information-stealing** and **system-profiling** functions, giving operators a flexible way to change behavior without rebuilding the core malware. The decoded configuration revealed operational logic including integrity checks, timestamps, versioning, expiration dates, conditional branches, procedure calls, and API-like functions tied to the malware’s main components. Researchers also identified anti-debugging and anti-analysis checks for antivirus processes, sandbox-related libraries, virtual-machine MAC addresses, and suspicious usernames or hostnames, along with payload drop paths, process exclusion lists, DNS settings, and command-and-control domains and URLs that can help defenders detect and track Nymaim activity.
Aug 14, 2026