ACCE Release Notes v2.5.20240313

Release Notes

This release consists of the following:

  • ToneShell Loader
  • Mustang Panda PlugX variants
  • SmugX variants
  • FormBook Stealer variant
  • EvilCoder’s XBinder variant
  • XWorm v5 support
  • Blank Loader, OBF, and Grabber support (open-source)
  • CStealer open-source stealer
  • Origami open-source Loader
  • Magma dead-drop downloader (CT named malware)
  • Glupteba botnet
  • Stealc variants
  • Ficker stealer
  • Gun downloader (CT named malware)
  • PureCoder suite tools:
    • PureCrypter downloader variants
    • PureCrypter Injector variants using ProtoBuf for configuration
    • PureCrypter Loader variants
  • Jinx Loader
  • Raccoon Clipper
  • Stipe Downloader (CT named malware)
  • UnamBinder .NET and Native Crypters
  • Rhadamanthys v0.5.0 support

FormBook Stealer

As part of our continuous monitoring, we recently discovered a new variant of FormBook stealer which does not use the FormBook null encoder, changes the way strings are decrypted, and has multiple layers and methods of code decryption to reveal the configuration decryption functions.

In previous versions of FormBook, strings were contained in a contiguous block and decrypted, as described by ZScaler. In this latest version, encrypted strings are loaded onto the stack in individual functions and decrypted using a sub-transform + RC4 cipher, as demonstrated below.

After decrypting code as described in the ZScaler article, a function will be decrypted which references a decrypted Base64 encoded string containing the C2 configuration. That string is Base64 decoded, sub-transform + RC4 decrypted using an initial key, stored in a structure, and then referenced in a separate function and sub-transform + RC4 decrypted using a final key to reveal the C2 URL.

The ACCE module supporting this variant reports decrypted strings and the C2 URL, and additionally outputs an IDA Database File with decrypted functions and labeling for decrypted string functions and other items.

Blank Grabber

Blank Grabber is an open-source Python stealer that has been observed being distributed by .NET compiled Crypters including what appears to be an EvilCoder’s XBinder variant using AES-ECB for component decryption.

Blank Grabber is embedded in a PyInstaller package, and consists of multiple layers, including a loader which uses zlib compression and AES-GCM encryption, and obfuscation using the open-source BlankOBF, which leverages LZMA compression and Rot13 encoding with a “shuffle.” The ACCE module supports all layers from the PyInstaller package down, reporting the C2 URL, mutex, and archive password for the Grabber component.

While researching the XBinder variant, we observed XWorm v5 samples, the open-source Python stealer CStealer, the open-source loader Origami, and a dead-drop downloader we are referring to as Magma based upon a module name observed in the original sample.

Burix Payloads

While checking on results from Burix packer samples we observed during monitoring, we found a number of payloads which were not identified or supported. In follow-on research for these payloads, we updated/added support as follows:

  • The Glupteba Botnet is written in GoLang and is configured with a BTC address and C2 URLs.
  • While traditionally using Base64 + RC4 for string decryption, we observed Stealc variants using XOR or Base64 encoding for strings.
  • Ficker is a stealer written in Rust and advertised as Malware-as-a-Service (MaaS) for a fee on underground forums. The ACCE module reports decrypted strings and C2 socket addresses.
  • Gun is a CT-named downloader which decrypts strings using sub-XOR decoding, where most strings are constructed on the stack. The ACCE module reports decrypted strings, C2 addresses, and URL paths.

Examples:

PureCoder

Any.RUN recently published research on the PureCoder suite of tools, including a PureCrypter Injector variant which instead uses ProtoBuf for configuration and payload storage. We had previously added support for a PureCrypter variant using a JSON configuration dictionary.

In addition to using ProtoBuf, the PureCrypter variant was observed to be obfuscated using both SmartAssembly and Babel .NET Obfuscators, such that the .NET resources first needed to be deobfuscated from SmartAssembly, then deobfuscated from Babel, to obtain the ProtoBuf structured and Gzip compressed configuration.

While researching additional PureCrypter samples, we observed a number of loaders we are categorizing under the PureCoder umbrella using a number of methodologies and obfuscators, including XOR decoding (as described in the article), TDES decryption, SmartAssembly .NET obfuscator, and Babel + EAZfuscator .NET obfuscators.

We ultimately found just less than 200 PureCrypter injector samples, and the payloads included Agent Tesla, DcRat, FormBook, Lumma Stealer, QusarRAT, Remcos, RisePro, SmokeLoader, Stealc, Vidar, WarzoneRAT, and XWorm. We additionally observed and added support for:

  • Jinx Loader, a GoLang implant for which we report C2 URLs and a named mutex.
  • Raccoon Clipper, part of the Raccoon MaaS suite.
  • UnamBinder, an open-source Crypter which has .NET and Native distribution options. We previously added support for the .NET Crypter using the descriptor ibFun, which we have now deprecated after identifying the UnamBinder correlation.
  • Stipe, a CT-named .NET downloader which executes a downloaded payload directly from the URL.
  • Rhadamanthys v0.5.0, described in detail by threat researcher hasherezade for CheckPoint Research. Additional details are provided below.

Examples:

Rhadamanthys

As mentioned above, Rhadamanthys v0.5.0 was well documented by CheckPoint Research, but, we wanted to provide a few additional details. In December 2023, we described a different Rhadamanthys Loader where the FS formatted component was stored in three separate segments. In this newer version, the loader uses the same methodology for the first segment, constructed on the stack across multiple functions, but the second (and final) segment is constructed differently.

The loader takes 4 different arrays of 32 elements each, each representing a block of plaintext or obfuscated data which are interwoven to form the second segment. The blocks in each array are obfuscated as follows:

  1. Plaintext, the data is not further manipulated
  2. Base64 encoded
  3. Hex-encoded data stored in a buffer of GUID strings (observed in the previous version)
  4. A custom obfuscation algorithm (observed in the previous version)

After interweaving the arrays and concatenating the segments, the FS component is Rhadamanthys-XOR decrypted. The loader then parses the FS component to decrypt and LZSS (custom implementation) decompress the XS component. While some loader samples use the TEA-CBC algorithm (with 2 rounds) for decryption as observed with the previous version, others instead use the Camellia-CBC algorithm.

Configuration decryption is also different in the new version. The previous version used Base64 with the alternative characters “*$”, RC4 decryption, and Rhadamanthys-XOR. Each sample of the new version was observed to Base64 decoded with the non-standard alphabet “ABC1fghijklmnop234NOPQRSTUVWXY567DEFGHIJKLMZ089abcdeqrstuvwxyz-|”, ChaCha decrypt using a block counter of 128, and Rhadamanthys-XOR decrypt the configuration. The structure of the configuration data, the “!RHY” format, is the same.

Posted in Uncategorized and tagged , .