Monitor/Audit Browsers with Wazuh

[Carlos Lopez]

Hi all,

Is it possible to monitor/audit the history, extensions and plugins of Safari, Firefox and Chrome browsers using Wazuh (under Windows. Linux and macOS?

So far the best result I have obtained is using Osquery, although it complicates the maintenance.

Any ideas?

[Matias Pereyra]

Hello Carlos!

If you combine some Wazuh capabilities, it is possible to monitor virtually anything. We only need to define the source and customize/adapt its ingestion and detection:

• The Log data collection capability is in charge of taking the data from the agents and send it to the Manager
• You can create Custom rules and decoders to analyze this information and trigger the proper alerts

Related to browsers, we can take the Google Chrome example: it has a managed version with a Chrome Reporting Extension. It is used to monitor its usage, extensions,  and the "data is stored in a structured log file in JSON format".

We can add a localfile configuration section, using JSON <log_format>

    <localfile>
      <location>%LOCALAPPDATA%\Google\ChromeReporting\*.json</location>
      <log_format>json</log_format>
    </localfile>

Then, the last step would be writing decoders and rules for the desired information according to its structure. This blog post describes the process: Creating decoders and rules from scratch.

It is just an example, and every application and OS has different ways to store the date, but after you define the source, the log collection and decoder/rule creation process is the same.

Don't hesitate in writing us again if you have more questions related to this topic.
Regards.

[Justang]

Hi Matias,

I stumbled upon this post, installed the extension, and have the .json file writing.

The .json file is written to my user directory, When I add the localfile pickup in Wazuh, it tries to grab the .json files from a directory that's not available because of where wazuh sees %LOCALAPPDATA% running from:

ossec-agent: INFO: (1141): Glob error. Invalid pattern: 'C:\WINDOWS\system32\config\systemprofile\AppData\Local\Google\ChromeReporting\*.json' or no files found.

Is there any way to get around the issue I'm having?

[Matias Pereyra]

Hello again!

Could you please share the real location and the name of the .json file ?

Then we could know if there is a problem with the environment variable, or with "\Google\ChromeReporting\" section.

If you use the complete path in the location tag, without %LOCALAPPDATA%,  does Wazuh read the file?

Regards.

[Justang]

Hi Matias,

When I run it manually from my account I get the AD user home directory

C:\Users\<AD-Username>\AppData\Local\

When I set the path manually in the agent.conf it works just fine, and pulls the file

C:\Users\<AD-Username>\AppData\Local\Google\ChromeReporting\*.json

I also tried a wildcard in the path, but the config didn't like that.

I'd want to centralize the configuration, and so a path like %LOCALAPPDATA% would be great, but wazuh doesn't run as a user account. 

Thanks!

[Matias Pereyra]

Thank you for the details!

You are right, the problem is the environment variable.

The Wazuh agent seems to resolve the %LOCALAPPDATA% in a different way because of the user account.

After some tests in a Win-2008 agent, the variables %UserProfile% and %LocalAppData%  are replaced as "C:\Windows\system32\config\systemprofile". This directory isn't what we need.

But if I use %Home%, I have "C:\Users\Administrator" as path. So it depends on what variable you use.

On the other hand, if you let me suggest a different approach, the Wazuh integration with Osquery may be helpful.

You can perform queries like these and generate the corresponding alerts analyzing the results:

    osquery> select name, version from chrome_extensions
    where name like "%Cisco%";

There is more information about Osquery and browser extensions in: https://www.uptycs.com/blog/finding-browser-extensions-in-osquery

Please, let me know if you have more questions.
Regards.

[Justang]

Hi Matias,

Thanks for checking and the response.