Passwordless and SSO solutions have become extremely popular, mostly due to their ability to balance convenience and security. But are they bulletproof? Join us to learn how these technologies have changed the attack surface. Using Windows Hello and Browser SSO in Hybrid Azure environments, the presenter will demonstrate successful attack methods and provide actionable mitigation techniques.

1. Asaf Hecht
Security Research Team Leader, @Hechtov

2. 2
Name: Asaf Hecht
Role: Security Research Team Leader @ CyberArk Labs
M.Sc degree in Software and Information Systems Engineering
Author of open source tools
Presented at RSA US, BlackHat EU, Infosec and Impact conferences
Submitted 17 patent pending ideas
Twitter: @Hechtov

3. How to Start
3

4. 4
A Word on CyberArk Labs
Researching from the red side Goal: have better defenses

5. 5
CyberArk Labs Website
https://labs.cyberark.com/

6. 6
Threat Research Blog
https://www.cyberark.com/resources/threat-research-blog

7. GitHub – Open Sources For All
https://github.com/cyberark
BlobHunter
DllSpy
ACLight
SkyWrapper Ketshash
Shimit
Examples for the tools:
Kubesploit
7

8. Starting The Journey

9. Modern Environments
9

10. How Users See It
10
Password
Password
Password
Password
Password
A key
A key
A key
A key
A key
Secret
pattern
Password
Password

11. How Attackers See It
11

12. The Current Promising Trends
12
Passwordless SSO

13. Adding SSO
13
SSO
One password
to rule them all

14. How Attackers See It
14
SSO
One password
to rule them all

15. Adding Passwordless Technologies
15
SSO
Face recognition,
Fingerprint,
Pin code with
TPM, etc.
Passwordless

16. How Attackers See It
16
SSO
Face recognition,
Fingerprint,
Pin code with
TPM, etc.
Passwordless Does it help?
What can the attacker still do?

17. Time to dive into the details

18. 18
Passwordless Trend
Microsoft leads with Windows Hello

19. 19
Windows Hello - Background
Windows Hello -> Password-less authentication

20. 20
Windows Hello - Background
Windows Hello for Business vs Windows Hello (Local Device)

21. Windows Hello - Background
key-based and certificate-based
authentication
Password
Authentication
+
21

22. 22
Windows Hello - Background
With Hello – new AD Attribute for the users:
msDS-KeyCredentialLink

23. 23
Windows Hello - Background
Public Key is stored on the AD
Private Key is stored inside the TPM
(Trusted Platform Module)

24. 24
Windows Hello - Background
The Private Key is protected in the TPM with:
PIN, face recognition, biometric, etc.

25. 25
Windows Hello - Background
Windows Hello MFA
A key or certificate tied to a physical device
Something that the person knows (a PIN)
Something that the person is (biometrics)
or
* The private key never leaves
the device when using TPM

26. 26
Windows Hello – Network Login Process
Entering PIN
Face Recognition
AD
Unlocking the Private Key
from the TPM
Private Key is used
for starting Kerberos
TGT and NTLM on the endpoint
The user can access other resources
3
1
1
2
4
5
* Users still have passwords,
but with Hello they
authenticate against the
Public Key

27. 27
What Attackers Can Still Do
Most of all the Active Directory attacks still work!!
THE REASON:
Windows Hello just changes the first authentication step, after that it’s still
Kerberos and NTLM in on-prem environments
Pass the Hash Over-Pass the Hash
Pass the Ticket

28. 28
Demo - Pass the Ticket Attack with Windows Hello is on

29. Exploiting Windows Hello for Business – Previous Work
Michael Grafnetter (@MGrafnetter) did great research in this area
Attack vectors:
– Injecting custom NGC (Next-Gen Credentials) keys
– Old TPM versions contain vulnerability that weaken Windows Hello’s key strength
– CVE-2017-15361 (A.K.A ROCA)
– Unused and orphaned public keys that still in the account’s properties
29

30. Injecting a Windows Hello key into the user
Injecting Custom NGC (Next-Gen Credentials) Keys:
– Generate an RSA key pair
– Create NGC Blob from RSA Public Key
– Write the NGC Blob to Active Directory
– Authenticate Using PKINIT
Prerequisite:
– Write permissions on target user account => means post-exploitation
30

31. CVE-2017-15361 A.K.A ROCA Vulnerability
31
Source: https://securityaffairs.co/wordpress/64401/breaking-news/roca-vulnerability-cve-2017-15361.html

32. Exploiting Windows Hello for Business – previous work
32
Source: https://www.darkreading.com/application-security/microsoft-issues-advisory-for-windows-hello-for-business/d/d-id/1336514
Windows Hello’s keys of
users and devices that were
removed might still be
useful!

33. Bypassing Face Recognition with External USB Camera
33
Stay tuned…
The research will be published
at Black Hat US conference

34. 34
Browser SSO in Hybrid Environments

35. 35
Hybrid Environment
Cloud
Domain Controller
(Active Directory)
IAM/SSO solution
(on-premises agent)
Federation solution
(ADFS)
Synchronization solution
(Azure AD Connect)
On-premises network:

36. 36
Hybrid Environment with Azure
Azure Cloud
Domain Controller
(Active Directory)
Synchronization solution
(Azure AD Connect)
On-premises network:

37. Joined Device in
an On-Prem Active Directory
37
Hybrid Device Join
Domain Controller
(Active Directory)
On-premises network:
Azure Active Directory
Joined Device in
an Azure Active Directory
device object in
Azure AD
device account
in the AD

38. 38
Example for an AD and AAD joined device

39. 39
Advantages of Being Hybrid
SSO
Single Sign On
Logon once with your on-prem
authentication
Access the cloud services and
online apps
One of the main advantages in Hybrid Environment:

40. 40
Browser SSO – Chrome Extension for Windows
* In Edge browser the SSO is built-in natively

41. 41
Azure Browser SSO – Applications View

42. OAuth provides authorization
and provide access to resources
OIDC is based on OAuth
Adding Authentication for SSO
Super Popular!
Background on Modern Authentication and Authorization
42

43. Background on Modern Authentication and Authorization
OAuth2
Access Tokens
Refresh Token
Application
OAuth is very popular in
modern cloud environments,
online apps and hybrid connectivity
43

44. In Azure Browser SSO
Gets a PRT (Primary Refresh Token)
Access Tokens
Applications
On an Azure AD Joined Device:
Refresh Tokens
User logs on
PRT Cookie (JWT token)
44

45. In Azure Browser SSO
Session Key -> per PRT, device
Derived Key -> required for getting
Refresh Token
Transport Key -> per device (on registration)
Gets a PRT (Primary Refresh Token)
Access Tokens
Applications
On an Azure AD Joined Device:
Refresh Tokens
User logs on
PRT Cookie (JWT token)
45

46. 46
In Azure Browser SSO
Stored in the TPM
If no TPM -> in the Registry
Stored in Lsass
In the CloudAP (an authentication package)
Stored in the browser and DPAPI
Session Key -> per PRT, device
Derived Key -> required for getting
Refresh Token
Transport Key -> per device (on registration)
Gets a PRT (Primary Refresh Token)
Access Tokens
Applications
On an Azure AD Joined Device:
Refresh Tokens
User logs on
PRT Cookie (JWT token)

47. Stored in Lsass
In the CloudAP (an authentication package)
Regular user rights can be used for exploitation
and extraction of the SSO tokens!
Local admin can exploit and
extract it!
47
In Azure Browser SSO
Stored in the TPM
If no TPM -> in the Registry
Stored in the browser and DPAPI
Session Key -> per PRT, device
Derived Key -> required for getting
Refresh Token
Transport Key -> per device (on registration)
Gets a PRT (Primary Refresh Token)
Access Tokens
Applications
On an Azure AD Joined Device:
Refresh Tokens
User logs on
PRT Cookie (JWT token)

48. 48
Attacking Azure Browser SSO
Local administrator privileges
Attacker can extract the PRT and
the derived key from the machine
Access Azure AD connected resources
Regular user privileges
Attacker can request regular
refresh tokens (like the user)

49. NEW Attack - Pass The PRT
Local administrator
privileges
Extract the PRT and the derived
key from the machine
Access any Azure AD connected resource
49

50. Mimikatz can be used to attack Azure Browser SSO
Great research work
was done in this field by
Benjamin Delpy @gentilkiwi and
Dirk-jan Mollema @_dirkjan
50

51. Another Weakness in OAuth Apps – BlackDirect Vulnerability

52. OAuth Application Configuration Example
URLs that are whitelisted
for getting OAuth tokens
52

53. OAuth 2.0 – Flow Example
USER
https://login.microsoftonline.com/common/oauth2/authorize?
response_type=token&
client_id=abc...&
resource=office&
redirect_uri=https://office.com/
https://office.com/
AUTHORIZATION SERVER
The browser sends HTTP request to the Authorization Server
for creating access token to the Resource Server
3
The user browses to https://office.com
1
Office.com redirect the user to the
authorization server for getting his
access token
2
The authorization server creates an access token
for the resource server and redirects the client’s browser
to the whitelisted given redirect URI
4
The browser (the client) sends
the access token to the resource
server to get his data
5
The resource server returns the client’s data
6
THE CLIENT
53

54. BlackDirect Vulnerability – Attack Flow
https://login.microsoftonline.com/common/oauth2/authorize?
response_type=token&
client_id=abc...&
resource=office&
redirect_uri=https://compromised-subdomain.office.com/
USER
https://office.com/
AUTHORIZATION SERVER
THE CLIENT
The browser sends HTTP request to the Authorization Server
for creating access token to the Resource Server
3
The user browses to
https://compromised-subdomain.office.com
1
compromised-subdomain.office.com
redirect the user to the authorization
server for getting his access token
2
The authorization server creates an access token
for the resource server and redirects the client’s browser
to the whitelisted given redirect URI
4
The browser (the client) sends
the access token to the fake
resource server
5 ATTACKER
https://compromised-
subdomain.office.com/
The Attacker gets the client’s data
from the real resource server
6 7
54

55. BlackDirect Discovery in Azure OAuth Apps
55
https://fix.sa.lcs.dynamics.com
https://fix.uae.lcs.dynamics.com
https://s2.support.ext.azure.com
https://s1.support.ext.azure.com
https://westus-maas-he.az-westus-maas.cloudsimple.com
https://env-cs-westus-devtest-03.qa.cloudsimple.us
https://env-cs-westus-devtest-30.qa.cloudsimple.us
https://env-cs-westus-devtest-80.cloudsimple.us
https://env-cs-westus-devtest-25.qa.cloudsimple.us
https://env-cs-westus-devtest-67.qa.cloudsimple.us
https://env-cs-westus-devtest-31.qa.cloudsimple.us
https://ccinsights-globalservice-prod.azurewebsites.net
https://oneproject-prod-global-m00.op.trafficmanager.net
https://demoaccount1.catalog-int.clouddatahub-int.net
https://demoaccount2.catalog-int.clouddatahub-int.net
Subdomains management
Not simple as you might
have thought
Real examples for possible subdomain takeovers:

56. We published a scanning tool:
– Website: https://black.direct/
– 203 companies scanned their Azure Apps for BlackDirect
Results – an average:
– 894 OAuth Applications per company
– About 6 vulnerable URLs per company!
– 3.5 vulnerable apps per company!
Example for a big electronic vendor:
– 3863 OAuth Applications
– 237 Vulnerable URLs
– 97 Vulnerable Applications
OAuth and BlackDirect Popularity
Blog post :
https://www.cyberark.com/resources/threat-research-blog/blackdirect-microsoft-azure-account-takeover
56

57. The End is only the Beginning

58. Apply What You Have Learned Today
Next week you should:
– Make sure all your SSO and Passworldless solutions are:
Implemented according to their best practices and install their last updates
In the first three months following this presentation you should:
– Secure your privilege accounts, including local admins, sensitive apps, remote access procedures
– If the security fundamentals will be compromised SSO and Passworldless aren’t going to help
Within six months you should:
– Perform a periodic scans for the mentioned threats:
– Remove unused Hello keys, go through the login logs, scan yourself against BlackDirect, etc.
58

59. Next Webinars by CyberArk Labs
59
Kubernetes Security Microsoft Teams Vulnerability

60. Summary
We reviewed real-life threats in the field of Passwordless, SSO and OAuth
More details are available online – check them out
Follow the best practices when implementing technologies
Ensure the security fundamentals are in place, like protecting the access points of your
network and your privileged accounts
60

61. GREAT! ANY Q?
Feel free to contact me
Twitter: @Hechtov
To learn more about CyberArk Labs, visit:
Https://labs.cyberark.com/