2026-10-06 · RESEARCH · Il team di Offensive Technology

Come i log di Certificate Transparency espongono i sottodomini interni

Certificate Transparency espone gli hostname interni? Sì, regolarmente. Abbiamo analizzato i log pubblici di CT per 702 domini principali tramite crt.sh, la stessa ricerca gratuita accessibile a chiunque, e abbiamo scoperto che il 65.5% ha registrato almeno un hostname dall'aspetto interno: a dev., staging., vpn., admin., jira., o vault.-style, quasi certamente destinato al personale e non a internet pubblico. Nessun host è stato scansionato, risolto o contattato per ottenere questo dato. CT è un log pubblico append-only di ogni certificato mai emesso da una CA pubblica, e a un nome basta ricevere un solo certificato pubblicamente attendibile per diventare un record permanente e ricercabile. Questa è la prima mossa di un attaccante prima di avviare qualsiasi scansione, e la maggior parte delle organizzazioni sta regalando la propria convenzione di denominazione interna a costo zero.

Perché un log pubblico espone nomi dall'aspetto privato

Certificate Transparency esiste per un ottimo motivo: impedisce a una CA di emettere silenziosamente un certificato non autorizzato per un dominio, poiché ogni certificato emesso diventa visibile al proprietario del dominio e al pubblico. Chrome e altri browser richiedono la registrazione in CT alle CA pubblicamente attendibili dal 2018 in base all'RFC 6962. Questo è un autentico traguardo di sicurezza per l'ecosistema. L'effetto collaterale è che CT registra anche l'hostname stesso, e l'hostname è spesso la parte più rivelatrice del record.

I sistemi interni ottengono certificati pubblici per un motivo ordinario e banale: nessuno vuole visualizzare un avviso del browser quando i dipendenti aprono il portale VPN o l'istanza interna di Jira, anche se il DNS per quel nome viene risolto solo sulla rete aziendale o tramite un tunnel VPN. Di conseguenza, il nome ottiene un vero certificato da Let's Encrypt, DigiCert o un'altra CA pubblica, esattamente come farebbe un sito pubblico. Il certificato svolge il proprio compito senza dare nell'occhio. L'effetto collaterale è che vpn.example.com o staging-admin.example.com è ora permanentemente consultabile da chiunque interroghi CT per example.com, tramite uno strumento gratuito come crt.sh, con zero interazioni con l'infrastruttura di example.com.

I dati: cosa registrano 702 domini principali

Abbiamo interrogato crt.sh per un campione della classifica dei siti principali di Tranco (lista 94Y82), un dominio alla volta con caching e backoff per non sovraccaricare il servizio, e abbiamo classificato la prima label DNS di ogni nome registrato in nove categorie convenzionali di denominazione interna: remote access, auth/identity, non-production, devops/CI, internal collaboration, observability, admin/management, secrets/infrastructure e nomi esplicitamente interni. 702 dei 1.000 domini richiesti sono stati completati; 660 presentavano una cronologia in CT. I risultati per singolo dominio sono stati mantenuti solo in memoria durante l'esecuzione e non sono mai stati salvati su disco, quindi nulla in questa sede cita organizzazioni specifiche. Si tratta di percentuali sull'intero campione, non di un elenco.

I nomi di non produzione dominano: il 58.8% dei domini ha registrato un nome del tipo dev., staging., test. o simile. Questo è il risultato meno sorprendente e di per sé il meno pericoloso: la denominazione di un ambiente di staging non costituisce una vulnerabilità. Ciò che è più interessante è quanto a fondo nella lista si spingano le categorie pericolose. Il 20.4% ha registrato un nome legato a segreti o infrastruttura come vault., consul. o k8s., e il 21.8% ha registrato un nome per l'accesso remoto come vpn. o citrix. Queste sono le categorie in cui il nome stesso rivela all'attaccante esattamente per quale prodotto cercare una CVE nota.

I singoli prefissi raccontano la stessa storia a un livello di dettaglio maggiore. Ecco le dodici label più comuni individuate, per quota rispetto al campione di 702 domini:

Il prefisso vpn. da solo si attesta al 12.8% dell'intero campione, il che significa che circa un dominio su otto tra i più trafficati di internet ha comunicato al mondo, tramite un log pubblico che non ha mai dovuto toccare, di utilizzare uno specifico prodotto di accesso remoto a un determinato nome. Aggiungendo a questo il fingerprinting della versione possibile una volta risolto l'hostname, un attaccante è passato da zero informazioni a un elenco di target prioritari senza inviare un singolo pacchetto al bersaglio.

Raramente ci si ferma a un solo nome

La dispersione di informazioni non è distribuita uniformemente con un solo nome per dominio. Dei 460 domini che hanno esposto dati, 113 hanno esposto un nome da una sola categoria, ma i restanti hanno mostrato esposizioni su più categorie contemporaneamente: 65 domini hanno toccato tre categorie, 42 sei categorie e 22 domini hanno registrato un nome in tutte e nove le categorie monitorate. Quando un'organizzazione prende l'abitudine di assegnare certificati pubblici reali ai tool interni, l'abitudine tende a essere sistematica per ogni strumento interno utilizzato, non per uno solo. Per un attaccante, un dominio che espone ampiamente è più prezioso di uno che espone un singolo nome, perché mappa l'infrastruttura di dev, quella di auth e quella di admin con una sola query.

Come verificare il proprio dominio

Questa verifica richiede meno di un minuto e non necessita di strumenti oltre a un browser o a curl, perché si consulta lo stesso registro pubblico che abbiamo esaminato noi.

• Interroga direttamente crt.sh. Apri https://crt.sh/?q=%25.yourdomain.com&output=json e analizza ogni hostname restituito. Questo rappresenta tutto ciò che CT ha mai registrato per il tuo dominio, inclusi nomi emessi anni fa per server che potrebbero essere stati dismessi da tempo.
• Fai grep dell'output per individuare label dall'aspetto interno. Cerca in particolare i prefissi nella tabella sopra: dev, test, staging, admin, auth, vpn, internal, vault, jenkins, gitlab, grafana e le loro varianti vicine. Tutto ciò che corrisponde è permanentemente pubblico, a prescindere dal fatto che attualmente si risolva o meno.
• Considera ogni corrispondenza come già nota a un attaccante. Non è possibile rimuovere retroattivamente un certificato dal log. L'unica contromisura è dare per scontato che il nome sia pubblico, assicurarsi che il servizio sottostante non si basi sull'oscurità e mantenerlo aggiornato e protetto da controlli di accesso come un asset esposto su internet, perché per un attaccante che consulta CT, lo è già a tutti gli effetti.

Cosa questo non dimostra

Limiti oggettivi, perché un dato senza i suoi caveat è solo marketing.

• Un nome registrato non è la prova di un servizio attivo, raggiungibile o vulnerabile. Abbiamo semplicemente confrontato stringhe di hostname in CT, nient'altro. Non abbiamo risolto alcun nome, non ci siamo connessi ad alcun host né abbiamo verificato se il servizio sottostante esista ancora. Alcuni di questi nomi puntano a infrastrutture dismesse; altri non puntano a nulla.
• È un campione di 702 domini, non l'intera rete internet. I siti principali di Tranco sbilanciano il campione verso organizzazioni grandi e strutturate con un'infrastruttura sufficiente per avere, innanzitutto, ambienti di dev e staging. Una diversa metodologia di ranking o un campione più ampio modificherebbero le percentuali esatte.
• È un'istantanea. Questi dati descrivono lo stato di CT al momento della nostra analisi del 24 luglio 2026. Le organizzazioni aggiungono e dismettono continuamente hostname interni, quindi le cifre esatte variano nel tempo, anche se il comportamento di fondo rimane lo stesso.
• Il matching dei prefissi è euristico, non assoluto. Una label come admin è solitamente un pannello di amministrazione interno, ma occasionalmente può essere il nome legittimo di un prodotto esposto al pubblico. Abbiamo ottimizzato l'elenco delle categorie per la convenzione di denominazione comune, non per una precisione assoluta, quindi considera queste percentuali come un segnale indicativo, non come un inventario esatto.
• Questo misura l'esposizione di un nome, non la sua sfruttabilità. Sapere che vpn.example.com esiste è attività di reconnaissance, non compromissione. Ciò che offre a un attaccante è una lista con priorità e a basso sforzo su cosa andare a verificare successivamente.

Domande frequenti

Gli attaccanti possono usare i log di Certificate Transparency per trovare sottodomini?

Sì. Ogni certificato emesso da una CA pubblica viene registrato in base a RFC 6962, e chiunque può interrogare liberamente questi log tramite crt.sh. Nel nostro campione di 702 domini, il 65.5% delle organizzazioni aveva registrato in questo modo almeno un hostname dall'aspetto interno, con zero interazioni con la propria infrastruttura.

I log di CT possono rivelare hostname interni che non avrebbero mai dovuto essere pubblici?

Sì. A un nome serve un solo certificato pubblicamente attendibile, spesso emesso per evitare che il personale visualizzi avvisi del browser, per diventare un record pubblico permanente. Il server sottostante non deve necessariamente essere raggiungibile da internet affinché il nome venga esposto.

Quali informazioni vengono esposte nel campo Subject Alternative Name di un certificato?

Il campo SAN elenca ogni hostname coperto da un certificato. Un singolo certificato multidominio può esporre decine di nomi contemporaneamente, tutti ricercabili in CT nel momento stesso in cui il certificato viene emesso.

Come si individuano i sottodomini usando crt.sh?

Interroga https://crt.sh/?q=%25.yourdomain.com&output=json. Restituisce ogni certificato registrato per il tuo dominio e i suoi sottodomini, inclusi quelli emessi per server che potrebbero non esistere più. Si tratta di una consultazione passiva e in sola lettura di un log pubblico, lo stesso metodo impiegato in questa ricerca.

Un certificato wildcard impedisce ai sottodomini di apparire nei log di CT?

Un certificato wildcard per *.example.com registra solo la stringa wildcard, nascondendo la label specifica del sottodominio. Ma nel momento in cui un servizio riceve un certificato con nome dedicato, quel nome viene registrato anche se tutto il resto si trova dietro una wildcard.

Come posso evitare che gli hostname interni trapelino in Certificate Transparency?

Utilizza una CA interna e privata per i nomi che non dovrebbero mai essere pubblici, poiché solo le CA pubbliche devono registrare in CT. Preferisci certificati wildcard rispetto a certificati foglia nominati singolarmente dove l'architettura lo consente, e considera tutto ciò che è già presente in CT come permanentemente noto.

Le autorità di certificazione private o interne sono esenti dalla registrazione in Certificate Transparency?

Sì. La registrazione in CT è richiesta per le CA pubblicamente attendibili, non per i certificati in generale. Un certificato emesso dalla propria CA interna, considerata attendibile solo dai dispositivi gestiti aziendali, non deve mai confluire in un log pubblico di CT.

Letture correlate

• Cosa possono effettivamente vedere gli attaccanti sulla tua azienda? La domanda più ampia sulla superficie di attacco di cui questo post analizza un frammento.
• Quanto tempo impiega un certificato a comparire in CT? Sempre nell'ambito di crt.sh, il tema delle tempistiche anziché della denominazione.
• Certificate Transparency è già post-quantum? Un livello diverso dello stesso ecosistema di log pubblici: il livello di firma dei checkpoint anziché il contenuto dei certificati.