Credenziali nei Messaggi di Chat: Chat Messages (T1552.008)

L'essenza di questa tecnica è semplice: cercare stringhe sensibili nei messaggi. In un engagement red team, la simulazione parte dall'accesso a un token utente o a credenziali di servizio per la piattaforma target, e si sviluppa con query mirate.

Slack come superficie d'attacco. Una volta in possesso di un token Slack con scope search:read, l'API nativa diventa lo strumento più potente. La chiamata search.messages accetta query testuali esattamente come la barra di ricerca del client. Un operatore red team può lanciare ricerche per pattern comuni:

curl -s -H "Authorization: Bearer xoxp-TOKEN" "https://slack.com/api/search.messages?query=password%3D&count=100" | jq '.messages.matches[].text'

Varianti utili della query includono stringhe come API_KEY=, bearer, token:, ssh-rsa, BEGIN RSA PRIVATE KEY. Ogni risultato restituito include il testo del messaggio, il canale, l'autore e il timestamp — tutto materiale per il report.

Microsoft Teams e Graph API. Se il perimetro include Microsoft 365, l'approccio equivalente sfrutta la Graph API. Con un token delegato che abbia i permessi ChannelMessage.Read.All o Chat.Read, è possibile enumerare i messaggi dei canali Teams. Il tool TokenTacticsV2 (open source) facilita l'acquisizione di token OAuth in scenari di device code phishing, mentre ROADtools (open source) permette di esplorare il tenant Azure AD e identificare i permessi disponibili.

TruffleHog per l'analisi offline. Se durante l'engagement si ottiene un export di canali (Slack permette l'export JSON ai workspace admin), TruffleHog (open source) è ideale per lo scanning massivo. Supporta nativamente oltre 800 detector di segreti e può processare archivi JSON:

trufflehog filesystem --directory ./slack-export/ --json > secrets_found.json

Ricerca manuale su Jira e Confluence. Questi strumenti Atlassian offrono potenti funzioni di ricerca interna. Query JQL come text ~ "password" OR text ~ "API_KEY" su Jira, o la ricerca CQL equivalente su Confluence, restituiscono ticket e pagine wiki dove sviluppatori hanno incollato credenziali durante il troubleshooting.

Per la fase di reporting, è fondamentale documentare non solo le credenziali trovate, ma anche da quanto tempo erano esposte e quanti utenti avevano accesso al canale. Questo dato trasforma un finding tecnico in un argomento di rischio comprensibile dal management.

La detection di questa tecnica ruota attorno a due assi: individuare credenziali condivise nei messaggi prima che un avversario le trovi, e rilevare pattern di ricerca anomali sulle piattaforme di collaborazione.

Log source primari. L'analytic AN0309 si basa su log m365:unified, il flusso di audit unificato di Microsoft 365 che cattura eventi di Exchange Online, Teams e SharePoint. L'analytic AN0310 estende la copertura a piattaforme SaaS come Slack e Okta, monitorando chiamate API e accessi ai messaggi. Entrambi gli analytics ruotano attorno a regex pattern per identificare stringhe che assomigliano a credenziali.

Le regex da implementare nel SIEM dovrebbero coprire almeno queste categorie:

• Pattern password=, passwd:, pwd= seguiti da stringhe alfanumeriche
• Token JWT (tre segmenti base64 separati da punti)
• Chiavi API con prefissi noti (AKIA per AWS, sk- per OpenAI, ghp_ per GitHub)
• Chiavi SSH (BEGIN RSA PRIVATE KEY, BEGIN OPENSSH PRIVATE KEY)
• Token OAuth bearer in header format

Rilevamento dell'estrazione massiva. Oltre ai contenuti, il comportamento è un segnale forte. In Slack, monitora le chiamate API search.messages e conversations.history effettuate da token utente — specialmente se il volume supera le normali interazioni. Negli audit log di Microsoft 365, l'evento SearchQueryPerformed registra le ricerche effettuate dagli utenti in Exchange e Teams: una query per "password" da un account appena compromesso è un indicatore ad alta fedeltà.

Gestione dei falsi positivi. Il tuning è cruciale. I bot DLP aziendali legittimi interrogano le API con scope di lettura messaggi: vanno inseriti in allowlist per identità. Gli ambienti DevOps generano messaggi automatici contenenti token temporanei (ad esempio, pipeline CI/CD che notificano deployment): correlare con il ruolo utente (sviluppatore vs. utente standard) riduce il rumore, come suggerito dal parametro UserContext dell'analytic AN0310. Infine, definire una finestra temporale (TimeWindow) per aggregare eventi di condivisione bulk evita di generare un alert per ogni singolo messaggio.

Un controllo preventivo efficace è l'audit proattivo raccomandato dalla mitigazione M1047: eseguire periodicamente scansioni automatizzate sui canali di comunicazione cercando pattern di credenziali esposte, e revocare o ruotare immediatamente quelle trovate.

Quando un incident coinvolge credenziali esfiltrate da piattaforme di chat, la ricostruzione della timeline richiede di incrociare log cloud con artefatti endpoint per determinare cosa è stato letto, quando e da dove.

Artefatti Microsoft 365. L'Unified Audit Log è il punto di partenza. Gli eventi chiave da estrarre includono MessageRead (lettura di email contenenti credenziali), SearchQueryPerformed (ricerche eseguite nel tenant), e FileAccessed per allegati con configurazioni o file .env. Ogni evento porta un ClientIP e un UserAgent: un accesso da un IP geolocalizzato in modo anomalo, combinato con un user agent insolito (ad esempio uno script Python), è un forte indicatore di compromissione.

Per l'estrazione forense di questi log, il modulo PowerShell Microsoft.Graph (gratuito, incluso nel tenant M365) permette query mirate:

Search-UnifiedAuditLog -StartDate "2025-01-01" -EndDate "2025-01-31" -Operations SearchQueryPerformed -ResultSize 5000 | Export-Csv -Path audit_search.csv

Artefatti Slack. Slack Enterprise Grid offre un'API di audit log che registra eventi come message_search, file_downloaded e member_joined_channel. Il workspace admin può esportare l'intero storico dei messaggi in formato JSON. Incrociando il timestamp di una ricerca sospetta con i messaggi restituiti, l'analista può ricostruire esattamente quali credenziali l'attaccante ha visualizzato.

Artefatti endpoint. Sul dispositivo dell'utente compromesso, i client desktop di Teams e Slack memorizzano dati locali. Il client Teams su Windows salva cache e log nella directory %AppData%\Microsoft\Teams. Il client Slack Electron mantiene un database LevelDB in %AppData%\Slack dove è possibile recuperare frammenti di messaggi visualizzati. L'analisi di questi artefatti con tool come hindsight (open source, pensato per browser Chromium ma applicabile a framework Electron) può rivelare la cronologia delle interazioni.

La timeline dovrebbe collegare: il momento dell'accesso iniziale all'account (login anomalo in Okta o Azure AD), le ricerche effettuate sulla piattaforma di chat, le credenziali trovate nei risultati, e infine l'uso di quelle credenziali per il movimento laterale. Questa catena causale — dall'accesso al messaggio alla compromissione del sistema target — è il cuore della narrative forense.

Il panorama degli attori associati a questa tecnica è dominato da un singolo gruppo, ma il suo profilo operativo offre lezioni significative sull'evoluzione delle tattiche di credential access.

LAPSUS$ (G1004) rappresenta un caso emblematico di gruppo orientato all'estorsione che ha elevato l'abuso delle piattaforme di collaborazione a metodo sistematico. Il gruppo ha preso di mira esplicitamente Slack, Teams, Jira e Confluence per cercare credenziali esposte a supporto di privilege escalation e lateral movement. Il modus operandi di LAPSUS$ è significativo per una ragione precisa: non si basa su malware sofisticato o exploit zero-day, ma sull'abuso di funzionalità native e sulla negligenza degli utenti nella gestione dei segreti.

Il pattern operativo ricorrente segue una catena prevedibile. L'accesso iniziale avviene tipicamente tramite social engineering o acquisto di credenziali da initial access broker. Una volta dentro il perimetro, l'attaccante si muove lateralmente non attraverso exploit di rete, ma semplicemente cercando nelle piattaforme di collaborazione le chiavi per aprire la porta successiva: una password di admin condivisa in un canale IT, una API key di produzione incollata in un ticket Jira, un token di servizio salvato in una pagina Confluence.

Questo approccio rivela un trend più ampio nella threat landscape: la convergenza tra credential access e abuso di servizi SaaS. Le piattaforme di collaborazione sono contemporaneamente il vettore di raccolta e il repository di credenziali, creando un ciclo che si autoalimenta. Un attaccante con accesso a Slack può trovare credenziali che danno accesso a sistemi che a loro volta contengono token per altri servizi.

Per i team di intelligence, il takeaway operativo è chiaro: monitorare i forum underground e i marketplace per la vendita di sessioni valide su piattaforme di collaborazione aziendale è un indicatore anticipatore. L'assenza di software catalogati per questa tecnica non significa assenza di tooling — significa che gli strumenti sono le API native delle piattaforme stesse, rendendo l'attribuzione e la detection significativamente più complesse.

La mitigazione M1017 (User Training) acquista qui un valore strategico: ridurre la quantità di credenziali presenti nei messaggi è l'unico controllo che agisce sulla root cause, non sul sintomo.

Framework MITRE ATT&CK: tecnica T1552.008, gruppo G1004, mitigazioni M1047 e M1017, detection DET0111 (analytics AN0309, AN0310). Integrato con conoscenza professionale per tool e procedure operative.