0

[Note: I have a Windows 10 system in an air-gapped network as the only computer on the network where it is the acting "server", as part of an RMF-compliant, DAAPM (link to PDF on dcsa.mil) defined "Multi User Standalone (MUSA) and Isolated LAN" configuration]

I have a nightly backup scheduled on Windows 10 to a Synology NAS with its own set of credentials unrelated to users on the Win 10 host. I am using the 'Backup and Restore (Windows 7) legacy' (sdclt.exe) backup feature of Windows 10. It was set up with the standard/only option for "Save on a network" (requiring a UNC path - which I pointed to a SMB share on the Synology), authenticating with a username/password created on the Synology:

enter image description here

Recently at the moment we see evidence in the logs of the scheduled backup job starting there have also been messages (seen in the Windows Event logs and Splunk) with Windows EventID 4624 with Logon Type: 8. According to Microsoft's information page for EventID 4624 (and Splunk) the title for this logon type is "NetworkCleartext" and the description reads:

A user logged on to this computer from the network. The user's password was passed to the authentication package in its unhashed form. The built-in authentication packages all hash credentials before sending them across the network. The credentials don't traverse the network in plaintext (also called cleartext).

There are a couple things puzzling me here. Firstly, when I first set all of this up I manually supplied credentials to the built-in Backup and Restore (Windows 7) menu (shown above) where it offered to remember my credentials for the NAS, which I accepted. That is the normal (if not only) way to use that backup feature. And the backups work fine each night.

But obviously such a scenario involves the Windows 10 machine using the credentials to authenticate to the NAS, and not the other way around. The description above makes it sound like there is something rather logging into the Windows 10 host. I don't know how to make sense of that. If instead it meant it caught the Windows 10 host sending local unhashed credentials across the network (outbound) to the NAS, then it would at least make sense as a statement.


Understanding the Log Message

I also admit that I don't understand how this statement, however, is not contradicting what it says in the rest of the description: "The built-in authentication packages all hash credentials before sending them across the network." Unless this is implying that somehow the this event captured an authentication attempt using some non-built-in authentication package, perhaps...

Any idea how to make sense of this and why Windows backup would trigger such a message?


Whatever the case, does anyone know whether Windows Backup sends credentials in the clear, and if so how to fix that? I can think of no reason why it would send credentials unhashed.

Given the incongruities I'm almost tempted to say it's something other than the Backup service, but this message occurs consistently (and only) when the Backup service kicks off late at night when no one could access this computer (air gapped + ensured with physical security).

4
  • Why would it send a hashed version of the password? It needs to log into a non-AD joined system, right? So, it's like logging into a website. It's a separate authentication system. It's not going to know what a hashed password means.
    – schroeder
    Apr 2 at 13:44
  • Well this is like saying you send your password over HTTP vs HTTPS. The issue is that it appears to not just be a plaintext password but is detectable on the network as such. You did give me an idea though. SMB has different levels of security and SMB3 encrypts the communication whereas other configurations of SMB do not necessarily do so. I found a Microsoft KB about it sending passwords plaintext on the network unencrypted in some cases: learn.microsoft.com/en-us/previous-versions/windows/it-pro/… Apr 2 at 14:26
  • That's not the correct analogy. Websites do send non-hashed passwords to the server. It is protected by TLS... So, yes, you want to use v3
    – schroeder
    Apr 2 at 17:04
  • Can you share your Splunk ingested logs or Event Logs by chance? Apr 2 at 19:50

0

You must log in to answer this question.

Browse other questions tagged .