So how hard is it to hide a payload in an executable?

This is a really common practice in malware delivery. Malware authors will regularly use Cryptors, Packers, and Protectors when building payloads. These are all used to make detecting and reversing the malware payloads more difficult. Cryptors encrypt the payload, camouflaging the contents, effectively hiding them from signature-based detection algorithms. Of course, if the content is encrypted with the same password each time, then AV software can detect the encrypted payload, so if you're a malware author it's really best to randomize these (this can be difficult, though). Packers essentially compress the payload. Some malware will use a hybrid cryptor/packer strategy to hide a payload, where they use multiple encryptions and compression algorithms, multiple times, to change the payload binary signature (Duqu2 did this, for example). Protectors make reverse engineering a malware sample more difficult.

Payload hiding is pretty established in the windows world, but you can also do it in the Mac OS and Linux environments.

The good news is that it's pretty difficult to completely stay memory resident in Linux and Mac OS using this approach, although FreeBSD does supply a library loading routine that will allow you to dynamically load a library from memory (i.e. via fdlopen(.)andshm_open(.)). Stock Linux and Mac OS don't, though Mac OS does provide some relatively complex lower-level deprecated interfaces that do this.

We'll use standard dynamic library loading techniques via the dlopen(.) family to load a packaged payload. We'll have a simple, innocuous application that contains an encrypted, malicious payload (well, it won't really be malicious, but we'll pretend it is). We'll extract the payload, load it into the application, and execute functions from the payload. The payload itself will be encoded via AES 256-bit encryption into the data segment of the file.

Next time, we'll start to build out the infrastructure to make this happen. Stay tuned!