Fidelis Blog
Author

Threat Research Team

The Fidelis Threat Research team is comprised of expert security researchers whose sole focus is generating accurate and actionable intelligence to better secure customers. Together, they represent over... Read More

Comments

Shining a Light on Xenon: Unravelling the Crypter

We’ve recently observed a new crypter called Xenon used to deliver Locky, a strain of ransomware, and Ruckguv, a type of malware that can download and install other types of malware. Xenon employs a novel trick to bypass debuggers, which we’ll describe here along with the techniques it uses. We also provide a Python script to decrypt objects packed using Xenon and the Krypton crypter, which we believe is its predecessor.

Delivering and monetizing malware involves a large chain of independent tools – exploit kits, traffic distribution systems, spambots and more. The crypter occupies a special place in this chain, where it’s typically used by threat actors to evade common security measures, such as antivirus and spam filters.

Many companies use crypters for legitimate purposes – to guard their systems, protect their code and products, and safeguard their intellectual property by protecting their binaries from reverse engineering. Crypters sold on underground forums serve similar purposes, but are more focused on bypassing sandbox/antivirus detections. The authors of these tools are acutely aware that researchers are poking at them, so they go to great lengths to evade detection and analysis.

The Xenon crypter seems aptly named. Parallels exist between Xenon crypter and Xenon, an odorless and colorless gas with very low chemical reactivity. Ultimately, every crypter author aspires to effectively hide malware to render it virtually invisible to evade observation.

In early 2016, Krypton was used along with Radamant ransomware. It was also sold on underground forums. When we first looked, Xenon struck us as familiar in that it uses the same unhandledexceptionfilter chaining method to start the real code. It also uses the beingdebugged flag as part of the XOR decoding process, so if you’re in a debugger the payload will not run properly.

But most interestingly, Xenon uses an undocumented NtYieldExecution interrupt that will give up the current thread’s execution time to any other thread. So if the current thread is in a debugger, but running a single-threaded program, then the timing will be off. It appears Xenon uses this technique in a loop to run a custom sleep routine.

Xenon uses the same header structure as Krypton but uses a third XOR key:

1

The XOR loops in both Krypton and Xenon — as well as in previous crypters — are always the same, using the IsBeingDebugged flag as an offset to the XOR key:

2

The offset to the payloads header is stored in a dword val, as shown above.

3

In the above diagram, you can see:

  • The second XOR after it executes the long NtYieldExecution unhandledexception chain, followed by an
  • LZNT Decompress, and the
  • Third XOR

These collective techniques form an effective defense against detection and analysis. And yet uncracking just this one layer can reveal numerous malware strains hidden beneath the crypter. Xenon uses some tricks that we haven’t seen to good effect.

This analysis has been captured in a pair of unpacking scripts available for download at: https://github.com/fideliscyber

-Fidelis Threat Research Team Researcher Jason Reaves

Stay up to date on all things security

Subscribe to the Threat Geek Blog