A chi è rivolta questa Knowledge Base

Questa guida è rivolta principalmente a:

• MSP e Managed Security Service Provider;
• System Integrator;
• responsabili IT e Security;
• team SOC;
• DevSecOps;
• tecnici che utilizzano RidgeBot per attività di vulnerability validation e penetration testing automatizzato.

Le informazioni specifiche sulle nuove funzioni della versione 7.1 derivano dalla comunicazione tecnica ufficiale Ridge Security relativa a RidgeBot 7.1. Le caratteristiche generali della piattaforma e il contesto tecnologico sono stati verificati sulla documentazione pubblica ufficiale Ridge Security e Microsoft.

1. Perché il crawling autenticato è importante

Un penetration test di un’applicazione web può essere efficace soltanto sulle aree che il sistema di testing riesce effettivamente a raggiungere.

Quando un’applicazione richiede autenticazione, una scansione non autenticata può limitarsi alla superficie esposta prima del login. Intere sezioni dell’applicazione, funzionalità amministrative, workflow interni e URL accessibili esclusivamente agli utenti autenticati possono quindi rimanere fuori dal perimetro effettivamente analizzato.

RidgeBot prevede già scenari di Authenticated Penetration, nei quali vengono utilizzate credenziali valide per eseguire test più approfonditi simulando un attaccante che abbia già ottenuto un livello iniziale di accesso. La documentazione Ridge descrive inoltre lo Smart Web Crawling come una delle tecnologie utilizzate per identificare e documentare le superfici di attacco delle applicazioni.

La documentazione Ridge precedente alla 7.1 contemplava già il crawling di pagine web protette da login e la possibilità di utilizzare modalità di crawler personalizzate per superare l’autenticazione web.

La novità di RidgeBot 7.1 è quindi più specifica: il web crawler può utilizzare l’autenticazione NTLMv2 per raggiungere applicazioni protette da Windows Authentication.

2. Cosa cambia con RidgeBot 7.1

La release 7.1 interviene su sei aree principali:

1. autenticazione NTLMv2 nel web crawler;
2. ampliamento della copertura delle vulnerabilità;
3. raw HTTP trace per il crawler;
4. maggiore affidabilità del Windows Botlet;
5. hardening dell’integrazione JIRA;
6. protezione delle credenziali nelle integrazioni DevOps.

La novità con il maggiore impatto operativo è il primo punto, soprattutto negli ambienti enterprise e nelle infrastrutture Windows.

3. Supporto NTLMv2 per il Web Crawling

Il contesto: Windows Authentication e IIS

Windows Authentication viene comunemente utilizzata nelle applicazioni intranet basate su Microsoft IIS e può sfruttare Kerberos o NTLM.

Microsoft indica infatti Windows Authentication come particolarmente adatta agli ambienti aziendali e intranet e documenta due provider principali:

• Negotiate, che tenta di utilizzare Kerberos quando disponibile;
• NTLM, che utilizza il protocollo Windows NT LAN Manager.

Questo tipo di autenticazione può trovarsi, ad esempio, davanti a:

• portali intranet;
• applicazioni amministrative interne;
• software gestionali web legacy;
• applicazioni custom pubblicate tramite IIS;
• interfacce operative accessibili soltanto agli utenti del dominio;
• applicazioni che utilizzano account Windows per l’accesso.

In questi scenari, un crawler incapace di completare l’autenticazione può non riuscire a raggiungere una parte significativa dell’applicazione.

Cosa introduce RidgeBot 7.1

Secondo le release information ufficiali comunicate da Ridge Security, RidgeBot 7.1 implementa il supporto end-to-end a NTLMv2 per il web crawler.

Questo permette di effettuare crawling autenticato contro applicazioni Windows-protected che utilizzano NTLMv2.

Le credenziali vengono associate attraverso il workflow già esistente dei DevSecOps credential group e configurate per il singolo host.

Un elemento particolarmente importante riguarda la protezione delle credenziali: Ridge dichiara che le credenziali risolte vengono trasmesse al componente interessato utilizzando un file temporaneo protetto, anziché essere inserite nella command line.

Questo riduce il rischio che informazioni sensibili possano essere esposte attraverso process list, logging della riga di comando o strumenti di diagnostica.

4. Come preparare una scansione autenticata NTLMv2

Prima di configurare il task è necessario verificare che l’applicazione target utilizzi effettivamente Windows Authentication e che NTLM sia tra i protocolli accettati.

Non bisogna presupporre che ogni applicazione IIS utilizzi NTLM.

Microsoft indica infatti Kerberos come metodo di autenticazione preferibile negli ambienti Active Directory, mentre NTLM rimane supportato per esigenze di compatibilità e per specifici scenari applicativi.

Verificare quindi:

• che il target sia autorizzato al penetration test;
• che Windows Authentication sia effettivamente utilizzata;
• che NTLM/NTLMv2 sia accettato dal target;
• che l’account destinato alla scansione sia attivo;
• che l’account disponga soltanto dei privilegi necessari per il test;
• che RidgeBot possa raggiungere l’applicazione target a livello di rete;
• che eventuali proxy, WAF, IPS o altri sistemi intermedi non impediscano il corretto completamento dell’autenticazione.

5. Gestione delle credenziali

Per l’autenticazione NTLMv2, RidgeBot 7.1 utilizza il sistema di gestione delle credenziali già previsto nei workflow DevSecOps.

La comunicazione ufficiale Ridge specifica che le credenziali vengono:

1. inserite nel relativo credential group;
2. associate al target/host interessato;
3. utilizzate dal web crawler durante il task.

Per ragioni di sicurezza è consigliabile utilizzare un account dedicato alle attività di security testing, quando tecnicamente possibile.

L’account dovrebbe seguire il principio del least privilege: deve poter accedere alle funzioni oggetto del test senza disporre inutilmente di privilegi amministrativi o di accesso ad altre risorse aziendali.

Da evitare

Non è consigliabile utilizzare:

• account personali degli amministratori;
• Domain Administrator;
• credenziali condivise non tracciabili;
• password di produzione utilizzate anche per altri servizi;
• account con privilegi superiori a quelli necessari per lo scenario di test.

6. Verificare che la scansione sia effettivamente autenticata

RidgeBot 7.1 introduce un’indicazione specifica nella pagina di dettaglio del task.

Quando sono in uso credenziali NTLM, viene visualizzato il badge:

Authenticated scan

L’indicatore permette al tecnico di distinguere immediatamente una scansione autenticata da una scansione che ha raggiunto soltanto la parte pubblicamente accessibile dell’applicazione.

Questo elemento è particolarmente importante nella documentazione degli assessment.

Dire semplicemente che un’applicazione è stata “scansionata” non è infatti sufficiente: occorre sapere quanta parte dell’applicazione sia stata effettivamente raggiunta dal crawler.

Il badge costituisce quindi un utile elemento operativo per:

• verificare la configurazione del task;
• documentare la profondità dell’assessment;
• confrontare test autenticati e non autenticati;
• supportare attività di troubleshooting.

7. Raw HTTP Trace del Web Crawler

RidgeBot 7.1 introduce inoltre un’opzione per acquisire il traffico HTTP generato dal crawler.

La funzione è opt-in e configurabile per singolo task.

Quando viene abilitata, RidgeBot registra in formato leggibile le richieste e le risposte HTTP relative alle transazioni effettuate durante il crawling.

Questa funzione può essere particolarmente utile in caso di:

• problemi di autenticazione;
• redirect anomali;
• pagine che non vengono correttamente raggiunte;
• problemi di sessione;
• comportamenti differenti tra browser e crawler;
• errori applicativi;
• attività di troubleshooting con il supporto Ridge.

La traccia può permettere al tecnico di ricostruire con maggiore precisione il comportamento della scansione.

Protezione delle credenziali

Ridge Security specifica che gli header contenenti credenziali vengono automaticamente redatti nelle tracce.

Questo permette di utilizzare più agevolmente il file all’interno dei support bundle senza includere direttamente i dati di autenticazione.

Rimane comunque consigliabile trattare i trace come informazioni potenzialmente sensibili, perché richieste e risposte HTTP possono contenere:

• URL interni;
• hostname;
• identificativi;
• parametri applicativi;
• cookie;
• dati restituiti dall’applicazione;
• informazioni sulla struttura del sistema.

Prima di trasferire il materiale al supporto o a terze parti è quindi consigliabile applicare le normali procedure aziendali per la gestione dei dati diagnostici.

8. Quando utilizzare il Raw HTTP Trace

Il tracing HTTP non dovrebbe necessariamente essere lasciato sempre attivo.

È particolarmente indicato quando:

• il crawler non riesce a completare il login;
• il badge di scansione autenticata non compare;
• alcune aree dell’applicazione non vengono individuate;
• si sospetta un problema con redirect o sessioni;
• il server restituisce errori HTTP;
• occorre aprire una richiesta di supporto;
• è necessario confrontare due configurazioni differenti.

Dopo aver terminato l’analisi è opportuno disattivare il tracing se non è più necessario e gestire o eliminare i file prodotti secondo le policy aziendali.

9. Troubleshooting dell’autenticazione NTLMv2

Il target restituisce HTTP 401

Verificare:

• correttezza di username, password e dominio;
• stato dell’account;
• eventuale blocco dell’account;
• configurazione Windows Authentication sul server;
• provider di autenticazione abilitati;
• raggiungibilità del Domain Controller, se necessaria;
• presenza di proxy o componenti intermedi;
• associazione corretta del credential group al target.

Un HTTP 401 non deve automaticamente essere interpretato come vulnerabilità o problema di RidgeBot: può essere semplicemente il risultato di un’autenticazione non completata.

Il target restituisce HTTP 403

Il server potrebbe aver autenticato correttamente l’utente ma negargli l’accesso alla specifica risorsa.

In questo caso verificare i permessi assegnati all’account utilizzato per il test.

È importante non aumentare indiscriminatamente i privilegi dell’account esclusivamente per ottenere una copertura maggiore: la configurazione delle credenziali dovrebbe riflettere lo scenario di attacco o il profilo utente che si intende effettivamente validare.

Il browser accede ma RidgeBot no

Controllare:

• protocollo effettivamente negoziato dal browser;
• configurazione Kerberos/NTLM;
• redirect;
• proxy;
• autenticazioni aggiuntive;
• eventuali cookie o meccanismi di sessione;
• differenze tra hostname e FQDN;
• configurazione dell’applicazione.

Il raw HTTP trace introdotto nella 7.1 può essere particolarmente utile in questo scenario.

Il badge “Authenticated scan” non compare

Verificare:

• presenza delle credenziali nel task;
• associazione al corretto host;
• corretto credential group;
• successo dell’autenticazione;
• scope del crawler;
• eventuali errori registrati nel task.

Se il comportamento persiste, acquisire la traccia HTTP e utilizzare il materiale per una richiesta di supporto.

10. Non riabilitare NTLM esclusivamente per eseguire il test

Questo punto merita particolare attenzione.

La presenza del supporto NTLMv2 in RidgeBot non significa che NTLM debba essere introdotto o riattivato negli ambienti nei quali è stato disabilitato.

Microsoft considera Kerberos il metodo di autenticazione preferenziale negli ambienti Active Directory e mette a disposizione strumenti e impostazioni per identificare e ridurre l’utilizzo di NTLM.

Di conseguenza:

se NTLM è stato disabilitato nell’ambito della security baseline dell’organizzazione, non dovrebbe essere riabilitato esclusivamente per consentire a RidgeBot di effettuare una scansione.

La configurazione del penetration test deve rispettare l’architettura e le policy di sicurezza dell’ambiente reale.

11. 19 nuovi security plugin

RidgeBot 7.1 introduce inoltre 19 nuovi plugin di sicurezza.

Secondo la comunicazione Ridge, la nuova copertura interessa principalmente:

• piattaforme CMS;
• strumenti di data analytics;
• vulnerabilità di information disclosure.

L’obiettivo è ampliare ulteriormente il numero di condizioni che RidgeBot può identificare e validare durante gli assessment.

RidgeBot utilizza infatti una metodologia che non si limita alla detection: la piattaforma è progettata per individuare vulnerabilità e, nei limiti dello scenario autorizzato, tentare di validarne l’effettiva sfruttabilità, fornendo evidenze del rischio riscontrato.

Nota: l’elenco dettagliato dei 19 plugin deve essere consultato nelle release notes RidgeBot 7.1 ufficiali. Non è opportuno ricostruirlo o dedurlo da fonti secondarie.

12. Miglioramenti al Windows Botlet

La release introduce anche miglioramenti dedicati al componente Windows Botlet.

Nell’architettura RidgeBot, il Botlet viene utilizzato per attività successive alla compromissione controllata, comprese operazioni di post-exploitation e lateral movement previste dallo scenario di test. La documentazione Ridge conferma inoltre il supporto del Botlet alle piattaforme Windows e Linux.

Con RidgeBot 7.1 vengono introdotti:

• un trace log file-backed, persistente anche dopo il riavvio del processo;
• un runtime kill switch per interrompere il logging senza dover effettuare un nuovo deployment;
• logging più dettagliato durante le varie fasi di startup.

Secondo Ridge, il kill switch permette di disattivare il logging entro circa un minuto.

L’obiettivo è rendere più semplice la diagnosi dei problemi di deployment e consentire al supporto tecnico di individuare con maggiore precisione il punto nel quale il Botlet non riesce ad avviarsi correttamente.

13. JIRA Integration Hardening

RidgeBot è integrabile con piattaforme DevOps e IT Service Management per trasformare i finding di sicurezza in attività operative.

Ridge Security documenta pubblicamente la possibilità di integrare RidgeBot con strumenti come Jira, GitHub, Jenkins, ServiceNow e GitLab, così da trasferire vulnerabilità e attività di remediation all’interno dei workflow utilizzati dai team.

RidgeBot 7.1 introduce diversi interventi di hardening relativi a:

• JIRA Cloud;
• JIRA Data Center;
• field mapping;
• assegnazione delle label;
• rendering delle description;
• sanitizzazione dei payload.

L’obiettivo è ridurre la necessità di correzioni manuali sui ticket generati e garantire maggiore continuità tra detection, validazione e remediation.

14. Hardening delle credenziali nelle integrazioni DevOps

Un’altra modifica rilevante della versione 7.1 riguarda la modalità con cui vengono gestiti password e token API nell’interfaccia delle integrazioni DevOps.

Secondo Ridge Security, password e API token in chiaro non vengono più restituiti dalla DevOps integration list API.

L’interfaccia può quindi determinare il metodo di autenticazione configurato utilizzando indicatori booleani di presenza, senza ricevere nuovamente il valore della credenziale.

Dal punto di vista della sicurezza si tratta di una scelta significativa perché riduce la superficie attraverso la quale un segreto potrebbe essere:

• esposto al browser;
• intercettato attraverso strumenti di debugging;
• memorizzato involontariamente;
• registrato nei log;
• visualizzato da utenti che non hanno necessità di conoscerne il valore.

È un approccio coerente con il principio secondo cui un segreto, una volta configurato, non dovrebbe essere nuovamente esposto se il sistema non ha una reale necessità operativa di mostrarlo.

15. Best practice per MSP e System Integrator

L’introduzione delle scansioni NTLMv2 può essere utilizzata per migliorare la qualità degli assessment presso i clienti, ma deve essere accompagnata da alcune precauzioni.

Definire chiaramente lo scope

Prima del test documentare:

• applicazioni interessate;
• URL e hostname;
• account autorizzati;
• privilegi dell’account;
• finestre temporali;
• eventuali sistemi esclusi;
• modalità di gestione dei dati raccolti.

Utilizzare credenziali dedicate

Quando possibile creare un account destinato allo specifico assessment.

Applicare il least privilege

Non utilizzare un account amministrativo quando lo scenario prevede l’accesso di un normale utente.

Verificare la differenza tra scansione autenticata e non autenticata

In alcuni assessment può essere utile effettuare entrambe, così da osservare:

• superficie pubblicamente raggiungibile;
• superficie disponibile dopo l’autenticazione;
• vulnerabilità specifiche delle funzionalità interne.

Proteggere i trace

Anche con la redazione automatica delle credenziali, i file HTTP possono contenere informazioni sensibili sull’ambiente del cliente.

Conservare evidenze del test

Task, badge, risultati e report possono contribuire a documentare quale livello di accesso sia stato effettivamente utilizzato durante l’assessment.

16. Un authenticated scan non equivale automaticamente a un test completo

Il badge Authenticated scan indica che la scansione utilizza credenziali NTLM.

Non deve però essere interpretato come garanzia automatica che:

• ogni URL dell’applicazione sia stato raggiunto;
• ogni ruolo applicativo sia stato analizzato;
• tutte le funzionalità siano accessibili all’account;
• l’intero application flow sia stato percorso;
• ogni vulnerabilità possibile sia stata testata.

La copertura dipende comunque da:

• privilegi dell’account;
• routing applicativo;
• link raggiungibili;
• tecnologie utilizzate;
• scope configurato;
• meccanismi di sessione;
• logica dell’applicazione;
• sistemi intermedi.

Per questo la verifica dei risultati del crawler rimane una fase essenziale dell’assessment.

17. Perché RidgeBot 7.1 è rilevante per i servizi di sicurezza gestiti

Per un MSP o un System Integrator, il supporto NTLMv2 non rappresenta semplicemente una nuova modalità di autenticazione.

Il valore principale consiste nella possibilità di estendere la validazione della sicurezza a una porzione dell’ambiente applicativo che può rimanere invisibile a una scansione esterna tradizionale.

Questo consente di strutturare servizi più approfonditi per:

• applicazioni intranet;
• ambienti Windows legacy;
• portali amministrativi;
• applicazioni business interne;
• DevSecOps;
• continuous security validation;
• vulnerability management;
• verifiche successive alle attività di remediation.

La metodologia RidgeBot è infatti basata sulla validazione delle vulnerabilità attraverso scenari di attacco controllati e sulla produzione di evidenze utili alla prioritizzazione della remediation.

18. In sintesi

Con RidgeBot 7.1, Ridge Security estende la profondità delle attività di web application security testing introducendo il supporto NTLMv2 nel web crawler.

Le principali novità sono:

• crawling autenticato di applicazioni Windows-protected;
• configurazione delle credenziali per host tramite credential group;
• badge Authenticated scan;
• gestione delle credenziali attraverso secure temporary file;
• raw HTTP request/response trace con redazione degli header di autenticazione;
• 19 nuovi security plugin;
• logging e troubleshooting migliorati per Windows Botlet;
• hardening delle integrazioni JIRA;
• maggiore protezione di password e API token nelle integrazioni DevOps.

Per MSP e team IT, il beneficio principale consiste nella possibilità di validare con maggiore profondità quelle applicazioni interne che richiedono Windows Authentication, mantenendo al tempo stesso maggiore visibilità sul livello effettivamente raggiunto dalla scansione.