Alerting – Operations Management Suite

So far, we have the domain & forest set up. I’ve already configured an OMS workspace, and added the VMs to it. We’ve cranked up the auditing via GPO after setting all the time correctly, now lets get some alerts going on to let us know something nasty might be going on.
To access (and create a workspace), you can go to https://mms.microsoft.com and sign in with a Microsoft account. We can link the workspace to an Active Directory environment later. Once you’ve gone through creating the workspace, you have several options to deploy the client. You can get data in to OMS using SCOM, or you can put the client on by manually running the MSI file, using PowerShell DSC or from within the Azure portal, connecting the client. I chose the latter and connected the VMs through the Azure portal. I have previously used the MSI File method. As part of setting up the workspace, you will get a notification about some suggested alerts. It’s worth enabling these as they include clearing of event logs. Often attackers will clear an event log to hide their tracks.
OMS can send notifications of events using Emails, Webhooks, execute a runbook (maybe to revert a change) or raise a ticket in an ITSM instance. For this I will just use email, it’s served me well so far and it has no costs associated with it.
After the agent/extension is installed and reporting in you can start receiving alerts based on event log entries. In this post, we will go through creating our first batch of alerts. Once again, Microsoft do provide a list of events to look out for, a link to this document can be found at the end of this post. To create an alert, once you’re signed in to OMS and your workspace, click Log Search on the left hand side. In the search bar, enter the following string:
Type=SecurityEvent EventID=4794
This will look for any recorded change to the DSRM password. Given this password is the one that will be required in the event of a DR scenario, we want to know if this has changed. It should return 0 results. To set up the alert, look at the icons in the top left of the page and click the Alert button with a bell icon. Fill in the form, make sure that you set the number of results to be greater than 0. Once you’ve completed the form, select Save in the bottom left. That’s it you’re done.
If you didn’t enable the suggested alerts, you can use the following query to create an alert for event logs being cleared:
Type=SecurityEvent (EventID=1102 OR EventID=517) EventSourceName=Microsoft-Windows-Eventlog | measure count() by Computer
Once you’ve set up the alert, clear a security log and see if you get the notification through!
Now we have a couple of basic alerts created, we are going to create some alerts based on group membership changes. AD has several groups that you want to know when the membership changes. A full list of privileged groups can be found in the doc linked at the end of this post, however we are going to setup alerts for the following groups being changed:

  • Domain Admins (Global security group)
  • Enterprise Admins (Universal security group)
  • Schema Admins (Universal security group)
  • Built-in Administrators (Domain-local security group)
  • Account Operators (Domain-local security group)
  • Backup Operators (Domain-local security group)
  • Cert Publishers (Domain-local security group)
  • Cryptographic Operators (Domain-local security group)
  • DHCP Administrators (Domain-local security group)
  • DnsAdmins (Domain-local security group)
  • Hyper-V Administrators (Domain-local security group)
  • Print Operators (Domain-local security group)
  • Server Operators (Domain-local security group)

The golden groups that will want to be monitored are the top 5. I’ve made a note of the scope of these groups as this will impact the Event IDs we are searching for within OMS. Membership to these groups should be changing very sporadically and so any change should be scrutinised and approved before being completed. The EventIDs for these events are as follows:

  • Domain Local: Add – 4732, Remove – 4733
  • Universal: Add – 4756, Remove – 4757
  • Global: Add – 4728, Remove – 4729

For the enterprise and schema admins groups, we use the following queries:
ADD: Type=SecurityEvent EventID=4756 TargetUserName="Schema Admins"
REMOVE: Type=SecurityEvent EventID=4757 TargetUserName="Schema Admins"
ADD: Type=SecurityEvent EventID=4756 TargetUserName="Enterprise Admins"
REMOVE: Type=SecurityEvent EventID=4757 TargetUserName="Enterprise Admins"

For the domain admins group, we use the following queries:
ADD: Type=SecurityEvent EventID=4728 TargetUserName="Domain Admins"
REMOVE: Type=SecurityEvent EventID=4729 TargetUserName="Domain Admins"

For the remaining domain local groups we will use the following alerts:
ADD: Type=SecurityEvent EventID=4732 TargetUserName="Builtin\\Adminstrators"
REMOVED: Type=SecurityEvent EventID=4733 TargetUserName="Builtin\\Adminstrators"
In the example above I show how to monitor the Built-in Administrators group. For the normal Domain Local groups, you can use the name of the group in the same way as the global and universal group alerts. You can choose the severity of the alerts, I use critical for add and warning for remove.
There will be more alerts coming through as we start putting in protections. For additional reading see the links below.
MS Doc for Events to Monitor: https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/appendix-l–events-to-monitor
MS Doc for Privileged Accounts: https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/appendix-b–privileged-accounts-and-groups-in-active-directory

Leave a Reply

Your email address will not be published. Required fields are marked *