Valid Accounts

Adversaries may obtain and abuse credentials of existing accounts as a means of gaining Initial Access, Persistence, Privilege Escalation, or Defense Evasion.

Compromised credentials may be used to bypass access controls placed on various resources on systems within the network and may even be used for persistent access to remote systems and externally available services, such as SSH, VPN, Outlook Web Access and Remote Desktop. Compromised credentials may also grant an adversary increased privilege to specific systems or access to restricted areas of the network. Adversaries may choose not to use malware or tools in conjunction with the legitimate access those credentials provide to make it harder to detect their presence.

The overlap of permissions for local, domain, and cloud accounts across a network of systems is of concern because the adversary may be able to pivot across accounts and systems to reach a high level of access (i.e., domain or enterprise administrator) to bypass access controls set within the enterprise. [1][2]

Procedure Examples

Name Description
APT18

APT18 actors leverage legitimate credentials to log into external remote services.[3]

APT20

APT20 uses valid credentials and key to login to remote services, such as SSH, and laterally move among its victims

APT39

APT39 has used stolen credentials to compromise Outlook Web Access (OWA). [4]

APT40

APT40 uses valid, compromised keys and credentials for defense evasion and lateral movement.

APT41

APT41 used compromised credentials to log on to other systems.[5]

Linux Rabbit

Linux Rabbit acquires valid SSH accounts through brute force. [6]

Sandworm Team

Sandworm Team have used previously acquired legitimate credentials prior to attacks.[7]

UNC1945

The group used credentials and private keys to sign into valid accounts

UNC2452

UNC2452 used different compromised machine identities and credentials for remote access and lateral movement.[8]

Mitigations

Mitigation Description
Application Developer Guidance

Ensure that applications do not store sensitive data or credentials insecurely. (e.g. plaintext credentials in code, published credentials in repositories, or credentials in public cloud storage).

Detection

Configure robust, consistent account activity audit policies across the enterprise and with externally accessible services. [9] Look for suspicious account behavior across systems that share accounts, either user, admin, or service accounts. Examples: one account logged into multiple systems simultaneously; multiple accounts logged into the same machine simultaneously; accounts logged in at odd times or outside of business hours. Activity may be from interactive login sessions or process ownership from accounts being used to execute binaries on a remote system as a particular account. Correlate other security systems with login information (e.g., a user has an active login session but has not entered the building or does not have VPN access).

Perform regular audits of domain and local system accounts to detect accounts that may have been created by an adversary for persistence. Checks on these accounts could also include whether default accounts such as Guest have been activated. These audits should also include checks on any appliances and applications for default credentials or SSH keys, and if any are discovered, they should be updated immediately.

References

Attachments

ID
VT0005
MITRE ID
Sub-techniques
Tactics
Defense Evasion
Persistence
Privilege Escalation
Initial Access
Platforms
AWS
Azure
Azure AD
GCP
Linux
Office 365
SaaS
Windows
macOS
Permissions Required
Administrator
User
Effective Permissions
Administrator
User
Data Sources
AWS CloudTrail logs
Authentication logs
Process monitoring
Stackdriver logs
Defense Bypassed
Anti-virus, Application control, Firewall, Host intrusion prevention systems, Network intrusion detection system, System access controls
CAPEC ID
Version
2.1

Created: 02 December 2020

Last Modified: 27 December 2020