The previous post in the series discussed possible options to hide Sliver c2 on the public internet. Cloudflares tunnel feature was used as an example implementation to tunnel Implant traffic through cloudflares edge network. The benefit of this modell is that the c2 backend is not directly exposed to the public internet and cloudflare generates and presents a valid TLS certificate for the tunnel entry domain.
Adversarial infrastructure is volatile nowadays. IOCs like IP-Adresses, Domain names and TLS certificates are subject to change. This post explores various ways in which C2 backends like sliver can be fingerprinted/identified on the internet.
Defenders are motivated to develop methods to detect malicious infrastructure in order to improve their detection/hunting capabilities. One example is CobaltStrikes whitespace in the HTTP response in 2018. The special space present in the HTTP Response of CobaltStrike Team Servers prior to Version 3.12 was used to identify/fingerprint CS Team Servers:
One of Fox-IT’s InTELL analysts, with a trained eye for HTTP header anomalies, spotted an unusual space in the response of a Cobalt Strike team server in one of our global investigations into malicious activity. Though this might seem irrelevant to a casual observer, details such as these can make a substantial difference in combating malicious activity, and warranted additional research into the set-up of the team servers.
Another fingerprinting technique is shared by Heige of KnownSec 404 Team.
https://80vul.medium.com/identifying-cobalt-strike-team-servers-in-the-wild-by-using-zoomeye-debf995b6798 https://80vul.medium.com/identifying-cobalt-strike-team-servers-in-the-wild-by-using-zoomeye-part-2-acace5cc612c
https://github.com/knownsec/pocsuite3
https://github.com/BishopFox/sliver/wiki/HTTP(S)-C2
JA3/JARM
JARM is an active TLS server fingerprinting tool created by Salesforce engineering. JARM offers the possibilty to fingerprint TLS Servers with the following goals:
- Quickly verify that all servers in a group have the same TLS configuration.
- Group disparate servers on the internet by configuration, identifying that a server may belong to Google vs. Salesforce vs. Apple, for example.
- Identify default applications or infrastructure.
- Identify and track malware command and control infrastructure and other malicious servers on the Internet.
TLS handshake revisited
TLS is used to authenticate and encrypt communication. To initiate a TLS session, a client will send a TLS Client Hello message following the TCP three-way handshake. This packet and the way in which it is generated is dependent on packages and methods used when building the client application. The server will respond with a TLS Server Hello packet. TLS servers formulate their Server Hello packet based on the details received in the TLS Client Hello packet. See following Message flow for a full handshake:
[Client] [Server]
ClientHello ------------------------>
ServerHello
Certificate*
ServerKeyExchange*
CertificateRequest*
<------------------------ ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished ------------------------>
[ChangeCipherSpec]
<------------------------ Finished
Application Data <----------------> Application Data
The manner in which the Server Hello is formulated for any given Client Hello can vary based on how the application or server was built including:
- Operating system
- Operating system version
- Libraries used
- Versions of those libraries used
- The order in which the libraries were called
- Custom configuration
JARM works by actively sending 10 TLS Client Hello packets to a target TLS server and capturing specific attributes of the TLS Server Hello responses. The aggregated TLS server responses are then hashed in a specific way to produce the JARM fingerprint.
┌──(kali㉿redstar-os)-[~/jarm]
└─$ python jarm.py sliverc2.port9.org
[...]
JARM: "3fd21b20d00000021c43d21b21b43d41226dd5dfc615dd4a96265559485910"
┌──(kali㉿redstar-os)-[~/jarm]
└─$ python jarm.py entry.random-malware-domain.com
[...]
JARM: "27d3ed3ed0003ed1dc42d43d00041d6183ff1bfae51ebd88d70384363d525c"
Can we find the identified Sliver hash in the wild?
JARM support has been added to several internet mapping services like Shodan or Censys. In addition Silas Cutler has scanned the internet for port 443 and obtained JARM values for each of these hosts. This data was made available as an SQLite database (see twitter thread).
The shodan cli application can be used to search and export the search results:
┌──(kali㉿redstar-os)-[~/]
└─$ shodan init <SHODAN API KEY>
┌──(kali㉿redstar-os)-[~/jarm]
└─$ shodan download search ssl.jarm:"3fd21b20d00000021c43d21b21b43d41226dd5dfc615dd4a96265559485910"
Search query: ssl.jarm:3fd21b20d00000021c43d21b21b43d41226dd5dfc615dd4a96265559485910
Total number of results: 1782
Query credits left: 97
Output file: search.json.gz
[#############################################################] 99% 00:00:00
Saved 1000 results into file search.json.gz
Shodan reported 1792 occurrences of the JARM hash. The result set can be filtered even more by searching for specifics in the HTTP Response of the sliver webserver e.g:
┌──(kali㉿redstar-os)-[~/1]
└─$ shodan download search ssl.jarm:3fd21b20d00000021c43d21b21b43d41226dd5dfc615dd4a96265559485910 "HTTP/1.1 404 Not Found" "Cache-Control: no-store, no-cache, must-revalidate" "Content-Length: 0"
Search query: ssl.jarm:3fd21b20d00000021c43d21b21b43d41226dd5dfc615dd4a96265559485910 HTTP/1.1 404 Not Found Cache-Control: no-store, no-cache, must-revalidate Content-Length: 0
Total number of results: 67
Query credits left: 95
Output file: search.json.gz
[###################################-] 98% 00:00:02
Saved 67 results into file search.json.gz
The sliver development team has added the option to optionally randomize server JARM fingerprint.
As Sliver is open source, all the fingnerprints could be changed. For example by the Sliver team in next releases of the tool, or by other people who may want to run customised versions. Goal of this post is to demonstrate several ways to fingerprint Sliver, and also give people ideas on how to discover and fingerprint other C2s with their own techniques.
C2 Infrastructure is only directly accessible through the whitelisted terraform environment source IP-Adress. Implants comunicate through Cloudflare’s Edge Network.
Please note: We are exposing the C2 server directly and don’t use redirectors for simplicity in this blog post.