Skip to content

Latest commit

 

History

History
316 lines (209 loc) · 36.6 KB

AADCSyncServiceAccount.md

File metadata and controls

316 lines (209 loc) · 36.6 KB
Raw

Abuse of Azure AD Connect Sync Service Account

Author: Sami Lamppu and Thomas Naunheim Created: March 2022 Updated: October 2022 (Added M&TRE mapping)

Introduction

In this paper we are mainly focusing on the following scenario:

  1. Attacking administrative account with directory role assignment to "Hybrid Identity Administrator" for managing Azure AD connect configurations
  2. Abusing of Azure AD user "On-Premises Directory Synchronization Service Account" which will be used to synchronize objects from Azure AD Connect (AADC) Server (AD on-premises) to Azure AD.

Out of scope are privilege escalation and attack paths from AADC server in direction to Active Directory (incl. abuse Azure AD DS connector account)

Architecture and Service Accounts

AD DS Connector Account has been configured during AADC server implementation and will be used to read/write information to Windows Server Active Directory. This account has no permissions in Azure AD but privileges to write-back attributes and passwords to on-premises AD. Service account cannot be used as "Group Managed Service Account (gMSA)" and needs to be protected particularly.

AAD Connector Account will be used to write information and synchronize objects from/to Azure AD. Account will be created for each AAD Connect Server and is visible with display name "On-Premises Directory Synchronization Service Account" in Azure AD tenant. The account is assigned to the Azure AD directory role "Directory Synchronization Accounts".

ADSync Service Account takes place for running the synchronization service but has also access to the database for storing AADC information. No (direct) privileged access exists to Azure AD or Active Directory objects. Nevertheless, it’s a sensitive account because it plays a central part in running AADC services and data access (incl. SQL database).

More details about Azure AD Connect accounts and permissions are described in Microsoft Docs articles.

Attack scenarios

This chapter describes attack scenarios referring to the document scope.

  • Access to unprotected Azure AD Connect servers (not hardened or restricted access as Tier0 system) or exfiltration from uncontrolled/unencrypted backups allows access to AADC database.

    • Decryption and extraction of stored Azure AD and Active Directory credentials can be achieved by using fox-it/adconnectdump.
    • Dumping of encryption keys of DPAPI and getting AADC related credentials has been automated as part of the "Get-AADIntSyncCredentials" cmdlet in the AADInternals PowerShell module.

  • Passwords of Azure AD connector account can be exfiltrated in clear text if privilege escalation to local admin permissions on AADC server was successfully.

  • Refresh/access token from account with assigned directory role "Hybrid Identity Administrator" can be replayed when it will be used to apply AADC configuration changes. Members of this role could be excluded from device compliance to allow usage on AAD Connect Server for management tasks.

    Picture1.png

    • Token could be exfiltrated by "man in the middle" attacks, such as compromised proxy solutions (which will be used to prevent direct internet connection) and manipulated certificates.

  • User accounts with assigned "Hybrid Identity administrators" roles has enhanced permissions for ’sync service features’ but also, extensive management permissions for service principals and app registrations in Azure AD which includes:

    • Change configuration of "soft and hard matching" feature settings.

      • By default, cloud-only accounts are only protected if they are assigned to directory roles.
      • Hard matching can be blocked for cloud-only particularly. This feature was introduced in October 2021.
      • Only users with direct (role assignable group) membership to directory roles (such as Global Admin) are particularly protected.

        • This can be seen in this test by using Privileged Access Groups (PAG), Role Assignable Groups (PRG) in a combination of eligible/permanent membership and ownership of group:

    • Blocking of soft and hard matching (recommended) could have been already configured.

      • Nevertheless, "Hybrid identity admins" are able to modify this setting and could be used to "synchronize" accounts and take control of accounts with sensitive permissions outside of Azure AD directory roles.

    • Directory role permissions allows to change ownership of "GraphAggregatorService" service principal and add app roles to self-grant arbitrary Microsoft Graph API permission.

  • Temporary Access Pass can be used by compromised high-privileged accounts or service accounts to create a backdoor on "On-Premises Directory Synchronization Service Account":

    • This allows to issue credentials for existing synchronization account(s), instead of creating noise (in security detections) by creating new accounts or reset password of existing ones. Most SecOps/SOC teams are not monitoring the synchronization accounts actively or particularly.

MITRE ATT&CK Framework

MITRE ATT&CK framework is commonly used for mapping Tactics, Techniques and Procedures (TTPs) for adversary actions and emulating defenses on organizations around the world.

Tactics, Techniques & Procedures (TTPs) of the named attack scenarios

Open in MITRE ATT&CK Navigator

TTP on abusing Azure AD Connect Sync Service Account

Attack Scenario TTPs Description
Access to unprotected Azure AD Connect servers (not hardened or restricted access as Tier0 system) or exfiltration from uncontrolled/unencrypted backups allows access to the AADC database

Passwords of Azure AD connector accounts can be exfiltrated in clear text if privilege escalation to local admin permissions on the AADC server was successful		 Unsecured Credentials: Credentials In Files T1552.001 Adversaries may search local file systems and remote file shares for files containing insecurely stored credentials. These can be files created by users to store their own credentials, shared credential stores for a group of individuals, configuration files containing passwords for a system or service, or source code/binary files containing embedded passwords.
Access to unprotected Azure AD Connect servers (not hardened or restricted access as Tier0 system) or exfiltration from uncontrolled/unencrypted backups allows access to the AADC database
 Unsecured Credentials: Private Keys T1552.004 Adversaries may search for private key certificate files on compromised systems for insecurely stored credentials. Private cryptographic keys and certificates are used for authentication, encryption/decryption, and digital signatures.[1] Common key and certificate file extensions include: .key, .pgp, .gpg, .ppk., .p12, .pem, .pfx, .cer, .p7b, .asc.
Using credentials of Azure AD Connector accounts from unprotected Azure AD Connect for privileged access to Connector API,
Adding temporary access pass to Azure AD Connector Account		 Valid Accounts: Cloud Accounts - T1078.004 Adversaries may obtain and abuse credentials of a cloud account as a means of gaining Initial Access, Persistence, Privilege Escalation, or Defense Evasion. Cloud accounts are those created and configured by an organization for use by users, remote support, services, or for administration of resources within a cloud service provider or SaaS application. In some cases, cloud accounts may be federated with traditional identity management system, such as Window Active Directory. Compromised credentials for cloud accounts can be used to harvest sensitive data from online storage accounts and databases. Access to cloud accounts can also be abused to gain Initial Access to a network by abusing a Trusted Relationship. Similar to Domain Accounts, compromise of federated cloud accounts may allow adversaries to more easily move laterally within an environment. Once a cloud account is compromised, an adversary may perform Account Manipulation - for example, by adding Additional Cloud Roles - to maintain persistence and potentially escalate their privileges.
User accounts with assigned "Hybrid Identity administrators" roles have enhanced permissions for ’sync service features’ but also, extensive management permissions for service principals and app registrations in Azure AD which includes Account Manipulation - T1098 Adversaries may manipulate accounts to maintain access to victim systems. Account manipulation may consist of any action that preserves adversary access to a compromised account, such as modifying credentials or permission groups. These actions could also include account activity designed to subvert security policies, such as performing iterative password updates to bypass password duration policies and preserve the life of compromised credentials. In order to create or manipulate accounts, the adversary must already have sufficient permissions on systems or the domain. However, account manipulation may also lead to privilege escalation where modifications grant access to additional roles, permissions, or higher-privileged Valid Accounts.
Temporary Access Pass can be used by compromised high-privileged accounts or service accounts to create a backdoor on "On-Premises Directory Synchronization Service Account Account Manipulation: Additional Cloud Credentials - T1098.001 Adversaries may add adversary-controlled credentials to a cloud account to maintain persistent access to victim accounts and instances within the environment. Adversaries may add credentials for Service Principals and Applications in addition to existing legitimate credentials in Azure AD. These credentials include both x509 keys and passwords.With sufficient permissions, there are a variety of ways to add credentials including the Azure Portal, Azure command line interface, and Azure or Az PowerShell modules.
Directory role permissions allow to change of ownership of the "GraphAggregatorService" service principal and add app roles to self-grant arbitrary Microsoft Graph API permission. Account Manipulation: Additional Cloud Roles - T1098.003 An adversary may add additional roles or permissions to an adversary-controlled cloud account to maintain persistent access to a tenant. For example, they may update IAM policies in cloud-based environments or add a new global administrator in Office 365 environments. With sufficient permissions, a compromised account can gain almost unlimited access to data and settings (including the ability to reset the passwords of other admins). This account modification may immediately follow Create Account or other malicious account activity. Adversaries may also modify an existing Valid Accounts that they have compromised. This could lead to privilege escalation, particularly if the roles added allow for lateral movement to additional accounts. For example, in Azure AD environments, an adversary with the Application Administrator role can add Additional Cloud Credentials to their application's service principal. In doing so the adversary would be able to gain the service principal’s roles and permissions, which may be different from those of the Application Administrator.
Refresh/access token from an account with assigned directory role "Hybrid Identity Administrator" can be replayed when it will be used to apply AADC configuration changes. Members of this role could be excluded from device compliance to allow usage of AAD Connect Server for management tasks Steal Application Access Token - T1528 Adversaries can steal application access tokens as a means of acquiring credentials to access remote systems and resources. Application access tokens are used to make authorized API requests on behalf of a user or service and are commonly used as a way to access resources in cloud and container-based applications and software-as-a-service (SaaS). OAuth is one commonly implemented framework that issues tokens to users for access to systems. Adversaries who steal account API tokens in cloud and containerized environments may be able to access data and perform actions with the permissions of these accounts, which can lead to privilege escalation and further compromise of the environment.

Detections

On the detections side, we are focusing on available Microsoft cloud-based security solutions: Starting from the source of the attack, Azure AD Connect server, which is located on-premises, and moving to cloud-based security solutions.

You can expect to find the tools used in the following scenarios in this chapter:

  • Microsoft Defender for Endpoint (MDE) on AAD Connect for detecting suspicious activities or tools on the operating system level and on-premises environment.
  • Microsoft Defender for Cloud Apps (MDCA) and Microsoft Sentinel for detecting suspicious sign-in and audit activities of the AAD Connector Account but also Hybrid Identity Admin.
  • Microsoft Sentinel takes essential part for advanced detection by using WatchList and anomaly techniques.
  • Azure AD Identity Protection (IPC) detection is valuable if interactive (and suspicious/unfamiliar) sign-in has been attempted by Azure AD connector account.

In our templates of Microsoft Sentinel analytics rule, we’re using WatchLists to enrich and store information for correlation centrally. WatchList template for "High-Value Assets" should be used to define "AAD Connect Servers" and the assigned public IP address.

Valid and authorized Azure AD connector accounts should be included in the "Service Accounts" WatchList template. This helps us to identify user accounts with assigned "Directory Synchronization" or similar account names which aren't whitelisted as part of the WatchList.

Both lists are using the same tag (Azure AD Connect) to identify related resources to the AADC operations and activities. These Watchlists are an important part and pre-requisite for the custom analytics rules which we have written for this playbook.

UEBA tables is another feature which will be included in one of the queries. We're using IdentityInfo table to identify user accounts with directory role assignment to "Hybrid Identity Administrator". Related Azure AD connector accounts can be also identified by directory role assignment ("Directory Synchronization Accounts") which is also stored in "IdentityInfo".

Threat signals by using offensive tools on AADC servers

If Microsoft Defender for Endpoint (MDE) is installed to AAD Connect server, EDR can detect suspicious activities from the instance. For example, when AADInternals is used to dump Azure AD Connect credentials the activity is detected by MDE.

Dumping credentials with AADInternals

Updating credentials with AADInternals

MDE will be able to detect access or updates to credentials of ADSync or Azure AD connector (by using AADInternals):

Side note: If you are not protecting AADC server(s) by MDE, activities of tools (such as AADInternals) can be detected based on a event in Windows Event logs which can be used for custom detections.. More information about detection options of credentials dump are described in the blog post "Shooting Up: On-Prem to Cloud" by imp hash.

Changes of AAD Connect sync features

Global and Hybrid Identity Administrators are able to change sync features of Azure AD Connect. This includes the attack scenario to enable "hard" and "soft" matching to takeover of cloud-only accounts. Current configuration can be displayed by using "Get-MsolDirSyncFeature":

The attacker needs to use "Set-MsolDirSyncFeature" cmdlet from the MSOL PowerShell module. This activity creates an audit log in Azure AD:

Microsoft Sentinel Analytics rule "Disabled soft- or hard match of Azure AD Connect sync" allows to create incidents if a identity synchronization features has been modified. The old and new value (in the audit log entry) is summed integer of all DirSync feature settings which includes "BlockSoftMatch" or "BlockCloudObjectTakeoverThroughHardMatch" but also other important settings such as enable/disable "Password Hash Sync"

Suspicious activities from Azure AD connector account

Suspicious AD sign-ins and audit events from AD DS connector service account can be detected by Microsoft Sentinel. As already described, we're using WatchLists to identify valid AADC servers (based on name/IP address) and also Azure AD connector accounts (based on Azure AD ObjectId).

Assignments and activities of "Directory Synchronization" role members can be sourced from the IdentityInfo table. In addition, we're using the standard naming pattern (sync_@.onmicrosoft.com) of Azure AD connector accounts to find similar named objects. Both sources will be used in the analytics rule "Azure AD connector accounts outside of WatchLists" to detect any accounts which aren't whitelisted and seems to be suspicous accounts or an indicator for outdated watchlist content.

Our next analytics rule "Sign-in from Azure AD connector account outside of AADC Server" is written to detect sign-ins outside of a named public IP addresses. We're using "AccountObject ID" from the "Service Accounts" watchlist to detect any sign-ins outside of the named IP address which is defined in the "High Value Asses" watchlist. Furthermore, we're covering all sign-ins to the "AAD Connect Endpoints" (Azure AD Sync and AAD Connect V2) to detect sign-ins that doesn't match with the WatchList.

The hunting query "Activities from AAD connector account with enrichment of IdentityInfo" can be used for further investigation of changes which was made by the whitelisted AAD connector account. It allows to find "take over" or synchronization to user objects with sensitive group membership or assigned AAD roles. This query is also useful to find anomaly of object changes.

In addition to the custom analytics rules, the following signals or queries could be used to identify suspicious events:

  • Insights from "BehaviourAnalytics" from Microsoft Sentinel's UEBA. This also includes events if firstpeer IP addresses or rare operations has been detected.
  • Any kind of risk events of Azure AD connector account (by Identity Protection) should be reviewed. Trigger incidents for those kind of events by using the AADRiskyUsers and AADUserRiskEvents tables.
  • Any password change and user modification to the "AAD Sync Service Account" should be also reviewed

Takeover Azure AD connector by generating Temporary access pass (TAP) as backdoor

High-privileged role administrators (such as Global Admin) could be a TAP to use Azure AD connector account with any noise or service interruption (compare to password change).

Analytics rule "Added temporary access pass or changed password of Azure AD connector account" is looking for security information (of TAP) and password change event. AAD connector accounts will be identified by IdentityInfo table (assignment to "Directory Synchronization Accounts" role) and name pattern.

Password Spray attacks to Azure AD connector account

Attackers could try to gain credentials of the account by using a "Password Spray Attack". This attack allows also to enforce (Smart) lockout which will end in stopping AADC synchronization if the source of attack and AADC seerver are sharing the same public IP address (e.g. common outbound public IP of on-premises environment).

If AAD Connect service account is hammered by password spray attack, "Microsoft Defender for Cloud Apps (MDCA)" is able to detect such activity:

More information about detecting password spray attacks can be found from this playbook chapter.

Mitigations

Increase visibility by implementing detections

Secure your AAD Connect Server and Service Accounts as Tier0

  • Protect your AADC as Tier0 system which is part of your "control plane" on-premises and in the cloud

    • Verify every asset with direct or indirect management access (incl. GPO, delegated permissions on OU, installed agents or open admin interfaces)
    • Verify your options for backup (use a full encrypted and secure way to isolate the backup, otherwise export configuration on a regular basis to restore without backup)

  • Follow Microsoft’s best practices to "harden" AADC server implementation

  • Lock down and disable permission inheritance for all AADC service accounts

    "Suppose there is a malicious on-premises AD administrator with limited access to Customer’s on-premises AD but has Reset-Password permission to the AD DS account. The malicious administrator can reset the password of the AD DS account to a known password value. This in turn allows the malicious administrator to gain unauthorized, privileged access to the Customer ’s on-premises AD"

  • Rotate credentials of all non-managed service accounts regularly

  • Limit your scope on synchronizing AD objects to Azure AD (exclude Tier0 assets incl. AADC related resources)

    • Delegate permissions to AD DS connector account to scoped OUs only

Reduce attack surface for AAD Connect resources

  • Avoid unpatched version of AAD connect server (track patch/versions by vulnerability management solution) and minimize installed agents which allows local exploit
  • Use local SQL if you aren’t able to use a protected/dedicated Tier0 SQL server
  • Remove unnecessary and unused "On-Premises Directory Synchronization Service Account" or "DirSync" account (assigned Global Admin roles) which can be abused by reset password and trigger sync operations
  • Disable Seamless SSO if you haven’t a particular use case or requirement for that
  • Evaluate "AAD Connect Cloud Synchronization" as alternate solution if the included features fit to your requirement. This allows to reduce risk dependencies and attack surface of AAD connect sync components in your on-premises environment.

Protect your cloud-only and privileged accounts from account take over

Disable "Soft match" and "Hard match" (for CloudOnly Accounts) by using "Set-MsolDirSyncFeature" cmdlets:

  • Set-MsolDirSyncFeature -Feature BlockCloudObjectTakeoverThroughHardMatch -Enable $true
  • Set-MsolDirSyncFeature -Feature BlockSoftMatch -Enable $true

Monitor any changes to these feature configurations, as we have shown in the detection section. Overall monitoring of changing "DirSync" feature configuration should be considered to see changes in other areas as well (such as disable password hash sync).

Include AAD Connect assets in Conditional Access Design to restrict and avoid attack surface:

  • As already shown, "Password Spray Attacks" on "On-Premises Directory Synchronization Service Account" allows to block synchronization from on-premises to Azure AD. This could avoid sychronization of security-related lifecycle updates (e.g. disable account of leaved employees)
  • Running AAD connect with dedicated public IP address allows to restrict access of "Azure AD connector account" based on IP addresses in Conditional Access. This avoid to have running password spray attack from a shared IP address range with other (on-premises) resources.
  • Use a dedicated CA policy that allows the sync account login from this certain IP address only:

    • Access to AAD Connect (API) endpoint ("Microsoft Azure Active Directory Connect") cannot be targeted as Cloud App. Therefore, CA policy must be target on "All Cloud Apps" for directory role members of "Directory Synchronization Accounts" and "Hybrid Identity Administrators" (if needed):

If authentication is allowed only from certain IP-addresses access, Conditional Access will block the authentication requests. We often see that the "AADC service account" is just excluded from the policies but we would rather recommend creating a separate policy for the service accounts as mentioned above.

Security Insights from Azure AD Connect Server

This chapter contains information about the "Azure AD Connect" server related security monitoring activities that can be established and also insights about Azure AD Connect Health. The latter one provides Azure AD Connect monitoring and performance data to Azure AD.

Local application and system events from Azure AD Connect (Server)

Information from activities inside the Azure AD Connect server is logged to Windows Event logs. Most of the AADC-related activities are found from the "Application log".

These events can be sent to Microsoft Sentinel and underlying Azure Log Analytics workspace (or 3rd party SIEM) when needed. If Microsoft Sentinel is used in the environment there are two options to send the Windows Events:

  • Microsoft Monitoring Agent (MMA) also known as Azure Log Analytics agent
  • Azure Monitoring Agent (AMA) through Azure Arc

Both agents obviously have pros and cons but we are not focusing on the agent capabilities in this playbook. Taking that into account, if you would like to have more information about the agent capabilities, we suggest starting with the Microsoft documentation:

Side note: Consider sending AADC events (at minimum from the application log) to your application log management solution (this could also include Microsoft Sentinel). AAD Connect produces great operational level logs and also exports configuration change every time change is made by ‘AAD Connect’ from version 1.5.30.0 onwards. This configuration export can be used to restore the whole service when needed.

- Only changes made by Azure AD Connect are automatically exported. - Any changes made by using PowerShell, the Synchronization Service Manager, or the Synchronization Rules Editor must be exported on demand as needed to maintain an up-to-date copy. Export on demand can also be used to place a copy of the settings in a secure location for disaster recovery purposes.

- If you are using Windows Sysinternals tool ‘Sysmon’ to collect events from your AADC Server these events can be sent to Log Analytics as a custom log. More information from - How to deploy Sysmon and MMA Agent to receive logs in Azure Sentinel? | Microsoft 365 Security (m365internals.com)

Removing AAD Sync Server(s) from AAD Connect Health

AAD Connect Health provides agent provides health information from AADC service and sends that information to Azure AD. The information is available in the dedicated AAD Connect Health blade in the Azure AD portal.

If the attacker wants to hide health events from the AADC server he/she might want to delete AADC servers from the portal. When deleted, there isn’t any event from the actual deletion process found from the Azure AD audit logs.

The event from the deletion can be found from Microsoft Defender for Cloud Apps (MDCA) as in many similar use cases.

Other references and resources