Machine Account Attempts to Reconnect to Previously Used UNC Paths Every 6-Hours

Question

We updated our IT department's Windows 10 devices to Windows 11. Since then, we are receiving alerts from our SIEM that accounts are failing network authentication to remote devices and are exceeding our set threshold. We determined that users are using the UNC path to \remotepc\c$\ to transfer files during troubleshooting. After these UNC connections are closed, Windows 11 attempts to reach out to the same PC's that were connected that day and previous days every 6-hours.

These login failures are increasing daily. Event ID 4625, 0xC000015B, "The user has not been granted the requested logon type at this machine." The connections are attempted through the computer account, 'computername$'. We do not grant that type of login in User Rights Assignment. What do do know is that svchost.exe (confirmed via process ID) started the connection, there are roughly 5-20 attempts per remote computer, attempts are Kerberos, simultaneous NTLM attempts are made but blocked by Credential Guard, and that there are 'privileged service was call[s]' by svchost.exe using SeLoadDriverPrivilege privileges using 0x3e4 subject_logon_id. I do not know this the last statement is related or not.

We restarted the machines, cleared the local Kerberos cache for the machine using 'klist -li 0x3e7,' reviewed the registry for the remote computers' SIDs and GUIDs (none in there), and review the wbem folders and files. We cannot find where these credentials are cached and cannot figure out why the computer is trying to re-authenticate. On one device, I set group policy Kerberos life to 5-hours and renewal to 1-day since it attempts to reconnect every 6-hours. It still made the connections.

I just noticed in the SIEM event logs that subject_login_id is 0x0 and not 0x3e5, 0x3e5, 0x3e7, or 0xsomethingelse. Any suggestions on how we are figure out where the cached credentials are? How can we clear them? How to stop and prevent this from continuing?

Answer 1

Hello there,

Access the file with a UNC path as if the remote computer were on the domain and ensure that the account under which the program runs is duplicated (including password) on the remote machine as a local user. Basically leverage the fact that Windows will automatically supply the current user's credentials when the user attempts to access a shared file.

The behavior you're describing, where a machine account attempts to reconnect to previously used UNC paths every 6 hours, is likely related to a Windows feature called Persistent UNC (Universal Naming Convention) Connections. When a user or application accesses a network resource using a UNC path (e.g., \server\share), Windows can establish a persistent connection to that resource to improve performance and avoid repeatedly authenticating. This connection is stored and can be reestablished when needed.

Hope this resolves your Query !!

--If the reply is helpful, please Upvote and Accept it as an answer–

Answer 2

Limitless,

Thank you again for a response. We finally were able to capture Process Monitor data and discovered that it was our EDR. We are inquiring with that service, but I am guessing that the EDR is attempting to scan the files opened by the user. The EDR seemingly maintains a list of every file a user accesses and then wants to test them every six hours.