Detect Install Digital Certificate in Splunk
Adversaries may install SSL/TLS certificates on infrastructure they control — whether acquired or compromised — to encrypt command-and-control traffic, lend credibility to credential harvesting sites, or enable adversary-in-the-middle operations. Certificate installation occurs entirely on adversary infrastructure and produces no telemetry within the victim environment. Sea Turtle (G1041) exemplifies this technique by capturing legitimate SSL certificates from victim organizations and installing them on attacker-controlled servers to conduct adversary-in-the-middle attacks against DNS infrastructure. Detection must rely on downstream signals: TLS certificate anomalies observed when victim systems connect to adversary infrastructure via proxy or NGFW TLS inspection, email security alerts for HTTPS phishing URLs, and certificate transparency (CT) log monitoring for adversary-registered domains.
MITRE ATT&CK
- Tactic
- Resource Development
- Technique
- T1608 Stage Capabilities
- Sub-technique
- T1608.003 Install Digital Certificate
- Canonical reference
- https://attack.mitre.org/techniques/T1608/003/
SPL Detection Query
index=network (sourcetype="stream:ssl" OR sourcetype="pan:traffic" OR sourcetype="cisco:asa" OR sourcetype="fortigate_traffic")
NOT (action="denied" OR action="blocked" OR action="dropped")
| where dest_port IN (443, 8443, 4443)
| eval ssl_subject=coalesce(ssl_subject, ssl_cn, tls_cert_subject, ssl_certificate_subject)
| eval ssl_issuer=coalesce(ssl_issuer, tls_cert_issuer, ssl_cert_issuer, ssl_certificate_issuer)
| where isnotnull(ssl_subject) OR isnotnull(ssl_issuer)
| eval ssl_subject_lower=lower(coalesce(ssl_subject, ""))
| eval ssl_issuer_lower=lower(coalesce(ssl_issuer, ""))
| eval dest_host_lower=lower(coalesce(dest_host, ""))
| eval SelfSignedScore=if(isnotnull(ssl_subject) AND isnotnull(ssl_issuer) AND ssl_subject==ssl_issuer, 3, 0)
| eval WeakCNScore=if(match(ssl_subject_lower, "(localhost|example\.com|\btest\b|\btemp\b|staging-|\.invalid|\bdefault\b)"), 2, 0)
| eval cn_value=replace(replace(ssl_subject_lower, "cn=\*\.", ""), "cn=", "")
| eval MismatchScore=if(len(dest_host_lower)>0 AND len(cn_value)>0 AND NOT like(dest_host_lower, "%".cn_value), 2, 0)
| eval CertRiskScore=SelfSignedScore + WeakCNScore + MismatchScore
| where CertRiskScore > 1
| eval CertRiskLevel=case(CertRiskScore>=5, "High", CertRiskScore>=3, "Medium", 1==1, "Low")
| table _time, src_ip, dest_ip, dest_host, dest_port, ssl_subject, ssl_issuer, SelfSignedScore, WeakCNScore, MismatchScore, CertRiskScore, CertRiskLevel
| sort - CertRiskScore, - _timeDetects suspicious TLS certificate properties using Splunk Stream SSL data and NGFW-sourced logs. Assigns a risk score based on three indicators: self-signed certificates where issuer equals subject (3 points), certificates with generic or placeholder CN values (2 points), and certificate CN mismatches against the destination hostname (2 points). Events scoring above 1 are surfaced for analyst review. The coalesce chain for ssl_subject and ssl_issuer handles field naming differences across Splunk Stream, Palo Alto, Cisco ASA, and Fortinet sourcetypes. Requires TLS inspection to be enabled on the feeding network device.
Data Sources
Required Sourcetypes
False Positives & Tuning
- Internal test and development servers using self-signed certificates for non-production services accessed via the corporate proxy
- Legacy applications with certificate subjects that no longer match current hostnames after infrastructure changes
- Internal CAs whose root certificates are not registered in the monitoring platform, causing their issued certificates to appear self-signed
- CDN or load balancer configurations presenting wildcard certificates where the CN wildcard does not exactly match the specific subdomain
- Security tools and network monitoring appliances performing their own TLS inspection and presenting self-signed interception certificates
Other platforms for T1608.003
Testing Methodology
Validate this detection against 4 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.
- Test 1Generate and Install Self-Signed TLS Certificate on Nginx (Linux)
Expected signal: Linux auditd: execve syscall for /usr/bin/openssl with arguments 'req', '-x509', '-newkey', '-subj'. Syslog: process creation entry for openssl invocation. File system: file creation events for /tmp/adversary-cert.pem and /tmp/adversary-key.pem (auditd OPEN+WRITE syscalls if -w /tmp -p wa rule is active). No network events during generation; network events occur when the cert is later served to connecting clients.
- Test 2Obtain Free TLS Certificate via certbot Dry Run (Let's Encrypt ACME)
Expected signal: Process creation events for 'certbot' with 'certonly --standalone --dry-run' arguments (auditd execve, Sysmon EventID 1 on Linux). Outbound TCP connections to Let's Encrypt ACME staging servers (acme-staging-v02.api.letsencrypt.org, port 443) and to port 80 on the local machine for HTTP-01 challenge validation. Socket binding event for port 80 (standalone mode binds to :80 to serve challenge). If auditd has -a network rules, connection events to Let's Encrypt IP ranges (66.133.109.0/24).
- Test 3Install Self-Signed Certificate on Windows IIS via PowerShell
Expected signal: Sysmon Event ID 1: Process Create for powershell.exe with 'New-SelfSignedCertificate' and 'DnsName' in CommandLine. PowerShell ScriptBlock Logging Event ID 4104 with full certificate creation command. Windows Security Event ID 4886 (Certificate Services received a certificate request) if Certificate Services is running. Microsoft-Windows-CertificateServicesClient-Lifecycle-System/Operational log Event ID 1006 (Certificate enrolled) for the new certificate. Registry modification to HKLM\SOFTWARE\Microsoft\SystemCertificates\MY\Certificates\<thumbprint>.
- Test 4Extract Certificate from Live Site (Sea Turtle Capture TTP)
Expected signal: Sysmon Event ID 3 (Linux via Sysmon for Linux) or auditd network connection event: outbound TCP to example.com:443 from openssl process. Process creation events for 'openssl s_client' with '-connect' argument. File creation event for /tmp/captured-cert.pem. If base64 encoding and file write occur, additional file creation event for the encoded output. Auditd rule 'auditctl -a exit,always -F arch=b64 -S execve -F exe=/usr/bin/openssl -k openssl_tls_connect' captures the connection.
References (10)
- https://attack.mitre.org/techniques/T1608/003/
- https://www.digicert.com/kb/ssl-certificate-installation.htm
- https://www.splunk.com/en_us/blog/security/tall-tales-of-hunting-with-tls-ssl-certificates.html
- https://blog.talosintelligence.com/sea-turtle-keeps-on-swimming/
- https://crt.sh/
- https://censys.io/
- https://letsencrypt.org/docs/acme-protocol/
- https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1608.003/T1608.003.md
- https://learn.microsoft.com/en-us/azure/sentinel/connect-common-event-format
- https://docs.splunk.com/Documentation/StreamApp/latest/DeployStreamApp/AboutSplunkStream
Unlock Pro Content
Get the full detection package for T1608.003 including response playbook, investigation guide, and atomic red team tests.