Microsoft

Microsoft Defender for Identity Encrypted Password

by thalpius

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.