Red Hot Cyber
La cybersecurity è condivisione.
Riconosci il rischio, combattilo, condividi le tue esperienze ed
incentiva gli altri a fare meglio di te.
Menu
La cybersecurity è condivisione.
Riconosci il rischio, combattilo, condividi le tue esperienze ed
incentiva gli altri a fare meglio di te.
Alessandro Molinari : 28 Agosto 2023 07:43
Terza ed ultima parte della creazione del nostro laboratorio di pentesting su Active Directory nel Cloud di Azure .
Creeremo gli utenti del dominio , le loro rispettive macchine , li aggiungeremo al dominio Zeus e creeremo infine la macchina Kali per poi procedere finalmente con gli attacchi e finalmente divertirci un po con il nostro lab.
Procediamo!
Supporta Red Hot Cyber attraverso
Creiamo ora alcuni utenti del dominio. Avviate Server Manager e fate clic sull’opzione di menu Utenti e computer di Active Directory, come mostrato di seguito.
In questo modo si avvia l’applicazione Utenti e computer di Active Directory, come mostrato di seguito. Andiamo sul nostro dominio OLYMPUS.local.
Facciamo clic sul nodo Users e ripuliamo un po’ le voci per facilitare la gestione.
Fare clic con il tasto destro del mouse sul nodo OLYMPUS.local e selezionare l’opzione di menu per la creazione di una nuova Organization Unit (OU), come mostrato di seguito.
chiamiamo la nostra OU “Gruppi”
Con l’eccezione degli utenti Guest e Ammini, spostiamo tutti gli altri utenti nella nuova OU Gruppi mediante drag and drop.
Il nodo Utenti dovrebbe quindi apparire come segue.
creiamo quindi un nuovo utente:
Ho utilizzato una password debole, Password1. Deselezionate la voce L’utente deve cambiare la password al prossimo accesso e selezionate l’opzione Password alla prossima scadenza. Fare clic su “next”.
Ripetiamo il processo per il secondo utente, io lo ho chiamato Salvatore Esposito con la stessa password “Password1“, questo utente più tardi sarà reso amministratore locale di entrambe le macchine per permetterci di dimostrare un attacco SMB RELAY.
Infine, faremo qualcosa di sbagliato ma che spesso in pentest reali viene trovato : creare un utente SQL Service Account di tipo domain-admin, questo non dovrebbe assolutamente avvenire ma accade spesso il contrario. In articoli successivi mostreremo anche come sfruttare questa vulnerabilitá.
A tale scopo, basta copiare l’utente admin esistente Ammini facendo clic con il tasto destro del mouse sul suo nome utente e facendo clic sull’opzione di menu Copia, come mostrato di seguito.
Assegniamo a questo utente il nome SQL, il cognome Service e il nome di accesso SQLService. Fate quindi clic su “next”.
Impostiamo la password per questo utente come MYpassword123# con le impostazioni indicate di seguito. Fare quindi clic su “next”.
Tornare alle proprietà dell’utente SQLService e impostare Descrizione come “la Password è MYpassword123# “ come mostrato di seguito, questo perché può capitare che vi siano nelle descrizioni degli utenti alcune informazioni preziose (come questa), che sono di fatto molo più facili da trovare e che potrebbero darci un grande aiuto nel nostro lavoro di Penetration Tester.
Accade spesso che gli amministratori del dominio inseriscano la password nelle proprietá dell’utente perché credono erroneamente di essere i soli a poter leggere tali proprietá ma come vedremo , non é cosi.
Impostiamo il Service Principal Names (SPN) per l’account SQLService utilizzando l’utility setspn.
Per ora non preoccupiamoci troppo di ciò ma in futuro vedremo anche come attaccare i servizi tramite Kerberoasting, ed é per questo che settiamo SQLService ed il suo SPN.
Un nome principale del servizio (SPN) è il nome con cui un client Kerberos identifica in modo univoco un’istanza di un servizio per un determinato computer di destinazione Kerberos. Se si installano più istanze di un servizio sui computer di una foresta, ogni istanza deve avere il proprio SPN. Un’istanza di servizio può avere più SPN se ci sono più nomi che i client possono usare per l’autenticazione. Ad esempio, un SPN include sempre il nome del computer host su cui è in esecuzione l’istanza del servizio, quindi un’istanza del servizio potrebbe registrare un SPN per ogni nome o alias del suo host.
Trovate ulteriori Informazioni relative qua:
e qua
Setspn: https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/cc731241(v%3Dws.11) .
Possiamo eseguire di nuovo setspn per confermare il dominio per l’SPN esistente, come mostrato sotto
In questo modo si completa la creazione degli utenti del dominio e la configurazione richiesta.
Al momento, nessun computer si è unito al dominio:
È importante annotare l’indirizzo IP del computer di dominio, poiché verrà utilizzato quando si uniranno i computer degli utenti al dominio.
Inserire tutte le informazioni sulla macchina virtuale. Ecco i punti chiave.
qui la policy MIcrosoft ci lascta utilizzare Windows per scopi di testing e studio:
Assicurarsi che anche questa macchina virtuale utilizzi la rete virtuale ADLab. Per il resto delle opzioni, utilizzare le impostazioni predefinite e fare clic sul pulsante Rivedi + crea.
Poco dopo viene visualizzato il messaggio che indica il completamento dell’installazione. È sufficiente fare clic sul pulsante Vai alla risorsa per visualizzare la nuova macchina virtuale creata.
Effettuare il desktop remoto in questa casella utilizzando l’account utente locale appena configurato prossi (password myPassword01).
Avviare Esplora file e fare clic sul nodo Rete. Verrà visualizzato un messaggio che indica che Network Discovery è disattivato. Fare clic su YES.
Perché? In questa seria di articoli vogliamo dimostrare i concetti fondamentali della sicurezza e dei possibili attacchi ad Active Directory. Inoltre l’evasione degli antivirus é una materia molto dinamica e le tecniche vengono modificate continuamente, se le includessimo qui, diventerebbe obsolete in un paio di mesi. Gli attacchi che tratteremo saranno le solide basi di conoscenza che ci serviranno sempre. Seguite come nelle schermate di seguito e create la policy di gruppo per disattivare Windows Defender:
é importante fare in modo che la policy sia enforced.
un ultima cosa, controllare che sulle macchine sia attiva la Network Discovery ed il file sharing.
questo il risultato finale sulla nuova macchina che ancora non sará parte del dominio.
Ripetiamo l’intero processo per la seconda macchina utente, la nuova macchina l’ho chiamata EROS , nome utente sesposito e password myPassword02. Ripetere tutti i passaggi, compresi quelli per attivare il Network discovery e impostare l’utilità BgInfo. La macchina dovrebbe avere il seguente aspetto. Alcune informazioni potrebbero essere diverse (ad esempio l’indirizzo IP, a seconda delle impostazioni utilizzate, ecc.)
I passi seguenti dovranno essere eseguiti su entrambe le macchine utenti, finalmente popoliamo il nostro Dominio.
Per prima cosa dobbiamo recuperare l IP del Domain Controller ZEUS ed impostarlo come DNS della macchina:
Trovate ora Access work or school:
ci logghiamo con l’account di amministrazione:
Dobbiamo ora fare in modo che gli utenti si possano loggare da remoto, digitiamo RUN nella barra delle applicazioni:
digitiamo secopol.msc
e cerchiamo le seguenti voci ed opzioni:
digitiamo prossi , click su check name ed il campo si popolerá automaticamente.
e , di nuovo run e lanciamo services.msc
ed assicuriamoci che “log on as” sia settato su “Network Service”
infine facciamo la stessa cosa per per l’altro utente sesposito sull’altra macchina APOLLO.
Abbiamo creato gli utenti del dominio, ma non li abbiamo ancora configurati rispetto alle macchine utente. Per fare ciò, accediamo prima a eros come amministratore di dominio.
dopo aver fatto click su check names, il campo si popolerá automaticamentE
PASSAGGIO IMPORTANTE
Facciamo la stessa cosa sull’altra macchina per l’utente “prossi” ma su quest’ultima renderemo amministratore anche l’utente sesposito
In pratica abbiamo reso entrambi gli utenti amministratori locali delle rispettive macchine ed l’utente sesposito amministratore su entrambe, questo ci servirá in futuro per dimostrare determinati attacchi come SMB RELAY.
Le macchine e gli utenti sono correttametne configurati:
ed ecco completato il setup di Windows ed Active Directory, passiamo ora alla macchina Kali:
L’ormai conosciuta interfaccia ci permette di installare Kali con le seguenti impostazioni.
ed alla fine , avremo completato la creazione del nostro laboratorio ( la piattaforma ha richiesto di passare ad un piano a pagamento per poter avere un quarto IP statico per la macchina Kali, potete farlo e se non volete pagare niente , cancellare l’account prima che scada il mese di prova):
tramite SSH ci possiamo connettere utilizzando il certificato scaricato durante la creazione della VM.
Controlliamo la presenza delle macchine sulla nostra rete interna:
nmap sul Domain Controller Zeus:
nmap sulle altre due macchine :
Da qui in avanti , nei prossimi articoli prenderemo in esame gli attacchi menzionati all’inizio.
Alessandro Molinari
Redazione: [email protected]
© Copyright RED HOT CYBER. PIVA 16821691009
