T0892: Change Credential
Adversaries may modify software and device credentials to prevent operator and responder access. Depending on the device, the modification or addition of this password could prevent any device configuration actions from being accomplished and may require a factory reset or replacement of hardware. These credentials are often built-in features provided by the device vendors as a means to restrict access to management interfaces.
An adversary with access to valid or hardcoded credentials could change the credential to prevent future authorized device access. Change Credential may be especially damaging when paired with other techniques such as Modify Program, Data Destruction, or Modify Controller Tasking. In these cases, a device’s configuration may be destroyed or include malicious actions for the process environment, which cannot not be removed through normal device configuration actions.
Additionally, recovery of the device and original configuration may be difficult depending on the features provided by the device. In some cases, these passwords cannot be removed onsite and may require that the device be sent back to the vendor for additional recovery steps.
A chain of incidents occurred in Germany, where adversaries locked operators out of their building automation system (BAS) controllers by enabling a previously unset BCU key. [1]
Analyst context for executives and security teams
Change Credential is an ICS lockout behavior: an adversary changes or enables device/software credentials so operators and responders can no longer manage affected systems. For executives, the material risk is not just account compromise; it is delayed recovery of controllers, HMIs, gateways, safety systems, or supporting servers when normal configuration access is blocked and vendor return, factory reset, hardware replacement, or restored configurations may be required.
Executive priority
Prioritize this where loss of engineering or operator access would extend downtime, slow safe restoration, or complicate incident command. The ATT&CK relationships make this broadly relevant across ICS assets, including workstations, HMIs, PLCs, RTUs, IEDs, historians, control/application servers, gateways, VPN servers, jump hosts, routers, switches, firewalls, safety controllers, DCS controllers, and PACs. Leadership should ask whether credential governance, gold-copy configurations, offline backups, and service redundancy are proven for the most critical devices, not merely documented.
Technical view
SOC, detection engineering, and IR teams should validate whether they can identify unauthorized credential changes, new or enabled device keys/passwords, failed operator access after a change, and management-interface activity against ICS assets. ATT&CK provides no official detection text for T0892, but it does relate DET0771, Detection of Change Credential, to this technique. Coverage should be tested against the actual management paths used for engineering workstations, HMIs, controllers, gateways, VPN/jump infrastructure, and network devices. IR playbooks should include recovery paths for devices whose credentials cannot be removed onsite.
Likely telemetry
- Device and application management logs showing credential, key, password, or access-control changes
- Authentication logs from HMIs, engineering workstations, jump hosts, VPN servers, servers, and network/security devices
- Configuration audit trails, controller/project version history, and change-management records
- Network telemetry for management sessions to ICS devices and supporting infrastructure
- Alerts or records showing operator/engineer lockout, repeated failed access, or loss of configuration capability
Detection direction
- Inventory which ICS assets support built-in, vendor, hardcoded, or device-local credentials and confirm those events are logged or otherwise observable.
- Tune for credential changes that occur outside approved maintenance windows or from unexpected management paths, while accounting for legitimate commissioning, vendor support, and maintenance activity.
- Correlate credential-change indicators with subsequent failed operator/engineer access, configuration drift, or inability to modify device settings.
- Use relationship context to prioritize monitoring around assets that can block recovery or control actions: controllers, HMIs, safety controllers, gateways, jump hosts, VPN servers, and network boundary devices.
- Treat the absence of official ATT&CK detection text as a coverage gap requiring local validation, not as evidence that standard endpoint monitoring is sufficient.
Mitigation priorities
- Enforce secure password policies for accounts where the device or software supports them, including lifecycle ownership and removal/change of default or vendor-provided credentials where possible.
- Maintain hardened, separated backups and gold-copy configurations for key ICS systems so recovery is not dependent on the compromised device remaining manageable.
- Exercise incident response plans for credential lockout scenarios, including procedures for factory reset, vendor escalation, device replacement, and restoration of known-good configurations.
- Provide redundancy for critical ICS devices and services, such as backup devices or hot-standby capability, where operational requirements justify it.
- Prioritize controls first on assets whose lockout would prevent safe operation or materially extend restoration time.
Analyst notes and limits
The supplied ATT&CK description specifically notes that Change Credential can be especially damaging when paired with Modify Program, Data Destruction, or Modify Controller Tasking, because malicious or destroyed configurations may not be removable through normal device configuration actions. The external reference describes German building automation system controllers being locked by enabling a previously unset BCU key. ATT&CK also relates this technique to the 2025 Poland Wiper Attacks campaign, but this summary does not infer broader exposure or current activity beyond the supplied relationship.
ATT&CK lists no tactic, no technique platform, and no official detection text for this object. The related detection strategy name is available, but no detection logic was supplied. Practical detection and response readiness therefore depend on local asset inventory, vendor device capabilities, logging configuration, backup quality, and tested recovery procedures.
Change Credential
Adversaries may modify software and device credentials to prevent operator and responder access. Depending on the device, the modification or addition of this password could prevent any device configuration actions from being accomplished and may require a factory reset or replacement of hardware. These credentials are often built-in features provided by the device vendors as a means to restrict access to management interfaces.
An adversary with access to valid or hardcoded credentials could change the credential to prevent future authorized device access. Change Credential may be especially damaging when paired with other techniques such as Modify Program, Data Destruction, or Modify Controller Tasking. In these cases, a device’s configuration may be destroyed or include malicious actions for the process environment, which cannot not be removed through normal device configuration actions.
Additionally, recovery of the device and original configuration may be difficult depending on the features provided by the device. In some cases, these passwords cannot be removed onsite and may require that the device be sent back to the vendor for additional recovery steps.
A chain of incidents occurred in Germany, where adversaries locked operators out of their building automation system (BAS) controllers by enabling a previously unset BCU key. [1]
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
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]
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.0 | Current bundle | 4ad2d7b8da27… |
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]
German BAS Lockout Dec 2021
Kelly Jackson Higgins. (2021, December 20). Lights Out: Cyberattacks Shut Down Building Automation Systems. Retrieved March 30, 2023.
Open source URL -
[2]
mitre-attack T0892Open 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.