When adding exceptions – especially Endpoint Exceptions – it is crucial to understand the activity from top to bottom. This article details recommended methodology for adding endpoint exceptions and includes some helpful examples.
Definition
An Endpoint Exception prevents the Cerulean Agent from taking action and raising alerts for specific files, processes, or behaviors. These exceptions prevent legitimate applications or behaviors from being blocked or flagged by the EDR.
Endpoint Exceptions can be added in directly relation to EDR/MDR alerts in the AgileBlue Portal.
To learn more about the mechanics behind adding exceptions, click here.
General Guidance
Before whitelisting any activity, make sure to review the following steps:
- Confirm the activity came from a trusted source
- Validate the file/process path is expected in the environment
- Confirm the user or service account performing the action is legitimate
Malware Prevention Alerts
Malware prevention alerts trigger when a process, file, or DLL is blocked due to:
- Known malicious reputation
- Being unsigned or incorrectly signed
- Behavioral similarity to known malware families
What to Check First
- Look at the code signature fields to determine if the item is signed:
- process.code_signature.exists
- file.code_signature.exists
- process.parent.code_signature.exists
- dll.code_signature.exists
- If these fields show True, it means the signature exists; if False, it is unsigned.
- If the item is unsigned but known to be legitimate, an exception should be created.
What To Use When Adding An Exception
- Use one of the following identifying components as the Field:
- process.name
- file.name
- dll.name
- Full path of the executable/dll if necessary
- Hashes can also be used, but it is not recommended as a stand-alone field unless it is a one-off incident. Hashes change, but paths and signatures are more stable.
Example Logic
Custom.client_id is 1
AND
process.name is legitimate_process.exe
AND
parent_process.name is approved_launcher.exe
AND
file.name is approved_file.name
AND
host.hostname is hostname *if limited to a specific device*
AND
user.name is username *if limited to a specific user*- A query like the one above will be useful in scenarios where either of the three listed (process, parent process, or file) are unsigned but should be allowed to run in the environment.
- Adding the host or user would limit the exception to a single device or a single user; if the exception should be applied environment-wide, these fields should not be included.
Behavior-Based Prevention Alerts
Behavior-based alerts focus on actions, not just files. These alerts typically include "Prevention" in the rule name, indicating the action was actively blocked.
Key Fields to Review
- Message – Explains what behavior was detected
- rule.description – High-level logic of the detection
- process.name and process.args – What was being executed
- process.parent.name and process.parent.args – What launched it
These fields allow you to understand the behavior being blocked and whether or not the behavior is expected or suspicious.
Adding Behavior-Based Exceptions
- Always include the rule.id as an exception condition to keep the rule tightly scoped and prevent unintentionally allowing other potentially malicious activity
Example Logic
Custom.client_id is 1
AND
process.name is legitimate_process.exe
AND
parent_process.name is approved_launcher.exe
AND
rule.id is approvedruleID
AND
host.hostname is hostname *if limited to a specific device*
AND
user.name is username *if limited to a specific user*- This example query would be useful in scenarios where a suspicious behavior is detected that analyzes how processes behave rather than relying on file signatures or known indicators. The alerts identify potential threats like privilege escalation, persistence, credential theft, or data exfiltration by monitoring command-line actions, registry changes, and process interactions.