TeamPCP: quando il silenzio operativo significa monetizzazione

48 ore. Zero nuove compromissioni.

Se stai monitorando la campagna TeamPCP, quella pausa non è una buona notizia. È il segnale che il gruppo ha smesso di espandersi perché ha iniziato a raccogliere.

Questo è il terzo aggiornamento sulla campagna TeamPCP, una delle operazioni supply chain più sofisticate documentate nel primo trimestre 2026. Il report originale — When the Security Scanner Became the Weapon (SANS ISC, marzo 2026) — ha tracciato l'evoluzione di un attore che ha trasformato uno strumento di analisi di sicurezza in vettore di compromissione silenziosa. L'Update 003 registra uno shift operativo significativo: il ritmo degli attacchi si è abbassato, ma non perché la campagna sia terminata.

Per il contesto generale sugli attacchi che usano l'email come vettore secondario in scenari di questo tipo, puoi consultare gli approfondimenti nel blog.

THREAT BRIEF

Attore: TeamPCP (cluster non attribuito con precisione; TTPs compatibili con gruppi a motivazione economica)

Campagna: Supply chain via security scanner trojanizzato

Periodo: documentato da Q4 2025, aggiornamento al 28 marzo 2026

Fase attuale: monetizzazione post-compromissione

TeamPCP ha condotto un'operazione di compromissione della supply chain sfruttando uno strumento di sicurezza — un security scanner — come vettore iniziale. Il software, usato da team IT e MSSP per scansioni di rete e audit di configurazione, è stato alterato per includere un loader che installa backdoor silenziose sui sistemi target.

Nelle ultime 48 ore precedenti all'Update 003, non sono stati rilevati nuovi host compromessi. L'interpretazione più probabile: il gruppo ha completato la fase di raccolta degli accessi e ha iniziato le operazioni di estrazione del valore. I vettori di monetizzazione attesi includono ransomware, vendita degli accessi su mercati underground e credential harvesting mirato su target ad alto valore.

La priorità di risposta rimane ALTA per le organizzazioni che hanno utilizzato il software coinvolto nelle ultime settimane.

Analisi della Minaccia

Il vettore: lo strumento di sicurezza come arma

L'aspetto più rilevante della campagna TeamPCP è il target del vettore iniziale: non un'applicazione utente generica, ma uno strumento usato specificamente da professionisti della sicurezza e team IT.

Compromettere un software di sicurezza significa compromettere chi si occupa di sicurezza — spesso persone con privilegi elevati, accesso a sistemi sensibili e visibilità sull'intera rete aziendale. È come rubare le chiavi del guardiano invece di scavalcare il muro.

Il loader installato dal security scanner trojanizzato opera in modo silenzioso: non genera alert evidenti, sfrutta chiamate di sistema legittime e si mimetizza nel normale traffico operativo dello strumento. Una tecnica di living-off-the-land evoluta, difficile da rilevare con le soluzioni di detection tradizionali basate su firma.

TTPs e mapping MITRE ATT&CK

Il meccanismo di C2 documentato utilizza canali HTTPS verso domini registrati recentemente con naming pattern che simulano CDN e servizi cloud legittimi. Questa tecnica rende difficile la detection tramite blocklist — il traffico appare indistinguibile dal normale utilizzo di servizi cloud aziendali.

La fase di monetizzazione: cosa sta succedendo ora

Nelle operazioni APT a motivazione economica, la monetizzazione segue uno schema temporale abbastanza prevedibile:

1. Raccolta accessi (settimane): inventario degli host compromessi, prioritizzazione per valore
2. Riconoscimento silenzioso (giorni): mappatura delle risorse di maggior valore — directory AD, backup, dati finanziari
3. Staged exfiltration (ore/giorni): estrazione dei dati prima del payload finale
4. Monetizzazione (trigger): ransomware, vendita accessi, o entrambi in sequenza

Il silenzio di 48 ore di TeamPCP è coerente con la transizione tra fase 2 e fase 3. I sistemi già compromessi sono operativi per il gruppo; espandere ulteriormente il footprint non è più necessario né desiderabile — ridurrebbe solo lo stealth.

Per i team di risposta agli incidenti, questo cambia le priorità in modo netto: non si tratta più di contenere la diffusione, ma di identificare e isolare i sistemi già compromessi prima che il payload finale venga attivato.

Impatto e Portata

Chi è realmente a rischio

Il target primario della campagna TeamPCP non sono le aziende end-user, ma i provider di servizi IT, i team di sicurezza interni e gli MSSP che usano strumenti di scanning nella loro operatività quotidiana.

Questo determina un effetto a cascata difficile da quantificare: se un MSSP è compromesso, potenzialmente lo sono anche tutti i suoi clienti — anche quelli che non hanno mai sentito parlare di TeamPCP.

Settori più esposti

Le campagne supply chain che colpiscono strumenti IT tendono a concentrarsi su settori con alta densità di MSP: manifatturiero, healthcare, servizi professionali (studi legali, commercialisti), logistica.

In Italia, il rischio è amplificato dalla struttura del mercato IT: molte PMI delegano completamente la gestione dei sistemi a provider esterni. Una singola compromissione di un MSP medio può impattare decine di aziende clienti contemporaneamente, ognuna ignara dell'esposizione.

Perché il silenzio è il segnale più allarmante

Un dato importante per chi fa threat monitoring professionale: la caduta del ritmo operativo non equivale a fine della campagna.

Nelle campagne ransomware documentate negli ultimi anni, il gap medio tra l'ultimo accesso malevolo non rilevato e il deploy del payload finale è stato di diversi giorni. Spesso una settimana. A volte di più. Il silenzio di 48 ore di TeamPCP potrebbe essere solo il preludio.

Analisi Comparativa

TeamPCP nel contesto delle supply chain attack più rilevanti

Le differenze che contano

Rispetto a SolarWinds, TeamPCP ha una scala più contenuta ma un targeting più chirurgico. Non punta alla massa — punta a chi ha le chiavi di casa.

Rispetto a Kaseya, il vettore è strutturalmente diverso: Kaseya sfruttò una vulnerabilità zero-day nella piattaforma di gestione remota; TeamPCP ha trojanizzato il software a monte, prima della distribuzione. Non c'era nessuna patch da applicare — il binario era già compromesso al momento del download.

La tecnica più simile rimane 3CX: software legittimo alterato, distribuzione tramite canali ufficiali, download volontario da parte delle vittime. La differenza è il target: mentre 3CX colpiva chiunque usasse quel prodotto VoIP, TeamPCP si è concentrato su uno strumento usato da chi dovrebbe rilevare le minacce.

Questo è il nodo strategico della campagna. Compromettere un team di sicurezza significa:

• Accesso a dati di audit e log (spesso contenenti credenziali e configurazioni sensibili)
• Visibilità completa sull'architettura di rete del cliente
• Possibilità di disabilitare o manipolare i controlli di sicurezza esistenti
• Minore probabilità di rilevamento (chi fa sicurezza tende a fidarsi degli strumenti che usa quotidianamente)

Evoluzione della tecnica: un trend strutturale

L'uso di software di sicurezza come vettore di attacco è un trend documentato da ENISA e dal MITRE ATT&CK knowledge base negli ultimi anni. I motivi sono strutturali: questi tool ricevono spesso eccezioni nelle policy di endpoint detection, si aggiornano frequentemente — ampliando la superficie di attacco — e operano con privilegi elevati per design.

TeamPCP non ha inventato questa tecnica. L'ha perfezionata, scegliendo un target con accesso privilegiato e una fiducia implicita negli strumenti che usa.

Raccomandazioni

Azioni ordinate per orizzonte temporale e priorità. Se il tuo provider IT o il tuo team usa security scanner, inizia dalla colonna "Immediata" — adesso.

Azioni immediate (entro 24-48 ore)

Inventory degli strumenti di scanning Identifica tutti i security scanner attivi nella rete, inclusi quelli usati da provider IT esterni. Per ognuno: versione installata, hash SHA-256 del file eseguibile, data di download o aggiornamento.

Verifica degli hash Confronta l'hash di ogni binario con il valore ufficiale pubblicato dal vendor. Se non riesci a ottenere hash ufficiali, questo è già un problema da escalare — un vendor che non pubblica hash non offre garanzie di integrità.

Analisi dei processi attivi Con EDR o Sysmon, cerca processi anomali lanciati dai binary degli scanner: child process inattesi, chiamate di rete verso domini esterni non documentati, accessi a credential store (LSASS, SAM, Credential Manager).

Monitoraggio del traffico di rete Pattern specifici da cercare: connessioni HTTPS verso domini registrati negli ultimi 60-90 giorni, traffico verso CDN insoliti, beacon regolari a intervalli fissi (tipico del C2 automatizzato), richieste DNS verso sottodomini con pattern algoritmico.

Breve termine (1-2 settimane)

Revisione dei privilegi degli account di servizio Gli scanner spesso operano con account ad alto privilegio. Applica il principio del least privilege: l'account del scanner deve accedere solo a ciò strettamente necessario per la sua funzione dichiarata.

Segmentazione degli strumenti di sicurezza Se possibile, isola i tool di scanning in VLAN dedicate con visibilità limitata sulle risorse production. Gli strumenti di sicurezza non devono avere accesso illimitato a tutto.

Verifica della protezione email Le campagne in fase di monetizzazione usano spesso l'email come secondo vettore — spear phishing costruito sui dati raccolti durante la compromissione, con pretesti altamente credibili. Assicurati che il filtro email includa URL analysis in real-time e sandboxing degli allegati. Strumenti come MailSniper integrano queste funzionalità e possono bloccare i payload secondari anche quando il contesto dell'email appare del tutto legittimo.

Revisione dei log degli ultimi 30-90 giorni Cerca retroattivamente le anomalie descritte nel Threat Brief. Un'intrusione silenziosa lascia tracce — a volte bastano ore per trovarle se sai cosa cercare e dove guardare.

Medio termine (1-3 mesi)

Software supply chain governance Implementa una policy formale per l'approvazione dei tool di sicurezza: nessun software installato senza verifica preventiva dell'hash, nessun aggiornamento automatico per tool con privilegi elevati. Il NIST SP 800-161 offre un framework operativo specifico per la gestione del rischio supply chain.

Incident Response Plan per scenari supply chain Se non hai un piano specifico per la compromissione via terze parti, è il momento di costruirlo. Le linee guida ENISA sulla supply chain security sono un punto di partenza operativo, non solo teorico.

Revisione contrattuale con provider IT I tuoi MSP e provider IT hanno clausole di notifica obbligatoria in caso di compromissione? Verifica i contratti. Se non ci sono SLA di sicurezza espliciti, è il momento di negoziarli.

Indicatori di compromissione da monitorare

• Processi scanner con parent-child relationship anomala (es. scanner che lancia PowerShell codificato)
• Scheduled task creati recentemente con nomi simili a processi di sistema legittimi
• Connessioni verso TLD insoliti (.cc, .pw, .xyz, .top) da host con security tool installati
• Accessi a LSASS o SAM da processi non standard
• Traffico DNS verso sottodomini con pattern generati algoritmicamente (DGA)
• Exfiltration via canali cloud legittimi (OneDrive, Dropbox, GitHub) con volumi anomali

Condividi gli IOC con il tuo ISAC di riferimento e con i canali CERT-AgID per contribuire al tracking collettivo della campagna.

Outlook

La pausa operativa di TeamPCP è probabilmente temporanea. Le campagne supply chain a motivazione economica raramente si interrompono prima del payload finale — più spesso, il silenzio precede l'escalation.

Nei prossimi 3-6 mesi, lo scenario più probabile prevede il deploy del payload ransomware sui sistemi già compromessi, oppure la vendita degli accessi su forum underground — o entrambe le cose in sequenza. Seguirà quasi certamente una fase di spear phishing mirato: email costruite sui dati raccolti durante la compromissione, credibili perché personalizzate. In questo scenario, il monitoraggio delle comunicazioni email diventa prioritario. Un filtro con analisi semantica come quello integrato in MailSniper può rilevare anomalie nei pattern di comunicazione anche quando il testo dell'email appare del tutto legittimo.

Sul medio termine, la tecnica di trojanizzare strumenti di sicurezza verrà replicata. La rarità dell'incidente oggi non equivale a sicurezza domani.

La lesson learned più importante da TeamPCP non è tecnica: è organizzativa. La fiducia implicita nei tool di sicurezza è un vettore di attacco. Ogni software, incluso quello che usi per proteggere la rete, merita lo stesso rigore che applicheresti a qualsiasi altro componente del sistema.