Authentication has changed dramatically over the past decade. Not long ago, attackers focused primarily on stealing usernames and passwords because that was all they needed to gain access to an environment. As organizations adopted Multi-Factor Authentication (MFA), Conditional Access, passwordless authentication, and stronger identity controls, compromising an account became significantly more difficult. Microsoft 365 and Microsoft Entra ID have played a major role in driving that improvement, making traditional password-based attacks far less successful than they once were.

Unfortunately, attackers adapted just as quickly.

Rather than attempting to defeat authentication itself, many threat actors now focus on what happens after authentication has already succeeded. Once a user has entered their password, completed Multi-Factor Authentication, and successfully signed into Microsoft 365, Microsoft Entra ID issues a series of tokens that allow the user to continue working without repeatedly authenticating. Those tokens become the new target. If an attacker can steal and replay them before they expire or are revoked, they can often gain access to Microsoft 365 services without ever knowing the user’s password or triggering another MFA challenge.

This represents an important shift in how we think about identity security. MFA remains one of the most effective security controls available and should continue to be deployed everywhere possible. The issue is not that MFA is broken. The issue is that authentication is only one stage of the overall identity lifecycle. Once a user has successfully authenticated, the authenticated session itself becomes an asset that attackers actively target.

For organizations built around Microsoft 365, this has significant implications. Administrative tasks are increasingly performed through cloud services such as Exchange Online, Microsoft Entra ID, SharePoint Online, Microsoft Teams, Microsoft Graph, and Azure. Almost every one of these services exposes extensive management capabilities through PowerShell. If an attacker successfully compromises an authenticated administrative session, PowerShell quickly becomes one of the most valuable tools available for expanding access, maintaining persistence, and performing administrative actions across the environment.

Understanding how these attacks work is therefore only half of the challenge. The other half is reducing what an attacker can actually do after authentication has already been compromised.

Authentication Doesn’t End With MFA

When a user signs into Microsoft 365, the authentication process involves considerably more than simply validating a username and password. Microsoft Entra ID evaluates the user’s credentials, applies Conditional Access policies, verifies device compliance where required, and prompts for Multi-Factor Authentication if the organization’s policies require it. Once those requirements have been satisfied, Microsoft issues a collection of authentication tokens that allow the user to continue interacting with Microsoft 365 services without repeatedly signing in.

These tokens exist for a very practical reason. Imagine having to complete Multi-Factor Authentication every time Outlook refreshed your mailbox, every time Teams loaded a conversation, or every time SharePoint retrieved a document. Modern cloud services rely on authentication tokens to provide a seamless user experience while maintaining security behind the scenes.

The important point is that these tokens represent proof that the authentication process has already taken place. Microsoft no longer needs to challenge the user because the token itself demonstrates that the required authentication requirements were previously satisfied. As long as that token remains valid, Microsoft trusts the authenticated session.

From a usability perspective, this works extremely well.

From a security perspective, however, those tokens become highly valuable. Rather than attempting to defeat Microsoft’s authentication process, attackers simply attempt to steal the evidence that authentication has already occurred.

Understanding Session Token Theft

Session token theft is often misunderstood because it is frequently described as “bypassing MFA.” In reality, Multi-Factor Authentication has usually worked exactly as designed. The user authenticated successfully, completed the required MFA challenge, and Microsoft correctly issued an authenticated session.

The attacker simply steals that session.

The process itself is surprisingly straightforward. A compromised endpoint, malicious browser extension, information-stealing malware, or Adversary-in-the-Middle phishing attack captures the browser cookies or authentication tokens associated with the user’s Microsoft 365 session. Those tokens are then imported into another browser under the attacker’s control. When that browser connects to Microsoft 365, the existing authentication token is presented to Microsoft Entra ID, which recognizes it as a valid session and allows access without requiring another sign-in.

  • No password is entered.
  • No Multi-Factor Authentication prompt appears.
  • No authentication challenge occurs because Microsoft believes the user has already completed that process.

This distinction is important because it fundamentally changes the security boundary. Organizations often spend considerable effort protecting usernames, passwords, and MFA methods, yet the authenticated session itself may receive far less attention. Once authentication has completed successfully, the session effectively becomes the new credential.

Why Browser Cookies Have Become So Valuable

Modern browsers are designed to improve the user experience by securely storing authentication information that allows users to remain signed in across multiple Microsoft services. As users move between Outlook, SharePoint, Teams, OneDrive, Exchange Online, and countless other cloud applications, those cookies allow Microsoft to recognize the authenticated session without repeatedly prompting for credentials. Attackers understand this extremely well.

Modern information-stealing malware rarely focuses exclusively on passwords anymore. Instead, many malware families specifically target browser profiles because they contain everything needed to recreate a user’s online identity. Session cookies, authentication tokens, browser profiles, saved credentials, autofill information, and cached authentication artifacts all become valuable because together they allow an attacker to rebuild an authenticated browsing session.

This is one of the reasons endpoint security has become such a critical part of identity protection.

Organizations often focus heavily on Microsoft Entra ID, Conditional Access, and identity governance while overlooking the fact that an infected endpoint may already contain everything an attacker needs to access cloud services.

Protecting the identity provider alone is no longer sufficient if the authenticated session can simply be copied from the user’s device.

The Evolution of Modern Attacks

Early attacks typically relied on malware installed directly on the endpoint to extract browser cookies after the user had already authenticated. While this technique continues to be used, more sophisticated attacks have evolved considerably. One of the most significant developments has been the rise of Adversary-in-the-Middle (AiTM) phishing frameworks such as Evilginx. Rather than stealing browser cookies from an infected endpoint, these attacks intercept the authentication process itself.

The victim receives what appears to be a legitimate Microsoft 365 sign-in page. Behind the scenes, however, the attacker is proxying the entire authentication session between the victim and Microsoft. The user enters their credentials, successfully completes Multi-Factor Authentication, and is redirected into the genuine Microsoft application. From their perspective, everything appears completely normal. The attacker, however, captures the authenticated session token immediately after Microsoft issues it.

Unlike traditional phishing attacks that attempt to steal passwords, AiTM attacks capture the authenticated session itself. The attacker never needs to know the user’s password again because they already possess proof that the authentication process has completed successfully.

This explains why organizations are increasingly investing in phishing-resistant authentication technologies such as FIDO2 security keys and passkeys. These approaches significantly reduce the effectiveness of credential interception attacks because the authentication process becomes cryptographically bound to the legitimate Microsoft domain rather than simply validating credentials that can be replayed elsewhere.

Why PowerShell Becomes the Next Target

Successfully stealing a Microsoft 365 session is rarely the attacker’s end goal. Access to email, documents, and collaboration platforms certainly provides valuable intelligence, but most attackers are ultimately looking for something far more powerful. They want administrative access that allows them to expand their control, establish persistence, manipulate the environment, or move laterally into additional systems.

For organizations built around Microsoft technologies, PowerShell often becomes the tool that enables those objectives.

PowerShell has become the management interface for almost every major Microsoft platform. Administrators use it daily to manage Exchange Online, Microsoft Entra ID, Microsoft Teams, SharePoint Online, Microsoft Graph, Azure, Windows Server, Active Directory, and countless third-party products. It provides consistency, automation, and scalability that simply cannot be achieved through graphical administration tools alone.

Those same advantages also make PowerShell extremely attractive to attackers.

Unlike traditional malware, PowerShell is already trusted by the operating system. It does not require an attacker to install additional software, exploit vulnerabilities, or bypass application control in many environments. If an attacker has obtained a legitimate administrative session, they can often use the same management tools as the administrator they have compromised. This is one of the reasons PowerShell is frequently associated with “living off the land” attacks, where adversaries deliberately use legitimate administrative tools to avoid detection.

Consider what a compromised Microsoft 365 Global Administrator account could potentially access through PowerShell. Depending on the organization’s configuration, that account may be capable of reading Exchange Online mailboxes, modifying Microsoft Entra ID users and groups, assigning administrative roles, creating application registrations, changing Conditional Access policies, modifying SharePoint Online permissions, interacting with Microsoft Graph, or automating administrative tasks across the tenant. None of these activities require malicious software. They simply require authenticated administrative access.

This is where traditional authentication controls begin to reach their limits. Once the attacker has successfully authenticated using a stolen session token, Microsoft 365 has already established their identity. From that point forward, the focus shifts away from authentication and towards authorization.

Authentication Does Not Equal Authorization

One of the most common misconceptions in enterprise security is that successfully authenticating a user automatically means they should have unrestricted access to everything their account can perform. In reality, authentication and authorization solve two very different problems.

  • Authentication answers a relatively simple question: Who is this user?
  • Authorization answers a much more important question: What should this user actually be allowed to do?

This distinction becomes particularly important when dealing with privileged administrative accounts. Many organizations still assign broad administrative permissions to users because it simplifies administration. An Exchange administrator may receive Exchange Administrator rights across the tenant. A SharePoint administrator may receive unrestricted access to SharePoint Online. A helpdesk technician may receive permissions that extend well beyond the tasks they perform on a daily basis. Under normal circumstances, those permissions are exercised responsibly by trusted administrators. During a session hijacking attack, however, the attacker inherits exactly the same capabilities.

From the attacker’s perspective, the compromised account is simply another administrative tool. If the account can execute PowerShell commands, assign permissions, create application registrations, or retrieve sensitive data, then those capabilities become available to the attacker as well.

The challenge therefore becomes limiting what an authenticated administrative session can actually accomplish after authentication has already succeeded.

Why Traditional Administrative Models Create Risk

Historically, privileged administration has often been built around standing administrative permissions. An administrator is assigned a privileged role and retains that level of access until the role is removed. Whenever they open PowerShell or connect to an administrative service, they immediately receive the full capabilities associated with that account.

While this approach is straightforward, it also creates a significant attack surface.

If the administrative account becomes compromised through phishing, session token theft, malware, or another identity attack, the attacker immediately inherits every permission associated with that account. There is no distinction between routine administrative work and high-risk privileged operations because the account always possesses both. Modern identity security has increasingly moved away from this approach.

Technologies such as Privileged Identity Management (PIM), Just-In-Time administration (JIT), and Conditional Access all attempt to reduce standing privilege by ensuring administrative access is only available when genuinely required.

PowerShell Just Enough Administration (JEA) takes that same philosophy one step further.

Instead of simply controlling who can access an administrative session, JEA controls what can actually be executed once that session has been established.

Defense-in-Depth Assumes Compromise

One of the most important principles in modern cybersecurity is that no single security control should ever be trusted to stop every attack. Organizations deploy Multi-Factor Authentication because passwords alone are insufficient.

  • They implement Conditional Access because MFA alone is insufficient.
  • They secure endpoints because identity controls alone are insufficient.
  • The same principle applies to administrative access.

PowerShell Just Enough Administration should not be viewed as a replacement for strong authentication, phishing-resistant credentials, Conditional Access, or endpoint protection. Instead, it becomes another layer within a broader defense-in-depth strategy.

Imagine a scenario where an attacker successfully steals an authenticated Microsoft 365 session through an Adversary-in-the-Middle phishing attack. They authenticate to Exchange Online using the stolen session and open a PowerShell connection using the victim’s existing administrative permissions.

  • Without additional controls, that attacker may have unrestricted administrative capability.
  • With JEA, the same authenticated session may be limited to only a small subset of approved PowerShell cmdlets that support the administrator’s day-to-day responsibilities.
  • The attacker still possesses an authenticated session.
  • They simply no longer possess unrestricted administrative capability.

That distinction dramatically reduces the potential impact of the compromise.

Looking Beyond Identity

Microsoft has invested heavily in strengthening identity security over recent years through Microsoft Entra ID, Conditional Access, Continuous Access Evaluation, phishing-resistant authentication, Identity Protection, and Privileged Identity Management. Together, these technologies significantly reduce the likelihood of successful identity attacks. However, identity is only one component of the overall security architecture.

Organizations must also consider what happens after authentication succeeds. Administrative authorization, least privilege, endpoint security, application control, and continuous monitoring all become equally important once an attacker has obtained an authenticated session.

PowerShell Just Enough Administration addresses one of the final gaps in that architecture by restricting what administrators are allowed to execute rather than assuming every authenticated administrative session should automatically receive unrestricted access.

In a future post, we’ll take a detailed look at how PowerShell Just Enough Administration works, how session configurations and role capability files combine to create highly restricted administrative endpoints, and why JEA remains one of the most effective ways to reduce the impact of compromised administrative credentials in Windows Server and hybrid Microsoft environments.