Product: Huntress Managed Endpoint Detection and Response (EDR), Huntress Managed Identity Threat Detection and Response (ITDR)
Environment: Client Endpoints
Summary: Use this article when Huntress remediation or manual cleanup cannot remove a malicious ScreenConnect Client directory and the partner sees access denied, file in use, or similar deletion failures. In the ScreenConnect-specific cases Huntress has documented, the most important cause is an LSA Authentication Packages registry entry that causes Windows to load ScreenConnect.WindowsAuthenticationPackage.dll at boot and keep it locked in memory.
This issue can also present as a more general permissions problem. Partner feedback shows two recurring causes: restrictive folder permissions and the LSA auth-package persistence path described above.
Symptoms
Huntress remediation fails to remove one or more
ScreenConnect Clientdirectories.Manual deletion may also fail, even as a local administrator, with errors such as access denied or file may be in use.
The affected machine may have one or more appended DLL paths in
Authentication Packagesunder the LSA registry keys below.
Why this happens
During these phishing-driven ScreenConnect attacks, the malicious installation appends a ScreenConnect.WindowsAuthenticationPackage.dll path to the Windows Authentication Packages value. Windows then loads that DLL into LSASS at startup, which keeps an open protected handle on the file and prevents both the Huntress agent and local administrators from deleting the DLL or its parent directory while the machine is running.
Validation
Before making changes, confirm the following:
The failed remediation references a
ScreenConnect Clientdirectory and the error is consistent with access denied or file in use behavior.You have the full affected directory path or paths from the incident or failed remediation output.
If the organization also uses ScreenConnect legitimately, confirm the client ID being targeted is not a known-good instance before removing anything.
Check both of these registry locations for appended values beyond
msv1_0inAuthentication Packages:HKLM\SYSTEM\CurrentControlSet\Control\LsaHKLM\SYSTEM\ControlSet001\Control\Lsa
Resolution
Follow these steps in order.
Step 1: Confirm whether this is just a file lock or the LSA auth-package case
If the partner is only reporting a generic file-in-use error and you have not yet confirmed the LSA persistence mechanism, you can first check whether a normal process handle is keeping the folder open. If no normal process lock explains the failure, proceed to the registry validation below.
For ScreenConnect incidents matching this article, treat the LSA Authentication Packages check as the primary validation step because that is the documented reason the directory remains undeletable in these cases.
Before modifying permissions, ensure the file isn't actively being held by a running process.
Open Resource Monitor (
resmon.exe).Navigate to the CPU tab.
Expand the Associated Handles section.
Search for the name of the un-deletable file or directory.
If a process is holding it open, determine if it is safe to terminate, right-click the process, and select End Process.
Step 2: Modify the DACL (Permissions) via GUI
If the file is not locked but still throws an access denied error:
Right-click the target folder and select Properties.
Go to the Security tab and click Advanced.
Change the Owner: Change the owner to
Administratorsor your current admin user account. Check the box for "Replace owner on subcontainers and objects". Click Apply.Edit Permissions (DACL): Look for any explicit Deny entries affecting your account or the Administrators group and remove them. Ensure your account has Full Control.
Check the box for "Replace all child object permission entries with inheritable permission entries from this object".
Click Apply and then OK. Attempt deletion again.
Step 3: Restore permissions on the affected directory
From an elevated Command Prompt, run:
takeown /f "<ScreenConnect Client directory path>" /r /d y
icacls "<ScreenConnect Client directory path>" /grant Administrators:F /t /c /qReplace <ScreenConnect Client directory path> with the actual directory from the failed remediation or incident notes.
Step 4: Remove the malicious appended Authentication Packages entry
Open regedit as an administrator and review:
HKLM\SYSTEM\CurrentControlSet\Control\LsaHKLM\SYSTEM\ControlSet001\Control\Lsa
In each location:
Find the
Authentication Packagesvalue.A normal value contains only
msv1_0.Remove only the malicious appended DLL path or paths referencing
ScreenConnect.WindowsAuthenticationPackage.dll.Do not delete the entire registry key or remove legitimate ScreenConnect entries the partner actually uses.
Step 5: Perform a full shutdown and power-on
Do a full shutdown and power-on, not just a standard restart. Huntress documents that a normal restart may not fully release the LSASS lock in all cases.
If you have fast startup enabled, it can prevent the file from being unlocked. It's recommended to disable fast startup or hold the Shift key when powering down to temporarily bypass it.
Step 6: Delete the remaining directory and DLL
After the system powers back on, delete the affected ScreenConnect Client directory and the associated DLL using an administrator account.
If deletion still fails
Re-check that the malicious appended registry path was removed from both LSA locations.
Re-confirm a full shutdown, and a power-on occurred rather than a restart on the endpoint.
If the file is still locked after registry cleanup and full power cycling, the recommended next step is to reimage the machine to ensure it is fully clean.
Important notes
Only remove the malicious appended path from
Authentication Packages; do not delete the entire key.Be careful not to remove legitimate ScreenConnect entries if the environment also uses ScreenConnect normally.
We have completed work on the next version of EDR/RIO 0.14.180 to address this problem, and we will begin rolling it out as soon as the rollout to 0.14.176 completes.