Active Directory | Unable to Find Track Admin Level Users

243 views
Skip to first unread message

John Carry

unread,
Feb 8, 2023, 11:47:52 PM2/8/23
to Wazuh mailing list
Dear Team,
We have integrated Active Directory with our Wazuh, and observing many other Alerts to investigate as per our routine tasks but unable to found any such alert or event that could help us to find admin users like one of the well-known event ID and Name to detect privilege users is 4672 with description "Special privileges assigned to new logon".

I have also created rule to match event ID 4672 but still no alerts observed, you are requested to share any guidelines to detect such logs that would help us to detect admin level users in our environment.

Or anyother way to detect domain admin would be highly helpful.


Ujunwa Okonkwo

unread,
Feb 11, 2023, 8:06:41 PM2/11/23
to Wazuh mailing list
Dear John,

Thank you for using Wazuh.

Wazuh monitors security logs by default. Please share the rule that you created and ensure you have enabled archives.log, so you can be sure the logs are getting to the manager.

Refer to this guide for:

I hope this is helpful.

Thank you.

Regards,

John Carry

unread,
Feb 13, 2023, 1:17:20 AM2/13/23
to Wazuh mailing list
I think you are unable to understand my query, just confirm below point

 Is there any need to modify the agent config file at AD end in-order to fetch all possible logs? or by-default the agent will forward every possible event to manager ?

Ujunwa Okonkwo

unread,
Feb 13, 2023, 2:19:27 AM2/13/23
to Wazuh mailing list
Hello John,

Yes, there is need to create custom rules by modifying the agent's config file in order to collect some special event logs.

If you want to make a rule with 4672, you can create a custom one using <field name="win.system.eventID">^4672$</field>. You can see more about custom rules in the following link below:
https://documentation.wazuh.com/current/user-manual/ruleset/custom.html

If you were to use a Wazuh Agent to collect these events, you would need to set the correct location  to your localfile module.
To get the correct location, you need to go to the Windows Event viewer, search for the event you're attempting to ingest, open it and check its Details in XML view. There the field channel contains the location you need to set.
For example, in order to fetch events with eventID = 4672, you would need to set a localfile module with "Security" as location. Check that you have it correctly configured in the windows agent.
On the other hand, check the ossec.log file of the agent that is generating this event to confirm that there is no error when connecting to the security channel.
Finally, to confirm that the event is reaching the manager for correct decoding and correlation with the rule, activate <logall_json>yes</logall_json> in your manager. For this, go to the file /var/ossec/etc/ossec.conf and activate the option:
<ossec_config>
  <global>
    <jsonout_output>yes</jsonout_output>
    <alerts_log>yes</alerts_log>
    <logall>no</logall>
    <logall_json>yes</logall_json>
    . . .
  </global>

After this, check if the alerts are generated correctly from the events, if the alerts are not generated you should review the rules, you can test if an alert will be generated using wazuh-logtest

Then, run filebeat test output to see if filebeat is properly sending the alerts to wazuh-indexer.

Then check if the indices in wazuh-indexer are being created correctly:
curl -XGET -k https://localhost:9200/_cat/indices?pretty -u admin:password
There should be a wazuh-alerts-* index for each day and there must not be red indices.

Also check the health of your wazuh-indexer  cluster:
curl -XGET -k https://localhost:9200/_cluster/health?pretty -u admin:password
If the indices are not showing correctly maybe there is a connection problem between your wazuh-indexer  and filebeat, or wazuh-indexer  is taking too long indexing the data due to a high volume of alerts and not having enough resources

Also, if everything else seems correct check if wazuh-dashboard cannot retrieve the  information from the indexer due to a connection or authentication issue.

Then, restart the manager and check that you get this alert is in your /var/ossec/logs/archives/archives.json file. This way you can confirm that this event has occurred in the agent and has been retrieved by the manager.

Remember to disable the logall option after you are done cause they can use a lot of disk space.

Regards,

Reply all
Reply to author
Forward
0 new messages