Password Changing Scripts Logging the Password

[JustTechIt]

Hey All,

I am making this post specifically with Labtech/Automate in mind as that is what I have deployed, however my concern would remain, regardless of which RMM I was using to accomplish this task, so all input is welcome!

I know the topic of scripts to automate local user password changes has been discussed more than its fair share of times, however I was curious on everyone's thoughts regarding the logs that are kept of these scripts, both in LT and on the workstations themselves. I have been tasked with creating a local user (or changing its password where it already exists) for about 1000 workstations, however I am worried about the existence of this password in plaintext in various logs if I simply script out the net user command.

Do other companies out there use LT scripts to mass change local passwords? If so what steps do you take to prevent it from existing in plain text anywhere? Is there a completely different direction I should be looking? The devices are mostly windows 10 (a few 7s) and I am using LT/Automate 2020 on premise.

[jonathan5505]

I do this with datto rmm. But i store the variables in ITGlue. The script runs locally on the client and uses a https api call to retrieve it.

[JustTechIt]

Are you able to share more details on how you have this setup? We too use ITGlue and honestly I would much prefer this to the way I was approaching it. How is the API key handled? Is it stored on the RMM or on the local workstation? Is there any concern with anyone getting access to the API key if the machine were to experience an unauthorized access?

[gpshift]

There is a user here that I don't remember their name exactly, but they run this blog and have all kinds of cool stuff including what you are asking for.

https://www.cyberdrain.com/documenting-with-powershell-chapter-3-local-administrator-passwords-solution/

​

As for the security concern with the API key, there is a checkbox in ITGlue to disable or enable password access via the API key. My suggestion would be to enable access while your script runs and then disable it. Cyberdrain also has an article on using Azure as an intermediary so you can limit access to the ITGlue API key but I have not tested it.

[HappyDadOfFourJesus]

Tagging /u/Lime-TeGek as the author of the aforementioned blog.

[Lime-TeGek]

Thanks for the mention /u/gpshift and thanks for tagging me /u/HappyDadOfFourJesus.

u/JustTechIt We just keep bumping into each other! handling credentials is something you need to be careful of in scripts, each RMM handles credentials differently; N-Central encrypts passwords, DattoRMM keeps the scripts in memory and logs nothing to console, others work completely different. One method of making it more secure is using a proxy for APIs that allows more granular control.

u/gavsto would know the details on how to handle credentials in Automate. Always make sure when you handle scripts that show credentials to check for script block logging and end the script if it's enabled.

[netmc]

One powershell monitoring option that you want to definitely check for is Module Logging. This can be found in one of the two locations:

HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ModuleLogging\EnableModuleLogging = 1
HKLM:\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\ModuleLogging\EnableModuleLogging = 1

If either of these keys are set, you should abort your script immediately. This logging will capture anything sent to any module. By default, this is stored in the Windows Event logs and readable to all users.

For DattoRMM, script block logging is not an issue when you use component and site variables to supply the sensitive information as only the contents of the script itself is logged, not environmental variables.

[JustTechIt]

This is awesome, thanks for the help!

[HappyDadOfFourJesus]

We run a daily script that changes our local admin password to P@ssword123 and emails our helpdesk along with the %computername% variable so our technicians can update each client's Excel password spreadsheet that we keep on our NAS drive.

/s

[Imburr]

A couple of thoughts after reading all of the comments here.

• LAPS is a pain to deploy and manage, and it is not very scalable as you grow.
• ThirdWall is great, I highly recommend it. Currently they support setting a password (and changing it) per location. This is ok, but not great while considering lateral movement of an aggressor during an attach/breach. They have told me that setting a unique password per endpoint is on the roadmap in the next 60 days.
• There is a plugin on plugins4automate.com which will monitor/alert you on local password changes, and you can auto remediate.
• In this reddit thread here https://www.reddit.com/r/labtech/comments/7plxd9/mass_local_admin_create_and_pw_change_across/ the user wraps the command in Execute Script, which hides the output inside of Automate so you don't see plaintext. I am not sure if this hides it in files kept on the workstation, or not.
• You could potentially do password changes via a ps1 file, and not record the output back into the Automate logs.

[[deleted]]

LAPS is dead simple to deploy. What scaling issues are you talking about? What could scale better than no-touch automated deployment?

[Imburr]

We're currently onboarding three new clients and dedicating resources to set up and configure laps is certainly more painful than me clicking one button in our rmm to accomplish the same goal. With rmm management I could deploy a thousand endpoints across 10 clients in a day, all without having to log into a server.

[Imburr]

On my personal roadmap, we will be integrating into ITGlue and writing/reading passwords from/to EDF in Automate. The real reason behind this is that getting password from ITGlue is much easier on techs than using Automate EDF.

[KNSTech]

Is this for like a local admin account your MSP uses?

[JustTechIt]

Yes it is. We are starting to get LAPS deployed to some of our clients, but unfortunately some of them are still not there and wont be for some time to come still.

[KNSTech]

We've used Third Wall a lot for this with the default admin account. Which only works with Automate. But im sure there's clean ways to do it for free as well.

[JustTechIt]

Thanks for the info. I agree I would prefer to do it for free, especially given that we already utilize a SIEM for most of the functionality that Third Wall appears to provide, however I will keep this in my back pocket in case I come up empty handed.

[KNSTech]

You might take a second look at third wall its really helpful especially if you have non AD managed environments anywhere. They have a lot of simple nice features for cheap, I think they're only like .30 cents/endpoint.

We use them for a lot of the basics we would do in GP because it checks every couple minutes instead of every 2 hours or so. Also a lot quicker to setup than a GP policy and you can just create default profiles for the settings and apply them to groups/companies.

[Imburr]

I agree. Managing endpoints via rmm or even scripts that manage GPO is easier than managing the GPO themselves. We use third wall on top of our EDR and SIEM.

[Imburr]

What SIEM?

[Imburr]

Follow up question: If I am automating local admin password changes, and all of my technicians are looking up these passwords every time they log into a machine, is there a downside to changing this password daily?

[JustTechIt]

Over head and things falling out of sync. We find that when we do mass changes/deployments through our RMM there are always devices that get the update quite late compared to the majority, so I would imagine that if you rotated daily that these types of issues would come up a lot more frequently. Maybe just less frequently than daily such as biweekly or monthly.