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, such as abnormal read volumes, write volumes, write sizes, or write frequency.
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.
Four ML models analyze the audit stream, each looking at a different dimension of user behavior. See Threat Hunting detection types.
The Threat Hunting VM runs separately from Eyeglass. It connects to the ECA Kafka brokers on port 9092, processes the audit stream, stores results in ClickHouse, and surfaces them through Apache Superset dashboards and the Threat Hunting interface.
Navigate to Threat Hunting in the left sidebar under Data Security.
Threat Hunting is included in your Data Security Edition subscription license and requires a dedicated ML VM deployment. It appears in the left sidebar once installed. See Machine Learning VM and Threat Hunting installation for setup requirements.
Access the Threat Hunting Interface
The interface opens in a dedicated view. If prompted, authenticate with your Eyeglass credentials. The page lists detected anomaly events with summary columns for quick triage, and a filter/search bar at the top.
What Threat Hunting Adds to Eyeglass
Once Threat Hunting is enabled and the module is running:
- A Threat Hunting menu item opens the Threat Hunting interface.
- Alarm RSW0034 (severity: Warning) is raised when Threat Hunting detects a high-confidence anomaly. See Alarm Codes.
- The Threat Hunting VM is added to Managed Services automatically after the installation.
- The existing webhook settings are extended to forward Threat Hunting anomalies to SIEM tools. See Integrate Threat Hunting with Your Security Stack.
Threat List
Each row in the threat list represents a single anomaly event detected by the ML system.
Threat List Columns
| Column | Description | Example values |
|---|---|---|
| Severity | The ML-assigned threat severity level. | high, med_high, med, low_med, low |
| Confidence Score | How strongly the activity deviates from the user's baseline, 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. |
| med_high | Substantial deviation from normal activity. Requires prompt review. |
| med | Moderate anomaly. May indicate early-stage threat activity or reconnaissance. |
| low_med | Minor deviation from baseline. Worth monitoring. |
| low | Minimal deviation. Low urgency but worth recording. |
Confidence Score and Severity
Every Threat Hunting event has a confidence score from 0 to 100%. The score reflects how far the activity deviates from the user's baseline, and it determines the severity of the event:
| Confidence score | Severity |
|---|---|
| 0–30% | low |
| 30–60% | low_med |
| 60–~81% | med |
| ~81–~88% | med_high |
| Above ~88% | high |
Events with a confidence score of 75% or higher raise alarm RSW0034 in Eyeglass and are never closed automatically. The 75% threshold can be changed. See Frequently Asked Questions.
Practical guidance:
- Review events with a score of 75% or higher first. They stay open until an administrator closes them.
- Review the Open tab regularly. Open events with a score below 75% are labeled as Expected Behavior automatically after 7 days, and a steady stream of untouched low-score events can shift the baseline.
How the Confidence Score Is Calculated
The Threat Hunting models use HDBSCAN, a density-based clustering method:
- Density-based clustering: the model groups training points by how tightly packed they are. There are no fixed thresholds.
- Outliers are anomalies: a point that does not fit any cluster is flagged. Its distance from the nearest cluster is the raw deviation.
- Per-user baselines: the same activity can be anomalous for one user and normal for another. For example, a 200 MB write can be anomalous for a user whose normal writes are 5–50 MB, and normal for a backup service account that writes 500 MB nightly.
- Score = deviation, mapped to a percentage: the raw deviation is mapped to a 0–100 scale so that the confidence score in the interface is easy to interpret.
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
Model Training
The models learn from the audit events collected for each monitored cluster and path.
- Initial training: a new deployment needs a stretch of ordinary activity before the baselines mean anything. Plan an initial training on 30 days of collected audit events. A minimum of 2 weeks of activity captures weekday and weekend patterns, and 1 month is recommended to capture monthly cycles.
- Weekly retraining: in steady state, training runs every 7 days. Each training job leaves out the most recent 48 hours of data, so that the data can settle.
- Feedback: events closed as Expected Behavior, and open events with a score below 75%, are included in the next training run.
- No maintenance window: each scheduled training run appears in the Jobs view, with one row per model showing the start time, end time, status, and training data size. When a run succeeds, the new model version is marked ACTIVE, and the inference service picks it up the next time it refreshes its cache. There is no pod restart and no dropped scoring.
To configure the training schedule and delta time, see Training Scheduler Configuration.
Search and Filter 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.
View 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.
Respond 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 event is included in the next scheduled training, so the model learns that this behavior is normal for the user. This reduces false positives for comparable activity going forward. Until that training run completes, the same activity can be detected again. 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. The event is excluded from model training permanently. 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.
Automatic Labeling
Open events with a confidence score below 75% are labeled as Expected Behavior automatically after 7 days. Events with a score of 75% or higher are never labeled automatically and stay open until an administrator closes them. For details, see Automatic Labeling.
Threat Hunting Detection Types
Threat Hunting deploys four ML models. Each model analyzes a different dimension of user storage behavior from the ECA audit stream, operates independently, and generates its own confidence score. Several models can fire on the same user at the same time.
| Model | Threat category | Signal | Detects | Example trigger |
|---|---|---|---|---|
| RWM-READ | TD 101 | bytesRead | Bulk reads and data exfiltration reconnaissance | A user who normally reads in 4 KB chunks suddenly reads in 1 MB blocks. |
| RWM-WRITE | TD 102 | bytesWritten | Large-volume writes and frequent overwrites | Mass file writes across shares the user rarely accesses. |
| ML-1 | TD 103 | Average bytesWritten | Unusual write chunk size | A backup application that normally writes 64 KB chunks starts writing 512 KB chunks. |
| ML-2 | TD 104 | writeEventsCount | Write-frequency bursts | A service account that normally performs 50 writes per second suddenly performs 500. |
Data exfiltration occurs when a user copies data. PowerScale does not provide a specific copy operation type, so the models analyze read and write activity instead.
Threat Hunting is a PowerScale-only capability (see Limitations and considerations). For ECS-specific object-storage detectors, used by Threat Detection and not by Threat Hunting, see Threat Detection and Severity Settings — ECS object storage detectors.
Monitor Training Jobs and Dashboards
The Jobs view in the Threat Hunting interface lists all running training jobs. Use it to verify that training jobs succeeded and to review any errors.
Apache Superset is bundled with the Threat Hunting VM and is the secondary tool for deep investigation and troubleshooting. Six dashboards are available. Access Superset at:
https://<THREAT_HUNTING_MODULE_IP>:30443/superset/welcome
| Dashboard | Use | Description |
|---|---|---|
| 01 — Anomalies Count Report | Trend analysis | Volume of anomalies over time. |
| 02 — Anomalies Deviation & Confidence | Investigation | Deviation magnitude and confidence score per anomaly. |
| 03 — Threats Detected Summary | Daily monitoring | Overview of anomalies detected in the last 7 days. |
| 04 — Threat Investigation | Deep investigation | Full drill-down on a specific anomaly. |
| 05 — Audit Events Overview | Data validation | Confirms the audit stream is flowing from ECA Kafka. |
| 06 — Training Jobs | Verification after install | Review the jobs created, which should be at least 4. Click a UID, then Plots, to review the training plot. |
If no anomalies appear after installation, see Threat Hunting Troubleshooting.
Integrate 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 need a period of ordinary activity before their baselines are reliable. Training too early produces a sparse baseline and a flood of false positives. See Model training for the recommended accumulation period and the initial training.
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 measure deviation: The confidence score is the deviation from the user's baseline, mapped to a 0–100 scale. It is not a probability that the event is a threat. A high score means a strong deviation. 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.
- Threat Hunting installation — How to install and configure the ML VM.
- Detection Types Reference — Complete list of detection categories.
- Integrations — SIEM/SOAR webhook configuration.
- Frequently Asked Questions — Common questions about how Threat Hunting detects, scores, and labels anomalies.