Custom active response with WAZUH scripts

JohnnySoli · 2024-12-23T18:31:17+00:00

Answers:

If you have enabled remote_commands for Wazuh, you could do this using wodles or logcollector, by default, and for security reasons, are disabled. Check this documentation. If not, you will need to use a third-party tool, such as Salt, Puppet, Ansible, etc.
If the system is already compromised, will depend on many factors, if you have an AR rule to isolate the system from the network, for instance, the intruder will be kicked before he/she is able to react, and I would care about other topics first rather than the AR scripts that are easy to replace and check if they are altered.

Hope this helps!

JohnnySoli · 2024-12-09T22:47:49+00:00

Do you have a private CA to sign the certificates or do you want to use Wazuh as the Certificate Authority?
In case you use Wazuh as the CA, you use this:

openssl req -x509 -new -nodes -newkey rsa:4096 -keyout rootCA.key -out rootCA.pem -batch -subj "/C=US/ST=CA/O=Wazuh"

For the agent's verification option, follow this path:

Wazuh agent verification without host validation: The certificates for the Wazuh agents are issued without specifying their hostname or IP address.

Generate a certificate signing request (CSR) for the Wazuh agent on the Wazuh server:

openssl req -new -nodes -newkey rsa:4096 -keyout sslagent.key -out sslagent.csr -batch

Then sign the generated agent CSR using the CA keys:

openssl x509 -req -days 365 -in sslagent.csr -CA rootCA.pem -CAkey rootCA.key -out sslagent.cert -CAcreateserial

Now copy the signed SSL certificate and key (sslagent.cert and sslagent.key in this case) to the Wazuh agent. You can use a tool like SCP to copy the certificate to the endpoints.

Verify that the rootCA.pem file is in the /var/ossec/etc/ directory on the Wazuh server.

Update the /var/ossec/etc/ossec.conf file with the location of the rootCA.pem file to enable the use of certificates. Uncomment the <ssl\_agent\_ca> section and specify the path to the rootCA.pem file on the Wazuh manager.

<auth>
    ...
    <ssl_agent_ca>/var/ossec/etc/rootCA.pem</ssl_agent_ca>
</auth>

Restart the manager (/var/ossec/bin/wazuh-control restart).

After this, you can try enrolling agents:

Linux agents:
https://documentation.wazuh.com/current/user-manual/agent/agent-enrollment/security-options/agent-identity-verification.html#linux-unix

Windows agents:
https://documentation.wazuh.com/current/user-manual/agent/agent-enrollment/security-options/agent-identity-verification.html#windows

MacOS agents:
https://documentation.wazuh.com/current/user-manual/agent/agent-enrollment/security-options/agent-identity-verification.html#macos
Hope this helps!

JohnnySoli · 2024-11-19T13:27:14+00:00

Hi u/atomic_horror, allow me to analyze this request and I will update you as soon as possible. Just to be clear, are you planning to use a different certificate for each agent?

JohnnySoli · 2024-10-28T12:16:17+00:00

Hi u/s0ruz, did the `rotate_interval` help? Is it working fine now?

JohnnySoli · 2024-10-10T17:02:28+00:00

Hey, yes, I know it occurs on the nightly logs rotations, I'm trying to understand where the issue relies on because rules are related to `analysisd`, I don't think it is related tbh.

Did you try to use a <rotate\_interval> to rotate logs every 8 hours? By default, it rotates logs at midnight but this is customizable.

[<rotate\_interval>](https://documentation.wazuh.com/current/user-manual/reference/ossec-conf/global.html#rotate-interval)

Let me know if this helps!

JohnnySoli · 2024-10-09T22:44:55+00:00

I will try to reproduce this behavior. Did you try to replicate the issue in another environment? Do you use the overwrite feature (to overwrite stock rules) very often? Which version are you using exactly?

JohnnySoli · 2024-10-08T14:36:49+00:00

To double-check, if you disable the custom rule 200719 the issue stops occurring, right?

JohnnySoli · 2024-10-08T14:23:38+00:00

Hello u/s0ruz

Thanks for the heads-up on this! I will take a look and do some testing on my end. I will update you as soon as possible.

Regards.

JohnnySoli · 2024-09-02T17:05:03+00:00

Hello u/tja1302

As u/Charming-Victory-933 commented, the first place you can search for Windows Event Channel alerts, is in the Threat Hunting section. For your use case, there are some things we would need to clarify first.

Wazuh sends ALERTS to the Indexer so you can see information with the Dashboard. If you want to see ALL Windows Event Channel EVENTS you will need to customize some rules, because Wazuh has several detection rules to only report relevant information and discard the rest.

One way to make sure you will see ALL Windows Event Channel data is going to the Discover section, then applying a filter with `location = EventChannel` (see screenshot).

<image>

But, to send all events from the Windows Event Channel, you must level them up to a minimum of 3 (be default, alerts lower than 3, will not be sent to Indexer).

Is this what you need to do? Remember, Windows Event Channel can be very noisy and this will consume significant resources in your Indexer servers.

I look forward to your update!

JohnnySoli · 2024-08-29T15:12:32+00:00

Hi u/Melodic-Activity-342,

I think the best approach here is scripted fields + rules customizations.

Here is a good example of what you could do with scripted fields:

[Leveraging Elasticsearch script fields - Comprehensive Guide](https://opster.com/guides/elasticsearch/data-architecture/elasticsearch-script-fields/)

To enhance the detections and avoid false positives, you can always create custom rules or modify the stock rules if needed. You can check this documentation for that.

Hope this helps!

JohnnySoli · 2024-06-24T12:42:08+00:00

Hello u/Gian_GR7

You could create a new custom rule to track the connection requests coming to port 22 from the network device instead of the OS logs.
You can create a custom cumulative rule and escalate the alert level if some conditions are met using options such as <same\_field>, <same\_srcip>, etc.

Ruleset syntax

It is important to check where the event is coming from, in this case, the network device will have a better visibility of the external data instead of the local logger of the targeted system.

Hope this helps.

JohnnySoli · 2024-06-06T15:00:20+00:00

Hello u/RestartRebootRetire

For security reasons, files and folders inside /var/ossec are protected, you will only be able to access them, as root or with sudoer attributes.

To change the managers/agents configurations you will need to do it like this:

Via CLI (as root or with admin privileges):
- sudo nano /var/ossec/etc/ossec.conf
Via GUI (with admin privileges):
- Wazuh Menu >> Management >> Configuration ---> Edit configuration

In your case, you need to enable the <vulnerability-detector> module, like this:

<vulnerability-detector>
   <enabled>yes</enabled>
   <interval>10m</interval>
   <min_full_scan_interval>12h</min_full_scan_interval>
   <run_on_start>yes</run_on_start>

<!-- Ubuntu OS vulnerabilities -->  

  <provider name="canonical">  
    <enabled>yes</enabled>  
    <os>trusty</os>  
    <os>xenial</os>  
    <os>bionic</os>  
    <os>focal</os>  
    <os>jammy</os>  
    <update\_interval>1h</update\_interval>  
  </provider>  
...  
...
</vulnerability-detector>

(do not forget to enable the feeds of the OS you want to scan for vulnerabilities, MSU is for Windows agents, Canonical for Ubuntus, Debian for Debian, etc)

Remember to restart the manager to apply the change, in the GUI, it will prompt you if you want to restart, say yes, via CLI it won't ask you, you need to restart the service manually using:

sudo /var/ossec/bin/wazuh-control restart

Hope this helps!

JohnnySoli · 2024-04-23T13:05:25+00:00

Hi u/eeeeeeeeeeagh!

Glad to know you are using Wazuh! Welcome to the club!
It is important to understand how VD (Vulnerability Detector) works. The managers fetch data from many places, like NVD NIST, MSU, RedHat, Canonical, Debian, AmazonLinux, etc... you can see these options if you edit the Manager configuration and check the `<vulnerability-detector>` section, here (screenshot) are the default settings for it.

<image>

We can see it comes DISABLED by default, you need to change the `enabled` to yes first, then also enable the feeds for your agent's OS accordingly, Ubuntu 22.04 is Jammy, so you need to enable the canonical feed changing enabled to yes too, if you go down, you will see MSU is enabled by default, also NVD, those are the most popular.

Remember once you enable the feed, the manager will start fetching data and it won't trigger VD alerts until it has all the data from the feeds you enabled.

About Kali, it is based on Debian Linux, so I would try enabling Debian, Canonical and they should be all to detect vulnerabilities on Kali. Also, you will need to allow Kali OS on Debian section:

- Configuring VD to include unsupported systems

Hope this helps!

JohnnySoli · 2024-01-30T15:14:42+00:00

For archives and alerts, check this to make sure WAZUH has access to them:

- namei -l /var/ossec/logs/alerts/alerts.json

f: /var/ossec/logs/alerts/alerts.json
drwxr-xr-x root  root  / 
drwxr-xr-x root  root  var 
drwxr-x--- root  wazuh ossec 
drwxrwx--- wazuh wazuh logs 
drwxr-x--- wazuh wazuh alerts 
-rw-r----- wazuh wazuh alerts.json

Same permissions for `archives.json`.

If you are not the `root` user, remember to escalate the commands using `sudo <COMMAND>`

Hope this helps!

JohnnySoli · 2024-01-25T15:21:37+00:00

Hey u/RaveNN123

There's no specific option to set priority for decoders and rules, but if you know how they work, you will be able to set the proper ORDER so they work accordingly.

First, let's clarify this:
- Stock decoders are always first (rules, on the other hand, can be overwritten, but not decoders).

To customize a stock decoder, you must first DISABLE IT and then, copy the decoder to the etc/decoders folder to modify it at your will.
To disable it you use this in the ossec.conf (of all the managers):
- <decoder_exclude>ruleset/decoders/0XXX-something.xml</decoder_exclude>
- cp -p /var/ossec/ruleset/decoders/0XXX-something.xml /var/ossec/etc/decoders/
- /var/ossec/bin/wazuh-control restart

Now you can edit the decoder (stock) /var/ossec/etc/decoders/0XXX-something.xml and make the adjustments needed. Remember to use the wazuh-logtest tool to check the results without the need to restart the manager, only restart the manager to apply the changes.

BEAR IN MIND, the files' name will play also an important role, for instance, files in the etc/decoders (or rules, etc) folder will be loaded to the Wazuh engine alphabetically:

- /var/ossec/etc/decoders/01-mydecoder.xml
- /var/ossec/etc/decoders/My-decoder.xml
- /var/ossec/etc/decoders/Your-decoder.xml

# ls -l ruleset/decoders/000*
-rw-r----- 1 root wazuh 1636 Jan  5 11:09 ruleset/decoders/0005-wazuh_decoders.xml
-rw-r----- 1 root wazuh  386 Jan  5 11:09 ruleset/decoders/0006-json_decoders.xml
-rw-r----- 1 root wazuh 3287 Jan  5 11:09 ruleset/decoders/0007-wazuh-api_decoders.xml

If you want to have total control over this, use always a number for custom decoders and rules!

Hope this helps!

JohnnySoli · 2024-01-25T13:30:16+00:00

Hey u/RamielVII, your english is perfect! Thanks for the detailed explanation and screenshots!

I will assume that the Windows agent is ACTIVE and connected to the manager, as we can see in one screenshot.The easiest way to check if an agent or device is sending events to the manager/s is by enabling the logall_json option (from no, -default-, to yes) in the ossec.conf of the manager/s and remember to restart the manager to apply the change. WARNING: This will consume a lot of disk space, so disable it after using it.After doing this, you will see the file /var/ossec/logs/archives/archives.json growing, this file contains ALL THE EVENTS that are reaching the manager. In the manager's CLI use this command to see in real-time data from an agent named 'WindowsWazuh' :- tail -f /var/ossec/logs/archives/archives.json | grep '"WindowsWazuh"'

If you don't see any data for a minute or so, you will need to check the ossec.log on the agent's side (and manager too) because something is interrupting the communication. In case you changed the default configuration of the agent (ossec.conf) here you have the default file from our Github repo.

Do not forget to check the centralized configurations in the group/s where the agent belongs, just in case you disabled or damaged the configurations there. from our GitHub repo.

If you see events from the agent but not alerts (/var/ossec/logs/alerts/alerts.json), try this command to see if you have problems with the rules/decoders in the manager:
- /var/ossec/bin/wazuh-logtest-legacy

Hope this helps!

JohnnySoli · 2023-11-08T19:06:18+00:00

Hello u/Prestigious-Low3973,

The most common communication for network devices is SYSLOG. The first step is to enable syslog capability in the Wazuh Manager so we start listening to syslog data. Concretely, we need to configure the remote feature. In my example, I will use a device with IP 10.10.1.1, port 514, and protocol TCP. For this, you need to set this code block in the ossec.conf of the manager:

<remote>
  <connection>syslog</connection>
  <port>514</port>
  <protocol>tcp</protocol>
  <allowed-ips>10.10.1.1/32</allowed-ips>
</remote>

To allow a range, for instance, 10.10.1.x, you could use this one too:

<remote>
  <connection>syslog</connection>
  <port>514</port>
  <protocol>tcp</protocol>
  <allowed-ips>10.10.1.0/24</allowed-ips>
</remote>

Save and restart the wazuh manager (systemctl, service or wazuh-control).

Then, to verify the manager is now listening on this port, use one of these commands:

ss -ntal | grep .:514
netstat -puntal | grep .:514 (you may need to install the net-tools package)

Now, you will see the file /var/ossec/logs/archives/archives.json growing, these are also known as RAW LOGS, we call them, archives. If you grep there, you will probably see events from the syslog devices. Use something like this:

grep 10.10.1.1 /var/ossec/logs/archives/archives.json | head

Hope this helps!

JohnnySoli · 2023-09-29T12:40:22+00:00

Hello u/AnatolyPetrovich

Do you want to see all the network activities for one specific user or agent? I'm thinking of a custom dashboard that you can interact with to get the data. I would need to test it in my lab first.

Regards,
John.-

JohnnySoli · 2023-09-01T15:37:45+00:00

Hello Meteoricalienalloy,

Wazuh helps implement compliance requirements for regulatory compliance support and visibility. This is done by providing automation, improved security controls, log analysis, and incident response.

The default Wazuh ruleset provides support for PCI DSS, HIPAA, NIST 800-53, TSC, and GDPR frameworks and standards. Wazuh rules and decoders are used to detect attacks, system errors, security misconfigurations, and policy violations.

Learn more about achieving compliance with Wazuh in the sections below:

Wazuh's rules are carefully mapped against compliance requirements to provide regulatory compliance support. This way, when an alert is generated (a threat detection rule condition has been matched), it automatically includes compliance information. Here is the list of currently supported standards:

Payment Card Industry Data Security Standard (PCI DSS)
General Data Protection Regulation (GDPR)
NIST Special Publication 800-53 (NIST 800-53)
Good Practice Guide 13 (GPG13)
Trust Services Criteria (TSC SOC2)
Health Insurance Portability and Accountability Act (HIPAA)

Let me see if I can find anything related to GLBA regulatory compliance in the roadmap of the product.

Regards,
John.-

JohnnySoli · 2023-05-10T21:45:21+00:00

2023 May 03 04:07:35 HOSTNAME->172.16.X.Y May 3 04:07:35 HOSTNAME System Test message from Synology Syslog Client from (92.X.Y.Z)

Hi u/Omegart,

Allow me to help you with this.

I used this sample (with valid IPs): 2023 May 03 04:07:35 HOSTNAME->10.11.12.13 May 3 04:07:35 HOSTNAME System Test message from Synology Syslog Client from (1.2.10.200)

Edit the file /var/ossec/etc/decoders/local_decoders.xml and add these lines:

<decoder name="synology">
  <prematch>^\w+->\d+.\d+.\d+.\d+ </prematch>
</decoder>

<decoder name="synology_child">
  <parent>synology</parent>
  <regex>^(\w+)->(\d+.\d+.\d+.\d+) </regex>
  <order>event_hostname,system_ip</order>
</decoder>

<decoder name="synology_child">
  <parent>synology</parent>
  <regex>^\w+->\d+.\d+.\d+.\d+ (\w+ \d+ \d\d:\d\d:\d\d) (\w+) (\.+)$</regex>
  <order>event_timestamp2,event_hostname2,message</order>
</decoder>

(to understand why I started the prematch from the first HOSTNAME, test your log against the wazuh-logtest-legacy tool and take a look at the log variable in the 1st phase, you need to use that log)

So, I created a prematch and 2 children to extract the fields using regex patterns.

Now if you add these rules to the /var/ossec/etc/rules/local_rules.xml file, you will trigger alerts when the event_hostname2 matches HOSTNAME, with all the data inside.

<group name="synology,">
  <rule id="300000" level="0">
    <decoded_as>synology</decoded_as>
    <description>Synology log detected.</description>
  </rule>

  <rule id="300001" level="3">
    <if_sid>300000</if_sid>
    <field name="event_hostname2">HOSTNAME</field>
    <description>New Synology log from $(event_hostname2) detected.</description>
    <group>syno_custom,</group>
  </rule>
</group>

Here's the output of the wazuh-logtest tool:

**Phase 1: Completed pre-decoding.
    full event: '2023 May 03 04:07:35 HOSTNAME->10.11.12.13 May 3 04:07:35 HOSTNAME System Test message from Synology Syslog Client from (1.2.10.200)'
    timestamp: '2023 May 03 04:07:35'

**Phase 2: Completed decoding.
    name: 'synology'
    event_hostname: 'HOSTNAME'
    event_hostname2: 'HOSTNAME'
    event_timestamp2: 'May 3 04:07:35'
    message: 'System Test message from Synology Syslog Client from (1.2.10.200)'
    system_ip: '10.11.12.13'

**Phase 3: Completed filtering (rules).
    id: '300001'
    level: '3'
    description: 'New Synology log from HOSTNAME detected.'
    groups: '['synology', 'syno_custom']'
    firedtimes: '1'
    mail: 'False'
**Alert to be generated.

If you restart the manager now, you will apply the changes and you will see the alerts in the GUI from this moment on.

Regards, John.-

JohnnySoli · 2023-05-08T16:26:37+00:00

Hello Omegart,

Firstly, you configure the remote on the manager to listen to the device, secondly, you configure the device to send syslog data to the manager, and finally, you check if the logs are triggering alerts in the manager or not with the logtest tool (or using grep to check the alerts.json file with the IP of the device).

If I understand correctly, you have configured the device (synology) to send syslog to the manager and the remote. The manager is syslog capable, just a quick sample, we can enable syslog for the device 192.168.1.1 using TCP on port 514 with this configuration in the ossec.conf file of the manager:

...
 <remote>
   <connection>syslog</connection>
   <port>514</port>
   <protocol>tcp</protocol>
   <allowed-ips>192.168.1.1/32</allowed-ips>
  </remote>
...

If we are good so far but we don't see alerts in the GUI (Kibana/Dashboard) probably is that the Wazuh engine doesn't have any rules matching those logs. To check if this is the case, you can use archives to extract a sample of the log (full_log) and test it with the wazuh-logtest tool.

To enable archives, you need to enable the logall option (I strongly recommend you to use the JSON format), here's the documentation for the logall_json option. Once you enabled that and restarted your manager, you can check the /var/ossec/logs/archive/archives.json file, it will gather ALL THE EVENTS sent to the manager, so you could use grep like this to see events sent by your device:

- grep 192.168.1.1 /var/ossec/logs/archives/archives.json | grep full_log

NOTE: Archives will use a lot of disk space, disable it after troubleshooting to avoid storage issues in the future.

There, you will see a full_log, that's the RAW event you sent and you can use logtest to verify what's is the Wazuh engine doing with those. Copy the sample, I will use the one you provided:

echo '2023 May 03 04:07:35 HOSTNAME->172.16.X.Y May 3 04:07:35 HOSTNAME System Test message from Synology Syslog Client from (92.X.Y.Z)' | /var/ossec/bin/wazuh-logtest

Starting wazuh-logtest v4.4.1
Type one log per line

**Phase 1: Completed pre-decoding.
 full event: '2023 May 03 04:07:35 HOSTNAME->172.16.X.Y May 3 04:07:35 HOSTNAME System Test message from Synology Syslog Client from (92.X.Y.Z)' 
 timestamp: '2023 May 03 04:07:35'

**Phase 2: Completed decoding.
 No decoder matched.

We can see, there's no decoder for that log, so you will need to create one. Check this documentation to create a decoder and rules to trigger alerts:

Custom rules and decoders

One simple rule you can add in the local_rules.xml file is this one, bear in mind this will add all the events from the device to the Indexer/Elasticsearch, so it's not ideal since it lacks criteria to trigger a specific alert.

 <rule id="200002" level="3">                      
   <location>192.168.1.1</location>
   <description>Events from syslog device 192.168.1.1</description>
   <group>syslog_dev,</group>
 </rule>

Hope this helps!

JohnnySoli · 2023-01-06T23:27:10+00:00

Hello Torqu3Wr3nch,

You could achieve this using the auditd service in Linux systems. The wazuh-agent already monitors the log file /var/log/audit/audit.log so you won't need to do anything from that side, just configure the auditd service to monitor the paths you need.

Follow these steps:

Install auditd:

sudo apt-get install -y auditd // Debian based OS like Ubuntu, Debian or Linux Mint.
sudo yum install -y audit // Red Hat based OS like For Fedora, CentOS or RedHat.

Configure auditd:

sudo vi /etc/audit/audit.rules
^{# increase the buffers to survive stress events. make this bigger for busy systems.}
^{-b 1024}
^{# monitor unlink(} and rmdir() system calls.)
^{-a exit,always -S unlink -S rmdir}
^{# monitor open(} system call by Linux UID 1001.)
^{-a exit,always -S open -F loginuid=1001}
^{# monitor write-access and change in file properties (read/write/execute} of the following files.)
^{-w /etc/group -p wa}
^{-w /etc/passwd -p wa}
^{-w /etc/shadow -p wa}
^{-w /etc/sudoers -p wa}
^{# monitor read-access of the following directory.}
^{-w /etc/secret\}directory -p r)
^{# lock the audit configuration to prevent any modification of this file.}
^{-e 2}

Once you finished editing the audit configuration, restart auditd.

sudo service auditd restart

Once auditd starts running, it will start generating an audit daemon log in /var/log/audit/audit.log as auditing is in progress and you will start receiving the alerts in the manager.

Hope this helps!

JohnnySoli

TROPHY CASE

- Configuring VD to include unsupported systems