Credenziali nelle Chat: Chat Messages (T1552.008)

In un ingaggio red team autorizzato, la ricerca di credenziali nelle chat parte tipicamente dopo un initial access che fornisce un token o una sessione valida su una piattaforma collaborativa. L'obiettivo è replicare in modo controllato ciò che farebbe un avversario come LAPSUS$: interrogare l'ecosistema di comunicazione per individuare segreti esposti.

Su Slack, con un token OAuth ottenuto da un endpoint compromesso (o rilasciato dal cliente per l'esercizio), si può interrogare l'endpoint di search delle API ufficiali. Il metodo search.messages accetta query testuali: pattern efficaci includono password, api_key, aws_access_key_id, BEGIN RSA PRIVATE KEY, xoxb-, ghp_, eyJ (prefisso comune dei JWT). Uno strumento aperto e mantenuto per questa attività è SlackPirate (open source), che automatizza la ricerca di segreti tramite pattern predefiniti e produce un report consolidato. Alternativa più recente è slack-watchman (open source), che monitora workspace per esposizioni credenziali secondo regex configurabili.

Per Microsoft Teams e l'ecosistema Microsoft 365, il red teamer con token Graph API può interrogare i messaggi via l'endpoint /chats/{id}/messages e /teams/{id}/channels/{id}/messages. ROADtools (open source) e AADInternals (open source) offrono moduli PowerShell per enumerare tenant e recuperare contenuti conversazionali, mentre TeamsPhisher (open source) è utile per la fase di consegna ma non per la raccolta credenziali.

Su Jira e Confluence (Atlassian), l'API REST consente ricerche con JQL: query come text ~ "password" nei commenti degli issue rivelano spesso credenziali temporanee condivise fra team DevOps. Trufflehog (open source) ha moduli per scansionare Confluence e Jira Cloud alla ricerca di segreti ad alta entropia.

Sul lato endpoint, se il tester ha shell interattiva su una workstation, i database locali dei client desktop sono un'altra fonte. Il client Slack Desktop conserva cache in %AppData%\Slack su Windows e ~/Library/Application Support/Slack su macOS; Teams (nuova versione basata su WebView2) memorizza dati in %LocalAppData%\Packages\MSTeams_8wekyb3d8bbwe. Un semplice *findstr /S /I "password" .json o grep -r -i "api_key" ~/Library/Application\ Support/Slack/ può rivelare segreti persistiti.

Regola operativa: ogni query condotta va tracciata nel report finale con timestamp, account utilizzato e pattern cercato, per consentire al cliente di riprodurre la scansione autonomamente in futuro tramite soluzioni DLP.

La detection di T1552.008 richiede visibilità sui log delle piattaforme collaborative, che nella maggior parte delle organizzazioni sono un punto cieco storico. Le due analytics MITRE AN0309 (Office Suite) e AN0310 (SaaS) forniscono il modello di riferimento.

Per l'ecosistema Microsoft 365, la sorgente primaria è m365:unified (Unified Audit Log), abilitabile dal Microsoft Purview Compliance Portal. Gli eventi rilevanti includono MessageSent, MessageUpdated e le operazioni di Search condotte via Graph API. Una regola efficace correla messaggi Teams o email Outlook che contengono pattern regex tipo password\s[:=]\s*\S+, api[_-]?key\s[:=], AKIA[0-9A-Z]{16} (AWS access key), ghp_[A-Za-z0-9]{36} (GitHub PAT), xox[baprs]-[A-Za-z0-9-]+ (Slack token), eyJ[A-Za-z0-9_-]{20,}.eyJ (JWT). La regex va tarata sui formati di segreti effettivamente usati in azienda per limitare falsi positivi.

Per Slack, l'Audit Logs API (disponibile su piano Enterprise Grid) alimenta il source saas:slack e registra file_downloaded, user_channel_join, app_installed. Chiamate massive a search.messages da account non-admin, o installazioni di app con scope search:read e channels:history, sono forti indicatori di raccolta credenziali. Correlare con saas:okta (o altro IdP) permette di associare l'attività a device non gestiti, geolocalizzazioni anomale o sessioni successive a viaggi impossibili.

I falsi positivi sono la sfida principale. Bot legittimi di DLP (Nightfall, GitGuardian, Microsoft Purview DLP) leggono massivamente i canali proprio per cercare segreti: vanno inseriti in allowlist per IntegrationScope. Anche i canali di supporto tecnico contengono spesso password temporanee di test o dummy string: separare i canali di produzione dai canali sandbox riduce il rumore. Query condotte da sviluppatori nel proprio ambito lavorativo (ricerca di documentazione tecnica) vanno filtrate con UserContext, correlando ruolo e team di appartenenza.

Una baseline utile è la frequenza normale di download di file e di ricerche full-text per utente: uno spike di 10x sul valore mediano settimanale merita un alert immediato. Splunk (a pagamento), Microsoft Sentinel (a pagamento) ed Elastic Security (freemium) offrono connettori nativi per M365 e Slack Enterprise. Per organizzazioni prive di piano Enterprise Grid Slack, l'unica opzione è integrare Nightfall (freemium) o GitGuardian SaaS (freemium) che agganciano l'API standard con scope limitati.

Sul fronte preventivo, la mitigazione M1047 (Audit) suggerisce scansioni proattive periodiche dei canali interni con pattern come "password is" e "password=" per rimuovere segreti già esposti prima che vengano scoperti da un attaccante.

L'analisi forense di un incidente che coinvolge T1552.008 ruota attorno a tre superfici: i log lato server delle piattaforme SaaS, i database locali dei client desktop sugli endpoint e i log dell'identity provider che collega tutto.

Per Microsoft Teams su Windows, la nuova versione basata su WebView2 conserva dati in %LocalAppData%\Packages\MSTeams_8wekyb3d8bbwe\LocalCache\Microsoft\MSTeams, mentre la versione classica in %AppData%\Microsoft\Teams. I file di interesse forense includono i database LevelDB in IndexedDB (contenenti cache di messaggi recenti), i log applicativi logs.txt e i file cookies con token di sessione. Su macOS il percorso è ~/Library/Group Containers/UBF8T346G9.com.microsoft.teams.

Per Slack Desktop, la cache risiede in %AppData%\Slack (Windows), ~/Library/Application Support/Slack (macOS) e ~/.config/Slack (Linux). Il file storage/slack-downloads elenca gli allegati scaricati con timestamp; Local Storage/leveldb contiene token workspace; Cache mantiene copia dei messaggi visualizzati recentemente. Chainsaw (open source) e Velociraptor (open source) hanno artifact predefiniti per acquisire questi percorsi in modo forense.

La timeline dell'incidente va costruita correlando: l'orario di prima autenticazione anomala dell'attaccante sull'IdP (log Okta, Azure AD Sign-in logs, Duo), le successive chiamate API alle piattaforme collaborative (Slack Audit Logs, M365 Unified Audit Log tramite Search-UnifiedAuditLog in PowerShell), i pattern di query eseguite (i log Slack Enterprise registrano le stringhe di ricerca), e infine l'uso downstream delle credenziali scoperte — tipicamente accessi a repository GitHub, console cloud AWS/Azure/GCP, o sistemi interni tramite VPN.

Un artefatto chiave lato M365 è il record SearchQueryPerformed nel Unified Audit Log, che memorizza le query eseguite dall'utente sulla propria mailbox e sui contenuti Teams condivisi. Query contenenti termini come credentials, secret, token, ssh, aws eseguite da account compromessi sono un forte indicatore di intento malevolo. La retention di default dell'Unified Audit Log è 90 giorni sui piani E3 e 365 giorni sui piani E5, un fattore cruciale per la ricostruzione tardiva.

Per Jira e Confluence Cloud, gli audit log accessibili via Atlassian Admin registrano issue.viewed e page.viewed con user agent e IP; scaricabili in JSON tramite l'API di audit. Ricerche massive con JQL contenenti keyword sensibili sono anch'esse tracciate.

Infine, sul lato browser dell'endpoint compromesso, l'analisi della cronologia (History SQLite di Chrome, places.sqlite di Firefox) documenta gli accessi alle interfacce web delle piattaforme collaborative e completa la ricostruzione delle azioni condotte manualmente dall'attaccante.

Il caso di riferimento per T1552.008 è LAPSUS$ (G1004), gruppo di estorsione emerso nel panorama cybercriminale con un modus operandi peculiare: giovane, opportunista, mediatico e straordinariamente efficace nel monetizzare tecniche relativamente semplici. La descrizione MITRE è esplicita: LAPSUS$ ha preso di mira Slack, Teams, Jira, Confluence e altri strumenti collaborativi per cacciare credenziali esposte, utilizzandole poi per privilege escalation e lateral movement.

Il valore strategico di questa tecnica per LAPSUS$ risiede nella sua asimmetria: dopo aver ottenuto un initial access spesso banale — SIM swap, social engineering dell'help desk, acquisto di credenziali su marketplace underground, reclutamento di insider tramite Telegram — il gruppo trasforma rapidamente un singolo account compromesso in un accesso profondo all'infrastruttura. Le piattaforme collaborative fungono da moltiplicatore, perché contengono credenziali di sistemi ben più critici dell'account originario. Un'analista di help desk con accesso a Slack può inavvertitamente esporre chiavi di produzione condivise da un DevOps engineer settimane prima.

Il pattern operativo osservato include: acquisizione di sessione VPN o SSO, accesso web a Slack/Teams, ricerche full-text con pattern come password, credentials, okta, aws, vpn, esfiltrazione delle credenziali trovate, escalation verso ambienti cloud e repository sorgente, esfiltrazione di codice proprietario, estorsione pubblica via Telegram. Le vittime documentate includono organizzazioni tech di primo livello, colpite non attraverso zero-day sofisticati ma sfruttando esattamente questa igiene carente delle comunicazioni interne.

Dal punto di vista geografico, gli arresti condotti dalle forze dell'ordine britanniche hanno individuato membri chiave nel Regno Unito e in Brasile, con un profilo demografico giovane (adolescenti e giovani adulti) atipico rispetto ai gruppi APT tradizionali. Questa composizione ha influenzato il TTP: assenza di malware custom, uso predominante di tool legittimi (browser, client ufficiali delle piattaforme, API), difficoltà di detection basata su IOC statici.

Il trend più ampio è la crescente attenzione da parte di gruppi ransomware e initial access broker verso le piattaforme SaaS collaborative come fonte credenziali. La superficie di attacco si espande con l'adozione di integrazioni, bot e workflow che accedono automaticamente ai contenuti: un singolo bot compromesso con scope channels:history può esporre anni di conversazioni. La mitigazione M1017 (User Training) rimane il controllo più efficace nel medio termine, poiché il problema è comportamentale prima che tecnico. Programmi ricorrenti di awareness per sviluppatori e amministratori, combinati con soluzioni DLP native (Nightfall, GitGuardian, Microsoft Purview DLP), riducono progressivamente la superficie esposta.

MITRE ATT&CK T1552.008 (Chat Messages), tattica TA0006. Gruppo G1004 (LAPSUS$). Mitigazioni M1017 (User Training) e M1047 (Audit). Detection DET0111 con analytics AN0309 (Office Suite, log m365:unified) e AN0310 (SaaS, log saas:slack, saas:okta). Consultato MITRE D3FEND per artefatti e tecniche difensive correlate. Parti operative su tool (SlackPirate, slack-watchman, ROADtools, AADInternals, Trufflehog, Chainsaw, Velociraptor, Nightfall, GitGuardian) e comandi basate su conoscenza professionale di cybersecurity verificabile tramite repository ufficiali.