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 <redazi...@segfault.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/
