Skip to main content

Understanding and Resolving Security Alerts Triggered by Druva Enterprise Workloads Activities

Understanding and Resolving Security Alerts Triggered by Druva Enterprise Workloads Activities

Problem description

Endpoint Detection and Response (EDR) or Antivirus (AV) platforms (such as CrowdStrike Falcon, Microsoft Defender for Endpoint, SentinelOne, or Carbon Black) flag legitimate Druva Enterprise Workloads processes (e.g., Phoenix agent components) as suspicious, potentially unwanted applications (PUA), or malicious behavior.

In severe scenarios, the security tool may quarantine binaries, block child process execution, or terminate active services. This causes running backup or restore jobs to freeze, fail, or exit abruptly, typically coinciding with VSS snapshot creation, file indexing, or high-volume data read phases.

Cause

To perform data protection and disaster recovery across enterprise servers and hypervisors, the Druva agent interacts with lower-level operating system layers:

  • Invoking and querying Volume Shadow Copy Service (VSS) writers and taking filesystem or disk-level snapshots.

  • Scanning massive directory hierarchies, reading metadata, and accessing system-protected files.

  • Communicating with workload-specific APIs (such as Microsoft SQL VSS Writer, Oracle RMAN, or VMware/Hyper-V integration components) for application-consistent backups.

  • Encrypting and transmitting large data volumes outbound over TLS to the Druva Cloud.

Heuristic, behavioral, or machine-learning detection engines monitor for traits commonly associated with ransomware or unauthorized data exfiltration. Because Druva’s routine operations involve rapid file traversal, low-level disk calls, and high-volume encrypted traffic, security platforms can generate false-positive alerts if proper process exclusions have not been defined.

Traceback

In third-party EDR/AV consoles:

Detection Type: Behavioral / Heuristic / Suspicious Process Activity Severity: High / Medium Threat Name: Suspicious File Modification / Potential Ransomware Activity / Unauthorized VSS Access Process Name: Phoenix.exe / PhoenixApp.exe / PhoenixAgent.exe Action Taken: Blocked / Quarantined / Alert Only

In Druva Cloud Console or Agent Logs (Phoenix.log / Backup.log):

[ERROR] Process terminated unexpectedly or access denied while accessing snapshot. [ERROR] Failed to query VSS writer status. System error: Access is denied. (0x80070005) [WARN] Connection dropped or agent process exited prematurely during file indexing phase.

Resolution

Step 1: Inspect and verify the flagged binary

  1. Access your endpoint security management console and locate the alert details.

  2. Review the flagged process name, file path, command-line arguments, parent process, and file digital signature.

  3. Confirm that the binary is signed by Druva (or verified under default install paths, such as C:\Program Files\Druva\Phoenix\bin\ or /opt/Druva/Phoenix/bin).

Step 2: Correlate alert timestamps with Druva backup activity

  1. Log in to the Druva Cloud Console.

  2. Navigate to Enterprise Workloads and select the workload type (e.g., File Servers, MS-SQL, VMware).

  3. Inspect Job Activity for the target host around the alert timestamp.

  4. Verify whether a snapshot creation, file indexing, or backup/restore job was running concurrently with the security alert.

Step 3: Define exclusion rules in endpoint security software

  1. Once confirmed as a legitimate Druva operation, add the official Druva process paths, folder trees, and digital signatures to your security vendor's allowlist / exclusion policy.

  2. Ensure exclusions cover:

    • Primary installation directories (e.g., C:\Program Files\Druva\Phoenix on Windows, /opt/Druva/Phoenix on Linux).

    • Dedicated agent and proxy executables (Phoenix.exe, PhoenixApp.exe, PhoenixAgent.exe, PhoenixFSVSSWorker.exe, etc.).

  3. Deploy the updated policy to the affected host groups.

Note: If the detection cannot be correlated to a valid Druva task or if the binary signature is missing/untrusted, do not add exclusions. Keep the alert contained and contact Druva Support.

Include and exclude filters

  • Process Exclusions: Add absolute executable paths (Phoenix.exe, PhoenixApp.exe, PhoenixAgent.exe) rather than generic wildcards to avoid creating security gaps.

  • Path Exclusions: Whitelist Druva installation folders, metadata staging locations, and local cache paths.

  • Behavioral Filters: Where supported by your EDR tool, whitelist Druva binaries from specific ransomware mitigation rules that monitor rapid file-touching and VSS deletion/access.

Verification

  1. Mark the alert as an inspected false positive in your security software console.

  2. Confirm the Druva agent services remain in the Running state without being terminated.

  3. Trigger a manual on-demand backup for the affected workload and verify it completes with status Successful.

See also

Did this answer your question?