D3-PCA Passive Certificate Analysis: Detect and Verify

Attackers depend on certificates for phishing sites, encrypted command and control and impersonation, and every one of those certificates leaves a trace a defender can read without ever connecting to the attacker's server. MITRE D3FEND names this countermeasure Passive Certificate Analysis (D3-PCA) and defines it as "Collecting host certificates from network traffic or other passive sources like a certificate transparency log and analyzing them for unauthorized activity." It sits under the Detect tactic as a child of Certificate Analysis (D3-CA), next to Active Certificate Analysis (D3-ACA), which instead opens a connection and inspects what the server returns. This card covers the two passive sources D3FEND describes, Certificate Transparency logs and certificates seen on the wire, the ATT&CK techniques D3FEND relates to the technique, how to deploy and verify it, and where it goes blind. It is written for detection engineers, threat intelligence analysts and PKI owners.

Key takeaways

Two sources, two jobs. Certificate Transparency (CT) logs show certificates issued for your names, or names that look like yours, often before a phishing site goes live; certificates observed in network traffic show what your own hosts are actually talking to.
The ATT&CK links are inferred. D3FEND relates D3-PCA to techniques that use a Certificate File, such as Asymmetric Cryptography (T1573.002), Web Protocols (T1071.001) and Steal or Forge Authentication Certificates (T1649), through the shared artefact rather than by a hand mapping.
TLS 1.3 removed most on-the-wire visibility. The server Certificate message is encrypted in TLS 1.3, so a passive sensor without decryption sees the server name and handshake parameters but not the certificate; Encrypted Client Hello removes the name as well.
CT monitoring only covers publicly trusted certificates. Private CA certificates and self-signed certificates used by much malware never appear in public logs.
Verification is a planted test. Issue a test certificate for a monitored name pattern and confirm the alert arrives; replay known traffic through the sensor and confirm certificate fields are logged.

D3-PCA at a glance

Attribute	Value
D3FEND ID	D3-PCA (d3f:PassiveCertificateAnalysis)
Tactic	Detect
Parent technique	Certificate Analysis (D3-CA), itself a child of Network Traffic Analysis
Sibling technique	Active Certificate Analysis (D3-ACA)
Digital artefact	Certificate File (D3FEND relation: analyzes, inherited from parent D3-CA)
Passive sources named by D3FEND	Network traffic; Certificate Transparency logs
Analytics named by D3FEND	CT log monitoring and auditing; phishing domain name scoring with machine learning and edit distance
D3FEND references	Certificate Transparency project; StreamingPhish; NIST SP 1800-16 Vol. D Appendix A (passive inspection)
Main limitation	Blind to private and self-signed certificates in CT, and to certificates inside TLS 1.3 handshakes without decryption

How it works

Source 1: Certificate Transparency logs

D3FEND's knowledge base article centres on CT. A CT log is an append-only Merkle tree of certificates. When a log accepts a certificate it returns a Signed Certificate Timestamp (SCT), a promise to include the certificate within the log's Maximum Merge Delay. RFC 6962 defines three roles: logs, monitors that watch logs for certificates of interest such as those for domains they are responsible for, and auditors that check logs behave consistently. RFC 6962 is Experimental and has been obsoleted by RFC 9162 (Certificate Transparency Version 2.0, also Experimental, December 2021). Check which version a log implements before building a monitor against it.

For a defender, the monitor role is the countermeasure. A monitor fetches each new Signed Tree Head and the entries added since the last poll, then matches subject and Subject Alternative Name values against a watch list. Two kinds of match matter:

Exact names you own: any certificate for your domains issued by a CA you did not authorise, or requested by a team you did not know about. This catches misissuance and shadow services.
Lookalike names: new certificates for names close to your brand. D3FEND describes the StreamingPhish approach: a model trained on known benign and phishing domains scores each new fully qualified domain name from the CT stream, using features such as Levenshtein distance, trusted brand names prepended as subdomains and regular expression matches, with a tunable alert threshold to balance precision and recall.

Operational detail on running a CT watch for your own estate is in the Certificate Transparency Monitoring Guide for Web Teams, and the protocol itself is covered in the Certificate Transparency Guide. This card does not repeat them.

Source 2: certificates in network traffic

A passive sensor on a span port or tap parses TLS handshakes and records the certificate chain. In TLS 1.2 the server certificate travels in clear, so a network security monitor can log subject, issuer, validity and fingerprint for every connection. Zeek, for example, writes certificate file IDs, subject and issuer to ssl.log for TLS 1.2 sessions and details each certificate in x509.log. Analytics then look for:

Self-signed or private CA certificates on outbound connections to the internet, which legitimate web services rarely present.
Very new or very short-lived certificates for rarely seen destinations, and names that do not match the server name the client requested.
Known bad fingerprints from threat intelligence for command and control frameworks.
Unexpected issuers on internal services, which can point to a rogue CA or a forged certificate.

TLS 1.3 changes this. RFC 8446 states that all handshake messages after the ServerHello are encrypted, which includes the Certificate message. Zeek's documentation confirms that under TLS 1.3 ssl.log carries no certificate references, subject or issuer, only the server name, version, cipher, curve and resumption status, and that with ESNI or Encrypted Client Hello the server name disappears too. Passive certificate analysis on the wire therefore needs either decryption or a shift to other signals.

D3FEND cites NIST SP 1800-16 Volume D Appendix A, where the NCCoE lab copied TLS server private keys to an appliance that passively observed mirrored traffic to decrypt it. That approach only works for servers you own, and the NCCoE notes organisations must weigh traffic security against visibility. Key-copy decryption also fails against forward-secret key exchange, the only kind TLS 1.3 offers, so modern estates rely on an inline proxy or endpoint telemetry for certificate visibility instead.

ATT&CK techniques D3FEND relates to D3-PCA

Relationship type: inferred only. D3FEND derives every row below from the shared Certificate File artefact (D3-PCA inherits the analyzes Certificate File relation from its parent D3-CA) and labels these relationships inferred and experimental (D3FEND 1.6.0, checked November 2026). Each ID was checked against ATT&CK v20.

ATT&CK ID	Technique	Tactic	What passive certificate analysis can show
T1573.002	Encrypted Channel: Asymmetric Cryptography	Command and Control	Self-signed or framework-default certificates on beaconing connections, where TLS 1.2 or decryption exposes them
T1071.001	Application Layer Protocol: Web Protocols	Command and Control	HTTPS command and control to freshly issued certificates for rare or lookalike names
T1048.002	Exfiltration Over Asymmetric Encrypted Non-C2 Protocol	Exfiltration	Certificates of unsanctioned destinations receiving large uploads
T1041	Exfiltration Over C2 Channel	Exfiltration	The same certificate indicators as the command and control channel carrying the data
T1649	Steal or Forge Authentication Certificates	Credential Access	CT entries or observed certificates for your names from an issuer you did not authorise

Two related techniques D3FEND does not list but where CT monitoring is the main defender visibility are Acquire Infrastructure: Domains (T1583.001) and Obtain Capabilities: Digital Certificates (T1588.004); this pairing is an NHI Mgmt Group view. Defensive detail for the listed techniques is in the MITRE ATT&CK T1573 Encrypted Channel, MITRE ATT&CK T1071 Application Layer Protocol, T1048 Exfiltration Over Alternative Protocol, MITRE ATT&CK T1041 Exfiltration Over C2 Channel and MITRE ATT&CK T1649 Steal or Forge Authentication Certificates Guide pages.

Where it is implemented

Implementation class	Source	What it gives you	Fits when
CT monitoring service or self-run monitor	Public CT logs	Alerts on new certificates for your names and lookalikes, often before the site is used	Any organisation with a public brand or domains
CT stream with lookalike scoring	Public CT logs via a streaming feed	Phishing domain candidates scored by similarity, as in StreamingPhish (Apache-2.0)	Brand protection and threat intelligence teams with tuning capacity
Network security monitor	Span or tap traffic	Certificate fields per TLS 1.2 session; server names and handshake fingerprints for TLS 1.3	Existing NDR or open source sensors on egress points
Decrypting proxy or TLS inspection	Inline traffic	Full certificate chain for all outbound TLS, including 1.3	Managed egress with legal and privacy approval for inspection
Internal certificate inventory	Scans and CA records	Baseline of legitimate issuers and certificates to compare observations against	Organisations with a certificate lifecycle tool

The baseline matters: an unexpected issuer is only visible if you know the expected ones. The Machine Identity, PKI and Certificate Lifecycle Guide covers inventory. Wider sensor choices are in the NDR Guide.

Where identity fits

Every TLS server certificate is a machine identity. CT monitoring is one of the few ways to discover certificates your teams obtained outside the managed process, a common source of unowned machine identities and surprise expiry outages. Treat an unknown but legitimate certificate as an inventory finding with an owner, not only as a security alert.

Implementation steps

Build the watch list. List registered domains, key subdomains and brand terms. Add the CAs you authorise (and publish them in CAA records) so other issuers stand out.
Start CT monitoring for exact names. Route matches to the PKI owner first, tune out known teams and automation, then send unexplained issuance to the SOC.
Add lookalike scoring. Start with a high threshold, review a sample of matches weekly, and lower the threshold only while analyst load allows. Feed confirmed phishing names into blocking and takedown.
Turn on certificate logging at egress sensors. Confirm which share of outbound TLS is version 1.3, since that sets how much certificate data the sensor will ever see.
Write traffic analytics. Alert on self-signed certificates to external addresses, issuer mismatches for internal names and known bad fingerprints. Pilot in alert-only mode for two to four weeks.
Decide on decryption. Where certificate visibility for TLS 1.3 is required, decide with legal and privacy teams whether an inline inspection point is justified, and for which traffic.
Roll back safely. CT and passive sensing change nothing on the wire, so rollback is disabling the rule or feed; keep the raw logs so a retired rule can be re-run.

How to verify it works

Planted CT test: issue a certificate from a public CA for a test name that matches your watch list and measure time from issuance to alert. CT logs may take up to their Maximum Merge Delay to include an entry, so expect variation.
Lookalike test: score a list of known historical phishing names for your brand and confirm the model flags them at the chosen threshold.
Sensor replay: replay a capture containing a TLS 1.2 session with a self-signed certificate through the sensor in a lab and confirm the certificate is logged and the rule fires.
Coverage check: measure the share of egress TLS sessions with certificate fields present; a sudden drop usually means a sensor fault or a protocol change.

Metric	Example target (NHI Mgmt Group suggestion, not a standard)	Why it matters
Time from public issuance to analyst alert for exact names	Within one working day	Misissued or lookalike certificates are often used within days
Unexplained certificates for owned names closed with an owner	100% each month	Turns CT into an inventory control
Lookalike alerts confirmed malicious or suspicious	Tracked monthly	Shows whether the threshold is useful or noisy
Egress TLS sessions with certificate data visible	Tracked; falls as TLS 1.3 grows	Shows the real reach of on-the-wire analysis

Limits, bypasses and failure patterns

Private and self-signed certificates: attackers who control both ends of a command and control channel do not need a public certificate, so it never appears in CT.
HTTP and non-TLS phishing: D3FEND's own considerations note that phishing sites served over plain HTTP are not discovered by CT analysis.
Wildcard certificates: D3FEND notes that wildcards in the name defeat some subdomain scoring, since the eventual phishing hostname is never logged.
Feed dependency: the technique depends on a reliable feed of new certificates; a stalled stream produces silence that looks like safety.
Encrypted handshakes: TLS 1.3 hides the certificate and ECH hides the name, so sensors that relied on TLS 1.2 fields lose coverage gradually and without error.
Revocation is separate: D3FEND notes revocation stays outside CT. Detection must hand off to a revocation and takedown process, or the alert changes nothing.

Framework mapping

Framework	Reference	Relevance
NIST SP 800-53 Rev 5	SI-4 System Monitoring	Monitoring network traffic and external sources for attack indicators
NIST SP 800-53 Rev 5	SC-17 Public Key Infrastructure Certificates	Managing the certificates whose misissuance CT exposes
NIST CSF 2.0	DE.CM-01, DE.AE-02	Monitoring networks and analysing adverse events
MITRE D3FEND	D3-CA, D3-PCA, D3-ACA	Parent, technique and sibling

Practitioner checklist

Maintain a watch list of owned domains, brand terms and authorised CAs.
Monitor CT for exact names and route unexplained issuance to an owner within a day.
Score lookalike names from the CT stream with a tuned threshold and review samples weekly.
Log certificate fields at egress sensors and know your TLS 1.3 share.
Alert on self-signed certificates to external destinations and on unexpected issuers for internal names.
Run a planted CT test and a sensor replay test each quarter.
Connect alerts to revocation, blocking and takedown processes.

D3-PCA Passive Certificate Analysis: What It Detects, Which ATT&CK Techniques It Counters and How to Verify It