File Integrity Monitoring and Windows security policies

| by Joe | Wazuh 1.1
Post icon

OSSEC is used for file integrity monitoring by thousands of companies. In this tutorial we will show you how to setup windows group policies, create custom decoders for security events, and apply rules for when an event occurs.

Prerequisites

  • A Manager with Wazuh HIDS v1.1
  • Windows Agent (in this example, we will be using Windows Server 2012 R2)
  • Test Lab (optional)

Step 1: Create a test user on your windows agent

Tools→ Computer management→ Local Users and Groups → Users

We created Jtest (short for Joe test user) and then added the following as my profile path and remote desktop services home folder. Note – This step might be slightly different depending on your environment.

File Integrity Monitoring: Create a test user on your windows agent. Screenshot.

Step 2: Enabling Windows Security Policies (GPO) — This is done on the Windows Agent

On the Server Manager dashboard:

Tools → Local Security policy → Local Policies → Audit Policies

From here we can set  the Audit Object Access policy to log successes and failures

File Integrity Monitoring: Set the Audit Object Access policy to log successes and failures. Screenshot.

On a Windows agent, these settings are needed to trigger a log that contains the user that attempted to access the object (Windows Event ID 4663). Without it, we will not be able to know the which user attempted to access the file.

Here is a list of codes for your reference.

Step 3: Setting up the directory we want to monitor

In order for us to test this, we will want to create a test directory and set the permissions. In this example we created a directory in C:\tmp. From here we will set the windows security policy to audit this folder. Note- Selecting “Everyone” as the principal ensures the policy is active for every user that attempts to access the file.

Right click:
Properties → Security → Advanced → Auditing → Click Add → Select Principal → Everyone

Advanced security settings for tmp. Screenshot.

Next we will want to create a couple of test files in our folder we selected to monitor:

Tmp folder with some test files. Screenshot.

After you have created your test files. Log out and attempt to access one of them and make a change. In this case we altered bank_information.txt which generates a log entry on the OSSEC Manager.

Step 4: Log Analysis

Here is where it can get a little tricky.
All raw logs are sent to the manager and are located in:

$ /var/ossec/logs/archives/archives.log

All processed logs, meaning they have decoders and rules are located in:

$ /var/ossec/logs/alerts/alerts.json

So if you have any prior knowledge of OSSEC and are used to seeing entries for alerts in the alerts.log, you might be confused as to why you are not seeing input from the windows agent. The reason for this, is there isn’t any decoders for the windows Event ID 4663. So you must look in the archives.log file for the raw log format, from here we have to build a decoder in order to process the log, also known as log analysis.

This is the raw windows log which is being sent from the Windows Agent to the manager. We will need this for testing our rules and decoders in ossec-logtest (STEP 5).

2016 Apr 26 19:24:39 WinEvtLog: Security: AUDIT_SUCCESS(4663): Microsoft-Windows-Security-Auditing: (no user): no domain: WIN-UENN0U6R5SF: An attempt was made to access an object. Subject: Security ID: S-1-5-21-2910110503-590998239-2551655963-1006 Account Name: Jtest Account Domain: WIN-UENN0U6R5SF Logon ID: 0xef8f7ee Object: Object Server: Security Object Type: File Object Name: C:\tmp\bank_information.txt Handle ID: 0x134 Process Information: Process ID: 0x9bc Process Name: C:\Windows\System32\notepad.exe Access Request Information: Accesses: %%4416 Access Mask: 0x1

Now that we have our log, we can start the process of building a decoder.
Open <code>/var/ossec/etc/ossec_decoders/windows_decoders.xml</code> and add this to the file. Be sure to put it before <code><decoder name="windows-Evtlog".</code>


<decoder name="windows-EvtLog-4663">
 <use_own_name>true</use_own_name>
 <type>windows</type>
 <parent>windows</parent>
 <regex offset="after_parent">^\.+: (\w+)\((\d+)\): (\.+): </regex>
 <regex>(\.+): \.+: (\S+): \.+: \.+: \.+: \.+: \.+: \.+: \.+: \.+: \.+: (\S+)</regex>
 <order>status, id, extra_data, user, system_name, url</order>
 <fts>name, location, user, system_name</fts>
</decoder>

Next we create the rule for the decoder.For this we will create the file ms-user.xml and add it to the the rules directory.

Open  /var/ossec/rules/ms-user.xml and add the following line:

<rule id="90015" level="0">
       <if_sid>90000</if_sid>
       <match>Accesses: %%4416</match>
       <description>Windows User attempted to access an object</description>
   </rule>
  </group>

Be sure to add it to the ossec.conf as well, otherwise the rule will not process:

<include>usb_rules.xml</include>
<include>opensmtpd_rules.xml</include>
<include>ms-user_rules.xml</include>
<include>local_rules.xml</include>

Next, restart the manager to load the rules and decoders.

$ /var/ossec/bin/ossec-control restart

Step 5: Using log-test to checking your rules and decoders

Ossec-logtest is designed to help troubleshoot and test custom decoders and rules. It is essential to learn how to use this tool if you need to build customized rulesets.

After adding in the rule and decoder we will need to paste the raw log output into ossec-logtest to make sure it fires correctly.

Example:

$ /var/ossec/bin/ossec-logtest

ossec-testrule: Type one log per line.

2016 Apr 26 19:24:39 WinEvtLog: Security: AUDIT_SUCCESS(4663): Microsoft-Windows-Security-Auditing: (no user): no domain: WIN-UENN0U6R5SF: An attempt was made to access an object. Subject:  Security ID:  S-1-5-21-2910110503-590998239-2551655963-1006  Account Name:  Jtest  Account Domain:  WIN-UENN0U6R5SF  Logon ID:  0xef8f7ee  Object:  Object Server: Security  Object Type: File  Object Name: C:\tmp\bank_information.txt  Handle ID: 0x134  Process Information:  Process ID: 0x9bc  Process Name: C:\Windows\System32\notepad.exe  Access Request Information:  Accesses: %%4416  Access Mask: 0x1

**Phase 1: Completed pre-decoding.
full event: '2016 Apr 26 19:24:39 WinEvtLog: Security: AUDIT_SUCCESS(4663): Microsoft-Windows-Security-Auditing: (no user): no domain: WIN-UENN0U6R5SF: An attempt was made to access an object. Subject:  Security ID:  S-1-5-21-2910110503-590998239-2551655963-1006  Account Name:  Jtest  Account Domain:  WIN-UENN0U6R5SF  Logon ID:  0xef8f7ee  Object:  Object Server: Security  Object Type: File  Object Name: C:\tmp\bank_information.txt  Handle ID: 0x134  Process Information:  Process ID: 0x9bc  Process Name: C:\Windows\System32\notepad.exe  Access Request Information:  Accesses: %%4416  Access Mask: 0x1'
hostname: 'vpc-ossec-manager'
program_name: '(null)'
log: '2016 Apr 26 19:24:39 WinEvtLog: Security: AUDIT_SUCCESS(4663): Microsoft-Windows-Security-Auditing: (no user): no domain: WIN-UENN0U6R5SF: An attempt was made to access an object. Subject:  Security ID:  S-1-5-21-2910110503-590998239-2551655963-1006  Account Name:  Jtest  Account Domain:  WIN-UENN0U6R5SF  Logon ID:  0xef8f7ee  Object:  Object Server: Security  Object Type: File  Object Name: C:\tmp\bank_information.txt  Handle ID: 0x134  Process Information:  Process ID: 0x9bc  Process Name: C:\Windows\System32\notepad.exe  Access Request Information:  Accesses: %%4416  Access Mask: 0x1'

**Phase 2: Completed decoding.
       decoder: 'windows'
       status: 'AUDIT_SUCCESS'
       id: '4663'
       extra_data: 'Microsoft-Windows-Security-Auditing'
       dstuser: '(no user)'
       system_name: 'WIN-UENN0U6R5SF'
       url: 'C:\tmp\bank_information.txt'

**Phase 3: Completed filtering (rules).
       Rule id: '90015'
       Level: '5'
       Description: ' User attempted to access a file'
**Alert to be generated.

Next go to your windows agent again, and click on one of your test files.

Now, check to make sure the decoders and rules are working:

On the manager

$ tail -f /var/ossec/logs/alerts/alerts.json

Remember this is where the processed logs are. As you can see our rule is being triggered and the log is being decoded properly.

{"rule":{"level":5,"comment":" User attempted to access a file","sidid":90015,"firedtimes":156,"groups":["windows"]},"dstuser":"(no user)","full_log":"2016 Apr 26 18:40:40 WinEvtLog: Security: AUDIT_SUCCESS(4663): Microsoft-Windows-Security-Auditing: (no user): no domain: WIN-UENN0U6R5SF: An attempt was made to access an object. Subject:  Security ID:  S-1-5-21-2910110503-590998239-2551655963-1006  
Account Name:  Jtest  Account Domain:  WIN-UENN0U6R5SF  Logon ID:  0xef8f7ee  Object:  Object Server: Security  Object Type: File  Object Name: C:\\tmp\\bank_information.txt  Handle ID: 0x134  Process Information:  Process ID: 0x974  Process Name: C:\\Windows\\System32\\notepad.exe  Access Request Information:  Accesses: %%4416  \t\t\t\t  Access Mask: 0x1","id":"4663","status":"AUDIT_SUCCESS","url":"C:\\tmp\\bank_information.txt","data":"Microsoft-Windows-Security-Auditing","systemname":"WIN-UENN0U6R5SF","decoder":{"name":"windows"},"hostname":"vpc-agent-windows","agentip":"10.0.0.124","timestamp":"2016 Apr 26 11:37:38","location":"WinEvtLog"}

If you have configured the Kibana dashboards using Wazuh Hids,  you will be able to see your alert represented on the dashboard along with the user which changed the file. This is our final result after adding the rule and decoder resulting in a correct file integrity monitoring.

Alert on Kibana dashboard, using Wazuh. Screenshot.

If you have any questions about file integrity monitoring, join our Slack community channel! Our team and other contributors will help you.