Add-RoleGroupMember

Table of contents:

• Overview
• Useful fields
• Key Fields of Note
• Fields to decipher
• Next Steps

Overview

Why it matters?

A threat actor can add a compromised user to an Exchange Online (EXO) role group as a method of achieving persistence. In this scenario, it's important to be able to understand exactly what has happened to answer questions like:

• Which role group was the user added to?
• Does this role group have any interesting roles assigned to it?

This page will help you investigate the audit event for the Add-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 Add-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
Add-RoleGroupMember	1	ExchangeAdmin		Add-RoleGroupMember is an operation logged when a new member is added to an EXO Role Group.

Useful fields

Field	Insight (Source)
CreationTime	From this, we know that the user was added to the EXO Role group on "30th July 2023 at 6:27 PM UTC"
UserId	From this, we know that that the user was added to the role group by "Admin@Domain(.)onmicrosoft.com"
ResultStatus	From this, we know that the user was successfully added to the role group; value of "True"
ClientIP	From this, we know that the action was performed from "4.231.207(.)170:25935". This is actually a Microsoft IP in Dublin, so in this case the IP of the service has been logged, not the IP of the device.

Other useful fields

Field	Insight
AppId	From this, we know that the Application ID of the application that performed this operation was "497effe9-df71-4043-a8bb-14cf78c4b63b". This resolves to Exchange Admin Center (EAC) which makes sense as the action was performed in the EAC.

Key fields of note

The Parameters object shown below contains some useful information relating to this operation:

Field	Insight
Parameters.Name.Identity	This is hard to interpret, we can see the value is "403c6e5f-34e2-4e89-97c9-c41f8ec015de" but What is this?
Parameters.Name.Member	This is also hard to interpret, we can see the value is "a0992238-4d74-4ca6-93ba-9d0eae3da739" but What is this?

Fields to Decipher

1. Parameters.Name.Identity - 403c6e5f-34e2-4e89-97c9-c41f8ec015de
2. Parameters.Name.Member - a0992238-4d74-4ca6-93ba-9d0eae3da739

Those of you that read 02-New-RoleGroup will remember that searching for a similar random string value in Microsoft Entra ID Users by Object ID didn't give any results, but is it any different here?

It's not clear whether the Parameters.Name.Identity value is for a user or a group so let's search both in Entra ID:

No results for either, interesting. Well we can rightly assume that Parameters.Name.Member must tie back to a user in the tenant so how about if we search for this value in Entra ID Users by Object ID?

Again, no results, alright let's actually decipher these values and see what they mean.

It turns out the value displayed in the Parameters.Name.Identity property is actually the Globally Unique IDentifier (GUID) of the EXO Role Group.

We can use EXO PowerShell with the appropriate permissions to resolve this by using the following command:

Get-RoleGroup 403c6e5f-34e2-4e89-97c9-c41f8ec015de | fl -Property Guid, Name, Roles, Description

This shows that the EXO Role Group that the user was added to is named "IR Audit Logs Reader" and additionally we can see metadata relating to this group including a description but more importantly the roles/permissions associated to this role group.

Note: If you look at the screenshot of the audit event at the top of this page, you'll see that the value of the "Item" and "ObjectId" field is "IR Audit Logs Reader" which tells you the name of the EXO Role Group without deciphering so why does Microsoft hide this in the Parameters Object? Nobody knows!

It turns out the value displayed in the Parameters.Name.Member property is actually the Globally Unique IDentifier (GUID) of the member's EXO Mailbox.

We can use EXO PowerShell with the appropriate permissions to resolve this by using the following command:

Get-User a0992238-4d74-4ca6-93ba-9d0eae3da739 | ft -Property Guid, UserPrincipalName, Name

:mag_right: Therefore we now know that NestorW was added to the "IR Audit Reader" EXO Role Group.

Next Steps

Now that you've seen how to interpret the audit log record for when a member has been added to an EXO role group, what can you do?

• Fortunately there are default alert policies for this kind of activity and now you know how to decipher the audit event for the activity to better understand what has happened from a DFIR perspective.
• A screenshot of this default alert for our particular scenario can be found here.

If the UAL is being sent to a third party SIEM then consider these additional steps:

• Creating a custom alert for when specific members are added to EXO Role Groups
• Creating a custom alert for when members are added to EXO role groups with specific roles associated to them