New identity security posture assessments: Riskiest LMPs and Unsecure Account Attributes
We are happy to announce two new Azure ATP identity security posture assessments for riskiest Lateral Movement Paths (LMP) and unsecure account attributes. What are risky lateral movement paths? Azure ATP continuously monitors your environment to identify sensitive accounts with the riskiest lateral movement paths that expose a security risk, and reports on these accounts to assist you in managing your environment. Paths are considered risky if they have three or more non-sensitive accounts that can expose the sensitive account to credential theft by malicious actors. Why should I be concerned about lateral movement paths? Malicious actors, much like thieves, often look for the easiest and quietest way into any environment. Sensitive accounts with risky lateral movement paths are windows of opportunities for attackers and can expose risks. For example, the riskiest paths are more readily visible to attackers and, if compromised, can give an attacker access to your organization's most sensitive entities. How do I use this security assessment? Use the report table to discover which of your sensitive accounts have risky LMPs. Take appropriate action: Remove the entity from the group as specified in the recommendation. Remove the local administrator permissions for the entity from the device specified in the recommendation. What are unsecure account attributes? Azure ATP continuously monitors your environment to identify accounts with attribute values that expose a security risk, and reports on these accounts to assist you in protecting your environment. What risk do unsecure account attributes pose? Organizations that fail to secure their account attributes leave the door unlocked for malicious actors. Malicious actors, much like thieves, often look for the easiest and quietest way into any environment. Accounts configured with unsecure attributes are windows of opportunities for attackers and can expose risks. For example, if the attribute PasswordNotRequired is enabled, an attacker can easy access to the account. This is especially risky if the account has privileged access to other resources. How do I use this security assessment? Use the report table to discover which of your accounts have unsecure attributes. Take appropriate action on those user accounts by modifying or removing the relevant attributes. You can find these new assessments under the Identity Security Posture in the Cloud App Security portal (Azure ATP integration must be enabled). Please let us know what you think about these assessments in the comments!
New Kerberos delegation types and columns in our identity security posture assessments
Two new enhancements are coming to Azure ATP's Identity security posture assessments: First, we are rolling out new types of Kerberos delegation into Azure ATP's Unsecure Kerberos delegation assessments: Constrained and Resource Based The new delegation types will show cases when a non-sensitive entity has been configured with constrained Kerberos delegation that points to a sensitive entity and when a sensitive entity has resource based constrained delegation configured for it, both allowing a malicious actor with a potential privilege escalation path if abused. to make things easier to configure, we will surface the exact delegation details that needs to be removed Furthermore, we are adding the much-requested Tags and Recommended action columns, where applicable, to show both the associated Tags (e.g. Sensitive) and the Recommend action per entity Or.New identity security posture assessments: Unsecure SID-History attributes and Microsoft LAPS Usage
We are happy to announce two new Azure ATP identity security posture assessments for unsecure SID-History attributes and Microsoft LAPS usage. What is the SID-History attribute? SID History is an attribute that supports migration scenarios. Every user account has an associated Security Identifier (SID) which is used to track the security principal and the access the account has when connecting to resources. SID History enables access for another account to effectively be cloned to another and is extremely useful to ensure users retain access when moved (migrated) from one domain to another. What risk does unsecure SID History attribute pose? Organizations that fail to secure their account attributes leave the door unlocked for malicious actors. Malicious actors, much like thieves, often look for the easiest and quietest way into any environment. Accounts configured with an unsecure SID History attribute are windows of opportunities for attackers and can expose risks. For example, a non-sensitive account in a domain can contain the Enterprise Admin SID in its SID History from another domain in the Active Directory forest, thus “elevating” access for the user account to effective Admin in all domains in the forest. Also, if you have a forest trust without SID Filtering enabled (also called Quarantine), it’s possible to inject a SID from another forest and it will be added to the user token when authenticated and used for elevated access. How do I use this security assessment? Use the report table to discover which of your accounts have an unsecure SID History attribute. Take appropriate action to remove SID History attribute from the accounts using PowerShell using the following command: Identify the SID in the SIDHistory attribute on the account. Get-ADUser -Identity <account> -Properties SIDHistory | Select-Object -ExpandProperty SIDHistory 2. Remove the SIDHistory attribute using the SID identified earlier. Set-ADUser -Identity <account> -Remove @{SIDHistory='S-1-5-21-...'} What is Microsoft LAPS? Microsoft LAPS (Local Administrator Password Solution) provide a solution to the issue of using a common local account with an identical password on every computer in a domain. LAPS resolve this issue by setting a different, rotated random password for the common local administrator account on every computer in the domain. Why should I use Microsoft LAPS? LAPS simplify password management while helping customers implement additional recommended defenses against cyberattacks. In particular, the solution mitigates the risk of lateral escalation that results when customers use the same administrative local account and password combination on their computers. LAPS store the password for each computer’s local administrator account in Active directory, secured in a confidential attribute in the computer’s corresponding AD object. The computer can update its own password data in Active directory, and domain administrators can grant read access to authorized users or groups, such as workstation helpdesk administrators. How do I use this security assessment? Use the report table to discover which of your domains have some (or all) compatible windows devices that are not protected by LAPS, or that have not had their LAPS managed password changed in the last 60 days. For domains that are partially protected, select the relevant row to view the list of devices not protected by LAPS in that domain. Take appropriate action on those devices by downloading, installing, and configuring or troubleshooting Microsoft LAPS using the documentation provided in the LAPS download. You can find these new assessments under the Identity Security Posture in the Cloud App Security portal (Azure ATP integration must be enabled). We would love to get your insights!
