Ossim. WMI plugins with a crisp. Recipe

Good day, dear readers.

I want to share with you my experiments to collect Windows event logs in OSSIM without the use of agents, i.e. using WMI plugins.

These plugins use the WMI interface and, accordingly, the wmi client to collect event logs. The use of these plugins is not recommended, but rather is NOT recommended by the vendor (Alienvault) method of collecting event logs of target systems. They argue that this method uses much more system resources than gathering event logs using the OSSEC agent. This is true, and besides this, when using WMI, events may simply disappear, or the minutes may be delayed by 20-30, which, of course, is not acceptable.

In addition, regular WMI plugins are made in such a way that they do not receive practically any useful information from Windows logs. Only the Windows event ID (numeric and its translation into a human language, for example: 4624 - An account was successfully logged on), the name of the log (Security, System, Application ...), a timestamp and a huge message of the message field (which receives all useful information) information - IP addresses, user names, UAC settings, etc.). Therefore, to get some useful information, the message field must be subjected to additional parsing, i.e. regular WMI plugins need to be further configured. Without this setting, a regular WMI plugin is almost useless.
')
If, nevertheless, the situation forces you to use not the OSSEC agent, but WMI plug-ins, I will tell you how to reduce the number and reduce the size of the rake that you will encounter along the way, namely:

1. How to set up receiving additional data from event logs collected via WMI;
2. How to diagnose and troubleshoot the WMI plugin.

1. Retrieving additional data from event logs collected via WMI

I will consider this task on the example of getting the user name. The algorithm for setting up any other data will be similar.

To obtain additional data, the “custom functions” functionality is used, which allows applying a samopisny function to any field received via WMI. This function will parse the message field of the Windows log and place the resulting value (user name) in the username field of the event displayed in OSSIM.

First, take a look at the regular wmi-security-logger plugin. As can be seen from its configuration file, located in /etc/ossim/agent/plugins/wmi-security-logger.cfg, it executes two WQL (SQL for WMI) queries, the first of which (the cmd field in the start_cmd section) gets the number events starting from which the log is being read, and the second (the cmd field in the cmd section) already reads the log. Here is an example of a second query reading the log:

Select ComputerName,EventCode,Logfile,Message,RecordNumber,SourceName,TimeWritten,User from Win32_NTLogEvent Where Logfile = 'Security' and RecordNumber > OSS_COUNTER 

These fields from the Windows log are read by the plugin:

ComputerName, EventCode, Logfile, Message, RecordNumber, SourceName, TimeWritten, User
You should not build hopes on the “User” field, in Windows 2008R2 and more recent it gets the value “null”.

Thus, the most informative field is “message”. From it using the function we will get the user name.

If you look at the Windows log examples, you will see that there are two constructs containing the user name:

1) Logon Account: <username>
An example of a "raw" event, as OSSIM sees it:

 nsrv_WinSRV-DC.domain.test|4776|Security|The computer attempted to validate the credentials for an account.\r\n\r\nAuthentication Package:\tMICROSOFT_AUTHENTICATION_PACKAGE_V1_0\r\nLogon Account:\tAdministrator\r\nSource Workstation:\tALIENVAULT\r\nError Code:\t0x0|17507786|Microsoft-Windows-Security-Auditing|20170410111356.914996-000|(null) 

2) Account Name: <username>
An example of a "raw" event, as OSSIM sees it:

 nsrv_WinSRV-DC.domain.test|4672|Security|Special privileges assigned to new logon.\r\n\r\nSubject:\r\n\tSecurity ID:\t\tS-1-5-21-2827692199-2880599349-568663292-500\r\n\tAccount Name:\t\tAdministrator\r\n\tAccount Domain:\t\tDOMAIN\r\n\tLogon ID:\t\t0x2B9EB90D\r\n\r\nPrivileges:\t\tSeSecurityPrivilege\r\n\t\t\tSeBackupPrivilege\r\n\t\t\tSeRestorePrivilege\r\n\t\t\tSeTakeOwnershipPrivilege\r\n\t\t\tSeDebugPrivilege\r\n\t\t\tSeSystemEnvironmentPrivilege\r\n\t\t\tSeLoadDriverPrivilege\r\n\t\t\tSeImpersonatePrivilege\r\n\t\t\tSeEnableDelegationPrivilege|17507787|Microsoft-Windows-Security-Auditing|20170410111356.914996-000|(null) 

Thus, we need a function that can get the user name from both of these structures. Functions that are used in plugins should be written in python 2.7 and stored in a separate file, the path to which will be written in a special variable in the configuration of the plug-in.

Please note that in the "raw" log \ r, \ t, \ n are all special characters, i.e. carriage return, newline and tab.

For files that store functions there is a special daddy - / etc / ossim / agent / plugins / custom_functions. The function file for obtaining additional information from the WMI log is named “wmi_funcs.cfg”.

Here are its contents:

 Start Function win_account import re def win_account(self, input=''): try: try: res = re.search( 'Logon Account:[^\w]t(\S+)[^\w]r[^\w]', input ).group(1) return res except: res = re.findall( 'Account Name:[^\w]t[^\w]t(\S+)[^\w]r[^\w]', input ) if len(res) > 1: return res[1] else: return res[0] except: return None End Function 

The body of the function must necessarily be enclosed in the tags "Start Function" and "End Function". Also, if you need to import additional python modules, as in my case, import must also be written before the function body itself.

Here you should especially pay attention to the moment that to designate special characters from the “raw” log “\ r”, ”\ n”, ”\ t” you need to use the construct [^ \ w] r, [^ \ w] n and [ ^ \ w] t respectively. Those. the symbol "\" from the "raw" message in our regular expression (namely, using regular expressions, we obtain the data by this function) is represented as "[^ \ w]". This solution was found by trial and error. No other constructions, including “. *”, “\ S +”, shielding with slashes and others, could not cope with “\” in the raw log.

As can be seen from the function, if there are several “Account Name” constructions in one message (and this happens, for example, in events of changing one UZ of a user of another UZ), it (function) takes the second value as a user name. Because the first is the name of the user who changed the target UZ.

Next, at the end of the [config] section of the plugin configuration file “/etc/ossim/agent/plugins/wmi-security-logger.cfg” we add a parameter that refers to the function file:
custom_functions_file = / etc / ossim / agent / plugins / custom_functions / wmi_funcs.cfg

And in the [cmd] section we add a parameter that uses a custom function to get data about the user's UZ. In general, it looks like this:

 <   OSSIM>={:< >($< ,   WQL>)} 

And in my particular case it looks like this:

 username={:win_account($3)} 

As a result, the plugin configuration file will look like this:

 [DEFAULT] plugin_id=1518 [config] type=detector enable=yes source=wmi credentials_file=/etc/ossim/agent/wmi_credentials.csv sleep=10 process= start=no stop=no custom_functions_file=/etc/ossim/agent/plugins/custom_functions/wmi_funcs.cfg [start_cmd] cmd=wmic -U OSS_WMI_USER%OSS_WMI_PASS //OSS_WMI_HOST "Select LogFile,RecordNumber from Win32_NTLogEvent Where Logfile = 'Security'" | head -n 3 | tail -n 1 | cut -f 2 -d \| regexp= [cmd] cmd = wmic -U OSS_WMI_USER%OSS_WMI_PASS //OSS_WMI_HOST "Select ComputerName,EventCode,Logfile,Message,RecordNumber,SourceName,TimeWritten,User from Win32_NTLogEvent Where Logfile = 'Security' and RecordNumber > OSS_COUNTER" | cat start_regexp=^([^\|]+)\|(\d+)\|([^\|]+)\| regexp="^(?P<system_name>[^\|]+)\|(?P<plugin_sid>\d+)\|(?P<logfile>[^\|]+)\|(?P<message>[^\|]+)\|(?P<recordnumber>[^\|]+)\|(?P<sourcename>[^\|]+)\|(?P<timewritten>[^\|]+)\|(?P<username>.*)$" src_ip={resolv($0)} plugin_sid={$1} userdata2={$2} userdata3={$3} userdata4={$4} userdata5={$5} userdata6={$6} username={:win_account($3)} 

2. Diagnose and troubleshoot WMI plugin

To diagnose the operation of the plugin, you must perform the following steps:

1) Test WMI by running the wmic client from the console of the OSSIM server.
The arguments with which wmic needs to be run can be taken from the same plugin configuration file.

For example:

 wmic -U domain\Administrator%Passw0rd //server.example.com "Select LogFile,RecordNumber from Win32_NTLogEvent Where Logfile = 'Security'" 

The result of the successful execution of this command should be a list of numeric event identifiers from the Windows log.

If errors appear, then it is necessary to check that the UZ is configured correctly and has all the necessary rights to receive the event logs of the target system. If there is a firewall between the OSSIM server and the target system, you also need to make sure that it passes OSSIM → Windows traffic in the opposite direction.

2) Restart the OSSIM plugin.
First stop the plugin:

 /etc/init.d/ossim-agent stop 

Then kill all the wmi client processes that are still hanging:

 ps –ef |grep wmi 

And in turn:

 kill -9 “ ” 

After this, start the agent:

 /etc/init.d/ossim-agent start 

3) Clean the target system log.
On highly loaded servers, such as domain controllers with a large number of users, the event log can grow very large, taking up hundreds of megabytes. In my practice I ran into the fact that on such volumes of event logs WMI plugin starts to receive events with significant delays in time. The only recommendation here is to set a log size limit on the target system. It is desirable if it will be no more than 30 MB.

In the lab, often the WMI plugin started working only after the big security log was completely empty.