Overview
One of our customers had issues with threat filters. They had created many filters within Threat Manager, but the results were inconsistent. Some seemed to work, while others didn’t .
Our internal tests showed that every filter was working as expected, so we concluded it should be a configuration issue.
We used advanced troubleshooting techniques to understand what was going on on the customer’s server, this post shows how we did it .
Description
The first thing we needed was clear logs. When configured, the advanced filter log allows you to see very clearly what is happening.
To enable advanced exclusion logs, follow these steps:
- Navigate to
C:\Program Files\Stealthbits\StealthDEFEND\JobService
and create a file calledappsettings.json
. - Inside this file, paste the following code:
{
"Serilog": {
"MinimumLevel": {
"Default": "Information",
"Override": {
"Microsoft": "Information",
"System": "Information",
"JobManager.ThreatExclusionActor": "Verbose"
}
}
}
}
Restart the JobService. Now anytime an event is tried against exclusion filters, the logs are a lot more talkative!
We opened the logs and found the culprit:
2025-04-02 10:40:00.909 -07:00 [VRB] Exclusion result: Input: 'EXAMPLE.LOCAL' Operator: '"Equals"' Pattern: ' EXAMPLE.LOCAL' Is Match: false
2025-04-02 10:40:00.915 -07:00 [VRB] Exclusion result: Input: 'EXAMPLE.TEST.LOCAL' Operator: '"Equals"' Pattern: ' EXAMPLE.LOCAL' Is Match: false
When the exclusion filter was created, a space was added. Because the “equals” filter is very strict, every character counts, even spaces !
The easy solution is to replace this filter with one without spaces. However, how could we ensure if any other filters had spaces within them? We had to dig deeper.
Digging Deeper
We installed pgAdmin on the server running Threat Manager. We launched pgAdmin and connected to the database. Please note the database is protected by a password, and only Netwrix employees should try to touch the database directly. For most cases, checking the logs should be enough to resolve your issue.
Inside the database, we ran the following query:
SELECT *
FROM public.blacklist
WHERE EXISTS (
SELECT 1
FROM jsonb_array_elements(rule_list->'Exclusions') as e1,
jsonb_array_elements(e1->'Exclusion') as e2,
jsonb_array_elements(e2->'Filter') as f
WHERE (f->>'Name') LIKE ' %'
OR (f->>'Name') LIKE '% '
);
This showed any row that had a filter starting or ending with a space! With it, we were able to quickly target every exclusion from the customer’s environment and resolve them
.
Hope this is helpful to anyone!
Side Note:
- We all agreed with the customer that Threat Manager should be more explicit about showing spaces or any hidden characters in exclusions
. This is a feature we will be working to implement in Threat Manager in the future
.