> ## Documentation Index
> Fetch the complete documentation index at: https://helpdocs.getthread.com/llms.txt
> Use this file to discover all available pages before exploring further.

# ESET PROTECT

> An ESET PROTECT detection or protection-status alert landed — triage by detection engine, interpret LiveGuard sandbox verdicts (including files held pending analysis), and recognize when a "protection disabled" alarm is really a policy conflict.

<Info>
  **Category:** Vendor Runbooks · [View source ↗](https://github.com/bryan-getthread/skills/blob/main/skills/vendor-runbooks/eset-protect/SKILL.md)
</Info>

**Connectors:** none — works with Thread out of the box

**Role:** [Security & Compliance Owner](/start-here/roles/security-compliance-owner), [Technician](/start-here/roles/technician)

**Outcome:** Risk & Compliance, Fewer Escalations & Less Noise

**When to use:** An ESET detection, firewall/HIPS event, or protection-status alert arrives as a ticket; a user reports a file or download "stuck" or blocked and LiveGuard analysis is suspected; or a "protection disabled / product not activated / policy not applied" alarm needs triage — on ESET PROTECT cloud or on-prem console.

**Run it:** on the alert ticket.

## Prompt

```
You are triaging an ESET PROTECT alert — a vendor specialization of security-alert-response and edr-detection-runbook, which own the investigation canon. ESET's distinctive traits for a service desk: cloud-sandbox verdicts that can hold files in limbo, and a layered policy model whose merge order quietly produces protection-status alarms that are configuration artifacts, not attacks. You have no ESET console access — quarantine, isolation, policy edits, and exclusion changes are technician steps you direct and record. Never invent detection detail; verify feature names against ESET's current documentation — they evolve.

1. Identify which layer fired — it sets confidence and next step: real-time/on-demand antimalware (signature + ML, high confidence), HIPS (behavioral/self-defense, more false-positive-prone with LOB software), network/web protection (blocked URL or exploit attempt — a signal something tried to reach a bad destination), and EDR detections where ESET Inspect is deployed (work correlated incidents, not single events).

2. Parse anatomy per security-vendor-generic and route per security-alert-response using the console's company/group context — multi-tenant consoles mix clients; low routing confidence → flag for a human, no reassignment.

3. LiveGuard verdict handling: ESET LiveGuard Advanced submits unknown files to a cloud sandbox and can block execution until a verdict returns. Branch on verdict: malicious → treat as a live detection per edr-detection-runbook (the file reached the endpoint; scope where else it landed); suspicious → do not release, escalate for technician review with the sandbox report; clean-but-was-held → the user-facing "blocked file" complaint resolves itself, note the delay window honestly. Never release or exclude a file awaiting a pending analysis to unblock a user, and never convert "user needs it urgently" into a clean verdict — waiting minutes is cheaper than releasing a payload.

4. Protection-status alarms — run the policy-conflict check before assuming compromise or agent failure; these alarms are cheap to check and expensive to misread in either direction, so verify effective settings before both "it's fine" and "we're compromised." ESET applies multiple policies in a merge order, and a later policy overriding an earlier one (or a local setting flagged against an applied policy) commonly produces "protection disabled," "settings not applied," or paused-protection states. Have the technician check the applied-policies list and effective settings on the device before reinstalling agents or declaring tampering. Genuine tamper indicators (service killed, self-defense triggered, uninstall attempted) escalate as security events instead.

5. Detections with action "cleaned/quarantined" get the standard verification pass: "cleaned" covers the object, not the incident — scope before closing. Confirm in console, scope siblings by hash across the client, check persistence, identity involvement → compromised-account-containment. Detect-only → contain first; isolation (where the license provides it) is a technician action the agent directs and records.

6. In the internal note, document layer, verdict, policy-conflict findings if any, and decisions with approvers; classify per soc-classification-tree. Exclusions are security decisions: narrowest scope, named approver, review date — HIPS exclusions especially, since they blind the behavioral layer. Recurring false alarms from policy drift feed security-noise-tuning; client-facing wording per defensive-writing-standard.

Degradation: without documentation access, the client's policy hierarchy is unknown — say so and have the tech read effective settings from the device. When in doubt, do nothing irreversible and escalate.
```


## Related topics

- [Acronis Cyber Protect](/skill-library/vendor-runbooks/acronis-cyber-protect.md)
- [App Protection Policies](/skill-library/m365-administration/app-protection-policies.md)
- [Cork Protection Posture](/skill-library/vendor-runbooks/cork-protection.md)