Detecting T1078 Valid accounts

Why valid account misuse looks like normal work

A successful login with a valid account raises no alert by default, so a SOC lead cannot rely on authentication failures to spot T1078 Valid accounts. The technique lets an adversary operate inside an environment with credentials the organization already issued, which allows the activity to blend into administrative and user work. It appears in intrusions after an initial foothold, when an adversary reuses existing identities to reach cloud consoles, container platforms, hypervisors or identity providers. MITRE defines the Stealth tactic (TA0005) as follows: "The adversary is trying to hide and conceal their actions, appearing as normal behavior." T1078 serves that goal directly, because the logon itself is legitimate.

This page targets Enterprise ATT&CK 20.0, and it names that version because releases can rename, deprecate or revoke techniques and detection mappings must match the version in use. T1078 has four sub-techniques, which cover the Containers, ESXi, IaaS and Identity Provider platforms named in this topic. The behavior looks similar in every log source, but the telemetry, account types and administrative paths differ on each platform. Decide early which of these platforms carry sensitive workloads in your estate, and assign an owner for each one so that detection work does not stop at the identity provider.

Treat a successful logon as an event that needs an explanation. Before tuning any rule, document which accounts are expected on each platform, the hours they normally authenticate, and the source systems they normally use. Then confirm with each platform owner that authentication events reach your SOC and retain enough fields to identify the account, source and target. Missing telemetry is the gap that most often leaves this technique unexamined, so verify ingestion for every platform in scope before you move on to detection logic.

Which telemetry reveals valid account misuse

This table maps the telemetry types named in the T1078 detection plan to the platforms in scope and the open-source collectors that gather them. Read each row as a question: what event shows that a valid credential was used somewhere it should not be, and what forwards that event to your analysts. Treat the ATT&CK 20.0 data component mapping as a starting point to verify, not a final answer.

Telemetry	Where it appears	Open-source collector	What to confirm
Logon Session Creation	Windows and Linux hosts, container nodes, ESXi hosts that log authentication	Wazuh agents on hosts and nodes, Zeek for network-visible sessions	Which hosts log successful logons with source address and account name
User Account Authentication	Identity provider sign-in logs, VPN and SSO gateways, ESXi and vCenter sign-ins	Log forwarding from the identity provider and gateways into Wazuh or Security Onion	Whether failed and successful authentications, MFA results and client details are all retained
Process Creation	Endpoints, container workloads and hypervisor shells where a session runs commands	Wazuh agents with command auditing, Security Onion host telemetry	Whether process creation is enabled on every platform in scope, since DC0032 is the most common reference
Cloud control plane activity	IaaS management APIs and account administration logs	Forwarding of cloud audit logs to Wazuh or Security Onion, with cloud-native logs kept as the source of record	Whether account creation, role changes and new access keys generate events you can query
Container runtime and orchestrator events	Kubernetes API audit records and container runtime logs	Wazuh agents on nodes and forwarding of API audit logs	Whether API audit policy captures authentication and service account token use
Detection strategy mapping	ATT&CK technique page for T1078 and its sub-techniques	Sigma rules and detection logic stored in version control	Confirm the current detection strategy and data component mapping for T1078 in the ATT&CK 20.0 STIX bundle before you rely on it

Detection logic for valid account abuse across platforms

Valid account abuse looks like normal authentication, so detection depends on comparing each login against a baseline of what that account usually does. The cards below describe five detection ideas, each with its logic, the thresholds to tune and the benign activity that will trigger it. Tune every idea against your own identity provider and platform logs before you alert on it.

Impossible travel and anomalous login times

Compare successive successful logons for the same account and flag pairs whose source locations are too far apart for the elapsed time, or logons outside the hours the account normally uses. Set the distance and time thresholds from your own baseline, not from a generic value. Expect false positives from business travel, VPN exit points that sit in other countries, and mobile carriers that route traffic through distant gateways. Check whether the account is a shared or break-glass identity before escalating.

First-seen source for established accounts

Build a per-account history of source addresses, user agents and client applications over a rolling window, then alert when an established account authenticates from a source it has never used. This catches credentials replayed from a new system more reliably than geography alone. Expect noise after device refreshes, new office networks, cloud NAT changes and new CI runners, so pair the alert with a check of the device or session record before escalation.

Privileged account use outside its usual role

Track which hosts, tenants, projects and administrative functions each privileged account touches, and alert when an administrator authenticates to a system outside its normal scope. Start with the accounts holding the most rights, since they carry the largest blast radius. Expect false positives during on-call rotations, emergency changes and approved migrations, so match alerts against your change calendar and ticket system before paging anyone.

Service account interactive logons

Service accounts are normally used by automation and should not open interactive sessions. Alert on any interactive, remote desktop or console logon by an account registered as a service identity, and on token requests from a service identity that come from a human workstation. Expect false positives from legacy scripts that were built to run interactively and from vendor tools that require a logged-on session, so inventory these before you enable blocking.

New sessions on container and ESXi management planes

Watch management interfaces such as the Kubernetes API server and the vCenter or ESXi management plane for new authenticated sessions that do not match a known pipeline, operator or jump host. Correlate session creation with privileged actions, such as creating workloads or changing host configuration, that follow shortly afterward. Expect false positives from automated deployment pipelines, scheduled backups and monitoring agents, so maintain an allowlist of service identities and the networks they use.

How to validate that a valid account detection fires

This sequence proves that a valid account detection for T1078 fires on the platforms in scope, using an approved test identity in a lab or cyber range. It produces evidence of log coverage, rule behavior, detection latency and alert quality that a CISO or auditor can review.

Define the account and platform under test
Agree in writing which platforms are in scope, such as the identity provider, IaaS control plane, ESXi hosts, or container clusters, and which account class is being emulated, for example a standard user, a service account, or a privileged administrator. Record the ATT&CK version the detection maps to, the sub-techniques covered, and the owner of each platform. This step is done when the scope document names the platform, the account class, the target ATT&CK version (v20.0 for these pages), and the people who will sign off on results. Ask your provider to confirm the exact sub-technique list against the current ATT&CK technique page before you start.
Provision an approved test identity
Create a dedicated test identity in the lab or range tenant, with a documented owner, an expiry date, and a restricted entitlement set that matches the account class under test. Keep it out of production groups and exclude it from routine access reviews only where your policy allows. Tag the identity so that every event it generates can be separated from real activity. This step is done when the identity, its entitlements and its tag are recorded in the test plan and approved by the owner of the platform under test.
Plan controlled sign-in scenarios
Write a scenario sheet that describes the legitimate-looking sign-in patterns to emulate, such as a sign-in from a known lab location, a sign-in outside the test identity's normal hours, a sign-in from an unfamiliar device, and a privileged role assumed by a standard identity. Each scenario lists the expected log events, the rule expected to fire, and the expected severity. Keep the scenarios descriptive and approved by the detection owner. This step is done when every scenario has an expected outcome and an approver, and the test window is agreed.
Run the scenarios under observation
A named operator runs the approved scenarios in the agreed window while a second person watches the SIEM and the platform audit logs. The operator records the start and end time of each scenario, the source addresses and device names used, and any deviations from the plan. The observer notes when each event first appears. This step is done when every scenario has a timestamped record from both the operator and the observer, with no unplanned activity in the test identity's history.
Confirm expected log events arrive in the SIEM
Check that the expected authentication and session events from the identity provider, cloud audit trail, hypervisor or container platform reach the SIEM, such as Wazuh, Security Onion or another platform your team uses, with the fields the rule depends on. Compare the field names and values against the scenario sheet, and note any gaps in timestamp, user identifier, source address or event type. Ingestion gaps are fixed before tuning is judged. This step is done when each expected event type is present for each scenario, or each gap has a logged owner and remediation.
Check the rule fires within the tuning window
Verify that the detection rule raises an alert for each scenario that should trigger it, and that scenarios meant to stay quiet do not raise alerts. Measure the time from the source event to the alert, and compare it with the latency target agreed for the tuning window. Confirm the rule references the ATT&CK technique and sub-technique it was written for. This step is done when the alert log shows a true positive or the expected negative for every scenario, with measured latency recorded against the target.
Record latency, fidelity and analyst notes
Produce a validation record that lists, for each scenario, the detection latency, the alert fidelity (true positive, false positive, or missed), the analyst's triage notes and the actions taken to tune the rule. Include the ATT&CK version, the rule version, and the test identity's tag so that the record can be reproduced in the next exercise. Have the detection owner and the platform owner sign the record. This step is done when the record is stored with the detection repository, and any missed or noisy scenario has an open tuning item with an owner.

How identity and platform logs reach the SOC

Detection of T1078 Valid Accounts depends on whether logins from the identity provider, cloud IaaS control plane, container orchestrator and ESXi hosts actually arrive in the SIEM, and in what order. Map each source to its path: the identity provider's sign-in and directory audit events, the cloud provider's control plane audit trail, the Kubernetes API audit log on the cluster, and the vCenter and ESXi authentication and shell logs. Each hop is a trust boundary. The collector agent, the forwarder, the message broker and the SIEM indexer each run under their own credentials, and each can drop, truncate or queue events. Mark those boundaries on the architecture diagram and record which team owns each one, because a gap at any hop looks identical to a quiet account during an investigation.

Some sources are off by default or hold events for a limited time. Confirm in your own environment whether sign-in logs, data access logs, API audit policy levels, and ESXi syslog forwarding are enabled for every tenant, subscription, cluster and host, and whether any of them are streamed or only available through periodic export. Ask each platform owner for the documented retention period and whether it can be extended. Retention shorter than your detection and investigation window means an account that was used months ago may leave no trace by the time someone looks. Keep these answers in a source inventory that the detection team reviews each quarter.

Investigations also need consistent timestamps. A login recorded in UTC on one platform and in local time on another, or a host whose clock has drifted, can place a token issuance after the access it supposedly enabled. Confirm that every source, collector and SIEM node synchronizes to an authorized time source, and that the pipeline preserves the original event time rather than the ingestion time. Test this during a cyber range exercise by generating a known login on each platform and checking that the timestamps line up across the SIEM. If they do not, fix the clocks before tuning any detection rule.

Preventive controls that limit valid account misuse

T1078 succeeds when a legitimate credential works in the wrong hands, so prevention focuses on who holds accounts, how much they can do, and how long they keep access. The cards below map to the two ATT&CK mitigations supplied for T1078, plus the logging control that makes misuse visible.

Account lifecycle under User Account Management

User Account Management (M1018) covers how accounts are created, changed, and retired. For T1078, the practical question is whether every account, including service and contractor accounts, has a named owner, an approval record, and a removal trigger tied to employment or contract end. Check for orphaned accounts that still authenticate after their owner has left, and for default or shared accounts on containers, ESXi hosts, and identity providers that no one actively manages. Confirm which controls your identity provider and platforms enforce natively and which depend on your own process.

Least privilege for every role

Valid accounts are most damaging when their permissions exceed the job. Review role assignments on cloud IaaS tenancies, Kubernetes clusters, ESXi, and SaaS admin consoles, and remove standing rights that are used rarely. Prefer roles scoped to a project, namespace, or host group over tenant-wide roles. Ask each platform owner which actions a standard user can perform without elevation, since those actions define how far a stolen session can reach.

Separation of administrative accounts

Privileged Account Management (M1026) centers on keeping administrative identities apart from daily work identities. Administrators should sign in with a separate account that is not used for email or web browsing, and privileged sessions should require stronger authentication than standard sessions. Where the platform supports it, time-bound or approval-based elevation reduces the window in which a privileged credential is valid. Document which accounts hold break-glass access and test that they still work.

Periodic access reviews

Access that was correct at grant time often drifts. A recurring review of accounts, group memberships, API keys, and service credentials lets owners confirm or revoke each entry. Focus reviews on dormant accounts, accounts with administrative rights, and accounts that authenticate from unexpected locations or at unusual hours. Record the reviewer, the date, and the decisions, because these records are the evidence auditors usually ask for.

Audit logging supports detection, not prevention

Audit (M1047) is listed as a mitigation for T1078 in the supplied mapping, but it reduces exposure only indirectly by making misuse visible. Authentication and account change events must reach a central store before the detection rules in this section can work. Confirm that your platforms record successful and failed logons, role changes, and credential creation, and that these logs are retained long enough for investigations. Verify the mapping for your target ATT&CK version, because releases can rename or revise mitigation links.

Triaging a valid account alert without tipping off the attacker

The first decision is whether the alert reflects a real person using the account, and that check must not run through the same channel the attacker may control. Confirm the identity and business context with the account owner through a verified channel that is already on file, such as the HR directory contact or the manager's known phone number, not a reply to an email or chat message that arrived after the alert fired. For service accounts, confirm with the application owner who expects the authentication pattern, the source hosts and the scheduled jobs. Record who was contacted, when and what was said, because that record becomes evidence if the account turns out to be compromised.

While that confirmation is in progress, review the account's recent sessions and privilege changes in the identity provider and the affected platform. Look at sign-in source addresses and user agents, the first time each source appeared for this account, MFA events, and any change to group membership, role assignments or API keys. Then scope the blast radius: find other accounts, service principals and platforms that share the same password vault entry, federation trust, API token or break-glass credential. Reviewing these shared paths first tells you whether containment will be a single account action or a coordinated rotation across several systems. Export the logs and session records to write-once storage before any change, so that containment does not erase the trail.

Containment choices are sessions, credentials and access, in that order of reach. Revoking active sessions and forcing re-authentication is usually the least disruptive step for an interactive user. A credential reset is the next step, but for shared or service accounts, disabling the account without coordination can stop a production pipeline or a backup job. Agree the sequence with the identity team and the platform owners in advance, using a named incident lead and a change window, and rotate shared secrets in a planned order. Confirm the expected outcome of each step with the account owner, and keep the attacker-facing signals quiet: do not send notifications to the account holder's mailbox until the team has agreed that the mailbox itself is not part of the compromise.

Rehearsing valid account detection in a private cyber range

Build the range with a self-hosted or sandboxed identity provider, a small set of test user accounts across standard, administrative and service roles, and the authentication logs forwarded to your SIEM. The goal is to see whether a sign-in that is technically valid still raises a useful alert when the context is wrong. Injects should describe the situation in plain terms, such as a successful sign-in from an unusual location or a dormant account becoming active, without scripted steps or credential material.

Range setup: Use test tenants with realistic role separation and confirm that sign-in events, session creation and account change events are all ingested by your detection platform.
Planned injects: Simulate a valid credential used outside its normal hours, a dormant account returning to use, and a privileged role assignment that was not requested through the change process.
Good detection: An alert fires for each inject within the agreed window, names the correct user and source, and is routed to the analyst queue with the ATT&CK technique and sub-technique recorded.
Good response: The analyst scopes containment to the affected account and active sessions, confirms with the account owner, and hands off a timeline that separates the sign-in from any follow-on activity.
Check: Confirm the rule set targets the ATT&CK version you have adopted, since detection strategy and data component references change between releases.

Questions SOC leads ask about detecting valid accounts

How do I baseline normal sign-in behavior for valid account misuse?

Start by recording who signs in, from where, to which systems, at what times and through which authentication methods, over a period long enough to cover your normal business cycles such as month-end and release windows. Group accounts by role (interactive staff, administrators, automation, vendors) because a single threshold for all of them produces noise. Build baselines per account and per role, covering source countries or networks, typical hosts, logon types and failure rates. Then alert on deviations that matter for T1078 such as a first-seen source for a privileged account, a successful sign-in shortly after repeated failures, or a dormant account suddenly active. Review the baseline quarterly, since travel patterns, vendor changes and new applications shift what normal looks like. Confirm that your identity provider and endpoint sources expose the fields you need before you commit to thresholds.

How should service accounts and break-glass accounts be monitored differently?

Service accounts and break-glass accounts should be monitored by expected behavior rather than by human-style patterns. A service account normally authenticates from a fixed set of hosts, at predictable intervals, to a short list of resources, so any interactive logon, new source host or use outside its job schedule is a strong signal. Break-glass accounts should be almost silent: every use should generate a high-priority alert, be tied to a documented incident or change record, and trigger a review of the session activity. Keep an inventory of these accounts with owners, purpose and credential rotation status, and confirm with your identity team how sign-in events for them are recorded, because some platforms log them differently. Test the alert path during your cyber range exercises so that a break-glass use is not discovered first in a quarterly report.

How do I tell valid account misuse from legitimate administration?

The difference usually lies in context rather than in the authentication event itself. Legitimate administration typically has a traceable change ticket, a known administrator working in a known window, a session from a managed device, and actions that match the change scope. Misuse often shows a mismatch: the account signs in outside its usual pattern, the device is unmanaged, the activity touches accounts or permissions unrelated to the task, or the session is followed by bulk reads, new credentials or disabled logging. Correlate sign-in events with process creation, privilege change and configuration change telemetry, then ask an administrator to confirm the action within a defined window. Record the outcome of each review so that false positives feed back into tuning. Expect some ambiguity, and document how analysts escalate it rather than expecting a single rule to settle every case.

How do ATT&CK v18 and v19 changes affect my T1078 detection mapping?

ATT&CK v18, released October 28, 2025, replaced detections in technique pages with detection strategies and analytics, updated data components and deprecated some data sources. ATT&CK v19, released April 28, 2026, split the Enterprise Defense Evasion tactic into Stealth, which keeps ID TA0005, and Defense Impairment, which has ID TA0112. Because T1078 and its sub-techniques appear under tactics that were affected by that split, review your mapping spreadsheets and detection rule metadata against the version you target. Name the ATT&CK version in every rule and dashboard, map each analytic to the current data components, and remove references to deprecated data sources. Check the official ATT&CK updates page before each review, because later releases can rename or revoke items again.

How often should I re-test valid account detections in a cyber range?

Re-test whenever something that feeds the detection changes, and also on a regular schedule so that drift is caught early. Triggers include a new identity provider or directory connector, a change to MFA or conditional access policy, a new ATT&CK version that changes your mapping, a major change to privileged roles, and a log pipeline upgrade. On a scheduled basis, many teams rehearse at least once per quarter for the highest-risk accounts and at a lower frequency for the rest, but the right cadence depends on your change rate and risk appetite, so agree it with your SOC and audit stakeholders. Each test should record which account type was used, which alert fired, how long triage took and what evidence was captured. Confirm the cadence and the evidence format with your compliance lead before committing to a schedule.

Can we run valid account detection ourselves, or do we need outside help?

Many teams can run baseline, alerting and triage themselves if they have log coverage across identity, endpoint and cloud sources and a clear owner for privileged accounts. Outside help tends to be useful in three places: defining the scope and deliverables in writing before work begins, building the test scenarios and private cyber range exercises, and documenting the controls for compliance assessment. DeployOpen implements, hardens and documents self-hosted open-source platforms inside your own infrastructure, runs security testing, operates private cyber ranges and prepares evidence for compliance assessments, although it does not issue audit reports or attestations. Engagements are typically fixed-scope, and ongoing support is available as a retainer. Ask any provider to show how their work maps to your ATT&CK version and which responsibilities stay with your team after handover.

How DeployOpen builds and tests valid account detections

DeployOpen works on T1078 Valid accounts as a fixed-scope engagement inside your own infrastructure, covering the platforms and identity sources you actually run. The work moves from a written scope to detections that are built, tested in a private cyber range, documented and handed over to your team.

How we scope

Inventory which identity providers, IaaS consoles, ESXi hosts and container platforms accept interactive or API logins in your estate.
Agree which logon, authentication and account-management telemetry sources are available and which must be enabled first.
Record the ATT&CK version the detections will target, so mappings stay correct after future ATT&CK releases.

How we build

Translate the detection strategies for T1078 and its sub-techniques into analytics written against your log sources.
Write detection rules in open formats such as Sigma and deploy them to Wazuh or your chosen SIEM in your environment.
Tune thresholds for service accounts, break-glass accounts and automation so routine logins do not flood analysts.

How we hand over

Test each analytic in a private cyber range using emulated valid account use, then record which cases fire and which do not.
Deliver documentation covering data sources, rule logic in plain language, known blind spots and the response runbook.
Map the User Account Management and Privileged Account Management mitigations to the controls and evidence you already keep.

How we support

Review detection coverage after each ATT&CK release and after changes to your identity or hypervisor configuration.
Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope work closes.
Confirm with your team which evidence your independent auditor expects, since DeployOpen prepares evidence but does not issue audit reports.

T1078 Valid accounts