Detecting and Mitigating Valid Accounts Abuse (T1078)

The hardest intruder to spot is one who logs in like everyone else. MITRE ATT&CK describes this as Valid Accounts (T1078). It spans four tactics: stealth, persistence, privilege escalation and initial access. The platforms listed are wide: Containers, ESXi, IaaS, Identity Provider, Linux, macOS, Network Devices, Office Suite, SaaS and Windows.

The technique has four sub-techniques, for default, domain, local and cloud accounts. This guide covers the parent technique and what is shared.

How attackers use it

MITRE says adversaries may obtain and abuse credentials of existing accounts to gain initial access, persistence, privilege escalation or defense evasion. Compromised credentials may be used to bypass access controls and may give persistent access to remote systems and externally available services such as VPNs, Outlook Web Access, network devices and remote desktop. They may also grant higher privilege or access to restricted areas.

Two points from the page stand out.

First, adversaries may choose not to use malware or tools at all. Legitimate access with real credentials makes their presence harder to notice.

Second, inactive accounts are attractive. MITRE gives the example of accounts belonging to people who have left the organization. Because the original user is not there to notice odd activity, abuse can go unseen.

MITRE also warns that overlapping permissions across local, domain and cloud accounts let an adversary pivot from account to account and system to system until they reach a high level of access, such as domain or enterprise administrator.

How to detect it

MITRE's strategy for this technique (DET0560) has an analytic for each environment:

• Windows endpoints: anomalous logon patterns, abnormal logon types, and inconsistent geographic or time based activity.
• Linux: SSH logins, sudo and su abuse, and service account anomalies outside expected patterns.
• macOS: interactive and remote logins by service accounts or users at unusual times, with unexpected child process activity.
• Identity providers: geographic anomalies, impossible travel, risky sign-ins, and multiple MFA attempts or failures.
• Containers: service accounts or compromised kubeconfigs being used for cluster access from unexpected nodes or IP addresses.

The signal is almost always a mismatch between the account and its habits. A service account that logs in interactively, an admin who signs in from two continents within the hour, a dormant account that suddenly wakes up: each is a behavioral fact you can alert on if the logs exist.

For that reason, the first control is log coverage. Make sure authentication events from every system and from your identity provider land in one searchable place, and keep them long enough to look back.

How to reduce the risk

MITRE lists these mitigations. In order of impact for most teams:

1. Turn on multi-factor authentication for all account types, including default, local, domain and cloud accounts. MITRE says this significantly reduces the risk even if credentials are compromised.
2. Disable legacy authentication, which does not support MFA, and require modern authentication protocols (Active Directory Configuration).
3. Use conditional access policies to block logins from non-compliant devices or from outside defined organization IP ranges (Account Use Policies).
4. Change default usernames and passwords on applications and appliances right after installation and before production. Update and secure SSH keys periodically. Minimize password reuse between accounts, including reuse of personal credentials (Password Policies).
5. Audit domain and local accounts and their permission levels routinely. Check whether default accounts are enabled or unauthorized local accounts have appeared, and limit privileged account use across administrative tiers (Privileged Account Management).
6. Review accounts for activity and deactivate or remove the ones no longer needed (User Account Management).
7. Make sure applications do not store credentials insecurely, such as plaintext in code, credentials published in repositories, or credentials in public cloud storage (Application Developer Guidance).
8. Train users to accept only valid MFA push notifications and to report suspicious ones (User Training).

Item 7 is where valid accounts meet the software supply chain. A key committed to a repository is a valid account waiting to be found.

Check your own environment

• Export the list of accounts from your directory and identity provider. Which have not signed in for 90 days? Which belong to people who left?
• Which accounts, if stolen, would give broad access? Do they have MFA and conditional access?
• Are any legacy authentication protocols still enabled?
• Do any appliances still use factory credentials?
• Have you searched your code and CI configuration for committed credentials?

On Windows, a read-only look at recent successful logons from the Security log:

wevtutil qe Security /q:"*[System[(EventID=4624)]]" /c:20 /rd:true /f:text

On Linux with systemd, to review recent SSH sign-ins (the unit may be named ssh or sshd):

journalctl -u ssh --since "1 day ago" | grep -i accepted

Try it yourself

Credentials in code are one of the ways valid accounts are lost. This demo shows what a secrets scan finds and how findings are reviewed.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• MITRE ATT&CK, T1078 Valid Accounts: https://attack.mitre.org/techniques/T1078/