- Introduction
- Why is important to monitor admin MFA changes?
- Sentinel Alert queries for this controls
- Sentinel Query for new Accounts where an admin has performed an MFA change or adding a new existing method
- Sentinel Query for Existing Accounts where an admin has performed an MFA change
- NIST Framework (SP 800-53) monitoring MFA changes control benefits
- ISO/IEC 27001 Monitoring MFA changes control benefits
Introduction
Monitoring changes to Multi-Factor Authentication (MFA) settings is a critical aspect of maintaining robust security practices
As we evolve in the new cloud era with AI, there has been a high demand on standards to maintain MFA methodology. It is certainly true that password only is not good enough in this era . MFA is the new password. However, MFA can also be hijacked using different methods or even worst your administrators can get also hacked.
if you are using service reset password in azure ad introducing a change on an account like replacing the MFA can lead into unathorized access if the request were not to be legitimate or the admin doing the change is compromised
This post covers ideas on such changes, and also I have provided some sentinel queries that can enhance this controls, including the risk possible solutions for the MFA changes.
Why is important to monitor admin MFA changes?
- Enhanced Security Posture: MFA adds a layer of security by requiring more than one form of verification to authenticate a user’s identity. Monitoring MFA changes helps ensure that this crucial security feature is properly configured and maintained, reducing the risk of unauthorized access from admin accounts. Teams should be monitoring and confirming these changes following and adhering with PIM or access on demand.
- Detection of Unauthorized Changes: By tracking changes to MFA settings, organizations can quickly detect unauthorized or suspicious activities, such as an attacker attempting to disable MFA to facilitate further malicious actions. This rapid detection enables timely responses to potential security threats.
- Compliance with Regulations: Industry standards and government regulations require the implementation of MFA for accessing sensitive data. Monitoring these settings ensures compliance with such regulations, helping organizations avoid legal and financial penalties.
- Forensic and Investigative Capabilities: If a security breach occurs, having detailed logs of MFA changes can be invaluable for forensic investigations. This data helps in reconstructing events to understand how the breach occurred and identifying any compromised accounts.
- Accountability and Transparency: Monitoring MFA changes promotes accountability within an organization. It ensures that any changes to MFA settings are traceable to specific users, which deters malicious or negligent behaviour by making users aware that their actions are recorded.
- Maintaining User Trust: Ensuring that MFA settings are securely managed helps maintain user trust, particularly for clients and partners who rely on the organization to safeguard their data and accounts accessing such data
- Operational Reliability: Regular monitoring helps verify that MFA systems are functioning as intended. This is crucial for avoiding disruptions caused by misconfigurations or failed MFA mechanisms, which could prevent legitimate access to systems and data.
The risk of MFA changes
- Modify or update MFA changes in azure AD can lead to unauthorized access for this specific Reason we must monitor and control with appropriate access controls who, when and how these changes are being made in order to protect the admins if their accounts were compromised
- Locking down these actions could stop a threat actor in case that could trick an engineer using voice cloning or any other type of social engineering as there is strict monitoring and combination of the Authentication role administrator using PIM (privileged identity management
Threat actors (what can go wrong)
Scenario 1 – Hijacking IT member account when authentication administrator role is not active (PIM) what to do?
- In order for the threat actor to be successful to hijack or change an MFA account using the IT team’s permissions would have to trick and figure how to trigger the PIM request, such request to be approved & once the change performed the alert has to be missed by the security team, since the threat actor does not know this process it has to figure it out, this gives extra time for the security team to effectively catch this.
- Mitigations using Role segregation when approving PIMS: Implement strict controls in PIM requests like ticket reference numbers , HR approvals & use different teams to approve the PIM. Do not allow IT teams to approve their own PIMS
- Allow only certain Administrative units to be used by the IT team, identify valuable assets like directors or application admins & establish a different workflow as for example if any Privileged roles or high risk accounts need an MFA reset must accordingly present in the physical office due security reasons and go over extra identification processes ( including physical)
Scenario 2 – Hijacking IT member account when authentication administrator role is active (PIM) what to do?
- The threat actor if lucky should or could steal the token of the IT engineer using social engineering or phishing when PIM is activated
- The Threat actor starts hijacking MFA accounts
- The less, the better: Certainly limit what accounts can perform these duties of MFA changes .
- Training : Train admins that can perform MFA changes .
- Mitigations Role activation time : Ensure role activation time is no more than 30 minutes
- Mitigations BYOD for Admins : Do not allow admin accounts to use personal devices . Limiting to the corporate device enhances posture ( most likely you are running an EDR in those machines )
- Mitigations using UEBA : Implement behaviour analytics to replicate such scenario, perform drills. How a hacker would effectively leave footprints on this behaviour ? Can this be replicated into an alert?
- Passwordless MFA & password strength : Activate passwordless MFA and implement 20 character passwords in the Admin accounts, although it does not directly mitigate the threat, certainly makes it a hard time for the threat actor.
Strengthening the process to the next level for MFA
- Review every quarter your process to show strength in security posture based on the threat intel and actual threats (remember, technology evolves, so do the hackers) . This also involves reviewing the technical changes
- Introduce in the PIM request where the username or usernames are shown in the PIM Request
- Sentinel Automations can detect if in a PIM request the username provided and ticket number is not correct, can raise or block the account that is attempting this change. As for example if in the PIM description there is usernameX however sentinel detects a change on a UsernameY . This can be matched and appropriate action or alert can be raised.
- Allow only PIM requests for authentication administrator to be done in hardened devices
- Extra Alerting to other teams : MFA changes should always be informed and approved by an HR department having an extra process, consider creating alerts for the HR team so they aware of these changes.
- Test that your process is effective: Exercise drills to test the process is robust
- Incident response plan for MFA Hijack : Have an incident response plan where covers using mitre MFA unauthorized changes
- Implement Conditional Access Evaluation ( CAE ) -> https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-continuous-access-evaluation
- Change control : Changes on the MFA process should be subject to change control advisory board
- Monitor changes on MFA : Appropriate monitoring of the PIM setup and configuration change should be put in place
- Introduce security questions in Azure AD SSPR : Mark that is required at least security questions & MFA approval via SMS or App . This questions could include information that only the user knows and are not public . Ensure this information is accordingly removed when the user leaves the company for compliance
Sentinel Alert queries for this controls
In this area I have left a couple of queries that can be handy in order to apply this controls .
Sentinel Query for new Accounts where an admin has performed an MFA change or adding a new existing method

AuditLogs
| where OperationName == "Admin updated security info"
or OperationName == "Admin registered security info"
| extend parsedTargetResources = parse_json(TargetResources)
| mv-expand parsedTargetResources
| extend modifiedProperties = parsedTargetResources.modifiedProperties
| mv-expand modifiedProperties
| where tostring(modifiedProperties.oldValue) != tostring(modifiedProperties.newValue)
| project TimeGenerated, OperationName, InitiatingUser=InitiatedBy.user.userPrincipalName, TargetedUser=parsedTargetResources.userPrincipalName, OldValue=modifiedProperties.oldValue, NewValue=modifiedProperties.newValue
Sentinel Query for Existing Accounts where an admin has performed an MFA change

AuditLogs
| where OperationName == "Admin updated security info"
| extend parsedTargetResources = parse_json(TargetResources)
| mv-expand parsedTargetResources
| extend modifiedProperties = parsedTargetResources.modifiedProperties
| mv-expand modifiedProperties
| where tostring(modifiedProperties.oldValue) != tostring(modifiedProperties.newValue)
| project TimeGenerated, InitiatingUser=InitiatedBy.user.userPrincipalName, TargetedUser=parsedTargetResources.userPrincipalName, OldValue=modifiedProperties.oldValue, NewValue=modifiedProperties.newValue
NIST Framework (SP 800-53) monitoring MFA changes control benefits
NIST Special Publication 800-53 provides a catalogue of security and privacy controls for federal information systems and organizations. Key controls related to monitoring MFA changes include:
- AC-2 (Account Management): Ensures that accounts are managed throughout their lifecycle, including monitoring and controlling changes in user authentication settings.
- AC-6 (The Least Privilege): Enforces the principle of least privilege by monitoring and possibly restricting configurations that might allow users more privileges than required.
- IA-2 (Identification and Authentication): Focuses on ensuring that identification and authentication processes are implemented securely, including mechanisms like MFA.
- AU-12 (Audit and Accountability): Requires the creation, protection, and retention of system audit logs, which would include logs recording changes to MFA settings.
ISO/IEC 27001 Monitoring MFA changes control benefits
ISO 27001 is focused on establishing, implementing, maintaining, and continually improving an information security management system (ISMS). Relevant controls from ISO 27001 include:
- A.9 Access Control: Specifically, control A.9.2.4, which deals with the management of privileged access rights, including the monitoring and review of user access settings.
- A.9.4 System and Application Access Control: This includes controls like A.9.4.2, which ensure secure log-on procedures, and A.9.4.3, which relates to the control of password management and authentication systems.
- A.12.4 Logging and Monitoring: Controls such as A.12.4.1, which involve event logging (including access control events), and A.12.4.3, which requires the administration of logs, ensuring that actions related to MFA settings are recorded and reviewed.

