Detect Install Digital Certificate in Elastic Security
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/
Elastic Detection Query
any where process.name : ("curl", "wget", "powershell.exe", "certutil.exe", "bitsadmin.exe") and (process.command_line : ("*.bin", "*.exe", "*.dll", "*.ps1", "*.bat", "*.vbs", "*.hta") or network.direction : "egress" and destination.port in (80, 443) and process.parent.name : ("winword.exe", "excel.exe", "outlook.exe", "mshta.exe", "wscript.exe", "cscript.exe"))Elastic EQL translation of the T1608.003 detection logic. Detects suspicious TLS certificate properties in outbound HTTPS connections using proxy and NGFW logs ingested via CommonSecurityLog. Scores three cer
Data Sources
Required Tables
False Positives & Tuning
- Internal development, test, or lab environments using self-signed certificates for services that should not be exposed externally but are reachable via proxy
- Legacy applications with hardcoded certificate subjects that no longer match the current hostname following a server rename or migration
- Internal Certificate Authorities (CAs) whose root certificates were not imported into the monitoring infrastructure, causing valid internal certificates to appear self-signed
- CDN providers (Cloudflare, Akamai, Fastly) presenting wildcard certificates where the wildcard CN does not exactly match the specific subdomain being accessed
- VPN concentrators, reverse proxies, or internal load balancers presenting a shared certificate that does not match every individual backend hostname
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.