Raccolta da Chat Aziendali: Messaging Applications (T1213.005)

In un red team engagement autorizzato, l'accesso alle piattaforme di messaging avviene tipicamente dopo la compromissione di un account utente o di un token OAuth. La superficie tecnica dipende dalla piattaforma bersaglio.

Per Microsoft Teams, l'approccio più realistico sfrutta le Microsoft Graph API. Con un token OAuth valido con scope Chat.Read o ChannelMessage.Read.All, un operatore può enumerare chat e canali via endpoint Graph (/me/chats, /teams/{id}/channels/{id}/messages). Il tool TeamsEnum (open source) automatizza l'enumerazione utenti Teams via API, mentre AADInternals (open source) offre moduli PowerShell per interagire con l'ecosistema M365 inclusi Teams e SharePoint. Per la fase di ricognizione post-phishing, GraphRunner (open source) rappresenta un framework maturo che include funzioni dedicate al pillage di Teams (Invoke-SearchTeams, Get-TeamsChat) con ricerca per keyword su chat e canali.

Per Slack, l'accesso passa dai token xoxb-, xoxp- o xoxc-. Il tool SlackPirate (open source) automatizza il dumping di credenziali, private key e link interni dai workspace via API. In alternativa, script custom sulla Slack Web API (endpoint conversations.history, search.messages, files.list) consentono ricerca mirata: query per pattern come password, api_key, BEGIN RSA PRIVATE KEY, aws_access_key rivelano regolarmente materiale sensibile.

La catena d'attacco tipica in laboratorio segue questo flusso: compromissione iniziale via phishing con Evilginx (open source) per catturare token di sessione, refresh del token, enumerazione dei workspace accessibili, dump massivo delle conversazioni recenti e ricerca full-text su termini di interesse. Uno script Python con la libreria slack_sdk può iterare su tutti i canali pubblici e privati accessibili all'utente compromesso ed estrarre il contenuto in JSON per analisi offline.

Un aspetto particolarmente rilevante per il red team è la counter-IR intelligence: monitorare i canali #security, #incident-response o simili durante l'operazione permette di calibrare le mosse successive. Se il team difensivo scrive "stiamo isolando l'host X", l'operatore può migrare il foothold prima del contenimento. Questo pattern, documentato in casi reali attribuiti a Scattered Spider, va simulato in esercitazioni purple team per validare la resilienza dei processi di IR.

Regola operativa: mai lasciare traccia con export massivi tramite eDiscovery, che generano log immediati. Preferire query API mirate su piccoli volumi ripetuti con jitter temporale.

La detection di T1213.005 si concentra su comportamenti anomali di accesso alle piattaforme SaaS di collaborazione, dove il perimetro tradizionale endpoint fornisce visibilità limitata. Le due detection analytic di riferimento — AN1565 per SaaS e AN1566 per Office Suite — poggiano su log source specifici: saas:slack, m365:signinlogs e m365:unified.

L'indicatore primario è l'accesso atipico via API o token di automazione alle conversazioni. Su Slack, gli Audit Logs (disponibili nei piani Enterprise Grid, a pagamento) espongono eventi come file_downloaded, message_searched e user_channel_join: un volume anomalo di search.messages o conversations.history da un singolo token in una finestra ristretta è un segnale forte. Su Microsoft 365, il Unified Audit Log registra operazioni Teams come MessagesListed, MessageRead, ChatRetrieved e attività eDiscovery (SearchCreated, SearchExported): un utente non appartenente a Legal o InfoSec che avvia una content search su Teams merita alert immediato.

La correlazione con m365:signinlogs è cruciale. Un pattern classico: sign-in da geolocalizzazione anomala o da ASP residenziale/VPN commerciale, seguito entro pochi minuti da chiamate massive a Graph API su endpoint Chat. Le query KQL su Microsoft Sentinel o Defender for Cloud Apps (a pagamento) possono correlare AADSignInLogs con OfficeActivity filtrando per Operation in ("MessagesListed", "MessageRead") e volumi sopra baseline.

Parametri di tuning raccomandati dalle analytic MITRE:

• TimeWindow: finestra di osservazione post-login per il pattern di scraping (tipicamente 15-60 minuti)
• MessageExportThreshold: soglia di messaggi o file scaricati (dipende dalla baseline organizzativa)
• UserContext: ruolo dell'utente, appartenenza a team autorizzati all'eDiscovery
• AccessMethod: distinzione tra accesso utente diretto, token OAuth, bot o app di terze parti
• GeoRiskScore: pattern di sign-in da paesi o IP inusuali

I falsi positivi più comuni riguardano attività legittima di InfoSec, Legal e Compliance, integrazioni SIEM che ingeriscono chat via API, bot aziendali di produttività e strumenti di backup Teams/Slack. La whitelist va costruita sulle app OAuth approvate e sui service principal noti.

Sul piano preventivo, allineato alla mitigazione M1047 (Audit), il SOC dovrebbe eseguire content search periodiche su pattern come password, AKIA (AWS access key), BEGIN PRIVATE KEY nei canali per identificare esposizioni prima che lo faccia l'attaccante. Microsoft Purview (a pagamento) e Nightfall DLP (freemium/a pagamento) automatizzano questa ricerca DLP-oriented su Teams e Slack.

L'indagine forense su T1213.005 ruota attorno a fonti prevalentemente cloud, poiché l'artefatto primario risiede nei log della piattaforma SaaS più che sull'endpoint. La timeline di un incidente tipicamente parte dal sign-in compromesso e si sviluppa attraverso le chiamate API di collezione.

Per Microsoft 365, il Unified Audit Log è la fonte cardine. Va acquisito entro la finestra di retention (90 giorni default, estendibile fino a 10 anni con licenze E5 Compliance) via Search-UnifiedAuditLog in PowerShell o via Office 365 Management Activity API. Gli eventi rilevanti includono MessagesListed, MessageRead, ChatRetrieved, MessageSent, oltre agli eventi eDiscovery SearchCreated, SearchStarted, SearchExported. Ogni record espone UserId, ClientIP, UserAgent e AppId dell'applicazione chiamante — quest'ultimo permette di distinguere accesso client Teams legittimo da chiamate Graph API dirette con app OAuth sospette.

Per Slack, gli Audit Logs API (Enterprise Grid) espongono eventi granulari conservati fino a 6 mesi. Le azioni chiave da correlare sono user_login, user_login_failed, file_downloaded, message_searched, app_installed, app_scopes_expanded. Un app_installed seguito da massiccia attività API su conversations.history è pattern classico di token abuse.

Sul fronte endpoint, se l'accesso è avvenuto tramite client desktop Teams o Slack compromesso, alcuni artefatti locali arricchiscono la timeline. Su Windows, la cartella %AppData%\Microsoft\Teams contiene cache, Cookies, Local Storage e IndexedDB con frammenti di conversazioni recenti. Il file Cookies SQLite conserva i token di sessione utili a stabilire persistenza. Per Slack, %AppData%\Slack\storage contiene database Leveldb con cache messaggi. Su macOS gli equivalenti sono ~/Library/Application Support/Microsoft/Teams e ~/Library/Application Support/Slack.

Strumenti utili per l'acquisizione: Magnet AXIOM (a pagamento) e Cellebrite Inspector (a pagamento) supportano parsing nativo di artefatti Teams e Slack. Per approccio open source, KAPE (gratuito per uso non commerciale) con target dedicati raccoglie le directory applicative, mentre DB Browser for SQLite (open source) permette l'analisi manuale di cookies e cache.

La timeline di correlazione ideale unisce: sign-in evento in AADSignInLogs → token issuance → prima chiamata API di lettura → picco di volume su endpoint di collezione → eventuali export via eDiscovery. Il campo CorrelationId nelle API Microsoft consente di legare eventi distribuiti tra servizi diversi (Azure AD, Graph, Teams) allo stesso session context.

Elementi da preservare come evidenza: audit log esportati in formato immutabile, token JWT decodificati con claim originali, app registration di eventuali app OAuth malevole scoperte nel tenant.

Il panorama degli attori che sfruttano T1213.005 è ristretto ma significativo, con tre gruppi documentati che rappresentano archetipi molto diversi di modus operandi.

Fox Kitten (G0117), attribuito all'ecosistema iraniano, ha utilizzato l'accesso a Microsoft Teams delle vittime per raccogliere informazioni valorizzabili all'interno di ambienti IT e security. Il pattern osservato indica un uso di Teams come fonte di intelligence interna dopo la compromissione di ambienti aziendali, coerente con il profilo del gruppo orientato allo spionaggio a lungo termine e al pre-positioning in infrastrutture critiche. L'interesse per canali di security suggerisce anche una componente di counter-IR.

LAPSUS$ (G1004) ha operato come attore estorsivo giovane e mediaticamente esposto, con vittime di alto profilo nel settore tech. Il gruppo ha sistematicamente cercato canali di collaborazione come MS Teams e Slack per scoprire credenziali di account privilegiati aggiuntivi. Il pattern è tipicamente opportunistico: dopo l'accesso iniziale (spesso via SIM swap o social engineering all'help desk), il gruppo pivottava rapidamente sulle chat per trovare segreti condivisi in chiaro — un vettore di privilege escalation efficace perché sfrutta la cultura dev-friendly di condividere token e password nei canali privati.

Scattered Spider (G1015), noto anche come UNC3944 o Octo Tempest, ha portato lo sfruttamento della tecnica al livello più sofisticato dal punto di vista tattico. Il gruppo ricerca attivamente in Slack e Microsoft Teams le conversazioni relative all'intrusione in corso e alla risposta all'incidente. Questa capacità di live monitoring del team di difesa consente a Scattered Spider di anticipare le mosse di contenimento, migrare persistenze e negoziare da posizione di vantaggio informativo. Il gruppo ha colpito ripetutamente settori telco, hospitality e retail nordamericani, spesso in combinazione con affiliazioni ransomware come ALPHV/BlackCat.

I pattern trasversali ai tre gruppi meritano attenzione. Primo: la tecnica è quasi sempre post-compromise, dipendente da credenziali valide o token — nessuno dei gruppi usa exploit su Teams o Slack, ma abusa di accessi legittimi. Secondo: il valore raccolto è principalmente credential-oriented (LAPSUS$) o intelligence-oriented (Fox Kitten, Scattered Spider), raramente esfiltrazione di massa. Terzo: la componente di counter-IR è emergente e va considerata sistemica per attori sofisticati.

Il trend previsto vede crescita dell'abuso di OAuth app malevole installate nei tenant per persistenza sulle chat aziendali, e maggiore integrazione tra credential theft (via infostealer) e riuso dei token di sessione Teams/Slack. La mitigazione M1060 (Out-of-Band Communications) diventa quindi essenziale: gestire l'IR su canale separato (Signal, telefonia dedicata) impedisce agli attori tipo Scattered Spider di leggere il playbook difensivo in tempo reale.

MITRE ATT&CK: T1213.005 (Messaging Applications), TA0009 (Collection). Gruppi: G0117 (Fox Kitten), G1004 (LAPSUS$), G1015 (Scattered Spider). Mitigazioni: M1017, M1047, M1060. Detection: DET0567, AN1565, AN1566. Le sezioni Ethical Hacker, SOC Specialist e Forensic Analyst integrano conoscenza professionale verificata su tool open source e piattaforme SaaS (Microsoft Graph, Slack API, Microsoft Purview) per comandi operativi, artefatti e procedure di detection.