Just Released!
Real-time threat detection and change monitoring with single pane‑of‑glass visibility across AD and Entra ID.
Threat Directory
Welcome to the Cayosoft Threat Directory— a continuously updated hub of intelligence on hybrid identity attack techniques and detection patterns. It’s designed to empower security teams to turn alerts into actionable insights with detailed remediation steps, enabling fast, confident response across Active Directory, Entra ID, Intune, and Microsoft 365.
A Microsoft Entra ID agent identity that has no assigned active owner is a vulnerability, because no one is accountable for its configuration or its operation. An owner whose account is disabled can't sign in, review the agent's permissions, or respond to an alert about it, so an agent owned only by disabled accounts is effectively unowned. A threat actor exploits this gap for persistence, because the agent keeps running with its original permissions and no active owner notices configuration drift or a change in the agent's behavior.
Example: A team creates an agent identity for a pilot project and assigns a single owner. That owner later leaves the organization, and their account is disabled but not removed from the agent. The agent retains its original application permissions, and the ownership record looks complete in a routine audit. A threat actor who compromises the agent's credentials operates under those permissions without triggering review, because no active owner exists to notice the change.
An inbound connector that accepts email without requiring authentication or a restricted, verified sender IP range is a vulnerability, because it allows any external system to relay email through your organization's infrastructure as if that system were internal or trusted. A threat actor exploits this by sending spoofed or malicious email through the misconfigured connector, which bypasses some of the spam and authentication checks that would otherwise apply to ordinary inbound email. Restricting inbound connectors to known sources that are authenticated or IP-restricted mitigates this exposure.
Example: A hybrid mail flow connector intended for a legacy on-premises application is left configured to accept email from any IP address without authentication. A threat actor discovers the connector and relays spoofed executive-impersonation email through it. Downstream filters treat that email with elevated trust because it arrived through an internal connector. Restricting the connector to specific verified source IP addresses, and requiring TLS and authentication, removes this abuse path.
An Exchange Online organization that has no user and domain impersonation protection in its anti-phishing policy is vulnerable, because the tenant accepts messages that mimic the display name or domain of executives, partners, or the organization itself. A threat actor exploits this gap by registering a lookalike domain or spoofing a trusted display name to solicit fraudulent payments or credentials, activity that impersonation protection is designed to detect and flag. Impersonation protection closes the gap because it compares each sender against the identities and domains you protect, and then acts when it finds a mismatch.
Example: A threat actor registers contos0.com and emails the accounts payable team using the CEO's display name to request an urgent invoice payment. Without impersonation protection for the CEO's identity, the message is delivered normally. With protection enabled, the mismatch between the sender's actual domain and the protected identity triggers a warning or quarantines the message.
An Exchange Online organization that allows automatic forwarding of email to external domains at the tenant level is vulnerable, because it removes a control point that would otherwise limit a threat actor's ability to exfiltrate data after a single mailbox is compromised. A threat actor exploits this after a phishing or credential-theft attack: once the actor has access to a mailbox, they create a silent forwarding rule and keep receiving sensitive correspondence even after you reset the compromised credentials. Restricting automatic forwarding at the tenant level closes this path, because email stops leaving the organization even when a mailbox forwarding rule survives the password reset.
Example: The organization's remote domain settings and outbound spam filter policy allow automatic forwarding to external addresses. After a successful phishing attack against an executive's mailbox, the threat actor configures forwarding of all email to an external address and keeps access to sensitive communications after the compromised password is changed. When automatic forwarding is restricted at the tenant level, and exceptions require approval, the forwarded email is blocked and the threat actor loses that access.
A domain that has no DMARC (Domain-based Message Authentication, Reporting, and Conformance) record, or that publishes a DMARC record with the policy p=none, is a vulnerability. Without an enforcement policy, receiving mail servers aren't instructed to reject or quarantine unauthenticated messages that claim to come from your organization.
A threat actor can exploit this gap to run convincing spoofing and business email compromise (BEC) campaigns, because the recipient's mail server has no enforced policy to act on SPF (Sender Policy Framework) or DKIM (DomainKeys Identified Mail) authentication failures.
To mitigate this vulnerability, publish a DMARC record that specifies an enforcement policy of quarantine or reject. Enforcement significantly reduces the success rate of domain-spoofing attacks.
Example: The domain contoso.com has no DMARC record, or its record is set to p=none. When a threat actor sends spoofed invoices from billing@contoso.com, receiving mail servers deliver the messages to recipients' inboxes, because no policy instructs them to reject or quarantine messages that fail authentication.
Microsoft Entra Privileged Identity Management (PIM) supports just-in-time access to privileged roles. Active role assignments that exceed the configured duration threshold provide privileged access for longer than permitted by the organization and increase unnecessary exposure.
If a threat actor compromises an Entra ID object with a long-duration active PIM assignment, they may maintain privileged access and perform lateral movement, data exfiltration, or critical configuration changes.
This threat detects active PIM assignments that exceed the duration threshold configured in the threat settings. The default threshold is 24 hours.
Threat actors may use unknown or non-existent OAuth client IDs in Microsoft Entra ID authentication requests to perform account enumeration, validate credentials, or evade application-based detection controls.
In this technique, the authentication request specifies an OAuth client ID that does not correspond to an application registration or service principal in the target tenant. As a result, application metadata—such as the application name, owner, or expected sign-in behavior—may be unavailable. This can reduce the effectiveness of detections that rely primarily on known application identifiers, successful sign-ins, or application-specific activity.
An authentication attempt involving an unknown OAuth client ID may indicate identity reconnaissance, credential validation, or an attempt to bypass application-centric monitoring. However, unknown client IDs can also result from application misconfiguration, obsolete clients, or requests directed to the wrong tenant.
The activity should be investigated when it is accompanied by suspicious authentication error codes, repeated attempts against multiple accounts, missing application metadata, unusual source locations or IP addresses, or other indicators of credential-testing activity. The combination of these signals may provide a high-confidence indication of malicious authentication activity.
NOTE: This threat rule includes a built-in lookback parameter set to 25 hours. Only events that occurred within this timeframe are processed by the rule.
Windows Local Administrator Password Solution (Windows LAPS) helps protect local administrator accounts by automatically rotating passwords and backing them up to Windows Server Active Directory or Microsoft Entra ID. Windows LAPS is built into supported Windows 10, Windows 11, and Windows Server versions that have the April 11, 2023 update or later.
If Windows LAPS is not configured, if the required policy is missing, or if Active Directory prerequisites are incomplete, local administrator passwords might not be rotated or backed up securely. This can leave devices using static or reused local administrator passwords and increase the risk of credential reuse, pass-the-hash attacks, and lateral movement.
For Active Directory backup, the Windows LAPS schema attributes must be added to the forest. To use encrypted password storage in Active Directory, the domain must run at Windows Server 2016 domain functional level or later. Hybrid-joined devices can back up Windows LAPS passwords to either Microsoft Entra ID or Windows Server Active Directory, but not both.
Legacy Microsoft LAPS is deprecated on newer Microsoft operating systems. Organizations should plan migration to Windows LAPS to use modern capabilities such as native OS support, password encryption in Active Directory, password history, and Microsoft Entra ID integration.
Active Directory Certificate Services (AD CS) is a critical identity infrastructure component used to issue and manage certificates. If AD CS auditing is not configured, certificate requests, issuance, revocation, configuration changes, and access attempts may not be logged. As a result, malicious or unauthorized certificate operations may go undetected, increasing the risk of privilege escalation, credential theft, and persistence.
For example, an attacker who compromises a user account could abuse a misconfigured certificate template to request a certificate that can be used for authentication as a privileged identity. Without AD CS auditing, this certificate request and issuance may not be recorded, making the activity difficult to detect, investigate, or report for compliance purposes.
Using passwords that match the samAccountName creates a predictable and vulnerable login combination. Attackers commonly attempt such patterns during brute-force or dictionary attacks to compromise user accounts.
Cayosoft detects and alerts when an account's password hash matches a hash derived from its samAccountName, signaling the use of weak, easily deducible credentials.
Cayosoft Guardian is designed with strict security principles to protect sensitive credential data within customer environments. Cayosoft Guardian does not store or transmit password hashes. All password-related comparison operations are executed locally on your domain controllers, ensuring that password hashes remain within your secure environment and are never sent to the internet or external systems.
This architecture ensures that password hashes are not collected, exported, or exposed outside your Active Directory domain controllers during backup, recovery, or change monitoring operations.
This indicator looks for principals (computers or users) that have constrained delegation enabled for a service running on a domain controller. If an attacker can create such a delegation, they can authenticate to that service using any user that is not protected against delegation.
A threat actor can gain control over a domain controller service account configured for constrained authentication delegation and exploit this access to escalate privileges within the network. By compromising this service account, which is trusted for constrained authentication delegation, the threat can impersonate users and access sensitive resources as specified by the delegation settings. This level of control can be leveraged to perform lateral movements, escalate privileges, and potentially gain domain administrator rights, thus significantly compromising the security and integrity of the entire network.
This rule checks if the domain's federation settings were recently modified.
When you federate your on-premises environment with Microsoft Entra ID, you establish a trust relationship between the on-premises identity provider and Microsoft Entra ID.
Due to this established trust, Microsoft Entra ID honours the security token issued by the on-premises identity provider post-authentication, to grant access to resources protected by Microsoft Entra ID. A malicious user might modify federation settings to get access to resources in Microsoft Entra ID.
In Active Directory, computer objects, including Delegated Managed Service Accounts (dMSAs), are securable and governed by Access Control Lists (ACLs). Improper delegation of permissions at the Organizational Unit (OU) level can allow unprivileged users to gain write access to these sensitive objects.
Windows Server 2025 introduces the msDS-DelegatedManagedServiceAccount class, which enables new service account capabilities, including successor inheritance. This functionality, while powerful, can be abused to simulate a migration from a privileged identity, allowing an attacker to craft a dMSA that inherits the access of a privileged account without needing to compromise the original.
Cayosoft Guardian considers both direct and indirect (nested) group permissions when evaluating risks. If a regular user is granted permissions such as GenericWrite, WriteDacl, or WriteProperty on OUs containing dMSAs, they could exploit this to escalate privileges, evade detection, and maintain long-term persistence.
NOTE: This threat applies only in environments with at least one Windows Server 2025 Domain Controller and the corresponding schema upgrade, which introduces the msDS-DelegatedManagedServiceAccount object class.
This can include promoting itself or other service principals to members of privileged roles, such as administrators or owners. This means that a threat actor who has gained access to a previously created service principal with the 'AppRoleAssignment.ReadWrite.All' permission could use it to persist in the environment and elevate their privileges when needed.
The Common Vulnerabilities and Exposures (CVEs) CVE-2021-42278 and CVE-2021-42287 are security flaws that can be exploited by a threat actor who has obtained access to low-privileged domain user credentials. These vulnerabilities enable the attacker to obtain a Kerberos Service Ticket for a Domain Controller computer account, which provides elevated privileges within a domain.
This escalation of privileges enables the attacker to take control of the domain controller, thereby compromising the security of the entire domain. The domain controller is a critical component of a Windows domain-based network and has a crucial role in managing and enforcing security policies, as well as controlling access to network resources.
Therefore, exploitation of these vulnerabilities can have serious consequences for organizations that are running vulnerable systems, including data breaches, unauthorized access to sensitive information, and the spread of malware. It is highly recommended that organizations apply the necessary patches and updates to protect their systems against these vulnerabilities.
A Microsoft Entra tenant configured to allow partner access through Delegated Administrative Privileges (DAP) poses a high-severity threat if not tightly monitored and restricted. This access model grants external partners elevated rights within the tenant, potentially including Global Administrator or other privileged roles.
The existence of DAP allows a partner organization to act on behalf of your tenant without needing per-activity approval or just-in-time access, which increases the attack surface. If a partner organization is compromised or acts maliciously, the threat actor could gain control over sensitive resources within your environment, bypass Conditional Access policies, or disable security configurations.
Furthermore, partner access may not show up in standard user audit logs, complicating the detection of misuse. If DAP accounts are unnecessary, it is highly recommended to eliminate them and implement Least Privilege Access, opting for more secure alternatives like Granular Delegated Admin Privileges (GDAP) instead.
Multiple failed authentication attempts from invalid users via NTLM might be an indication of a threat actor performing a Password Spraying attack against an Active Directory environment to obtain initial access or elevate privileges. Detection mechanism uses the event 4776 and error code 0xC0000064 meaning that `The username you typed does not exist` (the attempted user is a legitimate domain user).
NOTE: This threat rule includes a built-in lookback parameter set to 25 hours. Only events that occurred within this timeframe are processed by the rule.
If one source endpoint tries to authenticate with different unique user accounts using the Kerberos protocol, it might be a threat actor performing a Password Spraying attack against an Active Directory environment. The detection mechanism uses native events from Security Log. The event 4771 is generated when the Key Distribution Center fails to issue a Kerberos Ticket Granting Ticket (TGT) and failure code 0x18 means `wrong password provided` while the attempted user is a legitimate domain user.
NOTE: This threat rule includes a built-in lookback parameter set to 25 hours. Only events that occurred within this timeframe are processed by the rule.
Encrypting Active Directory backups adds an extra layer of security to sensitive data like user credentials, group policies, and other sensitive data. Encrypting backups ensures that even if threat actors gain access to the backup files, they won't be able to read or misuse the information.
Encrypted backups are much safer in the event of a data breach. Even if threat actors manage to access the backup files, they won't be able to decipher the information without the encryption key, minimizing the impact of the breach. In addition, they guard against insider threats. Even employees with access to backup files won't be able to misuse the data if it's encrypted without the necessary decryption keys.
When transferring backup files over networks or storing them in cloud services, encryption ensures that the data remains secure throughout the transmission and storage, protecting it from interception or unauthorized access.
A threat actor with permissions to link Group Policy objects at the AD site, Domain controllers OU, or domain can elevate their permissions.
NOTE: Cayosoft Guardian considers both direct and indirect (nested) group permissions when evaluating risks. Privileged users are defined in Active Directory as users with AdminCount=1. By design, Active Directory uses this attribute to protect members of administrative groups.
According to security best practices, it is not recommended to reuse admin accounts; instead, these accounts must be de-provisioned. If an account has administrative permissions, it may also gain access to other resources using these permissions and retain this access even after it is removed from the administrative groups. Learn more about AdminSdHolder and SDProp - Microsoft Community Hub.
If one source endpoint tries to authenticate with different unique user accounts against a single domain controller, it might be a threat actor performing a Password Spraying attack against an Active Directory environment. The detection mechanism uses native events from Security Log. The event 4625 documents failed attempts to log on to the computer and Logon Type value 3 describes a remote authentication attempt.
NOTE: This threat rule includes a built-in lookback parameter set to 25 hours. Only events that occurred within this timeframe are processed by the rule.
In a hybrid scenario, identities are synchronized from the on-premises AD to Microsoft Entra ID, with the on-premises AD being the authoritative source. Normally, lateral movement from the compromised on-premises AD to Microsoft Entra ID is more common, as information flows from on-premises to the cloud.
However, the Cloud Kerberos Trust model creates trust from the on-premises AD to Microsoft Entra ID, allowing authentication based on information from Microsoft Entra ID. A threat actor who obtains Global Admin privileges in Microsoft Entra ID can abuse this trust to escalate their privileges to Domain Admin. This means that the attacker, starting with control over Microsoft Entra ID, can gain control over the on-premises AD and potentially compromise the entire environment.
NOTE: Cayosoft Guardian defines privileged users in Active Directory as users with adminCount=1. By design Active Directory uses this attribute to protect members of administrative groups.
According to security best practices it is not recommended re-using admin accounts, instead these accounts must be de-provisioned. If an account has administrative permissions, it might also obtain access to other resources using these administrative permissions and keep this access even after it is removed from the administrative groups. Learn more about AdminSdHolder and SDProp - Microsoft Community Hub.
Failed logon attempts with multiple disabled domain users might be an indication of a threat actor trying to perform a Password Spraying attack against an Active Directory environment using Kerberos to obtain initial access or elevate privileges. The detection mechanism uses the event 4768 with the failure code 0x6 stands for `client not found in Kerberos database` (the attempted user is not a valid domain user).
NOTE: This threat rule includes a built-in lookback parameter set to 25 hours. Only events that occurred within this timeframe are processed by the rule.
Read-Only Domain Controllers (RODCs) in an inconsistent state pose significant risks to the integrity and security of an Active Directory environment. RODCs are intended to provide a read-only replica of the Active Directory database, often in less secure locations. Inconsistent states due to replication failures, partial updates, or misconfigurations, can lead to outdated or incorrect data being served to clients, undermining authentication, authorization, and policy application. Additionally, threat actors may exploit this inconsistency to escalate privileges, bypass security controls, or compromise sensitive credentials cached on the RODC.
Unauthorized changes to compliance policies weaken your organization's security by potentially allowing non-compliant or compromised devices to access corporate resources. Such changes may indicate that a threat actor has gained administrative access and is attempting to bypass security controls. Monitoring compliance policy changes ensures that the integrity of your device management environment remains intact.
A threat actor who gains administrative access could alter compliance policies to reduce security requirements, allowing non-compliant devices (such as those lacking encryption or updated software) to access critical systems. By detecting these unauthorized changes, the organization can quickly respond and restore secure policies, mitigating the risk of compromised devices accessing sensitive resources.
A threat actor who gains access to an Exchange Online mailbox may create multiple inbox rules to conceal emails - tactics commonly used in Business Email Compromise (BEC) attacks to evade detection and maintain access.
The threat is detected based on the creation of multiple new inbox rules in a given period of time.
Detection is scheduled to run regularly across all Entra tenants and will trigger an alert when particular number of new inbox rules are created in a particular period of time. Both the minimum rules number and the time period are adjustable in the Rule settings.
A threat actor who gains access to an Exchange Online mailbox may create a new inbox rule to delete, move, or forward incoming emails - tactics commonly used in Business Email Compromise (BEC) attacks to evade detection and maintain access.
The threat is detected based on the creation of new inbox rules that meet any of the following criteria:
- Move emails to Deleted Items
- Mark emails as Read
- Forward emails to external domains
Detection is scheduled to run regularly across all Entra tenants and will trigger an alert when:
- A new inbox rule with one or more of the above suspicious actions is created
- The rule is created by someone other than the mailbox owner (e.g., via delegated access or compromised credentials)
NOTE: This threat rule includes a built-in lookback parameter set to 25 hours. Only events that occurred within this timeframe are processed by the rule.
A threat actor who gains access to an Exchange Online mailbox may create a new inbox rule to delete, move, or forward incoming emails - tactics commonly used in Business Email Compromise (BEC) attacks to evade detection and maintain access.
The threat is detected based on the creation of new inbox rules that meet any of the following criteria:
- Move emails to Deleted Items
- Mark emails as Read
- Forward emails to external domains
Detection is scheduled to run regularly across all Entra tenants and will trigger an alert when:
- A new inbox rule with one or more of the above suspicious actions is created
- The rule is created by someone other than the mailbox owner (e.g., via delegated access or compromised credentials)
NOTE: This threat rule includes a built-in lookback parameter set to 25 hours. Only events that occurred within this timeframe are processed by the rule.
Bulk device wipes executed within a short time frame pose a serious threat to an organization's devices and data integrity. If an attacker gains access to administrative credentials, they could carry out large-scale wipes to eliminate evidence or disrupt business operations. This rule identifies instances where more than N device wipe or reset actions occur within a default 10-minute window (with both the value of N defaulting to 3 and the time interval set in the threat settings). Such activity is unusual and may indicate a coordinated attack targeting multiple devices.
If a threat actor gains access to administrative credentials, they could initiate multiple device wipes at the same time, resulting in significant data loss and operational disruption. In this situation, the malicious actor can erase several devices simultaneously, complicating efforts to recover data or track their activities. Early detection of bulk device wipes is crucial, as it minimizes the potential for widespread impact. This allows security teams to intervene and mitigate the damage before it spreads throughout the network.
NOTE: This threat rule includes a built-in lookback parameter set to 25 hours. Only events that occurred within this timeframe are processed by the rule.
When a device is successfully enrolled in Intune but never performs a compliance check-in, it may indicate one of the following: the management agent failed to initialize, the user uninstalled the MDM profile, or the device was enrolled solely to satisfy Conditional Access requirements and was subsequently abandoned or hidden from management.
This rule detects Kerberos pre-authentication failures targeting a honey account. Such failures may indicate that an attacker is attempting to brute-force credentials or enumerate accounts using Kerberos authentication. Monitoring failed attempts against decoy (honey) accounts can help identify suspicious activity before real accounts are compromised.
For more information, see Microsoft's documentation on Event ID 4771 - Kerberos pre-authentication failed.
A threat actor who gains access to an Exchange Online mailbox may create a new inbox rule to delete, move, or forward incoming emails - tactics commonly used in Business Email Compromise (BEC) attacks to evade detection and maintain access.
The threat is detected based on the creation of new inbox rules that meet any of the following criteria:
- Move emails to Deleted Items
- Mark emails as Read
- Forward emails to external domains
Detection is scheduled to run regularly across all Entra tenants and will trigger an alert when:
- A new inbox rule with one or more of the above suspicious actions is created
- The rule is created by someone other than the mailbox owner (e.g., via delegated access or compromised credentials)
NOTE: This threat rule includes a built-in lookback parameter set to 25 hours. Only events that occurred within this timeframe are processed by the rule.
Bulk changes might be a result of threat activities. Also, it could be a mistake. Deletions or modifications of Microsoft Entra objects can lead to service outages.
NOTE: This threat rule includes a built-in lookback parameter set to 25 hours. Only events that occurred within this timeframe are processed by the rule.
A regular user account or group with an AdminCount attribute set to any value might indicate potential threat activities. In particular, accounts with AdminCount=1 do not inherit permissions from parent containers. Active Directory employs the AdminSDHolder object, protected groups, and the Security Descriptor Propagator (SDProp) to safeguard privileged users and groups. SDProp is a process that runs every 60 minutes by default on the domain controller hosting the domain's PDC Emulator (PDCE). During this process, SDProp compares the permissions on the domain's AdminSDHolder object with those on the protected accounts and groups. If there is a discrepancy, SDProp resets the permissions on the protected accounts and groups to match those of the AdminSDHolder object.
An unexpected AdminCount value in a regular object may indicate potential threat activities. User accounts with previous administrative permissions should not be reused and should be deprovisioned.
NOTE: Cayosoft Guardian considers both direct and indirect (nested) group permissions when evaluating risks. Privileged groups are defined in Active Directory as groups with adminCount=1 and a well-known Security Identifier (SID). Any potential target objects are identified as members (including indirect ones) of previously identified built-in privileged groups. By design, Active Directory uses this attribute to protect members of administrative groups.
According to security best practices, it is not recommended to reuse admin accounts; instead, these accounts must be de-provisioned. If an account has administrative permissions, it may also gain access to other resources using these permissions and retain this access even after it is removed from the administrative groups. Learn more about AdminSdHolder and SDProp - Microsoft Community Hub.
In certain scenarios, threat actors who have gained control of a domain controller in a trusted domain can exploit the SID history attribute (sIDHistory) to associate SIDs with new user accounts, thereby granting themselves unauthorized access. SID filter quarantining is enabled by default on all external trusts to mitigate this risk. This security feature ensures that only SIDs from the directly trusted domain or forest are considered valid by removing any SID references that do not pertain to them from inbound access requests.
However, administrators can turn off this setting, and older Active Directory trusts may not enable SID filtering. Threat actors can insert spoofed SIDs into access requests without SID filtering, potentially gaining unauthorized access. While SID filtering significantly enhances security by blocking such attacks, it can also cause operational issues if legitimate access relies on SID history or Universal Groups, potentially leading to denied access.
Enabling SID filter quarantining on a trust relationship restricts the trust to the specific domains on either side, breaking its transitivity. This means only SIDs from the directly trusted domain are valid, strengthening security by ensuring only authorized SIDs are accepted.
Passwords in Group Policy Preferences (GPP) Compromise refers to a security vulnerability that occurs when Group Policy Preferences (GPP) in Active Directory are used to configure settings like local user accounts or service accounts, and passwords are stored in GPP XML files. These passwords are often stored in plain text or are weakly encrypted using a reversible encryption scheme. Attackers can exploit this vulnerability by accessing these files (typically found in SYSVOL, which is accessible to all domain users), decrypting the password, and using it to gain unauthorized access to privileged accounts or systems.
Microsoft has since disabled the use of passwords in GPP, but the vulnerability still poses a risk in environments where legacy GPP settings or files may exist. If the password field is empty, no alert should be triggered; alerts should only occur when the password field contains an actual password.
The Migrate sIDHistory permission in Active Directory allows an account to add or modify the sIDHistory attribute of a user or group. Delegating this permission to a regular user poses significant security threats. A threat actor can exploit this by migrating the SID of a high-privilege account into their own account, effectively gaining the same access rights and privileges. They can also add SIDs to access restricted resources, maintain persistence by hiding elevated privileges in a stealthy account, and evade security monitoring by masking their activities.
To mitigate these risks, restrict sIDHistory permissions to trusted administrative accounts, conduct regular audits, and monitor changes to the sIDHistory attribute.
NOTE: Cayosoft Guardian defines privileged users in Active Directory as users with adminCount=1. By design, Active Directory uses the attribute to protect members of administrative groups.
According to security best practices, it is not recommended to re-use admin accounts. Instead, these accounts must be de-provisioned. If an account has administrative permissions, it might also obtain access to other resources using these administrative permissions and keep this access even after it is removed from the administrative groups. Learn more about AdminSdHolder and SDProp - Microsoft Community Hub.
NOTE: Cayosoft Guardian defines privileged users in Active Directory as users with adminCount=1. By design Active Directory uses this attribute to protect members of administrative groups.
According to security best practices it is not recommended re-using admin accounts, instead these accounts must be de-provisioned. If an account has administrative permissions, it might also obtain access to other resources using these administrative permissions and keep this access even after it is removed from the administrative groups. Learn more about AdminSdHolder and SDProp - Microsoft Community Hub.