The complexity of modern IT landscapes becomes particularly apparent in the event of emergencies caused by cyberattacks. It is not just the recovery of the individual subsystems that needs to be considered when you restore, but also the interactions. The failure of basic services such as authentication as the result of an attack is a particularly serious worry.

Regardless of whether a company still has its IT firmly anchored locally or is already on its way into the cloud, most directory services now have a hybrid design. The legacy Active Directory (AD) is the primary identity store, and users, groups, and, increasingly, computer accounts are synchronized to Entra ID (formerly Azure AD) or other cloud-based directories to enable seamless access to applications in the cloud. The prime example is Microsoft Teams, which many companies were forced to introduce as an emergency measure during the pandemic. However, other services such as virtual private networks (VPNs), Microsoft Dynamics 365, Salesforce, or Box also work best with a cloud identity.

Hybrid Identities on the Rise

How tightly the on-premises part of a hybrid identity is tied in to its cloud counterpart can vary. Some organizations want to provide an online identity but keep the authentication process entirely on-premises and rely on pass-through authentication (PTA) or locally installed instances of Active Directory Federation Services (ADFS). Others synchronize the password hash to the cloud (password hash synchronization, PHS) or even make the cloud account authoritative with password write-back, enabling more extensive password checks than the complexity conditions supported in AD and providing users with a simple self-service password reset (SSPR). Thanks to Cloud Trust, even Kerberos authentication of a cloud account against local resources connected to AD is possible.

All types of hybrid identity are relatively easy to set up, and the providers supply both technical aids and very good instructions. Microsoft has a particular interest in migrating identities to its own cloud as quickly and painlessly as possible; the new privileged access strategy envisages the cloud as the "source of security" [1]. However, the successful cyberattacks of recent years all too clearly reveal the weaknesses of the strategy. On the one hand, both components – on premises and in the cloud – are required in a hybrid identity landscape to enable smooth operation of all applications. On the other hand, the relationship between the legacy identity and the modern identity creates completely new attack vectors that exploit the peculiarities and functional weaknesses of both sides.

Many Roads Lead to Disaster

A hybrid identity system can be attacked in many ways and be completely or partially disabled. The measures you need to take to get the system operational again are just as varied.

A classic attack scenario focuses on the local part of the organization. The attacker typically takes complete control of AD, ultimately to destroy it. This positioning also opens the cloud component attack, because by taking over the traditional AD, the attacker also gains control of Azure AD Connect or Cloud Sync agents and can escalate into the cloud (Figure 1).

Figure 1: Azure AD Connect is considered active even though the local AD has been compromised.

However, if the attacker discovers during their investigations that the cloud services are only in rudimentary use (e.g., video telephony in Teams), they will typically not waste time compromising these services and simply encrypt or destroy the applications and data operated onsite. Your cloud tenant may be spared to a great extent.

Now, though, you face a different challenge. Because AD is the leading identity store on the hybrid network, users and groups are available in the cloud but cannot be managed there. If you enabled PHS, users can even log in to cloud services with the last known password, but you cannot change the password if password write-back, SSPR, or both have not also been enabled. On the other hand, if you rely on PTA or ADFS, your cloud users will no longer be able to log in because the primary authentication systems are no longer available. For this reason, both Microsoft and most experts recommend enabling PHS – at least as an additional authentication procedure. The frequently cited angst prompted by synchronizing passwords with the cloud is unfounded, because hashing more than 1,000 times makes it uneconomical to reconstruct the plain text password in a reasonable time, even if relatively weak passwords are in use.

In known attacks, hackers have reset the passwords of all synchronized users as a last resort before destroying AD and Azure AD Connect. Although the data in the cloud applications are still intact, access is severely restricted or not possible at all for the time being.

In other, more complex scenarios, the attacker first penetrates the cloud by phishing or manipulating the multifactor authentication (MFA) procedures and only then discovers that a synchronized AD account they have hijacked has far-reaching authorizations. In this way, they can obtain an identity that allows them to compromise the cloud tenant or at least steal data such as email, documents, or chat histories from cloud applications to later phish other users (CEO fraud) or threaten to damage the company's image and extort money.

While you are restoring the on-premises infrastructure, you need to make sure your cloud services no longer offer the attacker a gateway before you reconnect the two parts of the hybrid environment.

Graph PowerShell Is the Future

Although the MSOnline and AzureAD PowerShell modules are still available and largely supported at press time, the date for shutting down the service endpoint these modules reference has already been set. Some initial functions have even been disabled; you will find many references to this with an online search. Therefore, this article focuses on the cmdlets from the Microsoft Graph Suite [2], which will be the only PowerShell interface to Microsoft 365, and in particular to Entra ID, supported in the future.

The Graph modules come with an extremely large number of cmdlets. If possible, you will want to use PowerShell 7 to work with Graph PowerShell. Even there, importing the entire Graph module, including all the dependencies, takes several minutes and bumps up the RAM utilization of the PowerShell session to somewhere between 2 and 5GB. If you already have experience with Graph, it is a good idea to load only the modules you really need. For basic Entra ID tasks, for example, you only require two submodules, and you can quickly set these up by typing:

Import-Module Microsoft.Graph.Authentication,Microsoft.Graph.Identity.DirectoryManagement

If you rely on PowerShell 5.1 and want to load many Graph modules or even the entire suite, you always need to increase the number of functions available within the session, for example,

$MaximumFunctionCount = 32768

from the default value of 4096 to something far higher, as shown.