DET0798: Detection of Hardcoded Credentials
DET0798 is an ICS ATT&CK detection strategy for identifying risk around hardcoded credentials: usernames/passwords, cryptographic keys/certificates, or API...
Analyst context for executives and security teams
DET0798 is an ICS ATT&CK detection strategy for identifying risk around hardcoded credentials: usernames/passwords, cryptographic keys/certificates, or API tokens embedded in software or firmware. The business issue is that these credentials may be difficult or impossible for the asset owner to change, so a single exposed secret can become a persistent access path to an operational asset.
Executive priority
Treat this as an operational resilience and governance question, not only a SOC alerting problem. Leaders should ask which ICS assets or supporting software/firmware could contain unchangeable or hard-to-change credentials, who owns compensating controls, and what evidence would be available during an incident or audit to show that access paths are understood and monitored.
Technical view
ATT&CK provides this as a detection strategy that detects T1694.002 Hardcoded Credentials, but the object does not include official detection logic, platforms, or tactics. SOC, IR, and detection engineering teams should validate whether they can identify authentication or session activity that could indicate use of embedded credentials, and whether asset, firmware/software, and credential inventories are sufficient to scope exposure when a hardcoded secret is suspected.
Likely telemetry
- Authentication and interactive session logs for relevant ICS assets and supporting systems
- Asset inventory linking devices to software or firmware versions
- Firmware/software analysis or vendor documentation indicating embedded usernames, passwords, keys, certificates, or API tokens
- Certificate/key usage records where available
- Remote access, management interface, and API access logs associated with operational assets
Detection direction
- Validate whether monitoring can distinguish expected maintenance access from unusual interactive sessions to operational assets.
- Correlate authentication events with known asset ownership, approved maintenance windows, and software/firmware versions where hardcoded credentials are suspected.
- Prioritize visibility on assets where embedded credentials cannot be changed or are infeasible to change, since normal password rotation may not remove the risk.
- Tune detections carefully: shared maintenance accounts, vendor service activity, and legacy operational workflows can create false positives without asset and change-management context.
- Document blind spots where platforms, logs, or official ATT&CK detection guidance are not specified and local engineering evidence is required.
Mitigation priorities
- Inventory ICS assets and supporting software/firmware where embedded credentials, keys, certificates, or API tokens may exist.
- Determine whether each credential can be changed, disabled, scoped, or replaced; where it cannot, define compensating controls.
- Restrict network and management access paths to affected assets using least-privilege and segmentation principles.
- Ensure incident response playbooks include steps to scope hardcoded credential exposure when unauthorized interactive sessions are suspected.
- Maintain audit-ready evidence of asset ownership, credential constraints, compensating controls, and monitoring coverage.
Analyst notes and limits
The strongest ATT&CK-supported context is the relationship to T1694.002 Hardcoded Credentials in the ICS domain. Because the detection strategy itself has no official description, detection text, platforms, or tactics, this take focuses on defensive validation, evidence readiness, and control prioritization rather than specific analytic logic.
No official detection procedure, platform scope, tactic mapping, or detailed description was supplied for DET0798. Local asset architecture, vendor documentation, firmware/software analysis, and available logs are required before judging actual exposure or detection coverage.
Detection of Hardcoded 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.002 | Hardcoded Credentials Sub-technique | This object detects Hardcoded 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 | 3ea438857d00… |
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 DET0798Open 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.