Hijacking Azure PowerShell Authentication Flow

While looking into some interesting Azure attacks I came upon something interesting when using the Connect-AzAccount

Connect-AzAccount

Now noticing the PowerShell opens a port when using the Connect -AzAccount, I wonder what was it used for, when opening the port, I dived a little more into this and stumbled upon a previous method for CAP Bypass from Github https://github.com/zh54321/PoCEntraDeviceComplianceBypass

Now according to the information from the GitHub repository this URI will now fail

Interesting URI

And interestingly the section that we need to tackle is this parameter code

Parameter

In Azure, you often deal with two main types of tokens:

• Access Tokens: Tokens that let you call Azure APIs. They usually start with eyJ0....

• Refresh Tokens: Tokens that let you get new Access Tokens without logging in again. They usually start with 1.Abc....

When looking at token formats, I noticed something interesting: A token that looked like a Refresh Token but was smaller. This was actually an authorization code.

So for what I had now, this means that:

• I had an authorization code.

• Azure PowerShell uses this flow. It relies on a known PowerShell ClientID and opens a local web server on port 8400 to catch the tokens after login.

• If that port is busy, the process can fail or it relies on consecutive ports until failure.

Now what I need to replicate is:

1. Log in.

2. Azure sends back an authorization code.

3. PowerShell exchanges that code for a real Access Token and Refresh Token.

4. These tokens then get stored and reused.

The approach I took to capture this information is to hijack or basically terminate the PowerShell process while the authentication is happening, while setting up my own listener that waits for the tokens. Now this approach was the easiest because the authentication flow needs to open the web browser, and the user needs to login, with that we can capture the tokens by terminating the powershell process and listening on the port ourselves, now I was thinking about a scenario of "what if SSO was enabled and the web browser was already running" the authentication was going to be faster.

This wasn’t really a blocker. I decided to use C# for the tool since it's easy for using it as an Initial Access payload as well that handles the authentication flow and captures the tokens. I also added a functionality to forward the Access and Refresh Tokens to a server I control. Since this is all happening through a normal login in a trusted environment, it can be used without worrying of Conditional Access Policies.

Now at first, I couldn’t fully capture the authentication because of the code_verifier (part of the PKCE flow) that was hidden by the client. Luckily, it turns out we can generate our own code_verifier and feed it into the flow to make the attack work.

With this in place, the payload is now functional. It replicates the same login process used by Connect-AzAccount:

• It opens the browser for login.

• It listens on the default redirect URI port (8400).

• Once the user signs in (either with credentials or via SSO which is automatically), the tool captures both the Access and Refresh Tokens.

The code for the project can be found here: https://github.com/init1Security/GrabTokenAzureAD

Demo