Wazuh Wodle

[Brenno Garcia]

Hello,

I've set up a Python script to monitor browser history and generate an output file. Wazuh reads this file, decodes it, and generates alerts.

I copied this Python script using Active Directory GPOs and configured a scheduled task to run it when a user logs in or unlocks their account.

Is there a more efficient way to run this script, like wodles?

[Olamilekan Abdullateef Ajani]

Hello Brenno,

Running the script only on login/unlock means you only get a snapshot at those moments alone and not continuous monitoring. If a user is logged in for hours, you will probably miss all browser activity in between. It also depends on AD GPO delivery timing and has no direct feedback to Wazuh if the script fails silently. Based on this, the best approach will be the command monitoring module option because aside from it being robust and scalable, it is tied to the operation of the Wazuh agent itself, and you can easily monitor its operation via the logs.

Wodles are the right option for this. Specifically, use the command wodle in the agent's ossec.conf file. It is configurable and runs continuously regardless of login state, and if the script fails or times out, Wazuh knows about it.

The other option is the log collector module, which utilizes the localfile option for command monitoring. You can find all required information to aid you in your decision for your use case in the documentation below.

Ref:
https://documentation.wazuh.com/current/user-manual/capabilities/command-monitoring/configuration.html

[Olamilekan Abdullateef Ajani]

Hello Brenno,

I got your feedback. And to answer your question, "the script saves the states of the last browser history collection, so it starts at login and checks for new browser history every minute. " Did you build the logic inside the script to run every minute, or is this just a suggestion?

"However, as I mentioned, the script is configured via GPO, so my limitation is the synchronization of machines and understanding why some are not working." For this, you can use the Wazuh centralized configuration to manage the distribution. You can find a reference here for this: https://github.com/bonyjohn05/AR-script-deploy

This requires you to enable remote execution on the agent via the manager, which is a security gap incase the Wazuh manager is compromised, it can introduce security risks if not properly controlled. So ensure you limit access to the manager to trusted zones and prevent unauthorized command execution.

You can configure the woodle in a similar pattern:

<agent_config>
  <wodle name="command">
    <disabled>no</disabled>
    <tag>browser-history</tag>
    <command>python3 "C:\Program Files (x86)\ossec-agent\shared\browser_history.py"</command>
    <interval>1m</interval>
    <run_on_start>yes</run_on_start>
    <timeout>55</timeout>
    <ignore_output>yes</ignore_output>
  </wodle>
</agent_config>

The timeout at 55 seconds (below the 1-minute interval) is what prevents duplicate instances, the woodle kills the previous run before starting the next one. If you set a long timeout instead (e.g., <timeout>0</timeout> meaning no timeout), the script runs its internal loop fine, but if the script ever crashes, the woodle won't relaunch it until the next <interval> fires, creating a blind spot. But you can also use similar option below so the woodle just starts the script.

<wodle name="command">
  <disabled>no</disabled>
  <tag>browser-history</tag>
  <command>python3  "C:\Program Files (x86)\ossec-agent\shared\browser_history.py"<  </command>
  <interval>24h</interval>
  <run_on_start>yes</run_on_start>
  <timeout>0</timeout>
</wodle>

Let me know what you think.

Ref:
https://documentation.wazuh.com/current/user-manual/reference/ossec-conf/wodle-command.html
https://github.com/bonyjohn05/AR-script-deploy

[Brenno Garcia]

How do i configure this wodle?

For example
my scheduled task is -> pythonw path/script.py

runs each logon/unlock

script runs and there is a loop to collect browser each 1 minute

My wodle:

 <wodle name="command">
     <disabled>no</disabled>

      <tag>browser</tag>
      <command>pythonw.exe C:\Path\Wazuh\wazuh-monitor.py</command>
      <interval>10m</interval>
      <ignore_output>no</ignore_output>

      <run_on_start>yes</run_on_start>
      <timeout>0</timeout>
    </wodle>

The logs says "wazuh-modulesd:command started"

The browser logs:

May 14 09:42:27 NTBX browser-monitor: Starting Browser Monitor. Logging to: C:\Path\Wazuh\browser_history.log
May 14 09:43:24 NTBX browser-monitor: Starting Browser Monitor. Logging to: C:\Path\Wazuh\browser_history.log
May 14 09:44:15 NTBX browser-monitor: Starting Browser Monitor. Logging to: C:\Path\Wazuh\browser_history.log
May 14 10:09:13 NTBX browser-monitor: Starting Browser Monitor. Logging to: C:\Path\Wazuh\browser_history.log

But the history logs aren't collected

[Olamilekan Abdullateef Ajani]

Hello Brenno,

I looked up the pythonw.exe logic you used and found out it suppresses all console output, including exceptions. This explains some of the challenges seen, and the script is probably crashing silently, and there is no information about it in the log, which is why history is never collected despite it starting successfully. As I have seen, Wazuh command wodles work more reliably with python.exe, so please update that. But if a windowless process is preferred, you can switch back to pythonw.exe once everything is working.

And again, since the script already loops every minute internally, the Wodle interval becomes mostly irrelevant, so as I mentioned earlier, you may want to choose between removing the internal infinite loop from the Python script and letting Wodle handle scheduling itself or keeping your internal Python loop but configuring Wodle only to launch the process once and letting the script do the rest.

The reason the browser history logs are not being collected is probably because the script restarts repeatedly before reaching the actual collection loop or because the output log file is not being updated consistently before Wazuh reads it.

Another culprit is the browser SQLite history file being locked while the browser is open, Chrome and Edge hold an exclusive lock on their history file during a session. The script needs to copy the file before reading it. So you may also want to review the logic there.

Lastly, disable the GPO scheduled task to eliminate competing instances, and just follow through with Wazuh handling end-to-end.

The process of configuring each option I have shared in my previous response.

[Brenno Garcia]

Hello

Even with the changes it didn't work

I removed the loop from script;

I changed the interval and timeout.

The logs still says "browser-monitor: Starting Browser Monitor. Logging to: C:\Path\Wazuh\browser_history.log"

The taskmanager shows python or pythonw process running, but it doesnt collect the history

[Olamilekan Abdullateef Ajani]

Hello again,

So I took time to try this out so I could see if there is something missing. But it works except I used Wazuh end-to-end and no scheduled task is added. You can see the results and script used attached.

One thing I noticed from your script is,  Python must be installed system-wide (C:\Program Files\Python314\)   

The `wodle` command must use the full Python path because of the way yours was declared. You can also try to run this locally before automating it.

The wazuh_command.remote_commands=1 flag is required in local_internal_options.conf on each endpoint  

The first run will collect all existing history; subsequent runs only collect new entries.

Try this and let me know what you find.

[Olamilekan Abdullateef Ajani]

Did a process walkthrough here too, if you don't mind. https://github.com/lakecide/wazuh-browser-monitor