This release consists of the following:
- Going Crypter (CT-named malware)
- Vidar v12 variant
- Lumma variant using ChaCha encrypted configuration
- JWTL (JohnWalkerTexasLoader)
- DemonWare ransomware
- FunkLocker ransomware
- VeilFramework BindTCP and RevHttp modules
- BindTCP: 8d243dd8e3cde7c2cb4697a8ada54d67
- RevHttp: c5020d1bcc02c568b7d2951d7af928cc
- Jason Stealer (CT-named malware)
- DarkGate AutoIt script variant using XOR-NOT decoding for the shellcode
- Dave + DarkGate: 0b0aabe01ecf2a33104063dd379fadf5
- C4 Crypter (CT-named malware)
- Screenshoter downloader (CT-named malware)
- Skuld stealer variant
- HexaLocker v2
- ZZART3XX Clipper (uses same GoLang obfuscator as HexaLocker v2, and same path “zzart/Desktop/MalwareDeveloppement/GoObfuscator”
Going Crypter
While researching Vidar, we identified a crypter written in GoLang that we are referring to as “Going Crypter”, based upon the “/going.go” path within each binary. The crypter AES-GCM decrypts an embedded component using a key derived from the MD5 hash of a seed value. The data buffer is structured as follows:
| Offset | Size | Description |
| 0 | 12 | AES-GCM IV |
| 12 | <VARIABLE> | AES-GCM encrypted data |
| -16 | 16 | AES-GCM tag |
During research, we identified ~50 Going Crypter samples on VirusTotal with the payloads consisting of a Vidar variant (self-reported version 12.x) and the new Lumma variant using ChaCha for its configuration, recently reported upon by eSentire.
- Going Crypter + Vidar: 0efa5966ba018424377f72a92301264e
- Going Crypter + Lumma: 062250dd669c1ee2ffad83db43299d54
Jason Stealer
Jason Stealer, named for the presence of “Jason” in class names, mutexes, and seeds, is written in .NET and analysis suggests it is a derivative work of DcRat (itself a variant of AsyncRAT).
One of the ACCE libraries available to our customers is dotnetfile, which is a pure Python library capable of processing .NET compiled binaries. This month, we released a major addition to dotnetfile enabling emulation of targeted methods.
When building the parser for Jason Stealer, we opted to leverage dotnetfile‘s emulator to facilitate key-derivation, Base64 decoding, and AES-256 decryption of the configuration parameters. This simplified the Jason Stealer parser to only require identification of the configuration decryption method, where the emulator handled the heavy lifting.
We plan to continually expand the emulator’s capabilities, including supporting common .NET obfuscators such as ConfuserEx and .NET Reactor, further reducing overhead in parser creation.
- Jason Stealer: 420ff8e35cf448236e3c5558b411ffef
C4 Crypter
Also while researching Vidar and Lumma, we identified another crypter we are calling “C4 Crypter” based on the presence of “AdminC4” in some of the PDB paths of identified samples.
C4 Crypter consists of a loader shellcode and a payload, where both components are XOR-encoded using a 4-byte key. The key is derived using the algorithm seen below, where each byte of the key is incremented until the first 4 bytes of the shellcode decode to b”\x55\x8b\xec\x83″, which are the assembly instructions “push ebp”, “mov ebp, esp” and the start of a “sub” instruction.
In most circumstances, the encrypted payload is loaded on the stack prior to decryption, while in others it is stored in a data buffer. This variation was also observed with the encrypted shellcode.
We identified ~80 C4 Crypter samples, with payloads including Lumma and Vidar (as previously mentioned), Rhadamanthys, and a downloader we are calling “Screenshoter” based upon the internal file information, including the file description.
Screenshoter uses a user-agent “Share_Screen” (also observed as “ShareScreen”) and uses a SUB-XOR string decoding algorithm, protecting strings including the mutex and download URL(s).
- C4 + Screenshoter: 17410740172d2524558548bfd9f05df4
- C4 + Lumma: 31708d5417b77605acf3641930d94ea7