Add Ekko / Sleep Obfuscation to Sliver #1805
Conversation
|
Looks awesome we'll try to get this reviewed and merged shortly! |
rkervella
left a comment
rkervella
left a comment
There was a problem hiding this comment.
Couple of things to changes before I can dynamically test that one:
- please don't print to stdout when you're not in debug mode
- generate the XOR key dynamically at runtime instead of the hardcoded buffer of
0x55values.
|
Heya, @rkervella ! Thanks for the first review. Cleaned out the prints and randomised XOR key generation. |
rkervella
left a comment
rkervella
left a comment
There was a problem hiding this comment.
Just found a few more things that need to be changed.
| f.BoolP("evasion", "e", false, "enable evasion features (e.g. overwrite user space hooks)") | ||
| f.BoolP("skip-symbols", "l", false, "skip symbol obfuscation") | ||
| f.BoolP("disable-sgn", "G", false, "disable shikata ga nai shellcode encoder") | ||
| f.BoolP("sleep-obfuscation", "B", false, "apply ekko in-memory sleep obfuscation") |
There was a problem hiding this comment.
This should probably be in coreBeaconFlags instead since sleep obfuscation is only relevant for beacons (unless I'm mistaken, feel free to correct me).
| debug, _ := cmd.Flags().GetBool("debug") | ||
| evasion, _ := cmd.Flags().GetBool("evasion") | ||
| templateName, _ := cmd.Flags().GetString("template") | ||
| sleepObfuscation, _ := cmd.Flags().GetBool("sleep-obfuscation") |
There was a problem hiding this comment.
Same idea, please move this to generate-beacon.go instead.
|
Alright, I finally started testing this, and I couldn't get the beacon process to self-encrypt when sleeping: I tried with a debug beacon to confirm Ekko is properly called, and it is. |
|
Hey, @rkervella, Busy time of the year. I believe the self-encryption is working as intended. If you reconfig the beacon to have short sleep time (a few seconds) you'll see the memory address changing from RW to RWX whenever it's time for the beacon callback. while awake, RWX: while sleeping, RW: Well spotted on the process randomly hanging after some time. I've also found an old process hanging on a test server as you described. It appears that the memory region stays stuck in RWX and never self-encrypts/ goes back to sleep. |
|
|
||
| hThread, err := windows.OpenThread(0xFFFF, false, te32.ThreadID) | ||
| if err != nil { | ||
| continue |
There was a problem hiding this comment.
Doesn't this create potential for an infinite loop?
E.g. we snapshot, one of the threads was short-lived and is no longer valid when we attempt to call OpenThread on it, error occurs and we loop to reattempt opening the same invalid thread ID.
Also, this code doesn't validate the size of the thread structure from the Thread32* calls, which as documented may be less than the total size of the structure (and may risk providing us with an invalid ThreadID)
|
|
||
| hThread, err := windows.OpenThread(0xFFFF, false, te32.ThreadID) | ||
| if err != nil { | ||
| continue |
There was a problem hiding this comment.
Same infinite loop issue here right?
|
Hey @armysick , Wouldn't changing to RWX make it easier for an EDR to detect suspicious behavior? A more common approach is to transition from RW to RX (Havoc example), which might be less noticeable. Is there a specific advantage to using RWX in this case? Looking forward to your thoughts—thanks! |
5 participants
Card
This PR implements Ekko / in-memory sleep obfuscation for a beacon.
Details
Based on the work of https://github.com/scriptchildie/goEkko, adapted from https://github.com/Cracked5pider/Ekko, it pauses Go runtime and encrypts the beacon's memory region with the Ekko technique.
Command -B / --sleep-obfuscation added on generate beacon to support this feature.
Only applicable for Windows.
Beacon while performing operations / active:
Beacon while in its sleep duration:
