Open Source and information security mailing list archives

Message-ID: <958207434.962955.1583268872555@webmail.register.it>
Date: Tue, 3 Mar 2020 21:54:32 +0100 (CET)
From: RedTimmy Security <redazione@...fault.it>
To: Hunger <hunger@...ger.hu>
Cc: fulldisclosure@...lists.org
Subject: Re: [FD] ELF launcher for encrypted binaries decrypted on-the-fly
 and executed in memory

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@...fault.it> 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/

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives