---
{
  "title": "Valid Accounts",
  "summary": "Valid-account abuse uses genuine credentials or sessions under unauthorized control.",
  "topic": "soc",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "published": "2026-10-04",
  "units": [
    2
  ],
  "aliases": [
    "T1078"
  ],
  "sources": [
    {
      "title": "MITRE ATT&CK T1078: Valid Accounts",
      "url": "https://attack.mitre.org/techniques/T1078"
    }
  ],
  "editorialVersion": 2
}
---

## What it means

Valid-account abuse uses genuine credentials or sessions under unauthorized control. Authentication succeeds, so defenders need context beyond whether the login was technically valid.


## An investigation example

A usually noninteractive account signs in from an unexpected source and retrieves data outside its normal workload.

## Evidence to examine

Correlate account role, source, device, timing, authentication method, and post-login resource access.

## A common analytical pitfall

A successful login does not prove that the rightful owner initiated it; an unusual source alone is also insufficient proof.

## Response considerations

Protect confirmed compromised identities and sessions, investigate initial credential exposure, and scope all activity performed with the account.


## Successful authentication does not prove authorized control

A genuine account can be used by an intruder through stolen credentials, compromised sessions, or another access path. The identity service may accept the login correctly while the human or process controlling the account is unauthorized. Investigation therefore needs more than the success status of authentication. Context and subsequent activity matter.

Local, directory, cloud, default, and service accounts can have different roles and permissions. Record the actual scope and account type. A low-privilege account can still expose useful information, while an administrator account can affect a much broader boundary. Do not infer privileges solely from a display name.

## A fictional familiar-name session

An academy sees an administrator account used from an unexpected device and followed by unusual resource changes. Analysts compare identity events, device context, approved work, session history, and the changes performed. Travel or a new support arrangement could explain part of the pattern, so they seek corroboration before attributing the activity.

Containment may involve session revocation, credential changes, or permission adjustments according to the platform and incident plan. Verify the effect rather than assume one password reset ends every form of access. Also review how the account was compromised and whether recovery methods or delegated permissions changed.

## Write a context-based finding

Create fictional login and application events for an account performing both normal and unexpected work. Identify which facts make the latter concerning and what evidence remains missing. State the difference between an account identity and the person operating it. Use prepared records, not real credentials or attempts against production accounts.

Account lifecycle controls help reduce unnecessary exposure: named ownership, appropriate permissions, timely removal, and review of service identities all matter. Multifactor authentication strengthens many access paths but should not be described as eliminating every session, recovery, or token risk. Evaluate the specific mechanism and the full sequence.

## Related concepts

- [[mitre-attack]]
- [[logs-and-telemetry]]
- [[incident-response]]