# Nymaim config decoded **proofpoint.com/us/threat-insight/post/nymaim-config-decoded** March 12, 2019 ----- [Blog](https://www.proofpoint.com/us/blog) [Threat Insight](https://www.proofpoint.com/us/blog/threat-insight) Nymaim config decoded March 12, 2019 Georgi Mladenov ----- **O e** **e** First documented in 2013 [1], Nymaim was originally identified as both a first-stage downloader and second-stage locking malware. Primarily distributed via the Blackhole exploit kit, most users found out they were infected because of the screen lock that demanded varying ransoms. In 2016, we documented distribution of the Ursnif banking Trojan via email campaigns and the presence of webinjects within Nymaim itself [2]. More recently, Nymaim has evolved into an even more robust downloader that includes a range of information stealing and system profiling capabilities. This incarnation of Nymaim has appeared in both global campaigns as well as attacks targeting North America, Germany, Italy, and Poland. In this respect, Nymaim is following global malware trends, with a focus on persistent, non-destructive infection to collect information long-term and flexibly download additional malware of the threat actor’s choosing. Despite its long history and increasing incidence of spreading via email, many aspects of Nymaim are not well understood, including its ownership and availability to groups of threat actors. Moreover, the configuration file format outlined in this blog and the config’s interaction with a virtual machine running within the malware itself appears to be unique. While CERT.pl described the configuration encryption algorithms previously [3], recent samples now employ a bytecode language with its own logic that is interpreted by the malware, running in a virtual machine managed by Nymaim. Technical details of the config file and its interaction with the Nymaim interpreter are outlined below. **Analysis** _Config parsing_ As other researchers have noted for various components of Nymaim [4], the configuration data is stored in an encrypted and, in some cases, aPLib-compressed format. The configuration data consists of a binary structure composed of multiple config components or chunks. Each data component has a recognizable pattern that is structured in the following format: struct CONFIG_LINE { DWORD opcode; DWORD params_length; byte params[params_length]; } Upon further analysis, we found that the configuration is compiled bytecode-like data that runs in a custom virtual machine environment inside Nymaim. The config has its own CODE and DATA sections, stack, local variables, registers, conditional cases, procedures, and API calls. Additionally, the config parser includes a built-in integrity check of the params data, such that on initialization, the structure outlined above is expanded in memory to four parameters: struct CONFIG_LINE_PARSED { DWORD opcode; DWORD crc; DWORD params_length; byte params[params_length]; } The integrity check uses a checksum algorithm that is widely used in the malware and this is its implementation: def crc(data, data_len): delta = 0x9AF598DC crc = 0 for i in range(0, data_len // 4): crc += struct.unpack_from("