Understand Encryption in Malware: AES (Lu0Bot Example)

AES (Advanced Encryption Standard) is a symmetric encryption algorithm. It’s a block cipher, which means it operates on fixed block sizes of 128, 192 or 256 bits. Malware often uses AES to encrypt traffic, and we’ll explore an example of this today.

This article is part of our series about malware encryption.

In the previous article, we covered encryption basics and looked at examples of XOR, which is a stream cipher. Today, we’ll focus on AES, which is a block cipher. 

We’ll discuss:

• The differences between block ciphers and stream ciphers, and what it means when it comes to decryption.
• How to identify AES and decrypt it in CyberChef.

Let’s get started!

A few titbits about AES

Let’s begin with a quick overview. 

☝️ With CyberChef, we don’t necessarily need to understand the inner workings of AES in-depth (but if you want a detailed look at encryption concepts, check out the first part of this series). 

So, we’ll round out the theoretical part with a few quick facts and talk about AES in the context of malware traffic analysis.

Understanding Block vs stream Cyphers

AES is an example of a block cipher, but how does this affect analysis?

• Block ciphers encrypt data in fixed-size blocks, typically 128 bits (16 bytes) for AES. Imagine a machine that always takes 16 bytes and seals them in a box. The box can only be opened with a key that has precisely 16 teeth.

• Stream ciphers, on the other hand, encrypt data one bit or byte at a time. They work like a conveyor belt, continuously processing data as it arrives.

☝️ This means that to decrypt data encrypted with AES, the decryption key must match the block size (128, 192, or 256 bits for AES variants) for the decryption to work correctly.

For instance, look what happens if we remove a single symbol from the encrypted message above.

Let’s remove 8 at the end.

This makes decrypting block ciphers a bit more challenging, as you not only have to find the correct key but also understand the structure of the encrypted data — and malware authors won’t make this easy.

Understanding encryption modes and Initialization Vector

Block ciphers have modes, which determine how the blocks are processed and linked together. We’ve listed the common ones below:

• ECB (Electronic Codebook): Identical plaintext blocks produce identical ciphertext.
• CBC (Cipher Block Chaining): Each block XORed with previous ciphertext
• CTR (Counter). Transforms block cipher into stream cipher.
• OFB (Output Feedback): Turns block cipher into stream cipher, using previous output for next block.
• CFB (Cipher Feedback): Converts block cipher to stream cipher. Feedback ciphertext means that previous ciphertext is used for next block.
• GCM (Galois/Counter): Combines counter mode with authentication.

The different modes are there to make the encryption more unpredictable by adding another layer of randomness. But the main thing is, you have to select the right mode in your decryption software.

Another crucial element that block ciphers like AES have, but that stream ciphers typically lack, is the initialization vector, or simply IV.

The IV is a unique value used to initialize the encryption process-it ensures that identical plaintext blocks are encrypted into different ciphertext blocks, even under the same key.

In the end, this means that you’ll need to extract both the VI and the key to decrypt AES encryption.

Enter both the key and the IV and select the correct mode to decrypt AES traffic.

Decrypting AES-encrypted traffic: Lu0bot case study

Let’s walk through the process using this recording of an analysis session of Lu0Bot in ANY.RUN as an example. 

Before we can decrypt AES, we need to confirm that AES was indeed used. The only way to find this out is by reverse engineering the code. This step varies for each malware family/sample, and we’ve covered our analysis of Lu0Bot in depth in this article.

During analysis, among other things, we found a key: becfe83392d83ef8c743ea00711a25c8

Next, we used a Node.js debugger, running it directly in a virtual machine in ANY.RUN, to step through the code.

If you’re curious about the setup, we’ve recorded the entire process here. 

Lu0Bot generates the traffic array through a multi-step process. After analyzing multiple samples and debugging them in ANY.RUN, we discovered the following sequence:

1. It likely starts by adding an initialization vector (IV) to the array. (Lu0Bot dynamically generates a new IV for each transmission, so that the encrypted traffic is never the same twice. Effectively, it encrypts traffic with a different IV every time.)

2. Two bytes are added at indexes 4-5, above them are bytes that will be overwritten later with a key. Starting from index 6, the traffic data is stored.

3. The IV is then added to the beginning of the array.

4. Finally, another byte is appended to the start of the array, resulting in the following structure:

• First, there is a single byte
• Followed by the 16-byte IV
• Two bytes are skipped
• The encoded message follows

We also found an object with encryption parameters:

Thus, we learned that the encryption algorithm is AES, and the method is CBC.

Knowing this, we can navigate back to ANY.RUN and look at the encrypted traffic in this task. Click on the connections section, and then open the last UDP connection:

(This is just a small glimpse into Lu0Bot’s traffic patterns – this malware exhibits quite peculiar behavior, and we plan to provide an in-depth analysis of its communication mechanisms in a future report.)

We know that Lu0Bot adds an extra byte, then the IV takes up the next 16 bytes, skips two bytes, and the encoded message follows:

With this, we can extract the IV, highlighted in yellow, and the message, highlighted in red. Now we have all the pieces to decrypt the traffic in CyberChef:

About ANY.RUN 

ANY.RUN helps more than 400,000 cybersecurity professionals worldwide. Our interactive sandbox simplifies malware analysis of threats that target both Windows and Linux systems. Our threat intelligence products, TI Lookup, Yara Search, and Feeds, help you find IOCs or files to learn more about the threats and respond to incidents faster. 

Advantages of ANY.RUN 

ANY.RUN helps you analyze threats faster while improving detection rates. The platform detects common malware families with YARA and Suricata rules and identifies malware behavior with signatures when detection by family is not possible.

With ANY.RUN you can:

• Detect malware in under 40s.
• Interact with samples in real time.
• Save time and money on sandbox setup and maintenance
• Record and study all aspects of malware behavior.
• Collaborate with your team
• Scale as you need.

Try the full power of ANY.RUN for free

Request free trial →