Utilize PowerShell’s Secret Management module to access secrets with the Keeper Secrets Manager PowerShell Plugin
Retrieve secrets from the Keeper Vault to use in PowerShell
Integrate Keeper vault with PowerShell Secrets Manager
Update secret values in the Keeper Vault from PowerShell
Get files from the Keeper vault
For a complete list of Keeper Secrets Manager features see the Overview
This page documents the Secrets Manager PowerShell integration. In order to utilize this integration, you will need:
Secrets Manager requires PowerShell version 6 or greater. Microsoft distributes PowerShell version 6+ as a separate application from versions 5 and earlier.
See Microsoft’s Documentation for installation details
PowerShell Version 6.0 or later
Secrets Manager addon enabled for your Keeper account
Membership in a Role with the Secrets Manager enforcement policy enabled
The Keeper Secrets Manager PowerShell plugin utilizes Microsoft PowerShell’s Secret Management module to inject secrets from the Keeper Vault into your PowerShell scripts.
The Keeper Secrets Manager extension can be easily configured added as a secret vault into new or existing PowerShell Secret Management workflows.
1. Install PowerShell Secret Management Module
Keeper Secrets Manager uses the Microsoft.PowerShell.SecretManagement module to manage secrets in PowerShell.
Install using PowerShell:
See PowerShell Gallery for other installation options
2. Install Keeper Secrets Manager for PowerShell
Install the Keeper Secrets Manager PowerShell extension from the PowerShell Gallery.
To update SecretManagement, use the command: Update-Module -Name SecretManagement.Keeper
3. Install a PowerShell Secret Management Extension
If you already have a local secrets extension that you would like to use, you can skip this step
The Keeper Secrets Manager PowerShell plugin will need a secret management extension to store the plugin configuration locally to your machine.
Keeper recommends Microsoft.Powershell.SecretStore or SecretManagement.KeyChain
4. Register a Vault to use for Configuration Storage
If you already have a local secrets vault registered that you would like to use, you can skip this step
Register a secret vault for the previously installed secret management extension, so that the Keeper Secrets Manager plugin configuration can be stored.
The name of this vault will be used to register the Keeper extension. We used LocalStore in this example.
The Secret Management extension that you use for local storage may ask you to create a password for securely accessing the local vault.
Depending on your system settings, you may need to allow PowerShell to trust external modules. To do this, run the command:
5. Register the Keeper Vault
Register the Keeper Secrets Manager Vault using the local vault registered above to save your credentials, and a one time token to connect to Keeper.
Replace ‘XXX’ below with a one time token.
Register-KeeperVault -Name Keeper `-LocalVaultName LocalStore `6. Set Keeper Vault as Default Secret Storage (Optional)
Set the Keeper vault you just added as the default secret storage. This will tell the PowerShell SecretsManagement module to use your Keeper vault when getting and setting secrets.
This step is optional, but if you choose not to do it, you may receive secrets from your default vault if they have the same name, and you will need to add -Vault <keeper vault name> (e.g. -Vault keeper ) to Set-Secret commands
The Keeper Secrets Manager PowerShell Plugin is now ready to be used
Find the Keeper Secrets Manager PowerShell Plugin source code in the GitHub repository.
Find descriptions and examples of the most common usage of the Keeper Secrets Manager PowerShell plugin below.
Use the name set for your Keeper secrets vault, in the examples above we use Keeper.
Getting a Single Secret
Get information and values of a single secret
Wrap the record name in quotation marks when there is a space in it.
-AsPlainText Shows the actual values of the secrets. Otherwise PowerShell shows them as a SecureString
Get a Value From a Secret
Utilize Keeper Dot Notation to identify a field to access. Note that you do not need the ‘keeper://’ prefix.
Set a Value to a Secret
Update the value of a single secret field
If the Keeper vault is not set as the default secret vault add
-Vault <keeper vault name> to the command
Download a File
Use dot notation to specify a file attached to a secret in the Keeper vault. Then pass that file to the Set-Content command to download it.
The specified file will be downloaded to the path location given to Set-Content
Скрипты Powershell в большинстве случаев используются для автоматизации выполнения определенных задач, и зачастую для их выполнения необходимо указывать определенные учетные данные, часто с повышенными правами. Для интерактивных сценариев это не проблема, поскольку при необходимости они могут предложить администратору ввести пароль, а вот для автоматизированных сценариев, требующих учетных данных, это становится более сложной задачей.
Да, бесчисленные руководства по кибербезопасности не устают повторять, что скрипты, требующие повышенных разрешений, должны запускаться только в защищенных системах, из каталогов, в которые имеют доступы только администраторы. Однако, при пентестах сетей Windows постоянно приходится сталкиваться со скриптами, содержащими жестко зашитые ученые данные. Причем очень часто это данные от привилегированных учеток. Очень часто так получается, что со временем уровень защищенности скриптов ослабевает. Бесчисленные копии, бекапы, старые версии – доступ к ним уже не так сильно ограничивается, в результате чего посторонним проще получить к ним доступ.
Поэтому администраторам важно помнить, что жестко вводить пароль в скрипт – плохая идея. Хотя можно зашифровать пароль в файл, как показано на рисунке, такие файлы лишь ненамного лучше, чем зашифрованный пароль с открытым текстом.
Это связано с тем, что любой, у кого есть доступ к файлу, может использовать его для аутентификации, не зная фактического пароля. Кстати, по похожему принципу построена атака pass the hash, когда злоумышленник вместо пароля использует его хэш, и этого бывает достаточно для аутентификации в системе.
Поэтому нужен более безопасный способ предоставления учетных данных автоматизированным сценариям PowerShell. В доменной инфраструктуре Active Directory мы можем использовать Windows Credential Manager для получения разрешений.
Хотя Windows Credential Manager существует в автономных системах, иногда его поведение может быть довольно странным. Например, если автономная система настроена без пароля (вообще без аутентификации), кэшированные учетные данные в диспетчере учетных данных часто не предоставляют доступ к подключенным сетевым дискам, даже если сохраненные учетные данные верны.
Специальные учетки
Первым шагом в этом процессе усиления защиты скриптов создание учетной записи специально для данного сценария PowerShell, которой и будут назначены необходимые разрешения. Хотя в некоторых организациях создается специальная учетная запись, которую могут использовать все сценарии PowerShell, такая практика может ослабить безопасность. Причина этого заключается в том, что использование универсальной “учетной записи PowerShell” нарушает принцип минимальных привилегий.
Принцип минимальных привилегий предполагает, что учетная запись должна иметь только те разрешения, которые необходимы для выполнения поставленной задачи, – ни больше, ни меньше.
Поскольку сценарии PowerShell часто выполняют привилегированные операции, создание единой учетной записи для обслуживания всех сценариев, по сути, приведет к созданию глобальной учетной записи администратора. Если злоумышленник скомпрометирует сценарий и получит доступ к такой учетной записи, последствия могут быть разрушительными для организации.
Поэтому лучше создать отдельные учетные записи Active Directory для каждого сценария PowerShell. Вы всегда можете сохранить эти учетные записи в специальной папке Active Directory, чтобы не загромождать папку пользователей. Просто убедитесь, что имя и описание каждой учетной записи четко указывают на ее назначение.
Настройка Windows Credential Manager
На скриншоте PowerShell показано, что модуль Credential Manager успешно установлен
После установки модуля вы можете добавить сохраненные учетные данные в Windows Credential Manager. Это уже можно делать в окне PowerShell без привилегированных прав доступа, используя учетную запись обычного пользователя. В переменной $Password мы сохраняем пароль.
$Username = PowerShellDemo@poseylab.com
$Password = ConvertTo-SecureString “P@ssw0rd” -AsPlainText -Force
$Credential = New-Object -TypeName PSCredential -ArgumentList $UserName, $Password
New-StoredCredential -Target PowerShell -Credential $Credential -Type Generic -Persist LocalMachine Стоит отметить, что параметр Target, используемый в последней команде, по сути, присваивает понятное имя учетным данным (PowerShell). В принципе, вы можете назвать целевой объект как угодно. Однако важно запомнить присвоенное целевое имя, поскольку вам нужно будет ссылаться на него всякий раз, когда вы будете использовать сохраненные учетные данные.
На скриншоте ниже показано, что учетные данные были записаны в диспетчер учетных данных Windows.
Соответственно, для получения сохраненных учетных данных достаточно просто использовать эту команду:
Get-StoredCredential -Target <Target Name>
$Cred = Get-StoredCredential -Target PowerShell
New-ADUser -Credential $Cred -Name “TestUser” -SamAccountName “TestUser” -UserPrincipalName TestUser@poseylab.com -AccountPassword (ConvertTo-SecureString “P@ssw0rd” -AsPlainText -Force) -Enabled $TrueПосле создания новой учетной записи подтвердаем успешность операции с помощью этой команды:
Вот что мы получили в итоге:
Заключение
Используя Windows Credential Manager, мы можем использовать в скриптах Powershell привилегированные учетные записи Active Directory, не снижая при этом общий уровень защищенности инфраструктуры.
18 июня для системных администраторов пройдет открытый урок, посвященный GPO: «Групповые политики как средство автоматизации». Записаться бесплатно можно на странице курса «Администратор Windows».
