0

When using XCOPY to copy files to a remote machine, are your credentials used to connect to the remote machine cached in the LSASS of that machine?

I am trying to avoid leaving any credentials vulnerable to Mimikatz on the target machine (Like here).

Edit: Wrong link! The link points to some trials they did with different logon methods (WMIC, PSExec, local admin vs domain admin, interactive, etc). Some methods cached credentials, some did not. They did not test XCOPY, so I wanted to know if anyone has tried it or knows for sure if XCOPY specifically caches credentials.

Improve this question
2
  • I've gotten a "yes", because you log in, and a "no", because XCOPY uses SMB. I might do a bit more research into how XCOPY works before I select their answer- they point to the fact that interactive logins are cached, but I don't know for certain that XCOPY is interactive.
    – girlsjustwanttohavepuns
    Oct 16, 2020 at 13:34
  • Yeah, at this point I think I'm just going to spin up some VMs and try it myself to know for sure, this isn't something I'm willing to take a risk on if there isn't a clear answer out there (From someone else trying and documenting it, or documented by Microsoft).
    – girlsjustwanttohavepuns
    Oct 16, 2020 at 13:46

1 Answer 1

Reset to default
2

No, file copy via SMB does not send any cacheable information in the first place – both authentication mechanisms used by SMB are built to only send temporary proofs and not your actual password. (SMB generally uses Kerberos in Active Directory environments, NTLM in other cases.)

  • Kerberos is a ticket-based, pre-shared secret protocol. With Kerberos, the server only receives a ticket that was issued for that specific server and cannot be used to acquire more tickets – neither your password nor your initial ticket (the TGT) are ever sent. (The ticket itself is verified offline, by decrypting it using the server's "machine account" password.)

  • NTLM is a challenge-response protocol, in which the server never receives the original "NT password hash" but only a version that's hashed again with connection-specific random data. In order to verify the response, the server needs to either already know the NT hash (in which case caching it is moot), or to forward it to a domain controller which does (in which case the server never learns the NT hash).

In both cases, the server only receives derived credentials which are useless to cache. (LSASS only caches initial credentials – its purpose is to derive those temporary credentials without actually revealing the initial ones. Mimikatz finds ways to extract them by force, but that's not normal operation.)

Also, the server doesn't need your password to check file permissions – it only needs to know your user SID & group memberships, which it'll obtain from the Kerberos ticket or by querying the DC.

RDP and WinRM are a different case; they're interactive access protocols, so they deliberately have a way to forward (delegate) your initial credentials to the remote machine, although it's optional and controllable via GPO. That's to allow the user to further access file shares and other things while connected to the server.

(Also, RDP carries a lot of legacy – although it can use Kerberos or NTLM nowadays via NLA, the older non-NLA mode simply involves sending your actual password to the server and indeed simulating a local interactive logon, with caching and all.)

Improve this answer
3
  • Tested it and it works! (At least for the server 2003 and the xp VM I had). I used "net use" to set up the network share, and then "xcopy" to copy a file over. I did mimikatz before and after, the only accounts it saw were the local ones on the XP user and the local domain account I had used to log into the XP machine. It did not cache the credentials from the domain admin when I xcopy'ed the files over.
    – girlsjustwanttohavepuns
    Oct 16, 2020 at 16:47
  • Oddly, it sounds like now you're talking about cache on the client system? Your original question was about cache on the file server.
    – u1686_grawity
    Oct 16, 2020 at 18:19
  • When I said "are your credentials used to connect to the remote machine cached in the LSASS of that machine?" I meant are the credentials cached in the lsass of the remote machine. Let's say I'm an admin: I want to administer a remote machine. I don't want anyone to be able to get my credentials from the LSASS on that remote machine. If someone accesses my local admin workstation, I'm hosed anyways. I'm more concerned with the remote (end-user) machine, and don't want my admin creds on there. (Hopefully) admins are less vulnerable to phishing, compromises, etc. than end-users
    – girlsjustwanttohavepuns
    Oct 16, 2020 at 19:54

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .