NSIS-based crypters (NSIXloader) are used to protect and obfuscate a wide range of malware, complicating static analysis and enabling automatic unpacking. The article describes how these NSIS packers unpack, decrypt, and execute payloads (including RC4/XOR variants), how they resolve Windows APIs by hashing, and how to build an automated static unpacker using 7-Zip and Python.
#NSIS #NSIXloader #XLoader #Remcos #404Keylogger #Lokibot #Azorult #Warzone #Formbook #AgentTesla
#NSIS #NSIXloader #XLoader #Remcos #404Keylogger #Lokibot #Azorult #Warzone #Formbook #AgentTesla
Keypoints
- NSIS-based crypters (referred to as NSIXloader) are widespread and used to protect a variety of malicious payloads, including loaders and RATs.
- The NSIS package typically contains two encrypted binaries in the archive root and a DLL in $PLUGINSDIR that must be called to unpack the payload.
- The NSIS installer script simply unpacks the encrypted files to a temporary directory and then invokes a function inside the malicious DLL to continue execution. “The malicious installer utilizes a very simple NSIS script whose task is to unpack the encrypted files, place them into a temporary directory, and then call a function inside the malicious DLL.”
- Payload decryption often relies on XOR (and sometimes a cyclic shift) with a text key found inside the DLL, followed by executing the decrypted shellcode. “The DLL reads the smallest encrypted file … and decrypts the file using the XOR operation with a text key.”
- APIs are resolved by hashing rather than naming, enabling loader to locate functions by scanning kernel32.dll exports and comparing function-name hashes. “The loader parses the header of kernel32.dll and locates the address of the export table. Next, it calculates the hash of each function name and compares it with the hash of the desired function.”
- There are multiple variants: DLL with embedded shellcode, EXE variant, shellcode stored in resources, RC4-encrypted payload, and more, showing flexible deployment by the same packer family.
- Automatic unpacking can be implemented by using 7-Zip to extract NSIS contents and Python-based tooling (with malduck) to locate keys, decrypt the shellcode, and reconstruct the payload decryption sequence for automation. “We can use 7-zip in the first step to extract and decompress the files from the NSIS package. The rest of the automation can be done in Python.”
MITRE Techniques
- [T1027] Obfuscated/Compressed Files and Information – The NSIS packer uses XOR (and possible cyclic shifts) to encrypt the payload; ‘Shellcode decryption inside the DLL.’
- [T1064] Scripting – The malicious NSIS installer uses a simple NSIS script to unpack files, place them in a temporary directory, and call a DLL function; ‘The malicious installer utilizes a very simple NSIS script whose task is to unpack the encrypted files, place them into a temporary directory, and then call a function inside the malicious DLL.’
- [T1036] Masquerading – NSIS-based installers are designed to look like legitimate installers; ‘The advantage for cybercriminals in using NSIS is that it allows them to create samples that, at first glance, are indistinguishable from legitimate installers.’
- [T1106] Native API – The loader resolves Windows API addresses by hashing function names and locating the export table in kernel32.dll; ‘The loader parses the header of kernel32.dll and locates the address of the export table. Next, it calculates the hash of each function name and compares it with the hash of the desired function.’
- [T1055] Process Injection – After decryption, execution is handed to the decrypted payload, effectively executing code in memory; ‘After the decryption, it passes execution to the decrypted code.’
- [T1074] Data Staged – The unpacked files are placed into a temporary directory before further processing; ‘place them into a temporary directory.’
Indicators of Compromise
- [SHA256] context – 12a06c74a79a595fce85c5cd05c043a6b1a830e50d84971dcfba52d100d76fc6, 44e51d311fc72e8c8710e59c0e96b1523ce26cd637126b26f1280d3d35c10661, and 9 more hashes (XLoader payloads with DLL loader or embedded shellcode)
- [SHA256] context – 00042ff7bcfa012a19f451cb23ab9bd2952d0324c76e034e7c0da8f8fc5698f8 (Shellcode embedded in DLL) and 2 more hashes (XLoader)
- [SHA256] context – 3f7771dd0f4546c6089d995726dc504186212e5245ff8bc974d884ed4f485c93 (Remcos variant with shellcode in separate file)
- [SHA256] context – 160928216aafe9eb3f17336f597af0b00259a70e861c441a78708b9dd1ccba1b (Payload RC4-encrypted in XLoader)
- [SHA256] context – cd7976d9b8330c46d6117c3b398c61a9f9abd48daee97468689bbb616691429e (Agent Tesla variant)
- [SHA256] context – a3e129f03707f517546c56c51ad94dea4c2a0b7f2bcacf6ccc1d4453b89be9f5 (404 Keylogger variant)
- [SHA256] context – bb8e87b246b8477863d6ca14ab5a5ee1f955258f4cb5c83e9e198d08354bef13 (Formbook variant)
- [SHA256] context – 178f977beaeb0470f4f4827a98ca4822f338d0caace283ed8d2ca259543df70e (Lokibot variant)
- [SHA256] context – 80db5ced294160666619a79f0bdcd690ad925e7f882ce229afb9a70ead46dffa (Warzone variant)
- [SHA256] context – 090979bcb0f2aeca528771bb4a88c336aec3ca8eee1cef0dfa27a40a0a06615c (Azorult variant)