Exclusions are a very powerful feature and when used correctly can reduce your false positive rate to zero. However, when done improperly they can silence important critical detections. Ask Wirespeed drafts the narrowest safe rule for you, and the Wirespeed team is always here to help you review exclusions before deploying them.
property=value format, combining expressions with AND or OR, and you can wrap groups of conditions in parentheses to control precedence.
A simple example is category=IDENTITY__LOGIN AND prevented=true, which automatically closes login cases that were already prevented by the source system.
Create with Ask Wirespeed
To create an exclusion use the /exclusion skill and let Ask Wirespeed draft it for you. Anywhere you can create an exclusion — Settings → Exclusions, a case, a detection, or an asset — you’ll find a Create with Ask Wirespeed (or Ask Wirespeed) button that opens the chat with the exclusion workflow already loaded and the relevant context prefilled.
Describe, in plain language, what you want to stop alerting on. The agent then:
- Reads the real evidence. It inspects the selected case or detection and builds the query only from field values that actually appear there — never invented emails, hosts, IPs, hashes, or locations.
- Scopes to the narrowest safe rule. It prefers several independent constraints joined with
AND (exact category, specific account, endpoint, network/location, process command, or file hash) so the rule captures your intended benign pattern without hiding true positives.
- Considers timeframe. It decides whether the activity is time-bounded (a penetration test, travel, a maintenance or migration window) or an ongoing pattern, and sets an appropriate TTL so temporary approvals expire on their own.
- Asks when it’s unsure. If the scope or duration is ambiguous — or if you ask for something broader than the evidence supports — it asks one focused question (often as selectable choices) rather than guessing.
- Presents a draft for confirmation. Nothing is saved until you confirm. You’ll see the proposed name, query, description, and TTL. If you want it tighter or broader, just say so and it re-drafts.
Ask Wirespeed will not refuse a request outright — even for dual-use tooling like remote-management software or PowerShell. Instead it narrows the scope (for example, to an exact hash or exact command plus category and actor) and asks for whatever it’s missing.
Editing an Exclusion
After an exclusion is created you can still edit it — including the raw query, TTL, and settings — from Settings → Exclusions. Because you’re editing the query directly there, the rest of this page documents the query syntax so you can read, review, and adjust what the agent produced.
property=valueproperty.sub=valueproperty=value AND property=valueproperty=value OR property=value(property=value AND property=value) OR property=value
Is that enough property=values for you?
Operators
Property Values
You will be provided with a JSON document containing the property values you can query from. These are values from your detection and all of its associated assets. When typing in the search, property names will autocomplete.
Arrays
Arrays are flattened and can be queried with the special @ operators.
Pay special attention to what array operator you are using. For example, using the “some array values equal” operator (@~=) will automatically close any cases containing at least one match, even if other values in the array do not match. Ensure this is the intended action.
Dates must be provided in ISO 8601 format
Email addresses, CIDR ranges, and strings with spaces in them must be quoted
Double-nested object arrays (for example indicators.observables.type) are flattened to leaf values for comparison — matches are not correlated to the same parent object across clauses
If a string contains quotes inside of it, they are removed during comparison
Backslashes in strings are double escaped when presented in the UI, you only need to provide one escape when referring to them
Settings
Exclusions can be disabled and will not be used until they are reenabled. Once an exclusion has caused a detection to be automatically closed it cannot be deleted, only disabled. If you would like an exclusion removed from your audit log and deleted please open a support ticket.
TTL
You can set a TTL for an exclusion. This will automatically disable the exclusion after the specified amount of time. When Ask Wirespeed recognizes a time-bounded activity, it sets the TTL to the shortest window that covers it, so the rule expires without you having to remember to remove it.
Rolling TTLs
Rolling TTLs reset their timer each time the exclusion matches a detection. This ensures that common patterns in your environment remain excluded as long as they occur regularly. If the pattern stops occurring, the TTL will eventually expire and future occurrences will no longer be excluded. Ask Wirespeed uses a rolling TTL only for an ongoing pattern, and a fixed (non-rolling) TTL for a one-time window such as a penetration test.
Suppress source system updates
By default, when Wirespeed automatically closes a detection because it matched an exclusion, we also sync that outcome to the integration (for example, closing or updating the alert in the vendor console). You can enable Suppress source system updates on an exclusion to stop that outbound sync for detections matched by that rule. Use this when you only want to silence or auto-close detections inside Wirespeed without changing how the alert appears or is handled in the source product.
Examples and Trade-offs
Writing exclusions can reduce the noise from false-positive alerts, but it can also come at the trade-off of ignoring true positives, opening your organization up to risks that prevent Wirespeed from protecting you. Ask Wirespeed applies the same trade-offs below and defaults to the tightest version of a rule — the examples here explain the reasoning so you can review a draft, or edit a query, with confidence.
Dealing with Safe Executables
It’s possible to use exclusions to prevent escalations or remediation for known-good applications. However, this requires a critical eye to be done effectively with a good risk trade-off.
A Simple Example
The following is an example to allow a specific version of a known-good executable to run. In this case, the executable was a helper application for banking software. It has only one purpose and is published directly by the business bank, with no history of being abused by attackers. Ideally, files like this would be enriched by their hashes, such as the SHA256 hash in this case, but it wasn’t found in Reversing Labs’ library of over 40 billion files. The best solution would be to submit that file for analysis and inclusion in their repository of files, but that’s not often feasible, so a simple exclusion like this can be safe enough to avoid future false-positive alerts:
The following can deceptively appear to be similar to the example above, but it comes with opening your organization to risks that Wirespeed does NOT recommend:
The difference in this case is that hash is for ScreenConnect.WindowsClient.exe, which is the primary executable for the ScreenConnect product, a remote management and IT help tool, that also happens to be commonly abused by attackers who leverage social engineering to masquerade as your IT support to your users, tricking them into running this legitimate application, but pointed at their remote management instance so that they can conduct nefarious steps, which can often lead to ransomware.
It is critical that you understand if an executable has a dual-use capability before you add it as an exclusion.
This is another deceptively simple exclusion that introduces significant risk:
This exclusion will ignore alerts from the Microsoft powershell.exe binary. This is of course an official binary, but adding exclusions for it allows attackers to execute all kinds of badness, from first stage malware to privilege escalation, even in some cases locking you out of your files in ransomware. Wirespeed highly recommends never adding exclusions for known Live off the Land Tools.
Using Processes Instead
Another approach to dealing with powershell might be to exclude a specific process that is acceptable, like this example, which is powershell retrieving the name of the DNS domain the computer is joined to, which is common for legitimate software to do (and also common for attackers orienting themselves within your environment, but probably OK to ignore since there would likely be other detections beyond this that are higher fidelity signal to indicate their presence):
Observe that the operator is @= and not @~=. Processes is an array (collection of many processes), so we need to use an array operator. The operator we chose requires every process to match “powershell $env:USERDNSDOMAIN”, unlike the following exclusion, which only needs a single process in the detection to match:
In that example, the detection could contain other processes which are a much higher signal of attacker behavior, resulting in a false-positive dismissal of an important alert. Exclusion logic is powerful, but must be precise. When in doubt, let Ask Wirespeed scope it for you or reach out and ask for help via support chat.
Privacy VPNs
Allowing your organization to use Privacy VPNs when logging in can pose a significant challenge to detecting malicious logins. A better approach would be to prevent their use in your SSO and Authentication systems, such as Conditional Access Policies in Microsoft. However, if that’s not possible, here are some examples.
Also, without creating exclusions at all, Wirespeed will learn to trust specific attributes of cases as you mark them as malicious or benign. For example, a suspicious login case that is closed as benign causes Wirespeed to remember that IP address for 30 days. When a user gets a detection at that IP in the 30 days following, it becomes automatically closed as benign, and the clock is reset for another 30 days from that point for more logins.
Further, to reduce impact on the security team from working escalations from Wirespeed, we highly recommend enabling Chat Ops to do this work for you. We will reach out to end users, ask them if they just logged in from an unusual location, authenticate them out of band (if enabled), and learn the safe locations … all without putting any burden on you.
How NOT to create an Exclusion for Privacy VPNs
The following exclusion is very loose and opens your organization up to significant risk, by simply ignoring (excluding) any detection or alert associated with NordVPN. This logic goes beyond just Login detections and could potentially exclude malware cases involving an IP address from NordVPN, as well as any user in your entire organization. Attackers use NordVPN, too, so this exclusion is NOT recommended.
Slightly Better
By adding the Login category, this exclusion will now no longer apply to other types, such as Execution (malware) or Invocation (cloud control plane). It is still quite loose and not recommended, because it allows any user, and it’s probable an attacker using NordVPN at some point could steal credentials or sessions and login with them from that provider, hit this exclusion rule, and there would be no alert:
Specific Users
Building on the above, if we add another AND clause, wrap it in parentheses, and specify the email addresses of the specific users we expect to be using NordVPN, then we get an even tighter rule. It still comes with the risk that an attacker could steal the credentials for these particular users and attempt to login with them, though:
A Very Tight Example
This example builds on the one before, but further restricts it to Austin, Texas. As a result, the likelihood of an attacker being able to steal credentials for the named users, use this specific privacy VPN, from this specific city and region, really reduces the odds of missing a true positive. It’s still preferable to block privacy VPNs in authentication settings or let ChatOps handle this for you, but if those aren’t good options for some reason, this is available:
Dealing with Shared Accounts
This is an example for how to craft an exclusion for a specific user account that is shared and logged in at various locations. It comes with serious risk trade-offs, though. It is ALWAYS best to follow security best practices, have good hygiene, use strong authentication (MFA), and NOT SHARE ACCOUNTS. But sometimes the security team gets overruled by the business, so this is an example for how to deal with that scenario.
First, this exclusion is restricted to the Login category, so it’s not wide open for things like malware reaching out to a location that we observe, or a user making suspicious changes in your AWS or Azure cloud control plane (Invocation).
Second, this exclusion is restricted to several U.S. states: California, Arizona, Washington, Oregon, and Nevada. Not the best, but in this particular case, there is a business reason for it.
Third, to compensate for the wide logic of the several U.S. states, any matching IP addresses must not have any of the privacy flags set on them: VPN, Proxy, TOR, Relay, or Hosting Provider. While no dataset is perfect, we have an excellent geographic enrichment that we apply to every single IP address we touch. The result of this logic will restrict to only IPs that physically reside at businesses and homes in those U.S. states. Data Center IP addresses (except for small private data centers that belong to specific businesses, not co-locations or cloud providers) will not match the logic.
The result is an attacker must physically be located in those states. Most (not all) financially motivated criminal actors will likely use hosted infrastructure to put a layer between you and their identification and attribution. So while this is not preferred (it’s always better to avoid this situation), this is a way to handle this scenario more safely than others.
