Installazione Certificati Digitali: Install Digital Certificate (T1608.003)

Trattandosi di una tecnica pre-compromise, l'obiettivo del red team è simulare in laboratorio la predisposizione di infrastruttura fidata, evitando di toccare terze parti reali. Il flusso tipico parte dalla generazione di un certificato e prosegue con la sua installazione sul server C2 o sul finto portale di raccolta credenziali.

Per i certificati validi e gratuiti in un ambiente controllato si usa Certbot (open source) con ACME, che automatizza l'emissione e il rinnovo su domini di test posseduti dal team. In alternativa, per un self-signed rapido in lab, openssl (open source) resta lo standard:

openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 90 -nodes

Per creare una CA interna di laboratorio e firmare più certificati coerenti tra loro, mkcert (open source) genera una root locale attendibile utile a rendere credibili i portali di phishing simulato senza avvisi del browser sulle macchine di test.

Sul fronte C2, framework come Cobalt Strike (a pagamento) e Mythic (open source) permettono di importare un keystore o un certificato PEM nei profili di ascolto HTTPS: il listener viene configurato per presentare il certificato installato, cifrando il traffico con crittografia asimmetrica sui protocolli web. Con Sliver (open source) è possibile abilitare listener mTLS o HTTPS che caricano certificati personalizzati, replicando la scelta avversaria di canali TLS credibili.

Per la componente credential harvesting, l'installazione del certificato sul reverse proxy è il passaggio chiave: strumenti come Evilginx (open source) e GoPhish (open source) accettano certificati emessi via ACME o forniti manualmente, così il sito clone appare protetto da TLS valido. La catena d'attacco simulata diventa quindi: registrazione dominio di test, emissione o import del certificato, installazione su server acquisito in lab, esposizione del servizio e verifica della presentazione TLS.

La validazione lato attaccante consiste nel confermare che il certificato sia servito correttamente:

openssl s_client -connect :443 -servername

Questo comando mostra la catena presentata, il CN/SAN e l'emittente, consentendo di verificare che l'infrastruttura sia pronta prima dell'esecuzione dello scenario. Tutte le attività vanno svolte su domini e host di proprietà del team, mantenendo l'esercizio lab-safe e circoscritto.

La rilevazione di questa tecnica è indiretta: il SOC non osserva l'installazione del certificato sul server avversario, ma le tracce che emergono quando quell'infrastruttura viene contattata. L'attenzione va quindi spostata sui comportamenti correlati, ovvero il traffico HTTPS/TLS verso C2 e le connessioni ai portali di phishing.

Gli artefatti digitali chiave sono il certificato e la sessione TLS. Sui log di rete e sui proxy conviene abilitare l'ispezione dei metadati TLS: Zeek (open source) con il suo ssl.log e x509.log registra emittente, subject, validità, catena e JA3/JA3S, permettendo di individuare certificati self-signed, catene incomplete, validità anomala (durata brevissima tipica di ACME automatizzato) o CN che non corrispondono al dominio richiesto. Suricata (open source) genera eventi TLS analoghi e supporta regole su fingerprint noti.

Sul piano preventivo e di hardening, il controllo determinante è il monitoraggio esterno della superficie. I log rilevanti sono quelli di tipo Internet Scan: piattaforme come Censys (freemium) e Shodan (freemium) consentono di pivotare su elementi noti del certificato — hash, subject, serial, chiave — per scoprire altra infrastruttura avversaria che riusa lo stesso materiale crittografico. Il database Certificate Transparency consultabile via crt.sh (gratuito) aiuta a scoprire certificati emessi per domini lookalike che imitano il brand aziendale, un segnale precoce di preparazione di credential harvesting.

Un flusso di detection efficace incrocia tre fonti: alert TLS da Zeek/Suricata sui JA3/JA3S ricorrenti, monitoraggio CT per emissioni sospette su domini simili ai propri, e threat intelligence su certificati già attribuiti ad avversari, aggregabile in MISP (open source) come indicatori pivotabili.

Sui falsi positivi serve prudenza. I certificati con durata di 90 giorni sono ormai lo standard legittimo di ACME, quindi la sola breve validità non è un indicatore affidabile. Allo stesso modo, i self-signed sono normali in ambienti interni, IoT e apparati di gestione: vanno valutati solo se presentati da host esterni verso cui gli endpoint iniziano comunicazioni cifrate inattese. Anche i fingerprint JA3 sono condivisi da intere librerie client, perciò diventano utili solo se correlati a destinazioni sospette. La priorità va data alla correlazione tra certificato anomalo, dominio di recente registrazione e beaconing periodico, che insieme delineano l'uso operativo dell'infrastruttura predisposta.

Nell'analisi forense di questa tecnica l'evidenza raramente risiede sull'endpoint della vittima, perché l'installazione del certificato avviene su server controllati dall'avversario. Il lavoro dell'analista si concentra quindi su fonti esterne e sugli artefatti che compaiono dopo il contatto con l'infrastruttura malevola.

Le fonti esterne primarie sono il Certificate Transparency log, interrogabile tramite crt.sh (gratuito) o le API di Censys (freemium), che consentono di ricostruire la cronologia di emissione dei certificati associati a un dominio sospetto: data di rilascio, emittente, subject alternative name e serial diventano ancore temporali per la timeline dell'operazione. Il passive DNS, disponibile su piattaforme come VirusTotal (freemium), collega il certificato agli IP e ai domini che lo hanno servito nel tempo, mentre il WHOIS storico aiuta a datare la registrazione dell'infrastruttura e a correlarla con la finestra dell'incidente.

Gli artefatti digitali centrali restano il certificato e le sessioni TLS catturate. Se è disponibile un packet capture dell'evento, tshark (open source) estrae la catena presentata durante l'handshake:

tshark -r capture.pcap -Y "tls.handshake.type==11" -T fields -e x509sat.uTF8String

Dal certificato recuperato si calcolano gli hash e si estraggono i campi identificativi con openssl x509 -in cert.pem -noout -text -fingerprint -sha256, materiale che alimenta il pivoting verso altra infrastruttura riconducibile allo stesso attore.

Sull'endpoint gli artefatti emergono solo come conseguenza del contatto. Su Windows la cronologia di navigazione e i log del browser, insieme al Windows Certificate Store ispezionabile con certutil -store, possono mostrare l'accettazione di certificati anomali; le connessioni verso il C2 lasciano tracce in Sysmon EventCode 3 (Network Connection) e negli eventi TLS del sistema. Su Linux le connessioni si ricostruiscono da netstat/ss, dai log di sistema e da eventuali cattura di rete, mentre i certificati fidati aggiunti in /etc/ssl/certs meritano verifica.

Un caso documentato di questa tecnica riguarda il gruppo Sea Turtle, che sottraeva certificati SSL legittimi dalle organizzazioni vittima per installarli sulla propria infrastruttura e sostenere successive operazioni di intercettazione adversary-in-the-middle. Per l'analista questo scenario implica un'attenzione particolare: un certificato legittimo dell'organizzazione osservato su IP o hosting non riconducibili all'ente è un forte indicatore di furto e reinstallazione, e la correlazione tra CT log, passive DNS e inventario interno dei certificati diventa il fulcro dell'indagine.

Nei dati disponibili questa tecnica è associata a un unico attore, ma particolarmente istruttivo sul piano del profiling. Sea Turtle (G1041) è documentato per aver catturato certificati SSL legittimi dalle organizzazioni vittima e averli installati su infrastruttura sotto il proprio controllo, con l'obiettivo di abilitare operazioni di intercettazione adversary-in-the-middle. Questo dettaglio è significativo perché distingue nettamente due modelli operativi: l'uso di certificati self-signed o acquistati ex novo, e il riuso di certificati autentici sottratti alla vittima. La seconda scelta è più sofisticata e insidiosa, perché il certificato è realmente valido e supera i controlli di catena, spostando la fiducia della vittima verso il server dell'attaccante senza sollevare avvisi nel browser.

Il valore per un Threat Intelligence Officer sta nel pattern sottostante più che nel singolo indicatore. Il riuso di materiale crittografico è una debolezza operativa dell'avversario: un certificato installato su più host lascia un filo conduttore che, tramite pivoting su hash, serial e subject, permette di mappare cluster di infrastruttura. Le operazioni AITM come quelle attribuite a Sea Turtle spesso si combinano con manipolazioni DNS a monte, quindi l'analisi va estesa alla correlazione tra certificati sospetti e anomalie di risoluzione dei domini bersaglio.

Sul piano dei trend, l'installazione di certificati fidati è cresciuta come pratica trasversale perché la diffusione di TLS ovunque ha reso il traffico cifrato la norma: un canale C2 senza certificato oggi risalterebbe, mentre uno con TLS valido si mimetizza nel rumore di fondo. Questo spinge molti attori verso l'automazione dell'emissione tramite ACME e verso il furto di certificati aziendali per campagne mirate, soprattutto quando l'obiettivo è la raccolta credenziali con la massima credibilità visiva.

Dal punto di vista della prioritizzazione difensiva, la mitigazione applicabile è Pre-compromise (M1056), che agisce riducendo la superficie e monitorando la preparazione avversaria: audit dei dati esposti, protezione di dominio e DNS con DNSSEC, sorveglianza dei domini lookalike e integrazione di threat intelligence su piattaforme come MISP. Poiché l'attività avviene fuori dal perimetro, il contributo dell'intelligence è duplice: costruire watchlist di certificati e domini attribuiti ad attori noti e alimentare il monitoraggio dei Certificate Transparency log per anticipare campagne che imitano il proprio brand.

MITRE ATT&CK: T1608.003 (Install Digital Certificate), tattica TA0042. Gruppo G1041 (Sea Turtle). Mitigazione M1056 (Pre-compromise). Detection DET0840, analitica AN1972 (log Internet Scan). Tool di detection e verifica citati: Zeek, Suricata, MISP, Censys, Shodan, VirusTotal, crt.sh (Certificate Transparency), openssl, tshark, Certbot, mkcert, Sliver, Mythic, Evilginx, GoPhish. Contenuti operativi su comandi e artefatti derivano da conoscenza professionale di cybersecurity, nel rispetto delle regole su tool reali e sintassi verificabile.