Sliver, a versatile Command & Control (C2) framework built entirely in Go, has gained significant attention within the offensive security community since its launch in 2020.
Originally, the framework equipped red teams with robust post-exploitation tools, but as its popularity grew, detection rates rose. Initially, freshly created payloads could easily bypass detection, with up to 90% success, due to their large implant sizes and obfuscated code. However, as security vendors developed static signature-based detection methods for Sliver’s default configurations, the framework’s out-of-the-box payloads became much more susceptible to detection.
In response, operators began seeking ways to customize the framework to avoid detection by modern Endpoint Detection and Response (EDR) systems.
Sliver’s primary limitations include large binary sizes (up to 30 MB) and the absence of a sleep mask, which makes it harder to stay hidden in memory during idle periods. Researchers at Fortbridge found that minor code tweaks could greatly improve the framework’s ability to bypass detection mechanisms, especially those relying on static YARA signatures, a common tool for security products.
This strategy provides a practical solution that balances ease of use and effectiveness, enabling red teams to continue leveraging the framework without creating new tools from scratch.
The results of these evasion methods are significant, as they allow Sliver to be deployed in environments with modern security measures, evading detection and potentially prolonging the time red teams can operate during assessments or—more alarmingly—real-world breaches.
Detection Evasion Techniques One of the most effective evasion methods involves altering the framework’s protobuf data definitions. These definitions are essential for generating Go source code to serialize data structures, and many detections are triggered by specific strings within the .proto files, such as “ScreenshotReq” in the sliver.proto file:
message ScreenshotReq {
commonpb.Request Request = 9;
}
By renaming these message types in the source code and regenerating the protobuf files, security researchers successfully avoided triggering signature-based detections. A simple automation script utilizing Linux’s sed command demonstrates this technique:
FILE_TO_EDIT='/root/sliver-repo/protobuf/sliverpb/sliver.proto'
if [ ! -f "$FILE_TO_EDIT" ]; then
echo "The file $FILE_TO_EDIT does not exist!"
exit 1
fi
SEARCH_FOR='ScreenshotReq'
REPLACE_WITH='ScShotReq'
sed -i "s|$SEARCH_FOR|$REPLACE_WITH|g" "$FILE_TO_EDIT"
echo "sliver.proto File edited successfully."
Further modifications targeted specific Windows Defender YARA rules by replacing ASCII character strings in byte format, such as “DllUnregisterServer,” “GetJitter,” and “VoidFunc.” These strings refer to functions executed by Sliver’s dynamic libraries via LOLBin regsvr32.exe or used in conjunction with PowerSploit’s Invoke-ReflectivePEInjection.ps1 script.
When tested against Elastic EDR and Windows Defender, these tailored Sliver implants successfully avoided detection both on disk and in memory, proving that even small alterations to open-source offensive tools can significantly disrupt modern security measures.
Despite these changes, researchers caution that many of Sliver’s built-in commands may still trigger Elastic’s behavioral alerts during runtime.
Projects like better-sliver and slivercloak, which have incorporated similar modifications, highlight an increasing trend toward customizing open-source offensive security tools to improve their ability to remain undetected.
