Domain Controller User or Group Modification

[dmontgomery]

Hello All:

We want to modify the Domain Controller User or Group Modification rule to give it a more narrow focus on Privileged groups only. Has anyone done this already and could share what you did?

Regards,

David

[sioannou]

Hi David, 

There are two ways to achieve this. Either utilising the account SID or the Account name. But to achieve this you need to modify the WinOSWmiParser. 

In the parser search for the following line "$_id IN '4722, 4723, 4724, 4725, 4738'"

 The above are the windows event IDs for account changes. 

Modify the parser to capture the Target Account SID and Username. 

From there you can follow two paths for the rule optimisation:

1) Create an exception per SID or User Name 

2) Create a new Watch List called Privileged Users and either include the SID or User name and add them as a match to the rule for trigger. 

Regards,

S

[dmontgomery]

Thanks - I will play around with this and see.

Can I assume this will work with Group SIDs as well as user?

[sioannou]

Yes it will work for both, have a look at the parser I think there are certain Event IDs that the SID is not parsed but that can be easily fixed with mapping the attribute under the specific event type. 

Regards,

S

[dmontgomery]

Hello: We played around with different permutations and came up with these conditions:

Reporting IP IN Applications: Domain Controller AND

Event Type IN Win-Security-641, Win-Security-659, Win-Security-654, Win-Security-664, Win-Security-4737, Win-Security-4750, Win-Security-4755, Win-Security-4760 AND

Target User Group IN Enterprise Admins, Domain Admins

This works if run in a report and it can run as a query from the rule editor but when I create a notification policy on the rule we are not getting alerts via email nor does it generate at incident.

Any thoughts?

regards,

David

[FSM_FTNT]

can you attach your rule XML?

[dmontgomery]

Here it is

<rules><DataRequest active="true" advanced="true" custId="1" dataChangeType="SYSTEM" dataCreationType="USER" dbId="294759852" debug="false" entityVersion="13" fireInternalIncident="false" functionCategory="Security" id="294759852" naturalId="PH_Rule_Change_3__DUP_1_1708609220964" phIncidentCategory="Application" subFunction="PH_RULE_SECURITY_Application" technique="T1098.001" type="Rule">
<Name>Sandvine - Domain Controller User or Group Modification 2024-02-22</Name>
<Description>Detects user/group configuration in a domain controller. This rule would trigger on all changes made by any person. To prevent false positives, a restriction on the user attribute should be made by excluding the domain administrators.</Description>
<Remediation/>
<CustomerScope groupByEachCustomer="true">
<Include all="true"/>
<Exclude/>
</CustomerScope>
<PatternClause window="300">
<SubPattern id="294759904" name="DCUserGrpChange">
<SingleEvtConstr>reptDevIpAddr IN (Group@PH_SYS_APP_DOMAIN_CONTROLLER) AND eventType IN ("Win-Security-641","Win-Security-659","Win-Security-654","Win-Security-664","Win-Security-4737","Win-Security-4750","Win-Security-4755","Win-Security-4760") AND targetUserGrp IN ("Enterprise Admins","Domain Admins")</SingleEvtConstr>
<GroupEvtConstr>COUNT(*) &gt;= 1</GroupEvtConstr>
<GroupByAttr>targetDomain,targetUserGrp,domain,computer,user,reptDevName</GroupByAttr>
</SubPattern>
</PatternClause>
<IncidentDef eventType="Sandvine_Domain_Controller_User_or_Group_Modification_2024_02_22" eventTypeGroup="PH_SYS_EVENT_PH_RULE_SEC" fireFreq="86400" severity="9">
<ArgList>
hostName = DCUserGrpChange.reptDevName, user = DCUserGrpChange.user, computer = DCUserGrpChange.computer, domain = DCUserGrpChange.domain, targetUser = DCUserGrpChange.targetUser, targetDomain = DCUserGrpChange.targetDomain
</ArgList>
</IncidentDef>
<DynWatchListDef/>
<userRoles>
<roles custId="1">962501</roles>
</userRoles>
<TriggerEventDisplay>
<AttrList>phRecvTime,reptDevIpAddr,eventType,user,computer,domain,targetUser,targetDomain,rawEventMsg</AttrList>
</TriggerEventDisplay>
<IncidentTitle>$user modified $targetUser account on $hostName domain $domain</IncidentTitle>
</DataRequest>
</rules>

[sioannou]

Usually this is an indicator of a mistake in the rule. Start by investigating matching conditions and the rule it self. Running a test on the rule while it is inactive is highly recommended, if you fail to receive a response during testing then 99% of the time there is a mistake in the rule. 

From there check the /opt/phoenix/log/phoenix.log for further details. 

S

[FSM_FTNT]

I have updated the rule and tested in the lab, please see attached. It now triggers.

I believe I know how the problem occured once you cloned the system rule.

When deleting the target user from the rule group by conditions it let the targetUser in the argg list:

<ArgList>
hostName = DCUserGrpChange.reptDevName, user = DCUserGrpChange.user, computer = DCUserGrpChange.computer, domain = DCUserGrpChange.domain, targetUser = DCUserGrpChange.targetUser, targetDomain = DCUserGrpChange.targetDomain</ArgList>
</IncidentDef><DynWatchLists/><TriggerEventDisplay>
<AttrList>

I will check further into this issue.

[dmontgomery]

This works if I run it as a query or as a report but it does not generate and incident or trigger the notification policy.