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 released a new detection for Microsoft Defender for Identity. The detection detects a malicious request for user accounts that do not require pre-authentication, also known as an AS-REP roasting attack. This blog post will briefly explain what an AS-REP roasting attack is and how to mitigate it.
AS-REP roasting is not a new attack. The detection by Microsoft Defender for Identity is, though. People like harmj0y and many others documented AS-REP roasting well, but since the detection is new in Microsoft Defender for Identity, I will briefly go through the attack.
In my previous blog post, I explained how Kerberos works but let us go over it again.
Kerberos is an authentication protocol based on tickets. The protocol is an authentication protocol developed by MIT and adopted by Microsoft since Windows 2000. Kerberos is also complicated and hard to secure.
Here is an oversimplified overview of these ticket requests:
First, the user needs to authenticate. The Authentication Service, which is part of the Key Distribution Center, handles the authentication.
Note: Within a Microsoft environment, the Key Distribution Center is the Domain Controller.
The user sends a Ticket Granting Ticket (AS-REQ) request and encrypts the timestamp in the request with the users’ password hash. The encryption of the timestamp is the pre-authentication within Active Directory. Active Directory tries to decrypt the timestamp using the users’ password hash. If the decryption works, Active Directory knows the password is correct and sends a Ticket Granting Ticket (AS-REP) back to the user.
Within Active Directory, there is an option to disable the need for pre-authentication:
When pre-authentication is disabled, there is no need to encrypt the timestamp in the Ticket Granting Ticket request, making it possible for everyone, even unauthenticated users, to request a Ticket Granting Ticket for that user.
The Ticket Granting Ticket sent back to the user is encrypted with the users’ password hash. If an attacker decrypts the ticket using a rainbow table, the attacker knows the user’s password.
Some non-Microsoft products require pre-authentication to be disabled. I have not seen an organization where this is needed, but if pre-authentication needs to be disabled, use a strong and generated password for the user account to be impossible for an attacker to brute-force the password. I highly recommend enabling pre-authentication for all user accounts, though.
To check which user accounts have pre-authentication disabled, use this PowerShell script:
Note: Run this script using a domain user. No additional module is needed to run the script.
Any unauthenticated user can request a Ticket Granting Ticket when pre-authentication is disabled. Even though the ticket is encrypted, an attacker can brute-force the ticket to get the users’ password. Be sure no users have pre-authentication disabled within Active Directory.
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.
The PowerShell script validates the following settings, including Multi-Factor Authentication:
Conditional Access Policy Setting
Exchange Active Sync
Table 1: PowerShell Script validations
Visit my GitHub page for the PowerShell script, and please add any feature requests or issues if there are any.
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 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.