Valid Accounts: Local Accounts

APT29 targets dormant or inactive user accounts, accounts belonging to individuals no longer at the organization but whose accounts remain on the system, for access and persistence.^[1]

APT32 has used legitimate local admin account credentials.^[2]

Cobalt Strike can use known credentials to run commands and spawn processes as a local user account.^[3][4]

Emotet can brute force a local admin password, then use it to facilitate lateral movement.^[5]

FIN10 has moved laterally using the Local Administrator account.^[6]

FIN7 has used compromised credentials for access as SYSTEM on Exchange servers.^[7]

HAFNIUM has used the NT AUTHORITY\SYSTEM account to create files on Exchange servers.^[8]

Kimsuky has used a tool called GREASE to add a Windows admin account in order to allow them continued access via RDP.^[9]

Leviathan used captured local account information, such as service accounts, for actions during Leviathan Australian Intrusions.^[10]

LockBit 3.0 can use a compromised local account for lateral movement.^[11]

NotPetya can use valid credentials with PsExec or wmic to spread itself to remote systems.^[12][13]

During Operation Wocao, threat actors used local account credentials found during the intrusion for lateral movement and privilege escalation.^[14]

Play has used valid local accounts to gain initial access.^[15]

PROMETHIUM has created admin accounts on a compromised host.^[16]

Sea Turtle compromised cPanel accounts in victim environments.^[17]

During the SolarWinds Compromise, APT29 used compromised local accounts to access victims' networks.^[18]

Tropic Trooper has used known administrator account credentials to execute the backdoor directly.^[19]

Turla has abused local accounts that have the same password across the victim’s network.^[20]

Umbreon creates valid local users to provide access to the system.^[21]

Velvet Ant accessed vulnerable Cisco switch devices using accounts with administrator privileges.^[22]

Enable multi-factor authentication (MFA) for local accounts to add an extra layer of protection against credential theft and misuse. MFA can be implemented using methods like mobile-based authenticators or hardware tokens, even in environments that do not rely on domain controllers or cloud services. This additional security measure can help reduce the risk of adversaries gaining unauthorized access to local systems and resources.

Ensure that local administrator accounts have complex, unique passwords across all systems on the network.

Audit local accounts permission levels routinely to look for situations that could allow an adversary to gain wide access by obtaining credentials of a privileged account. ^{[23] [24]} Limit the usage of local administrator accounts to be used for day-to-day operations that may expose them to potential adversaries.

For example, audit the use of service accounts in Kubernetes, and avoid automatically granting them access to the Kubernetes API if this is not required.^[25] Implementing LAPS may also help prevent reuse of local administrator credentials across a domain.^[26]

Enforce user account management practices for local accounts to limit access and remove inactive or unused accounts. By doing so, you reduce the attack surface available to adversaries and prevent unauthorized access to local systems.