From 43400b8003e3b0841382d8701a982bcaef7b521d Mon Sep 17 00:00:00 2001 From: "Mariusz B. / mgeeky" Date: Sat, 2 Oct 2021 13:18:33 +0200 Subject: [PATCH] update --- README.md | 56 +++++++++++++++++++++++++++---------------------------- 1 file changed, 27 insertions(+), 29 deletions(-) diff --git a/README.md b/README.md index b250087..5b65258 100644 --- a/README.md +++ b/README.md @@ -27,33 +27,6 @@ This implementation along with my [ThreadStackSpoofer](https://github.com/mgeeky --- -### It's not a novel technique - -The technique is not brand new, nothing that I've devised myself. Merely an implementation showing the concept and its practical utilisation to let our Offensive Security community catch up on offering made by commercial C2 frameworks. - -Actually, I've been introduced to the idea of flipping shellcode's memory protection couple of years back through the work of [**Josh Lospinoso**](https://github.com/JLospinoso) in his amazing [Gargoyle](https://github.com/JLospinoso/gargoyle). - -Here's more background: -- [gargoyle, a memory scanning evasion technique](https://lospi.net/security/assembly/c/cpp/developing/software/2017/03/04/gargoyle-memory-analysis-evasion.html) -- [Bypassing Memory Scanners with Cobalt Strike and Gargoyle](https://labs.f-secure.com/blog/experimenting-bypassing-memory-scanners-with-cobalt-strike-and-gargoyle/) - -**Gargoyle** takes the concept of self-aware and self-fluctuating shellcode a way further, by leveraging ROP sequence calling out to `VirtualProtect`. -However the technique is impressive, its equally hard to leverage it with Cobalt Strike's Beacon without having to kill its thread and keep re-initializing Beacon while in memory. - -That's far from perfect, however since we already operate from the grounds of our own self-injection loader process, we're able to do whatever we want with the environment in which shellcode operate and hide it however we like. This technique (and the previous one being [ThreadStackSpoofer](https://github.com/mgeeky/ThreadStackSpoofer)) shows advantages from running our shellcodes this way. - -The implementation of fluctuating to `PAGE_NOACCESS` is inspired by [ORCA666](https://github.com/ORCA666)'s work presented in his https://github.com/ORCA666/0x41 injector. -ORCA showed that: - -1. we can initialize a vectored exception handler (VEH), -2. flip shellcode's pages to no-access -3. and then catch Access Violation exceptions that will occur as soon as the shellcode wants to resume its execution and decrypt + flip its memory pages back to Read+Execute. - -This implementation contains this idea implemented, available with option `2` in ``. -Be sure to check out other his projects as well. - ---- - ## How it works? This program performs self-injection shellcode (roughly via classic `VirtualAlloc` + `memcpy` + `CreateThread`). @@ -74,8 +47,6 @@ Having awaited for expected amount of time, when shellcode gets back to our `MyS ### Fluctuation to `PAGE_NOACCESS` works as follows -(do note that the idea was borrowed from _ORCA666_'s [0x41](https://github.com/ORCA666/0x41) project): - 1. Read shellcode's contents from file. 2. Hook `kernel32!Sleep` pointing back to our callback. 3. Inject and launch shellcode via `VirtualAlloc` + `memcpy` + `CreateThread` ... @@ -90,6 +61,33 @@ Having awaited for expected amount of time, when shellcode gets back to our `MyS --- +### It's not a novel technique + +The technique is not brand new, nothing that I've devised myself. Merely an implementation showing the concept and its practical utilisation to let our Offensive Security community catch up on offering made by commercial C2 frameworks. + +Actually, I've been introduced to the idea of flipping shellcode's memory protection couple of years back through the work of [**Josh Lospinoso**](https://github.com/JLospinoso) in his amazing [Gargoyle](https://github.com/JLospinoso/gargoyle). + +Here's more background: +- [gargoyle, a memory scanning evasion technique](https://lospi.net/security/assembly/c/cpp/developing/software/2017/03/04/gargoyle-memory-analysis-evasion.html) +- [Bypassing Memory Scanners with Cobalt Strike and Gargoyle](https://labs.f-secure.com/blog/experimenting-bypassing-memory-scanners-with-cobalt-strike-and-gargoyle/) + +**Gargoyle** takes the concept of self-aware and self-fluctuating shellcode a way further, by leveraging ROP sequence calling out to `VirtualProtect`. +However the technique is impressive, its equally hard to leverage it with Cobalt Strike's Beacon without having to kill its thread and keep re-initializing Beacon while in memory. + +That's far from perfect, however since we already operate from the grounds of our own self-injection loader process, we're able to do whatever we want with the environment in which shellcode operate and hide it however we like. This technique (and the previous one being [ThreadStackSpoofer](https://github.com/mgeeky/ThreadStackSpoofer)) shows advantages from running our shellcodes this way. + +The implementation of fluctuating to `PAGE_NOACCESS` is inspired by [ORCA666](https://github.com/ORCA666)'s work presented in his https://github.com/ORCA666/0x41 injector. +He showed that: + +1. we can initialize a vectored exception handler (VEH), +2. flip shellcode's pages to no-access +3. and then catch Access Violation exceptions that will occur as soon as the shellcode wants to resume its execution and decrypt + flip its memory pages back to Read+Execute. + +This implementation contains this idea implemented, available with option `2` in ``. +Be sure to check out other his projects as well. + +--- + ## Demo The tool `ShellcodeFluctuation` accepts three parameters: first one being path to the shellcode and the second one modifier of our functionality.