Gli aggressori amano trovare punti deboli nei nostri domini e nelle nostre reti. Troppo spesso possono entrare nei sistemi per rimanere in attesa e lanciare attacchi in un secondo momento. Un esempio è il famigerato attacco al software SolarWinds, che ha infettato fino a nove agenzie statunitensi e molte organizzazioni con backdoor nelle loro infrastrutture. Recenti indagini dimostrano che il Dipartimento di Giustizia potrebbe essere stato a conoscenza della potenziale violazione mesi prima che si verificasse. Prima di acquistare il software in questione, è stata installata una versione di prova su alcuni server campione e sembra che gli amministratori di rete si siano preoccupati e abbiano fatto domande quando è stato rilevato un traffico insolito da uno dei server. Gli investigatori sono stati chiamati a esaminare la situazione, ma nessuno ha capito il significato fino a mesi dopo.

La backdoor è stata infine scoperta da alcuni di questi stessi investigatori quando il software è stato trovato sui loro server. Se gli esperti del settore hanno impiegato mesi per scoprire che il software era stato backdoorato, chi di noi non è un esperto può aspettarsi di trovare questi aggressori nella propria rete?

Usare il filtraggio in uscita sui firewall

La raccomandazione in questo tipo di scenario è duplice. In primo luogo, non bisogna trascurare l’uso del filtro di uscita su un firewall per determinare se il traffico inviato in uscita dai vostri server è normale. È possibile utilizzare il firewall integrato di Windows per bloccare il traffico. Troppo spesso non utilizziamo le soluzioni integrate nell’infrastruttura esistente e ci affidiamo alle soluzioni di altri fornitori. Tuttavia, l’utilizzo del filtro in uscita comporta un notevole dispendio di tempo; le aziende spesso chiedono che le connessioni e le comunicazioni con gli altri server vengano prima di tutto e non si prendono il tempo e lo sforzo di determinare quale traffico sia normale e previsto.

In secondo luogo, non giudicate gli amministratori di rete quando si chiedono perché un fornitore faccia qualcosa di strano con il suo software. Capita spesso di indagare su qualcosa che sembra essere una fuga di informazioni inaspettata o un software che si comporta male, e di pensare di stare reagendo in modo eccessivo. Sicuramente qualche altra azienda ha già visto e segnalato questo comportamento e stiamo semplicemente fraintendendo ciò che sta accadendo?

Fare due diligence quando si acquista un nuovo software

Quando acquistate un nuovo software, assicuratevi che il personale sia autorizzato a indagare su qualsiasi traffico insolito che non possa essere spiegato e prendete in considerazione l’idea di passare a un processo di verifica “prima blocca, poi abilita” per il vostro firewall. Non introducete un nuovo software nel vostro dominio Active Directory prima di aver eseguito una vera e propria due diligence e un’indagine.

Ma cosa succede se la tecnica di attacco è un po’ più vicina a noi? Un altro metodo che gli aggressori utilizzano e che è altrettanto difficile da investigare e comprendere è lo stile di attacco “living off the land”, che utilizza il codice o l’infrastruttura esistente. Se avete una rete Active Directory, dovete fare un piccolo auto-esame. Se avete mai utilizzato un server Active Directory Certificate Services (ADCS) nella vostra rete, gli aggressori potrebbero essere in grado di passare da un utente normale ad un amministratore di dominio semplicemente sfruttando le vulnerabilità degli ADCS. Tenete presente che questo tipo di vulnerabilità non emerge da una normale scansione: dovete infatti conoscere alcuni di questi punti deboli.

Gli attacchi ADCS possono essere banali per i malintenzionati

Molto probabilmente la vostra infrastruttura Active Directory è in funzione da molti anni. Di conseguenza, potreste avere impostazioni vecchie, servizi residui e impostazioni di domini obsolete. I pentester e gli aggressori utilizzano spesso gli attacchi ADCS per dimostrare quanto possa essere banale ottenere l’accesso. Come illustrato da Spectorops in un whitepaper sull’argomento, esistono diversi metodi per eseguire le tecniche di attacco.

Se il vostro modello di certificato di Active Directory consente l’autenticazione del cliente e permette a chi si iscrive di fornire un nome alternativo soggetto (SAN) arbitrario, l’aggressore può richiedere un certificato basato sul modello vulnerabile e specificare un SAN arbitrario. In questo modo, se l’aggressore dispone di una password ottenuta da un utente autenticato sul dominio, può utilizzare vari strumenti per richiedere un certificato e specificare che il campo SAN è quello dell’amministratore del dominio. Potete già immaginare cosa succederà, visto che l’aggressore ha richiesto un certificato e lo ha ricevuto con l’equivalente dei diritti di amministratore del dominio. Anche se avete già risolto questo potenziale di violazione, dovreste comunque rivolgervi a tutti i consulenti a cui vi affidate e assicurarvi che controllino la loro Active Directory.

Alcune protezioni per gli ADCS sono integrate in Windows

Alcuni dei metodi che potete utilizzare per monitorare e prevenire questi attacchi sono già integrati in Windows. Dovrete monitorare l’evento 4886, che indica “I servizi di certificazione hanno ricevuto una richiesta di certificato”, e l’evento 4887, che indica “I servizi di certificazione hanno approvato una richiesta di certificato ed emesso un certificato”.

Infine, non dimenticate di controllare il livello funzionale del dominio della vostra rete. Il fatto che non sia presente in una versione più recente può spesso ostacolare l’introduzione di protezioni di sicurezza fondamentali. Un esempio è il recente rilascio della soluzione nativa per la password dell’amministratore locale di Windows (LAPS). Con gli aggiornamenti cumulativi di aprile 2023, Microsoft ha introdotto una nuova funzionalità in tutte le piattaforme Windows 10 e 11, nonché in Server 2022 e Server 2019, che ora integra la possibilità di memorizzare una password di amministratore locale casuale in modo nativo, senza dover ricorrere al toolkit di amministratore locale separato (ora chiamato legacy). Potete anche utilizzare Windows LAPS per gestire ed eseguire il backup automatico della password dell’account DSRM (directory services restore mode) sui controller di dominio di Windows Server Active Directory.

Se state ancora utilizzando un controller di dominio Windows 2016, Server 2016 non supporta la nuova soluzione Windows LAPS e quindi non potete criptare la password di Windows LAPS. Come fa notare Microsoft, se il modello di foresta di domini è 2016 o inferiore, è supportata l’archiviazione delle password in chiaro ma non l’archiviazione delle password crittografate per i client uniti al dominio e la gestione degli account DSRM per i controller di dominio. Dovete implementare i controller di dominio Windows Server 2019 o successivi per ottenere tutti i vantaggi della crittografia integrata delle password Windows LAPS utilizzando la nuova metodologia integrata negli aggiornamenti cumulativi di aprile. Il vostro punto debole potrebbe essere quel controller di dominio legacy che vi siete lasciati alle spalle e che non avete ancora aggiornato.