|
Account Access Removal
Adversaries may interrupt availability of system and network resources by inhibiting access to accounts utilized by legitimate users. Accounts may be deleted, locked, or manipulated (ex: changed credentials) to remove access to accounts. Adversaries may also subsequently log off and/or perform a
System Shutdown/Reboot [MITRE]
to set malicious changes into place.
In Windows,
Net [MITRE]
utility, Set-LocalUser and Set-ADAccountPassword
PowerShell [MITRE]
cmdlets may be used by adversaries to modify user accounts. In Linux, the passwd utility may be used to change passwords. Accounts could also be disabled by Group Policy.
Adversaries who use ransomware or similar attacks may first perform this and other Impact behaviors, such as
Data Destruction [MITRE]
and
Defacement [MITRE]
, in order to impede incident response/recovery before completing the
Data Encrypted for Impact [MITRE]
objective.
AWS Specific Content
A prerequisite for this technique is that a threat actor has already gained control of an AWS identity with the permissions to delete IAM users.
In AWS, an AWS account is a container where you can create and manage your AWS resources. An account is also a unique identity, typically associated with a user, that grants access to a specific system or resource, for example, an IAM user. Using this technique, a threat actor can delete legitimate and authorized IAM users within an AWS account, such as IAM users with administrative privileges that would otherwise be used by the AWS account holder to contain the threat actor and recover from unauthorized actions taken. Note that while it is possible for the threat actor to delete legitimate IAM users, it is not possible to delete the account root user.
This technique uses the same Event names as the Indicator Removal > Delete IAM Entities technique (
iam:DeleteUser), however, the difference is that in the Indicator Removal > Delete IAM Entities technique, a threat actor first creates the users and roles, performs unauthorized actions with the users and roles, and then deletes the previously created users and roles to remove their existence to evade defensive actions. With this technique, the roles and users that are deleted are legitimate users created by the AWS account holder.Detection
Use process monitoring to monitor the execution and command line parameters of binaries involved in deleting accounts or changing passwords, such as use of [Net](https://attack.mitre.org/software/S0039). Windows event logs may also designate activity associated with an adversary's attempt to remove access to an account: * Event ID 4723 - An attempt was made to change an account's password * Event ID 4724 - An attempt was made to reset an account's password * Event ID 4726 - A user account was deleted * Event ID 4740 - A user account was locked out Alerting on [Net](https://attack.mitre.org/software/S0039) and these Event IDs may generate a high degree of false positives, so compare against baseline knowledge for how systems are typically used and correlate modification events with other indications of malicious activity where possible.AWS Specific Content
When this technique is used by the threat actor, actions taken by the threat actor using the credentials obtained will be logged in CloudTrail. You can use the Event History page in the AWS CloudTrail console to view the last 90 days of management events in an AWS Region for the events listed in the AWS CloudTrail Event Name(s) section, such as
iam:DeleteUser.A separate CloudTrail trail will give you an ongoing record of events in your AWS account past 90 days and can be configured to log events in multiple regions. You can also review events using the console as well as the AWS CLI.
It is also possible to create a CloudWatch metric filter to watch for when specific AWS API calls are used and perform notification actions if logged, and additionally configure CloudWatch to automatically perform an action in response to an alarm.
Mitigation
AWS Specific Content
You can make sure that principals are scoped with the least-privileged permissions necessary to perform duties, limiting the ability to perform unauthorized actions in an AWS account when not required. One possible method of applying the principle of least-privileged permissions is to use Service Control Policies to restrict the maximum available permissions for the IAM users and IAM roles within your AWS Organizations accounts (note - you should test SCPs in a development environment before deploying them in production).
You can also use IAM Access Analyzer to regularly review and verify access and manage permissions across your AWS environment, which will highlight AWS identities with excessive permissions and the actions performed by those identities.