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.

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.

Executive Summary Modern threat actors increasingly use a “test, modify, observe, and revert” methodology during post-compromise operations. Rather than deploying malware immediately, adversaries often make temporary configuration changes, disable protections, modify policies, test persistence mechanisms, and then revert changes to avoid detection. TDRL We recommend Huntress develop a detection capability that identifies endpoints exhibiting repeated configuration changes followed by rollbacks over short periods of time. This behavior can indicate adversary reconnaissance, security control testing, persistence validation, or exploitation of newly disclosed vulnerabilities. The rest of the recommendation was created using AI. The capability would provide Huntress analysts and customers with a new behavioral signal that is difficult for attackers to conceal and often precedes larger incidents. Background Recent nation-state and advanced threat actor campaigns have demonstrated an increasing focus on: Living-off-the-land techniques Temporary policy modifications Security control bypass testing Zero-day validation Persistence testing Credential access experimentation Endpoint hardening rollback Threat actors frequently perform the following sequence: Disable or weaken a security control Test access or payload execution Observe telemetry and response Restore the original configuration Repeat until successful Traditional security tools often focus only on the final state of a system. If a setting is reverted before a scan or review occurs, evidence of the activity may be missed. Behavioral change tracking can expose this activity. Threat Intelligence Relevance Chinese state-sponsored threat groups have repeatedly demonstrated patient, stealth-focused operations that emphasize long-term access and operational security. Observed techniques include: Testing endpoint controls before deployment Modifying logging configurations Temporary privilege escalation Security product tampering Scheduled task experimentation Registry modifications Policy manipulation Driver and kernel-level persistence testing In many incidents, configuration changes occur repeatedly before the final malicious action. The pattern itself becomes the detection opportunity. Proposed Detection Logic Configuration Drift Score Track important endpoint security settings: Microsoft Defender settings Tamper Protection Windows Firewall Attack Surface Reduction rules Local Administrator membership BitLocker status PowerShell logging Audit logging LSA Protection Credential Guard Application Control settings Generate events when: Setting changes Setting reverts Setting changes again within a defined time window. Example Detection Alert if: Same setting modified 3+ times within 24 hours Same setting modified 5+ times within 7 days Security-sensitive settings are disabled then re-enabled Multiple security controls experience synchronized changes Example: 08:00 - Defender Real-Time Protection disabled 08:15 - Defender Real-Time Protection enabled 11:22 - Defender Real-Time Protection disabled 11:25 - Defender Real-Time Protection enabled 14:02 - Defender Real-Time Protection disabled 14:04 - Defender Real-Time Protection enabled This activity should generate a high-confidence Huntress signal. Additional Telemetry Sources Potential integration points: Windows Event Logs Microsoft Defender APIs Sysmon Registry auditing Huntress agent telemetry MDM/Intune policy changes Local Group Policy changes Customer Benefits Earlier Threat Detection Detect attacker testing before ransomware deployment, data theft, or persistence establishment. Improved Threat Hunting Provides analysts with behavioral indicators that are not dependent on malware signatures. Zero-Day Exposure Discovery When attackers leverage newly disclosed vulnerabilities, they often test exploit reliability across multiple endpoints. Repeated configuration changes and reversions may provide early indicators of exploitation activity. Insider Threat Visibility Administrators or contractors making repeated unauthorized changes become easier to identify. Future Enhancement Develop a “Configuration Stability Score” for each endpoint. Factors could include: Number of security setting changes Frequency of rollbacks Policy drift rate Administrative activity patterns Historical baseline comparison Endpoints with unusually high volatility would be prioritized for analyst review. Strategic Value for Huntress Most EDR platforms focus on malicious execution. Very few focus on repeated security-control manipulation and rollback behavior as a first-class detection signal. This capability would create a unique Huntress behavioral detection that aligns with modern nation-state tradecraft, improves early warning visibility, and provides additional value beyond traditional endpoint protection.

Is it possible to see the username of who is logged to the host when looking at the Agent list as well seeing it in the details when you click on an Agent. It currently shows the Active Directory domain name so I assume it would be easy to pull the current logged in user.

Had a machine with a rio_msi.log that had grown to almost 200GB - a file size cap or a health check in the agent would be extremely helpful.

Microsoft Defender for Endpoint is implementing the ability to track AI agents and discover their use: https://learn.microsoft.com/en-us/defender-endpoint/local-agent-discovery-overview?trk=public_post_comment-text To ensure we can control Shadow-AI in organizations it'd be useful for Huntress to be able to block these agents via a policy configuration. Something where we can either have an approve or deny for agents that can be detected.

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 have our clients under our company in huntress, of which we handle most of them. a couple of single customers, however, manage this flow themselves. We don't want to see their cases in our dashboard. and we don't want to have to manually filter out when logging in.

If a client/customer wishes to keep a file on their machine that has the name "passwords" on it that's up to them. We should be able to mark somewhere that we've followed up about that file and would like to mute or white-list or exclude future alerts about it. I can't imagine having hundreds or thousands of machines what kind of noise this would be creating weekly.

In co managed MSP environments, organization level Admins or Security Engineers often manage remediation and recovery after an incident. When an endpoint is isolated during an incident and remediation is complete, it would be very useful for organization level Admins or Security Engineers to de isolate the host without escalating back to the MSP. This would reduce operational friction. It would speed up recovery. It would better reflect how MSPs and internal IT teams work in practice. The permission could be limited to post incident de isolation only and restricted to the organization level.