General
These rules (RULE-1159 and RULE-1160) detect when an administrator with high privileges (tier0) starts a self-service password reset (SSPR) operation. RULE-1159 monitors permanent administrators, while RULE-1160 also monitors users who can activate administrator privileges via Privileged Identity Management (PIM).
Rationale
Self-service password reset is a legitimate feature that allows users to reset their own password without helpdesk assistance. It is normal that administrators also use this feature when they have forgotten their password or need to reset their password for other reasons. However, for administrators with high privileges (tier0), extra attention is warranted because a compromised tier0 account can lead to complete compromise of the organization.
Attackers who have gained access to an administrator account can abuse SSPR to maintain and expand their access. By resetting the password via SSPR, they can set their own password without this being noticed through normal password changes performed by administrators. Additionally, SSPR can be used as part of a brute force attack (see also: MITRE ATT&CK T1110 - Brute Force) or as an account manipulation technique (see also: MITRE ATT&CK T1098 - Account Manipulation).
Because tier0 administrators hold the keys to the kingdom - full control over Entra ID, Exchange, SharePoint, and all other critical systems - it is crucial to validate every SSPR activity from these accounts. A compromised tier0 account can be used for data exfiltration, installing backdoors, privilege escalation, and compromising other accounts within the organization.
Follow-up
Follow these steps to adequately address this detection:
- Immediately contact the administrator in question to validate whether the SSPR operation was deliberately initiated.
-
If no: consider the account as compromised and perform immediate containment:
- Disable the administrator account immediately
- Revoke all active sessions from the account
- Reset the password of the account via a secure channel (not via SSPR)
- Investigate the IP address and location from which the SSPR operation was initiated:
- Is this a known location for this administrator?
- Does the IP address match previous login locations?
- Is there impossible travel (login from two distant locations within a short time)?
- Investigate all activities of the account since the SSPR operation:
- Were new users or groups created?
- Were permissions granted to other accounts?
- Were new application registrations or service principals created?
- Were there changes to Conditional Access policies or MFA settings?
- Was data exported or shared with external parties?
- Were there changes to mailbox forwarding rules or inbox rules?
- Were new Azure resources created?
- Check the SSPR authentication methods of the account - were these modified by the attacker?
-
If no: consider the account as compromised and perform immediate containment:
Attic FIX
A fix will be offered to disable the administrator account, after you have validated that this is malicious behavior. For further investigation you can contact us, Attic can support via our IR service.
Difference between RULE-1159 and RULE-1160
This detection consists of two rules due to different admin configurations:
- RULE-1159: Monitors permanent administrators - users who have been permanently assigned administrator roles (CHK1105_admins list)
- RULE-1160: Monitors PIM-eligible administrators - users who can activate administrator roles via Privileged Identity Management when needed (CHK1106_pimadmins list). This rule requires Azure AD Premium P1 or P2.
The reason for two rules is that organizations can have different admin models. Some have permanent admins, others use only PIM, and still others have a mix. By monitoring both, full coverage is achieved regardless of the chosen model.
Comments
0 comments
Please sign in to leave a comment.