Loading story…
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.
Mallory correlates global threat intelligence with your attack surface — know if you’re exposed before adversaries strike.
5 events from the most recent confirmed update back to the earliest known activity.
Avast Decoded published research describing how to extract and execute VB6 P-Code functions outside their original host by initializing the runtime, rebuilding required structures, and invoking ProcCallEngine. The article also highlighted use of the VBDec debugger and generator to automate extraction and patching tasks.
Avast Decoded published a reverse-engineering paper on VB6 P-Code disassembly and runtime internals, documenting opcode dispatch, argument decoding, and the complexity of the instruction set. The paper estimated about 822 unique handlers after removing invalid and duplicate entries from a theoretical maximum of 1,531 opcodes.
Avast Decoded published research concluding that VB6 P-Code can be obfuscated at the byte-stream layer. The paper demonstrated mutated samples using jump-over-junk, jumps into argument bytes, and invalid sequences that still execute correctly in the VB6 runtime.
Avast Decoded published a technical overview of how VB6 malware can embed binary data in executables, covering string encodings, opcode-based hiding, VB6 file-format structures, and PE-related storage tricks.
The researchers uploaded a mutated VB6 P-Code sample to VirusTotal so vendors could test their tooling against the demonstrated obfuscation techniques.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
5 references tracked. Mallory keeps watching after this page renders.
decoded.avast.io
Open sourcedecoded.avast.io
Open sourcedecoded.avast.io
Open sourcedecoded.avast.io
Open sourcesandsprite.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.
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.
Aug 15, 2026
Security research and malware-development writeups detailed a Windows evasion technique that avoids standard loader APIs such as **`GetProcAddress`** and **`GetModuleHandle`** by manually walking the **Process Environment Block (PEB)** and parsing DLL export tables. The approach resolves modules like **`kernel32.dll`** and **`user32.dll`** at runtime, including from encrypted strings, to reduce obvious API references in binaries and make static or behavioral detection more difficult. Microsoft’s documentation for **`GetProcAddress`** provides the baseline behavior that these custom implementations are designed to replace. One proof of concept showed a custom `GetProcAddress` implementation that located **`MessageBoxA`** dynamically on Windows 10 x64, while another demonstrated finding **`kernel32.dll`** in assembly-style code and resolving exports by hash before allocating memory and launching a benign payload with **`CreateThread`**. The authors framed the method as malware and red-team tradecraft, linked it to **MITRE ATT&CK `T1027`**, and noted similarities to techniques seen in **Conti ransomware** source code, underscoring how manual API resolution can help malicious code lower its detection footprint.
Aug 15, 2026
Palo Alto Networks Unit 42 detailed how analysts defeated anti-analysis protections in **BazarLoader**, a Windows backdoor linked to multiple ransomware operations, to accelerate reverse engineering and expose its behavior. The research focused on two obfuscation methods in a BazarLoader sample: API function hashing that concealed Windows API calls and opaque predicates that distorted control-flow analysis and decompilation. By reversing those protections, analysts were able to recover hidden functionality and better map the malware’s execution path. The team used **IDAPython** with IDA Pro’s Appcall feature to invoke BazarLoader’s own API-decoding routine during debugging, automatically recover dynamically resolved API names, and annotate calls. They also identified and patched opaque predicates so dead code blocks were removed and decompiled output became clearer. After applying those techniques, the researchers identified behaviors including **code injection** and determined that one heavily obfuscated routine acted as a wrapper for `GetModuleFileNameW()`, with accompanying GitHub-hosted scripts provided to automate API deobfuscation and opaque-predicate patching.
Aug 14, 2026