mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/windows-hardening/active-directory-methodology/README.m
This commit is contained in:
Translator
parent
cf52cb4f10
commit
0cca2b3e56
@ -241,6 +241,7 @@
|
||||
- [Windows C Payloads](windows-hardening/windows-local-privilege-escalation/windows-c-payloads.md)
|
||||
- [Active Directory Methodology](windows-hardening/active-directory-methodology/README.md)
|
||||
- [Abusing Active Directory ACLs/ACEs](windows-hardening/active-directory-methodology/acl-persistence-abuse/README.md)
|
||||
- [BadSuccessor](windows-hardening/active-directory-methodology/acl-persistence-abuse/BadSuccessor.md)
|
||||
- [Shadow Credentials](windows-hardening/active-directory-methodology/acl-persistence-abuse/shadow-credentials.md)
|
||||
- [AD Certificates](windows-hardening/active-directory-methodology/ad-certificates/README.md)
|
||||
- [AD CS Account Persistence](windows-hardening/active-directory-methodology/ad-certificates/account-persistence.md)
|
||||
|
||||
@ -12,20 +12,20 @@ I concetti chiave all'interno di **Active Directory** includono:
|
||||
|
||||
1. **Directory** – Contiene tutte le informazioni relative agli oggetti di Active Directory.
|
||||
2. **Oggetto** – Denota entità all'interno della directory, inclusi **utenti**, **gruppi** o **cartelle condivise**.
|
||||
3. **Dominio** – Funziona come contenitore per gli oggetti della directory, con la capacità di più domini di coesistere all'interno di una **foresta**, ciascuno mantenendo la propria raccolta di oggetti.
|
||||
3. **Dominio** – Funziona come contenitore per gli oggetti della directory, con la possibilità che più domini coesistano all'interno di una **foresta**, ciascuno mantenendo la propria raccolta di oggetti.
|
||||
4. **Albero** – Un raggruppamento di domini che condividono un dominio radice comune.
|
||||
5. **Foresta** – Il culmine della struttura organizzativa in Active Directory, composta da diversi alberi con **relazioni di fiducia** tra di loro.
|
||||
|
||||
**Active Directory Domain Services (AD DS)** comprende una serie di servizi critici per la gestione centralizzata e la comunicazione all'interno di una rete. Questi servizi comprendono:
|
||||
|
||||
1. **Domain Services** – Centralizza l'archiviazione dei dati e gestisce le interazioni tra **utenti** e **domini**, inclusi i funzionalità di **autenticazione** e **ricerca**.
|
||||
2. **Certificate Services** – Supervisiona la creazione, distribuzione e gestione di **certificati digitali** sicuri.
|
||||
3. **Lightweight Directory Services** – Supporta applicazioni abilitate per directory tramite il **protocollo LDAP**.
|
||||
4. **Directory Federation Services** – Fornisce capacità di **single-sign-on** per autenticare gli utenti attraverso più applicazioni web in una singola sessione.
|
||||
5. **Rights Management** – Aiuta a proteggere il materiale protetto da copyright regolando la sua distribuzione e uso non autorizzati.
|
||||
6. **DNS Service** – Cruciale per la risoluzione dei **nomi di dominio**.
|
||||
1. **Servizi di Dominio** – Centralizza l'archiviazione dei dati e gestisce le interazioni tra **utenti** e **domini**, inclusi **funzionalità di autenticazione** e **ricerca**.
|
||||
2. **Servizi di Certificato** – Supervisiona la creazione, distribuzione e gestione di **certificati digitali** sicuri.
|
||||
3. **Servizi di Directory Leggeri** – Supporta applicazioni abilitate per directory tramite il **protocollo LDAP**.
|
||||
4. **Servizi di Federazione della Directory** – Fornisce capacità di **single-sign-on** per autenticare gli utenti attraverso più applicazioni web in una singola sessione.
|
||||
5. **Gestione dei Diritti** – Aiuta a proteggere il materiale protetto da copyright regolando la sua distribuzione e uso non autorizzati.
|
||||
6. **Servizio DNS** – Cruciale per la risoluzione dei **nomi di dominio**.
|
||||
|
||||
Per una spiegazione più dettagliata controlla: [**TechTerms - Definizione di Active Directory**](https://techterms.com/definition/active_directory)
|
||||
Per una spiegazione più dettagliata, controlla: [**TechTerms - Definizione di Active Directory**](https://techterms.com/definition/active_directory)
|
||||
|
||||
### **Autenticazione Kerberos**
|
||||
|
||||
@ -44,10 +44,10 @@ Puoi prendere molto da [https://wadcoms.github.io/](https://wadcoms.github.io) p
|
||||
Se hai solo accesso a un ambiente AD ma non hai credenziali/sessioni, potresti:
|
||||
|
||||
- **Pentestare la rete:**
|
||||
- Scansiona la rete, trova macchine e porte aperte e prova a **sfruttare vulnerabilità** o **estrarre credenziali** da esse (ad esempio, [le stampanti potrebbero essere obiettivi molto interessanti](ad-information-in-printers.md).
|
||||
- Enumerare DNS potrebbe fornire informazioni sui server chiave nel dominio come web, stampanti, condivisioni, vpn, media, ecc.
|
||||
- Scansionare la rete, trovare macchine e porte aperte e provare a **sfruttare vulnerabilità** o **estrarre credenziali** da esse (ad esempio, [le stampanti potrebbero essere obiettivi molto interessanti](ad-information-in-printers.md).
|
||||
- Enumerare il DNS potrebbe fornire informazioni sui server chiave nel dominio come web, stampanti, condivisioni, vpn, media, ecc.
|
||||
- `gobuster dns -d domain.local -t 25 -w /opt/Seclist/Discovery/DNS/subdomain-top2000.txt`
|
||||
- Dai un'occhiata alla [**Pentesting Methodology**](../../generic-methodologies-and-resources/pentesting-methodology.md) generale per trovare ulteriori informazioni su come fare questo.
|
||||
- Dai un'occhiata alla [**Metodologia di Pentesting Generale**](../../generic-methodologies-and-resources/pentesting-methodology.md) per trovare ulteriori informazioni su come fare questo.
|
||||
- **Controlla l'accesso nullo e Guest sui servizi smb** (questo non funzionerà su versioni moderne di Windows):
|
||||
- `enum4linux -a -u "" -p "" <DC IP> && enum4linux -a -u "guest" -p "" <DC IP>`
|
||||
- `smbmap -u "" -p "" -P 445 -H <DC IP> && smbmap -u "guest" -p "" -P 445 -H <DC IP>`
|
||||
@ -67,11 +67,11 @@ Se hai solo accesso a un ambiente AD ma non hai credenziali/sessioni, potresti:
|
||||
{{#endref}}
|
||||
|
||||
- **Avvelenare la rete**
|
||||
- Raccogli credenziali [**impersonando servizi con Responder**](../../generic-methodologies-and-resources/pentesting-network/spoofing-llmnr-nbt-ns-mdns-dns-and-wpad-and-relay-attacks.md)
|
||||
- Accedi all'host [**abusando dell'attacco di relay**](../../generic-methodologies-and-resources/pentesting-network/spoofing-llmnr-nbt-ns-mdns-dns-and-wpad-and-relay-attacks.md#relay-attack)
|
||||
- Raccogli credenziali **esponendo** [**falsi servizi UPnP con evil-S**](../../generic-methodologies-and-resources/pentesting-network/spoofing-ssdp-and-upnp-devices.md)[**SDP**](https://medium.com/@nickvangilder/exploiting-multifunction-printers-during-a-penetration-test-engagement-28d3840d8856)
|
||||
- Raccogliere credenziali [**impersonando servizi con Responder**](../../generic-methodologies-and-resources/pentesting-network/spoofing-llmnr-nbt-ns-mdns-dns-and-wpad-and-relay-attacks.md)
|
||||
- Accedere all'host [**abusando dell'attacco di relay**](../../generic-methodologies-and-resources/pentesting-network/spoofing-llmnr-nbt-ns-mdns-dns-and-wpad-and-relay-attacks.md#relay-attack)
|
||||
- Raccogliere credenziali **esponendo** [**falsi servizi UPnP con evil-S**](../../generic-methodologies-and-resources/pentesting-network/spoofing-ssdp-and-upnp-devices.md)[**SDP**](https://medium.com/@nickvangilder/exploiting-multifunction-printers-during-a-penetration-test-engagement-28d3840d8856)
|
||||
- [**OSINT**](https://book.hacktricks.wiki/en/generic-methodologies-and-resources/external-recon-methodology/index.html):
|
||||
- Estrai nomi utenti/nomi da documenti interni, social media, servizi (principalmente web) all'interno degli ambienti di dominio e anche da quelli pubblicamente disponibili.
|
||||
- Estrarre nomi utenti/nomi da documenti interni, social media, servizi (principalmente web) all'interno degli ambienti di dominio e anche da fonti pubblicamente disponibili.
|
||||
- Se trovi i nomi completi dei lavoratori dell'azienda, potresti provare diverse **convenzioni di nome utente AD** (**[leggi questo](https://activedirectorypro.com/active-directory-user-naming-convention/)**). Le convenzioni più comuni sono: _NomeCognome_, _Nome.Cognome_, _NamSur_ (3 lettere di ciascuno), _Nam.Sur_, _NSurname_, _N.Surname_, _SurnameName_, _Surname.Name_, _SurnameN_, _Surname.N_, 3 _lettere casuali e 3 numeri casuali_ (abc123).
|
||||
- Strumenti:
|
||||
- [w0Tx/generate-ad-username](https://github.com/w0Tx/generate-ad-username)
|
||||
@ -118,7 +118,7 @@ Ok, quindi sai di avere già un nome utente valido ma nessuna password... Prova:
|
||||
|
||||
- [**ASREPRoast**](asreproast.md): Se un utente **non ha** l'attributo _DONT_REQ_PREAUTH_, puoi **richiedere un messaggio AS_REP** per quell'utente che conterrà alcuni dati crittografati da una derivazione della password dell'utente.
|
||||
- [**Password Spraying**](password-spraying.md): Proviamo le password più **comuni** con ciascuno degli utenti scoperti, forse qualche utente sta usando una password debole (tieni presente la politica delle password!).
|
||||
- Nota che puoi anche **sprayare i server OWA** per cercare di accedere ai server di posta degli utenti.
|
||||
- Nota che puoi anche **spray i server OWA** per cercare di accedere ai server di posta degli utenti.
|
||||
|
||||
{{#ref}}
|
||||
password-spraying.md
|
||||
@ -126,7 +126,7 @@ password-spraying.md
|
||||
|
||||
### Avvelenamento LLMNR/NBT-NS
|
||||
|
||||
Potresti essere in grado di **ottenere** alcuni **hash di sfida** per decifrare **avvelenando** alcuni protocolli della **rete**:
|
||||
Potresti essere in grado di **ottenere** alcune **hash** di sfida per decifrare **avvelenando** alcuni protocolli della **rete**:
|
||||
|
||||
{{#ref}}
|
||||
../../generic-methodologies-and-resources/pentesting-network/spoofing-llmnr-nbt-ns-mdns-dns-and-wpad-and-relay-attacks.md
|
||||
@ -146,7 +146,7 @@ Se puoi **accedere ad altri PC o condivisioni** con l'**utente null o guest** po
|
||||
|
||||
## Enumerare Active Directory CON credenziali/sessione
|
||||
|
||||
Per questa fase devi avere **compromesso le credenziali o una sessione di un account di dominio valido.** Se hai alcune credenziali valide o una shell come utente di dominio, **dovresti ricordare che le opzioni fornite prima sono ancora opzioni per compromettere altri utenti**.
|
||||
Per questa fase devi aver **compromesso le credenziali o una sessione di un account di dominio valido.** Se hai delle credenziali valide o una shell come utente di dominio, **dovresti ricordare che le opzioni fornite prima sono ancora opzioni per compromettere altri utenti**.
|
||||
|
||||
Prima di iniziare l'enumerazione autenticata dovresti sapere qual è il **problema del doppio salto Kerberos.**
|
||||
|
||||
@ -158,7 +158,7 @@ kerberos-double-hop-problem.md
|
||||
|
||||
Aver compromesso un account è un **grande passo per iniziare a compromettere l'intero dominio**, perché sarai in grado di avviare l'**Enumerazione di Active Directory:**
|
||||
|
||||
Per quanto riguarda [**ASREPRoast**](asreproast.md) ora puoi trovare ogni possibile utente vulnerabile, e per quanto riguarda [**Password Spraying**](password-spraying.md) puoi ottenere un **elenco di tutti i nomi utente** e provare la password dell'account compromesso, password vuote e nuove password promettenti.
|
||||
Riguardo a [**ASREPRoast**](asreproast.md) ora puoi trovare ogni possibile utente vulnerabile, e riguardo a [**Password Spraying**](password-spraying.md) puoi ottenere un **elenco di tutti i nomi utente** e provare la password dell'account compromesso, password vuote e nuove password promettenti.
|
||||
|
||||
- Potresti usare il [**CMD per eseguire una ricognizione di base**](../basic-cmd-for-pentesters.md#domain-info)
|
||||
- Puoi anche usare [**powershell per la ricognizione**](../basic-powershell-for-pentesters/index.html) che sarà più furtivo
|
||||
@ -180,7 +180,7 @@ Per quanto riguarda [**ASREPRoast**](asreproast.md) ora puoi trovare ogni possib
|
||||
|
||||
### Kerberoast
|
||||
|
||||
Kerberoasting implica ottenere **ticket TGS** utilizzati dai servizi legati agli account utente e decifrare la loro crittografia—che si basa sulle password degli utenti—**offline**.
|
||||
Kerberoasting implica ottenere **ticket TGS** utilizzati da servizi legati a account utente e decifrare la loro crittografia—che si basa sulle password degli utenti—**offline**.
|
||||
|
||||
Maggiori informazioni su questo in:
|
||||
|
||||
@ -188,7 +188,7 @@ Maggiori informazioni su questo in:
|
||||
kerberoast.md
|
||||
{{#endref}}
|
||||
|
||||
### Connessione remota (RDP, SSH, FTP, Win-RM, ecc.)
|
||||
### Connessione remota (RDP, SSH, FTP, Win-RM, ecc)
|
||||
|
||||
Una volta ottenute alcune credenziali, potresti controllare se hai accesso a qualche **macchina**. A tal fine, potresti usare **CrackMapExec** per tentare di connetterti a diversi server con diversi protocolli, in base alle tue scansioni delle porte.
|
||||
|
||||
@ -210,7 +210,7 @@ C'è una pagina completa in questo libro su [**escalation dei privilegi locali i
|
||||
```
|
||||
### NTLM Relay
|
||||
|
||||
Se sei riuscito a enumerare l'active directory avrai **più email e una migliore comprensione della rete**. Potresti essere in grado di forzare gli attacchi [**NTLM relay**](../../generic-methodologies-and-resources/pentesting-network/spoofing-llmnr-nbt-ns-mdns-dns-and-wpad-and-relay-attacks.md#relay-attack)**.**
|
||||
Se sei riuscito a enumerare l'active directory avrai **più email e una migliore comprensione della rete**. Potresti essere in grado di forzare gli attacchi di NTLM [**relay attacks**](../../generic-methodologies-and-resources/pentesting-network/spoofing-llmnr-nbt-ns-mdns-dns-and-wpad-and-relay-attacks.md#relay-attack)**.**
|
||||
|
||||
### Cerca Credenziali nelle Condivisioni di Computer | Condivisioni SMB
|
||||
|
||||
@ -240,7 +240,7 @@ printnightmare.md
|
||||
|
||||
### Estrazione degli hash
|
||||
|
||||
Speriamo che tu sia riuscito a **compromettere qualche account admin locale** utilizzando [AsRepRoast](asreproast.md), [Password Spraying](password-spraying.md), [Kerberoast](kerberoast.md), [Responder](../../generic-methodologies-and-resources/pentesting-network/spoofing-llmnr-nbt-ns-mdns-dns-and-wpad-and-relay-attacks.md) inclusi i relay, [EvilSSDP](../../generic-methodologies-and-resources/pentesting-network/spoofing-ssdp-and-upnp-devices.md), [escalare privilegi localmente](../windows-local-privilege-escalation/index.html).\
|
||||
Speriamo che tu sia riuscito a **compromettere qualche account admin locale** utilizzando [AsRepRoast](asreproast.md), [Password Spraying](password-spraying.md), [Kerberoast](kerberoast.md), [Responder](../../generic-methodologies-and-resources/pentesting-network/spoofing-llmnr-nbt-ns-mdns-dns-and-wpad-and-relay-attacks.md) inclusi i relay, [EvilSSDP](../../generic-methodologies-and-resources/pentesting-network/spoofing-ssdp-and-upnp-devices.md), [escalating privileges locally](../windows-local-privilege-escalation/index.html).\
|
||||
Poi, è tempo di estrarre tutti gli hash in memoria e localmente.\
|
||||
[**Leggi questa pagina sui diversi modi per ottenere gli hash.**](https://github.com/carlospolop/hacktricks/blob/master/windows-hardening/active-directory-methodology/broken-reference/README.md)
|
||||
|
||||
@ -291,7 +291,7 @@ abusing-ad-mssql.md
|
||||
|
||||
Se trovi un oggetto Computer con l'attributo [ADS_UF_TRUSTED_FOR_DELEGATION](<https://msdn.microsoft.com/en-us/library/aa772300(v=vs.85).aspx>) e hai privilegi di dominio nel computer, sarai in grado di estrarre i TGT dalla memoria di ogni utente che accede al computer.\
|
||||
Quindi, se un **Domain Admin accede al computer**, sarai in grado di estrarre il suo TGT e impersonarlo usando [Pass the Ticket](pass-the-ticket.md).\
|
||||
Grazie alla delegazione vincolata potresti anche **compromettere automaticamente un Print Server** (si spera che sia un DC).
|
||||
Grazie alla delegazione vincolata potresti anche **compromettere automaticamente un Print Server** (speriamo che sia un DC).
|
||||
|
||||
{{#ref}}
|
||||
unconstrained-delegation.md
|
||||
@ -314,7 +314,7 @@ Avere il privilegio di **SCRITTURA** su un oggetto Active Directory di un comput
|
||||
resource-based-constrained-delegation.md
|
||||
{{#endref}}
|
||||
|
||||
### Abuso delle ACL
|
||||
### Abuso di Permessi/ACL
|
||||
|
||||
L'utente compromesso potrebbe avere alcuni **privilegi interessanti su alcuni oggetti di dominio** che potrebbero consentirti di **muoverti** lateralmente/**escalare** privilegi.
|
||||
|
||||
@ -330,10 +330,10 @@ Scoprire un **servizio Spool in ascolto** all'interno del dominio può essere **
|
||||
printers-spooler-service-abuse.md
|
||||
{{#endref}}
|
||||
|
||||
### Abuso delle sessioni di terze parti
|
||||
### Abuso di sessioni di terze parti
|
||||
|
||||
Se **altri utenti** **accedono** alla macchina **compromessa**, è possibile **raccogliere credenziali dalla memoria** e persino **iniettare beacon nei loro processi** per impersonarli.\
|
||||
Di solito gli utenti accedono al sistema tramite RDP, quindi ecco come eseguire un paio di attacchi sulle sessioni RDP di terze parti:
|
||||
Di solito gli utenti accedono al sistema tramite RDP, quindi ecco come eseguire un paio di attacchi su sessioni RDP di terze parti:
|
||||
|
||||
{{#ref}}
|
||||
rdp-sessions-abuse.md
|
||||
@ -355,7 +355,7 @@ laps.md
|
||||
ad-certificates/certificate-theft.md
|
||||
{{#endref}}
|
||||
|
||||
### Abuso dei Modelli di Certificato
|
||||
### Abuso di Modelli di Certificati
|
||||
|
||||
Se sono configurati **modelli vulnerabili**, è possibile abusarne per escalare privilegi:
|
||||
|
||||
@ -367,7 +367,7 @@ ad-certificates/domain-escalation.md
|
||||
|
||||
### Dumping delle Credenziali di Dominio
|
||||
|
||||
Una volta ottenuti i privilegi di **Domain Admin** o anche meglio di **Enterprise Admin**, puoi **dumpare** il **database di dominio**: _ntds.dit_.
|
||||
Una volta ottenuti i privilegi di **Domain Admin** o ancora meglio di **Enterprise Admin**, puoi **dumpare** il **database di dominio**: _ntds.dit_.
|
||||
|
||||
[**Maggiori informazioni sull'attacco DCSync possono essere trovate qui**](dcsync.md).
|
||||
|
||||
@ -398,7 +398,7 @@ Add-DomainObjectAcl -TargetIdentity "DC=SUB,DC=DOMAIN,DC=LOCAL" -PrincipalIdenti
|
||||
|
||||
### Silver Ticket
|
||||
|
||||
L'**attacco Silver Ticket** crea un **ticket di servizio Ticket Granting Service (TGS)** legittimo per un servizio specifico utilizzando l'**hash NTLM** (ad esempio, l'**hash dell'account PC**). Questo metodo viene impiegato per **accedere ai privilegi del servizio**.
|
||||
L'**attacco Silver Ticket** crea un **ticket di Ticket Granting Service (TGS)** legittimo per un servizio specifico utilizzando l'**hash NTLM** (ad esempio, l'**hash dell'account PC**). Questo metodo viene impiegato per **accedere ai privilegi del servizio**.
|
||||
|
||||
{{#ref}}
|
||||
silver-ticket.md
|
||||
@ -422,7 +422,7 @@ Questi sono simili ai golden ticket forgiati in un modo che **bypassa i comuni m
|
||||
diamond-ticket.md
|
||||
{{#endref}}
|
||||
|
||||
### **Persistenza degli Account Certificati**
|
||||
### **Persistenza dell'Account Certificati**
|
||||
|
||||
**Avere certificati di un account o essere in grado di richiederli** è un ottimo modo per poter persistere nell'account degli utenti (anche se cambia la password):
|
||||
|
||||
@ -430,7 +430,7 @@ diamond-ticket.md
|
||||
ad-certificates/account-persistence.md
|
||||
{{#endref}}
|
||||
|
||||
### **Persistenza dei Certificati nel Dominio**
|
||||
### **Persistenza del Dominio Certificati**
|
||||
|
||||
**Utilizzare certificati è anche possibile per persistere con privilegi elevati all'interno del dominio:**
|
||||
|
||||
@ -440,21 +440,21 @@ ad-certificates/domain-persistence.md
|
||||
|
||||
### Gruppo AdminSDHolder
|
||||
|
||||
L'oggetto **AdminSDHolder** in Active Directory garantisce la sicurezza dei **gruppi privilegiati** (come Domain Admins e Enterprise Admins) applicando una standard **Access Control List (ACL)** a questi gruppi per prevenire modifiche non autorizzate. Tuttavia, questa funzionalità può essere sfruttata; se un attaccante modifica l'ACL di AdminSDHolder per dare accesso completo a un utente normale, quell'utente ottiene un controllo esteso su tutti i gruppi privilegiati. Questa misura di sicurezza, destinata a proteggere, può quindi ritorcersi contro, consentendo accessi non autorizzati a meno che non venga monitorata da vicino.
|
||||
L'oggetto **AdminSDHolder** in Active Directory garantisce la sicurezza dei **gruppi privilegiati** (come Domain Admins e Enterprise Admins) applicando una standard **Access Control List (ACL)** su questi gruppi per prevenire modifiche non autorizzate. Tuttavia, questa funzionalità può essere sfruttata; se un attaccante modifica l'ACL di AdminSDHolder per dare accesso completo a un utente normale, quell'utente ottiene un controllo esteso su tutti i gruppi privilegiati. Questa misura di sicurezza, destinata a proteggere, può quindi ritorcersi contro, consentendo accessi non autorizzati a meno che non venga monitorata da vicino.
|
||||
|
||||
[**Maggiori informazioni sul Gruppo AdminDSHolder qui.**](privileged-groups-and-token-privileges.md#adminsdholder-group)
|
||||
|
||||
### Credenziali DSRM
|
||||
|
||||
All'interno di ogni **Domain Controller (DC)**, esiste un account **amministratore locale**. Ottenendo diritti di amministratore su una tale macchina, l'hash dell'Amministratore locale può essere estratto utilizzando **mimikatz**. Successivamente, è necessaria una modifica del registro per **abilitare l'uso di questa password**, consentendo l'accesso remoto all'account dell'Amministratore locale.
|
||||
All'interno di ogni **Domain Controller (DC)**, esiste un account di **amministratore locale**. Ottenendo diritti di amministratore su una tale macchina, l'hash dell'Amministratore locale può essere estratto utilizzando **mimikatz**. Successivamente, è necessaria una modifica del registro per **abilitare l'uso di questa password**, consentendo l'accesso remoto all'account dell'Amministratore locale.
|
||||
|
||||
{{#ref}}
|
||||
dsrm-credentials.md
|
||||
{{#endref}}
|
||||
|
||||
### Persistenza delle ACL
|
||||
### Persistenza ACL
|
||||
|
||||
Potresti **dare** alcuni **privilegi speciali** a un **utente** su alcuni oggetti di dominio specifici che consentiranno all'utente di **escalare privilegi in futuro**.
|
||||
Potresti **dare** alcuni **permessi speciali** a un **utente** su alcuni oggetti di dominio specifici che consentiranno all'utente di **escalare privilegi in futuro**.
|
||||
|
||||
{{#ref}}
|
||||
acl-persistence-abuse/
|
||||
@ -462,7 +462,7 @@ acl-persistence-abuse/
|
||||
|
||||
### Descrittori di Sicurezza
|
||||
|
||||
I **descrittori di sicurezza** vengono utilizzati per **memorizzare** i **privilegi** che un **oggetto** ha **su** un **oggetto**. Se puoi semplicemente **fare** un **piccolo cambiamento** nel **descrittore di sicurezza** di un oggetto, puoi ottenere privilegi molto interessanti su quell'oggetto senza dover essere membro di un gruppo privilegiato.
|
||||
I **descrittori di sicurezza** vengono utilizzati per **memorizzare** i **permessi** che un **oggetto** ha **su** un **oggetto**. Se puoi solo **fare** un **piccolo cambiamento** nel **descrittore di sicurezza** di un oggetto, puoi ottenere privilegi molto interessanti su quell'oggetto senza dover essere membro di un gruppo privilegiato.
|
||||
|
||||
{{#ref}}
|
||||
security-descriptors.md
|
||||
@ -479,7 +479,7 @@ skeleton-key.md
|
||||
### SSP Personalizzato
|
||||
|
||||
[Scopri cos'è un SSP (Security Support Provider) qui.](../authentication-credentials-uac-and-efs/index.html#security-support-provider-interface-sspi)\
|
||||
Puoi creare il tuo **SSP** per **catturare** in **testo chiaro** le **credenziali** utilizzate per accedere alla macchina.
|
||||
Puoi creare il tuo **SSP** per **catturare** in **chiaro** le **credenziali** utilizzate per accedere alla macchina.
|
||||
|
||||
{{#ref}}
|
||||
custom-ssp.md
|
||||
@ -487,7 +487,7 @@ custom-ssp.md
|
||||
|
||||
### DCShadow
|
||||
|
||||
Registra un **nuovo Domain Controller** nell'AD e lo utilizza per **inviare attributi** (SIDHistory, SPNs...) su oggetti specificati **senza** lasciare alcun **log** riguardo alle **modifiche**. Hai **bisogno di privilegi DA** e di essere all'interno del **dominio radice**.\
|
||||
Registra un **nuovo Domain Controller** nell'AD e lo utilizza per **spingere attributi** (SIDHistory, SPNs...) su oggetti specificati **senza** lasciare alcun **log** riguardo alle **modifiche**. Hai **bisogno di privilegi DA** e di essere all'interno del **dominio radice**.\
|
||||
Nota che se usi dati errati, appariranno log piuttosto brutti.
|
||||
|
||||
{{#ref}}
|
||||
@ -509,14 +509,14 @@ Microsoft considera la **Foresta** come il confine di sicurezza. Ciò implica ch
|
||||
|
||||
### Informazioni di Base
|
||||
|
||||
Una [**fiducia di dominio**](<http://technet.microsoft.com/en-us/library/cc759554(v=ws.10).aspx>) è un meccanismo di sicurezza che consente a un utente di un **dominio** di accedere alle risorse in un altro **dominio**. Crea essenzialmente un collegamento tra i sistemi di autenticazione dei due domini, consentendo che le verifiche di autenticazione fluiscano senza problemi. Quando i domini stabiliscono una fiducia, scambiano e mantengono specifici **chiavi** all'interno dei loro **Domain Controllers (DC)**, che sono cruciali per l'integrità della fiducia.
|
||||
Una [**fiducia di dominio**](<http://technet.microsoft.com/en-us/library/cc759554(v=ws.10).aspx>) è un meccanismo di sicurezza che consente a un utente di un **dominio** di accedere a risorse in un altro **dominio**. Crea essenzialmente un collegamento tra i sistemi di autenticazione dei due domini, consentendo che le verifiche di autenticazione fluiscano senza problemi. Quando i domini stabiliscono una fiducia, scambiano e mantengono specifici **chiavi** all'interno dei loro **Domain Controllers (DC)**, che sono cruciali per l'integrità della fiducia.
|
||||
|
||||
In uno scenario tipico, se un utente intende accedere a un servizio in un **dominio fidato**, deve prima richiedere un ticket speciale noto come **inter-realm TGT** dal DC del proprio dominio. Questo TGT è crittografato con una **chiave** condivisa su cui entrambi i domini hanno concordato. L'utente presenta quindi questo TGT al **DC del dominio fidato** per ottenere un ticket di servizio (**TGS**). Dopo la validazione con successo dell'inter-realm TGT da parte del DC del dominio fidato, emette un TGS, concedendo all'utente accesso al servizio.
|
||||
|
||||
**Passaggi**:
|
||||
|
||||
1. Un **computer client** nel **Dominio 1** avvia il processo utilizzando il proprio **hash NTLM** per richiedere un **Ticket Granting Ticket (TGT)** dal proprio **Domain Controller (DC1)**.
|
||||
2. DC1 emette un nuovo TGT se il client viene autenticato con successo.
|
||||
2. DC1 emette un nuovo TGT se il client è autenticato con successo.
|
||||
3. Il client richiede quindi un **inter-realm TGT** da DC1, necessario per accedere alle risorse nel **Dominio 2**.
|
||||
4. L'inter-realm TGT è crittografato con una **chiave di fiducia** condivisa tra DC1 e DC2 come parte della fiducia tra domini bidirezionale.
|
||||
5. Il client porta l'inter-realm TGT al **Domain Controller (DC2)** del Dominio 2.
|
||||
@ -525,22 +525,22 @@ In uno scenario tipico, se un utente intende accedere a un servizio in un **domi
|
||||
|
||||
### Diverse fiducia
|
||||
|
||||
È importante notare che **una fiducia può essere unidirezionale o bidirezionale**. Nelle opzioni bidirezionali, entrambi i domini si fideranno l'uno dell'altro, ma nella relazione di fiducia **unidirezionale** uno dei domini sarà il **fidato** e l'altro il **fiducioso**. Nel secondo caso, **sarai in grado di accedere solo alle risorse all'interno del dominio fiducioso dal dominio fidato**.
|
||||
È importante notare che **una fiducia può essere unidirezionale o bidirezionale**. Nelle opzioni bidirezionali, entrambi i domini si fideranno l'uno dell'altro, ma nella relazione di fiducia **unidirezionale** uno dei domini sarà il **fidato** e l'altro il **fiducioso**. Nel secondo caso, **sarai in grado di accedere solo alle risorse all'interno del dominio fiducioso dal fidato**.
|
||||
|
||||
Se il Dominio A si fida del Dominio B, A è il dominio fiducioso e B è quello fidato. Inoltre, in **Dominio A**, questo sarebbe una **fiducia in uscita**; e in **Dominio B**, questo sarebbe una **fiducia in entrata**.
|
||||
Se il Dominio A fida il Dominio B, A è il dominio fiducioso e B è quello fidato. Inoltre, in **Dominio A**, questo sarebbe una **fiducia in uscita**; e in **Dominio B**, questo sarebbe una **fiducia in entrata**.
|
||||
|
||||
**Diverse relazioni di fiducia**
|
||||
|
||||
- **Fiducia Genitore-Figlio**: Questa è una configurazione comune all'interno della stessa foresta, dove un dominio figlio ha automaticamente una fiducia bidirezionale transitiva con il suo dominio genitore. Essenzialmente, ciò significa che le richieste di autenticazione possono fluire senza problemi tra il genitore e il figlio.
|
||||
- **Fiducia Cross-link**: Riferita come "fiducia abbreviata", queste vengono stabilite tra domini figli per accelerare i processi di riferimento. In foreste complesse, i riferimenti di autenticazione devono generalmente viaggiare fino alla radice della foresta e poi giù fino al dominio target. Creando collegamenti incrociati, il viaggio viene accorciato, il che è particolarmente vantaggioso in ambienti geograficamente dispersi.
|
||||
- **Fiducia Esterna**: Queste vengono impostate tra domini diversi e non correlati e sono di natura non transitiva. Secondo la [documentazione di Microsoft](<https://technet.microsoft.com/en-us/library/cc773178(v=ws.10).aspx>), le fiducia esterne sono utili per accedere a risorse in un dominio al di fuori della foresta attuale che non è connesso tramite una fiducia tra foreste. La sicurezza è rafforzata attraverso il filtraggio SID con fiducia esterne.
|
||||
- **Fiducia Esterna**: Queste vengono stabilite tra domini diversi e non correlati e sono di natura non transitiva. Secondo [la documentazione di Microsoft](<https://technet.microsoft.com/en-us/library/cc773178(v=ws.10).aspx>), le fiducia esterne sono utili per accedere a risorse in un dominio al di fuori della foresta attuale che non è connesso tramite una fiducia tra foreste. La sicurezza è rafforzata attraverso il filtraggio SID con fiducia esterne.
|
||||
- **Fiducia Tree-root**: Queste fiducia vengono stabilite automaticamente tra il dominio radice della foresta e un nuovo albero radice aggiunto. Anche se non comunemente incontrate, le fiducia tree-root sono importanti per aggiungere nuovi alberi di dominio a una foresta, consentendo loro di mantenere un nome di dominio unico e garantendo una transitività bidirezionale. Maggiori informazioni possono essere trovate nella [guida di Microsoft](<https://technet.microsoft.com/en-us/library/cc773178(v=ws.10).aspx>).
|
||||
- **Fiducia tra Foreste**: Questo tipo di fiducia è una fiducia bidirezionale transitiva tra due domini radice di foresta, imponendo anche il filtraggio SID per migliorare le misure di sicurezza.
|
||||
- **Fiducia MIT**: Queste fiducia vengono stabilite con domini Kerberos non Windows, [conformi a RFC4120](https://tools.ietf.org/html/rfc4120). Le fiducia MIT sono un po' più specializzate e si rivolgono a ambienti che richiedono integrazione con sistemi basati su Kerberos al di fuori dell'ecosistema Windows.
|
||||
|
||||
#### Altre differenze nelle **relazioni di fiducia**
|
||||
|
||||
- Una relazione di fiducia può anche essere **transitiva** (A si fida di B, B si fida di C, quindi A si fida di C) o **non transitiva**.
|
||||
- Una relazione di fiducia può anche essere **transitiva** (A fida B, B fida C, quindi A fida C) o **non transitiva**.
|
||||
- Una relazione di fiducia può essere impostata come **fiducia bidirezionale** (entrambi si fidano l'uno dell'altro) o come **fiducia unidirezionale** (solo uno di loro si fida dell'altro).
|
||||
|
||||
### Percorso di Attacco
|
||||
@ -552,7 +552,7 @@ Se il Dominio A si fida del Dominio B, A è il dominio fiducioso e B è quello f
|
||||
|
||||
Gli attaccanti potrebbero accedere alle risorse in un altro dominio attraverso tre meccanismi principali:
|
||||
|
||||
- **Appartenenza a Gruppi Locali**: I principi potrebbero essere aggiunti a gruppi locali su macchine, come il gruppo "Amministratori" su un server, concedendo loro un controllo significativo su quella macchina.
|
||||
- **Appartenenza a Gruppi Locali**: I principi potrebbero essere aggiunti a gruppi locali su macchine, come il gruppo “Amministratori” su un server, concedendo loro un controllo significativo su quella macchina.
|
||||
- **Appartenenza a Gruppi di Domini Esterni**: I principi possono anche essere membri di gruppi all'interno del dominio esterno. Tuttavia, l'efficacia di questo metodo dipende dalla natura della fiducia e dall'ambito del gruppo.
|
||||
- **Liste di Controllo degli Accessi (ACL)**: I principi potrebbero essere specificati in un **ACL**, in particolare come entità in **ACE** all'interno di un **DACL**, fornendo loro accesso a risorse specifiche. Per coloro che desiderano approfondire la meccanica delle ACL, DACL e ACE, il whitepaper intitolato “[An ACE Up The Sleeve](https://specterops.io/assets/resources/an_ace_up_the_sleeve.pdf)” è una risorsa preziosa.
|
||||
|
||||
@ -612,7 +612,7 @@ sid-history-injection.md
|
||||
|
||||
#### Sfruttare il Configuration NC scrivibile
|
||||
|
||||
Comprendere come il Configuration Naming Context (NC) possa essere sfruttato è cruciale. Il Configuration NC funge da repository centrale per i dati di configurazione in ambienti Active Directory (AD) all'interno di una foresta. Questi dati vengono replicati a ogni Domain Controller (DC) all'interno della foresta, con DC scrivibili che mantengono una copia scrivibile del Configuration NC. Per sfruttare questo, è necessario avere **privilegi SYSTEM su un DC**, preferibilmente un DC child.
|
||||
Comprendere come il Configuration Naming Context (NC) possa essere sfruttato è cruciale. Il Configuration NC funge da repository centrale per i dati di configurazione in ambienti Active Directory (AD) attraverso una foresta. Questi dati vengono replicati a ogni Domain Controller (DC) all'interno della foresta, con i DC scrivibili che mantengono una copia scrivibile del Configuration NC. Per sfruttare questo, è necessario avere **privilegi SYSTEM su un DC**, preferibilmente un DC child.
|
||||
|
||||
**Collegare GPO al sito root DC**
|
||||
|
||||
@ -649,7 +649,7 @@ TrustDirection : Inbound --> Inboud trust
|
||||
WhenCreated : 2/19/2021 10:50:56 PM
|
||||
WhenChanged : 2/19/2021 10:50:56 PM
|
||||
```
|
||||
In questo scenario **il tuo dominio è fidato** da un dominio esterno che ti concede **permessi indeterminati** su di esso. Dovrai scoprire **quali principi del tuo dominio hanno accesso a quale dominio esterno** e poi cercare di sfruttarlo:
|
||||
In questo scenario **il tuo dominio è fidato** da un dominio esterno che ti concede **permessi indeterminati** su di esso. Dovrai scoprire **quali principi del tuo dominio hanno accesso su quale dominio esterno** e poi cercare di sfruttarlo:
|
||||
|
||||
{{#ref}}
|
||||
external-forest-domain-oneway-inbound.md
|
||||
@ -669,7 +669,7 @@ WhenChanged : 2/19/2021 10:15:24 PM
|
||||
```
|
||||
In questo scenario **il tuo dominio** sta **fidando** alcuni **privilegi** a un principale di **domini diversi**.
|
||||
|
||||
Tuttavia, quando un **dominio è fidato** dal dominio fidante, il dominio fidato **crea un utente** con un **nome prevedibile** che utilizza come **password la password fidata**. Ciò significa che è possibile **accedere a un utente dal dominio fidante per entrare in quello fidato** per enumerarlo e cercare di aumentare ulteriormente i privilegi:
|
||||
Tuttavia, quando un **dominio è fidato** dal dominio fidante, il dominio fidato **crea un utente** con un **nome prevedibile** che utilizza come **password la password fidata**. Ciò significa che è possibile **accedere a un utente dal dominio fidante per entrare in quello fidato** per enumerarlo e cercare di ottenere più privilegi:
|
||||
|
||||
{{#ref}}
|
||||
external-forest-domain-one-way-outbound.md
|
||||
@ -677,7 +677,7 @@ external-forest-domain-one-way-outbound.md
|
||||
|
||||
Un altro modo per compromettere il dominio fidato è trovare un [**collegamento SQL fidato**](abusing-ad-mssql.md#mssql-trusted-links) creato nella **direzione opposta** della fiducia del dominio (che non è molto comune).
|
||||
|
||||
Un altro modo per compromettere il dominio fidato è aspettare su una macchina dove un **utente del dominio fidato può accedere** per effettuare il login tramite **RDP**. Poi, l'attaccante potrebbe iniettare codice nel processo della sessione RDP e **accedere al dominio di origine della vittima** da lì.\
|
||||
Un altro modo per compromettere il dominio fidato è aspettare su una macchina a cui un **utente del dominio fidato può accedere** per effettuare il login tramite **RDP**. Poi, l'attaccante potrebbe iniettare codice nel processo della sessione RDP e **accedere al dominio di origine della vittima** da lì.\
|
||||
Inoltre, se la **vittima ha montato il suo hard disk**, dal processo della **sessione RDP** l'attaccante potrebbe memorizzare **backdoor** nella **cartella di avvio dell'hard disk**. Questa tecnica è chiamata **RDPInception.**
|
||||
|
||||
{{#ref}}
|
||||
@ -694,7 +694,7 @@ rdp-sessions-abuse.md
|
||||
### **Autenticazione Selettiva:**
|
||||
|
||||
- Per le fiducie inter-foresta, l'uso dell'Autenticazione Selettiva garantisce che gli utenti delle due foreste non siano autenticati automaticamente. Invece, sono necessarie autorizzazioni esplicite per gli utenti per accedere ai domini e ai server all'interno del dominio o della foresta fidante.
|
||||
- È importante notare che queste misure non proteggono contro lo sfruttamento del Contesto di Nominazione di Configurazione (NC) scrivibile o attacchi all'account di fiducia.
|
||||
- È importante notare che queste misure non proteggono contro lo sfruttamento del Contesto di Nominazione di Configurazione scrivibile (NC) o attacchi all'account di fiducia.
|
||||
|
||||
[**Ulteriori informazioni sulle fiducie di dominio in ired.team.**](https://ired.team/offensive-security-experiments/active-directory-kerberos-abuse/child-domain-da-to-ea-in-parent-domain)
|
||||
|
||||
@ -716,18 +716,18 @@ https://cloud.hacktricks.wiki/en/pentesting-cloud/azure-security/az-lateral-move
|
||||
|
||||
### **Implementazione di Tecniche di Inganno**
|
||||
|
||||
- Implementare l'inganno implica impostare trappole, come utenti o computer esca, con caratteristiche come password che non scadono o sono contrassegnate come Fidate per Delegazione. Un approccio dettagliato include la creazione di utenti con diritti specifici o l'aggiunta a gruppi ad alto privilegio.
|
||||
- L'implementazione dell'inganno comporta la creazione di trappole, come utenti o computer esca, con caratteristiche come password che non scadono o sono contrassegnate come Fidate per Delegazione. Un approccio dettagliato include la creazione di utenti con diritti specifici o l'aggiunta a gruppi ad alto privilegio.
|
||||
- Un esempio pratico prevede l'uso di strumenti come: `Create-DecoyUser -UserFirstName user -UserLastName manager-uncommon -Password Pass@123 | DeployUserDeception -UserFlag PasswordNeverExpires -GUID d07da11f-8a3d-42b6-b0aa-76c962be719a -Verbose`
|
||||
- Maggiori informazioni sull'implementazione di tecniche di inganno possono essere trovate in [Deploy-Deception su GitHub](https://github.com/samratashok/Deploy-Deception).
|
||||
|
||||
### **Identificazione dell'Inganno**
|
||||
|
||||
- **Per Oggetti Utente**: Indicatori sospetti includono ObjectSID atipico, accessi infrequenti, date di creazione e bassi conteggi di password errate.
|
||||
- **Per Oggetti Utente**: Indicatori sospetti includono ObjectSID atipici, accessi infrequenti, date di creazione e bassi conteggi di password errate.
|
||||
- **Indicatori Generali**: Confrontare gli attributi di potenziali oggetti esca con quelli di oggetti genuini può rivelare incongruenze. Strumenti come [HoneypotBuster](https://github.com/JavelinNetworks/HoneypotBuster) possono aiutare a identificare tali inganni.
|
||||
|
||||
### **Evitare i Sistemi di Rilevamento**
|
||||
### **Evasione dei Sistemi di Rilevamento**
|
||||
|
||||
- **Bypass della Rilevazione di Microsoft ATA**:
|
||||
- **Evasione della Rilevazione di Microsoft ATA**:
|
||||
- **Enumerazione degli Utenti**: Evitare l'enumerazione delle sessioni sui Controller di Dominio per prevenire la rilevazione da parte di ATA.
|
||||
- **Impersonificazione del Ticket**: Utilizzare chiavi **aes** per la creazione di ticket aiuta a evitare la rilevazione non degradando a NTLM.
|
||||
- **Attacchi DCSync**: È consigliato eseguire da un non-Controller di Dominio per evitare la rilevazione da parte di ATA, poiché l'esecuzione diretta da un Controller di Dominio attiverà avvisi.
|
||||
|
||||
@ -0,0 +1,68 @@
|
||||
# Abusing Active Directory ACLs/ACEs
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Overview
|
||||
|
||||
I Delegated Managed Service Accounts (**dMSAs**) sono un nuovo tipo di principale AD introdotto con **Windows Server 2025**. Sono progettati per sostituire gli account di servizio legacy consentendo una “migrazione” con un clic che copia automaticamente i Service Principal Names (SPNs), le appartenenze ai gruppi, le impostazioni di delega e persino le chiavi crittografiche dell'account precedente nel nuovo dMSA, offrendo alle applicazioni un passaggio senza soluzione di continuità ed eliminando il rischio di Kerberoasting.
|
||||
|
||||
I ricercatori di Akamai hanno scoperto che un singolo attributo — **`msDS‑ManagedAccountPrecededByLink`** — indica al KDC quale account legacy un dMSA “sostituisce”. Se un attaccante può scrivere quell'attributo (e attivare **`msDS‑DelegatedMSAState` → 2**), il KDC costruirà felicemente un PAC che **eredita ogni SID della vittima scelta**, consentendo effettivamente al dMSA di impersonare qualsiasi utente, inclusi gli Amministratori di Dominio.
|
||||
|
||||
## What exactly is a dMSA?
|
||||
|
||||
* Basato sulla tecnologia **gMSA** ma memorizzato come la nuova classe AD **`msDS‑DelegatedManagedServiceAccount`**.
|
||||
* Supporta una **migrazione su richiesta**: chiamando `Start‑ADServiceAccountMigration` si collega il dMSA all'account legacy, si concede all'account legacy l'accesso in scrittura a `msDS‑GroupMSAMembership` e si attiva `msDS‑DelegatedMSAState` = 1.
|
||||
* Dopo `Complete‑ADServiceAccountMigration`, l'account superato viene disabilitato e il dMSA diventa completamente funzionale; qualsiasi host che precedentemente utilizzava l'account legacy è automaticamente autorizzato a prelevare la password del dMSA.
|
||||
* Durante l'autenticazione, il KDC incorpora un suggerimento **KERB‑SUPERSEDED‑BY‑USER** in modo che i client Windows 11/24H2 riprovino in modo trasparente con il dMSA.
|
||||
|
||||
## Requirements to attack
|
||||
1. **Almeno un Windows Server 2025 DC** affinché la classe LDAP del dMSA e la logica KDC esistano.
|
||||
2. **Qualsiasi diritto di creazione di oggetti o scrittura di attributi su un OU** (qualsiasi OU) – ad esempio, `Create msDS‑DelegatedManagedServiceAccount` o semplicemente **Create All Child Objects**. Akamai ha scoperto che il 91 % dei tenant nel mondo reale concede tali permessi “benigni” sugli OU a non amministratori.
|
||||
3. Capacità di eseguire strumenti (PowerShell/Rubeus) da qualsiasi host unito al dominio per richiedere ticket Kerberos.
|
||||
*Non è richiesto alcun controllo sull'utente vittima; l'attacco non tocca mai direttamente l'account target.*
|
||||
|
||||
## Step‑by‑step: BadSuccessor*privilege escalation
|
||||
|
||||
1. **Trova o crea un dMSA che controlli**
|
||||
```bash
|
||||
New‑ADServiceAccount Attacker_dMSA `
|
||||
‑DNSHostName ad.lab `
|
||||
‑Path "OU=temp,DC=lab,DC=local"
|
||||
```
|
||||
|
||||
Poiché hai creato l'oggetto all'interno di un OU a cui puoi scrivere, possiedi automaticamente tutti i suoi attributi.
|
||||
|
||||
2. **Simula una “migrazione completata” in due scritture LDAP**:
|
||||
- Imposta `msDS‑ManagedAccountPrecededByLink = DN` di qualsiasi vittima (ad esempio `CN=Administrator,CN=Users,DC=lab,DC=local`).
|
||||
- Imposta `msDS‑DelegatedMSAState = 2` (migrazione completata).
|
||||
|
||||
Strumenti come **Set‑ADComputer, ldapmodify**, o anche **ADSI Edit** funzionano; non sono necessari diritti di amministratore di dominio.
|
||||
|
||||
3. **Richiedi un TGT per il dMSA** — Rubeus supporta il flag `/dmsa`:
|
||||
|
||||
```bash
|
||||
Rubeus.exe asktgs /targetuser:attacker_dmsa$ /service:krbtgt/aka.test /dmsa /opsec /nowrap /ptt /ticket:<Machine TGT>
|
||||
```
|
||||
|
||||
Il PAC restituito ora contiene il SID 500 (Amministratore) più i gruppi Amministratori di Dominio/Amministratori di Impresa.
|
||||
|
||||
## Gather all the users passwords
|
||||
|
||||
Durante le migrazioni legittime, il KDC deve consentire al nuovo dMSA di decrittografare **i ticket emessi all'account precedente prima del passaggio**. Per evitare di interrompere le sessioni attive, inserisce sia le chiavi correnti che le chiavi precedenti all'interno di un nuovo blob ASN.1 chiamato **`KERB‑DMSA‑KEY‑PACKAGE`**.
|
||||
|
||||
Poiché la nostra falsa migrazione afferma che il dMSA sostituisce la vittima, il KDC copia diligentemente la chiave RC4‑HMAC della vittima nella lista delle **chiavi precedenti** – anche se il dMSA non ha mai avuto una password “precedente”. Quella chiave RC4 non è salata, quindi è effettivamente l'hash NT della vittima, dando all'attaccante la capacità di **cracking offline o “pass‑the‑hash”**.
|
||||
|
||||
Pertanto, il collegamento di massa di migliaia di utenti consente a un attaccante di estrarre hash “su larga scala”, trasformando **BadSuccessor in un primitivo sia di escalation dei privilegi che di compromissione delle credenziali**.
|
||||
|
||||
## Tools
|
||||
|
||||
- [https://github.com/akamai/BadSuccessor](https://github.com/akamai/BadSuccessor)
|
||||
- [https://github.com/logangoins/SharpSuccessor](https://github.com/logangoins/SharpSuccessor)
|
||||
- [https://github.com/LuemmelSec/Pentest-Tools-Collection/blob/main/tools/ActiveDirectory/BadSuccessor.ps1](https://github.com/LuemmelSec/Pentest-Tools-Collection/blob/main/tools/ActiveDirectory/BadSuccessor.ps1)
|
||||
|
||||
## References
|
||||
|
||||
- [https://www.akamai.com/blog/security-research/abusing-dmsa-for-privilege-escalation-in-active-directory](https://www.akamai.com/blog/security-research/abusing-dmsa-for-privilege-escalation-in-active-directory)
|
||||
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
@ -4,12 +4,18 @@
|
||||
|
||||
**Questa pagina è principalmente un riepilogo delle tecniche da** [**https://www.ired.team/offensive-security-experiments/active-directory-kerberos-abuse/abusing-active-directory-acls-aces**](https://www.ired.team/offensive-security-experiments/active-directory-kerberos-abuse/abusing-active-directory-acls-aces) **e** [**https://www.ired.team/offensive-security-experiments/active-directory-kerberos-abuse/privileged-accounts-and-token-privileges**](https://www.ired.team/offensive-security-experiments/active-directory-kerberos-abuse/privileged-accounts-and-token-privileges)**. Per ulteriori dettagli, controlla gli articoli originali.**
|
||||
|
||||
## **Diritti GenericAll su Utente**
|
||||
## BadSuccesor
|
||||
|
||||
{{#ref}}
|
||||
BadSuccesor.md
|
||||
{{#endref}}
|
||||
|
||||
## **Diritti GenericAll su un Utente**
|
||||
|
||||
Questo privilegio concede a un attaccante il pieno controllo su un account utente target. Una volta confermati i diritti `GenericAll` utilizzando il comando `Get-ObjectAcl`, un attaccante può:
|
||||
|
||||
- **Cambiare la Password del Target**: Utilizzando `net user <username> <password> /domain`, l'attaccante può reimpostare la password dell'utente.
|
||||
- **Kerberoasting Mirato**: Assegnare un SPN all'account dell'utente per renderlo kerberoastable, quindi utilizzare Rubeus e targetedKerberoast.py per estrarre e tentare di decifrare gli hash del ticket-granting ticket (TGT).
|
||||
- **Kerberoasting Mirato**: Assegnare un SPN all'account dell'utente per renderlo kerberoastable, quindi utilizzare Rubeus e targetedKerberoast.py per estrarre e tentare di decifrare gli hash del ticket di concessione del ticket (TGT).
|
||||
```bash
|
||||
Set-DomainObject -Credential $creds -Identity <username> -Set @{serviceprincipalname="fake/NOTHING"}
|
||||
.\Rubeus.exe kerberoast /user:<username> /nowrap
|
||||
@ -52,7 +58,7 @@ net user spotless /domain; Add-NetGroupUser -UserName spotless -GroupName "domai
|
||||
```
|
||||
## **WriteProperty (Auto-Membership)**
|
||||
|
||||
Un privilegio simile, questo consente agli attaccanti di aggiungersi direttamente ai gruppi modificando le proprietà del gruppo se hanno il diritto di `WriteProperty` su quei gruppi. La conferma e l'esecuzione di questo privilegio vengono eseguite con:
|
||||
Un privilegio simile, questo consente agli attaccanti di aggiungersi direttamente ai gruppi modificando le proprietà del gruppo se hanno il diritto `WriteProperty` su quei gruppi. La conferma e l'esecuzione di questo privilegio vengono eseguite con:
|
||||
```bash
|
||||
Get-ObjectAcl -ResolveGUIDs | ? {$_.objectdn -eq "CN=Domain Admins,CN=Users,DC=offense,DC=local" -and $_.IdentityReference -eq "OFFENSE\spotless"}
|
||||
net group "domain admins" spotless /add /domain
|
||||
@ -104,19 +110,19 @@ $ACE = New-Object System.DirectoryServices.ActiveDirectoryAccessRule $IdentityRe
|
||||
$ADSI.psbase.ObjectSecurity.SetAccessRule($ACE)
|
||||
$ADSI.psbase.commitchanges()
|
||||
```
|
||||
## **Replica sul Dominio (DCSync)**
|
||||
## **Replica nel Dominio (DCSync)**
|
||||
|
||||
L'attacco DCSync sfrutta specifici permessi di replica sul dominio per mimare un Domain Controller e sincronizzare dati, inclusi le credenziali degli utenti. Questa potente tecnica richiede permessi come `DS-Replication-Get-Changes`, consentendo agli attaccanti di estrarre informazioni sensibili dall'ambiente AD senza accesso diretto a un Domain Controller. [**Scopri di più sull'attacco DCSync qui.**](../dcsync.md)
|
||||
L'attacco DCSync sfrutta specifiche autorizzazioni di replica nel dominio per mimare un Domain Controller e sincronizzare i dati, comprese le credenziali degli utenti. Questa potente tecnica richiede autorizzazioni come `DS-Replication-Get-Changes`, consentendo agli attaccanti di estrarre informazioni sensibili dall'ambiente AD senza accesso diretto a un Domain Controller. [**Scopri di più sull'attacco DCSync qui.**](../dcsync.md)
|
||||
|
||||
## Delegazione GPO <a href="#gpo-delegation" id="gpo-delegation"></a>
|
||||
|
||||
### Delegazione GPO
|
||||
|
||||
L'accesso delegato per gestire gli Oggetti di Criterio di Gruppo (GPO) può presentare significativi rischi per la sicurezza. Ad esempio, se un utente come `offense\spotless` ha diritti di gestione GPO delegati, potrebbe avere privilegi come **WriteProperty**, **WriteDacl** e **WriteOwner**. Questi permessi possono essere abusati per scopi malevoli, come identificato utilizzando PowerView: `bash Get-ObjectAcl -ResolveGUIDs | ? {$_.IdentityReference -eq "OFFENSE\spotless"}`
|
||||
L'accesso delegato per gestire gli Oggetti di Criterio di Gruppo (GPO) può presentare rischi significativi per la sicurezza. Ad esempio, se a un utente come `offense\spotless` vengono delegati i diritti di gestione GPO, potrebbero avere privilegi come **WriteProperty**, **WriteDacl** e **WriteOwner**. Queste autorizzazioni possono essere abusate per scopi malevoli, come identificato utilizzando PowerView: `bash Get-ObjectAcl -ResolveGUIDs | ? {$_.IdentityReference -eq "OFFENSE\spotless"}`
|
||||
|
||||
### Enumerare i Permessi GPO
|
||||
### Enumerare le Autorizzazioni GPO
|
||||
|
||||
Per identificare GPO mal configurati, i cmdlet di PowerSploit possono essere concatenati. Questo consente di scoprire i GPO che un utente specifico ha permessi per gestire: `powershell Get-NetGPO | %{Get-ObjectAcl -ResolveGUIDs -Name $_.Name} | ? {$_.IdentityReference -eq "OFFENSE\spotless"}`
|
||||
Per identificare GPO mal configurati, i cmdlet di PowerSploit possono essere concatenati. Questo consente di scoprire i GPO che un utente specifico ha il permesso di gestire: `powershell Get-NetGPO | %{Get-ObjectAcl -ResolveGUIDs -Name $_.Name} | ? {$_.IdentityReference -eq "OFFENSE\spotless"}`
|
||||
|
||||
**Computer con una Politica Applicata**: È possibile risolvere quali computer una specifica GPO si applica, aiutando a comprendere l'ambito del potenziale impatto. `powershell Get-NetOU -GUID "{DDC640FF-634A-4442-BC2E-C05EED132F0C}" | % {Get-NetComputer -ADSpath $_}`
|
||||
|
||||
@ -124,6 +130,8 @@ Per identificare GPO mal configurati, i cmdlet di PowerSploit possono essere con
|
||||
|
||||
**OU con una Politica Applicata**: Identificare le unità organizzative (OU) colpite da una data politica può essere fatto utilizzando `Get-DomainOU`.
|
||||
|
||||
Puoi anche utilizzare lo strumento [**GPOHound**](https://github.com/cogiceo/GPOHound) per enumerare i GPO e trovare problemi in essi.
|
||||
|
||||
### Abuso GPO - New-GPOImmediateTask
|
||||
|
||||
I GPO mal configurati possono essere sfruttati per eseguire codice, ad esempio, creando un'attività pianificata immediata. Questo può essere fatto per aggiungere un utente al gruppo degli amministratori locali sulle macchine interessate, elevando significativamente i privilegi:
|
||||
@ -149,13 +157,13 @@ Gli aggiornamenti GPO si verificano tipicamente ogni 90 minuti. Per accelerare q
|
||||
|
||||
### Sotto il cofano
|
||||
|
||||
Dopo aver ispezionato i Compiti Pianificati per una data GPO, come la `Misconfigured Policy`, è possibile confermare l'aggiunta di compiti come `evilTask`. Questi compiti vengono creati tramite script o strumenti da riga di comando con l'obiettivo di modificare il comportamento del sistema o di elevare i privilegi.
|
||||
Dopo aver ispezionato i Task Pianificati per una data GPO, come la `Misconfigured Policy`, è possibile confermare l'aggiunta di task come `evilTask`. Questi task vengono creati tramite script o strumenti da riga di comando con l'obiettivo di modificare il comportamento del sistema o di elevare i privilegi.
|
||||
|
||||
La struttura del compito, come mostrato nel file di configurazione XML generato da `New-GPOImmediateTask`, delinea le specifiche del compito pianificato - inclusi il comando da eseguire e i suoi trigger. Questo file rappresenta come i compiti pianificati sono definiti e gestiti all'interno delle GPO, fornendo un metodo per eseguire comandi o script arbitrari come parte dell'applicazione delle policy.
|
||||
La struttura del task, come mostrato nel file di configurazione XML generato da `New-GPOImmediateTask`, delinea le specifiche del task pianificato - inclusi il comando da eseguire e i suoi trigger. Questo file rappresenta come i task pianificati sono definiti e gestiti all'interno delle GPO, fornendo un metodo per eseguire comandi o script arbitrari come parte dell'applicazione delle policy.
|
||||
|
||||
### Utenti e Gruppi
|
||||
|
||||
Le GPO consentono anche la manipolazione delle appartenenze degli utenti e dei gruppi sui sistemi target. Modificando direttamente i file di policy degli Utenti e dei Gruppi, gli attaccanti possono aggiungere utenti a gruppi privilegiati, come il gruppo locale `administrators`. Questo è possibile attraverso la delega dei permessi di gestione delle GPO, che consente la modifica dei file di policy per includere nuovi utenti o cambiare le appartenenze ai gruppi.
|
||||
Le GPO consentono anche la manipolazione delle appartenenze a utenti e gruppi sui sistemi target. Modificando direttamente i file di policy degli Utenti e dei Gruppi, gli attaccanti possono aggiungere utenti a gruppi privilegiati, come il gruppo locale `administrators`. Questo è possibile attraverso la delega dei permessi di gestione delle GPO, che consente la modifica dei file di policy per includere nuovi utenti o cambiare le appartenenze ai gruppi.
|
||||
|
||||
Il file di configurazione XML per Utenti e Gruppi delinea come queste modifiche vengono implementate. Aggiungendo voci a questo file, utenti specifici possono essere concessi privilegi elevati sui sistemi interessati. Questo metodo offre un approccio diretto all'elevazione dei privilegi attraverso la manipolazione delle GPO.
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user