06-Update-RoleGroupMember.md
September 29, 2023 · View on GitHub
Update-RoleGroupMember
Table of contents:
Overview
Why it matters?
A threat actor can run a Command (Cmdlet) to replace the entire membership list of an Microsoft Defender for Office (MDO), Purview Compliance or Exchange Online (EXO) role group with an account they've compromised, or clear out this membership list completely as a method of Impact. This would cause a denial of service as it would remove role permissions from legitimate users. In this scenario, it's important to be able to understand exactly what has happened to answer questions like:
- Which role group was impacted?
- Was the role group membership list cleared completely or replaced with an account instead?
This page will help you investigate the audit event for the Update-RoleGroupMember operation from a DFIR perspective in terms of:
- Useful fields and the insight we can gain from them
- Key fields of note and if applicable, how to decipher them
Pre-Requisites
- Ensure you have access to the Audit Log following the guide in 01-Access
- Search for the Update-RoleGroupMember operation, adjusting the date/time range and if applicable, including other relevant criteria to refine the search.
| Operation | RecordType | RecordType Name | Screenshot (Note: Some personal fields have been redacted) | Description |
|---|---|---|---|---|
| Update-RoleGroupMember | 1 | ExchangeAdmin |  | Update-RoleGroupMember is an operation logged when an admin runs a command to modify the membership list of a MDO, EXO or Purview Compliance role group. |
Note
The screenshot above shows the full audit record for this operation. Right click on it and open in a new tab to see a larger version. Fields from this will be referenced throughout so follow along.
Useful fields
| Field | Insight (Source) |
|---|---|
| CreationTime | From this, we know that the command was run on "2nd September 2023 at 1:07 PM UTC" |
| ObjectId | From this, we know that the role group impacted was "IR Audit Logs Reader" |
| UserId | From this, we know that that the user that ran the command was "MiriamG@domain(.)onmicrosoft.com" |
| ResultStatus | From this, we know that the command executed successfully; value of "True" |
| ClientIP | From this, we would know which IP address the command was ran from. In this case, it's been redacted. |
Other useful fields
| Field | Insight |
|---|---|
| AppId | From this, we know that the Application ID of the application that performed this operation was "fb78d390-0c51-40cd-8e17-fdbfab77341b". This resolves to Microsoft Exchange REST API Based Powershell. This shows that Exchange Online PowerShell was used to run this command. |
Key fields of note
The Parameters object shown below contains useful information relating to this operation:
| Field | Insight |
|---|---|
| Parameters.Name.Confirm | From this we can see the command was ran with a hidden confirmation prompt; value of "False" |
| Parameters.Name.BypassSecurityGroupManagerCheck | From this we can see the command was run with a flag to override the security group management check, value of "True". More information on this field is in the "Important" section directly below. |
| Parameters.Name.Members | From this we can see that the user that replaced the previous membership list for this role group was "DiegoS" |
| Parameters.Name.Identity | From this, we get further confirmation that the role group impacted was "IR Audit Logs Reader" |
Important
Parameters.Name.BypassSecurityGroupManagerCheck doesn't apply for MDO and Purview Compliance role groups. This flag is only applicable for EXO Role Groups. The below points will help to better explain this parameter:
- Every EXO Role Group has a "ManagedBy" property. This property specifies who can modify the membership of the role group and can be retrieved using EXO PowerShell. A screenshot showing the "ManagedBy" output for the "IR Audit Logs Reader" EXO role group can be found here. From this we know, the role group membership can only be modified by the "Organization Management" group and "MeganB". We've seen previously that typically only Global Admins are added to "Organization Management" and for this scenario, we have made sure MiriamG is not a global Admin. So how was MiriamG able to modify the membership successfully? Read on.
- It's possible using EXO PowerShell to retrieve any EXO custom role groups that have the "Role Management" permission assigned and then use Get-RoleGroupMember to find out members of this role group. A screenshot showing the steps to achieve this with the output can be found here. From this we can see that there is an "EXO Role Management" role group with the "Role Management" role and that MiriamG is a member of this role group.
- Any user with the "Role Management" role can, by default, update the membership for any EXO Role Groups that don't have the "ManagedBy" property populated. If the "ManagedBy" property is populated and the user with "Role Management" role isn't part of the "ManagedBy" property then the User would have to use the "BypassSecurityGroupManagerCheck" flag to update membership, otherwise it would fail. A screenshot showing this failure can be seen here and a screenshot showing success when using the flag can be seen here.
- It's important to stress that ONLY a user with the "Role Management" permission can use this bypass flag to update the membership of EXO groups that have the "ManagedBy" property populated.
- As stated at the start, this Cmdlet can be used to replace the entire membership list so you might be wondering how did the membership look like prior to this change? A screenshot of this can be found here, note the time! In other words, there were five previous members in this role group who would have simultaneously lost their permissions as they were replaced with DiegoS.
Note
As hinted at towards the start, the entire membership list could be cleared out by a threat actor as a more destructive technique. A screenshot showing the command to achieve this with the output can be found here. Note the "-Members null scenario would be the same as the one at the top of this page apart from the Parameters.Members field having a value of "" .
Fields to Decipher
None 👌🏽
Next Steps
Now that you've seen how to interpret the audit log record for when an entire membership list of an MDO, Purview Compliance & EXO Role Group is replaced by a compromised account, what can you do?
- Ensure you're regularly taking inventory of role groups with their memberships & ideally there should be a change/incident record for role group membership changes. This is so that if a scenario similar to this were to happen, it could be quickly remediated.
- Ensure that principle of least privilege is followed in that only users who have legitimate need to modify role group memberships have the "Role Management" role assigned.