Forum Discussion
Is it possible to protect the Primary Refresh Token (PRT) if attacker has hands on keyboard
Hi everyone,
I want to ask if anyone know if possible to defend against pass-the-prt attack? We are about to embark on a journey to deploy privilege access workstations to all IT admins with more or less no internet access. The idea is to have a clean source and heavily reduce an attacker getting hold of the credentials / PRT of an admin account. But because it is so heavily locked down it is already causing issues for us.
So I want to find out how big of an issue it is if an attacker was able to get a foothold on a device which is used by a standard user account that has Microsoft Entra ID roles assigned via PIM.
So we have Defender for Endpoint installed on all devices, Tamper protection is on and the ASR rule "Block credential stealing from the Windows local security authority subsystem (lsass.exe)" is set to block. further to that we require a FIDO2 security key for all IT admins and CA policies are set to require both MFA and a compliant device.
But as mentioned above, if an attacker gets a foothold on a device used by an IT admin user who logs in with his or hers standard account and elevate into an Entra admin role, is it game over by then?
If that is the case, it seems to me that the PRT is the weekend and we would be better off not having the device used for admin privileged joined Microsoft Entra.
Hi RippieUK,
You mention that the admins must request elevated roles via PIM. These PIM requests should be reviewed and confirmed by someone on the IT team before allowing the elevation and approval of the PIM request. Even roles where the default is self-service you can go in and edit to Require Approval.The main security feature you might be interested in considering you mentioned pass-the-prt specifically is (currently in preview) CAP - Token Protection aka device binding. This ensures that the token in use is coming from the device it’s meant to be coming from. Furthermore, you could play around with the CAPs targeting these devices and users and adding Session controls such as a short SIF: https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-session-lifetime#user-sign-in-frequency-and-device-identities .
This GitHub repo is a great read and goes into detail about several different token attack types and highlights where the attacks could fail or expose the malicious behavior: Cloud Architekt - Azure Attack-DefenseIt sounds like you’re already implementing MFA Strength Factors and forcing phish-proof which is awesome. Make sure you’ve also disabled SSPR for admins.
Also want to confirm, these admins have a separate account to perform admin tasks in Entra from their on-prem admin accounts and ensure the Entra admin accounts only exist in the cloud and don’t touch your on-prem directory.
Best regards,
Dylan
- Hi Dylan, SSPR is disabled for admins and PIM requests are behind approvals and the admin accounts are separate cloud only accounts. further more the admin portals require a FIDO2 security key and FIDO2 security keys are not able to log in to Windows, we disabled that.
There is still the fear that what if an attacker gets a foothold on to our PAW devices, privilege escalate up to local admin and steal the PRT.
We do use a PAW device as referenced above which has no real internet so the chance of an attacker landing on a PAW device would have to come from either stealing the device and breaking bitlocker pre-boot and guess the username and password or if an admin use a PAW some random location with a dodgy wireless network and is able to compromise it being MITM.
I just dont fully understand it. if the PRT is so sensitive, surely an option to turn it off so the device behave from a sign in perspective as if you signed in from a personal home device. No PRT, no automatically logging in to Microsoft services with your Azure account.
