IV. Payload Encryption Modules
DropEngine uses payload encryption to make droppers resistant to both reverse engineering efforts and signature-based detections. This capability is facilitated by the following module types:
- Crypters - Used to encrypt shellcode before it included in the rendered payload. All Crypters correspond to at least one Decrypter module.
- EKeys - Used to derive encryption keys that can be used by Crypter modules
- Decrypters - Subroutines that are rendered into the generated payload that can be used to reverse the encryption provided by one or more Crypter modules.
- DKeys - Used to derive decryption keys that can be used by Decrypter modules.
These module types are described in the sections that follow.
Crypters are Input Modules that convert plaintext shellcode into ciphertext. Decrypters are Output Modules that generate a payload component that can be used to reverse the effects of a Crypter module.
You can only select one Crypter and one Decrypter per generated payload. The Crypter and Decrypter you select must be compatible with one another, as well as the interface module that you are using.
To list all Crypter and Decrypter modules that are compatible with your interface, use the --list, --compatible, and --interface flags as described in II. Listing Modules.
Once you've chosen a set of Crypter and Decrypter modules, you can instruct DropEngine to run them using the --crypter and --decrypter flags as shown in the following example.
Command:
python dropengine.py --build [..snip..] --crypter do_some_crypto --decrypter undo_some_crypto [..snip..]
EKey modules are executed prior to payload generation, and are used to derive encryption keys that can be used by DropEngine's Crypter module to encrypt the payload. DKey modules are rendered into the payload itself, and are used to derive the keys used by the payload Decrypter component to convert the encrypted shellcode into plaintext.
DropEngine currently supports three basic key types:
- Static
- Environmental
- Remote
These key types are described in the subsections that follow.
Static keys are the most basic key type offered by DropEngine, and consist of a hard-coded encryption key that is stored within the payload itself. These keys can be advantageous in that they are highly simplistic and don't require a lot of moving parts. However, they offer no expectation of payload privacy in the event that your dropper is compromised.
Environmental keys are derived entirely or in part from one or more values in the target execution environment (e.g. active username, external IP, hard drive serial number). Environmental keys are advantageous in that they are difficult to guess (the actual encryption key is not stored in the payload), and that they allow highly targeted attacks (the shellcode will only be decrypted on machines with the key's required attributes).
This is a topic that has already been covered in detail in other places, so this guide won't cover it in any level of depth. However, if you'd like to know more about environmental keying, this blog post (and the work it cites) is a good starting point:
Remote keys are retrieved by the payload from a remote source over HTTP(S), DNS< or some other communication channel. Remote keys are particularly effective when combined with well-designed non-attributable attack infrastructure (e.g. placed behind a redirector). One advantage to using remote keys is that they are not stored in the payload file, and can be protected in transit using TLS. They are also less targeted than environmental keys, which could be advantageous in some situations.
As with environmental keying, remote keying is a fairly old concept that has already been covered in detail elsewhere. Once again, I recommend using the following blog post (and the work it cites) as a starting point:
DropEngine currently only supports one set remote key modules, which are dkey_remote_csharp_otk_http and ekey_one_time_remote_http. To use these keys, you'll need to select them as you would any other corresponding set of EKey and DKey modules (described in later sections).
When these modules are used as part of a payload, the encryption key is stored in a local SQLite database along with a unique identifier.
The stored key can then be made available to the payload by running DropEngine's integrated key server, as shown in the following command:
Command:
# make otk available on port 443
python remote_otk_server.py --lport 443 --lhost 0.0.0.0
The unique identifier can then used by the payload to retrieve the encryption key from key server over HTTP(S). When the payload is successfully retrieved, the key server deletes it from the database.
DropEngine supports the use of Key Stacking, which is the practice of combining the results of multiple keying methods to create a single combined key. For example, a key could be comprised of four parts - a hard drive serial number, an external IP address, a nonce stored in the payload file, and a one-time key (OTK) retrieved over HTTPS. Stacked keys can be advantageous in that they can be more difficult to guess.
The concept of Key Stacking is illustrated in the following diagram, which describes how DropEngine organizes stacked keys within generated payloads.
The exact syntax required to use Key Stacking is described in the next section.
You can select and stack an arbitrary number of EKey and DKey modules. The only limitation is that you must select Ekey and Dkey modules that are compatible with one another, and are compatible with the interface that you're using.
To list all EKeys and DKeys that are compatible with your interface, use the --list, --compatible, and --interface flags as described in II. Listing Modules.
Once you've chosen a set EKey and DKey modules, you can instruct DropEngine to run them using the --ekeys and --dkeys flags as shown in the following example.
Command:
python dropengine.py --build [..snip..] --dkeys dapples doranges dgrapes dpears --ekeys eapples, eoranges, egrapes, epears [..snip..]
Note: You must provide an EKey modules for every DKey module you pass to DropEngine, and vice versa.
Note: EKey and DKey modules must be passed to DropEngine in the same order. For example, if you plan on using EKey modules A, B, and C, which correspond to DKey modules 1, 2, and 3 respectively, then you must pass them as follows: --ekeys A B C --dkeys 1 2 3.