Skip to content
KitploitKITPLOIT
StrumentiExploitsBlog
Log in
Invia
StrumentiExploitsBlog
Invia

Strumenti di Hacking, PenTest e Cybersecurity per il tuo Arsenale di Sicurezza!

Kitploit è una directory di strumenti di hacking, cybersecurity e pentesting. Scopri gli ultimi aggiornamenti dei progetti per trovare vulnerabilità, analizzare sistemi, automatizzare i test e rafforzare la tua sicurezza.

FeedContattoPrivacy© 2026 Kitploit

Directory degli strumenti

Categorie

Vedi tutte le categorie
Loading categories
redcap_cve_2026_90817_scan — 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 | Kitploit
Strumenti/GitHubGitHub/ctsit/redcap_cve_2026_90817_scan
Strumenti DifensiviGestione degli Indicatori di Compromissione (IOC)Scanner di VulnerabilitàAudit di ConfigurazioneSicurezza WebAnalisi MalwareDigital ForensicsRisposta agli Incidenti

Più Popolari

Vedi tutti →

Scopri gli strumenti più utilizzati dalla nostra community.

Esplora tutti gli strumenti

Sfoglia la nostra collezione di strumenti

Vedi tutti gli strumenti →
Analisi dei Log
GitHubctsit/redcap_cve_2026_90817_scan

redcap_cve_2026_90817_scan

Vedi Repository
216 giorni faNon ancora revisionato

Informazioni

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

Condividi

Scanner di compromissione REDCap per CVE-2026-90817

DOI

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:

  1. Sono vulnerabile? La versione di REDCap installata è precedente alle release corrette?
  2. Sono compromesso? Sono presenti alcuni degli indicatori di compromissione (IOC) documentati — e, se l'host è stato attaccato, gli attacchi sono arrivati prima o dopo la sua correzione?

Sicurezza / ambito

Questo strumento è solo per il rilevamento. Esso:

  • non invia mai richieste HTTP e non riproduce mai l'exploit o alcun payload;
  • non modifica, mette in quarantena, elimina o "pulisce" mai nulla;
  • legge solo file, metadati dei processi, socket e log sull'host.

È destinato a un amministratore che lo esegue contro il proprio server REDCap.

Requisiti

  • Python 3.7+. Solo libreria standard — nessuna installazione tramite pip. Un singolo file; copialo sull'host ed eseguilo.
  • Linux (famiglie Debian e RHEL): pienamente supportato. I log di Apache vengono scansionati automaticamente in /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.
  • Windows (REDCap su IIS o Apache/XAMPP): non testato — non è mai stato eseguito su un host Windows. Vedi Piattaforme e supporto Windows. Esegui da un PowerShell/cmd con privilegi elevati per una scansione completa.

Utilizzo

# 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.

Opzioni

FlagPredefinitoScopo
--redcap-root PATH/var/www/html/redcapDirectory 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|windowsautoPiattaforma 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-DDrilevata automaticamenteData 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-scandisattivatoCalcola ricorsivamente l'hash dei file in temp/cache e nelle directory di staging (più lento).
--max-log-matches N | all100Quante 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.
--jsondisattivatoEmette JSON invece del report testuale.
--quietdisattivatoSopprime le righe OK/INFO nell'output testuale.

Codici di uscita

CodiceSignificato
0Pulito e aggiornato, e la scansione è stata completata integralmente.
1Una o più rilevazioni (versione vulnerabile e/o IOC/attacco) — da investigare.
2La scansione non è potuta essere completata integralmente (errori, oppure senza privilegi e altrimenti pulito — non è stato possibile affermare pienamente un risultato pulito).

Cosa controlla

Ogni IOC documentato corrisponde a un controllo locale passivo:

  • Stato della versione / patch — legge la versione installata dai nomi delle directory 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).
  • File noti come dannosi in 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.
  • Staging del miner — directory .syslog-*, archivi xmrig* e le directory dei concorrenti (/dev/shm/duet, /var/tmp/.bin) a cui la campagna imposta i permessi 000.
  • Processi — miner (riferimenti a XMRig / pool / wallet), eseguibili in esecuzione da /var/tmp, /dev/shm, /tmp e processi camuffati syslog-ng-*.
  • Socket — l'API JSON-RPC locale di XMRig su 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.
  • Persistenza tramite cron — cradle fetch-to-shell e riferimenti IOC nei crontab di sistema e per utente.
  • 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.)
  • Shell rc / ~/.profile — codice di avvio iniettato e anti-forensics tramite HISTFILE.
  • Log di accesso del web server — firme dei tentativi di exploit (vedi sotto).
Scarica lo strumento