Threat Hunting
Overview
Threat Hunting is a machine learning-based anomaly detection system that operates independently from Ransomware Defender. While Ransomware Defender detects real-time, threshold-based behavioral patterns, Threat Hunting looks for subtler, longer-horizon deviations from a user's or entity's established baseline — including patterns consistent with data exfiltration, unusual access timing, or abnormal data volumes that fall below the Ransomware Defender thresholds.
Threat Hunting runs on a dedicated ML VM deployed separately from the core Eyeglass appliance. It analyzes audit data processed by the ECA and produces anomaly events with severity and confidence scores.
Navigate to Data Security → Threat Hunting in the left sidebar.
Note: Threat Hunting is included in your subscription license for Data Security Edition and requires a dedicated ML VM deployment. It will show up in the menu once installed. See Prerequisites and Installation — Threat Hunting for setup requirements.
Accessing the Threat Hunting interface
The Threat Hunting interface opens in a dedicated view. If prompted, authenticate with your Eyeglass credentials.
The page displays a list of detected anomaly events with summary columns for quick triage, and a filter/search bar at the top.
Understanding the threat list
Each row in the threat list represents a single anomaly event detected by the ML system.
The screenshot previously shown here displayed an older, differently-themed Threat Hunting list interface that does not match the current 2.15.0 UI (dark theme, left-sidebar navigation). It has been removed rather than left inaccurate. A current 2.15.0 screenshot of the Threat Hunting list is pending.
Threat list columns
| Column | Description | Example values |
|---|---|---|
| Severity | The ML-assigned threat severity level. | HIGH, MID_HIGH, MID, MID_LOW, LOW |
| Confidence Score | The ML model's certainty that this is a genuine anomaly, expressed as a percentage. | 88.7%, 95.2%, 75.0% |
| Source | Client IP address where the anomalous activity originated. | 192.168.1.45 |
| User | The account associated with the anomalous activity. | DOMAIN\jsmith |
| Target | The storage device being monitored. | ProductionPS-01 |
| Threat Category | The type of anomalous behavior detected. | See detection types below. |
| State | Whether the event is open or closed. | Open, Closed |
| Time Detected | When the anomaly was first identified. | Jun 18, 2025 at 4:48 pm |
Severity levels
Threat Hunting uses five severity levels, reflecting the degree of deviation from the user's baseline behavior:
| Severity | Description |
|---|---|
| HIGH | Highly anomalous patterns — significant deviation indicating a potential active threat. |
| MID_HIGH | Substantial deviation from normal activity. Requires prompt review. |
| MID | Moderate anomaly. May indicate early-stage threat activity or reconnaissance. |
| MID_LOW | Minor deviation from baseline. Worth monitoring. |
| LOW | Minimal deviation. Low urgency but worth recording. |
Confidence Score and its independence from Severity
Severity and Confidence Score are two independent dimensions of every Threat Hunting event. They measure different things:
- Severity classifies the type and intensity of the anomaly.
- Confidence Score reflects how certain the ML model is that the anomaly is real, rather than noise. A HIGH severity event can have a low confidence score (the system detected a severe pattern but is not certain it is real), and a LOW severity event can have a high confidence score (the system is very certain about a subtle anomaly). Use both dimensions together when prioritizing your response.
Practical guidance:
- Prioritize events with HIGH severity and high confidence first.
- Do not dismiss LOW severity events with very high confidence — a subtle, certain anomaly may be an early indicator of a threat developing over time.
- HIGH severity events with low confidence (below ~60%) warrant investigation but may be false positives in active environments.
Anomaly event processing
Threat Hunting builds a behavioral baseline for each user from their historical audit activity — what they access, when, how much, and from where. New activity is continuously compared against this baseline using ML models running on the dedicated ML VM.
When a deviation is detected that crosses the ML model's detection threshold, an anomaly event is created with an assigned severity and confidence score. The event captures the files involved, the source IP, the target device, and the detected threat categories.
The processing flow is:
ECA processes PowerScale audit stream
↓
Audit data forwarded to ML VM
↓
ML models compare activity against user baseline
↓
Deviation detected above threshold
↓
Anomaly event created with:
- Severity level (HIGH to LOW)
- Confidence score (0–100%)
- Threat category
- Affected files list
- Source IP, user, target device
↓
Event appears in Threat Hunting interface
Searching and filtering events
Search bar: Type any value — username, IP address, threat type, event ID — to filter the list. Results update as you type.
Filters: Click the filter icon next to the search bar to apply structured filters:
- Severity — filter by one or more severity levels
- Confidence Score — filter by a minimum confidence threshold
- Category — filter by specific threat types
- User — filter by specific user accounts
Active filters appear as tags above the list. Use the Reset button to clear all filters. A counter (for example:
+2) shows how many filters are currently applied.
Viewing event details
Click any event in the list to open the details panel on the right side of the screen.
Open threat details panel shows:
- Event ID and detection timestamp
- Threat categories with descriptions of the anomalous behavior patterns
- Severity level and confidence score
- Affected files and folders (searchable)
- File types and extensions involved
- Source IP, target device, and item count
- Full details section (expandable) with all event metadata Investigate button: Opens the dedicated investigation page for deeper analysis — search through affected files, filter data, analyze patterns, and add comments.
Take an Action button: Opens the response options to close the event.
Responding to Threat Hunting events
Open vs. closed events
Open events require investigation and classification. Any action taken on an open event moves it to the Closed tab.
Closed events are read-only. You can investigate them for historical review and add comments, but cannot change their status.
How to take action
- Locate the Take an Action button in the threat details panel or on the investigation page.
- Click it to open the action selection dialog.
- Choose one of two closure options: Close as Expected Behavior Use when the detected activity is confirmed as normal business operation for this user or application. The system uses this feedback to retrain the ML model, improving future accuracy for similar patterns in your environment. This reduces false positives for comparable activity going forward. Common scenarios: bulk file operations during a deployment, automated backup systems, database maintenance scripts. Close as Anomaly Confirmed Use when you have verified the activity is genuinely suspicious or represents a security concern. Because the ML model detected this correctly, closing as Anomaly Confirmed does not retrain the system — it confirms the detection was accurate and creates a record of a genuine security incident for your audit trail. Common scenarios: unauthorized access to sensitive files, data exfiltration patterns (unusually large downloads), ransomware-like behavior.
- Optionally add a comment for audit purposes.
- Confirm your selection. The event moves to the Closed tab.
Threat Hunting detection types
The following categories of anomalous behavior are detected by the Threat Hunting ML models. Threat Hunting is a PowerScale-only capability (see Limitations and considerations below), so every category here is PowerScale-scoped — for ECS-specific object-storage detectors (used by Threat Detection, not Threat Hunting), see Threat Detection and Severity Settings — ECS object storage detectors.
| Category | Type | Description |
|---|---|---|
| Data Creation and Deletion | Ransomware | Creation of new encrypted data while removing original data |
| Data Encryption | Ransomware | New encrypted data created with a specific extension while originals are removed |
| Data Renaming | Ransomware | Data read followed by bulk file renaming |
| Suspicious Extension | Suspicious Activity | File operations with extensions associated with ransomware |
| Mass Delete | Data Loss | Multiple files or objects deleted from a single location |
| Data Loss Prevention | Data Theft | DLP access threshold exceeded |
| Honeypot Activity | Suspicious Activity | Interaction with honeypot tripwire files |
| Data Overwrite | Ransomware | Data read followed by bulk overwriting of the same files |
| Multi-Extension File Modification | Ransomware | Files renamed to multiple different extensions |
| Data Deletion | Data Loss | Bulk deletion of objects or buckets |
Integrating Threat Hunting with your security stack
Threat Hunting supports webhook integrations to forward anomaly events to SIEM or SOAR platforms. Configure webhook endpoints in Integrations from the left sidebar.
For webhook configuration details, see the Integrations reference page.
Limitations and considerations
Baseline learning period: The ML models require a period of normal activity to establish a reliable baseline before anomaly detection becomes effective. In new deployments, expect a higher rate of false positives during the first few weeks while the baseline is being built. Closing events as Expected Behavior during this period accelerates baseline refinement.
ML VM dependency: Threat Hunting is entirely dependent on the ML VM being operational. If the ML VM is offline, no anomaly events are generated. Monitor ML VM health in Health Check.
Confidence scores are probabilistic: A 95% confidence score does not mean the event is definitely a threat — it means the ML model is 95% confident the deviation is real. Always verify with investigation before taking action.
Threat Hunting does not lock out users: Unlike Ransomware Defender, Threat Hunting does not automatically revoke user access. All response actions are manual. If investigation confirms malicious activity, you must take containment steps through Ransomware Defender or manually via your storage platform.
PowerScale only: Threat Hunting is not available on ECS. ECS environments are covered by Threat Detection's ECS object storage detectors instead.
See also
- Threat Detection — Ransomware Defender events, triage, and response.
- Installation — Threat Hunting — How to install and configure the ML VM.
- Detection Types Reference — Complete list of detection categories.
- Integrations — SIEM/SOAR webhook configuration.