T1596.003, Search Open Technical Databases

Digital Certificates

Adversaries search certificate transparency logs to discover subdomains, organizational structure, and infrastructure details encrypted in publicly accessible SSL/TLS certificate records...

🔎 CT LOG QUERY ACTIVE

🏆

              SSL/TLS Certificate, Acme Corp
            

              Issued by DigiCert SHA2 Extended Validation Server CA
            

Common Name *.acmecorp.com

Organization Acme Corporation Holdings, Inc.

Issuer CA DigiCert Inc, Extended Validation

Serial Number 0A:B2:C4:D6:E8:F0:12:34:56:78:9A:BC:DE:F0

Signature Alg SHA256withRSA, 2048 bit

Key Usage Digital Signature, Key Encipherment, Server Auth

⚠ Subject Alternative Names (SANs), 8 entries discovered

acmecorp.com www.acmecorp.com staging-internal.acmecorp.comNEW api-v2.acmecorp.comNEW mail.acmecorp.com dev-db.acmecorp.comNEW jenkins-ci.acmecorp.comNEW admin-panel.acmecorp.comNEW

CERTIFICATE VALIDITY PERIOD

2024-01-15, Issued 2025-01-15, Midpoint 2025-01-15, Expires

🔒 Root CA DigiCert Global Root G2

🔐 Intermediate DigiCert SHA2 EV Server CA

🏆 End Entity *.acmecorp.com

✓ Certificate Chain, VALID

✓ Signature Verification, PASSED

⚠ Wildcard Detected, *.acmecorp.com

⚠ Internal SANs Exposed, 5 FOUND

🔍 crt.sh Search Results, acmecorp.com (847 certificates found)

#01 *.acmecorp.com DigiCert Active

#02 staging-internal.acmecorp.com Let's Encrypt Internal

#03 jenkins-ci.acmecorp.com Let's Encrypt Internal

#04 api-v2.acmecorp.com DigiCert Internal

#05 mail.acmecorp.com Sectigo Active

#06 dev-db.acmecorp.com Let's Encrypt Expired

          🕵 Attacker extracting intelligence from certificate data...
        

staging-internal jenkins-ci admin-panel dev-db api-v2

Certificates indexed in public CT logs (estimated)

4.8 Billion+

Every certificate issued since 2018 is publicly logged and searchable

CT Log Query

SANs Extraction

Subdomain Mapping

Chain Validation

Understanding the Risk

Why Digital Certificate Reconnaissance Matters

78%

Of organizations have at least one subdomain discovered through certificate transparency logs that was not intended to be public

4.8B+

Certificates publicly logged in CT logs worldwide, searchable by anyone including threat actors

91%

Of Fortune 500 companies have internal-only subdomains exposed in certificate transparency logs

62%

Of advanced persistent threat (APT) groups use certificate searches as an early-stage reconnaissance technique

The Double-Edged Sword of Transparency

Certificate Transparency (CT) was introduced by Google in 2013 as an open framework for monitoring and auditing SSL/TLS certificates. The system requires that every certificate issued by a publicly-trusted Certificate Authority be logged in a publicly accessible, append-only database. While CT is essential for detecting mis-issued or fraudulent certificates, it simultaneously creates an exhaustive map of every domain and subdomain an organization has ever protected with a certificate. For security teams, this means internal staging environments, development databases, CI/CD servers, and administrative panels can all be discovered by a simple query to crt.sh or Censys.

According to CISA's supply chain guidance, adversaries routinely mine CT logs to build comprehensive target profiles before launching attacks. The NIST Cybersecurity Framework recommends that organizations proactively audit their own certificate exposure as part of Identify (ID) and Protect (PR) functions. CSO Online reports that certificate-based reconnaissance is one of the fastest-growing attack surface discovery methods, with CT log searches now being integrated into automated reconnaissance frameworks used by both red teams and APT groups.

MITRE ATT&CK T1596.003 CISA Supply Chain Guidance NIST Cybersecurity Framework CSO Online, CT Logs crt.sh, Certificate Search Censys Certificate Search

Core Knowledge

Key Terms & Concepts

What are Digital Certificates?

Digital certificates (also called SSL/TLS certificates or X.509 certificates) are electronic documents that use cryptography to bind a public key with an identity, such as a website domain, organization name, or individual. They are issued by trusted entities called Certificate Authorities (CAs) like DigiCert, Let's Encrypt, Sectigo, and GlobalSign. When you see the padlock icon in your browser, it means the website presented a valid certificate that has been verified against a chain of trust.

Everyday Analogy

Digital certificates are like a restaurant's health inspection certificate posted on the wall. Anyone walking by can check it, you can see the restaurant's name, the inspector who signed it, and when it expires. Certificate transparency takes this further: it's as if every health inspection certificate ever issued is photocopied and placed in a public filing cabinet at city hall. An attacker can simply browse the cabinet to find restaurants (domains) that have back kitchens (internal subdomains) not listed on the main menu.

Essential Terminology

Term	Definition	Analogy
Certificate Authority (CA)	A trusted organization that issues digital certificates, verifying the identity of the certificate requestor before signing.	The government office that issues official ID cards or passports
Certificate Transparency (CT) Log	A publicly accessible, append-only database that records all SSL/TLS certificates issued by publicly-trusted CAs.	A public ledger at city hall recording every business license ever issued
Subject Alternative Names (SANs)	An X.509 extension that allows a single certificate to cover multiple domain names (including subdomains and wildcard entries).	An all-access pass that lists every room in a building you're authorized to enter
Wildcard Certificate	A certificate that covers all subdomains at a single level (e.g., *.acmecorp.com covers any subdomain).	A master key card that opens every door on one floor of a building
Certificate Chain	The hierarchical path of trust from the end-entity certificate through intermediate CAs up to a trusted Root CA.	A chain of custody: store manager → regional director → corporate CEO
crt.sh	A free, web-based search engine that queries certificate transparency logs maintained by the CAcert project.	Google for restaurant inspection certificates, search any name, see every license
Extended Validation (EV)	The highest level of certificate validation, requiring rigorous verification of the organization's legal identity and physical existence.	A background-checked VIP badge, more trustworthy but reveals more about you
Certificate Fingerprint	A unique hash (SHA-1 or SHA-256) that identifies a specific certificate, used for pinning and verification.	A fingerprint, unique to one person, used for positive identification

Case Study

Real-World Scenario: The Exposed Staging Server

Natalie Park is a senior security engineer at Meridian Financial Services, a mid-size fintech company managing retirement accounts for over 200,000 clients. On a routine Tuesday morning, she receives an alert from the company's external attack surface management (EASM) tool: 23 previously unknown subdomains have been discovered through public certificate transparency logs. What follows is a story of how a seemingly harmless certificate request exposed the company's entire internal infrastructure to potential attackers.

🔴 The Discovery, A Dev's Shortcut Becomes an Attacker's Goldmine

Three months earlier, a developer on Meridian's platform team needed to test a new payment processing feature. To speed up testing, they requested a free Let's Encrypt certificate for staging-payments.meridianfs.com. Because Let's Encrypt automatically logs every issued certificate to CT logs, this single certificate, intended only for internal use, now permanently existed in public databases. The developer had also included several related subdomains in the SANs field: api-staging.meridianfs.com, db-test.meridianfs.com, and jenkins-build.meridianfs.com. Each of these pointed to infrastructure that was never meant to be accessible from the public internet.

🔴 The Reconnaissance, Attacker Builds a Complete Infrastructure Map

An APT group tracked as "Crimson Sands" was conducting reconnaissance against financial services firms. Using open technical database searches (T1596), an operator queried crt.sh for %.meridianfs.com. The results returned 847 certificates spanning 14 years. By analyzing the SANs fields across all certificates, they identified 63 unique subdomains, including 23 that were not referenced anywhere on Meridian's public website, DNS records, or marketing materials. Cross-referencing with domain property data (T1590.001), they determined which subdomains resolved to public IP addresses and which CAs had issued the certificates. The Let's Encrypt certificates for staging environments were particularly valuable because they indicated recently deployed, potentially less-secured infrastructure.

🔴 The Exploitation, From Certificate to Breach

The attacker group focused on staging-payments.meridianfs.com, which resolved to an AWS Elastic Load Balancer. The staging server was running an outdated version of Apache Struts with a known remote code execution vulnerability. Because the server was believed to be "internal-only," it had not been included in Meridian's regular vulnerability scanning cycle (see T1595.002). Crimson Sands exploited the Struts vulnerability, gained initial access, and spent 47 days moving laterally through the network before Meridian's security team detected anomalous traffic patterns. By the time the breach was contained, the attackers had exfiltrated personal information of approximately 12,000 clients.

🟢 The Response, Natalie's Recovery Plan

Upon receiving the EASM alert, Natalie immediately launched a comprehensive certificate audit. She worked with the DevOps team to implement a policy requiring all certificate requests to go through a centralized certificate management team with security review. She set up automated monitoring that alerts whenever a new certificate containing a Meridian domain appears in any CT log. She also worked with the infrastructure team to ensure that internal staging environments were only accessible through the corporate VPN, not through public DNS resolution. Most importantly, she deployed a passive DNS monitoring (T1596.001) system to detect unauthorized DNS records pointing to Meridian's infrastructure. Six months later, Meridian had reduced its CT log-exposed attack surface by 78%, and the new certificate governance process prevented all future accidental exposures of internal subdomains.

Key Takeaway

Every certificate your organization requests, whether for production, staging, development, or testing, creates a permanent public record that adversaries can discover and exploit. Natalie's story illustrates that the problem isn't certificate transparency itself (which is essential for web security), but rather the lack of governance over what domains are included in certificate requests and how internal infrastructure is exposed through software and service configuration (T1592.002).

Defense Playbook

Step-by-Step Protection Guide

Audit Your Current Certificate Exposure DETECT

Before you can protect your certificate attack surface, you need to understand what's already exposed. Query public CT logs for every domain and subdomain your organization controls.

Visit crt.sh and search for %.yourdomain.com, the percent sign acts as a wildcard to find all subdomains
Use Censys certificate search for advanced filtering by organization name, CA, and date range
Run openssl s_client -connect target:443 2>/dev/null | openssl x509 -noout -text to inspect live certificates for SAN entries
Document every unique subdomain found in the SANs field across all certificates
Cross-reference discovered subdomains with your internal inventory of production and staging systems

Classify Subdomains by Risk Level DETECT

Not all exposed subdomains represent the same level of risk. Categorize each discovered subdomain based on its purpose and the sensitivity of the data it handles.

Low Risk: Public-facing marketing sites, documentation portals, and public APIs, already intended to be accessible
Medium Risk: Staging environments, test servers, and pre-production systems, not meant for public access but may have basic protections
High Risk: Administrative panels, CI/CD pipelines, database servers, and internal tools, critical infrastructure that should never be publicly resolvable
Pay special attention to subdomains using Let's Encrypt or other free CAs, which often indicate developer-deployed, less-managed infrastructure

Implement Certificate Governance Policy PREVENT

Create and enforce policies that control who can request certificates and what domains can be included in certificate requests.

Designate a centralized certificate management team responsible for all certificate requests and renewals
Create an approval workflow requiring security team review for any certificate that includes non-production domains in the SANs field
Maintain a whitelist of approved domains that can be included in certificate requests
Implement technical controls using ACME client restrictions or private CA infrastructure for internal certificates
Train development teams on the security implications of requesting public certificates for internal infrastructure

Use a Private CA for Internal Infrastructure PREVENT

The most effective way to prevent internal subdomain exposure through CT logs is to avoid using publicly-trusted CAs for internal infrastructure entirely.

Deploy an internal Certificate Authority using solutions like HashiCorp Vault, Microsoft Active Directory Certificate Services, or cfssl
Issue all certificates for staging, development, and internal-only systems from the private CA, these will never appear in public CT logs
Distribute the private CA's root certificate to all corporate-managed devices and browsers
Reserve publicly-trusted certificates exclusively for production systems that legitimately need to be verified by external clients
Review related network trust dependencies (T1590.003) to ensure private CA trust is properly scoped

Deploy Continuous CT Log Monitoring DETECT

Set up automated monitoring that alerts you whenever a new certificate containing your organization's domains appears in any public CT log.

Use tools like certspotter, ct-monitor, or commercial EASM platforms for real-time CT log monitoring
Configure alerts for new certificates, certificate renewals, new CA relationships, and unexpected SAN entries
Monitor for certificates issued by CAs your organization doesn't normally use, this could indicate a malicious certificate request
Track certificate expiration dates to prevent outages and detect potential certificate hijacking attempts
Integrate CT log alerts into your SIEM for correlation with other open source intelligence data

Network Segmentation and Access Controls PREVENT

Even if a subdomain is discovered through CT logs, network segmentation ensures that attackers cannot reach the underlying infrastructure.

Ensure all staging, development, and internal systems are only accessible through the corporate VPN or zero-trust network access (ZTNA)
Implement DNS split-horizon configuration so that internal subdomains only resolve to internal IP addresses from within the corporate network
Apply the principle of least privilege to all services exposed on any publicly-resolvable subdomain
Regularly review DNS records (T1590.002) and remove any public DNS entries for internal-only infrastructure

Conduct Regular Certificate Audits and Red Team Exercises RESPOND

Maintain an ongoing program of certificate auditing and adversarial testing to identify new exposure before attackers do.

Schedule quarterly certificate exposure audits using the same tools attackers use: crt.sh, Censys, Google CT search
Include certificate transparency reconnaissance in your red team exercises and purple team assessments
Track the growth rate of discovered subdomains over time, rapid growth often indicates uncontrolled certificate sprawl
Create an incident response plan specifically for unauthorized certificate discovery and potential infrastructure exposure
Document lessons learned from each audit cycle and update governance policies accordingly

Lessons Learned

Common Mistakes & Best Practices

❌ Common Mistakes

Using public CAs for internal infrastructure, Requesting Let's Encrypt or other free certificates for staging, development, and testing environments creates permanent public records of subdomains that should remain private.
Including too many SANs in a single certificate, Bundling 20+ subdomains into one certificate for convenience means a single CT log entry exposes your entire infrastructure map to attackers.
Never auditing your own CT log exposure, Many organizations have never searched crt.sh for their own domains and are unaware of the attack surface that certificate transparency reveals.
Allowing developers to self-service certificate requests without governance, When any developer can request a publicly-trusted certificate for any subdomain, certificate sprawl is inevitable and uncontrolled.
Ignoring certificates from defunct projects and decommissioned infrastructure, Old certificates for abandoned projects remain in CT logs indefinitely, revealing historical infrastructure details that may still be partially active.

✔ Best Practices

Deploy a private CA for all internal infrastructure, Use HashiCorp Vault, AWS Private CA, or Microsoft AD CS to issue certificates for staging, development, and internal systems, these never appear in public CT logs.
Implement centralized certificate lifecycle management, Use platforms like Venafi, Keyfactor, or HashiCorp Vault to manage all certificate requests, renewals, and revocations through a governed workflow.
Monitor CT logs continuously with automated alerts, Deploy tools that watch for new certificates containing your domains and alert on unexpected CAs, new SANs, or certificate anomalies in real time.
Maintain a domain inventory and cross-reference with certificate data, Keep an authoritative inventory of every domain and subdomain your organization controls, and regularly reconcile it against CT log data.
Use DNS split-horizon and network segmentation, Ensure that even if a subdomain is discovered through CT logs, the underlying infrastructure is only reachable through authenticated network access paths.

Tactical Perspectives

Red Team vs Blue Team

☠ ATTACKER

Red Team: How Adversaries Exploit Digital Certificates

For red teams and real-world adversaries, certificate transparency logs represent one of the highest-value, lowest-cost reconnaissance sources available. A single crt.sh query can reveal more about an organization's infrastructure than weeks of port scanning.

Discovery Phase:

▶ Query crt.sh/?q=%.target.com to enumerate all subdomains ever protected by public certificates
▶ Use Censys to filter results by certificate type, CA, organization name, and geographic location of issuing authority
▶ Cross-reference CT data with passive DNS records to determine which discovered subdomains have active DNS resolution
▶ Analyze certificate issuance patterns over time, sudden spikes in Let's Encrypt certificates may indicate new development projects

Target Selection:

▶ Prioritize subdomains with free CA certificates (Let's Encrypt), these often belong to developer-managed, less-secured infrastructure
▶ Focus on subdomains with names like "staging," "dev," "test," "jenkins," "admin," "internal," "db," or "api"
▶ Identify wildcard certificates (*.domain.com) that may cover infrastructure the organization is unaware of
▶ Map certificate trust chains to identify the CA ecosystem the organization uses, this informs phishing and impersonation campaigns

Exploitation:

▶ Target exposed staging and CI/CD servers for initial access, then pivot to production systems
▶ Use discovered organizational names and CA details to craft convincing phishing emails and fake login portals
▶ Monitor CT logs for newly issued certificates to detect when the target deploys new infrastructure before it's fully hardened

🛡 DEFENDER

Blue Team: How Defenders Protect Against Certificate Reconnaissance

Blue teams must shift from treating certificate transparency as a compliance requirement to recognizing it as a critical attack surface that requires active management and monitoring.

Detection:

▶ Deploy CT log monitoring tools (certspotter, ct-monitor, or commercial EASM) to detect new certificates for your domains in real time
▶ Set up SIEM alerts for certificates issued by unauthorized CAs or containing unexpected SAN entries
▶ Regularly run your own CT log searches to simulate what attackers can discover, mirror the open technical database search methodology
▶ Monitor for unauthorized certificate issuance requests to your organization's validated domains (CAA record enforcement)

Prevention:

▶ Publish CAA (Certification Authority Authorization) DNS records to restrict which CAs can issue certificates for your domains
▶ Deploy a private CA for all internal infrastructure, this is the single most effective control against CT log exposure
▶ Implement certificate pinning for critical applications to reduce the impact of fraudulent certificate issuance
▶ Enforce network segmentation so that even discovered subdomains cannot be reached without authentication

Response:

▶ Create a rapid response process for unauthorized certificate discovery, including certificate revocation and infrastructure hardening
▶ Maintain relationships with CAs to quickly revoke fraudulently issued certificates
▶ Conduct purple team exercises that specifically test certificate reconnaissance detection and response capabilities

Deep Dive

Threat Hunter's Eye: How Attackers Abuse Certificate Weaknesses

👁 Attack Patterns in Certificate-Based Reconnaissance

Threat hunters and SOC analysts should understand the specific patterns that indicate an adversary is using certificate transparency logs as part of their reconnaissance operations. The following attack patterns represent the most common and dangerous ways this technique is abused in the wild.

🔴 Pattern 1: Subdomain Sprawl Mining

Attackers systematically query CT logs for every subdomain ever associated with a target organization. They focus on identifying subdomain sprawl, the gradual accumulation of certificates for staging, testing, and abandoned infrastructure that the organization has lost track of. This pattern is particularly effective against large enterprises that have undergone mergers, acquisitions, or major technology migrations.

Hunting Query: Monitor for high-frequency CT log queries from single IP ranges targeting your domain space

🔴 Pattern 2: CA Ecosystem Profiling

By analyzing which CAs have issued certificates for a target, attackers build a "certificate ecosystem profile" that reveals the organization's security maturity. Heavy use of free CAs like Let's Encrypt for internal infrastructure suggests developer-driven, ungoverned certificate management. Exclusive use of premium CAs like DigiCert with EV validation suggests a more mature security posture but also reveals organizational structure through EV certificate details.

Hunting Query: Track certificate issuance patterns by CA to identify shifts in security practices or new infrastructure deployment

🔴 Pattern 3: Infrastructure Lifecycle Tracking

Certificate issuance dates reveal when specific infrastructure was deployed. By tracking certificate lifecycle events, issuance, renewal, expiration, and re-issuance, attackers can infer the target's technology refresh cycles, identify recently deployed systems that may not yet be fully hardened, and detect when infrastructure is being decommissioned (expired certificates for subdomains that still resolve in DNS).

Hunting Query: Cross-reference expired certificates with active DNS records to find "zombie" infrastructure

🔴 Pattern 4: Organizational Intelligence Extraction

Extended Validation (EV) certificates and organization-validated certificates contain verified business details: legal company name, address, jurisdiction, and business registration number. Attackers mine these details to build dossiers for social engineering campaigns, business email compromise (BEC), and spear-phishing attacks. The organizational details in certificates are often more accurate and up-to-date than public business registries.

Hunting Query: Audit EV certificate organizational fields for sensitivity and compare against public business filings

🔴 Pattern 5: Wildcard Certificate Exploitation

Organizations that use wildcard certificates (*.domain.com) create a particularly rich reconnaissance target. While the wildcard itself appears in CT logs, the actual subdomains it covers are often revealed through related certificates, DNS records, and web content. Attackers who discover a wildcard certificate know that any subdomain they find through other means will be covered by the same trust relationship, which helps them prioritize which subdomains to target.

Hunting Query: Monitor for wildcard certificate renewal patterns and cross-reference with domain property changes

🔴 Pattern 6: Certificate Change Detection for Active Monitoring

Sophisticated threat actors set up automated systems that continuously monitor CT logs for changes in a target's certificate landscape. A new certificate for a previously unseen subdomain immediately flags new infrastructure deployment. A certificate issued by an unusual CA may indicate a compromised system or a third-party integration that hasn't been security-reviewed. This passive, persistent monitoring provides attackers with near-real-time intelligence about the target's infrastructure evolution.

Hunting Query: Deploy your own CT log change detection to match adversary monitoring speed, detect what they detect, when they detect it

Hunting Toolkit for Certificate Intelligence

Defenders should use the same tools as attackers to understand their own exposure. Key resources include:

crt.sh Censys Google CT Search OpenSSL certspotter ct-monitor subfinder amass Certificate Transparency Logs

Join the Conversation

Have you audited your organization's certificate transparency exposure? What subdomains did you discover that shouldn't have been public? Share your experience, ask questions, or discuss certificate reconnaissance strategies with the community.

Discussion Prompts: What's the most surprising subdomain you've found in your own CT log audit? Has your organization implemented a private CA? How do you balance developer agility with certificate governance?

This page is part of the MITRE ATT&CK T1596, Search Open Technical Databases series. Explore related techniques:

T1596 Overview T1596.001 DNS T1596.002 WHOIS T1596.004 Code Repos T1596.005 Scan DBs

T1590.001 Domains T1596.001 DNS T1592.002 Software