T1078
Valid Accounts
Containers · ESXi · IaaS · Identity Provider · Linux · macOS · Network Devices · Office Suite · SaaS · Windows33 pieces on this siteT1078 on attack.mitre.org
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 VPNs, Outlook Web Access, network devices, and remote desktop.
If this is happening now
Checklists and playbooks to open while the alert is still live.
Insider threat response plan: evidence, proportion and the employee who may have done nothing
The response where the usual instincts are wrong. Speed matters less than lawfulness, the suspect is a colleague with rights, and half of these turn out to be misunderstanding. A plan for investigating quietly, preserving what you would need, and being able to stand behind how you did it.
Ransomware response plan: from the first renamed file to the review
The whole response rather than the first hour of it: who decides what, how to contain without destroying the evidence you will need, what has to be true before you restore, and the notifications whose clocks started before you noticed.
First 15 minutes: a successful sign-in from an IP address nobody recognises
A user's account signed in successfully from an address, country or device that does not fit. How to tell a traveller from a stolen session in five minutes, and what to cut off if it is the second.
How to know they are actually gone
Remediation is finished and somebody is about to say so in writing.
A leaver's account is still being used
Sign-ins, mailbox activity or VPN sessions on the account of somebody who has left, or of a contractor whose engagement has ended.
Cloud account takeover response plan: sessions, methods, devices and grants, then what they read
A successful sign-in the user did not make, in Microsoft Entra ID and Microsoft 365. A password reset alone evicts almost nobody. The plan works through the order that does, how to tell a guessed password from a stolen session, and how to answer what they read.
Business email compromise response plan: the money first, then the mailbox
Two responses that have to run at once. One is a race with a bank transfer measured in hours. The other is evicting an operator who is still reading the mailbox, and who survives a password reset unless you remove what they left behind.
First 15 minutes: a user is getting MFA prompts they did not start
Repeated MFA prompts mean somebody already has the password and is waiting for a tired tap. What to tell the user, what to check, and what to change so the next attempt fails.
First 15 minutes: a user typed their password into a phishing page
Assume the session was taken, not just the password. Revoke first, find everybody else the email reached, and check what the attacker did with the time they had.
First 15 minutes: an account was added to Domain Admins
A tier-zero group changed and nobody has a ticket for it. Whoever made the change is at least as compromised as the account they added. How to confirm, contain and scope without handing the operator another credential.
Cloud account compromise
Impossible travel, an unrecognised inbox rule, or a reported invoice-fraud attempt.
Domain-level access you cannot account for
An unexplained Domain Admin, directory replication by something that is not a domain controller, or a ticket that does not match any authentication.
A credential is public
A secret scanner alert, a report from a researcher, or finding a key in a public repository.
Unexplained compute in a cloud account
A billing alert, instances nobody created, or a provider notification about mining.
Somebody talked the help desk into a reset
The service desk reset a password or an MFA method for a caller, and the real user says it was not them. Or a new MFA method appeared on an account straight after a help desk ticket.
Detect it
Hunts and rules you can run, each stating what it needs and what else it returns.
Cloud identity and token theft detection pack for Entra ID and Okta
Four Sigma rules for the cloud identity attacks that actually land: illicit consent grants, authentication methods added after a risky sign-in, help-desk MFA resets, and session tokens replayed from a second address.
Hunt: successful sign-ins from an address the user has never used
For each account, the successful sign-ins from an IP address not seen for that account in the previous 30 days. The first question in any unfamiliar sign-in alert, asked across the whole tenant at once.
The evidence it leaves
Where the traces live, and what each source proves and does not.
Linux authentication records
Logon events (4624, 4625, 4648)
RDP session logs
utmp, wtmp and btmp
AWS CloudTrail
Entra ID sign-in logs
Practise it
Labs, timelines, evidence packs and tabletop scenarios to work before you need to.
Guided lab: forty failures, no lockouts, one success
A password spray that stayed under the lockout threshold and never produced a failed-logon event on the server it was aimed at. Find where the failures were recorded, identify the account that fell, and explain why the dashboard showed nothing.
Guided lab: the mailbox rule that was not the point
A business email compromise where the obvious finding is a decoy. Ninety minutes on Microsoft 365 audit logs, OAuth consent grants, and why resetting the password does not end this incident.
Impossible travel, and then a mailbox rule
You have fifteen minutes. What are your first three queries, in order, and what single action do you take before any of them? Write down what you expect each query to return before you run it.
A domain admin logon from a workstation that has never had one
Twenty minutes. Is this lateral movement, a misconfiguration, or a backup job nobody documented? Name the three pieces of evidence that would settle it, and say what you would do if you could not get any of them.
Read
Analyses, case studies, guides, references and interview questions.
Case study: the update was signed, and that was the problem
A trusted software update that carried a backdoor, worked as a case. Signing proved the build was the vendor's; it proved nothing about what was in it. Eight questions on detection, scope and the uncomfortable part, which is that nothing your endpoint controls were watching for was wrong.
Mini-guide: the five fields of a 4624 that decide what a logon means
Event 4624 has more than twenty fields and most triage reads two of them. The five that change the conclusion, what each one is really recording, and the values that catch people out.
Windows event log cheat sheet: by the question you are asking
Organised by what you are trying to establish rather than by number: who logged on and how, what ran, what persisted, what was tampered with. Every entry says which log, whether it is on by default, and what it does not tell you.
Evidence Gap Challenge No. 3: four people knew that password
An operational technology jump host, a shared engineering account, and a change nobody will own. Every log works, every timestamp is right, and attribution is still impossible. Work out what that costs, and what you would have needed to collect to make a name provable.
Evidence Gap Challenge No. 1: the laptop was reimaged on Tuesday
A supplier is out €96,000 and the only endpoint that mattered was wiped on day one, by a helpdesk following the documented process correctly. Here is every artefact that still exists. Work out what you can prove, what you can only say is consistent, and the one collection change that would have moved the most from the second column to the first.
Entra ID sign-in logs: the fields and error codes that settle an account question
Which fields in a sign-in record separate a traveller from a stolen session, what the common error codes mean, where non-interactive sign-ins hide, and how long any of it is kept.
how MITRE says to see it
Detection of Valid Account Abuse Across Platforms
- Detection of compromised or misused valid accounts via anomalous logon patterns, abnormal logon types, and inconsistent geographic or time-based activity across Windows endpoints.
- Detection of valid account misuse through SSH logins, sudo/su abuse, and service account anomalies outside expected patterns.
- Detection of interactive and remote logins by service accounts or users at unusual times, with unexpected child process activity.
- Detection of valid account abuse in IdP logs via geographic anomalies, impossible travel, risky sign-ins, and multiple MFA attempts or failures.
what reduces it
- M1013 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).
- M1017 User Training. Applications may send push notifications to verify a login as a form of multi-factor authentication (MFA). Train users to only accept valid push notifications and to report suspicious push notifications.
- M1027 Password Policies. Applications and appliances that utilize default username and password should be changed immediately after the installation, and before deployment to a production environment. When possible, applications that use SSH keys should be updated periodically and properly secured.
- M1018 User Account Management. Regularly audit user accounts for activity and deactivate or remove any that are no longer needed.
- M1026 Privileged Account Management. Audit domain and local accounts as well as their permission levels routinely to look for situations that could allow an adversary to gain wide access by obtaining credentials of a privileged account. These audits should also include if default accounts have been enabled, or if new local accounts are created that have not been authorized.
- M1032 Multi-factor Authentication. Implement multi-factor authentication (MFA) across all account types, including default, local, domain, and cloud accounts, to prevent unauthorized access, even if credentials are compromised. MFA provides a critical layer of security by requiring multiple forms of verification beyond just a password.