Come scoprire quali dati un programma invia su Internet: guida pratica per Windows 11

Un programma può comunicare con server remoti anche quando non stiamo utilizzando attivamente le sue funzionalità. Può controllare la disponibilità di aggiornamenti, sincronizzare informazioni, trasmettere statistiche di utilizzo, inviare dati diagnostici o qualunque altro genere di informazione. Ma come possiamo verificare quali informazioni lascia effettivamente uscire dal nostro computer?

Windows 11 permette di individuare le applicazioni che utilizzano la rete, ma conoscere l’indirizzo IP di destinazione non significa sapere quali dati raggiungano il server. Per scoprirlo dobbiamo combinare strumenti differenti e separare ciò che possiamo osservare direttamente da ciò che rimane protetto dalla crittografia.

Vediamo come procedere attraverso un laboratorio pratico, riproducibile sul proprio PC, senza ricorrere a costosi software commerciali. L’obiettivo non è soltanto scoprire quali programmi “chiamano casa“, ma ricostruire il contenuto delle richieste e capire quando una trasmissione potrebbe comportare rischi per la privacy.

Primo passo: individuare il programma che comunica su Internet

Premiamo Windows+R, digitiamo resmon e selezioniamo la scheda Rete dalla finestra Monitoraggio risorse.

Nel riquadro Processi con attività rete troviamo i programmi che stanno scambiando dati. Le colonne Invio, Ricezione e Totale mostrano il traffico in byte al secondo, mentre selezionando un processo possiamo filtrare le attività associate.

Il riquadro Attività rete permette di osservare gli indirizzi contattati. Quello denominato Connessioni TCP aggiunge le porte locali e remote e lo stato delle connessioni.

È un buon punto di partenza, ma con limiti precisi: Monitoraggio risorse non mostra il contenuto delle richieste HTTP, né permette di ricostruire messaggi trasmessi attraverso connessioni crittografate. Avevamo già illustrato queste funzionalità nella guida dedicata a come individuare i programmi che generano più traffico di rete in Windows.

TCPView: associare ogni connessione al processo responsabile

Per ottenere una rappresentazione più dettagliata possiamo avvalerci di uno strumento come TCPView di Microsoft Sysinternals.

L’applicazione mostra il nome di ciascun processo, il suo identificativo PID (Process ID), gli indirizzi locali e remoti, le porte utilizzate. Aggiorna inoltre l’elenco delle connessioni, evidenziando quelle appena create e quelle terminate. Un particolare importante: il PID identifica un’istanza del processo, non l’applicazione in modo permanente. Dopo un riavvio il numero può cambiare.

Avviamo TCPView, individuiamo l’eseguibile da controllare e osserviamo cosa succede quando apriamo il programma, utilizziamo una funzione oppure lo lasciamo inattivo.

Disattivando temporaneamente la risoluzione dei nomi (Options, Resolve Addresses) possiamo vedere gli indirizzi IP originali, evitando di prendere in esame un nome ottenuto mediante risoluzione inversa con il dominio effettivamente richiesto dall’applicazione.

TCPView consente quindi di rispondere alla domanda “chi comunica con chi?”, ma non rivela da solo se un’applicazione trasmetta identificativi, documenti, token di autenticazione o altri dati personali.

Wireshark: osservare i pacchetti e capire cosa nasconde HTTPS

Scarichiamo Wireshark dal sito ufficiale, installando anche Npcap quando richiesto.

Come spiegato nella guida all’uso di Wireshark, selezioniamo l’interfaccia Ethernet o WiFi utilizzata per la connessione e iniziamo la cattura. Nella barra dei filtri possiamo inserire dns per attivare il filtro mostra le interrogazioni DNS tradizionali visibili nella cattura. È utile per identificare i nomi richiesti, ma non intercetta le risoluzioni effettuate mediante DNS over HTTPS (DoH) o altri meccanismi cifrati.

Per osservare le comunicazioni TLS possiamo utilizzare il filtro seguente:

tls

Per concentrarci su una destinazione individuata con TCPView:

ip.addr == 203.0.113.10

L’indirizzo nell’esempio è puramente dimostrativo: dobbiamo sostituirlo con quello rilevato durante l’analisi. Selezionando Statistiche, Conversazioni possiamo inoltre confrontare la quantità di dati scambiati tra coppie di indirizzi.

Non dimentichiamo che Wireshark di norma non associa i pacchetti al processo Windows che li ha generati: dobbiamo correlare indirizzi, porte e tempi con quanto osservato in TCPView.

Soprattutto, se il programma utilizza il protocollo HTTPS, il contenuto applicativo resta cifrato: possiamo osservare metadati e caratteristiche del traffico, talvolta anche il nome del server indicato mediante SNI, ma non leggere automaticamente URL completi, intestazioni HTTP (o header) e corpi delle richieste. SNI (Server Name Indication) è un’informazione della connessione TLS che indica il nome del dominio a cui il programma vuole collegarsi, spesso visibile anche quando il contenuto HTTPS è cifrato.

TLS 1.3, QUIC, DNS cifrato ed ECH possono ridurre ulteriormente le informazioni visibili. Per approfondire il funzionamento del programma rimandiamo anche alla documentazione ufficiale.

Come leggere davvero i dati trasmessi: il ruolo di mitmproxy

Per passare dall’osservazione delle connessioni all’ispezione dei contenuti possiamo utilizzare mitmproxy, disponibile anche su Windows.

Il software opera come intermediario tra applicazione e server: quando il client lo utilizza come proxy e riconosce l’autorità di certificazione locale, mitmproxy può decifrare la comunicazione HTTPS e mostrarne richieste e risposte. In questo modo diventano esaminabili i metodi HTTP (GET, POST), gli URL, gli header e i dati contenuti nel corpo delle richieste.

L’intercettazione è possibile soltanto se il traffico dell’applicazione passa attraverso il proxy oppure è acquisito attraverso una modalità di cattura compatibile. Anche in questi casi, la lettura dei dati HTTPS non è sempre garantita: alcuni programmi utilizzano il certificate pinning, un meccanismo che accetta soltanto specifici certificati digitali, impedendo a mitmproxy di inserirsi nella comunicazione. Altri gestiscono autonomamente i certificati attendibili oppure utilizzano protocolli che lo strumento non riesce a interpretare.

Non bisogna modificare indiscriminatamente i meccanismi di sicurezza delle applicazioni per forzare l’intercettazione: il principio è simile a quello già descritto nella nostra guida su come intercettare il traffico delle app installate su smartphone con Burp Suite, ma qui lavoriamo direttamente sui processi Windows.

Laboratorio: intercettare una richiesta HTTPS e leggerne il contenuto

Costruiamo un esperimento controllato usando il software curl, già incluso nelle installazioni aggiornate di Windows 11, e il servizio pubblico HTTPBin. Utilizzeremo esclusivamente dati inventati, evitando di trasmettere informazioni personali durante il test.

Installiamo mitmproxy seguendo le istruzioni ufficiali per Windows; apriamo poi una finestra del terminale e avviamo il programma con il comando mitmweb. Il software avvia un proxy HTTP locale sulla porta 8080 e un’interfaccia Web di analisi. Prima di proseguire, assicuriamoci che l’interfaccia mostri il servizio attivo.

Al primo avvio mitmproxy genera anche una propria autorità di certificazione, salvandola nella directory .mitmproxy del profilo utente. Apriamo quindi un secondo terminale ed eseguiamo quanto segue (tutto su un’unica riga):

curl -x http://127.0.0.1:8080 --cacert "%USERPROFILE%\.mitmproxy\mitmproxy-ca-cert.pem" -H "Content-Type: application/json" -d "{\"test\":\"dato-fittizio\",\"origine\":\"windows11\"}" https://httpbin.org/post

Il comando chiede a curl di inoltrare attraverso il proxy locale una richiesta HTTPS contenente un piccolo documento JSON. L’opzione --cacert indica il certificato dell’autorità locale che deve essere considerata attendibile per la verifica TLS. Evitiamo così di disabilitare la verifica dei certificati mediante -k o di installare una nuova autorità attendibile per tutto il sistema.

Se curl segnalasse errori relativi al certificato o al proxy, verifichiamo il percorso del file, l’avvio di mitmproxy e il supporto TLS della versione di curl utilizzata.

Cosa possiamo vedere nella richiesta intercettata

Nell’interfaccia di mitmweb individuiamo la richiesta verso httpbin.org, quindi apriamone i dettagli.

Possiamo esaminare il metodo POST, il percorso /post, le intestazioni HTTP e il corpo JSON:

{
  "test": "dato-fittizio",
  "origine": "windows11"
}

Ecco la differenza fondamentale rispetto a TCPView e alla normale cattura Wireshark: ora possiamo verificare i valori trasmessi a livello applicativo, anziché limitarci agli indirizzi dei server e ai volumi di traffico.

Come applicare il metodo a un programma reale

Una volta acquisita familiarità con la procedura, possiamo passare all’applicazione che desideriamo controllare: è preferibile effettuare queste prove in un ambiente dedicato, possibilmente una macchina virtuale, senza account reali e senza documenti riservati.

mitmproxy supporta anche la modalità di cattura locale (Local Capture), capace di intercettare il traffico di processi selezionati senza configurarli manualmente per utilizzare un proxy. Su Windows possiamo avviare, ad esempio:

mitmweb --mode local:NomeProgramma.exe

Sostituiamo NomeProgramma.exe con l’eseguibile individuato in TCPView. La modalità dipende dalla versione installata, dai privilegi disponibili e dalla compatibilità del programma analizzato.

Per un’applicazione che non riconosce la CA di mitmproxy, la cattura potrebbe registrare tentativi di connessione ma non mostrare contenuti decifrati.

Un’alternativa alla decifratura tramite proxy: SSLKEYLOGFILE

Esiste un secondo metodo, utilizzabile con alcuni browser e programmi che supportano l’esportazione dei segreti delle sessioni TLS.

La variabile d’ambiente SSLKEYLOGFILE indica dove salvare le chiavi necessarie alla decifratura delle comunicazioni: Wireshark può utilizzare il file per ricostruire i dati applicativi contenuti nei pacchetti catturati.

Per esempio, da Prompt dei comandi di Windows 11 possiamo avviare Firefox in un ambiente controllato (assicurarsi di aver chiuso Firefox, compresi eventuali processi in background):

set SSLKEYLOGFILE=%TEMP%\tls-keys.log
start "" firefox.exe

In Wireshark apriamo Modifica, Preferenze, Protocolli, TLS e indichiamo il percorso del file nel campo (Pre)-Master-Secret log filename: se il browser produce correttamente il file delle chiavi, Wireshark può interpretare anche le comunicazioni cifrate della sessione catturata.

Non tutti i programmi supportano questa possibilità. Inoltre, il file contiene materiale crittografico “delicato”: dobbiamo proteggerlo ed eliminarlo al termine dell’esperimento.

La procedura è documentata nella Wireshark Wiki dedicata a TLS. Su IlSoftware.it avevamo già affrontato il tema nell’articolo sulle comunicazioni HTTPS e sulla variabile SSLKEYLOGFILE.

Come riconoscere telemetria e dati personali nelle richieste HTTP

Una volta ottenuto il contenuto delle comunicazioni, la parte più importante dell’indagine consiste nell’interpretare correttamente tutto questo materiale.

Una richiesta verso un dominio denominato telemetry o analytics non dimostra automaticamente la trasmissione di informazioni personali. Analogamente, un dominio apparentemente innocuo può ricevere dati personali o riservati.

Dobbiamo invece cercare elementi concreti: identificativi persistenti dell’installazione, indirizzi email, nomi utente, informazioni sul dispositivo, percorsi locali, identificativi di sessione, URL contenenti parametri e contenuti inseriti dall’utente. Prestiamo particolare attenzione agli header HTTP: campi come Authorization, Cookie e User-Agent, oltre agli header personalizzati, possono contenere informazioni rilevanti.

Per distinguere una trasmissione occasionale da un comportamento ripetuto, si possono e si devono effettuare più test: avviare il software, lasciarlo inattivo, accedere a una funzione specifica e confrontare le richieste osservate.

Nel caso degli assistenti AI, è utile verificare se il programma trasmetta soltanto il prompt richiesto oppure aggiunga metadati, identificativi o informazioni recuperate automaticamente da altri componenti.

Cosa possiamo concludere dopo l’analisi

Quando un’applicazione stabilisce una connessione con un server remoto, non significa che stia per forza raccogliendo informazioni personali o trasmettendo dati senza autorizzazione. Allo stesso tempo, il fatto che un programma funzioni correttamente e provenga da uno sviluppatore affidabile non garantisce che ogni comunicazione sia trasparente.

Gli strumenti che abbiamo utilizzato permettono di superare le supposizioni e osservare il comportamento reale del software. Monitoraggio risorse e TCPView aiutano a individuare le connessioni, Wireshark permette di analizzare il traffico di rete e mitmproxy, quando le condizioni tecniche lo consentono, arriva a mostrare il contenuto delle richieste HTTP.

D’altra parte, rilevare da un lato una connessione verso un servizio di telemetria e dall’altro verificare che al suo interno viaggiano identificativi persistenti, dettagli sul dispositivo o dati inseriti dall’utente è un altro paio di maniche.

Il nostro obiettivo era fornire metodologie e strumenti direttamente accessibili a costo zero per capire cosa succede “dietro le quinte”, senza bisogno di affidarsi esclusivamente alle dichiarazioni degli sviluppatori o alle informative privacy.