Managed EDR

When Huntress remediates a threat by deleting artifacts, a protected copy should be retained for a configurable period and made accessible to admins for post-incident investigation. This is standard behavior in major NGAV/EDR platforms and is critical for: Root cause analysis — examining the original payload after the fact Threat intel extraction — submitting samples to sandboxes or sharing with IR teams Evidence preservation — maintaining chain of custody for compliance or legal purposes False positive review — verifying legitimate files weren't incorrectly removed The retained copy should be: Cryptographically isolated (e.g., encrypted vault or password-protected archive) to prevent re-execution Accessible only to admin-level users in the Huntress portal Subject to a configurable or fixed retention window before permanent deletion Ideally downloadable Currently, files deleted by Huntress are unrecoverable, which can significantly hamper post-incident investigations on managed endpoints.

I am starting to see a new pattern of Screenconnect style attacks (via phishing) that always leaves some automatic remediations unable to complete. The components of this are twofold, and am hoping that maybe with this feedback, it can become more automated in the future. These issues always seem to manifest as a permissions-related issue with deleting the infected folders. This occurs for one of two reasons: The permissions are truly locked down on the folder and have to be forcefully re-added to a local administrator so deletion can occur. In both cases I have seen, I have had to use the following commands to allow deletion: takeown /f " insert path to folder/file here " /r /d y icacls " insert path to folder/file here " /grant Administrators:F /t /c /q Sometimes though, this is not even enough, and the reason for it is worrisome. These screenconnect attacks have gone so far as to modify a key registry value that injects a malicious dll file upon boot, even in safe mode. The path to the key is: HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Lsa\Authentication Packages Normally, this key only reads "msv1_0" however in an infected machine, it will have the path to a malicious dll appended to the end. Subsequently the dlls cannot be deleted until this appended path is removed, and system is rebooted. I suspect that if the automated response is aware of these needed changes, it might be able to be removed without our direct intervention.

A partner managing Huntress Managed Microsoft Defender exclusions ran into significant usability issues while trying to add 2 endpoints to roughly 12 existing exclusions in a single org. In its current form, this workflow is highly manual and does not scale well for real-world administration. -- Current pain points: Managed Exclusions are currently scoped only at the account, organization, or endpoint level; there is no way to target exclusions by machine type, tag, or group. The partner wants to apply exclusions to a subset of systems within an org, such as a logical grouping like FSLogix hosts, without having to manage each endpoint individually. Editing exclusions appears to be effectively one-at-a-time for this workflow, making repetitive changes across many exclusions slow and frustrating. After each edit, the UI resets filters, forcing the admin to re-find their place and repeat the same navigation over and over. The partner explicitly described this as one of the worst UX experiences they have had in a long time, which suggests this is more than a minor inconvenience and is likely to create friction for larger or more mature environments. -- Public API support for Managed Exclusions Expose Managed Exclusions management through the Huntress API so partners can automate: Listing exclusions Creating exclusions Updating exclusion scope Bulk assigning endpoints Removing endpoints from exclusions This would allow partners to automate repetitive changes that are currently manual in the UI.

We've had clients question the status of their protection after moving from more traditional EDR's as there is no icon in either the Menu Bar or System Tray to indicate or show a pop up that they are protected. I understand this is purely a cosmetic change but it would save a lot of headaches explaining that it is still working.

PUP that should be considered as Malicious

Employees are using OpenAI ChatGPT, Anthropic Claude, OpenClaw, browser copilots, AI extensions, personal API keys, and many other tools..... often without IT visibility. Our IT departaments need What AI tools are being used What data is being uploaded or pasted If sensitive information is leaving the company Which tools are approved vs shadow AI How to manage risk without killing productivity Many companies are blind here are risk is very high. Traditional firewalls and DNS filters are not enough. In February during The Product Lab, they mentioned the idea of an AI Scraper to detect AI tool usage, APIs, exfiltration risks, and user activity. Two months later, that idea already feels necessary.

We recently transitioned from a different solution, SentinelOne, and Huntress is certainly better. There is only one thing we miss: having PowerShell access through the system. I assume Huntress uses PowerShell to manage remediations, as that would be the most logical method. Is this something that can be integrated into the portal? If it comes from the Huntress portal, it could be tied into the same ip exceptions that huntress already uses to talk to the device during isolation.

Currently, filtering on the agents can be performed based on Defender Firewall Status being either "Active" or "Disabled". In the new reports, a count of hosts with firewall policy conflicts is listed but there is no way to filter in the UI for all agents with a policy conflict. Please implement a filter that allows for filtering based on policy conflict status.

Add a Huntress-initiated "Repair Defender" action that can be invoked. Behind the scenes, this could orchestrate the existing recommended sequences, (e.g., validate Defender services, attempt lightweight reset, then optional deeper OS/Defender repair path), provide status back to the portal and log what was executed. Configuration could include safeguards (e.g., only when Defender is primary/only AV, confirmation prompts for destructive steps, etc.) There is excellent documentation for resetting and repairing MS Defender (Reset Platform, uninstall/re-install on Server, resetting policies, etc.) but it is all manual or script-driven today. There is no simple Huntress platform "Repair Defender" action in the UI. Frontline technicians must copy scripts, run OS-level repair commands and interpret output which can be error-prone and time-consuming.

Today we have to click on individual agents and infer "online vs. offline: from "Last Seen" check-in behavior. The Agents dashboard for both Accounts and Organizations does not expose a simple explicit state at a glance. This slows down triage and makes it more difficult for technicians to quickly confirm if a device is "live." Add a clear, Online/Offline (or Currently Connected) indicator directly in the "Agents" list view (add to both global and organization levels), ideally with sortable/filterable status and hover text explaining logic (e.g., seen in last X minutes). This request is in addition to the Organizational Level "Last Seen" and "Unresponsive" Agent Behavior.