DIY Genetic Malware: EBOWLA

Back in 1998, the year that Mongolia went from a 46 hour to a 40 hour work week, another ground breaking event happened— the publishing of Environmental Key Generation towards Clueless Agents by Riordan and Schneier. This paper discussed using environmental factors on a host as a means to encrypt and protect data and code from inspection. The idea discussed is simple: use unique identifiable information from the host as the key to encrypt the data/code you want to protect. If encrypted blobs were moved from the host or captured in transit to the host, the encrypted data would be safe from disclosure.

18 years later, there hasn’t been publicly available code for environmental keying. Some folks thought Riordan and Schneier’s paper was a just theory, others decided to stay away for ethical reasons, and a few developed commercial products. However, there have been high profile malware, like Gauss and Flashback which use an environmental keying mechanism to protect their payloads. Since there were no public examples of code that pentesters and defenders  could use to generate samples themselves for testing we decided to build and release our own.

Riordan and Schneier’s simple, but elegant solution to protect data and target select systems caught our eye. So did its potential use in our industry, incorporation into malware, and wide use in attacker “what-if” scenarios. We decided to build upon these concepts and release our version of genetic malware “EBOWLA” as a project, with source, that researchers and others can poke at, learn from, and criticize.

The name was chosen as a play on words and the utter destruction and chaos that many people fear (wrongly so) from an easy to use and effective environmental keying tool. EBOWLA stands for Ethnic BioWeapon Limited Access:

Ethnic: Targeted subset of companies based on a group attribute.

Bio: Changes based on environment through keying material or execution circumstances similar to biological pathogens in the wild.

Limited Access: Due to the ineffectiveness of modern RE tools to analyze the payload.

The name is a not-so-subtle jab at the security industry, and the hype machine around cyber pathogens, mutating malware, and other FUD. Our intent is not to create the next unstoppable worm— and we don’t take the actual Ebola outbreak lightly— but we do want to offer a proof of concept and a useful tool for Pen Testers.

Recommended Use:​

• Use it during a penetration test to keep custom payloads from being used outside the target organization, including an expiration date on it's usage.
• Defenders and malware reverse engineers can use it to test their preparedness and techniques against malware that use such techniques. You can formulate processes for attacking the encrypted data within the binary into your reverse engineering and incident response process.
• Deploy scripts with credentials or other sensitive operations that will only run on the target environment / host.

A few things to consider:

• The project isn’t perfect, we are aware of issues in our One Time Pad (OTP) implementation and left them in the code for our release (it’s actually closer to a digital book cipher). We hope that people will review and point out the subtle issues we left implemented (no one has yet as of this posting).

• One thing that surprised us about translating the concept to code was how easy it was to create. We used python and go, and only learned golang a few months ago.

• The project isn’t about malware: there is not any malware in our code repo. It’s a deployment method for code, compiled or position independent assembly instructions (ahem shellcode). The entire concept is closer to a highly-targeted digital rights management (DRM) system which protects proprietary information (code) from access by unauthorized systems.

• Obviously, this project could be used to deploy malicious code— such is the risk of many projects aimed at advancing the work we do. Our intention and hope is that it will be used for good.

Technical Details

The three protection mechanisms implemented in our proof of concept are AES file based keying, AES environmental based keying, and One Time Pad (closer to a digital book cipher) based off a known file on the target’s system. We choose the payload type and select options from user specified options in genetic.config. On the author’s machine we protect the payload (company proprietary or attacker code) with one of the protection mechanisms and create a loader, python or golang. This loader contains the protected payload and is deployed to any number of systems, but will only execute the payload for the hosts which meet all the criteria, thus generating the correct key for decryption.

AES protection mechanisms generate their encryption key from either a unique file on the client system or a list of pre-defined environment variable that must be present on the target system. These environment variables can range from file system path, external IP, time/date, and windows variables.

Our OTP implementation is basically a lookup table of offsets to rebuild a protected binary from a known good binary on the target’s machine. This mechanism is the most targeted and transmits a file that can not be reassembled without the exact file originally used.

Technical details, slides from infiltrate, and all code can be found on our github page: https://github.com/Genetic-Malware/Ebowla . We welcome your comments, feedback, and most of all your help to create modules to support other languages.