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.

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.

Today, Huntress focuses on malicious footholds and behavior, so the presence/installation of these tools alone does not generate an alert. This can lead to situations where tools are discovered “by accident” on a host and Huntress has not surfaced anything notable because there’s no confirmed malicious activity yet. I expect visibility and some level of escalation for these sensitive tools so we can quickly confirm whether these tools were intentionally deployed. I also wants the ability to distinguish between “expected” dual‑use tools and unexpected ones and feels this isn’t possible from the current UI/detections. This creates a perception gap where companies like mine feel that potentially risky monitoring/remote‑control software can hide in plain sight unless we manually deep‑dive each host.

After fixing "Unmanged" clients, it can take up to 24 hours for the portal to update. Support said that they need to send a force survey command. I would like to see a "Force Survey" button added to the client portal.

Huntress now supports an IP address allow list for isolated hosts, but this doesn't work with Cloud RMM, AV, or other tooling which typically uses dynamic IP addresses for agent connectivity. Vote here if you'd like to see this capability added. Even better, it would be great to hear what specific tools you'd want to use it with; the list of DNS names that need allowing for typical cloud tooling is long, and we could potentially preconfigure them (just check a box) for common-needed tools.

Add an option to mass update agents from the Command Center.

Being able to edit the title for the test incident. Being able to edit the description / content. Not needing to select an endpoint to isolate. I would not like to need to create an exception for my device and target that just to test my alerting integration.

As browser-based applications become central to modern workflows, the security risks associated with Chromium-based browser extensions are increasing significantly. We request improved monitoring, control, and policy enforcement capabilities for browser extensions to mitigate risks related to malicious plugins and shadow IT. In today’s work environment, the reliance on browser applications continues to grow. At the same time, the number of malicious or compromised extensions in the Chrome Web Store and other Chromium-based marketplaces is rising rapidly. This creates several security challenges: Malicious extensions can exfiltrate sensitive data, inject scripts, or act as persistence mechanisms. Shadow IT risks increase as users install extensions tied to unapproved SaaS platforms, leading to uncontrolled data distribution. Lack of centralized visibility makes it difficult for IT and security teams to audit and manage extension usage across endpoints. Existing endpoint security solutions, including Huntress, have limited visibility and control over browser extensions, particularly: No centralized inventory of installed extensions Limited insight into extension permissions and behaviors No enforcement of allow/block policies at scale Lack of alerting on high-risk or newly installed extensions We propose adding dedicated browser extension security capabilities, including: Extension Inventory & Visibility Centralized dashboard of all installed Chromium extensions across endpoints - Metadata including publisher, permissions, install source, and user Risk Assessment & Detection Flag extensions with high-risk permissions (e.g., access to all sites, clipboard, downloads) Detection of known malicious or suspicious extensions Alerts on newly installed or recently updated extensions Policy-Based Control Ability to create allowlists and blocklists Enforcement of approved extensions only Optional auto-removal or disablement of unauthorized extensions Shadow IT Insights Identify extensions linked to unapproved SaaS or data-sharing services Reporting on potential data exposure vectors Integration & Response Tie extension activity into existing Huntress detection and response workflows Enable automated or guided remediation actions Conclusion: As browsers increasingly function as primary work platforms, extension security must be treated as a first-class concern. Enhanced control and visibility over Chromium extensions would provide significant security value to customers operating in today’s threat landscape.

You don't currently detect the very common browser hijacker and adware known as OneLauch. I contacted support and was told you don't plan on doing so as it doesn't currently do anything more severe like provide remote access or execute commands. However, it installs itself through deceptive means through scareware advertisements. It makes itself very hard to remove and recreates links to itself when deleted. It serves up further scareware ads that other firms have said are linked to account compromises. It spreads through shared environments such as RDS servers and causes serious functionality issues. It also is detected by competing EDR solutions such as Crowdstrike. I implore you to reconsider and start detecting it. Thank you!