Microsoft Secure Tech Accelerator
Apr 03 2024, 07:00 AM - 11:00 AM (PDT)
Microsoft Tech Community
Alert when a group is added to a sensitive Active Directory group
Published Jun 07 2022 09:00 AM 12.6K Views
Iron Contributor

Hi everyone, it’s Gershon, back again with a follow up to my last blog where we were able to track changes to sensitive groups with Advanced Hunting in Microsoft 365 Defender.  One of the questions I had from a customer after they read through the blog was “how can we be alerted directly when a group has been added to a sensitive group?”. This is a great question to focus on, as this scenario should not be commonplace in an established environment, as nested group memberships in sensitive groups should not be something that changes after initial set up. Additionally, adding a group to another group is a quick and easy way to add users to a sensitive group and making sure it’s highlighted quickly could stop an attacker from gaining persistence.  

 

We will start by assuming that all the steps from my previous blog have been completed, where we can see all the changes to the groups we defined as sensitive.

 

In this blog, we will take things further by:

  • Updating the advanced hunting query to focus on groups that are added to a sensitive group.
  • Validating that the query works as expected.
  • Creating a custom detection policy based on the advanced query.
  • Testing out the custom detection policy.

 

Updating the advanced hunting query to show additions of a group to a sensitive group.

 

Starting with the query from the last blog as a starting point, we will make a few changes that focuses on activities that occur when adding a group to a sensitive group.

 

In the last line, we will also add the “AccountSid” column as this can be used in the custom detection policy, covered later in this entry.

 

 

let SensitiveGroupName = pack_array(  // Declare Sensitive Group names. Add any groups that you manually tagged as sensitive
    'Account Operators',
    'Administrators',
    'Domain Admins', 
    'Backup Operators',
    'Domain Controllers',
    'Enterprise Admins',
    'Enterprise Read-only Domain Controllers',
    'Group Policy Creator Owners',
    'Incoming Forest Trust Builders',
    'Microsoft Exchange Servers',
    'Network Configuration Operators',
    'Print Operators',
    'Read-only Domain Controllers',
    'Replicator',
    'Schema Admins',
    'Server Operators'
);
IdentityDirectoryEvents
| where Application == "Active Directory"
| where ActionType == "Group Membership changed"
| where DestinationDeviceName != "" // Exclude activities coming from AD Sync changes
| extend GroupModified = tostring(parse_json(AdditionalFields).["TO.GROUP"]) // Extracts the group name if action is add enity to a group.
| where GroupModified in~ (SensitiveGroupName)
| extend GroupAdded = tostring(parse_json(AdditionalFields).["TARGET_OBJECT.GROUP"])
| where GroupAdded  != "" // only show activites that are group being added to another group
| project Timestamp, GroupModified, GroupAdded, Actor=AccountName, Actor_UPN=AccountUpn, ActorSid=AccountSid, AccountSid, ActorDomain=AccountDomain, DC=DestinationDeviceName, ReportId, AdditionalFields
| sort by Timestamp desc 

 

 

 

GersonLevitz_5-1654243502720.png

 

 As you can see here, the results only show groups that have been added to a sensitive group.

 

If you don’t see any results when you run your query, you can either change the time range or add a group to one of the sensitive groups listed in the array at the beginning of the query.

 

Create a custom detection policy

 

After you are comfortable with the query, we can now create the custom detection rule.

  1. Click “Create detection rule” on the top right corner.

GersonLevitz_3-1654505100399.png

 

GersonLevitz_4-1654243438408.png

 

 

  1. On the alert details page enter the required information and click Next. See the screenshot below.

The customer I was working with selected High for Severity as this is not something that should happen often, if at all, in their environment.

For the MITRE techniques the customer chose:

  • T1078 Valid Accounts
  • T1078:002 Domain Accounts
  • T1548 Abuse Elevation Control Mechanism

GersonLevitz_0-1654504769536.png

 

  1. On the Impacted entities page, select User and AccountSid and then click Next. This is the reason we needed to add the AccountSid column in the project line in the query earlier.                                                                                                     GersonLevitz_1-1654504800484.png

     

  2. On the Actions page expand Users. If you have configured an action account in the Defender for Identity settings page, you will have the option to select Disable user and Force password reset actions. If you select one of these actions, Microsoft Defender 365 will attempt to disable the user or reset the user’s password in Active Directory. Click Next to move to the Summary page.GersonLevitz_2-1654504832995.png
  3. On the Summary page, review the rule you’ve created and click Submit.
  4. You will now see the custom detection listed on the Detection rules page

GersonLevitz_4-1654505109829.png

 

Test new custom detection rule

 

Now we want to test that the new rule is working as expected.

 

In Active Directory, create a new group and add this group to a sensitive group. In my lab I created a group named “TestGroupforBlog” and added it as a member of “Domain Admins.”

 

There are different ways that we can search for the alert. Here is one way:

  1. In the Microsoft 365 Defender portal, click on Alerts and then click on Filters.
  2. In the filter pane, click Clear filters, and under Service Sources expand Microsoft 365 Defender and select Custom Detection.GersonLevitz_0-1654500463942.png

     

  3. Click Apply.
  4. Find the alert with title given when you created the custom detection policy earlier and click on the alert to see the details.GersonLevitz_1-1654500507736.png

     

  5. To see the activities that triggered this alert click Query results (1). You can see the sensitive group that was modified (2), the group that was added to the sensitive group (3) and the user who made this change (4).

     

    GersonLevitz_2-1654500718984.png

 

If this is an approved legitimate change, we would want to update the Advanced Hunting query to include this group in the list of sensitive group list for this query and for the query from the previous blog.

 

If this was an unauthorized change, we should continue to investigate the user to see:

  • additional activities they have performed
  • additional alerts open for the user
  • devices the user has logged in to

We can do this using data from all the products in Microsoft 365 Defender.

For more information on investigating threats see, https://docs.microsoft.com/en-us/microsoft-365/security/defender/incidents-overview?view=o365-worldw....

 

So to recap, you just created a query to show activities when a group is added to a sensitive group and then you created a custom detection policy. Congratulations! Feel free to save this query, then customize it further to suit your organization’s needs.

 

If you find the query and custom detection policy helpful, please leave a comment, or use the comment space to tell us what you’ve done to make this query even more powerful in your organization. Please let us know what areas you want to see us tackle next in Advanced Hunting. We can’t wait to hear your ideas. Happy hunting!

Co-Authors
Version history
Last update:
‎Jun 06 2022 10:53 AM
Updated by: