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.
Let us look at a 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.
Note: Since HistorySavePath loads when PowerShell starts, “Microsoft JSON Web Token Extractor” also displays these tokens.
Depending on how a user or admin connects to Azure, the following JSON files contains the JSON Web Token in plain text:
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.
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.
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”:
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:
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:
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:
Let us try and remove the restriction using the “Restrict Editing” option:
Once you click the “Restrict Editing” option, you have an option to stop the protection on the bottom right:
Once you click the “Stop Protection,” no restriction is set, and the document is editable:
Simply deleting the image shows us the 5926 words with white font and font size 2:
To see what the text contains, we select a 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:
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:
Enable the macro, which starts audit logging and saves the logs in the event viewer:
Now that we have auditing enabled, click “Enable Content.” The following message box will appear:
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):
If we scroll down, we can see the base64 encoded command:
Let us use PowerShell to decode the base64 encoded string:
Use the following command to decode the base64 string:
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:
So what this malware does is the following:
Hide a base64 encoded string behind a restricted editing image.
Uses macros to de-obfuscate the base64 string used to download a malicious file.
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 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.
Microsoft recognises the federation and sends a 302 HTTP response code, redirecting the user to the federated AD FS server ;
The user identifies itself using a password on the Web Application Proxy used by AD FS;
The Web Application Proxy sends the request to AD FS;
AD FS authenticates the user by checking Active Directory if the user entered the correct credentials;
AD DS sends the response of the authentication back to the AD FS server;
AD FS signs a token using a token-signing certificate and sends it to the Web Application proxy;
The Web Authentication Proxy sends the signed token to the user;
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:
The date creation of the private key helps identify which key to use;
The private keys are in the correct format;
Microsoft Defender for Identity does not detect the attack.
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.
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.
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.
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.
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.
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 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.
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 name
Old Product name
Microsoft Defender for Identity
Microsoft Azure ATP
Microsoft Defender for Endpoint
Microsoft Defender ATP
Microsoft Defender for Office 365
Microsoft Office 365 ATP
Microsoft 365 Defender
Microsoft Threat Protection
Azure Defender for Servers
Azure Security Center Standard Edition
Azure Defender for IoT
Azure Security Center for IoT
Azure Defender for SQL
Advanced 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.