#### **Environment Buildout** This is less focused on the infrastructure set-up of Sliver, and more so on the later evasion for the Sliver shellcode. With that being said, I decided to keep my environment simple. A sandboxed off AD environment consisting of two Windows servers, and a non domain joined Kali box that is on the same VNet as the Windows servers. ![[Pasted image 20250723224158.png]] Additionally, there is a separate isolated WindowsVM that is utilized for compiling of any executables. I had chose to keep this separate to minimize the potential for contamination within the AD network if something got loose. #### **Setting the Stage** I’m not going to go too into depth on setting up the stager and listeners. [This](https://dominicbreuker.com/post/learning_sliver_c2_06_stagers/) is a great article for reference, that walks through setting up a mtls listener and generating the shellcode for your stager. One initial question I did have was what the big difference was between a stager and implant within Sliver, and why couldn’t I just obfuscate my implant shellcode and execute it directly? The implants are fairly well signatured, and being written in GO they are MASSIVE. For context, a Sliver implant can be anywhere around 15 Mb compared to around 2 Kb for a stager. ![[Pasted image 20250723224256.png]] 15 Mb is relatively small, there can’t be that much shellcode for this right? Outputting the above Sliver implant to C shellcode is around 733,000 lines ![[Pasted image 20250723224313.png]] Compared to our AES encoded stager, which we will see later on, which is around 33 lines. ![[Pasted image 20250723224330.png]] How exactly is the shellcode for Sliver stagers so small? It’s simply as the name implies, shellcode that reaches out to our target server to download the Sliver implant as a secondary stage. The focus of this article is on the execution of the shellcode for the Sliver stager to get a working session/beacon. Thus, that is where we will begin. For context the shellcode that will be used we can generate within Sliver. ![[Pasted image 20251026211520.png]] Looking at the file output we get our shellcode … ![[Pasted image 20250723224432.png]] Opening up Visual Studio a new C program will be created with the following code below, inserting our shellcode output above into the shellcode variable below. This is not perfect OPSEC, and in fact there’s multiple issues we would run into later if trying to bypass any sort of advanced threat protection. Issues related to raw shellcode, read-write-execute regions of memory, and the context of execution for the function pointer just to name a few. ![[Pasted image 20251026211557.png]] After compiling our executable as x64 Release within Visual Studio, we can drop this onto our Windows AD machine where Defender is enabled. Upon dropping our executable onto the machine, Defender picks it off instantly. ![[Pasted image 20250723224609.png]] Defender primarily has 3 areas it detects on: 1. On-disk 2. In-memory 3. Behavioral We can query Defender to get an idea on what caused our executable to be detected as malware. ![[Pasted image 20250723224731.png]] The output of Get-MpThreatDetection indicates the detection was on the ‘file’ PrinterDriver_x64.exe (the name of our malware executable created within Visual Studio). Likely indicating in this scenario, the executable was detected on-disk. Thankfully on-disk bypassing is fairly trivial, and there is tools that can assist with this. Rasta Mouse has developed a tool called [‘ThreatCheck’](https://github.com/rasta-mouse/ThreatCheck) that aids in finding bad bytes that are flagged by Defender/AMSI. ![[Pasted image 20250723224750.png]] ThreatCheck identifies bad bytes at sequence 0x17E9. We can search for these bytes within any decompiler to determine what code is being flagged on. Using Binja, we can search for the byte sequence ‘D8 58 44 8B’ which was identified as the start of our bad bytes per the screenshot above. There is a successful hit that comes back to a string that looks very similar to the original shellcode[] string in the C program compiled above. This is a good indicator that Defender Antivirus is flagging on the declaration of our string in our code. ![[Pasted image 20250723224818.png]] Armed with this knowledge, there is a multitude of ways we can attempt to obfuscate our shellcode. For purpose of our testing, we’ll attempt to obfuscate the shellcode as IPv4 addresses. This isn’t a brand new technique, and there is many tools that can assist with this. For simplicity sake, I’ve chosen to utilize a modified version of [HellShell](https://github.com/NUL0x4C/HellShell), but choosing to write your own obfuscation/deobfuscation functions is pretty straight forward if choosing to go that route. HellShell is a simplistic way to obfuscate shellcode as it outputs the deobfuscation functions which you can insert directly into your code. #### **IPV4 Fuscation** To translate the stager shellcode above into IPV4 obfuscated shellcode, a binary file needs to be generated within Sliver. It is important to generate a raw file if using something such as HellShell. Trying to input a C shellcode file will not deobfuscate correctly and you will never get your staged implant to download (something I found out the hard way). ![[Pasted image 20251026211623.png]] From here we can take this file and input into HellShell to generate the obfuscated shellcode to insert into our program. Moving the FOOLISH_SANDBAR payload over to the HellShell directory, C shellcode can be generated and dropped into the runner we are trying to create. ![[Pasted image 20251026211652.png]] This will output a C source file with the deobfuscation functions and shellcode within the file. ![[Pasted image 20250723224944.png]] This can be inserted into the program created within Visual Studio earlier. ![[Pasted image 20251026211812.png]] Now after compiling the code within Visual Studio, ThreatCheck can be run against the newly created binary. ![[Pasted image 20250723225032.png]] Signs show initial success, and we attempt to drop the file and execute on our target system. First we will make sure our Sliver server is up and listeners are set-up. ![[Pasted image 20250723225051.png]] Dropping our payload onto the Windows Server and executing does not appear to be picked off by Defender. ![[Pasted image 20250723225106.png]] Jumping back to the Sliver server, there is a successful call back with a session established. ![[Pasted image 20250723225122.png]]