{
	"id": "3a0ac328-6729-4bfd-9dac-f55f7210a13c",
	"created_at": "2026-04-06T01:32:40.547246Z",
	"updated_at": "2026-04-10T03:20:24.607213Z",
	"deleted_at": null,
	"sha1_hash": "1cc8f2e2899a4150598e92e6943ffa3750b0363c",
	"title": "Detecting and decrypting Sliver C2 – a threat hunter's guide",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 3918739,
	"plain_text": "Detecting and decrypting Sliver C2 – a threat hunter's guide\r\nBy Immersive\r\nPublished: 2023-04-24 · Archived: 2026-04-06 00:41:29 UTC\r\nContributors\r\nOriginating from the Bishop Fox team, Sliver is an open-source, cross-platform, and extensible C2 framework. It’s\r\nwritten primarily in Go, making it fast, portable, and easy to customize. This versatility makes it a popular\r\nchoice among red teams for adversary emulation and as a learning tool for security enthusiasts.\r\nThe Sliver C2 framework has features catering to both beginner and advanced users. One of its main attractions is\r\nthe ability to generate dynamic payloads for multiple platforms, such as Windows, Linux, and macOS. These\r\npayloads, or “slivers,” provide capabilities like establishing persistence, spawning a shell, and exfiltrating data.\r\nWhen it comes to communication, Sliver supports a wide range of communication protocols, including HTTP,\r\nHTTPS, DNS, TCP, and WireGuard. This ensures that C2 traffic is flexible, stealthy, and can blend in with\r\nnormal network traffic.\r\nThe open-source nature and ease of use make Sliver a powerful tool for red teams and a powerful weapon for\r\nthreat actors and adversaries. Team Cymru, which tracks the use of C2 frameworks, has observed an increase in\r\nSliver’s popularity over recent months.\r\nhttps://www.immersivelabs.com/blog/detecting-and-decrypting-sliver-c2-a-threat-hunters-guide/\r\nPage 1 of 25\n\nhttps://twitter.com/teamcymru_S2/status/1626597384284438532\r\nThis is echoed in recent reporting published by Microsoft and the UK’s NCSC, detailing how threat actors use\r\nSliver to target large organizations.\r\nAs an offensive tool that adversaries are using more frequently, it’s important that defenders understand the\r\ncapabilities and how to detect the presence of these C2 frameworks. The Immersive Labs CTI team has taken a\r\ncloser look at Sliver and identified some methods that incident responders can use to detect Sliver through file,\r\nmemory, and network artifacts.\r\nThis report details these technical findings and the detection engineering process we used to discover them.\r\nTo capture all of the traffic and artifacts necessary for analyzing the implant, we first set up a specialized range\r\nmade for detection engineering with high-fidelity log collection and EDR capabilities. We deployed this using a\r\nCyber Range template in Immersive Labs. You can achieve the same outcome by manually deploying your own\r\ninfrastructure and replicating the steps in this report.\r\nOur range had the following essential elements:\r\nHost machine we controlled to deploy the implant\r\nEvent logging\r\nSysmon\r\nSplunk\r\nhttps://www.immersivelabs.com/blog/detecting-and-decrypting-sliver-c2-a-threat-hunters-guide/\r\nPage 2 of 25\n\nNetwork logging\r\nFull packet capture\r\nDNS logging\r\nTLS secrets\r\nEDR\r\nVelociraptor\r\nReset/restore\r\nHeimdall Range network diagram\r\nWith a defensive range in place, we then had to deploy the attacker’s infrastructure. In this instance, we kept it\r\nsimple, a single EC2 instance on a public IP address, making it easy to open the required TCP, HTTP/S, and DNS\r\nports to the range.\r\nWe could have deployed Sliver inside the range, but at that point, it would have had an internal IP address. So, for\r\na little more realism, we used a completely separate AWS EC2 instance for our attacker’s infrastructure.\r\nDNS\r\nFor the DNS, we used a simple Cloudflare configuration, allowing us to set both the ‘A’ records required for the\r\nHTTP/S C2 comms and create the Name Server record for DNS C2 without requiring multiple domains.\r\nhttps://www.immersivelabs.com/blog/detecting-and-decrypting-sliver-c2-a-threat-hunters-guide/\r\nPage 3 of 25\n\nCloudflare DNS configuration\r\nThis setup uses the default settings as per the BishopFix wiki entry on setup and configuration of DNS.\r\nSliver server\r\nFor this research, we weren’t looking at how to use the Sliver C2 framework, so we simply connected directly to\r\nthe server instead of using the multiplayer mode, which allows multiple operators to manage the C2 while\r\nmaintaining OpSec. A more traditional deployment looks like this.\r\nhttps://github.com/BishopFox/sliver/wiki\r\nIn our configuration, instead of having the remote operators, we just used direct console access to the C2 Server.\r\nFor more details on how to use Sliver, please refer to Sliver’s documentation.\r\nInstallation\r\nAs a Go application, installation is pretty easy. You can download the release file you want, make the file\r\nexecutable, then run it.\r\nhttps://www.immersivelabs.com/blog/detecting-and-decrypting-sliver-c2-a-threat-hunters-guide/\r\nPage 4 of 25\n\nRunning Sliver from the CLI\r\nWith the Sliver C2 server running, we started our listeners for HTTP and DNS. We could have also started an\r\nHTTPS listener, but the protocol is the same as HTTP, and this way, we could review the network protocols more\r\neasily.\r\nConfiguration\r\nConfiguring Sliver\r\nWith the listeners now running, we had to create some implants to send to our hosts to trigger the initial\r\ncompromise.\r\nGenerating payloads in the Sliver CLI\r\nImportant delivery\r\nhttps://www.immersivelabs.com/blog/detecting-and-decrypting-sliver-c2-a-threat-hunters-guide/\r\nPage 5 of 25\n\nFor this report, we aren’t interested in weaponized delivery mechanisms. So for transferring payloads to the client,\r\nwe opted to use a simple `python3 -m http.server` on the Sliver host and a PowerShell `iwr` command on the\r\ntarget host.\r\nPushing the implant to the target host\r\nWith the infrastructure set up, it was time to jump into the analysis. The implants can be obfuscated and modified\r\nusing a number of techniques – too many to document here. This report provides some basic detections for the\r\nbinary files, but the main focus is on detecting the implant in memory or via the C2 protocols.\r\nWe generated the core payload as a compiled Go binary. This makes it extremely portable across multiple\r\noperating systems and architectures. However, as a statically compiled Go binary, this implant is not small, with\r\nan average file size of 16 Mb. To counter this, Sliver supports using other frameworks and tools, such as\r\nmsfvenom or Metasploit, to create smaller compatible stagers.\r\nMemory detection is easier as the entire Go binary must be unpacked into memory regardless of any packing of\r\nthe binary or staged delivery.\r\nCanary domains\r\nWhen generating payloads, Sliver has the option to add canary domains; these are domain names provided at\r\ncompile time and won’t be encoded. Instead, they can be found in the binary, in clear text. The real C2 IPs or\r\ndomains will be encrypted in the binary.\r\nYara – binary\r\nWe used a simple Yara rule to detect an unmodified Sliver implant generated for Windows, Linux, or MacOS.\r\nhttps://www.immersivelabs.com/blog/detecting-and-decrypting-sliver-c2-a-threat-hunters-guide/\r\nPage 6 of 25\n\nhttps://github.com/Immersive-Labs-Sec/SliverC2-Forensics/tree/main/Rules\r\nYara – memory\r\nThis rule is designed to detect Sliver running in memory; the binary rule above is unsuitable for detection in\r\nmemory as it uses some fixed offsets to reduce false positives on file scans.\r\nhttps://www.immersivelabs.com/blog/detecting-and-decrypting-sliver-c2-a-threat-hunters-guide/\r\nPage 7 of 25\n\nhttps://github.com/Immersive-Labs-Sec/SliverC2-Forensics/tree/main/Rules\r\nSliver has four main callback protocols:\r\nDNS\r\nmTLS\r\nWireGuard\r\nHTTP(S)\r\nAll Sliver traffic is encrypted, and, depending on the protocol, you may use additional encoding to obfuscate the\r\ntraffic further.\r\nDNS\r\nWhen communicating over DNS, the Sliver implant encodes its messages into subdomain requests and responses.\r\nThis isn’t dissimilar to other DNS tunneling methods.\r\nDNS traffic in Wireshark\r\nhttps://www.immersivelabs.com/blog/detecting-and-decrypting-sliver-c2-a-threat-hunters-guide/\r\nPage 8 of 25\n\nSliver differs from most C2s in how the data is packaged and encoded, maximizing the amount of data that can be\r\nsent in any single request.\r\nStructure\r\nAs DNS isn’t connection-oriented, Sliver needs a way to track the order and sequence of data in encoded packets.\r\nTo do this, it makes use of a protobuf.\r\nDNS Protobuff\r\nEncoding\r\nOnce the message has been packed into a protobuf, it needs to be encoded into a subdomain string. The default\r\nencoding is Base58 with a fallback to Base32, in case resolvers don’t adhere to the DNS standards completely.\r\nTo further increase the obfuscation of the encoding, Sliver also uses subtly modified alphabets for both Base32\r\nand Base58 encoding.\r\nCustom alphabets for encoding\r\nDetection\r\nAs the encoded and encrypted payload is limited to 254 characters per subdomain, with a limited character count\r\nper request, C2 servers and implants using DNS generate significant traffic orders of magnitude higher than\r\nother protocols like HTTP. This can make it trivial to detect in organizations that log DNS traffic. Two simple\r\nqueries are to look for subdomains with an excessive subdomain count or a large number of bytes per request.\r\nhttps://www.immersivelabs.com/blog/detecting-and-decrypting-sliver-c2-a-threat-hunters-guide/\r\nPage 9 of 25\n\nUnique subdomain counts in Kibana\r\nDNS traffic volumes in Kibana\r\nThe examples above show the event counts after sending three or four commands over a five-minute period.\r\nHTTP(S)\r\nhttps://www.immersivelabs.com/blog/detecting-and-decrypting-sliver-c2-a-threat-hunters-guide/\r\nPage 10 of 25\n\nThe protocol is identical for both HTTP and HTTPS, except for the extra layer of encryption added in HTTPS\r\nconnections. This means TLS interception or host-based network logging with Zeek or PacketBeat is required.\r\nIt’s important to note that Sliver’s HTTP settings are highly configurable, and the details below apply to the\r\ndefault configuration.\r\nStructure\r\nSliver uses file extensions to determine what type of request is being made\r\n.woff – Used for stagers\r\n.html – Key exchange messages\r\n.js – Long poll messages\r\n.php – Session messages\r\n.png – Close session messages\r\nA random path is created for each request, which is ignored and has no relevance to the message or the request.\r\nHowever, there are a fixed number of default paths and filenames, meaning you can create some generic\r\ndetections.\r\nhttps://www.immersivelabs.com/blog/detecting-and-decrypting-sliver-c2-a-threat-hunters-guide/\r\nPage 11 of 25\n\nHTTP Default configuration\r\nTo reiterate, all of these paths and extensions can be configured by the server operator.\r\nEncoding\r\nMessages are encoded using one of the following encoders:\r\nhttps://www.immersivelabs.com/blog/detecting-and-decrypting-sliver-c2-a-threat-hunters-guide/\r\nPage 12 of 25\n\nNonce\r\nThe encoder is selected at random each time a new message is sent. The encoder being used is encoded as a nonce\r\nvalue and added as a query parameter to each HTTP request. For example, given the following URL, you can\r\neasily determine which encoder is used with a little bit of Python code.\r\nDecoder for nonce values\r\nThis gives an `encoded_id` value of 13, meaning it was encoded with a modified Base64 alphabet.\r\nHex\r\nThis is just a simple hex-encoded payload.\r\nBase32, 58, and 64\r\nThese three encoders use a modified alphabet but are otherwise standard for encoding and decoding.\r\nhttps://www.immersivelabs.com/blog/detecting-and-decrypting-sliver-c2-a-threat-hunters-guide/\r\nPage 13 of 25\n\nCustom alphabets for encoding\r\nEnglish words\r\nThis encoder uses lists of English words as the encoding mechanism. The words themselves are hardcoded into\r\nthe implant, with 1,420 in total.\r\nHTTP POST using English words encoder\r\nThe words themselves aren’t important; the position in the list or the sum of the characters per word is used to\r\nencode and decode. An example decoder written in Python is shown below.\r\nhttps://www.immersivelabs.com/blog/detecting-and-decrypting-sliver-c2-a-threat-hunters-guide/\r\nPage 14 of 25\n\nEnglish words decoder\r\nGzip\r\nGzip compression can be set as a standalone encoder or combined with other encoders, but uses the standard Gzip\r\nalgorithm.\r\nDetection\r\nIf the implant is configured to use HTTP, or you have the ability to TLS intercept at your proxy or edge gateway,\r\nthen these snort rules can be used to detect Sliver HTTP traffic.\r\nhttps://www.immersivelabs.com/blog/detecting-and-decrypting-sliver-c2-a-threat-hunters-guide/\r\nPage 15 of 25\n\nSnort rules for HTTP C2\r\nhttps://www.immersivelabs.com/blog/detecting-and-decrypting-sliver-c2-a-threat-hunters-guide/\r\nPage 16 of 25\n\nDetection of Sliver by Snort rules\r\nIf you collect network logs from hosts using a collector like Zeek or Packet Beat, the same patterns can be\r\ndetected in event logs.\r\nPacketbeat logs in Kibana\r\nThe transport encryption process is well documented in the official documentation. We won’t cover all the details\r\nhere except to say that each message is individually encrypted using a session key generated by the implant each\r\ntime the implant executes.\r\nSession keys\r\nhttps://www.immersivelabs.com/blog/detecting-and-decrypting-sliver-c2-a-threat-hunters-guide/\r\nPage 17 of 25\n\nThis session key is passed securely to the Sliver server. However, if you can grab the key from memory, you’ll be\r\nable to decrypt any intercepted network traffic.\r\nModified Sliver\r\nTo find the session key in memory, we first had to find out what it looked like and if it existed somewhere in a\r\ndata structure that we could parse. The easiest way to do this is by knowing the key and then looking for it in\r\nmemory.\r\nThis was fairly simple to achieve. As Sliver is open source, we grabbed a copy of the source code and modified it\r\nto report the session keys.\r\nEditing Sliver Source\r\nWith the changes in place, we were able to compile a new version of the server and push it to our attacker\r\ninfrastructure.\r\nThen, when the implant connected back, we also got the session key printed to the screen.\r\nPrinting Sliver Session keys to screen\r\nProcess memory\r\nThe next thing to do was to identify the running process for the implant. This is relatively simple to do using an\r\nEDR like Velociraptor and the Yara rule we created earlier.\r\nhttps://www.immersivelabs.com/blog/detecting-and-decrypting-sliver-c2-a-threat-hunters-guide/\r\nPage 18 of 25\n\nVelociraptor Hunt\r\nRunning the hunt against the range returned a process dump for the matching process.\r\nProcess memory capture in velociraptor\r\nAlternatively, if you know the name of the process, you could use a standard procump hunt.\r\nThen, we downloaded this dump to see if we could find the keys.\r\nExtracting keys\r\nUsing the keys we identified in our modified Sliver server, we scanned the process dump to try and find the keys.\r\nhttps://www.immersivelabs.com/blog/detecting-and-decrypting-sliver-c2-a-threat-hunters-guide/\r\nPage 19 of 25\n\nHex editor showing captured session key\r\nThe good news is that the key can always be found in memory for an active implant. The bad news is that it\r\nseemed to be in an unreliable location, meaning we couldn’t easily read this value.\r\nWe ran the same process several times, and a pattern emerged.\r\nThat process was simply:\r\n1. Stop the running process\r\n2. Start the running process\r\n3. Send a handful of commands to the implant from the server\r\n4. Wait a minute or two\r\n5. Run the hunt to dump process memory\r\n6. Search for the key that’s displayed for each session\r\n7. Go to step 1\r\nWe saw the pattern\r\n00 00 [32 bytes key] ?? ?? ?? 00 C0 00 00\r\nevery time we located the key. This pattern was also present when we looked at the DNS implant’s behavior.\r\nScanning memory for this pattern yielded several thousand results – 17,206  matching patterns for this specific\r\nmemory capture. But a quick check showed that our key was in that matching set.\r\nIdeally, we needed to reduce that number down. If we could get the number of results small enough, we could\r\nbrute force the key given an encrypted payload. So, how could we reduce the results?\r\nhttps://www.immersivelabs.com/blog/detecting-and-decrypting-sliver-c2-a-threat-hunters-guide/\r\nPage 20 of 25\n\nThe session key itself is derived from a SHA256 hash of random bytes. We assumed that any given session key\r\nwouldn’t have a series of three sequential null bytes in it, and were able to reduce this list down to only 38\r\npossible keys.\r\nIt’s possible that any given session key could end up with a sequence of multiple null bytes, but the chances are\r\npretty slim. To prove this, we wrote a small script that generated 10 million SHA256 values from random and then\r\nchecked for possible chains of null bytes.\r\nhttps://www.immersivelabs.com/blog/detecting-and-decrypting-sliver-c2-a-threat-hunters-guide/\r\nPage 21 of 25\n\nCalculating SHA256 values\r\nAs you can see from 30 million generated SHA256 values, the likelihood of three or four consecutive null bytes is\r\npretty low at 0.0004%.\r\nIf we could capture the traffic through packet capture, log capture (DNS), or even extracting fragments from\r\nprocess memory, there would be enough information to decrypt the traffic.\r\nhttps://www.immersivelabs.com/blog/detecting-and-decrypting-sliver-c2-a-threat-hunters-guide/\r\nPage 22 of 25\n\nAll the tools and scripts used to parse PCAP files and decrypt traffic have been published to the Immersive Labs\r\nGitHub repository.\r\nDNS payloads\r\nDNS logs are arguably the easiest to collect, either from PCAP files or from event logs and SIEMS.\r\nUsing the sliver_pcap_parser.py script in the GitHub repository, we provided a domain name, and the script\r\nextracted all possible encoded values ready for the next step, decryption.\r\nParsing DNS from PCAPs\r\nAs you can see from 30 million generated SHA256 values, the likelihood of three or four consecutive null bytes is\r\npretty low at 0.0004%.\r\nHTTP payloads\r\nThe same script parses HTTP requests and responses for possible encoded payloads. HTTP payloads are written in\r\na JSON file that contains all the required fields for the decryption script to process.\r\nhttps://www.immersivelabs.com/blog/detecting-and-decrypting-sliver-c2-a-threat-hunters-guide/\r\nPage 23 of 25\n\nParsing HTTP from PCAPs\r\nProcess memory\r\nDepending on the time between observing the implant and collecting the memory, payloads can also be captured\r\nin the memory dump. You can find the Python script sliver_memdump_parser.py in the GitHub repository to\r\nscan a process dump for these fragments.\r\nDecode and decrypt\r\nWith a process dump and the encoded payloads extracted from a suitable source, we then attempted to decode and\r\ndecrypt the session data.\r\nThe script first scanned the process memory dump for all possible session keys, then tested each key using the\r\nprovided payloads until it achieved a successful decode.\r\nhttps://www.immersivelabs.com/blog/detecting-and-decrypting-sliver-c2-a-threat-hunters-guide/\r\nPage 24 of 25\n\ndecode and decrypting HTTP traffic\r\nThe message data is presented in its protobuf structure; the requests and responses contain the message type, so it\r\nwould be possible to use the sliver_pb2 protobuf parser to clean up this data. But that’s an exercise left for the\r\nfuture.\r\nIf you’re an Immersive Labs CyberPro customer, you might enjoy our Sliver C2: Memory Forensics lab, a\r\nhands-on practical lab with example payloads and captures.\r\nIf you want to exercise all the elements of this report, from identifying processes, dumping memory, and\r\ndecrypting traffic from PCAP files, then our TeamSim: Detecting Sliver is available for customers with Team\r\nSim licensing.\r\nYou can also find the detection engineering range without the addition of the attacker infrastructure in the Ranges\r\nDashboard as the Heimdall Detection Engineering range.\r\nSource: https://www.immersivelabs.com/blog/detecting-and-decrypting-sliver-c2-a-threat-hunters-guide/\r\nhttps://www.immersivelabs.com/blog/detecting-and-decrypting-sliver-c2-a-threat-hunters-guide/\r\nPage 25 of 25",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://www.immersivelabs.com/blog/detecting-and-decrypting-sliver-c2-a-threat-hunters-guide/"
	],
	"report_names": [
		"detecting-and-decrypting-sliver-c2-a-threat-hunters-guide"
	],
	"threat_actors": [],
	"ts_created_at": 1775439160,
	"ts_updated_at": 1775791224,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/1cc8f2e2899a4150598e92e6943ffa3750b0363c.pdf",
		"text": "https://archive.orkl.eu/1cc8f2e2899a4150598e92e6943ffa3750b0363c.txt",
		"img": "https://archive.orkl.eu/1cc8f2e2899a4150598e92e6943ffa3750b0363c.jpg"
	}
}