Re: ELF launcher for encrypted binaries decrypted on-the-fly and executed in memory

[Phil Ashby <Phil.Ashby () gbgplc com>]

Not a particularly new topic (eg: 
https://reverseengineering.stackexchange.com/questions/3184/packers-protectors-for-linux) but always interesting to see 
new work in the space.

The challenges here IMO are twofold:
- Protecting the key material (a challenge shared with DRM): in this demo its not stored but requested via interactive 
prompt which helps (apart from swap space leakage).
- Obfuscating the launcher otherwise it's signature will be the indicator of compromise. This becomes a circular 
problem if the launcher is stored on the target, better to inject directly into memory from the remote end?

Cheers,
Phlash.
________________________________
From: Fulldisclosure <fulldisclosure-bounces () seclists org> on behalf of RedTimmy Security <redazione () segfault it>
Sent: 01 March 2020 15:05
To: fulldisclosure () seclists org <fulldisclosure () seclists org>
Subject: [FD] ELF launcher for encrypted binaries decrypted on-the-fly and executed in memory

Hi all,
think about a typical Red Team operation, in which tools that commonly trigger security alerts to SOC, such as 
“procmon” or “mimikatz”, are uploaded in a compromised machine and then launched without having antivirus, antimalware 
or endpoint protection solutions complaining about that.

There are several ways this could be achieved. The most comprehensive one is probably to encrypt the whole ".text" 
section of a binary and find a way to decrypt it on-the-fly in memory at runtime, just before the code is executed. The 
binary should live in encrypted form in the filesystem so that no static analysis would be possible even if identified 
and copied somewhere else. It should be only decrypted on the fly in memory when executed, in order to prevent dynamic 
analysis too, unless the decryption key is known. Easier to say than to do.

First, "text" is not the only section where valuable information can be retrieved. The content of relocations and 
dynamic symbol tables are places to look at too. Their analysis is normally enough to reveal the nature of the binary 
itself. A way to circumvent this fact has to be found.

Similarly, ".rodata" and ".data" are valuable sources of information and nothing more than the "strings" command is 
necessary to get this information out of a binary. For example when symbols are resolved at runtime with dlopen() and 
dlsyms(), the string of the function to be resolved lives in the ".rodata" section.

We have considered all these factors and described a method for the decryption at runtime of ELF binaries in a blog 
post: 
https://www.redtimmy.com/red-teaming/blue-team-vs-red-team-how-to-run-your-encrypted-binary-in-memory-and-go-undetected/<https://protect-eu.mimecast.com/s/ngiyCVOMkhP9B6msQbdV6?domain=redtimmy.com>

The proof of concept code (golden-frieza project) can be found on github: 
https://github.com/redtimmy/golden-frieza<https://protect-eu.mimecast.com/s/XdAfCW6NlsyG3KZipahbe?domain=github.com>

regards

_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure<https://protect-eu.mimecast.com/s/f96JCXDO0FM0ARjf7bKyX?domain=nmap.org>
Web Archives & RSS: 
http://seclists.org/fulldisclosure/<https://protect-eu.mimecast.com/s/EOgmCYEPnh6OYqmSjc2Ys?domain=seclists.org>

_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/