AN1930: Analytic 1930
Monitor network traffic for hardcoded credential use in protocols that allow unencrypted authentication. Monitor logon sessions for hardcoded credential use, when feasible.
Analyst context for executives and security teams
This analytic matters because hardcoded credentials used over unencrypted authentication can turn an operational environment into a shared-password problem: one exposed credential may enable repeated access across systems. For security leaders, the decision value is not just whether a rule exists, but whether the organization can see credential reuse in network traffic and logon activity without disrupting sensitive ICS operations.
Executive priority
Prioritize this as a visibility and control-validation question for ICS environments: do teams know where unencrypted authentication is still present, which accounts appear to be embedded or repeatedly reused, and whether evidence exists to support incident response or audit review? The business risk is operational resilience—shared or hardcoded credentials can complicate containment, accountability, and recovery decisions.
Technical view
SOC, detection, and IR teams should validate whether network monitoring can identify credential use in protocols that allow unencrypted authentication, and whether logon session records can be correlated to recurring account use patterns when feasible. Because the ATT&CK object supplies no platforms, tactics, or specific detection logic, teams should avoid assuming coverage and instead test available telemetry against local ICS assets, authentication paths, and account inventories.
Likely telemetry
- Network traffic records for protocols that allow unencrypted authentication
- Packet or application-layer inspection data where permitted and operationally safe
- Authentication and logon session records
- Account, service account, and asset inventories used to distinguish expected from suspicious repeated use
- ICS network sensor logs or security monitoring records, if deployed
Detection direction
- Validate that monitoring exists on network segments where unencrypted authentication may occur; absence of sensor placement is a likely blind spot.
- Correlate observed credential use with known accounts, service accounts, and authorized embedded credentials to reduce false positives.
- Look for repeated use of the same credential or account across systems where that pattern is not expected.
- Confirm whether logon session monitoring is feasible in the environment; some ICS assets may provide limited or inconsistent logs.
- Treat findings as control-validation leads, not proof of compromise, unless supported by additional local evidence.
Mitigation priorities
- Inventory systems and protocols where unencrypted authentication is still used.
- Identify accounts that appear hardcoded, shared, or repeatedly reused across assets.
- Prioritize removal or reduction of hardcoded credentials where operationally feasible.
- Strengthen account governance, credential rotation, and least-privilege controls for accounts that cannot be immediately removed.
- Use findings to support compliance evidence, incident response planning, and longer-term modernization of insecure authentication paths.
Analyst notes and limits
This is an ICS ATT&CK detection analytic focused on monitoring network traffic and, where feasible, logon sessions for hardcoded credential use in unencrypted authentication. There is no relationship context, platform list, tactic mapping, or official detection logic supplied, so local architecture and telemetry determine practical coverage.
The supplied object is sparse: platforms and tactics are not specified, official detection content is not provided, and no relationships are supplied. This take does not assert active exploitation, attribution, impact, or guaranteed detection coverage.
Analytic 1930
Monitor network traffic for hardcoded credential use in protocols that allow unencrypted authentication. Monitor logon sessions for hardcoded credential use, when feasible.
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.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
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 | 9fbbbee9a1ee… |
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 AN1930Open 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.