{
	"id": "3e3d6c2c-3e41-49f3-b0d0-d191f753b3d3",
	"created_at": "2026-04-06T00:19:01.608253Z",
	"updated_at": "2026-04-10T03:22:10.405149Z",
	"deleted_at": null,
	"sha1_hash": "4833c9210aff090807e710d993abc262193b7ab1",
	"title": "Threat Hunting with TLS/SSL Certificates | Splunk",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 2356946,
	"plain_text": "Threat Hunting with TLS/SSL Certificates | Splunk\r\nBy Lauren Stemler\r\nPublished: 2025-07-03 · Archived: 2026-04-05 22:26:06 UTC\r\n In this article, we’ll analyze how\r\nthreat actors exploit TLS to hide their operations and how defenders can use exposed certificate metadata to detect\r\nthem. We will discuss:\r\n1. Why TLS certificate hunting matters\r\n2. Which metadata fields remain visible\r\n3. How Splunk can be used to identify suspicious TLS activity\r\n4. Queries to enhance threat detection\r\n5. Next steps for integrating TLS analysis into security operations.\r\nhttps://www.splunk.com/en_us/blog/security/tall-tales-of-hunting-with-tls-ssl-certificates.html\r\nPage 1 of 8\n\nLet’s get started!\r\n(This article is part of our Threat Hunting with Splunk series. We’ve updated it recently to maximize your value.)\r\nThe importance of hunting in TLS certificates\r\nFirst things first: this discussion will not delve into the cryptographic intricacies of TLS and SSL. Instead, it’s\r\nimportant to note that TLS (Transport Layer Security) is the modern, more secure successor to SSL (Secure\r\nSockets Layer). For simplicity, the terms \"SSL\" and \"TLS\" will be used interchangeably throughout this article.\r\nTLS has become today’s standard for secure online communications, offering stronger encryption and enhanced\r\nsecurity protocols. However, attackers can exploit TLS to conceal their malicious activities. While TLS effectively\r\nencrypts the content of communications, it does not entirely obscure metadata, such as the identities of the\r\ncommunicating parties.\r\nAs cyber threats evolve, attackers have adapted to advances in security. A decade ago, malware command-and-control (C2) traffic often relied on plaintext HTTP, making it straightforward for security teams to intercept and\r\nanalyze. Today, attackers leverage TLS encryption to mask their traffic, complicating efforts to monitor and detect\r\ntheir activities.\r\nDespite these challenges, defenders are not without options. After all, we know that attackers are creatures of\r\nhabit, they reuse infrastructure and leave data behind that defenders can use to trace their actions back to them. By\r\nidentifying these clues, security teams can uncover malicious activity and link it back to its source.\r\n(Note: This article assumes that you have already captured TLS metadata in Splunk. If not, implementing\r\nmetadata collection will need to be done before diving into these hunting techniques.)\r\nWhat unencrypted information does SSL leave?\r\nTLS certificates are like digital ID cards for websites and services, proving their authenticity while enabling\r\nencrypted information. But here’s the catch — while the actual communication is encrypted, the certificate itself\r\ncontains unencrypted metadata that attackers can’t hide. Defenders like you can use this metadata to identify and\r\ntrack suspicious activity.\r\nThe fields within a TLS certificate are generated either by cryptographic algorithms or manually entered during\r\nthe creation of the certificate.\r\nhttps://www.splunk.com/en_us/blog/security/tall-tales-of-hunting-with-tls-ssl-certificates.html\r\nPage 2 of 8\n\nHow does this help defenders? Because these fields can be unique and are often shared by adversaries across their\r\nbackend infrastructure. So… what are some unique fields? The ones that we are primarily interested in are:\r\nssl_cert_self_signed\r\nssl_subject_country\r\nssl_subject_state\r\nssl_issuer\r\nssl_subject_locality\r\nssl_subject_unit\r\nssl_subject_organization\r\nssl_validity_end\r\nssl_subject_common_name\r\nssl_serialnumber\r\nssl_cert_sha1\r\nhttps://www.splunk.com/en_us/blog/security/tall-tales-of-hunting-with-tls-ssl-certificates.html\r\nPage 3 of 8\n\nThese fields can help security teams detect anomalies, track threat actors, and distinguish legitimate infrastructure\r\nfrom adversarial activity.\r\nNow that we know TLS certificates leave behind valuable metadata, how do we actually use this information?\r\nSince adversaries are using TLS to encrypt command and control (C2) communications, it’s important to look\r\nbeyond the encryption itself and analyze the exposed metadata. Since we have a hypothesis that malware is\r\nbeginning to use SSL to encrypt its communications, I believe it is also reasonable to assume that they would use\r\nSSL to encrypt communication on alternative ports!\r\nFinding encrypted communications in SSL\r\nFor nearly all the following examples, we will be using SSL data captured in Stream. Let’s look:\r\nsourcetype=stream:tcp ssl_cert_sha1=* NOT (dest_port=443 OR dest_port=993 OR dest_port=995 OR dest_port=465 OR\r\n | stats VALUES(ssl_issuer) VALUES(dest_port) VALUES(ssl_subject_common_name) VALUES(dest_ip) count(ssl_subject_\r\nBOOM! You’ll notice the 3rd and 4th entry have very suspicious metadata and link to some nasty looking\r\ndomains and IP addresses. A quick pivot to VirusTotal shows that there have been malicious files hosted on that IP\r\naddress in the past:\r\nhttps://www.splunk.com/en_us/blog/security/tall-tales-of-hunting-with-tls-ssl-certificates.html\r\nPage 4 of 8\n\nFinding unique values in SSL certificates\r\nFor our next search, let’s try and find values in SSL certificates that are unique. We will do a little pre-parsing by\r\nshowing only SSL certificates that are not part of the Alexa 1 Million top sites. This is done with the UT_PARSE\r\nmacro (which you can install with URL Toolbox) and the Alexa 1 Million list. You can download a sample of\r\nAlexa 1 Million from this GitHub as a properly formatted lookup table.\r\nsourcetype=stream:tcp ssl_cert_sha1=*\r\n | stats VALUES(ssl_issuer) AS ssl_issuer VALUES(ssl_subject_common_name) AS ssl_subject_common_name VALUES(dest\r\n | search count=1\r\n | eval list=\"*\"\r\n |`ut_parse(ssl_subject_common_name,list)`\r\n | lookup alexa-1MM domain AS ut_domain\r\n | fillnull value=NULL rank\r\n | search rank=NULL\r\n | stats VALUES(ssl_cert_sha1) VALUES(ssl_subject_common_name) AS ssl_subject_common_name VALUES(dest_ip) AS des\r\nhttps://www.splunk.com/en_us/blog/security/tall-tales-of-hunting-with-tls-ssl-certificates.html\r\nPage 5 of 8\n\nRight away we see some very odd values in the ssl_issuer and ssl_subject_common_name fields. If we search\r\nfor that SHA1 certificate value (ssl_cert_sha1), we find that various websites have identified that SHA1 hash as\r\nmalicious.\r\nDetecting bad SSL certificates\r\nhttps://www.splunk.com/en_us/blog/security/tall-tales-of-hunting-with-tls-ssl-certificates.html\r\nPage 6 of 8\n\nFinally, what about detecting certificates that are “known bad”? The most common repository of externally\r\nidentified certificates is from https://sslbl.abuse.ch/. With minimal effort, you can turn that list of malicious SHA1\r\nSSL certificates into a lookup table in Splunk. The example below assumes that you have done that already, but if\r\nyou want an example, visit my GitHub and download the ssl_blacklist_2.csv file.\r\nindex=* sourcetype=stream:tcp ssl_cert_sha1=*\r\n | lookup ssl_block_list sha1_cert AS ssl_cert_sha1\r\n | search reason=*\r\n | stats VALUES(ssl_issuer) AS issuer VALUES(dest_port) AS \"Destination Port\" VALUES(ssl_subject_common_name) AS\r\nThe results below show that we have five hits against our data and a quick explanation of each malicious\r\ncertificate.\r\nNext steps in security operations\r\nFinding malicious SSL/TLS in your environment is just the first step. Just like finding malicious IP addresses or\r\nfile hashes you will need to pivot and research using tools like\r\nwww.passivetotal.com\r\nwww.censys.io\r\nhttps://www.circl.lu/services/passive-ssl/\r\nOnce you understand how to use these certificates, try creating workflow actions in Splunk to pivot\r\n“automagically”.\r\nIf you’d like an example, check out my sample workflow action for www.censys.io located on my github page. If\r\nyou are interested in more information on hunting and pivoting with TLS certificates, check out this great talk\r\nfrom my good friend Mark Parsons on hunting a TLS certificate. Until then…\r\nhttps://www.splunk.com/en_us/blog/security/tall-tales-of-hunting-with-tls-ssl-certificates.html\r\nPage 7 of 8\n\nHappy hunting!\r\nSource: https://www.splunk.com/en_us/blog/security/tall-tales-of-hunting-with-tls-ssl-certificates.html\r\nhttps://www.splunk.com/en_us/blog/security/tall-tales-of-hunting-with-tls-ssl-certificates.html\r\nPage 8 of 8",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://www.splunk.com/en_us/blog/security/tall-tales-of-hunting-with-tls-ssl-certificates.html"
	],
	"report_names": [
		"tall-tales-of-hunting-with-tls-ssl-certificates.html"
	],
	"threat_actors": [],
	"ts_created_at": 1775434741,
	"ts_updated_at": 1775791330,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/4833c9210aff090807e710d993abc262193b7ab1.pdf",
		"text": "https://archive.orkl.eu/4833c9210aff090807e710d993abc262193b7ab1.txt",
		"img": "https://archive.orkl.eu/4833c9210aff090807e710d993abc262193b7ab1.jpg"
	}
}