Team: Huntress Managed Endpoint Detection and Response (EDR)
Product: Incident Reports
Environment: Windows, Huntress.io portal
Summary: If an incident report does not auto close, manual intervention may be required to close it out.
After an incident has been remediated, Huntress may still show the incident as "active." It may take up to 30 minutes to refresh the data and clear an incident within the Huntress Dashboard (this is due to how often the agent surveys the endpoint). If the active incident has not cleared within 30 minutes, follow the troubleshooting steps below.
In this article
- User Registry Values
- Services Scheduled Tasks
- Manually Removing Services from the Registry
- Manually Removing Scheduled Tasks
- Verifying that the Reported Footholds are No Longer Present
On occasion, you may notice an incident is in the "active" state when you thought it was remediated. These usually occur with two groups of persistence mechanisms: User Registry Values and Services/Scheduled Tasks.
User Registry Values
User registry values are the most common to be found in this "active" state after remediation. The reason for this is how we handle user roaming profiles. We have had issues in the past with footholds being remediated, and then a roaming profile would re-add the foothold. As such, we don’t update the user-specific data until we can verify the user’s profile is active (i.e., when the user logs in). Once Huntress verifies the user's profile is loaded and the foothold has been removed, it will be reflected in the Huntress Dashboard. This is why we add a note to remediation direction advising having the user logged in when removing user-specific registry values, otherwise remediation will fail.
Services/Scheduled Tasks
Remediated services and scheduled tasks appearing as "active" are much less common, but do occur occasionally. There are instances where Windows will mark a task or service for deletion and remove the task /service from the GUI, but has not removed the service from the system. These tasks/services that are marked for deletion will be removed when the system reboots. If you believe a service or scheduled task has been remediated, reboot the system, if you can, and it should be removed from Huntress the next time the endpoint checks-in.
Manually Removing Services from the Registry
The Huntress Agent enumerates the registry to identify the services on the endpoint. If a service is not present in the services manager, you can remove the service by editing the registry, removing the service key:
HKLM\SYSTEM\CurrentControlSet\Services\<ServiceName>
Manually Removing Scheduled Tasks
The Huntress Agent enumerates the scheduled tasks directory to identify the tasks. If a scheduled task is not present in the Task Scheduler, you can remove it by deleting the backing task file. Note: Some tasks may be in a sub-folder.
%windir%\system32\tasks\<TaskName> %windir%\system32\tasks\<TaskDir>\<TaskName>
Verifying that the Reported Footholds are No Longer Present.
If you remediated a endpoint and want to verify the reported footholds are no longer present,** click the View button under Actions
On the report page, click the Remaining Footholds tabs to view the footholds that were present at the time of the last survey:
Note: Because the agent scans at regular intervals and sends the data to the cloud for analysis, it may take a few minutes for the console to reflect that the footholds have been removed.
You can also view when the endpoint last checked in (LAST SEEN) and last surveyed (LAST SURVEY) by clicking the hostname to go to the agent view:
** Remember that Huntress specifically looks for malware that auto-starts at boot/user login. Depending on the malware, there may be other files that do not auto-start and would therefore not be seen by Huntress. That is why we typically recommend wiping the endpoint and restoring from backup when malware is found.