Skip to content

Latest commit

 

History

History
9 lines (6 loc) · 3.21 KB

README.md

File metadata and controls

9 lines (6 loc) · 3.21 KB

Key-Derivation-Malware-POC

A POC malware that uses key derivation to protect its' payload

How it works

This PoC (proof of concept) uses AES-256 and key derivation to prevent the payload from running on any computer except the intended target. This is primarily intended as an anti-reverse engineering feature. But it can also help bypass antivirus products. There are two parts to the malware. The decryption loader and the main malware payload. The main malware payload can be anything. The decryptor stub is the primary focus of the PoC. The primary malware payload is encrypted using a key generated using one or more values unique to the target's environment. To decrypt and run the main payload, the malware has to have those values present. If the environment doesn't match the one the authors intended, the key generated will be different than the one used to encrypt the malware. The decryption will fail with an invalid key. To demonstrate, I'll use a scenario.

A nation-state's cyber warfare unit is planning to infiltrate the computer of a hostile nation's high-ranking official. The cyber unit knows the official's full name and his email address. They combine these two values to generate an AES key. They encrypt the primary malware payload using the key and insert the encrypted payload into the decryption loader. The key isn't needed anymore, so it is deleted. The cyber unit sends the decryption loader to the target official via a phishing email. The official is smart and has antivirus running on his laptop. The decryption loader is run in the antivirus sandbox, where it checks for the name and email of the official and generates an AES key based on the values it finds. The decryption loader tries to decrypt the payload using the key, but fails since the generated key was made using different values than the original key. The main payload is still encrypted, and the antivirus lets the program onto the official's computer. The decryption loader is run again, but on the official's actual laptop. The decryption loader again looks for the email and name tied to this computer's microsoft account and generates a key. Since these are the same values the malware was encrypted with originally, the key successfully decrypts and runs the main payload. If the compromise is discovered and any attempts are made to reverse engineer the malware, the decrytor will not decrypt in a virtual environment or any environment other than the official's.

There are some limitations to this technique. It is a highly targeted attack due to the malware only decrypting under very specific circumstances. The malware could of course be sent to many victims with the hope that one of them will be the target. The malware will still only be run if it reaches its' target. Post-compromise is the only realistic point that the malware could be reverse engineered as long as the encryption is properly implemented. Security researchers could determine what the malware was trying to do before compromise, but wouldn't be able to tell the exact values it needed to generate the right key. After the payload was run, researchers could determine that the malware only decrypts when certain parameters are present. They could then reproduce the environment and decrypt the malware.