DET0905: Detection of Insecure Credentials
DET0905 is a detection strategy for identifying insecure credentials in ICS environments. Its business importance is that default or hard-coded credentials...
Analyst context for executives and security teams
DET0905 is a detection strategy for identifying insecure credentials in ICS environments. Its business importance is that default or hard-coded credentials can give an adversary a practical path to maintain access or move between systems and devices, which can affect operational resilience and cyber-physical risk. Because the ATT&CK entry provides no platform, tactic, or detection detail, organizations should treat this as a prompt to validate credential exposure and monitoring across their own ICS asset base rather than as a ready-made analytic.
Executive priority
Security leaders should ask whether the organization can prove that default and hard-coded credentials are known, risk-ranked, monitored, and reduced where feasible. This matters for incident decision-making, compliance evidence, and operational continuity because insecure credentials may enable persistence or lateral movement in control environments. Priority should go to assets or devices where credential changes are difficult because of control-process impact.
Technical view
SOC, detection engineering, and IR teams should map this strategy to ATT&CK technique T1694, Insecure Credentials. Validate whether the environment has an inventory of devices, software, and systems with default or hard-coded credentials; whether authentication activity involving those credentials can be observed; and whether exceptions are documented where credentials cannot be changed easily. Since ATT&CK supplies no official detection logic or platforms for DET0905, local architecture and asset knowledge are required to define analytics.
Likely telemetry
- ICS asset and software inventory identifying devices with default or hard-coded credentials
- Credential management records, exception registers, and configuration baselines
- Authentication and access logs where available for systems, devices, and management interfaces
- Network session or remote access records that can show credential use between systems or devices
- Configuration assessment or audit outputs documenting unchanged default credentials
Detection direction
- Validate whether known default credentials are detectable when used, not only whether they are listed in policy.
- Correlate credential findings with asset criticality and paths that could support persistence or lateral movement.
- Tune alerts to distinguish approved maintenance or vendor support activity from unexpected credential use.
- Look for blind spots where devices do not produce usable authentication logs or where hard-coded credentials cannot be rotated.
- Use the relationship to T1694 to keep the analytic focused on insecure credentials rather than broad identity failures.
Mitigation priorities
- Inventory systems, devices, and software that may contain default or hard-coded credentials.
- Change default credentials where operationally safe and supported.
- Document and risk-accept credentials that cannot be changed because of control-process impact.
- Restrict and monitor access paths to assets with unavoidable hard-coded or difficult-to-change credentials.
- Maintain evidence for audits and incident response showing credential status, exceptions, monitoring coverage, and compensating controls.
Analyst notes and limits
The supplied ATT&CK object is a detection strategy in the ICS domain and only states that it detects T1694, Insecure Credentials. The related technique explains that insecure credentials may be default or hard-coded and may support persistence or lateral movement. Practical detection therefore depends heavily on local asset inventory, credential management, and available authentication telemetry.
ATT&CK provides no official description, detection text, tactics, platforms, aliases, or labels for DET0905 in the supplied fields. This take does not assert active exploitation, attribution, affected products, or guaranteed detection coverage. Organizations must validate applicability against their own ICS architecture and logging capabilities.
Detection of Insecure Credentials
No official description is available in the imported ATT&CK source object.
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.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| ICS | T1694 | Insecure Credentials | This object detects Insecure Credentials. |
All related ATT&CK context
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 | 3617aac9342b… |
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]
mitre-attack DET0905Open 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.