Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

I'm in your cloud... reading everyone's email. Hacking Azure AD via Active Directory


Published on

Azure AD is everything but a domain controller in the cloud. This talk will cover what Azure AD is, how it is commonly integrated with Active Directory and how security boundaries extend into the cloud, covering sync account password recovery, privilege escalations in Azure AD and full admin account takeovers using limited on-premise privileges.

While Active Directory has been researched for years and the security boundaries and risks are generally well documented, more and more organizations are extending their network into the cloud. A prime example of this is Office 365, which Microsoft offers through their Azure cloud. Connecting the on-premise Active Directory with the cloud introduces new attack surface both for the cloud and the on-premise directory.

This talk looks at the way the trust between Active Directory and Azure is set up and can be abused through the Azure AD Connect tool. We will take a dive into how the synchronization is set up, how the high-privilege credentials for both the cloud and Active Directory are protected (and can be obtained) and what permissions are associated with these accounts.

The talk will outline how a zero day in common setups was discovered through which on-premise users with limited privileges could take over the highest administration account in Azure and potentially compromise all cloud assets.

We will also take a look at the Azure AD architecture and common roles, and how attackers could backdoor or escalate privileges in cloud setups.

Lastly we will look at how to prevent against these kind of attacks and why your AD Connect server is perhaps one of the most critical assets in the on-premise infrastructure.

Published in: Technology

I'm in your cloud... reading everyone's email. Hacking Azure AD via Active Directory

  1. 1. Hacking Azure AD via Active Directory Dirk-jan Mollema (@_dirkjan) I’m in your cloud… reading everyone’s email Classification: Public
  2. 2. - Lives in The Netherlands - Hacker / Red Teamer / Researcher @ Fox-IT since 2016 - Previously freelance webdeveloper - Author of several Active Directory tools - Mitm6 - Ldapdomaindump - - - Co-author of ntlmrelayx - Blogs on - PrivExchange - Tweets stuff on @_dirkjan Whoami Classification: Public
  3. 3. • What is Azure AD • Integrating Azure AD with Active Directory • Azure AD Administrator roles • Pwning the cloud • Privilege escalation in Azure AD • Abusing Seamless Single Sign On Contents Classification: Public
  4. 4. • Me writing PowerShell • Me writing C# Also: Classification: Public
  5. 5. • Pentest goal: Access CEO mailbox • Stored in Office 365 • MFA enforced for most accounts • CEO workstation unreachable How it all started Classification: Public
  6. 6. Office 365 Azure Active Directory Active Directory Domain admin Controls ??? ??? ??? Limited AD admin ??? ??? ??? Classification: Public
  7. 7. On-premise Research approach Cloud Active Directory Azure Active Directory Classification: Public
  8. 8. On-premise Assumption: security boundary Cloud Active Directory Azure Active Directory Security boundary Classification: Public
  9. 9. On-premise Security boundary information flow Cloud Active Directory Azure Active Directory Security boundary Flow of trusted information Classification: Public
  10. 10. • “Azure Active Directory (Azure AD) is Microsoft’s cloud-based identity and access management service.” Azure AD Classification: Public
  11. 11. Azure AD vs Active Directory (Windows Server) Active Directory Azure Active Directory LDAP REST API’s NTLM/Kerberos OAuth/SAML/OpenID/etc Structured directory (OU tree) Flat structure GPO’s No GPO’s Super fine-tuned access controls Predefined roles Domain/forest Tenant Trusts Guests Classification: Public
  12. 12. • 3 primary methods of integration: • Password Hash Synchronization (PHS) • Pass Through Authentication (PTA) • Active Directory Federation Services (AD FS) Integrating Azure AD and Active Directory Classification: Public
  13. 13. Password hash synchronization Source: Classification: Public
  14. 14. • Utility installed on-premise • Has a high-privilege account in AD • Has also a high-privilege account in Azure AD • High value target! Azure AD connect Classification: Public
  15. 15. • If password hash sync is in use: TL;DR Compromised Azure AD connect Sync account = Compromised AD Classification: Public
  16. 16. Finding the Sync server and account Classification: Public
  17. 17. • Configuration database ADSync.mdf C:Program FilesMicrosoft Azure AD SyncData • Can be accessed as LocalDB on host or copied and browsed locally Hunting for creds in AD Sync Classification: Public
  18. 18. Extracting the configuration SELECT private_configuration_xml, encrypted_configuration FROM mms_management_agent; Classification: Public
  19. 19. Agent configuration Classification: Public
  20. 20. • Crypto stuff is in mcrypt.dll • Mcrypt.dll contains both C# and native code • C# easy to analyze using dnSpy • Native code contains the crypto functions Encrypted configuration Classification: Public
  21. 21. SELECT instance_id, keyset_id, entropy FROM mms_server_configuration; Classification: Public
  22. 22. Create limited POC – analyze with procmon Classification: Public
  23. 23. • Locally: error • On server: works • Even with same data in registry • Suggests: Machine dependent protection  DPAPI Local test VS server test Classification: Public
  24. 24. • Simple API to use: 1 line of code to securely encrypt data • Uses certificates per user or computer • Monitor calls to Crypt32.dll DPAPI Classification: Public
  25. 25. Tracking DPAPI with API Monitor Classification: Public
  26. 26. More crypto stuff Classification: Public
  27. 27. • Encryption key is encrypted with DPAPI • Decrypted version contains some blob with AES keys • Uses AES-256 in CBC mode Crypto TL;DR Classification: Public
  28. 28. • Adsync database • Encrypted data • Entropy • Instance ID • Keyset ID • Registry • Encryption Key (DPAPI protected) • DPAPI machine secrets Info needed to decrypt variables Classification: Public
  29. 29. Dumping the info - demo Classification: Public
  30. 30. Classification: Public
  31. 31. Or remotely over the network Classification: Public Credit: @agsolino for his work on impacket and secretsdump Get the database Dump DPAPI enc. Keys (registry) Dump AD Sync enc. keys (registry) Get DPAPI masterkey Decrypt all the stuff
  32. 32. DCSync with AD Sync account Classification: Public
  33. 33. Recommendation Azure AD Connect Active Directory administrative tier model: Classification: Public
  34. 34. Azure AD – Roles and access Classification: Public
  35. 35. • RBAC Roles are only used for Azure Resource Manager • Office 365 uses administrator roles exclusively Azure AD roles Classification: Public
  36. 36. • MSOnline PowerShell module • Focusses on Office 365 • Some Office 365 specific features • AzureAD PowerShell module • General Azure AD • Different feature set Interacting with Azure AD Classification: Public
  37. 37. Module differences Classification: Public
  38. 38. • Company Administrator = Global Administrator • Anyone can query role members Hunting for admins Admins only Classification: Public
  39. 39. • Most likely not all admins are synced with on-premise • Can be queried by any Azure AD user • If we are Domain Admin, can we sync an on-premise account? Cloud-only or synced Classification: Public
  40. 40. Can we sync existing users? Classification: Public
  41. 41. • Needs to have a proxy address (means the account has a mailbox) • License not required • Should not already be synced Finding potential targets Classification: Public
  42. 42. Classification: Public
  43. 43. Creating a sync target Classification: Public
  44. 44. Classification: Public
  45. 45. Delegate permissions for the inbox Classification: Public
  46. 46. • We created a new account • Linked it to an existing admin • Delegated ourselves mailbox permissions • Flag achieved  So about that assignment Classification: Public
  47. 47. • Domain Admin is not required to create new users • Often delegated to (junior) IT admins • “Create user” privileges sufficient to take over admin accounts • Multi Factor Authentication not bypassed • Make sure all admin accounts have MFA enforced! • Prime target: emergency admin accounts not requiring MFA (recommendation from Microsoft until a few months ago) I sync we have a problem Classification: Public
  48. 48. • Reported to MSRC in June 2018 • Fixed mid October 2018 • Account sync not possible anymore for admin accounts Don’t worry it’s fixed Classification: Public
  49. 49. • MFA all the things! • If you can’t, enable monitoring (license required) Still Classification: Public
  50. 50. Role privileges and escalation Classification: Public
  51. 51. • Global/Company administrator can do anything • Limited administrator accounts • Application Administrator • Authentication Administrator • Exchange Administrator • Etc • Roles are fixed Azure AD admin roles Source: Classification: Public
  52. 52. • “create and manage all aspects of enterprise applications, application registrations, and application proxy settings” • What is an application? Application Administrators Classification: Public
  53. 53. • Examples: • Microsoft Graph • Azure Multi-Factor Auth Client • Azure Portal • Office 365 portal • Azure ATP • A default Office 365 Azure AD has about 200 service principals (read: applications) Everything is an application Classification: Public
  54. 54. • Applications/App registrations are applications that exist in your Azure AD • Service principals/Enterprise Applications are accounts in your Azure AD linked to either your application or a third party application. Service principals VS applications Classification: Public
  55. 55. • Two types of privileges: • Delegated permissions • Require signed-in user present to perform • Application permissions • Are assigned to the application, which can use them at any time • These privileges are assigned to the service principal • Admin approval may be needed Application privileges Classification: Public
  56. 56. Example: Application permissions Classification: Public
  57. 57. Service principal permissions Classification: Public
  58. 58. • By default, any user in Azure AD can create: • New applications • Service principals for these application • That user will be the owner of the applications • Bob registers an application • Admin grants consent to the application to access data • Bob now has access to that data Problem 1 Classification: Public
  59. 59. • Step 1: Add certificate as credential to our application Example: Add certificate to service principal Classification: Public
  60. 60. • Step 2: Connect as service principal Example (2) Classification: Public
  61. 61. With user context Classification: Public
  62. 62. With application context Classification: Public
  63. 63. • Log shows actions were performed by application Logging? Classification: Public
  64. 64. • “Application administrators” can manage all applications and service principals • Two (default) service principals have “Directory.ReadWrite.All” • By adding a credential to an application, the Application Administrator escalates their privileges Problem 2 Classification: Public
  65. 65. Previously Classification: Public
  66. 66. Python POC code to connect Classification: Public
  67. 67. • Reported to MSRC in August 2018 • Confirmed fixed in December • Current behaviour: Fix timeline Classification: Public
  68. 68. Behaviour is now documented Classification: Public
  69. 69. • Global Admins can still assign privileges to applications • Possibility for backdooring accounts • Service Principal accounts do not require MFA • Credentials assigned to Microsoft apps are not visible in the Azure Portal • Custom applications with high privileges still at risk Remaining risks Classification: Public
  70. 70. Azure Resource manager also affected Classification: Public
  71. 71. • RBAC roles can be assigned to service principals • These can be managed by Application Administrators • Also by the on-premise sync account • High privilege applications might need an account • Example: Terraform Azure RBAC Classification: Public
  72. 72. Anyone with control over Service Principals can assign credentials to them and potentially escalate privileges. TL;DR Classification: Public
  73. 73. Seamless Single Sign On aka: let’s port all of Kerberos’ weaknesses to Azure Classification: Public
  74. 74. SSO Flow (simplified) 1. Log in request Active Directory 2 .Request Service Ticket for AAD Azure Active Directory Classification: Public
  75. 75. SSO Flow 2 (simplified) Active Directory 3. Reply with service ticket 4. Log in with service ticket Azure Active Directory Classification: Public
  76. 76. • Active Directory stores a computer account: AZUREADSSOACC$ • Password is shared with Azure AD • Service ticket is encrypted with this password, contains user SID • Azure AD decrypts ticket, looks up user by SID in Azure AD • Logged in Technical things Classification: Public
  77. 77. • If Active Directory is compromised, attackers can dump hashes and create fake Service Tickets • Called Silver Tickets • Can be used to log in as any user in Azure AD (if no MFA) • Well-known Kerberos risk Compromised Active Directory Source: Classification: Public
  78. 78. • Kerberos has the concept of “delegation” • Delegation means trusting applications to impersonate other users • If configured incorrectly, applications can impersonate any user • 3 forms of delegation: • Unconstrained: very dangerous, avoid using • Constrained: has to be specifically configured, unlikely attack vector for Azure AD • Resource based constrained: Recently being researched What about delegation Classification: Public
  79. 79. • Delegation is configured on the target object • The AZUREADSSOACC$ account is a computer account • No special protections • Anyone that can manage computer accounts in the container or OU this account is in can configure it • Likely many admins in larger orgs have this access Resource based constrained delegation Credits: @elad_shamir, @harmj0y and @gentilkiwi for their research on this topic Classification: Public
  80. 80. Demo Classification: Public
  81. 81. Getting a ticket for Vince Classification: Public
  82. 82. Log in on Azure Classification: Public
  83. 83. Classification: Public
  84. 84. Insert ticket here Classification: Public
  85. 85. Logged in  Classification: Public
  86. 86. Anyone who can edit properties* of the AZUREADSSOACC$ account, can impersonate any user in Azure AD using Kerberos (if no MFA) TL;DR *and has control over at least one account with a Service Principal Name set Classification: Public
  87. 87. In BloodHound 2.1 Classification: Public
  88. 88. • Reported to MSRC January 2019 • Conclusion: Won’t fix for now, but looking into hardening measures for the future Disclosure timeline Classification: Public
  89. 89. Conclusions Classification: Public
  90. 90. • MFA all the things • Be careful with MFA exclusions on IP basis (guest network?) • Protect your Azure AD Sync servers like domain controllers • Audit your Service Principals, their access and their owners • Using SSO weakens security, protect the SSO account Conclusions Classification: Public