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

[RedTimmy Security <redazione@xxxxxxxxxxx>]

in that case it should be enough to:
- mmap(..., PROT_READ | PROT_WRITE | PROT_MAYREAD | PROT_MAYEXEC, ...)
- store the decrypted code into the above mmap'ed area
- mprotect(..., PROT_READ | PROT_EXEC)
- execute the decrypted code from the mmap'ed area

regards

> 
> 
> Hey,
> 
> mprotect(RWX)... this is not working in a properly hardened
> environment (like grsecurity/PaX mprotect restrictions ;).
> 
> Cheers,
> 
> -h
> 
> 
> On Tue, Mar 3, 2020 at 5:30 PM RedTimmy Security <redazione@xxxxxxxxxxx> 
> wrote:
> >
> > 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/
> >
> > The proof of concept code (golden-frieza project) can be found on github: 
> > https://github.com/redtimmy/golden-frieza
> >
> > regards
> >
> > _______________________________________________
> > Sent through the Full Disclosure mailing list
> > https://nmap.org/mailman/listinfo/fulldisclosure
> > Web Archives & RSS: http://seclists.org/fulldisclosure/

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