
Uno scanner passivo e in sola lettura che verifica un host REDCap per l'esposizione a e la compromissione da **CVE-2026-90817** — la vulnerabilità di esecuzione di codice da remoto sull'endpoint delle survey non autenticato, sfruttata dalla campagna di cryptomining XMRig documentata da Palo Alto Unit 42
redcap_cve_2026_90817_scan.py è uno scanner passivo e in sola lettura che verifica
un host REDCap per l'esposizione a e la compromissione da CVE-2026-90817 — la
vulnerabilità di esecuzione di codice da remoto non autenticata sull'endpoint delle survey,
sfruttata dalla campagna di cryptomining XMRig documentata da Palo Alto Unit 42
(2026-10-07-XMRig-campaign-through-CVE-2026-90817).
Risponde a due domande sull'host su cui viene eseguito:
Questo strumento è solo per il rilevamento. Esso:
È destinato a un amministratore che lo esegue contro il proprio server REDCap.
pip. Un singolo file; copialo
sull'host ed eseguilo./var/log/apache2 (Debian) o /var/log/httpd
(RHEL/CentOS/Rocky/Alma), e quelli di nginx in /var/log/nginx. Su RHEL 8 il python3
di sistema è la 3.6, quindi invoca python3.9 (o superiore) lì; RHEL/Rocky/Alma 9
includono la 3.9+. Esegui come root per una scansione completa (i crontab per utente, le
authorized_keys degli altri utenti e /proc/<pid>/exe, e alcuni log sono altrimenti
illeggibili). Senza root viene comunque eseguito e contrassegna chiaramente il risultato come
scansione parziale.# Simplest: defaults to /var/www/html/redcap, auto-detects the mitigation date
sudo python3 -I redcap_cve_2026_90817_scan.py
# Point at a non-default install, pin the mitigation date, list every attack entry
sudo python3 -I redcap_cve_2026_90817_scan.py \
--redcap-root /var/https/redcap \
--mitigation-date 2026-09-21 \
--max-log-matches all
# Machine-readable output for monitoring / ticketing
sudo python3 -I redcap_cve_2026_90817_scan.py --json
Su Windows, eseguire da un prompt con privilegi elevati e puntare --redcap-root alla
directory di installazione (la piattaforma e le directory di log predefinite vengono rilevate automaticamente):
# IIS or Apache/XAMPP; logs under C:\inetpub\logs\LogFiles or the Apache logs dir
python -I redcap_cve_2026_90817_scan.py --redcap-root C:\redcap --json
-I esegue Python in modalità isolata (ignora $PYTHONPATH e la CWD) — una buona pratica
quando si analizza un host potenzialmente compromesso.
| Flag | Predefinito | Scopo |
|---|---|---|
--redcap-root PATH | /var/www/html/redcap | Directory radice dell'installazione REDCap. |
--log-dir DIR (ripetibile) | specifico della piattaforma (Apache/nginx su Linux; IIS LogFiles + Apache su Windows) | Directory dei log del web server da analizzare (gestisce i file .gz ruotati e i log W3C di IIS). |
--home-dir DIR (ripetibile) | /root + ogni /home/* (Linux); ogni C:\Users\* (Windows) | Directory home aggiuntive in cui cercare chiavi SSH / file shell/profile. |
--platform auto|linux|windows | auto | Piattaforma host da assumere. Rilevata automaticamente dal sistema operativo; forzala per selezionare un provider (le sonde host specifiche del sistema operativo vengono comunque eseguite solo sul sistema operativo live corrispondente). |
--mitigation-date YYYY-MM-DD | rilevata automaticamente | Data in cui la vulnerabilità è stata chiusa tramite aggiornamento. Vedi Tempistica dell'attacco. |
--since YYYY-MM-DD | — | Esamina solo le voci dei log web a partire da questa data (inclusa). I file di log modificati in precedenza non vengono aperti. Si applica a entrambe le passate sui log; i controlli sullo stato dell'host non sono interessati. Vedi Tempistica dell'attacco. |
--until YYYY-MM-DD | — | Esamina solo le voci dei log web fino a questa data (inclusa). |
--full-hash-scan | disattivato | Calcola ricorsivamente l'hash dei file in temp/cache e nelle directory di staging (più lento). |
--max-log-matches N | all | 100 | Quante voci di log di attacco elencare per categoria, mantenute alla lettera. |
--attacker-ip IP (ripetibile) | — | IP aggiuntivo di un attaccante noto (ad es. dalla scansione di un altro host). Trattato come l'IP IOC documentato. Vedi Seconda passata. |
--json | disattivato | Emette JSON invece del report testuale. |
--quiet | disattivato | Sopprime le righe OK/INFO nell'output testuale. |
| Codice | Significato |
|---|---|
0 | Pulito e aggiornato, e la scansione è stata completata integralmente. |
1 | Una o più rilevazioni (versione vulnerabile e/o IOC/attacco) — da investigare. |
2 | La scansione non è potuta essere completata integralmente (errori, oppure senza privilegi e altrimenti pulito — non è stato possibile affermare pienamente un risultato pulito). |
Ogni IOC documentato corrisponde a un controllo locale passivo:
redcap_vX.Y.Z e la confronta con le release aggiornate
(16.0.49 LTS / 17.3.10 LTS / 17.4.4 Standard; soglia inferiore interessata 13.3.0).temp/cache — ogni file presente (e nelle directory
di staging) viene sottoposto a hash confrontandolo con lo SHA-256 del dropper di Unit 42. Nota: lo strumento non
segnala i file in base all'estensione .bladec. Il core di REDCap utilizza il motore di template
BladeOne, che scrive template compilati .bladec con nomi basati su hash in temp/cache come
output normale, quindi l'estensione non è un indicatore di compromissione; un file droppato
realmente malevolo viene individuato tramite l'hash del suo contenuto, indipendentemente dall'estensione..syslog-*, archivi xmrig* e le directory dei concorrenti
(/dev/shm/duet, /var/tmp/.bin) a cui la campagna imposta i permessi 000./var/tmp, /dev/shm, /tmp e processi camuffati syslog-ng-*.127.0.0.1:50001 e le connessioni
attive verso gli IP sorgente dell'attaccante — quello documentato, quelli
osservati, qualsiasi --attacker-ip e ogni IP scoperto dal controllo dei log web.authorized_keys SSH — chiavi corrispondenti all'impronta della backdoor dell'attaccante.
(Deliberatamente non elenca chiavi non correlate per "revisione" — su un host normale
quelle appartengono ad account reali e non sono verificabili in modo indipendente.)~/.profile — codice di avvio iniettato e anti-forensics tramite HISTFILE.