Az - Device Registration

Basiese Inligting

Wanneer 'n toestel by AzureAD aansluit, word 'n nuwe objek in AzureAD geskep.

Wanneer 'n toestel geregistreer word, word die gebruiker gevra om met sy rekening aan te meld (met MFA indien nodig), dan versoek dit tokens vir die toestelregistrasiediens en vra dan 'n finale bevestigingsprompt.

Dan word twee RSA-sleutelpaar in die toestel gegenereer: Die toestelsleutel (publieke sleutel) wat na AzureAD gestuur word en die transport sleutel (private sleutel) wat in TPM gestoor word indien moontlik.

Dan word die objek in AzureAD geskep (nie in Intune nie) en AzureAD gee 'n sertifikaat wat deur dit onderteken is, terug aan die toestel. Jy kan nagaan dat die toestel AzureAD-verbonden is en inligting oor die sertifikaat (soos of dit deur TPM beskerm word).

dsregcmd /status

Na die toestelregistrasie word 'n Primêre Vernuwingsleutel deur die LSASS CloudAP-module aangevra en aan die toestel gegee. Met die PRT word ook die sessiesleutel gelewer wat slegs deur die toestel ontcijfer kan word (met die publieke sleutel van die vervoersleutel) en dit is nodig om die PRT te gebruik.

Vir meer inligting oor wat 'n PRT is, kyk:

{{#ref}} az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md {{#endref}}

TPM - Betroubare Platformmodule

Die TPM beskerm teen sleutel onttrekking van 'n afgeskakel toestel (as dit deur 'n PIN beskerm word) en teen die onttrekking van die private materiaal uit die OS-laag.
Maar dit beskerm nie teen snuffeling van die fisiese verbinding tussen die TPM en CPU of gebruik van die kriptografiese materiaal in die TPM terwyl die stelsel loop vanaf 'n proses met SISTEEM regte.

As jy die volgende bladsy kyk, sal jy sien dat diefstal van die PRT gebruik kan word om toegang te verkry soos 'n gebruiker, wat wonderlik is omdat die PRT op toestelle geleë is, so dit kan van hulle gesteel word (of as dit nie gesteel word, misbruik word om nuwe ondertekeningssleutels te genereer):

{{#ref}} az-lateral-movement-cloud-on-prem/pass-the-prt.md {{#endref}}

Registrasie van 'n toestel met SSO-token

Dit sou moontlik wees vir 'n aanvaller om 'n token vir die Microsoft toestelregistrasiediens van die gecompromitteerde toestel aan te vra en dit te registreer:

# Initialize SSO flow
roadrecon auth prt-init
.\ROADtoken.exe <nonce>

# Request token with PRT with PRT cookie
roadrecon auth -r 01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9 --prt-cookie <cookie>

# Custom pyhton script to register a device (check roadtx)
registerdevice.py

Wat jou 'n sertifikaat sal gee wat jy kan gebruik om in die toekoms vir PRT's te vra. Dit hou dus volharding in stand en omseil MFA omdat die oorspronklike PRT-token wat gebruik is om die nuwe toestel te registreer reeds MFA-toestemmings toegeken het.

Tip

Let daarop dat jy toestemming nodig sal hê om nuwe toestelle te registreer om hierdie aanval uit te voer. Ook, die registrasie van 'n toestel beteken nie dat die toestel toegelaat sal word om in Intune in te skryf nie.

Caution

Hierdie aanval is in September 2021 reggestel aangesien jy nie meer nuwe toestelle kan registreer met 'n SSO-token nie. Dit is egter steeds moontlik om toestelle op 'n wettige manier te registreer (met gebruikersnaam, wagwoord en MFA indien nodig). Kyk: roadtx.

Oorskrywing van 'n toestel-tiket

Dit was moontlik om 'n toestel-tiket aan te vra, die huidige een van die toestel te oorskryf, en tydens die vloei die PRT te steel (so geen behoefte om dit van die TPM te steel nie. Vir meer inligting kyk na hierdie praatjie.

Caution

Dit is egter reggestel.

Oorskryf WHFB-sleutel

Kyk die oorspronklike skyfies hier

Aanval opsomming:

Dit is moontlik om die geregistreerde WHFB sleutel van 'n toestel via SSO te oorskryf
Dit verslaan TPM-beskerming aangesien die sleutel gesnif word tydens die generasie van die nuwe sleutel
Dit bied ook volharding

Gebruikers kan hul eie searchableDeviceKey eienskap via die Azure AD Graph wysig, egter, die aanvaller moet 'n toestel in die tenant hê (geregistreer op die vlug of 'n gesteelde sertifikaat + sleutel van 'n wettige toestel hê) en 'n geldige toegangstoken vir die AAD Graph.

Dan is dit moontlik om 'n nuwe sleutel te genereer met:

roadtx genhellokey -d <device id> -k tempkey.key

en dan PATCH die inligting van die searchableDeviceKey:

Dit is moontlik om 'n toegangstoken van 'n gebruiker te verkry via device code phishing en die vorige stappe te misbruik om sy toegang te steel. Vir meer inligting, kyk:

{{#ref}} az-lateral-movement-cloud-on-prem/az-phishing-primary-refresh-token-microsoft-entra.md {{#endref}}

5.7 KiB Raw Blame History