Advanced Shadow AI Detection in Wazuh Beyond Static Package/Process Matching

[minshad]

Hi ,

Currently working on a Shadow AI detection use case in Wazuh 4.12 using Syscollector inventory monitoring and custom Python integrations.

At the moment, a static detection approach has been implemented based on:

• package name matching,

• process name matching,

• and predefined keywords for known AI tools such as Ollama, LM Studio, Copilot, Cursor, etc.

This is currently working well for detecting known AI applications, but the challenge is that the detection logic depends on maintaining a predefined list of package/process names. This requires continuous updates whenever new AI tools emerge and can also lead to false positives caused by generic package names or partial keyword matches.

The next objective is to move from this static detection model toward a more advanced/dynamic approach capable of identifying unknown or previously unseen AI/LLM tools without relying only on predefined keywords.

The idea is to explore whether AI-related tooling can be identified through:

• binaries,

• runtime behavior,

• artifacts,

• telemetry patterns,

• local inference activity,

• AI-related processes/services,

• or other indicators that can provide higher confidence that an AI/LLM tool is present or actively being used.

Wanted to ask whether anyone in the community has explored something similar in Wazuh or implemented approaches beyond static package/process matching.

Also interested in understanding:

1. Best ways to reduce false positives in this use case.

2. Whether there are recommended telemetry sources or integrations for this type of detection.

3. If anyone has explored artifact-based or behavior/telemetry-based correlation for identifying unknown AI tooling.

4. Whether tools like Sysmon, YARA, Falco, eBPF, Suricata, or other integrations could help improve this detection model.

Would really appreciate any ideas, experiences, or architectural guidance from the community.

Thanks!

[Bony V John]

Hi,

Regarding the dynamic approach for user LLM usage detection, I shared another approach along with step-by-step guidance, including the custom script, in the Wazuh Google Group community thread. You can refer to it there.

In the first method, we used Syscollector to collect the running process and package details from the endpoint and compared them with static LLM model names to trigger alerts.

In the second use case, I shared a custom script that runs directly on the endpoints. The script checks packages, running processes, IDE plugins, and other endpoint artifacts. It also pulls LLM model details from Hugging Face, creates a model list, and compares the package, process, and plugin details against that list to verify whether any LLM-related tools or models are being used on the endpoint.

You can also use a different feed URL instead of Hugging Face to collect the LLM model list.

With this approach, only positive match events are sent to the Wazuh manager for analysis, which helps avoid sending unnecessary events to the Wazuh manager.

I also updated the name-matching logic to reduce false positives and added some ignored process names used by the operating system to avoid unnecessary alerts.

Regarding other tools such as Sysmon, YARA, and Suricata, they also mainly work based on rules. They evaluate conditions defined in static rules and generate events when those conditions match. In such cases, it is difficult to make the detection fully dynamic only through rules.

Because of that, using a custom script that periodically fetches updated feeds from a trusted source containing up-to-date LLM model details is a better approach. The script can then compare endpoint activity against the latest feed data dynamically.

You can further fine-tune the scripts and rules based on your environment and requirements.

Please let me know if you face any issues.