Microsoft JSON Web Token Extractor

Microsoft JSON Web Token Extractor

When connecting to Azure using, for example, the PowerShell Az module, a JSON Web Token is created and sometimes stored in plain text on disk and memory. I will show where to find the JSON Web Tokens on disk in this blog post, including a tool I wrote to get JSON Web Tokens from memory that contains the JSON Web Tokens, including those found on disk.

JSON Web Tokens

To securely exchange information between parties, authenticating and authorizing a JSON Web Token is commonly used.

A JSON Web Token encodes any sets of identity claims into a payload, including a header that contains how it is to be signed.

The client authenticates to an Identity Provider, and the Identity Provider creates and signs, using a private key, a JSON Web Token. When the client connects to a service, it provides the signed JSON Web Token. The service validates the token using the public key of the Identity Provider and authenticates the client.

Image 1: JSON Web Token Authentication

Let us look at a JSON Web Token example:

Image 2: JSON Web Token example

The encoded part consists of three parts: A header, a payload, and a verify signature. If you tamper with the header or payload, the signature is not valid, and the token becomes invalid.

So, in short, having a valid JSON Web Token is the key to the kingdom.


The first and most obvious path to look for JSON Web Tokens is the HistorySavePath.

HistorySavePath is a setting that saves all PowerShell console history. When a user or admin connects to Azure using PowerShell, the command is stored to file in plain text.

Image 3: HistorySavePath
Image 4: Logging saved to file

Note: Since HistorySavePath loads when PowerShell starts, “Microsoft JSON Web Token Extractor” also displays these tokens.

User Profile

Depending on how a user or admin connects to Azure, the following JSON files contains the JSON Web Token in plain text:

Image 5: File location for JSON Web Tokens

Note: Since the JSON files load when PowerShell starts, “Microsoft JSON Web Token Extractor” also displays these tokens.

Script Block Logging

Script Block Logging saves blocks of code as PowerShell executes them. When a user or admin runs the following command in PowerShell and Script Block Logging is enabled, the event viewer contains the JSON Web Token.

Note: Script Block Logging setting is disabled by default but enabled by many companies due to monitoring.

Microsoft JSON Web Token Extractor

A JSON Web Token is created in memory when connecting to Azure using PowerShell using the following command:

I wondered if I could extract the JSON Web Token from memory without dumping anything on disk to avoid a trigger from any Endpoint Detection and Response solution.

The result is a C# tool to extract all JSON Web Tokens found in memory used by PowerShell, including those found on disk.

Image 6: Microsoft JSON Web Token Extractor


My idea was to jump from on-premises to the cloud without dumping the process to disk using standard tools. The token still needs to be valid, and a user or an admin needs to connect to Azure using PowerShell, but if they do, an attacker can connect to the cloud without touching any other device in the network and stay low-profile.

Microsoft Defender for Identity: ADFSDump

Microsoft Defender for Identity: ADFSDump

Microsoft updated Microsoft Defender for Identity to detect the ADFSDump tool’s use, which was the initial tool used in the Solorigate campaign. This blog post will describe what the attack does, including mitigations for the attack. I created a tool to perform the attack for educational purposes.

Active Directory Federation Services Authentication

To understand the attack, we first need to look at how Active Directory Federation Services (AD FS) works. Here is an oversimplified overview of the authentication using AD FS.

Image 1: AD FS Authentication Overview
  1. The user goes to and signs in with the username;
  2. Microsoft recognises the federation and sends a 302 HTTP response code, redirecting the user to the federated AD FS server ;
  3. The user identifies itself using a password on the Web Application Proxy used by AD FS;
  4. The Web Application Proxy sends the request to AD FS;
  5. AD FS authenticates the user by checking Active Directory if the user entered the correct credentials;
  6. AD DS sends the response of the authentication back to the AD FS server;
  7. AD FS signs a token using a token-signing certificate and sends it to the Web Application proxy;
  8. The Web Authentication Proxy sends the signed token to the user;
  9. The user presents the signed token to Microsoft 365 and can log in to the service.

Suppose there is a way to sign your tokens using a private key and token-signing certificate used by AD FS. In that case, you could impersonate the AD FS server and authenticate to federated services by presenting the signed token. Step 1 to 8 is not needed, and you can submit the forged token directly to the federated service. The federated service checks the token with the public key, and with the correct signed private key, the federated service authenticates the user.

The impersonation of an AD FS server is precisely what Doug Bienstock did. Doug Bienstock created a tool to obtain the token-signing certificate and private key to generate forged security tokens. The tool to obtain the token-signing certificate and private key is called ADFSDump. Since release 2.135 of Microsoft Defender for Identity, ADFSDump gets detected.


For educational purposes, I created a tool to dump the private key and certificate and get undetected by Microsoft Defender for Identity. Some key features of my tool are:

  1. The date creation of the private key helps identify which key to use;
  2. The private keys are in the correct format;
  3. Microsoft Defender for Identity does not detect the attack.
Image 2: ADFS Info

Once you have obtained the private key and token-signing certificate, use ADFSSpoof to create the forged token.


The service account used by AD FS contains Service Principal Names. That means the account is vulnerable to Kerberoasting. Be sure the service account includes a strong and generated password, so it is less likely an attacker can brute-force the password.

Looking at the Administrative Tier Model, consider placing AD FS in the tier 0 scope.

An obvious but important one is monitoring. As I mentioned in my top 5, monitoring is crucial in any organization. An attacker needs to go through many steps in the kill chain before the attacker can extract the details. Monitoring should detect an attacker by then.


In my previous blog post, I mentioned that attackers could hop from on-premises to the cloud. The attack described in this blog post is another way for an attacker to jump from on-premises to the cloud. Once the on-premises environment is compromised, the attacker has many possibilities to hop to the cloud. Even though a lot of companies are focussing on the cloud, do not forget the on-premises environment.

Microsoft Defender

Microsoft Defender

Microsoft rebrands its enterprise security solutions to Microsoft Defender. Microsoft Defender is a holistic solution for what is known as Extended Detection and Response. This blog post will explain what is meant by Extended Detection and Response and go through the Microsoft Defender security name changes.

Extended Detection and Response is a solution that provides threat detection across multiple domains rather than the single point of view that Endpoint Detection and Response delivers. Endpoint Detection and Response uses machine learning and behavioral analysis to detect zero-day vulnerabilities looking at the behavior across a single security layer. Extended Detection and Response enables telemetry and behavioral analysis across numerous security layers.

Two Extended Detection and Response products from Microsoft Defender are Microsoft 365 Defender and Azure Defender. Microsoft 365 Defender is not a new product in the family. Microsoft 365 Defender is known as Microsoft Threat Protection. Microsoft 365 Defender uses a single unified portal, cross-domain hunting, for four products: Microsoft Defender for Identity, Microsoft Defender for Endpoint, Microsoft Defender for Office 365, and Microsoft Cloud App Security.

Figure 1: Microsoft Defender – Extended Detection and Response

Here is an example of an Extended Detection and Response incident: Suppose a potential threat identifies in Microsoft Defender for Office 365 as a “Potential phishing attack,” and around the same time, a potential threat is identified on the endpoint by Microsoft Defender for Endpoint. In that case, Microsoft 365 Defender will determine the risk and raise an alert, and creates an incident. The threat is not classified as potential anymore but as an incident due to detection across multiple domains.

Another added value of Extended Detection and Response is aggregation. Multiple threat encounters across various domains aggregates to less and manageable alerts, and those alerts aggregate to less and manageable incidents. Using aggregation, Security Operations Center does not need to go through all threat encounters, but they can focus on the more critical incidents. Using Microsoft 365 Defender makes it possible to execute advanced hunting using Kusto Query Language across multiple domains as well.

Last but not least, a reminder of the name changes within Microsoft Defender.

New product nameOld Product name
Microsoft Defender for IdentityMicrosoft Azure ATP
Microsoft Defender for EndpointMicrosoft Defender ATP
Microsoft Defender for Office 365Microsoft Office 365 ATP
Microsoft 365 DefenderMicrosoft Threat Protection
Azure Defender for ServersAzure Security Center Standard Edition
Azure Defender for IoTAzure Security Center for IoT
Azure Defender for SQLAdvanced Threat Protection for SQL
Microsoft Products Name Changes


Although Microsoft 365 Defender is not new, I like Microsoft 365 Defender as an Extended Detection and Response solution. The aggregation of alerts and advanced hunting makes it possible to get a better and more precise insight within the environment.

I had to get used to the name changes, but I am thrilled that Microsoft changes their products to a simpler naming scheme.