Author: thalpius

Microsoft Defender for Identity is a cloud-based security solution to monitor your on-premises identities. Since it is a cloud-based security solution, it must communicate with the cloud. In this blog post, I will describe how Microsoft Defender for Identity communicates with the cloud during the installation of the sensor.

Introduction

I started monitoring the installer using Burp Suite. After intercepting the first request, I see that the body includes some jibberish. The body looks encrypted or compressed. Since the installer does not contain a certificate, the body is probably compressed and not encrypted.

Here is an example of an intercept in Burp.

POST /api/sensorDeployment/v1.0 HTTP/1.1
Authorization: Basic <WorkSpaceID>:<AccessKey>
Host: thalpius-onmicrosoft-comsensorapi.atp.azure.com
Content-Length: 41
Expect: 100-continue
Connection: close

«æåRPPR)©,HU²RP
I-.qI-ÈɯÌMÍ+	J-,
(ñrÕ

The body looks compressed, so the question is: What does the body look like after decompression?

Microsoft Defender for Identity API Fiddler

There are different ways to decompress the bytes, but I created a tool to add more features to test the API endpoints in the future.

The tool includes a compressor and a decompressor. When we copy the compressed bytes from Burp to see what the body looks like decompressed, we can see it is a JSON object.

Because I do not want to compress and decompress a JSON object all the time, I created a simple API requester that compresses and decompresses the body automatically. Using my tool, you can send a request in JSON format without compressing it, making it much simpler.

The installer does not contain a certificate, so how does it authenticate to the cloud?

Authentication

The Burp interception shows an authentication header which is basic authentication.

Authorization: Basic <WorkSpaceID>:<AccessKey>

There is a comment in the Microsoft 365 Defender portal which says, “Access key is only used during the sensor installation.”

The installer creates a certificate for all future communication to the cloud. For that reason, the access key is used only during the installation. I added a settings option in my tool to set the authorization needed to send a valid request.

API Endpoints

I identified three API endpoints during my research: sensorDeployment, protobuf, and json. The URI of the endpoints are:

• https://<WorkspaceName>sensorapi.atp.azure.com/api/sensorDeployment/v1.0
• https://<WorkspaceName>sensorapi.atp.azure.com/api/protobuf/v1.0
• https://<WorkspaceName>sensorapi.atp.azure.com/api/json/v1.0

Note: The installation only used the sensorDeployment API endpoint—more on the protobuf and json endpoints in a later blog post.

API Requests

Now that we know how the authentication takes place and we can decompress the body, let us see what the installer sends to the API endpoint during the installation.

Here are the API requests:

{
  "$type": "TestDeploymentRequest"
}

{
  "$type": "ValidateCreateSensorRequest",
  "Version": "2.193.15824.20477"
}

{
  "$type": "GetSensorMinorDeploymentPackageSensorApiDeploymentRequest",
  "Version": "2.193.15824.20477"
}

{
  "$type": "CreateSensorRequest",
  "Certificate": {
    "$type": "X509Certificate2",
    "RawData": "MIIDbj<SNIP>rjjb88"
  },
  "DnsName": "THALPIUS.thalpius.local",
  "NetbiosName": "THALPIUS",
  "NetworkAdapters": [
    {
      "$type": "NetworkAdapter",
      "Id": "{9846C447-1A36-4739-B469-E03769E013DE}",
      "Name": "Ethernet",
      "State": "EnabledConnected",
      "IpAddresses": [
        "10.211.55.83",
        "[fdb2:2c26:f4e4:0:558b:329c:4fd7:477e]",
        "[fe80::558b:329c:4fd7:477e%9]"
      ]
    }
  ],
  "ShouldEnableDelayedUpdate": false,
  "Type": "DomainControllerIntegrated",
  "Version": "2.193.15824.20477"
}

Download Sensor

For example, the GetSensorMinorDeploymentPackageSensorApiDeploymentRequest downloads a cabinet file of the latest sensor. You can see the response in my tool, which automatically decompresses the result.

If we take the base64 encoded string and decode it using certutil, we see we got the latest sensor.

Conclusion

My intention in researching the API is to understand better how the product works and see what I can do with it as an attacker. I will soon add more functionality to my tool, such as the JSON API endpoint, and post my findings testing that API in a future blog post.

After installing a Microsoft Defender for Identity sensor, the SensorConfiguration.json contains information about the sensor, including an encrypted password when using an authenticated proxy server. I wanted to see if I could decrypt the password and if I could set a proxy without the need to reinstall the Microsoft Defender for Identity sensor. I found more exciting things during this research, which I will describe in this blog post.

Introduction

The recommended practice from Microsoft to use a proxy server for the Microsoft Defender for Identity sensor is to run the setup with some arguments. There are alternative ways to configure a proxy, but that affects all services for the entire system. Configuring a proxy for Microsoft Defender for Identity using the command line means reinstalling the sensor. Microsoft provides no way to set up a proxy server after you install the sensor without reinstalling the sensor using the command line. During the setup, the password gets encrypted and stored in SensorConfiguration.json, which is why you need to reinstall the sensor when using a proxy server.

Proxy Server Without Authentication

When using no authentication for the proxy server, you can edit SensorConfiguration.json, so you do not have to reinstall the sensor. Here is an example of a SensorConfiguration.json with no authentication for the proxy server.

{
  "$type": "SensorMandatoryConfiguration",
  "SecretManagerConfigurationCertificateThumbprint": "F9E489827037BBC8ADFE82E43A3C63FCB6C717A9",
  "SensorProxyConfiguration": {
    "$type": "SensorProxyConfiguration",
    "Url": "http://localhost:8080",
    "UserName": null,
    "EncryptedUserPasswordData": null
  },
  "WorkspaceApplicationSensorApiWebClientConfigurationServiceEndpoint": {
    "$type": "EndpointData",
    "Address": "thalpius-onmicrosoft-comsensorapi.atp.azure.com",
    "Port": 443
  }
}

Proxy Server With Authentication

Things get a little trickier when you use authentication for the proxy server since the password is encrypted and stored in SensorConfiguration.json.

Here is an example of a SensorConfiguration.json with authentication for the proxy server.

{
  "$type": "SensorMandatoryConfiguration",
  "SecretManagerConfigurationCertificateThumbprint": "B6DED748E000B5A62D3F4C45058E1DCF64BB55B9",
  "SensorProxyConfiguration": {
    "$type": "SensorProxyConfiguration",
    "Url": "http://localhost:8080",
    "UserName": "thalpius.local\\thalpius",
    "EncryptedUserPasswordData": {
      "$type": "EncryptedData",
      "EncryptedBytes": "FecQfIeoURIu/oCGrvzkSsVP3IIBHDnOchSRQ0hjwzoZSvxLFMnleVNoPSZuCDCy7MVpi1qyFSdBWcrS1nmfgXpzQUFmY4XItKug4OlEYST6F96LY5mWW7H9noOIF5LOGNeltQkJYqeo3MKrXZdoh87EnjBbhKV5cSCgrMOwUXUMsiXd6KvEmsevAkIHvRHZnYbrdG/2pIqI/l4/oyRgU7fOunDlyZF9Ne/xgxApjcMa/sEdnoqBu+0Rs3XVN8K6RbjdxtiGHlbaCM5WUYQ4h+Qznd3GkhNo4iGaXvpa75tedpUbi/aofNMA9w0W+z2ScXqPEBuZhxE6O1t28I5feA==",
      "CertificateThumbprint": "B6DED748E000B5A62D3F4C45058E1DCF64BB55B9",
      "SecretVersion": null
    }
  },
  "WorkspaceApplicationSensorApiWebClientConfigurationServiceEndpoint": {
    "$type": "EndpointData",
    "Address": "thalpius-onmicrosoft-comsensorapi.atp.azure.com",
    "Port": 443
  }
}

You need to know the encryption to decrypt the password. Luckily the sensor is written in C# and is easy to decompile. Looking at the code, we can see that the encryption takes place using the public key from a certificate with RSA and OAEP padding.

public EncryptedData Encrypt(byte[] data)
{
    Ensure.NotNull("data", data);
    return new EncryptedData(this._rsaCng.Encrypt(data, ApplicationCryptoKey._rsaEncryptionPadding), null, this.SecretVersion);
}

public byte[] Decrypt(EncryptedData encryptedData)
{
    Ensure.NotNull("encryptedData", encryptedData);
    Ensure.That("attempt to decrypt certificate-encrypted data [encryptedData.CertificateThumbprint=" + encryptedData.CertificateThumbprint.Sanitize() + "]", encryptedData.CertificateThumbprint == null);
    return this._rsaCng.Decrypt(encryptedData.EncryptedBytes, ApplicationCryptoKey._rsaEncryptionPadding);
}

private static readonly RSAEncryptionPadding _rsaEncryptionPadding = RSAEncryptionPadding.OaepSHA256;

I created a tool that encrypts and decrypts the password using the certificate found on the server, which has the sensor installed. Using the tool and encrypting the password makes it possible to set up an authenticated proxy server in SensorConfiguration.json without reinstalling the sensor. Encrypt the password and use the example above by replacing the EncryptedBytes property to set the authenticated proxy server in SensorConfiguration.json.

Decrypt ALL Directory Services Accounts

During my research, I discovered that I could decrypt all passwords found for all non-gMSA accounts entered in the portal at “Directory Services Accounts” since the sensor-updater log contains all encrypted passwords for all accounts during an update. The weird thing is that I can decrypt all passwords with a single certificate. So, once a single server is compromised, which holds the Microsoft Defender for Identity sensor, all passwords are known in plain text using my tool, including all passwords across forests or domains

Recommended Practice

Here are my recommended practice regarding decrypting passwords for the Microsoft Defender for Identity sensor.

• Do not re-use passwords for any account since the decryption of the password shows the password in plain text.
• Use a gMSA account for connecting the sensor to Active Directory domains.
• Be aware when using multiple domains or even forests that the decryption of a password shows the password in plain text for that particular domain or forest. So, anyone with access to a server which holds a sensor can decrypt the password.
• Although an attacker already needs to compromise AD DS to perform this attack, remember the AD FS servers which also can contain a sensor. So getting a foothold on an AD FS server makes it possible to achieve this attack without touching AD DS. Handle an AD FS server the same as an AD DS server (TIER-0).

Conclusion

Although an attacker already needs a foothold on an AD DS server, an AD FS can also hold a sensor if installed. From the AD FS server, an attacker can decrypt all passwords entered as a Directory Services Account in the portal without touching AD DS. Using only gMSA accounts mitigates everything, and it is a recommended practice anyway.

Recently I have seen some videos and read some blog posts about bypassing Microsoft Defender for Identity. I agree that there are possibilities to bypass Microsoft Defender for Identity, but in this blog post, I would like to add some notes about these bypasses.

Comments

• Auditing is critical for Microsoft Defender for Identity to work correctly. Either use my auditing tool or the Microsoft documentation to be sure you audit all events needed for Microsoft Defender for Identity to work correctly.
• Be sure to install the Microsoft Defender for Identity sensor on all Domain Controllers since security events do not replicate between Domain Controllers.
• When performing a domain dominance attack, you probably got detected during the lateral movement to achieve a domain dominance attack in the first place. Especially when all Microsoft Security E5 is installed and configured correctly.
• Install the Microsoft Defender for Identity sensor on all AD FS servers to detect attacks against the AD FS servers. Like Account Enumeration Reconnaissance, Suspected Brute Force Attack (LDAP), Remote Code Execution Attempt, and Abnormal ADFS authentication using a suspicious certificate.
• When using a test environment, some detections do not trigger because there is no baseline or enough information to detect an anomaly. These detections will trigger in a production environment.
• The recommended actions from Microsoft Defender for Identity are an excellent addition to creating a solid secure baseline for Active Directory.
• Please do not use a newly created account when using a honeytoken account. Attackers use the properties ‘logonCount’ and ‘badPwdCount’ to identify honeytoken accounts.
• Use a password that is not easy to brute-force for all accounts with a Service Principal Name to protect against Kerberoasting.
• Forcing AES on an account does not block an attacker from requesting an RC4 encrypted ticket. Disable RC4 encryption for Active Directory to prevent attackers from performing a Kerberoast attack.
• Use a dedicated Group Managed Service Account for Microsoft Defender for Identity, and do not use the account elsewhere. The Group Managed Service Account does have high privileges in Active Directory due to the response actions.

Conclusion

Like every security product, there are bypasses for Microsoft Defender for Identity. Attackers are still walking on eggshells, though. One simple mistake in the entire kill chain, and they get caught. It is getting worse for attackers when all Microsoft Security E5 is in place and configured correctly.

Remember that attackers use the on-premises environment as a stepping-stone to the cloud, so monitoring your environment is crucial even though you are moving to the cloud.

Microsoft Defender for Identity monitors your domain controllers by capturing and parsing network traffic and leveraging Windows events directly from your domain controllers. Auditing needs to be enabled for the Windows events to appear in the event viewer. Unfortunately, auditing is not on by default. Microsoft created a great docs page on configuring Windows event collection, but it is “a lot” of manual work, so I decided to make life a bit easier. I created an export of the policies needed for Microsoft Defender for Identity to enhance detection using the Windows events for others to import using a single command.

Configuration

Microsoft docs describe five configurations. Ideally, all configurations need to be done for Microsoft Defender for Identity to enable enhanced detection. These are the five configuration settings.

1. Configure Audit Policies
2. Event ID 8004 (NTLM)
3. Event ID 1644 (Active Directory Web Service)
4. Configure Object Auditing
5. Auditing for Specific Detections (AD FS and Exchange)

For the first three configuration settings, I created a backup of a GPO, which you can import using a single command.

1. Download the files by clicking the green “Code” button on top of the repository, followed by “Download ZIP.”
2. Unpack the files to a location you remember.
3. Run the PowerShell command shown below.

Import-Gpo -BackupGpoName "Microsoft Defender for Identity Auditing" -TargetName "Microsoft Defender for Identity Auditing" -Path C:\UnpackedFiles -CreateIfNeeded

The command imports the GPO but does not link it to any Organisation Unit. To link the GPO to the Domain Controller OU, use the following command.

New-GPLink -Name "Microsoft Defender for Identity Auditing" -Target "OU=Domain Controllers, DC=domain, DC=local"

Note: While the resource limitation feature can stop the Defender for Identity service if the server runs out of resources, it does not stop the event auditing at the operating system level. Therefore, ensure your servers have sufficient memory, CPU, and disk resources to avoid performance issues.

Configure Object Auditing

For the forth configuration setting, the following script enables auditing on all users, groups, and computers in the Active Directory domain.

$Path = (Get-ADRootDSE).defaultNamingContext
$ACL = Get-Acl "AD:\$Path" -audit
$inheritedobjectguid = new-object Guid bf967aba-0de6-11d0-a285-00aa003049e2
$identity = [Security.Principal.NTAccount]'everyone'
$inheritanceType = [System.DirectoryServices.ActiveDirectorySecurityInheritance]"Descendents"
$ace = new-object System.DirectoryServices.ActiveDirectoryAuditRule($identity, 'CreateChild, DeleteChild, Self, WriteProperty, DeleteTree, ExtendedRight, Delete, WriteDacl, WriteOwner', "success", [guid]'00000000-0000-0000-0000-000000000000', $inheritanceType, $inheritedobjectguid)
$acl.AddAuditRule($ace)
Set-ACL -Path "AD:\$Path" -AclObject $ACL

$inheritedobjectguid = new-object Guid bf967a86-0de6-11d0-a285-00aa003049e2
$ace = new-object System.DirectoryServices.ActiveDirectoryAuditRule($identity, 'CreateChild, DeleteChild, Self, WriteProperty, DeleteTree, ExtendedRight, Delete, WriteDacl, WriteOwner', "success", [guid]'00000000-0000-0000-0000-000000000000', $inheritanceType, $inheritedobjectguid)
$acl.AddAuditRule($ace)
Set-ACL -Path "AD:\$Path" -AclObject $ACL

$inheritedobjectguid = new-object Guid bf967a9c-0de6-11d0-a285-00aa003049e2
$ace = new-object System.DirectoryServices.ActiveDirectoryAuditRule($identity, 'CreateChild, DeleteChild, Self, WriteProperty, DeleteTree, ExtendedRight, Delete, WriteDacl, WriteOwner', "success", [guid]'00000000-0000-0000-0000-000000000000', $inheritanceType, $inheritedobjectguid)
$acl.AddAuditRule($ace)
Set-ACL -Path "AD:\$Path" -AclObject $ACL

Auditing for Specific Detections

Some detections require auditing specific Active Directory objects. For the fifth configuration setting, one detection is for AD FS and requires auditing on an AD FS object, and the other is for Exchange which requires auditing on the configuration container.

To enable auditing for AD FS detections, use this script.

$Path = (Get-ADRootDSE).defaultNamingContext
$ACL = Get-Acl "AD:\CN=ADFS,CN=Microsoft,CN=Program Data,$Path" -audit
$inheritedobjectguid = new-object Guid 00000000-0000-0000-0000-000000000000
$identity = [Security.Principal.NTAccount]'everyone'
$inheritanceType = [System.DirectoryServices.ActiveDirectorySecurityInheritance]"All"
$ace = new-object System.DirectoryServices.ActiveDirectoryAuditRule($identity, 'ReadProperty, WriteProperty', "Success, Failure", [guid]'00000000-0000-0000-0000-000000000000', $inheritanceType, $inheritedobjectguid)
$acl.AddAuditRule($ace)
Set-ACL -Path "AD:\CN=ADFS,CN=Microsoft,CN=Program Data,$Path" -AclObject $ACL

To enable auditing for Exchange detection, use this script.

$Path = (Get-ADRootDSE).defaultNamingContext
$ACL = Get-Acl "AD:\CN=Configuration,$Path" -audit
$inheritedobjectguid = new-object Guid 00000000-0000-0000-0000-000000000000
$identity = [Security.Principal.NTAccount]'everyone'
$inheritanceType = [System.DirectoryServices.ActiveDirectorySecurityInheritance]"All"
$ace = new-object System.DirectoryServices.ActiveDirectoryAuditRule($identity, 'WriteProperty', "Success, Failure", [guid]'00000000-0000-0000-0000-000000000000', $inheritanceType, $inheritedobjectguid)
$acl.AddAuditRule($ace)
Set-ACL -Path "AD:\CN=Configuration,$Path" -AclObject $ACL

Conclusion

Many organizations go through a digital transformation to the cloud. As attackers use the on-premises environment as a stepping-stone to the cloud, as long as you have an on-premises environment, please use Microsoft Defender for Identity to protect your organization. Since Microsoft Defender for Identity leverages on Windows events, always enable auditing to be sure Microsoft Defender for Identity detects all attacks.

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.

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.

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.

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.