Valid Accounts, MITRE technique T1078, means an adversary logs in with real credentials instead of exploiting software. It is hard to detect because the activity looks like a legitimate user. The defences are strong MFA, account hygiene, conditional access and detection of unusual sign-in patterns.
Why it matters across four tactics
MITRE lists T1078 under Initial Access, Persistence, Privilege Escalation and Stealth. One technique serves four goals. A valid login gets an attacker in, keeps them in, can lift them to higher permissions and hides them among normal traffic.
CISA's Volt Typhoon advisory says that actor "primarily relies on valid credentials for persistence". It describes repeated extraction of the NTDS.dit database from domain controllers to keep credentials current, and footholds lasting at least five years.
Which accounts get abused
MITRE's page names several kinds:
- Default accounts with vendor credentials never changed.
- Domain accounts.
- Local accounts on a single system.
- Cloud accounts for services and platforms.
It also points to accounts of former employees. Misuse of those can go unnoticed because the owner is not around to see anything odd. Overlapping permissions across local, domain and cloud accounts can let an attacker move to domain or enterprise admin.
Mitigations MITRE lists
- Multi-factor authentication on all account types, which limits the value of a stolen password.
- Account use policies, for example conditional access that blocks sign-ins from non-compliant devices or unexpected locations.
- Disable legacy authentication that cannot support MFA.
- Password policies: change default credentials before deployment and limit reuse.
- Privileged account management: audit privileged and default accounts regularly.
- User account management: deactivate accounts no longer needed.
- Developer guidance: do not store credentials insecurely in code, repositories or cloud storage.
- User training: teach people to report unexpected MFA push prompts.
Detection ideas from the same page
MITRE's detection notes point to patterns, not signatures: unusual logon types, inconsistent geography or time, service accounts logging in interactively, impossible travel and repeated MFA failures in identity provider logs, and kubeconfigs used from unexpected nodes or addresses.
A one-week starter plan
- Export all accounts with admin rights and confirm each has a current owner.
- Disable accounts for people who have left.
- Find service accounts that allow interactive logon and fix or document them.
- Turn on sign-in logging in your identity provider and keep it centrally.
- Search repositories for committed credentials, then rotate any you find.
Step 5 can be partly automated. Safeguard's dependency and code scanning can help with the repository side, and the free scan at https://gold.safeguard.sh/scan is a no-cost way to try it.
Quick check
Is MFA enough to stop valid account abuse?
It helps a great deal but is not the only control. MITRE also lists conditional access, account clean-up and detection of odd sign-in patterns.
Why are former employee accounts a risk?
Nobody is left to notice unusual use, so misuse can go unseen for a long time.
Sources
Last reviewed: 19 October 2026.
