T0859: Valid Accounts
Adversaries may steal the credentials of a specific user or service account using credential access techniques. In some cases, default credentials for control system devices may be publicly available. Compromised credentials may be used to bypass access controls placed on various resources on hosts and within the network, and may even be used for persistent access to remote systems. Compromised and default credentials may also grant an adversary increased privilege to specific systems and devices 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 or to control devices and send legitimate commands in an unintended way.
Adversaries may also create accounts, sometimes using predefined account names and passwords, to provide a means of backup access for persistence. [1]
The overlap of credentials and permissions across a network of systems is of concern because the adversary may be able to pivot across accounts and systems to reach a high level of access (i.e., domain or enterprise administrator) and possibly between the enterprise and operational technology environments. Adversaries may be able to leverage valid credentials from one system to gain access to another system.
Analyst context for executives and security teams
Valid Accounts is high-value in ICS because legitimate credentials can let an adversary look like an authorized operator, engineer, service, or remote-access user rather than malware. The business issue is not just password theft; it is whether compromised, default, or newly created accounts could provide persistent access to workstations, HMIs, PLC-adjacent systems, historians, control servers, VPN servers, jump hosts, and other operational assets where legitimate commands may affect operations.
Executive priority
Treat this as an identity and access governance risk for operational resilience. Leaders should ask whether OT accounts, privileged accounts, remote access accounts, service accounts, and any default credentials are inventoried, reviewed, and separable between enterprise and OT environments. Priority should go to evidence that access management, privileged account management, MFA where operationally feasible, password/account-use policies, network filtering, Active Directory hardening, and audit practices are actually enforced for ICS pathways such as VPN servers, jump hosts, HMIs, control servers, and engineering workstations.
Technical view
MITRE provides no official detection text for T0859, but the relationship to DET0724 indicates a detection strategy exists for Valid Accounts. SOC and IR teams should validate identity-centric visibility across ICS access paths: successful and failed logons, account creation and modification, privileged group changes, service account use, remote sessions through VPN and jump hosts, authentication to Windows/Linux ICS hosts, and access to embedded or networked control assets where logs are available. Because the technique may involve no malware or unusual tooling, detection should emphasize abnormal use of otherwise valid accounts, especially cross-boundary enterprise-to-OT access, unexpected account reuse, default credential exposure, and commands or sessions inconsistent with normal operational roles.
Likely telemetry
- Authentication logs for VPN servers, jump hosts, workstations, HMIs, control servers, application servers, historians, and data gateways where available
- Directory service and Active Directory events, including account creation, group membership changes, privileged account changes, and SID/filtering-relevant configuration evidence
- Privileged account management and access management system logs
- Remote access session records, including source, destination, user, time, and session duration
- Account use policy evidence such as lockouts, failed login bursts, login time violations, and disabled-account activity
Detection direction
- Validate whether DET0724-aligned analytics are implemented or mapped locally, since MITRE does not provide detection details in the object fields.
- Baseline normal account use by role and asset type; prioritize anomalies involving VPN servers, jump hosts, engineering workstations, HMIs, control servers, historians, and gateways.
- Tune for legitimate but risky patterns: new accounts with predefined names, unexpected privileged access, use of default or shared credentials, service account interactive logon, and enterprise credentials used in OT paths.
- Correlate identity events with network session records and operational change records, because valid-account activity may not produce malware alerts.
- Account for false positives from maintenance windows, vendor support, shift changes, and emergency operations; require local operational context before escalation.
Mitigation priorities
- Start with account inventory and ownership: remove default, stale, shared, and unnecessary accounts; document service accounts and privileged accounts.
- Enforce User Account Management, Privileged Account Management, Password Policies, and Account Use Policies for OT-relevant accounts.
- Apply Access Management controls, especially where field devices or legacy systems cannot enforce strong user identification and authentication directly.
- Use Multi-factor Authentication where operational, safety, and real-time constraints allow, with particular focus on remote access, jump hosts, VPN servers, and privileged workflows.
- Harden Active Directory configuration where AD supports ICS access paths, including controls that limit credential reuse and inappropriate trust expansion.
Analyst notes and limits
The supplied ATT&CK object is an ICS technique with no tactic or platform specified for the technique itself, but it targets a broad set of ICS assets including workstations, HMIs, PLCs, RTUs, IEDs, historians, control servers, application servers, data gateways, safety controllers, VPN servers, jump hosts, and field I/O. The decision value is strongest where identity, remote access, and OT segmentation intersect: a valid account can make harmful access appear routine unless identity telemetry is correlated with operational context.
MITRE did not provide official detection text for this object, and the relationship context gives only the name of DET0724 without detailed analytics. Local validation is required to determine which ICS assets can produce authentication logs, whether embedded devices support account-level auditing, and whether operational constraints limit MFA, lockouts, or other account controls.
Valid Accounts
Adversaries may steal the credentials of a specific user or service account using credential access techniques. In some cases, default credentials for control system devices may be publicly available. Compromised credentials may be used to bypass access controls placed on various resources on hosts and within the network, and may even be used for persistent access to remote systems. Compromised and default credentials may also grant an adversary increased privilege to specific systems and devices 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 or to control devices and send legitimate commands in an unintended way.
Adversaries may also create accounts, sometimes using predefined account names and passwords, to provide a means of backup access for persistence. [1]
The overlap of credentials and permissions across a network of systems is of concern because the adversary may be able to pivot across accounts and systems to reach a high level of access (i.e., domain or enterprise administrator) and possibly between the enterprise and operational technology environments. Adversaries may be able to leverage valid credentials from one system to gain access to another system.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Groups, software, and campaigns
G1000: ALLANITE
ALLANITE is a suspected Russian cyber espionage group, that has primarily targeted the electric utility sector within the United States and United Kingdom. The group's tactics and techniques are reportedly similar to Dragonfly, although ALLANITEs technical capabilities have not exhibited disruptive or destructive abilities. It has been suggested that the group maintains a presence in ICS for the purpose of gaining understanding of processes and to maintain persistence. [1]
G0049: OilRig
OilRig is a suspected Iranian threat group that has targeted Middle Eastern and international victims since at least 2014. The group has targeted a variety of sectors, including financial, government, energy, chemical, and telecommunications. It appears the group carries out supply chain attacks, leveraging the trust relationship between organizations to attack their primary targets. The group works on behalf of the Iranian government based on infrastructure details that contain references to Iran, use of Iranian infrastructure, and targeting that aligns with nation-state interests.[1][2][3][4][5][6][7]
S1045: INCONTROLLER
INCONTROLLER is custom malware that includes multiple modules tailored towards ICS devices and technologies, including Schneider Electric and Omron PLCs as well as OPC UA, Modbus, and CODESYS protocols. INCONTROLLER has the ability to discover specific devices, download logic on the devices, and exploit platform-specific vulnerabilities. As of September 2022, some security researchers assessed INCONTROLLER was developed by CHERNOVITE.[1][2][3][4][5]
S0089: BlackEnergy
BlackEnergy is a malware toolkit that has been used by both criminal and APT actors. It dates back to at least 2007 and was originally designed to create botnets for use in conducting Distributed Denial of Service (DDoS) attacks, but its use has evolved to support various plug-ins. It is well known for being used during the confrontation between Georgia and Russia in 2008, as well as in targeting Ukrainian institutions. Variants include BlackEnergy 2 and BlackEnergy 3. [1]
C0028: 2015 Ukraine Electric Power Attack
2015 Ukraine Electric Power Attack was a Sandworm Team campaign during which they used BlackEnergy (specifically BlackEnergy3) and KillDisk to target and disrupt transmission and distribution substations within the Ukrainian power grid. This campaign was the first major public attack conducted against the Ukrainian power grid by Sandworm Team.
C0063: 2025 Poland Wiper Attacks
2025 Poland Wiper Attacks is a Russian state-sponsored campaign that conducted destructive cyberattacks against Polish energy infrastructure in December 2025. Targets included more than 30 wind and photovoltaic farms, a combined heat and power (CHP) plant, and a manufacturing sector company. The attacks on the distributed energy resources (DER) disrupted communications between affected facilities and the distribution system operator, but did not impact electricity generation or heat supply. Across the campaign, threat actors deployed two previously undocumented wiper tools, DynoWiper, a Windows-based wiper and LazyWiper, a PowerShell wiper, distributed via malicious Group Policy Objects. At the CHP plant, threat actors had maintained access since at least March 2025, using that foothold to obtain credentials and move laterally before attempting wiper deployment. Some reporting has assessed the activity to be consistent with Russian Federal Security Service (FSB) threat activity group Dragonfly, also tracked as STATIC TUNDRA, while other reporting attributes the destructive wiper activities to the Russian General Staff Main Intelligence Directorate (GRU) threat activity group ELECTRUM, also tracked as Sandworm Team.[1][2][3][4]
C0025: 2016 Ukraine Electric Power Attack
2016 Ukraine Electric Power Attack was a Sandworm Team campaign during which they used Industroyer malware to target and disrupt distribution substations within the Ukrainian power grid. This campaign was the second major public attack conducted against Ukraine by Sandworm Team.[1][2]
C0030: Triton Safety Instrumented System Attack
Triton Safety Instrumented System Attack was a campaign employed by TEMP.Veles which leveraged the Triton malware framework against a petrochemical organization.[1] The malware and techniques used within this campaign targeted specific Triconex Safety Controllers within the environment.[2] The incident was eventually discovered due to a safety trip that occurred as a result of an issue in the malware.[3]
All related ATT&CK context
Mitigation direction
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.1 | Current bundle | 30f9dc44b0b1… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
Booz Allen Hamilton
Booz Allen Hamilton. (2016). When The Lights Went Out. Retrieved December 18, 2024.
Open source URL -
[2]
mitre-attack T0859Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.