Defending against attacks on Azure AD: Goodbye firewall, hello identity protection

Not too long ago, guarding access to the network was the focal point of defense for security teams. Powerful firewalls ensured that attackers were blocked on the outside while on the inside things might get “squishy,” allowing users fairly free rein within. Those firewalls were the ultimate defense—no one undesirable got access.

Until they did. With the advent of cloud computing, the edge of a network is no longer protected by a firewall. In fact, the network no longer has an edge: in our work-from-anywhere environment in which any data center is now a boundary, we can no longer rely on traditional protection mechanisms. Security has become more about protecting identity rather than the network itself.

Microsoft discussed several of the trends in protecting Azure Active Directory (Azure AD) identity security in a recent blog post that noted many attack sequences now start with the individual in a bid to gain a toehold in the organization and then launch ransomware or other attacks. (You can watch more on key authentication trends by reviewing the videos on the Authenticatecon website.)

Passwords are still security’s Achilles’ heel

As Microsoft Vice President of Identity Security Alex Weinert notes in the above-mentioned blog, passwords are still the Achilles’ heel of security, with three major types of attack sequences in play:

• Password spray: guessing common passwords against many accounts.
• Phishing: convincing someone to type in their credentials at a fake website or in response to a text or email.
• Breach replay: relying on pervasive password reuse to take passwords compromised on one site and try them against others.

Attackers used to go after the weak spots in a network, but now they go after weak spots in authentication and protection. We reuse passwords far too often and attackers know this, so they will take a password from a previously hacked database and attempt to use it in another location. While most password attacks go after those accounts that don’t have multifactor authentication (MFA), more sophisticated attacks are targeting MFA. When they do, the attackers go after the following:

• SIM-jacking and other telephony vulnerabilities.
• MFA hammering or griefing attacks.
• Adversary-in-the-middle attacks, which trick users into performing MFA interaction.

Microsoft: Move away from MFA, protect passwords

To defend against these three attacks, Microsoft recommends that we move away from MFA and increase how we protect passwords. Attackers know we fail too often due to authentication fatigue and can be tricked into entering passwords into sites that mimic our normal authentication platforms.  Password fatigue is one of the reasons that Microsoft is changing the defaults to its authentication application to be a number match rather than merely an authentication “pop” that you have to approve.

An excellent resource discussing the different types of attacks was posted to a recent blog along with remediation techniques. As Microsoft notes, one of the attacks, “pass-the-cookie,” is similar to pass-the-hash or pass-the-ticket attacks in Azure AD. After authentication to Azure AD via a browser, a cookie is created and stored for that session. If an attacker can compromise a device and extract the browser cookies, they can pass that cookie into a separate web browser on another system, bypassing security checkpoints along the way. Users who are accessing corporate resources on personal devices are especially at risk, as those often have weaker security controls than corporate-managed devices and IT staff lack visibility to those devices to determine compromise.

Review who can access your systems

When devising an MFA protection review, it’s important to consider who will have access to which systems and perform hierarchical reviews of your accounts. First, review your users and segment them based on risk and what they have access to; attackers will often target a specific user or someone in their work area. For example, LinkedIn is often used to identify connections between employees at a firm, so you should be aware of these relationships and identify the proper resources to protect key individuals.

Businesses typically deploy computers to satisfy the needs of a job—not based on the risks inherent to a role—rolling out workstations based on budget. But what if you should go back and review your network based on how an attacker sees it? As you know Windows 11 now mandates additional hardware specifically to better protect cloud-based logins. The Trusted platform module is used to better protect and harden credentials used on a machine. But if you have not deployed hardware that can support Windows 11, or, just as importantly, ensured that you are licensed appropriately to obtain the Windows 11 benefits for these key roles, you may not be protecting your network appropriately.

How to defend Azure AD from attacks

Protecting your network from the Azure AD style of attacks starts by ensuring that you have configured settings appropriately. While the authors of a recent post lay out a laundry list of configurations, I’ll start with one that many of us have long struggled with: stop deploying workstations with local administrator rights. Too often we start by assigning a local admin workstation to our builds and then (hopefully) using Local Administrator Password toolkit to assign a random password for each local administrator. We should consider not assigning a local administrator at all, but rather joining the Azure AD directly.

As researchers Sami Lamppu and Thomas Naunheim note, most of the known attacks start by having the workstation have local administrator access. The bottom line is that you should be continuously reviewing and analyzing the additional steps you need to take to protect identity, as it is the new entry point into our modern networks.

Here are some mitigations recommended by the blog authors:

• Create attack surface reduction (ASR) rules in Microsoft Intune to protect the LSAAS process.
• Deploy Microsoft Defender for Endpoint to get automatic alerts if suspicious activities or tools are detected.
• Enable tamper protection to protect your client’s security settings (such as threat protection and real-time AV). Prevent users from taking actions such as disabling virus and threat protection, cloud-delivered protection, or automatic actions against detected threats; turning off behavior monitoring; or removing security intelligence updates.
• Create a device compliance policy to require Microsoft Defender Antimalware and Defender Real-time Protection and immediately enforce the compliance check.
• Require a minimal Machine Risk Score in Device Compliance Policy without a long grace period.
• Use a unique attribute on the device object that will be updated as soon an endpoint is on- or offboarded. This can be used as a dynamic group filter to build an assignment for device compliance policy to require a machine risk score. Otherwise, the device compliance will fail.
• Consideration in Privileged Access Device scenarios, such as Secure Admin Workstation (SAW) or Privileged Access Workstation (PAW): Require the device to be under a “clear” machine risk score. If changes in compliance policies are enforced immediately the changes are valid in a 5min timeframe (based on our tests).
• Actively monitor your endpoints to detect malicious credential theft tools (such as Mimikatz & AADInternals).
• Run a Microsoft Sentinel playbook to “isolate device” if suspicious activity has been detected.

A list of logged-on users on the affected device can be received by calls to the Microsoft 365 Defender API. This should be executed as part of a Microsoft Sentinel Playbook to initialize SOAR actions when offensive identity theft tools have been detected on the endpoint.