Explorer

Question

Domain Controller User or Group Modification

Forum|Forum|2 years ago
February 15, 2024
6 replies
3499 views

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

Fortisiem

sioannou

Explorer II

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

dmontgomeryAuthor

Explorer

Thanks - I will play around with this and see.

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

sioannou

Explorer II

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

dmontgomeryAuthor

Explorer

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

Staff

can you attach your rule XML?

dmontgomeryAuthor

Explorer

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(*) >= 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

Explorer II

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

Staff

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.

rule2_xml.zip

dmontgomeryAuthor

Explorer

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.

FSM_FTNT

Staff

Hi, I tested this in the lab on 7.1.x and an incident is generated. Silly question maybe, but the rule is enabled after you imported it, right?

Have you got one of the raw logs that you believe it should trigger on? I could replay them and check the rule in the lab.

dmontgomeryAuthor

Explorer

Our version is 6.7.9.1763.

Here is the raw event:

Sign up

Login with SSO

Login to the community

Login with SSO