T1608.003 IBM QRadar · QRadar

Detect Install Digital Certificate in IBM QRadar

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/

QRadar Detection Query

IBM QRadar (QRadar)
sql
SELECT sourceip as "SourceIP", destinationip as "DestinationIP", UTF8(payload) as "URL", username as "Username", devicetime as "EventTime", CASE WHEN UTF8(payload) ILIKE '%.exe%' OR UTF8(payload) ILIKE '%.dll%' OR UTF8(payload) ILIKE '%.bin%' THEN 80 WHEN UTF8(payload) ILIKE '%paste%' OR UTF8(payload) ILIKE '%transfer.sh%' OR UTF8(payload) ILIKE '%gofile%' THEN 75 WHEN UTF8(payload) ILIKE '%certutil%' OR UTF8(payload) ILIKE '%bitsadmin%' THEN 70 ELSE 50 END as "RiskScore" FROM events WHERE LOGSOURCETYPENAME(devicetype) IN ('Proxy', 'Windows', 'Zscaler Internet Access') AND (eventid = 4688 OR destinationport IN (80, 443)) ORDER BY "RiskScore" DESC LAST 24 HOURS
medium severity low confidence

IBM QRadar AQL translation of the T1608.003 detection. Uses SQL-like syntax with risk scoring. Detects suspicious TLS certificate properties in outbound HTTPS connections using proxy and NGFW log

Data Sources

Windows Security Event LogProxyZscaler Internet Access

Required Tables

events

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
Download portable Sigma rule (.yml)

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.

  1. 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.

  2. 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).

  3. 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>.

  4. 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.

Unlock Pro Content

Get the full detection package for T1608.003 including response playbook, investigation guide, and atomic red team tests.

Response PlaybookInvestigation GuideHunting QueriesAtomic Red Team TestsTuning Guidance

Related Detections