I’ve had an itch lately to do something with AES encryption in Powershell. I’ve tossed around the idea of building a password manager in Powershell, but I g...
Secure Credentials in Powershell
A coworker from a neighboring department had an interesting request one day. They wanted a scheduled task to run on a server. Through whatever mechanism the task would look in a series of folders for PDF files. If it found PDFs it would then FTP upload them and when complete move the files to an archive server for safe keeping. A good job for Powershell with a lot of fun components to it but I want to focus on one aspect: how to save the FTP credentials in the script securely. At some point everyone has probably come across this in a script somewhere:
This wouldn’t fly here. Typically I would handle this by having the script prompt the user for the credential at the execution of the script using Get-Credential:
The value for the provided password is then stored in that object as a SecureString. It can then be safely used throughout the script during execution and is cleared when the script ends. If you want to save a SecureString to a file for use later you need to convert the object from a SecureString using ConvertFrom-SecureString. I recommend reading Microsoft’s documentation about the ConvertFrom and ConvertTo SecureString cmdlets.
By default ConvertFrom-SecureString will use the Windows Data Protection API (DPAPI) to encrypt the standard string contents, which looks like this:
What’s convenient, and secure, about the use of DPAPI with ConvertFrom-SecureString is that the encryption key is derived from the current user on the current machine. This means that if I saved that string to a file only my user account on that computer would be able to convert it back in to a SecureString object and use it in a script. If your account got hacked then an attacker could reveal the plain text content of these saved SecureStrings.
My first thought was that there should be a dedicated service account for use with this Scheduled Task. It would have no logon rights and a very complex secure password. This account, on the intended server/computer, would then be the one to take the FTP credentials, convert them from a SecureString and save them to a file for later use. This way, any other administrator of that server would just see encrypted junk in the file and no amount of Powershell-fu could reveal it to them.
The Powershell to collect the credentials and save them to a file is pretty simple:
It will then pop up the standard Get-Credential GUI prompt. Fill out the fields and hit enter. Now we’ll use a cmdlet called “Export-Clixml” to save the entire PScredential object to a file for ease of importation later.
If you look at this XML file in a text editor you can see that this cmdlet saves what type of Powershell object it is and contains both object properties: UserName and Password. You can see the password is a DPAPI encrypted string.
Using the companion cmdlet Import-Clixml you can easily create a PScredential object with these saved credentials.
Now we have the mechanics we need to capture credentials, save them to a file and import those credentials to Powershell all securely. The trick is, we need the service account that will be running this script to store the credentials for import later. That’s tricky because I already said this service account won’t have logon rights to the server. We need a script just for saving these credentials it turns out. A server administrator should be able to launch this script and provide the FTP credentials to then be saved to an XML file and that process has to be done as our service account user. There may be another way to do this but I decided to use the “-Credential” parameter of the “Start-Job” cmdlet to execute a script block as the service account. Observe the behavior here:
First I run “whoami” so you can see the session is running under my account then I start a job that executes “whoami” as part of the script block and lastly I provide the “-Credential” parameter and specify a different user account (FTPuser). I receive the job, which would be the output of the executed “whoami” script block and as you can see it returned the username “FTPuser”.
The workflow would then be:
- Administrator launches script
- Administrator is prompted for service account credentials
- Administrator is prompted for FTP credentials they wish to save
- XML file it outputted with the saved credentials
Then in the primary script the FTP credentials can just be imported via Import-Clixml from that file. It’s pretty common for service account passwords to be set to never expire meaning that this whole exercise might seem pointless but nevertheless I wanted the end user to have the option to change the saved password if they wanted.
Here’s an example of what this script might look like:
The last three lines were added to support better execution of this script via a shortcut. The administrator then simply double-clicks a standard Windows shortcut and is greeted with a Powershell window, and then prompted for the credentials. The shortcut might look something like this:
The behavior at the end is simply that when the user hits “enter” (or really anything to satisfy the Read-Host cmdlet) the script moves to the next execution statement which is an “Exit” causing the window to close.
You may have also noticed the lines regarding validating the service account credentials are correct. This is just another sanity check to deal with the potential error of the administrator providing an incorrect password for the service account. Had we not validated it there then the Start-Job cmdlet would have likely generated an error when the credentials didn’t work. Since I had written this little validation block before I thought I would recycle it.
There you have it. A secure way to leverage service accounts, Windows Task Scheduler, Powershell and saved credentials.
“If all you have is a hammer, everything looks like a nail” - Abraham Maslow. I use a variation of this quote a lot, and I typically use it in jest, but it’s...
Introduction I’ve had some exposure to Microsoft Defender here and there, but I was in a class with Microsoft recently where they were going over some more f...
In my previous post I explained a bit about some of my justifications for logging in Powershell. My interest in logging has continued since then and I spent...
Everyone has a different use for Powershell. Some people use it for daily administrative tasks at work. Some people are hard at work developing Powershell m...
Early on when I first started using Powershell I was dealing with some firewall logs from a perimeter firewall. They were exported from a SIEM in CSV format...
One of the tools I feel like I’ve been using for years is Netstat. It exists in both Linux and Windows (with some differences) and has similar syntax. It’s ...
A coworker from a neighboring department had an interesting request one day. They wanted a scheduled task to run on a server. Through whatever mechanism the ...
When I first started getting in to Powershell I was working in an IT Security position and was sifting through a lot of “noise” in the SIEM alerts. The main...
“Hello World” and all that. What started as a small conversation turned in to an Idea that I couldn’t shake: I wanted a blog. But I didn’t want a WordPress...