v9.0
Observables are data points found within alerts that represent potential indicators of malicious activity, such as IP addresses, URLs, file hashes, hostnames, and usernames. These pieces of information are essential for understanding what an alert is about, where it originated, and how it might relate to other activity in the environment. The Extract Observables action plays a foundational role in the alert processing workflow by automatically parsing incoming alert payloads and extracting these critical observables, along with any detectable relationships between them. By turning unstructured alert data into actionable intelligence early in the workflow, this action sets the stage for effective enrichment, correlation, triage, and automated response.
How it Works
-
Alert Processing and Initialization
- When a new alert is added to the Alerts Table, its Alert ID is received, and the system retrieves its associated payload. This payload is then processed to extract key observables and it’s relations (if it exists) systematically, ensuring all relevant data points are captured for further analysis.
-
Template-Based Parsing
- Using predefined Observable Extraction Rules in Case Management Settings, the system identifies specific alert payload fields that contain observables. Each rule maps payload keys (e.g.,
device.external_ip) to their corresponding observable types (e.g., IP Address), ensuring structured and consistent extraction.
- Using predefined Observable Extraction Rules in Case Management Settings, the system identifies specific alert payload fields that contain observables. Each rule maps payload keys (e.g.,
-
Extraction and Validation
- Once identified, it then verifies whether each extracted observable is valid and unique, preventing duplicates and filtering out irrelevant data.
Navigate [here for a more detailed explanation of observable extraction logic.
- Once identified, it then verifies whether each extracted observable is valid and unique, preventing duplicates and filtering out irrelevant data.
-
Creating and Linking Observables
- Create Observables: If the Create Observables option is enabled, extracted observables are added to the Observables Table, categorized by type (e.g., IP addresses, usernames).
- Link Existing Observables: If the Link Existing Observables option is enabled, the extracted observables are linked to the alert record, associating them with existing data for further investigation.
For best results, we strongly recommend enabling both ‘Create Observables’ and ‘Link Existing Observables’ options.
Extract Observables Action Fields
Extract Observables Action Fields
| Parameter | Description |
|---|---|
| Alert ID | The Alert ID received from the incoming alert payload |
| Create Observables: | If the Create Observables option is enabled, extracted observables are added to the Observables Table, categorized by type (e.g., IP addresses, usernames). |
| Link Existing Observables: | If the Link Existing Observables option is enabled, the extracted observables are linked to the alert record, associating them with existing data for further investigation. |
‘Extract Observables’ Action Output
When the ‘Extract Observables’ action is executed, the output is returned in a structured JSON format. This output provides detailed information about the observable extraction process, including the following key fields: Note: The following images and
JSON outputs are provided for illustrative purposes only. The actual results you see may vary depending on how you have configured the Extract Observables action and the associated Extract Observable Rules.Extract Observables Output Example
Extract Observables Output Example
Breakdown of the `JSON` Key-Value Pairs
Breakdown of the `JSON` Key-Value Pairs
matched_rule : Indicates whether the alert matched an existing Observable Extraction Rule.rule: The name of the rule that was matched, if applicable.processing_status: Represents the current state of the observable extraction workflow.- Unprocessed – The alert has not yet gone through observable extraction or any related processing.
- Missing Template – No matching Observable Extraction Rule was found for this alert, meaning the system doesn’t know how to extract observables from its structure.
- Mid-processing – The alert is currently being processed. Observable extraction or case deduplication is still in progress.
- Bad Template – A matching Observable Extraction Rule was found, but the system failed to extract any observables because the expected fields (defined in the rule) were not present in the alert’s data. This status is only assigned if
0observables were extracted. - Processed – The alert has successfully completed observable extraction and case deduplication.
In the Extract Observable action, if both the Create Observable and Link Existing Observables checkboxes are left unchecked, the
processing_statusfield will be omitted from the output. As a result, the processing status will not be updated when the action is executed.
extracted_observables: A list of observables that were successfully extracted from the alert. Each observable object contains the following attributes:id: A unique identifier for the observable.name: The logical name of the observable (e.g.,agent_id).type: The classification of the observable (e.g.,Device Agent ID).content: The extracted value or identifier (e.g., a hash, string, or ID).relation: The context in which the observable is associated with the alert (e.g.,Target Device).is_new: A boolean value that indicates whether the observable was newly extracted during alert processing. If set totrue, the observable is considered new and will be included in thenew_observablesarray at the bottom of the JSON output. If set tofalse, the observable already existed in the system and will not appear in thenew_observableslist.
new_observables: [] – This array contains only observables marked with is_new: true. An observable is considered new and included here only if an identical observable (based on its content value) does not already exist in the system. This ensures that duplicate observables are not reprocessed.case_type: The case type defines the classification or category assigned to the case that was generated from the alert. This value is typically determined based on the matched rule.log: Displays the rule selection process during deduplication. It lists additional rules that were considered but not applied because a more suitable rule was chosen for the extracted observable in the case match. This visibility helps users understand how rules are applied and supports easier self-service troubleshooting. If no additional rules are found, the field remains an empty string.The system selects the most appropriate rule based on the Alert Name. When multiple rules could match, the rule with the longest matching string is prioritized, and exact matches take precedence over regular expression (regex) patterns.
Troubleshooting Observable Extraction Action
When observable extraction action fails or produces unexpected results, it is important to understand how blink processes and maps observables based on the alert payload’s data and configured deduplication rules (templates). When troubleshooting observable extraction, there are several key fields and scenarios to consider that can help you understand what went wrong:- Missing Template: The action may have failed because it couldn’t find a matching extraction template.
- Invalid Template: A template was found, but it failed to extract any observables, this typically indicates an issue with the template logic.
- Partial Extraction Only a subset of observables was extracted, even though the template mapping includes more. This could be due to how the data was structured or how the extraction rules were defined.
- Duplicate Observable Content (edge case): In some cases, an observable’s content may already exist in another observable. If so, the observable linked to the alert will retain the original observable type already associated with that content.
-
Extraction Limit (edge case): If there are more than
100 observablesto extract from a single alert, the system will not extract any. This is a built-in size limit.
‘Extract Observables’ Action – Use Case Example
'Extract Observables' Action – Suspicious File Execution Detected
'Extract Observables' Action – Suspicious File Execution Detected
Case Summary: Suspicious File Execution DetectedCrowdStrike Falcon Insight has flagged a potential malware incident involving whoami.rtf, a file executed on DESKTOP-HLLEERH by user bart.s from the /Users/wilder/ directory. The execution method—command-line invocation (
Alert IngestionStep 1: Create an Alert RecordTo begin handling this case, start by triggering the Alert Ingestion workflow. When the workflow runs successfully, it will create a new Alert and populate its details in the Alert Table. This allows security teams to track the incident, correlate it with other related alerts, and take appropriate action efficiently.
Step 2: Define Observable & Relations TypeAfter creating the alert, the next step is extracting key observables and it’s relations|(if application). Observables refer to data (such as file hashes, IP addresses, and domain names) that help security teams track malicious activity.
Step 3: Execute the Extract Observables ActionOnce observables and observable relations (if applicable) are identified, we need to run the Extract Observables action.
./whoami.rtf)—is suspicious since RTF files are not meant to be executable. This suggests Masquerading, where attackers disguise malicious files to bypass security measures.The file’s execution indicates a possible attempt to gather system information using the whoami command. Further investigation is needed to assess the impact and mitigate risks.Alert IngestionStep 1: Create an Alert RecordTo begin handling this case, start by triggering the Alert Ingestion workflow. When the workflow runs successfully, it will create a new Alert and populate its details in the Alert Table. This allows security teams to track the incident, correlate it with other related alerts, and take appropriate action efficiently.
Click here to view the full Alert's Payload
Click here to view the full Alert's Payload
Step 2: Define Observable & Relations TypeAfter creating the alert, the next step is extracting key observables and it’s relations|(if application). Observables refer to data (such as file hashes, IP addresses, and domain names) that help security teams track malicious activity.
-
Create an Observable Extraction Rule to determine:
-
Observable Type – In this use case example, we are extracting:
- A Resource UID (unique identifier of the suspicious file).
- An IP Address (if the file attempted to communicate externally).
-
Observable Relations – This defines how extracted observables relate to each other and the alert:
- whoami.rtf (Resource UID) is linked to FalseExecutableExtension (alert).
- If an external connection was made, the extracted IP Address would be linked to both the file and the alert.
ֿNote: Not all extracted observables will have observable relations, and defining such relationships is not mandatory. However, when relations exist—such as a file being associated with a specific IP address or command execution—these will be automatically extracted and identified as part of the process. This helps build a clearer picture of the attack chain and supports better investigation and response. -
Observable Type – In this use case example, we are extracting:
Step 3: Execute the Extract Observables ActionOnce observables and observable relations (if applicable) are identified, we need to run the Extract Observables action.
- This automated action parses the alert payload, extracts observables and observable relations(if they exist), and categorizes them according to the extraction rule.
- The extracted observables and their relations are stored in the case management system for correlation, enrichment, and further investigation.
- Security teams can then use these observables for threat intelligence lookups, IOC (Indicator of Compromise) correlation, and automated response actions.