DET0350: Detecting Downgrade Attacks
DET0350 is a detection strategy for downgrade attacks, where an adversary may push systems or features into older, weaker, or less-protected modes. The bus...
Analyst context for executives and security teams
DET0350 is a detection strategy for downgrade attacks, where an adversary may push systems or features into older, weaker, or less-protected modes. The business issue is not just software age; it is whether backward compatibility can silently undermine security controls that leaders believe are in force.
Executive priority
Treat this as a control-assurance question: can the organization prove that critical systems are not being forced into outdated or vulnerable modes? This matters for operational resilience, audit evidence, and incident response because downgrade behavior can weaken defenses before other activity occurs. Security leaders should ask where backward compatibility is allowed, who monitors version or protocol changes, and whether exceptions are reviewed as risk decisions.
Technical view
The detection object has no official ATT&CK detection text or platform list, but it is related to T1689 Downgrade Attack under defense-impairment, with related platforms macOS, Windows, and Linux. SOC and detection teams should validate visibility into events that show security-relevant versions, feature states, protocol negotiation, interpreter or runtime version selection, and configuration changes that reduce protection levels. IR teams should treat unexpected downgrades as possible defense-impairment context and investigate what occurred immediately before and after the change.
Likely telemetry
- Endpoint configuration and policy change logs
- Operating system and application version inventory
- Process execution telemetry showing interpreter or runtime versions where available
- Authentication, service, or protocol negotiation logs where versions or modes are recorded
- Security control status and tamper/configuration events
Detection direction
- Baseline expected versions, protocol modes, and security feature states for critical assets, then alert on unauthorized or unusual movement to older or weaker modes.
- Correlate downgrade indicators with process execution, administrative changes, and security-control status changes to reduce noise from legitimate maintenance.
- Pay special attention to backward-compatibility exceptions, legacy systems, and temporary operational workarounds, which can become blind spots.
- Because the official detection text is not provided, local engineering must define what constitutes a downgrade for each operating system, application, protocol, or control surface in scope.
Mitigation priorities
- Inventory where backward compatibility or legacy modes are enabled and document business ownership for exceptions.
- Prioritize disabling outdated or vulnerable modes where operationally feasible, especially on critical systems.
- Use configuration management and change control to make downgrades visible and reviewable.
- Ensure SOC and IR playbooks treat unexpected downgrade activity as potential defense impairment rather than routine configuration drift.
Analyst notes and limits
This take is derived from the detection strategy metadata and its relationship to T1689 Downgrade Attack. The supplied relationship indicates defense-impairment relevance and macOS, Windows, and Linux applicability for the related technique, but the detection strategy itself does not specify platforms, tactics, description, or detection logic.
ATT&CK provides no official description or detection guidance for DET0350 in the supplied fields. The guidance here is therefore conservative and focused on validation direction, telemetry classes, and control questions rather than specific analytics or guaranteed detections. Local environment data is required to define normal version, protocol, and security-feature behavior.
Detecting Downgrade Attacks
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 |
|---|---|---|---|
| Enterprise | T1689 | Downgrade Attack | This object detects Downgrade Attack. |
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 | 40c341a26bb8… |
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 DET0350Open 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.