Has used valid high-privileged SSO users as leverage during negotiations.1
Valid Accounts T1078
- Tactics
- Initial Access, Persistence, Privilege Escalation, Stealth
- Platforms
- Containers, ESXi, IaaS, Identity Provider, Linux, macOS, Network Devices, Office Suite, SaaS, Windows
- Version
- 3.0
- Created
- 31 May 2017
- Last modified
- 12 May 2026
- Contributors
- Jon Sternstein, Stern Security; Mark Wee; Menachem Goldstein; Netskope; Praetorian; Prasad Somasamudram, McAfee; Sekhar Sarukkai, McAfee; Syed Ummar Farooqh, McAfee; Yossi Weizman, Azure Defender Research Team
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.[1] 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.
Valid Accounts MITRE reference T1078
47 groups have been recorded using this technique. Newest first; each entry carries MITRE’s procedure text and a link to the group’s full record. Click a name to filter the rules below.
Has compromised credentials associated with open source security scanning tools and used them to push malicious code to all the resources the tools had access to.1
Has leveraged valid accounts to log into VPN infrastructure.1 VOID MANTICORE has used compromised valid credentials to gain access to management infrastructure and enterprise control systems.2 VOID MANTICORE has also validated and tested authentication using compromised credentials prior to malicious actions.1
Has utilized compromised legitimate local and domain accounts within the victim environment to facilitate remote access and lateral movement sometimes in combination with PsExec.1
Has used tools to hijack valid SSH accounts.1
Has gained access to victim environments through legitimate VPN credentials.1
All 47 groups for this technique · 6 newest in this preview
11 campaigns have been recorded using this technique. Listed newest first; dates are year-granularity and attribution is MITRE’s.
During the Anthropic AI-orchestrated Campaign, the adversary used harvested credentials to authenticate against internal APIs, database systems, container registries, and logging infrastructure across targeted networks.1
During RedPenguin, UNC3886 used legitimate credentials to gain priviliged access to Juniper routers.12
During Operation MidnightEclipse, threat actors extracted sensitive credentials while moving laterally through compromised networks.1
During 3CX Supply Chain Attack, AppleJeus has gained access to the 3CX corporate environment through legitimate VPN credentials.1
Leviathan used captured, valid account information to log into victim web applications and appliances during Leviathan Australian Intrusions.1
During HomeLand Justice, threat actors used a compromised Exchange account to search mailboxes and create new Exchange accounts.1
All 11 campaigns for this technique · 6 newest in this preview
7 software entries are documented implementing this technique. MITRE files each as a tool or as malware; newest first, then by how many groups carry them.
Has used stolen Windows credentials to log in as the users.1
Has used valid SSH credentials to access remote hosts.1
Used hard-coded credentials to gain access to a network share.1
Can use supplied user credentials to execute processes and stop services.1
Acquires valid SSH accounts through brute force. 1
Some SeaDuke samples have a module to extract email from Microsoft Exchange servers using compromised credentials.1
All 7 software entries for this technique · 6 newest in this preview
Offense vs defense T1078
Is defensive coverage keeping up with adversary use? Eight counts, each ranked against all 697 ATT&CK techniques. Attack sits left, defense right, so a shape leaning left means adversaries are better documented here than defenders are equipped. Hover any spoke for its percentile and the share of techniques that have more. The timeline below shows when each side arrived.
How it got here
Adversary activity (campaign spans) over cumulative rule output. Each source is plotted independently from zero, so neither line includes the other. Campaign dates are year-granularity.
Valid Accounts detection strategy DET0560
MITRE names one behaviour worth catching for this technique and breaks it into 5 analytics, one per platform. Each carries the log sources it needs and the fields you tune per environment.
Detection of Valid Account Abuse Across Platforms
AN1543 · Windows
Detection of compromised or misused valid accounts via anomalous logon patterns, abnormal logon types, and inconsistent geographic or time-based activity across Windows endpoints.
Log sources
The data this analytic draws on. You do not need every component — each one you already collect covers part of it. Each links to its ATT&CK record.
| Data component | Name | Channel |
|---|---|---|
| User Account AuthenticationDC0002 | WinEventLog:Security | EventCode=4776, 4625 |
| Process CreationDC0032 | WinEventLog:Sysmon | EventCode=1 |
| Logon Session CreationDC0067 | WinEventLog:Security | EventCode=4624 |
Tunable fields
MITRE calls these the analytic’s mutable elements: the thresholds and filters you set for your own environment.
| Field | What you tune |
|---|---|
| LogonType | Flag unexpected logon types (e.g., Type 10 for remote interactive logins) for sensitive accounts. |
| TimeWindow | Define acceptable hours for interactive logon activity (e.g., 9AM-6PM local). |
| GeoIPMismatch | Trigger on location anomalies based on prior user behavior or policy. |
AN1544 · Linux
Detection of valid account misuse through SSH logins, sudo/su abuse, and service account anomalies outside expected patterns.
Log sources
The data this analytic draws on. You do not need every component — each one you already collect covers part of it. Each links to its ATT&CK record.
| Data component | Name | Channel |
|---|---|---|
| User Account AuthenticationDC0002 | NSM:Connections | sshd or PAM logins |
| Process CreationDC0032 | auditd:SYSCALL | execve |
Tunable fields
MITRE calls these the analytic’s mutable elements: the thresholds and filters you set for your own environment.
| Field | What you tune |
|---|---|
| UserContext | Identify logins to root or sudoers not aligned with normal usage profiles. |
| HostDensityThreshold | Number of unique systems a user authenticates to in a time window. |
| LoginMethod | Trigger on rarely used access methods such as password instead of SSH key. |
AN1545 · macOS
Detection of interactive and remote logins by service accounts or users at unusual times, with unexpected child process activity.
Log sources
The data this analytic draws on. You do not need every component — each one you already collect covers part of it. Each links to its ATT&CK record.
| Data component | Name | Channel |
|---|---|---|
| Process CreationDC0032 | macos:unifiedlog | exec logs |
| Logon Session MetadataDC0088 | macos:unifiedlog | loginwindow, sshd |
Tunable fields
MITRE calls these the analytic’s mutable elements: the thresholds and filters you set for your own environment.
| Field | What you tune |
|---|---|
| LoginOrigin | Login sourced from unexpected remote addresses. |
| ProcessTreeDepth | Track execution depth or anomalous chains post-login. |
AN1546 · Identity Provider
Detection of valid account abuse in IdP logs via geographic anomalies, impossible travel, risky sign-ins, and multiple MFA attempts or failures.
Log sources
The data this analytic draws on. You do not need every component — each one you already collect covers part of it. Each links to its ATT&CK record.
| Data component | Name | Channel |
|---|---|---|
| User Account AuthenticationDC0002 | saas:okta | Sign-in logs / audit events |
Tunable fields
MITRE calls these the analytic’s mutable elements: the thresholds and filters you set for your own environment.
| Field | What you tune |
|---|---|
| MFAFailureCount | Threshold of failed MFA attempts before alerting. |
| RiskScoreThreshold | Custom threshold based on calculated identity risk. |
| IPGeoVelocity | Detect impossible travel (logins from two distant geolocations within short time). |
AN1547 · Containers
Detection of containerized service accounts or compromised kubeconfigs being used for cluster access from unexpected nodes or IPs.
Log sources
The data this analytic draws on. You do not need every component — each one you already collect covers part of it. Each links to its ATT&CK record.
| Data component | Name | Channel |
|---|---|---|
| User Account AuthenticationDC0002 | kubernetes:audit | authentication.k8s.io |
Tunable fields
MITRE calls these the analytic’s mutable elements: the thresholds and filters you set for your own environment.
| Field | What you tune |
|---|---|
| ServiceAccountScope | Validate access from expected namespaces only. |
| ClusterIPWhitelist | Permit kubeconfig usage from a limited set of IPs. |
Use conditional access policies to block logins from non-compliant devices or from outside defined organization IP ranges.
Disable legacy authentication, which does not support MFA, and require the use of modern authentication protocols instead.
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).
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. This measure significantly reduces the risk of adversaries abusing valid accounts to gain initial access, escalate privileges, maintain persistence, or evade defenses within your network.
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. Policies should minimize (if not eliminate) reuse of passwords between different user accounts, especially employees using the same credentials for personal accounts that may not be defended by enterprise security resources.
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. Follow best practices for design and administration of an enterprise network to limit privileged account use across administrative tiers.
Regularly audit user accounts for activity and deactivate or remove any that are no longer needed.
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.