ATT&CK for ICS T0859 Valid Accounts: OT Credentials

Valid Accounts (T0859) is the technique that lets an adversary operate an industrial network as a legitimate user: stolen, default or newly created credentials that open HMIs, engineering software, jump hosts and field devices without any exploit. ATT&CK for ICS places it under both Persistence and Lateral Movement, and notes that adversaries may avoid malware altogether so they can send legitimate commands in an unintended way. This guide covers the credential types that matter in OT, the campaigns ATT&CK records from the Ukraine grid attacks to TRITON, how to reduce credential exposure across IT, the DMZ and field devices, the detection analytics ATT&CK attaches to T0859, and how to respond without locking operators out. It is written for OT security engineers, identity and PAM teams, control system owners and SOC analysts. For the matrix see the MITRE ATT&CK for ICS Guide; for the enterprise technique see the MITRE ATT&CK T1078 Valid Accounts Guide.

Key takeaways

In OT, a valid account is often enough to change the process. ATT&CK records Sandworm Team using valid credentials to interact with client applications and reach workstations hosting HMI applications in the 2015 Ukraine Electric Power Attack.
Default credentials are valid accounts too. ATT&CK v20 covers them under T0859 and notes that default credentials for control system devices may be publicly available, and its password policy mitigation says to change them before deployment to production.
Credential overlap is the bridge from IT to OT. ATT&CK warns that shared credentials and permissions let an adversary pivot between enterprise and OT environments, as TEMP.Veles did through RDP jump boxes in the TRITON attack.
Detection is about where and when, not whether, an account logs on. ATT&CK's analytics flag ICS-role accounts used from unapproved hosts, subnets or times, followed by access to field devices or engineering tools.
Named accounts make everything else work. ATT&CK recommends individual user accounts for enforcement and non-repudiation; shared operator logins defeat both detection and investigation.

What T0859 covers in ICS

ATT&CK for ICS v20 describes Valid Accounts as adversaries stealing the credentials of a specific user or service account, noting that default credentials for control system devices may be publicly available. Compromised credentials can bypass access controls, give persistent access to remote systems, and grant increased privilege or access to restricted network areas. Adversaries may also create accounts, sometimes with predefined names and passwords, as backup access for persistence. The technique applies to Embedded, Windows, Linux and Network Devices platforms.

ATT&CK highlights the overlap of credentials and permissions across systems: an adversary can pivot across accounts to reach domain or enterprise administrator level, and possibly move between enterprise and OT environments using credentials valid in both.

Technique	Role of the credential	OT example	First control
T0859 Valid Accounts	Using a working credential for persistence or movement	A domain account used to log on to an HMI host	Separate OT identities, named accounts, approved source hosts
T0822 External Remote Services	Credential used through a remote access service	A stolen engineer password on the plant VPN	Brokered access with phishing-resistant MFA
T0892 Change Credential	The adversary changes a credential to lock out owners	Setting a new device password so operators cannot log on	Recovery procedures, credential change monitoring

See the T0892 Change Credential guide, the ATT&CK for ICS Persistence Tactic Guide and the ATT&CK for ICS Lateral Movement Tactic Guide.

Procedure examples ATT&CK records

ATT&CK v20 lists eight procedure examples for T0859, more than most ICS techniques, which reflects how often credentials appear in OT intrusions.

Procedure example	What ATT&CK records	Lesson for defenders
2015 Ukraine Electric Power Attack (C0028)	Sandworm Team used valid accounts to move laterally through VPN connections and dual-homed systems, and to interact with client applications and reach workstations hosting HMI applications	Dual-homed hosts and shared domain credentials connect IT to OT
2016 Ukraine Electric Power Attack (C0025)	Sandworm Team used valid accounts to move laterally through VPN connections and dual-homed systems	The same pattern repeated a year later
Triton Safety Instrumented System Attack (C0030)	TEMP.Veles used valid credentials when moving laterally through RDP jump boxes into the ICS environment	Jump hosts protect nothing if the credentials that open them are stolen
2025 Poland Wiper Attacks (C0063)	The adversaries used valid accounts to access RTUs, protection and control relays, HMI computers and serial device servers	Field devices are account targets, not only Windows hosts
BlackEnergy (S0089)	Uses valid user and administrator credentials and creates new administrator accounts to maintain presence	Watch for new privileged accounts, not only misuse of existing ones
INCONTROLLER (S1045)	Can brute force password authentication to Schneider PLCs over the CODESYS protocol (UDP port 1740) and to OPC UA servers with a predefined password list	Weak device and OPC UA passwords become valid accounts
ALLANITE (G1000)	Used credentials collected through phishing and watering hole attacks	Credential theft upstream feeds T0859 later
OilRig (G0049)	Used stolen credentials to gain access to victim machines	Same lesson as ALLANITE

Mandiant's 2019 analysis of the TRITON actor reported that it was present in the target network for almost a year before reaching the safety instrumented system engineering workstation, relied heavily on remote administration such as RDP so its activity resembled legitimate administrator work, and used Windows systems in both the IT and OT networks as conduits to the ICS. See the Sandworm Threat Actor Profile and the Safety Instrumented Systems Security Guide.

The credential landscape in OT

OT credentials are more varied than enterprise ones, and many sit outside directory services. Inventory each class, because each needs a different control.

Credential class	Where it lives	Typical problem	Target state
Domain accounts with OT access	Corporate Active Directory	Same identity opens IT and OT, as in the Ukraine campaigns	Separate OT domain or local OT identity store, no trust that lets corporate accounts in
Shared operator logins	HMIs and SCADA clients	One login per control room, never changed	Named accounts, with fast user switching where the product supports it
Engineering software and project passwords	Engineering workstations and controller projects	Shared among engineers and integrators	Per-person accounts, project passwords held in a vault
Device credentials	PLCs, RTUs, relays, drives, serial device servers, network gear	Defaults unchanged, the same password across a fleet	Unique per device, stored in a vault, central authentication such as RADIUS where devices support it
Service and application accounts	Historians, OPC servers, SCADA services, backup jobs	Interactive logon allowed, passwords never rotated, no owner	Owned, non-interactive, least privilege, rotated
Vendor and integrator accounts	Remote access, jump hosts, local device accounts	Shared by a vendor team, enabled permanently	Named, enabled per session, recorded

Service, application and device credentials are non-human identities, and they are often the least governed accounts in OT. See NHIs in OT, the Service Account Security Guide and the Default Credential Breaches Lessons Guide.

Prevention: ATT&CK's mitigations in practice

ATT&CK lists eleven mitigations for T0859. Grouped by what they achieve:

Separate OT identity from IT (M0915, M0926): ATT&CK suggests a network-wide authentication service such as Active Directory, LDAP or RADIUS, which many ICS devices support, and following best practice to limit privileged account use across administrative tiers. In OT that means an identity store the corporate domain cannot administer. See the Identity for OT Environments Guide.
Use named accounts with least privilege (M0918, M0801): ATT&CK recommends user accounts for each individual for enforcement and non-repudiation, and authenticating all access to field controllers before authorising changes to state, logic or programs.
Eliminate default and weak passwords (M0927, M0913, M0947): change defaults immediately after installation and before production; keep credentials out of code, repositories and cloud storage; audit configuration files and repositories for stored credentials. The joint CISA, FBI, EPA and DOE primary OT mitigations also call for changing default passwords immediately and using strong, unique passwords.
Require MFA where it fits (M0932): ATT&CK says MFA can greatly reduce the risk of stolen credentials being used. Apply phishing-resistant MFA at the remote access and jump host layer, where it does not slow operators responding to the process.
Restrict where accounts can be used (M0937, M0936): ATT&CK suggests IP allowlisting combined with account management, so data access is limited to valid users from expected ranges, and account use policies such as login hours and lockout, considered against safety and availability.
Audit privileged and new accounts (M0926): ATT&CK says to audit domain and local accounts routinely, including whether default accounts are enabled or unauthorised local accounts have been created.

Choosing controls where trade-offs bite

Situation	Preferred approach	Trade-off
Control room HMIs used around the clock	Named accounts with fast switching, or a locked-down shared view-only session plus named accounts for control actions	Training and product support needed; never lock out an operator mid-incident
Field devices with local passwords only	Unique passwords per device held in a vault, checked out by engineers	Vault availability becomes an operational dependency; plan break-glass
Devices that support RADIUS or LDAP	Central authentication with a local fallback account held in a vault	Authentication server must be resilient and inside the OT zone
Small sites with few engineers	Change all defaults, separate OT accounts from email accounts, MFA on remote access	Less monitoring depth; review accounts quarterly

Emergency access needs its own design so that tighter controls do not stop recovery. See the Break-Glass Account Guide and the Privileged Access Management Guide.

Detection: ATT&CK's analytics for T0859

ATT&CK v20 attaches a detection strategy, Detection of Valid Accounts, with four analytics. Each carries the OT operational fidelity gate: alert only when the account, device or session breaks the approved identity, source host, jump path or zone policy and is corroborated by access to a protected OT asset, execution, a configuration change or another security-relevant follow-on event. Approved shift activity, vendor support, break-glass use, commissioning and documented remote-access windows are suppressed.

Platform	What it looks for	Data you need
Windows	An ICS-role account logging on interactively or remotely from a workstation not in the approved host inventory, or outside its usual pattern, then connecting to the field device network or an ICS application	Windows logon events with logon type and source, approved host inventory per account, flow records
Linux	SSH or local authentication by an ICS service or operator account from outside the approved administrative subnet, or sudo or su escalation by a service account that does not normally need it, followed by use of ICS engineering tools	SSH and sudo logs, process execution records
Network devices	Management sessions (SSH, RADIUS, TACACS+) with valid ICS network administrator credentials from outside the approved network management subnet or at unusual times, making configuration changes with no open change ticket	AAA logs, device configuration change logs, change tickets
Embedded	Field device access with a legitimate engineering credential from an IP or MAC address not enrolled as an authorised engineering workstation, followed by write operations the credential owner has not acknowledged through change control	Protocol-aware network monitoring, enrolled engineering workstation list, change records

Signals worth adding

New local or domain administrator accounts in OT zones: BlackEnergy created administrator accounts for persistence. Any new privileged account outside a change record deserves review.
Interactive logons by service accounts: historian and OPC service accounts should not log on interactively. See How to detect interactive logons by service accounts.
Repeated authentication failures to controllers or OPC UA servers: INCONTROLLER's password guessing would show as bursts of failed authentication from one source.
Infeasible remote logons: Mandiant's TRITON guidance suggests looking for VPN logons with infeasible location, address or hostname patterns.

See the OT Security Operations Centre Guide for building these into a monitoring programme.

Safety-aware response

Establish what the account can do: which hosts, applications and devices it can reach and whether it can write to controllers or safety systems.
Agree containment with operations: disabling a shared operator account can lock out the control room. Issue replacement credentials to legitimate users before, or at the same moment as, disabling the compromised one.
Reset in the right order: rotate the compromised credential, any credential that shared its password, and credentials stored on hosts the account touched, including service account and device passwords. Rotate service credentials in step with the applications that use them, to avoid outages.
Hunt for persistence: look for new accounts, added group memberships and changed device passwords, then compare controller logic and parameters against known-good copies.
Preserve evidence: authentication logs, jump host and remote access records, AAA logs and network captures. See the OT Incident Response Guide.

Metrics that show it is working

Devices with default credentials: count from assessments and inventory. Target zero.
Shared accounts on HMIs and engineering hosts: count, with a dated plan to replace each.
OT access granted through corporate domain accounts: target zero.
Service accounts with an owner and rotation date: share of OT service and application accounts. Target 100%.
Unexplained new privileged accounts: found in monthly review with no change record. Target zero.

Framework mapping

Control area	NIST SP 800-53 Rev 5	NIST CSF 2.0	ATT&CK for ICS mitigation
Account lifecycle and review	AC-2 Account Management	PR.AA-01	M0918 User Account Management; M0926 Privileged Account Management
Named, authenticated access	IA-2 Identification and Authentication (Organizational Users); IA-3 Device Identification and Authentication	PR.AA-03	M0801 Access Management; M0932 Multi-factor Authentication
Passwords and defaults	IA-5 Authenticator Management	PR.AA-01	M0927 Password Policies; M0913 Application Developer Guidance
Least privilege	AC-6 Least Privilege	PR.AA-05	M0926 Privileged Account Management
Where accounts can be used	AC-3 Access Enforcement; SC-7 Boundary Protection	PR.IR-01	M0937 Filter Network Traffic; M0936 Account Use Policies
Detection	AU-6 Audit Record Review, Analysis, and Reporting; SI-4 System Monitoring	DE.CM-03; DE.CM-09	M0947 Audit; ATT&CK detection strategy for T0859

NIST SP 800-82 Rev. 3 (final, 28 September 2023) is the OT tailoring reference; NIST notes an initial public draft of Revision 4 is open for comment until 30 November 2026. See the NIST SP 800-82 OT Security Guide and the IEC 62443 Guide.

Common failure patterns

OT access through the corporate domain: both Ukraine campaigns moved from IT to OT with valid accounts through VPNs and dual-homed systems.
Jump hosts opened with stolen credentials: TRITON's operators passed through RDP jump boxes with valid credentials. A jump host needs MFA and its own monitored accounts to add protection.
Dormant accounts left enabled: the Colonial Pipeline intrusion used a legacy VPN profile that was no longer in use, with a leaked password and no MFA.
Fleet-wide device passwords: one password across every RTU or relay means one leak opens the fleet.
Lockout policies on shared operator accounts: a guessing attack can lock the control room out. ATT&CK explicitly asks for account use policies to be weighed against safety and availability.
Service accounts nobody owns: historian and OPC accounts with interactive rights and old passwords are ready-made persistence.

Practitioner checklist

Inventory OT credentials by class: domain, shared operator, engineering, device, service and vendor.
Remove OT access from corporate domain accounts and separate the OT identity store.
Replace shared HMI and engineering logins with named accounts, starting with accounts that can write to controllers.
Change every device default password and use unique passwords per device, held in a vault.
Require phishing-resistant MFA at remote access and jump hosts.
Give every service and application account an owner, deny interactive logon and set a rotation date.
Deploy the ATT&CK T0859 analytics with approved host lists, administrative subnets and enrolled engineering workstations.
Design and test break-glass access so credential controls never block recovery.

MITRE ATT&CK for ICS T0859 Valid Accounts: Controlling and Monitoring Credentials in OT