Raccolta Dati da Wiki Aziendali: Confluence (T1213.001)

La simulazione di questa tecnica presuppone che tu abbia già ottenuto credenziali valide per l'istanza Confluence — tipicamente un account di sviluppatore, un token API o una sessione rubata. L'obiettivo del test è dimostrare quante informazioni sensibili un account con permessi ordinari può estrarre, e in quanto tempo.

Il primo passo è l'enumerazione degli space. L'API REST di Confluence espone un endpoint dedicato. Tramite curl, con un token personale (PAT) o credenziali base, puoi ottenere l'elenco completo degli space accessibili:

curl -s -u utente:token "/rest/api/space?limit=500" | jq '.results[] | {key: .key, name: .name, type: .type}'

Questo restituisce chiave, nome e tipo di ogni space. A quel punto, per ogni space interessante, puoi enumerare le pagine con:

curl -s -u utente:token "/rest/api/space/SPACEKEY/content/page?limit=100&expand=body.storage" | jq '.results[] | {title: .title, id: .id}'

Espandendo il campo body.storage ottieni il contenuto HTML della pagina in linea. Per un'estrazione massiva, uno script Bash o Python che itera sugli space e scarica tutte le pagine è banale da costruire. Lo strumento confluence-dumper (open source), disponibile su GitHub, automatizza esattamente questo processo: dato un URL base e credenziali, effettua il dump completo di space, pagine e allegati in formato locale.

Una volta ottenuto il dump, la fase di mining è cruciale. Cerca credenziali hardcoded con pattern regex:

grep -rEi '(password|passwd|secret|token|api_key)\s[:=]' ./dump/*

Per individuare diagrammi di rete e architetture, filtra per allegati con estensione .vsd, .drawio, .png, .pdf. Non sottovalutare le pagine che contengono link a share SMB o percorsi UNC — sono indicatori diretti di risorse interne raggiungibili.

Nel report di penetration test, documenta tre metriche fondamentali: il numero di space accessibili dall'account compromesso rispetto al totale, il volume di credenziali in chiaro trovate e la presenza di documentazione di rete che mappa l'infrastruttura. Queste metriche trasformano un finding generico in un rischio quantificabile per il cliente.

Per ambienti Confluence Cloud, tieni presente che l'autenticazione avviene via token API Atlassian e le chiamate REST hanno endpoint leggermente diversi (con prefisso /wiki). Lo strumento Nuclei (open source) di ProjectDiscovery include template per verificare configurazioni errate e permessi eccessivi su istanze Confluence esposte.

La detection di questa tecnica ruota attorno a un concetto chiave: l'accesso anomalo per volume, velocità o contesto. Un utente legittimo consulta Confluence in modo organico — poche pagine alla volta, con pause naturali, da un browser standard. Un attaccante o uno script di scraping mostra pattern radicalmente diversi.

La detection DET0358 — Programmatic and Excessive Access to Confluence Documentation — definisce quattro parametri di tuning che diventano la tua base operativa. Il primo è la finestra temporale (TimeWindow): stabilisci un intervallo (ad esempio 5 o 15 minuti) oltre il quale un burst di accessi diventa sospetto. Il secondo è la soglia di accesso (AccessThreshold): quante pagine può ragionevolmente visualizzare o esportare un singolo utente in quella finestra? Nella maggior parte degli ambienti, superare 30-50 pagine in 5 minuti è altamente anomalo.

Il terzo parametro è il contesto utente (UserContext). Un domain admin che improvvisamente consulta decine di pagine di documentazione tecnica in space a cui non ha mai acceduto merita un alert ad alta priorità. Al contrario, un tecnico che lavora quotidianamente su uno space specifico potrebbe generare picchi legittimi — questo va gestito come falso positivo noto. Il quarto parametro è il filtro sugli User-Agent (AgentFilter): stringhe che indicano accesso via script Python (come python-requests), curl, o agent generici non associati a browser interattivi sono fortemente indicative di automazione.

La log source primaria è il log audit di Confluence stesso, indicato come saas:confluence. Su Confluence Data Center, i log di accesso si trovano nella directory <confluence-home>/logs/ e registrano ogni visualizzazione di pagina con timestamp, utente e indirizzo IP. Per Confluence Cloud, Atlassian espone gli audit log tramite la console di amministrazione e le API di Atlassian Access.

Una regola SIEM efficace correla tre segnali: volume di pagine accedute sopra soglia nella finestra temporale, User-Agent non standard e primo accesso dell'utente a quello space specifico (analisi di baseline comportamentale). Se il tuo SIEM supporta il concetto di first seen, sfruttalo: un account che accede per la prima volta a 10 space diversi in un'ora è un indicatore ad altissima affidabilità.

Per ridurre i falsi positivi, crea una whitelist di service account noti — bot di migrazione, integrazioni CI/CD, connettori Jira — e monitora separatamente il loro comportamento con soglie più elevate. Non escluderli dalla detection: limitati ad assegnare loro una severità differente.

Quando un incidente coinvolge l'estrazione massiva di dati da Confluence, la ricostruzione forense deve coprire due domini: i log applicativi della piattaforma e gli artefatti endpoint della macchina da cui l'attaccante ha operato.

Sul lato Confluence, il punto di partenza è l'audit log nativo. Nelle installazioni Data Center, il file atlassian-confluence.log e l'audit log accessibile da interfaccia amministrativa registrano eventi di tipo page view, page export, attachment download e space export. Ogni entry contiene timestamp, username, indirizzo IP sorgente e risorsa acceduta. Cerca in particolare eventi di export in formato PDF, Word o XML dell'intero space — questa funzionalità è legittima ma raramente usata su larga scala, e rappresenta il metodo più rapido per esfiltrare un repository completo.

Se l'attaccante ha usato le API REST, i log del reverse proxy o del load balancer davanti a Confluence (tipicamente Nginx o Apache) registrano le chiamate con path, parametri e User-Agent. Filtra per path contenenti /rest/api/content, /rest/api/space e /rest/api/search con parametri limit elevati — valori come limit=500 o limit=1000 sono firma quasi certa di scraping automatizzato.

Sul lato endpoint, se l'attaccante ha operato da una workstation compromessa, cerca nei log del browser (cronologia e cache) le tracce di navigazione massiva su Confluence. Per Chrome, il database SQLite History nella directory del profilo utente contiene URL e timestamp di ogni pagina visitata. Se ha usato script, cerca artefatti di esecuzione: nei sistemi Windows, i log PowerShell Script Block Logging (EventCode 4104) e i record di Prefetch per python.exe o curl.exe possono rivelare l'esecuzione degli strumenti di dump.

Per la timeline, l'artefatto più prezioso è la correlazione tra il primo accesso anomalo a Confluence (dal log applicativo) e l'attività di autenticazione che lo ha preceduto. Verifica nei log di Active Directory o dell'IdP (Okta, Azure AD) come e quando l'account utilizzato ha ottenuto la sessione: un accesso VPN da IP insolito seguito da burst su Confluence in pochi minuti è un pattern classico da documentare nella catena degli eventi.

Se l'ambiente utilizza un proxy web, i log proxy forniscono un ulteriore punto di correlazione — volume di dati trasferiti dall'endpoint verso il server Confluence e, soprattutto, eventuali connessioni successive verso destinazioni esterne che suggeriscono esfiltrazione.

Il panorama degli attori che sfruttano Confluence come fonte di collection è, nei dati disponibili, dominato da un unico gruppo documentato, ma il suo profilo è estremamente istruttivo per comprendere il modello operativo.

LAPSUS$ (G1004) ha cercato attivamente piattaforme di collaborazione come Confluence e JIRA nelle reti delle vittime, con un obiettivo preciso: scoprire credenziali di account ad alto privilegio. Questo approccio rivela una logica operativa sofisticata — il gruppo non si limitava a sfruttare le credenziali iniziali, ma utilizzava le wiki aziendali come acceleratore per l'escalation dei privilegi. Confluence, in questo contesto, non era il bersaglio finale ma un moltiplicatore di capacità offensiva.

Il pattern di LAPSUS$ è particolarmente rilevante perché il gruppo operava con un modello low-and-slow nella fase di collection: una volta dentro la rete, invece di lanciare tool rumorosi di enumerazione, consultava la documentazione interna per capire l'architettura del target. Questo approccio rende la fase di raccolta quasi invisibile ai controlli tradizionali basati su firma, perché l'attività assomiglia a quella di un dipendente curioso.

Dal punto di vista del targeting geografico e settoriale, LAPSUS$ ha colpito organizzazioni di grandi dimensioni nel settore tecnologico e delle telecomunicazioni, dove Confluence è particolarmente diffuso come repository di documentazione tecnica. Questo suggerisce una selezione intenzionale dei target basata anche sulla probabilità di trovare piattaforme wiki ricche di informazioni.

Per il modello predittivo, qualsiasi organizzazione che utilizzi Confluence come repository centralizzato di documentazione tecnica — specialmente se contiene diagrammi di rete, credenziali di ambienti non produttivi o documentazione di architettura — dovrebbe considerare questo scenario come altamente probabile dopo una compromissione iniziale. La mitigazione più efficace dal punto di vista intelligence è la riduzione della superficie informativa: classificare il contenuto di Confluence e rimuovere proattivamente credenziali, diagrammi dettagliati e informazioni di accesso che non hanno ragione di risiedere su una piattaforma collaborativa.

Il trend più significativo è che la tecnica non richiede tool specializzati — bastano un browser e credenziali valide — il che la rende accessibile a qualsiasi categoria di threat actor, dal gruppo APT al insider threat.

Framework MITRE ATT&CK: tecnica T1213.001 (Confluence), tattica TA0009 (Collection), gruppo G1004, mitigazioni M1017 / M1047 / M1018, detection DET0358. Integrato con conoscenza professionale per tool e procedure operative.