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.

HistorySavePath

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

Conclusion

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 Azure AD Conditional Access Validator

Microsoft Azure AD Conditional Access Validator

Conditional Access policies, at their simplest, are if-then statements. If a user wants to access a resource, they must complete an action. Conditional Access contains many settings, and they can complement each other. Conditional Access contains many settings, and they can complement each other. Misconfiguration can take place when having multiple Conditional Access policies, or missing policies can occur. I created a PowerShell script for companies to validate their Conditional Access configuration.

When forcing Multi-Factor Authentication using Conditional Access, some companies forget to create a policy to disable Legacy Authentication, making the environment less secure since Legacy Authentication does not support Multi-Factor Authentication. The PowerShell script gives you an overview of how a user can log in to the environment.

PowerShell Script

The PowerShell script validates the following settings, including Multi-Factor Authentication:

Conditional Access Policy SettingOptionMulti-Factor Authentication
Cloud AppsPowerShellX
Device PlatformAndroidV
Device PlatformiOSV
Device PlatformWindows PhoneV
Device PlatformWindowsV
Device PlatformmacOSV
Device PlatformOtherV
Client AppsExchange Active SyncX
Table 1: PowerShell Script validations
Image 1: CheckAll function
Image 2: CheckLegacyAuth function

Visit my GitHub page for the PowerShell script, and please add any feature requests or issues if there are any.

Conclusion

Configuring Conditional Access can be a challenge. Most companies forget to create a Conditional Access policy to blocks Legacy Authentication when forcing Multi-Factor Authentication or forget to disable “Other” clients when allowing a set of Device Platforms. Using this PowerShell script hopefully helps to validate the Conditional Access policy settings.

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/autologon.microsoftazuread-sso.com’ 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 https://myapps.microsoft.com 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

Conclusion

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 Log Retention Overview

Microsoft Log Retention Overview

For most Microsoft products, data retention is 30 days. However, it depends on some products if you use the free or paid version of the product, and some products do not allow you to change to the retention period at all. To get a clear overview, I created a table with the most common Microsoft products with their retention period.

Microsoft Log Retention

ProductReportMinimumMaximumDefault
Microsoft Azure AD FreeAudit Logs7 days7 days7 days
Microsoft Azure AD FreeSign-in Logs7 days7 days7 days
Microsoft Azure AD FreeAzure MFA Usage30 days30 days30 days
Microsoft Azure AD FreeUsers at risk7 days7 days7 days
Microsoft Azure AD FreeRisky sign-ins7 days7 days7 days
Microsoft Azure AD PremiumAudit Logs30 days30 days30 days
Microsoft Azure AD PremiumSign-in Logs30 days30 days30 days
Microsoft Azure AD PremiumAzure MFA Usage30 days30 days30 days
Microsoft Azure AD Premium P1Users at risk30 days30 days30 days
Microsoft Azure AD Premium P1Risky sign-ins30 days30 days30 days
Microsoft Azure AD Premium P2Users at risk90 days90 days90 days
Microsoft Azure AD Premium P2Risky sign-ins90 days90 days90 days
Microsoft Defender for EndpointData Retention30 days180 days180 days
Microsoft Cloud App SecurityActivity Logs180 days180 days180 days
Microsoft Cloud App SecurityDiscovery Data90 days90 days90 days
Microsoft Cloud App SecurityAlerts180 days180 days180 days
Microsoft Cloud App SecurityGovernance Logs120 days120 days120 days
Microsoft Defender for IdentityAudit Logs90 days90 days90 days
Microsoft Defender for Office 365 P1Real-time Detections30 days30 days30 days
Microsoft Defender for Office 365 P2Threat Explorer30 days30 days30 days
Microsoft Azure Log Analytics FreeData Retention30 days30 days30 days
Microsoft Azure Log Analytics PaidData Retention30 days730 days30 days
Microsoft Office 365Basic Audit Logs90 days90 days90 days
Microsoft Office 365Advanced Audit Logs365 days365 days365 days
Microsoft Office 365Message Trace90 days90 days90 days
Table 1: Microsoft Log Retention Overview

Conclusion

Not all products allow you to change the retention period, and some products come with an additional cost when changing the retention period. However, this is not always the case. When a Log Analytics Workspace is attached to Sentinel, data retention if free for 90 days.

Suppose you want to extend the retention period longer than the maximum period. In that case, you need to send the logs to a Security Information and Event Management (SIEM) solution or send it to an Azure Log Analytics workspace if the product supports it.

Microsoft Azure AD Premium

Microsoft Azure AD Premium

Every Microsoft 365 tenant contains an Azure AD free edition. The free version includes Core Identity and Access Management, and Business to Business Collaboration. Even though the free edition comes with many features like Multi-Factor Authentication (MFA), Password Protection, Azure AD Connect sync, and Single Sign-On (SSO), Microsoft offers two additional plans called Azure AD Premium P1 and P2.

This article will explain the differences between the two and take a more in-depth look into Azure AD Premium.

Azure AD Premium Features

The difference between Azure AD Premium P1 and P2 is Identity Protection and Identity Governance. But before we look at the features of Identity Protection and Identity Governance, let’s take a look at the premium features first.

The free version contains Password Protection, but it is not possible to use custom banned passwords. Custom banned passwords is one of the premium features. You can set a list of passwords that users cannot use as their password. Simple passwords like “Company Name” is not allowed. Password Protection for Windows Server Active Directory does the same as Password Protection, but for on-premises.

Self-service password reset eliminates the users to call the ServiceDesk to change their password. The user can change their password on a portal that does not need any support from the company. Azure AD Join makes it possible to auto-enroll your mobile device.

A noticeable feature in Azure AD Premium is Conditional Access. Conditional Access, as the name implies, grants, or block access to certain conditions. You can force MFA, block specific applications, block legacy authentication, etc.

Figure 1: Conditional Access Policies

Identity Protection and Identity Governance

An Azure AD Premium P2 feature not included in Azure AD Premium P1 is Identity Protection and Identity Governance. Identity Protection is a feature that detects risky accounts based on many indicators (atypical travel, malware linked IP address, and many more). Conditional Access uses these detections to allow or block an identity. Using Identity Protection makes it possible to mitigate an attack within seconds due to an automated response to a risky user.

Figure 2: Risky Users

Identity Governance contains Privileged Identity Management (PIM), Access Reviews, and Entitlement Management. PIM makes it possible to control, manage, and monitor access to essential resources in your organization. PIM provides Just-In-Time (JIT) access to Azure AD and Azure resources, assign time-bound access, asks for approval, and much more. Identity Governance also includes Access Review to review access regularly to make sure only the right people have continued access.

Conditional Access, Identity Protection, and Privileged Identity Management help organizations control their identities and definitely worth checking.

Licensing

Azure AD Premium comes with Microsoft 365 E3, Microsoft 365 E5, or a separate license.

Figure 3: Licensing

Conclusion

With features like conditional access, Azure AD premium is a must.