Loading story…
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.
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.
The analyzed Nymaim configuration included an expiration date of 23 November 2018. The report notes that expiration metadata is embedded in the malware's encrypted configuration format.
The decompiled Nymaim sample discussed in the report carried a compile timestamp of 2018-11-20T16:36:01.263625 and version 2.1.20.21. Proofpoint used such embedded metadata to date campaigns precisely.
In 2016, Nymaim was documented distributing the Ursnif banking Trojan through email campaigns. This marked a documented evolution beyond its earlier ransomware-style screen-locking behavior.
Proofpoint states that the Nymaim malware family was first documented in 2013. At that time it was identified as both a first-stage downloader and second-stage locking malware.
Proofpoint published research detailing how Nymaim stores its encrypted configuration as compiled bytecode executed by a custom virtual machine. The report also disclosed anti-analysis checks, integrity mechanisms, and decoded operational details such as process checks and C2-related configuration elements.
1 reference tracked. Mallory keeps watching after this page renders.
Map 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.
Nymaim evolved from a ransomware-associated threat into a flexible malware downloader delivered primarily through phishing emails, including campaigns that abused a legitimate bulk email marketing service to improve delivery and evade blacklist-based defenses. Victims were lured into opening malicious Word documents or links to macro-enabled files, after which Nymaim installed and frequently fetched additional payloads such as the **Ursnif** banking Trojan; one observed infection chain dropped **Pony** first and then used it to retrieve Nymaim. Researchers also noted that the malware retained web-injection capabilities aimed at banking sessions and continued to use heavy in-memory obfuscation to complicate analysis and detection. Later analysis showed Nymaim also overhauled its command-and-control resilience with a new wordlist-based **domain generation algorithm (DGA)** seeded by a hard-coded key and date values, producing domains across an 11-day sliding window with 64 domains per day alongside 46 hard-coded domains. The malware avoided exposing direct C2 addresses by transforming DNS `A` records into IPs, validating responses with a checksum mechanism, and screening `NS` records for sinkhole-related keywords before connecting. Once infrastructure was selected, the sample sent encrypted HTTP `POST` traffic to a hard-coded `/index.php` endpoint using **AES** and asymmetric encryption, underscoring Nymaim's transition into a more stealthy and resilient banking-malware delivery platform.
Aug 15, 2026
Researchers published proof-of-concept tooling to deobfuscate **Nymaim** malware, showing how analysts can recover cleaner code and improve reverse engineering in **IDA Pro**. One GitHub project, **Nymaim deobfuscation**, uses **miasm** for emulation and **grap** for graph-pattern matching to identify and patch common Nymaim obfuscation routines such as `push_reg`, `detour_call`, and `detour_jmp`, then generates an IDA script to rename functions and produce a cleaned sample. A related Bitbucket project, **Patchwork**, was built to demonstrate malware deobfuscation against the same malware family inside IDA using a modified **PyEmu** engine. The author described upgrades including stronger memory management, better support for uncommon x86 instructions, and a Python 2.7-compatible rebuild of **pydasm**, alongside setup guidance for loading Nymaim samples and running the deobfuscation workflow, underscoring a broader effort to automate analysis of heavily obfuscated Nymaim binaries.
Aug 15, 2026
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