Managed EDR

The current release notes at https://support.huntress.io/hc/en-us/articles/19223729361939-Huntress-Release-Notes-and-Agent-Version are woefully insufficient for tracking changes and bug fixes in the product. As an example, .14.132 for Windows included changes to the EDR Health API so it is available immediately upon install and no longer dependent on Rio, but this isn't mentioned anywhere in the release notes. So if I was trying to see when this update shipped, I would have no idea. Bug fixes and improvements should be listed in the release notes. They don't have to be extremely detailed, but it would be good to see these details and track specific improvements to the product.

Adding credential theft monitoring seems like an easy fit for Huntress and would kill off a competitor service too.

It would be extremely helpful if agents that remain unresponsive for a certain period could automatically transition into a non-billable state. We’ve noticed that in co-managed environments where customers handle their own device refresh cycles - devices are sometimes wiped and shelved when a user leaves, but the Huntress agent isn’t uninstalled. This results in continued billing for inactive devices. Ideally, if an agent remains unresponsive beyond a defined threshold, it would be marked as non-billable. Should the device come back online or re-register, billing and protection could automatically resume.

It would be invaluble for huntress to be able to mark a file as tamper-proof/offer tamper protection for various system files. We had a TA bypass DUO by pushing changes to the host file and flooding the API to localhost .

We would love to use Huntress as our MEDR but unable to utilize as long as the datacenters are located outside of Canada. Please setup a Canadian datacenter so we can enjoy the use of your product.

When I click dismiss once I would like to be asked for a reason and input the details so there is good understanding for you and us. eg. Advised the customer to remove the vpn or remove outlook from their device. Add Expected rule would be insecure, adding an Unauthorized rule will block the user

Ability to deploy canaries to network drives/custom locations

We need the ability to provide an SRA as required by HIPAA to our clients. I feel with Huntress's telemetry around SAT and endpoint security, this should be easy peasy. I'd prefer to have a client facing portal that allows the following without having to introduce another agent into their environment that could be susceptible to attack. The Healthit.gov SRA Tool is a desktop application that walks users through the security risk assessment process using a simple, wizard-based approach. Users are guided through multiple-choice questions, threat and vulnerability assessments, and asset and vendor management. References and additional guidance are given along the way. Reports are available to save and print after the assessment is completed.

Is someone able to update this KB ' https://support.huntress.io/hc/en-us/articles/47045055446931-Updating-outdated-EDR-RIO-Agents ' to include the troubleshooting steps of checking/deleting the reg key 'Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Huntress Labs\Huntress' and 'C:\Program Files\Huntress' directories that prevent the reinstallation of the updated EDR/Rio vs?

Due to age and trying to prevent this topic from becoming stale, im recreating this post: https://feedback.huntress.com/ransomware-canaries/p/ransomware-canaries-ability-to-put-deploy-canaries-to-network-drives-custom-loca This needs to be implemented as soon as possible. Not monitoring all system drives is a huge blind spot and I'm baffled this has not been implemented yet. One of our clients were recently hit with ransomware and the attackers went after the data drives first. It's common for a large majority of critical data to be stored on a separate data drive on a server and then shared out to the network. I don't think we need to specifically add "Network share ransomware canaries." I think we'd be fine just making sure each system has canaries distributed to all local system drives. For NAS, maybe we can assign one server/device on the network to watch the canaries. You guys are awesome, but I feel this is a critical oversight/blindspot.. especially considering this is exactly what we just saw in the wild. Would appreciate any and all attention you can give to this post so we can get this implement and on the roadmap.