AN2048: Analytic 2048
Monitor network traffic for insecure credential use in protocols that allow unencrypted authentication.
Monitor logon sessions for insecure credential use, when feasible.
Analyst context for executives and security teams
This analytic is about finding credentials exposed through unencrypted authentication on the network. For security leaders, the practical issue is not just “bad protocol hygiene”; it is whether an attacker, insider, or misconfigured system could observe reusable credentials moving across industrial network paths and turn that into unauthorized access. In ICS environments, that can affect operational resilience because credential exposure may bridge monitoring, engineering, or control-related systems if segmentation and authentication practices are weak.
Executive priority
Prioritize this as an evidence-driven control validation item: can the organization prove that insecure credential use is either eliminated or visible where it still exists? Leaders should ask which legacy or operational protocols still permit unencrypted authentication, whether exceptions are formally risk-accepted, and whether SOC/IR teams have network and logon evidence to investigate exposed credentials quickly. This is also useful for audit and compliance readiness because it produces concrete evidence about authentication hygiene and compensating controls.
Technical view
ATT&CK provides this as an ICS detection analytic with the direction to monitor network traffic for protocols that allow unencrypted authentication and, where feasible, monitor logon sessions for insecure credential use. Because no platforms, tactics, or relationships are supplied, teams should scope validation locally: identify network zones and protocols where cleartext or otherwise unencrypted authentication may occur, confirm whether packet/flow inspection can distinguish authentication use, and correlate suspicious observations with logon session records where available.
Likely telemetry
- Network traffic captures or network security monitoring metadata that can identify protocols allowing unencrypted authentication
- Protocol-specific authentication indicators where visible in network traffic
- Logon session records, where feasible and available
- Asset, zone, and protocol inventories to determine where insecure authentication could occur
- Exception or compensating-control records for legacy systems that cannot be changed
Detection direction
- Validate that monitoring actually covers the network segments where insecure authentication could occur, especially legacy or operational enclaves.
- Tune detections around protocols that permit unencrypted authentication rather than generic network volume alone.
- Correlate network observations with logon sessions when feasible to determine whether credentials were used and which assets/accounts were involved.
- Account for false positives from approved legacy systems, maintenance activity, or documented compensating-control exceptions, but ensure those exceptions remain visible to the SOC.
- Treat lack of platform and relationship detail in the ATT&CK object as a prompt for local scoping rather than a universal detection recipe.
Mitigation priorities
- Inventory protocols and systems that allow unencrypted authentication.
- Eliminate insecure authentication where operationally feasible by moving to encrypted or otherwise protected authentication mechanisms.
- Where elimination is not feasible, restrict exposure through segmentation, access control, and documented compensating controls.
- Ensure credentials used with legacy or insecure protocols are tightly managed, monitored, and reviewed.
- Prepare IR playbooks for exposed credential handling, including account review, session investigation, and credential rotation decisions based on local evidence.
Analyst notes and limits
The official object is a detection analytic, not a technique or procedure. Its value is in validating whether insecure credential use is observable and governed in an ICS context. The supplied relationship context is empty, so no specific ATT&CK tactics, platforms, adversaries, software, or campaigns should be inferred.
Official detection text is not provided beyond the description, and no platforms, tactics, labels, aliases, or relationships are supplied. Local protocol inventory, network architecture, logging capability, and operational constraints are required to turn this into deployable detection logic.
Analytic 2048
Monitor network traffic for insecure credential use in protocols that allow unencrypted authentication.
Monitor logon sessions for insecure 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 | 18251cd1f084… |
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 AN2048Open 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.