2

I am looking for a way to capture the network credentials of the current session into a variable that I can pass later...

The point is to execute commands on a foreign domain that I have account access/privileges to, but there is not a trust between the source and target domains.

First, we run inside a powershell that was spawned using the runas command (runas /netonly /user:domian\account powershell

From here I can do pretty much everything I want to except create an event in the task scheduler without hardcoding the username/password into the command line

invoke-command -computer $destination -scriptblock {schtasks -ru domain\account -rp password}

What I am looking to do is something like

$username = Get Current Session Network Username ($(whoami) brings up the actual local longon account,not the runas account that spawned the powershell window)

$password = Get the Password that was entered when the RunAs command was executed

x0n
  • 51,312
  • 7
  • 89
  • 111
Chris White
  • 71
  • 3
  • 7
  • 3
    This sounds like another in the list of [when people ask for security holes as features](http://blogs.msdn.com/b/oldnewthing/archive/2005/05/04/414602.aspx). – Bill_Stewart Mar 28 '13 at 21:35

1 Answers1

4

Once a security token has been created from credentials entered and validated against active directory, the password is no longer kept around. It is not available for retrieval and reuse elsewhere. Only the token remains. This is by design.

UPDATE:

I dug a little further to bolster my case, and it's not quite as above but the end result is the same. The password used with runas.exe does not appear to be available. The network credentials are not validated against AD, which makes sense in retrospect since you often use /netonly for working with a remote, untrusted domain: By definition, you cannot validate the remote credentials from the local system. From MSDN:

Here's information for the flag LOGON_NETCREDENTIALS_ONLY, used with CreateProcessWithLogonW.

Log on, but use the specified credentials on the network only. The new process uses the same token as the caller, but the system creates a new logon session within LSA, and the process uses the specified credentials as the default credentials.

This value can be used to create a process that uses a different set of credentials locally than it does remotely. This is useful in inter-domain scenarios where there is no trust relationship.

The system does not validate the specified credentials. Therefore, the process can start, but it may not have access to network resources.

Ok, so since it can't validate the credentials and get a token, then it must store the password somewhere in memory since it must pass them over the wire later for SSPI etc. So, can we get at them from the process launched from runas.exe ? Let's see:

PS> runas /netonly /user:foo\bar powershell.exe
Enter the password for foo\bar: ******

I literally used foo\bar for domain and user above. It is not validated, as mentioned already. I entered 12345 for a password. The above line will launch a new instance of powershell. So, from that new instance, let's look at the default network credentials:

PS> [System.Net.CredentialCache]::DefaultNetworkCredentials

UserName                                           Domain
--------                                           ------

Oh well, out of luck: Nothing there. My guess is the credentials are guarded in some encrypted part of memory in the kernel, probably the LSA (local security authority) out of reach from prying processes.

x0n
  • 51,312
  • 7
  • 89
  • 111
  • If you capture the credentials in a variable, the password *is* still around. Try this: `$cred = get-credential;$cred.GetNetworkCredential().password;` [See also](http://blogs.technet.com/b/heyscriptingguy/archive/2013/03/26/decrypt-powershell-secure-string-password.aspx) – alroc Mar 28 '13 at 18:37
  • xOn - then where do the cmdlets get the info? By doing the powershell runas, cmndlets that would normally require me to enter a new set of credentials use the credentials that are wrapped into the powershell session. – Chris White Mar 28 '13 at 19:20
  • The cmdlets *don't* get the info. This happens higher up the stack; using /netonly means that Windows will use the alternate token for network access automatically, but it will use the process-level token for local work. It's all about tokens - the password is long gone. – x0n Mar 28 '13 at 19:35
  • 2
    @alroc yes, of course you can get the password like that. But this is not what he's asking. He's asking to retrieve the password that was used with "runas." – x0n Mar 28 '13 at 19:38