Cyber Resilience

← ISO 27001 Annex A

A.5.26 Organizational

Response to information security incidents

AttributesCorrective C·I·A Respond Recover Information security event management Defence

Structured attributes from ISO/IEC 27002:2022 — control type · CIA properties · cybersecurity concept · operational capability · security domain. What do these mean?

The implementation guidance for this control is published in ISO/IEC 27002:2022 and is not reproduced here. The structured attributes and the cross-walk rationales below are derived facts and our own AI-authored analysis.

Mapped NIST 800-53 r5 controls (23)

Our AI-authored reading (authority llm_unverified, under review) of how this ISO control and each NIST 800-53 control relate. Not an ISO or NIST product.

Direction: ← other covers this; → this covers other (F/M/P = full / mostly / partial). gov = governs / implements (a mandate, not coverage).

AU-6←P IR-2←P IR-3←P IR-4←F →M IR-5←P →P IR-6←M →M IR-7←P IR-8←M →M IR-9→P SI-2←P

Why these map — AI rationale (under review)

IR-4mostlyaligns with — Both controls require a structured, team-based process to contain, investigate, escalate, and close security incidents while coordinating with internal and external parties.
IR-4mostlycovers — A.5.26's mandate for efficient/effective incident response directly accounts for the core handling lifecycle (prep/detect/analyze/contain/eradicate/recover) and coordination elements of IR-4, but leaves a residual on the explicit incorporation of lessons learned into procedures/training/tests that sits outside its primary response focus.
IR-6mostlycovers — A.5.26's incident response process (including detection, reporting, and handling) accounts for the bulk of IR-6's internal reporting requirements, but leaves a residual on the exact external reporting destinations and parameters that IR-6 explicitly mandates.
IR-8mostlyaligns with — The ISO control's requirement to establish, communicate, and execute incident response procedures directly supports the NIST mandate for a documented incident response plan.
IR-8mostlycovers — A.5.26's mandate to ensure efficient/effective incident response (including planning elements) accounts for the bulk of IR-8's plan-development requirements, but leaves a residual on explicit high-level organizational-fit and mission-specific tailoring details not required by the ISO control.
IR-5partialaligns with — Logging all response activities and performing post-incident analysis provide the monitoring and tracking functions that IR-5 expects for incident oversight.
IR-5partialcovers — A.5.26's broad incident response process (including detection, reporting, assessment and response activities) addresses a slice of incident monitoring and documentation but leaves the bulk of ir-5's dedicated, ongoing tracking requirements outside its scope
IR-6partialaligns with — The ISO guidance to communicate incident details to relevant internal and external parties aligns with NIST's requirement for timely incident reporting.
IR-9partialaligns with — Collecting evidence and conducting forensic analysis under the ISO control supports the information-spillage handling and evidence-preservation objectives of IR-9.
IR-9partialcovers — A.5.26's general incident response process covers the assignment of responsibility, identification, alerting, and isolation steps for information spillage as a specific incident type, but leaves substantial residual (e.g., spillage-specific communication channels, eradication, and recovery procedures unique to IR-9) uncovered.
SI-2partialaligns with — Identifying and remediating vulnerabilities or weaknesses revealed by the incident maps to the flaw-remediation activities required by SI-2.
SI-2covers — Assessed as NOT holding by the authoring instrument at v1.22-2026-08-29. This row records a tested non-relation; it is not a graded claim and carries no rationale, because the instrument produced none when the verb did not hold.

Aligned NIST CSF 2.0 outcomes (29)

NIST CSF 2.0 outcomes this ISO control aligns with — our AI-authored analysis (authority llm_unverified, under review).

Direction: ← other covers this; → this covers other (F/M/P = full / mostly / partial). gov = governs / implements (a mandate, not coverage).

ID.RA-01gov RS.AN-03gov RS.AN-06gov RS.AN-07gov RS.CO-02gov RS.CO-03gov RS.MA-01gov RS.MA-04gov RS.MA-05gov RS.MI-01gov

Why these map — AI rationale (under review)

RS.AN-03mostlyaligns with — Post-incident root-cause analysis and forensic examination are required by the ISO guidance and directly support the CSF analysis outcome.
RS.CO-02mostlyaligns with — The ISO control mandates notifying internal and external stakeholders of incidents in accordance with the need-to-know principle.
RS.CO-03mostlyaligns with — Coordination and information sharing with authorities, suppliers, clients, and other external parties are explicitly required to improve response effectiveness.
RS.MA-01mostlyaligns with — Both require coordinated execution of the incident response plan with relevant third parties once an incident is declared.
RS.MI-01mostlyaligns with — The ISO control explicitly directs containment actions to limit the spread of incident consequences, matching the CSF containment outcome.
ID.RA-01partialaligns with — The ISO control requires identification and management of vulnerabilities and weaknesses that contributed to or failed to prevent the incident.
RS.MA-05partialaligns with — Formal closure of the incident and transition to normal operations align with the CSF outcome that applies criteria for initiating recovery.
ID.RA-01implements — Assessed as NOT holding by the authoring instrument at v1.22-2026-08-29. This row records a tested non-relation; it is not a graded claim and carries no rationale, because the instrument produced none when the verb did not hold.
RS.AN-03implements — A.5.26's defined purpose is to ensure an efficient and effective incident response process; performing analysis to establish what happened and the root cause (RS.AN-03) is a core operational activity that directly gives effect to that purpose within the incident-response domain.
RS.CO-02implements — A.5.26's incident response process directly operationalizes notification of internal and external stakeholders as a core part of effective response
RS.CO-03implements — A.5.26's incident response process directly operationalizes the sharing of incident information with stakeholders that RS.CO-03 requires; sharing is a core, named element of effective response within the incident-response domain, though the control does not cite the exact CSF outcome.
RS.MA-01implements — A.5.26's defined purpose is to ensure an efficient/effective incident response; executing the incident response plan (RS.MA-01) is exactly the operational effect that gives direct life to this governance outcome.
RS.MA-05implements — A.5.26's operational response activities (including recovery initiation) give effect to the RS.MA-05 criteria within the shared incident-response domain, but the ISO control does not name or cite the specific CSF criteria.
RS.MI-01implements — A.5.26's defined purpose is to ensure an efficient/effective incident response process; containment (RS.MI-01) is a core operational step that the response process directly gives effect to within the incident-management domain

Related OWASP ASVS 5.0 requirements (6)

Application-security verification requirements (OWASP ASVS 5.0) this ISO control aligns with; links open the ASVS chapter. Our AI-authored analysis (authority llm_unverified, under review) — many ISO controls have no ASVS counterpart.

Direction: ← other covers this; → this covers other (F/M/P = full / mostly / partial). gov = governs / implements (a mandate, not coverage).

V16.2.1←P V16.3.3←M V16.3.4←M V16.4.2←P V16.4.3←P V16.5.3←P

Related weaknesses / CWE (4)

Weakness classes this ISO control helps prevent or mitigate — our AI-authored analysis (authority llm_unverified, under review).

Direction: ← other covers this; → this covers other (F/M/P = full / mostly / partial). gov = governs / implements (a mandate, not coverage).

CWE-200→P CWE-284→P CWE-508→P

Why these map — AI rationale (under review)

CWE-400nonedetects — Escalation procedures and business-continuity invocation help restore service availability after resource-exhaustion incidents.
CWE-200mitigates — Evidence collection, need-to-know communication, and forensic analysis limit further exposure of sensitive information once an incident is detected.
CWE-284finds — Formal incident containment and post-incident root-cause analysis reduce the window during which improper access control flaws can be exploited and ensure discovered authorization weaknesses are corrected.
CWE-508finds — Incident-response procedures help contain and eradicate non-replicating malicious code.

Mitigated MITRE ATT&CK techniques (2125)

Adversary techniques (MITRE ATT&CK Enterprise) this ISO control helps mitigate; links open attack.mitre.org. Our AI-authored analysis (authority llm_unverified, under review).

Direction: ← other covers this; → this covers other (F/M/P = full / mostly / partial). gov = governs / implements (a mandate, not coverage).

T1001←M →M T1001.001←M →M T1001.002←M →M T1001.003←M →M T1003←P →M T1003.001←P →M T1003.002→M T1003.003←M →M T1003.004→M T1003.005→M T1003.006→M T1003.007→M T1003.008→M T1005→M T1006←M →M T1008→M T1011→M T1011.001→P T1014←M →M T1020→M T1020.001→M T1021→M T1021.001→M T1021.002→M T1021.003→M T1021.004→M T1021.005→M T1021.006→M T1021.007→M T1021.008→M T1025→M T1027→M T1027.001←M T1027.002←M T1027.003←M →M T1027.004→M T1027.005←M →M T1027.006←M →M T1027.007←M →P T1027.008←M T1027.009←M →P T1027.010←M →M T1027.011←M →P T1027.012→P T1027.013←M →P T1027.014←M →M T1027.015→P T1027.016←M T1027.017→M T1027.018←M →M T1030←M →P T1036←M →M T1036.001→M T1036.002←M →M T1036.003←M →M T1036.004←M →M T1036.005←M →M T1036.006→M T1036.007←M →M T1036.008←M →M T1036.009←M →M T1036.010→M T1036.011←M →M T1036.012←M T1037→M T1037.001→M T1037.002→M T1037.003→M T1037.004→M T1037.005→M T1039→M T1040→M T1041→M T1046→P T1047→M T1048←M →M T1048.001→M T1048.002→M T1048.003→M T1052→P T1052.001→M T1053→M T1053.002→M T1053.003→M T1053.005←M →M T1053.006→M T1053.007→M T1055←M →M T1055.001←M →M T1055.002←M →M T1055.003←M →M T1055.004←M →M T1055.005←M →M T1055.008←M →M T1055.009←M →M T1055.011←M →M T1055.012←M →M T1055.013←M →M T1055.014←M →M T1055.015←M →M T1056→M T1056.001→M T1056.002→M T1056.003→M T1056.004→M T1057→M T1059→M T1059.001→M T1059.002→M T1059.003→M T1059.004→M T1059.005→M T1059.006→M T1059.007→M T1059.008←M →M T1059.009→M T1059.010→M T1059.011→M T1059.012→M T1059.013→M T1068→M T1069.003→M T1070←M →M T1070.003←M →M T1070.004←M →M T1070.005→M T1070.006←M →M T1070.007←M →M T1070.008←M →M T1070.009←M →M T1070.010←M →M T1071←M →P T1071.001←M →P T1071.002→M T1071.003→M T1071.004←M →M T1071.005←M →P T1072←P →M T1074→M T1074.001→M T1074.002←P →M T1078←P →M T1078.001→M T1078.002→M T1078.003→M T1078.004→M T1080→M T1087→M T1087.002→P T1087.003→M T1090←M →M T1090.001←M →M T1090.002←M →M T1090.003←M →M T1091→M T1092→M T1095←M →P T1098→M T1098.001→M T1098.002←P →M T1098.003→M T1098.004→M T1098.005←M →M T1098.006→M T1098.007→M T1102←M →M T1102.001←M →P T1102.002←M →M T1102.003←M →M T1104←M →P T1105→M T1106→M T1110→M T1110.001→M T1110.002→M T1110.003→M T1110.004→M T1111←M →M T1112←P →M T1113→M T1114→M T1114.001→M T1114.002→M T1114.003←P →M T1115→M T1119→M T1123→M T1125→M T1127←M →M T1127.001←M →M T1127.002→M T1127.003←M →M T1129→M T1132←M T1132.001←M →M T1132.002←M →P T1133←M →M T1134←M →M T1134.001←M →M T1134.002→M T1134.003→M T1134.004←M →P T1134.005←M →M T1136→M T1136.001→M T1136.002→M T1136.003→M T1137→M T1137.001→M T1137.002→M T1137.003→M T1137.004→M T1137.005→M T1137.006→M T1140←M T1176→M T1176.001→M T1176.002→M T1185←M →M T1187→M T1189→M T1190→P T1195→P T1195.001→P T1195.002→P T1195.003→P T1197←M →M T1199→P T1201→M T1202←M T1203→M T1204→M T1204.001→M T1204.002→M T1204.003→M T1204.004←M →M T1204.005→M T1205←M →M T1205.001←M →M T1205.002←M →P T1207←M →M T1210→M T1211→M T1212→M T1213→M T1213.001→P T1213.002→M T1213.003→M T1213.004→M T1213.005→M T1213.006→M T1216←M →M T1216.001←M →P T1216.002→P T1217→M T1218←M →M T1218.001→M T1218.002→P T1218.003→M T1218.004→M T1218.005←M →M T1218.007←M →M T1218.008←M →M T1218.009→M T1218.010←M →M T1218.011←M →M T1218.012←M →M T1218.013←M →M T1218.014→M T1218.015→M T1219←M →M T1219.002→M T1219.003←M →M T1220←M →M T1221←M →P T1222←M →M T1222.001←P T1222.002←M →M T1480.001→P T1480.002→M T1484←M →M T1484.001←P →M T1484.002←M →M T1485→M T1485.001←P →M T1486→F T1489→M T1490←M →M T1491→M T1491.001→M T1491.002→M T1495←P →M T1496→M T1496.001←P →M T1496.002→M T1496.003→M T1496.004→M T1497←M T1497.001←M T1497.002←M T1498←M →M T1498.001←M →M T1498.002←P →P T1499←M →P T1499.001←M →P T1499.002→P T1499.003→P T1499.004→P T1505→M T1505.001→M T1505.002→M T1505.003←P →M T1505.004→M T1505.005→M T1505.006→M T1518→M T1518.001→P T1525→M T1528→M T1529→M T1530→M T1531→M T1534→M T1535←M →P T1537←M →M T1538→P T1539←F →M T1542←M →M T1542.001←M →M T1542.002←M →M T1542.003←M →M T1542.004←M →M T1542.005→M T1543→M T1543.001→M T1543.002→M T1543.003←M →M T1543.004→M T1543.005→M T1546→M T1546.001→M T1546.002→M T1546.003←M →M T1546.004→M T1546.005→M T1546.006→M T1546.007→M T1546.008→M T1546.009→M T1546.010→M T1546.011←P →M T1546.012←M →M T1546.013→M T1546.014→M T1546.015→M T1546.016→M T1546.017→M T1546.018→M T1547→M T1547.001→M T1547.002→M T1547.003→M T1547.004→M T1547.005→M T1547.006←M →M T1547.007→M T1547.008→M T1547.009→M T1547.010→M T1547.012←M →M T1547.013→M T1547.014→M T1547.015→M T1548→M T1548.001→M T1548.002←M →M T1548.003→M T1548.004→M T1548.005←M →M T1548.006←M →M T1550←F →M T1550.001←F →M T1550.002←F →M T1550.003←F →M T1550.004→M T1552→M T1552.001→M T1552.002→M T1552.003→M T1552.004→M T1552.005→M T1552.006→M T1552.007→M T1552.008→M T1553→M T1553.001←F →M T1553.002←M →M T1553.003←M →M T1553.004←P →M T1553.005←M →M T1553.006←M →M T1554→M T1555→M T1555.001→M T1555.002→M T1555.003→M T1555.004→M T1555.005→M T1555.006→M T1556←M →M T1556.001←M →M T1556.002→M T1556.003←M →M T1556.004→M T1556.005→M T1556.006←M →M T1556.007←M →P T1556.008→M T1556.009←M →M T1557→M T1557.001→M T1557.002→M T1557.003→M T1557.004→P T1558→M T1558.001←P →M T1558.002→M T1558.003→M T1558.004→M T1558.005→P T1559→M T1559.001→M T1559.002→M T1559.003→P T1560→M T1560.001→M T1560.002→M T1560.003→M T1561←P →M T1561.001→M T1561.002←M →M T1563→M T1563.001→M T1563.002←M →M T1564←M →M T1564.001→M T1564.002→M T1564.003→P T1564.004→M T1564.005→M T1564.006→M T1564.007→M T1564.008→M T1564.009→M T1564.010→M T1564.011→M T1564.012→M T1564.013→M T1564.014→P T1565→M T1565.001→M T1565.002→M T1565.003→M T1566→M T1566.001→M T1566.002→M T1566.003←M →M T1566.004→M T1567→M T1567.001→M T1567.002→M T1567.003→M T1567.004←M →M T1568←M →M T1568.001←M →P T1568.002←M →P T1568.003←P →M T1569→M T1569.001→P T1569.002→M T1569.003→M T1570→M T1571←M →P T1572←M →M T1573.001→M T1574←M →M T1574.001←M →M T1574.004←M →M T1574.005→M T1574.006←M →M T1574.007→M T1574.008→M T1574.009→M T1574.010→M T1574.011→M T1574.012←P →P T1574.013←M →M T1574.014→M T1578←M →M T1578.001←M →M T1578.002←M →M T1578.003←M →M T1578.004←M →M T1578.005←M →M T1583.001→P T1583.003→M T1583.005→M T1583.006→P T1583.007←M →M T1583.008←M →M T1584→M T1584.001←M →P T1584.002→M T1584.003→M T1584.004→M T1584.005→M T1584.006→M T1584.007←M →M T1584.008→P T1585.001→M T1585.002→M T1586→M T1586.001→M T1586.002→M T1586.003→M T1587.001→M T1587.002→M T1587.003→P T1587.004→M T1588→P T1588.001←M →P T1588.002→M T1588.003→M T1588.004→M T1588.005→M T1589→M T1589.001→M T1589.003→P T1591.004→M T1592.002→P T1593.001→P T1595.001→P T1595.002→P T1595.003→P T1598→M T1598.001→P T1598.002→P T1598.003→P T1598.004→P T1599←M →M T1599.001←M →M T1600←P →M T1600.001←P →M T1601→M T1601.001←M →M T1601.002←M →M T1602→P T1602.001→M T1602.002→M T1606→M T1606.001←F →M T1606.002←M →M T1608→P T1608.003→P T1608.004→M T1608.005→P T1608.006→P T1609→M T1610←P →M T1611←P →M T1612←M →P T1619→M T1620←M →M T1621←M →M T1622←M T1647←P →M T1648→M T1649→M T1650→M T1651→M T1653←P →M T1654→P T1657→M T1659→P T1665←M →M T1666←M →P T1667←P →M T1668←P T1669→M T1671→P T1675→M T1677→P T1678←M T1679←P →M T1681→M T1683→M T1683.002→P T1684→M T1684.001→F T1684.002←M →M T1685←M →M T1685.001←M →M T1685.002←M →M T1685.003←M →M T1685.004←M →M T1685.005←M →M T1685.006←M →M T1686←M →M T1686.001←M →M T1686.002←M →M T1686.003←M →M T1687→M T1688←M →M T1689←P →M T1690←M →M

Why these map — AI rationale (under review)

T1001detects — A.5.26 requires a competent incident response team to handle incidents (including detection/escalation of security events that have occurred), which surfaces some T1001-obfuscated C2 once it triggers an observable incident but does not mandate or perform proactive detection of the obfuscation technique itself.
T1001prevents — A.5.26 requires a designated competent team to respond under communicated procedures — containment and eradication of an event ALREADY UNDERWAY, which is the act `responds` names. The ransomware ran; responding bounds its spread and removes the foothold. `mostly`, with the remainder that marks the boundary to `recovers`: data encrypted BEFORE containment is not un-encrypted by responding to the incident
T1001responds — A.5.26 requires a designated competent team to respond to incidents once underway (containment, eradication, evidence collection, escalation, logging, communication, forensic analysis, post-incident root-cause work and vulnerability management), which directly addresses an in-progress T1001-obfuscated C2 channel as an information security incident.
T1001.001prevents — A.5.26's designated competent team responding to an incident (including containment, evidence collection, forensic analysis, root-cause identification, and vulnerability/weakness management) stops the junk-data C2 channel from continuing, which is what prevents asserts for a technique already in flight.
T1001.001responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment, evidence collection, logging, escalation, communication, coordination, forensic analysis, root-cause identification, and post-incident vulnerability management, which directly addresses an in-flight C2 technique like junk data that has already enabled undetected communication.
T1001.002detects — A.5.26 requires monitoring for anomalous behaviour and a designated team to respond to incidents (including detection, containment, and analysis), which can surface steganographic C2 as an information security incident once underway, but the clause sets scope by business requirements and does not mandate instrumentation that reliably catches hidden data in transit.
T1001.002prevents — A.5.26's designated competent team responding to an incident (including containment, evidence collection, forensic analysis, root-cause identification, and vulnerability/weakness management) directly stops the ongoing steganographic C2 channel from continuing to operate once it is recognized as an incident.
T1001.002responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment, evidence collection, escalation, logging, communication, coordination, forensic analysis, root-cause review and vulnerability remediation — all of which directly address an active T1001.002 C2 channel that has already been established.
T1001.003detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause identification and communicating details once an incident is underway; impersonation of protocols/services (e.g. fake SSL/TLS or manipulated HTTP) produces observable network artifacts that can be surfaced by competent incident response when it reaches the organization's estate, but pre-compromise acquisition and much of the C2 blending occurs outside monitored boundaries with no guaranteed event on the estate.
T1001.003prevents — A.5.26's designated competent team following defined procedures (including containment, evidence collection, escalation, forensic analysis, root-cause identification, and vulnerability/weakness management) prevents the impersonation technique from continuing to succeed once detected, by stopping the C2 channel and addressing the enabling flaws.
T1001.003responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, analyze root cause, and close an information security incident once underway, which directly matches the act of responding to T1001.003 C2 traffic that has already begun blending with legitimate protocols.
T1003detects — A.5.26 explicitly requires a designated competent team to respond to incidents (including detection triggers, evidence collection, logging, and post-incident root-cause analysis), which surfaces T1003 when it occurs as part of an information security incident.
T1003prevents — A.5.26's designated competent team responding to an incident (including containment, evidence collection, escalation, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that allowed the incident) stops the T1003 technique from continuing or recurring on affected systems, with the named remainder being successful dumps that complete before response begins.
T1003recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability management in j, forensic analysis, and formal closure) act after the credential-dumping technique has run and its artifacts (stolen hashes/passwords) exist, enabling recovery actions that limit further impact and restore secure state.
T1003responds — A.5.26 requires a competent team to respond to incidents (including containment, eradication, evidence collection, logging, escalation, and post-incident root-cause/vulnerability management once underway), which directly matches the act of responding to a realized T1003 credential-dumping event; the named remainder is that some post-incident steps (e.g., forensic analysis) are 'as required' rather than mandatory for every case.
T1003.001detects — A.5.26 requires a designated competent team to respond to incidents (including detection via reported anomalies, evidence collection, logging, forensic analysis, and post-incident root-cause identification), which surfaces LSASS credential dumping once underway or reported.
T1003.001prevents — A.5.26's designated competent team, containment (a), forensic collection/analysis (b/h), root-cause identification (i), and explicit management of vulnerabilities/weaknesses that failed to prevent the incident (j) stop LSASS credential dumping from recurring as a repeatable technique.
T1003.001recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability management in j, formal closure) enable recovery of credentials and systems after LSASS dumping has occurred, with the named remainder being that it does not itself restore the harvested credentials or undo lateral movement already completed.
T1003.001responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, analyze root cause/vulnerabilities, and formally close an information security incident once underway, which directly matches the `responds` verb for a credential-access technique that has already executed.
T1003.002detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause, and post-incident review) can surface the credential-dumping technique or its artifacts once it has run on the organization's estate, but pre-compromise reconnaissance, in-memory execution without observable effects, or attacks on non-monitored systems fall outside its scope.
T1003.002prevents — A.5.26 requires a designated competent team to respond under communicated procedures — containment and eradication of an event ALREADY UNDERWAY, which is the act `responds` names. The ransomware ran; responding bounds its spread and removes the foothold. `mostly`, with the remainder that marks the boundary to `recovers`: data encrypted BEFORE containment is not un-encrypted by responding to the incident
T1003.002recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability management in j, formal closure) enable recovery actions that restore credential hygiene and limit further use of dumped SAM material after the technique has run.
T1003.002responds — A.5.26 explicitly requires a designated competent team to respond to incidents (including containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis, and managing related vulnerabilities/weaknesses) once an information security incident such as credential dumping via T1003.002 is underway.
T1003.003detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause identification) can surface the NTDS access/copy once it has occurred on the organization's estate, but the technique's pre-compromise reconnaissance and external-tool execution (e.g. on a domain controller or via backups) often leaves no observable event inside the control's defined scope until after impact.
T1003.003prevents — A.5.26 requires a designated competent team to respond under communicated procedures — containment and eradication of an event ALREADY UNDERWAY, which is the act `responds` names. The ransomware ran; responding bounds its spread and removes the foothold. `mostly`, with the remainder that marks the boundary to `recovers`: data encrypted BEFORE containment is not un-encrypted by responding to the incident
T1003.003recovers — A.5.26's post-incident steps (forensic analysis, root-cause identification, vulnerability management, and formal closure) enable recovery actions that restore credential hygiene and domain integrity after the NTDS theft has occurred.
T1003.003responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, escalate, close, and perform post-incident/root-cause analysis on an information security incident once underway, which directly matches the definition of responds for a credential-dumping technique that has already executed.
T1003.004detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause identification and communicating the incident, all of which can surface LSA secret dumping when it occurs on an organizational Windows host; however the pre-compromise acquisition of SYSTEM-level access and the technique's execution on the local registry/memory leave a large slice unseen by organizational response procedures.
T1003.004prevents — A.5.26's designated competent team, containment (a), forensic/root-cause analysis (h/i), vulnerability/weakness management (j), and coordination directly stop the LSA-secrets technique from completing or recurring when it is already underway or has just succeeded, which satisfies the `prevents` verb per the event-lane anchors (cf. A.5.26 vs T1486 = responds mostly; the same clause's post-incident actions prevent the technique from succeeding again).
T1003.004recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability management, formal closure, and coordination) enable recovery of the credential material and affected accounts after the LSA-secrets technique has run, with the named remainder being any already-compromised external systems or data that cannot be fully restored by the incident-response process alone.
T1003.004responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, analyze root cause, and close an information security incident once it is underway, which matches the `responds` verb against an in-progress credential-dumping technique such as T1003.004.
T1003.005detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause identification and communicating the incident once it is underway; these surface the credential-access technique when it triggers an observable incident on the organization's estate, but pre-compromise reconnaissance or extraction outside monitored scope (e.g. on non-incident systems) is unseen, matching the partial rung set by A.5.26 vs T1595.002.
T1003.005prevents — A.5.26's incident response procedures (containment, escalation, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that allowed the incident) stop cached-credential theft techniques from completing or recurring once they have begun, which satisfies the `prevents` verb for the bulk of the technique's realized impact; the named remainder is that the control activates only after initial access has already occurred.
T1003.005recovers — A.5.26's post-incident analysis, root-cause identification, vulnerability/weakness management (item j), and formal closure directly enable recovery of credentials, systems, and trust after the T1003.005 extraction has occurred.
T1003.005responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, analyze root cause/vulnerabilities/weaknesses that enabled the incident, and formally close it once addressed — which is the definition of responding to an already-underway technique such as credential access.
T1003.006detects — A.5.26's monitoring, logging (d), evidence collection (b), forensic analysis (h), and post-incident root-cause steps (i) can surface DCSync when it occurs on the organization's estate and is noticed via anomalous replication or related indicators, but the technique can also be performed from outside the organization or on unmanaged infrastructure where none of the response activities engage.
T1003.006prevents — A.5.26 requires a designated competent team to respond to incidents once underway (containment, eradication, root-cause analysis, vulnerability/weakness remediation), which stops the DCSync technique from continuing or recurring after initial execution — matching the prevents verb per the event-lane anchors that separate it from responds.
T1003.006recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability management in j, forensic work, formal closure) enable recovery of the credential material and environment after DCSync has succeeded, matching the recovers verb in the event-lane anchors (e.g. A.5.26 vs T1486).
T1003.006responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, analyze root cause, and close an information security incident once underway, which directly matches the act of responding to a DCSync technique that has already executed.
T1003.007detects — A.5.26's response activities include collecting evidence, logging, forensic analysis and post-incident root-cause work that can surface the technique once it has run on the organization's Linux estate; the remainder is pre-compromise reconnaissance or execution outside monitored scope where no incident is triggered.
T1003.007prevents — A.5.26's designated competent team responding to an incident (including containment, evidence collection, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that enabled it) stops the credential-gathering technique from continuing or recurring on the affected Linux systems.
T1003.007recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability management in j, formal closure) enable recovery of credentials and systems after the T1003.007 technique has run and exfiltrated them, with the named remainder being any unrecoverable data already disclosed to the adversary.
T1003.007responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, analyze root cause, and formally close an information security incident once underway, which matches the `responds` verb for a credential-gathering technique that has already executed.
T1003.008detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause identification and communicating the incident once it occurs, which can surface the credential-dumping technique when it touches the organization's estate; however, the technique can complete silently on a compromised host with no user-visible artifact, no network activity, and no mandatory instrumentation, so detection is not assured and depends on scope and tooling choices.
T1003.008prevents — A.5.26's designated competent team and explicit steps (a: contain spread, b: collect evidence early, c: escalate/invoke continuity, f: coordinate to minimize consequences for others, j: identify/manage the vulnerabilities/weaknesses that enabled the incident) act to stop the technique from completing or recurring once it has begun, which satisfies `prevents` per the event-lane definition and A.5.26 vs T1486 anchor; the remainder is that it cannot stop the initial read if the adversary already has the necessary privileges before response begins.
T1003.008recovers — A.5.26 requires post-incident root-cause analysis, vulnerability/weakness management (including failed controls), and formal closure; this restores the system to a secure state after credential-dumping has occurred, with the named remainder being any already-compromised credentials outside the incident response itself.
T1003.008responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, analyze root cause, and formally close an information security incident once underway, which matches the `responds` verb against an in-progress credential-dumping technique.
T1005recovers — A.5.26's post-incident analysis, root-cause identification, vulnerability management (j), forensic collection, and formal closure enable recovery actions that restore affected systems and data after the T1005 collection has occurred.
T1006detects — A.5.26 requires a designated competent team to respond to incidents (including detection via reported anomalies or logs per its procedures), which surfaces T1006 once the volume-access technique is underway, but only for incidents that reach the response pipeline rather than all executions.
T1006recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability management in j, formal closure) enable recovery actions that restore state after T1006's bypass and data access has occurred, matching the recovers verb in the event lane.
T1006responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, analyze root cause, and close an information security incident once underway, which directly matches the act of responding to T1006's execution (e.g., containing spread via volume access, forensic analysis of shadow copies/backups, and post-incident remediation of the bypass).
T1008detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause identification and communicating details once an incident is underway; fallback channel use (especially after primary C2 loss) produces detectable artifacts on the organization's estate that engage several of those steps, but pre-compromise channel acquisition, non-escalating use, and incidents outside the defined response scope remain unseen.
T1008prevents — A.5.26's designated competent team, containment, coordination with external parties, and post-incident root-cause/vulnerability management directly stop fallback-channel C2 from continuing or recurring once the primary channel compromise is known.
T1008responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis and vulnerability management — all of which directly address an adversary already using a fallback C2 channel (T1008) to contain/eradicate it and minimize further consequences.
T1011prevents — A.5.26's designated competent team responding to an incident (including containment, escalation, coordination with external parties, and addressing related vulnerabilities/weaknesses) stops the exfiltration technique from completing or recurring once it has begun, which satisfies `prevents` per the event-lane anchors; the remainder is that it does not stop the initial attempt before detection.
T1011responds — A.5.26 explicitly requires a designated competent team to respond to incidents (once underway) via containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis and vulnerability management — all of which directly address an exfiltration event that has already begun.
T1011.001prevents — A.5.26's designated competent team responding to an incident (including containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis, and vulnerability management) prevents the Bluetooth exfiltration technique from completing or recurring once it has begun or been detected.
T1011.001responds — A.5.26's designated competent team and enumerated activities (contain spread, collect/analyze evidence, log, communicate, coordinate, close, forensics, root-cause, manage weaknesses) engage once exfiltration is underway on the Bluetooth channel, with the named remainder being the data already exfiltrated before response begins.
T1014detects — A.5.26 requires a designated competent team to respond to incidents (including detection via reported anomalies or indicators), but its core focus is post-detection response rather than proactive detection mechanisms for rootkit hiding techniques.
T1014prevents — A.5.26's designated competent team and explicit steps (a) contain spread, (b/h) collect/forensic evidence, (i) root-cause analysis, and (j) identify/manage the vulnerabilities/weaknesses that allowed the rootkit directly stop the technique from persisting or recurring on affected systems.
T1014responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment, evidence collection, escalation, logging, communication, coordination, forensic analysis, root-cause identification, and post-incident vulnerability/weakness management, which directly matches the act of responding to a rootkit technique that has already executed.
T1020detects — A.5.26's response activities (evidence collection, logging, post-incident analysis, root-cause identification) can surface automated exfiltration once it has produced observable artifacts on the organization's estate, but the technique's outbound transfer often occurs without triggering the control's scope-limited monitoring or response triggers.
T1020prevents — A.5.26's designated competent team, containment (a), coordination (f), and explicit post-incident identification/management of vulnerabilities/weaknesses/controls that failed to prevent the incident (j) stops automated exfiltration from recurring, with the bounded remainder being the initial occurrence before response is invoked.
T1020responds — A.5.26 explicitly requires a designated competent team to respond to incidents already underway via containment, eradication, escalation, evidence collection, logging, communication, coordination, forensic analysis, root-cause identification, and post-incident closure — all of which directly address an automated exfiltration event in flight or recently completed.
T1020.001detects — A.5.26 requires a designated competent team to respond to incidents (including detection via reported anomalies or evidence collection), but its core focus is post-detection response rather than proactive or broad detection of traffic mirroring itself
T1020.001prevents — A.5.26's designated competent team, containment (a), coordination (f), and post-incident root-cause/vulnerability management (i,j) directly stop the adversary's traffic-mirroring setup or its ongoing exfiltration once the incident is recognized, preventing the technique from completing its data-exfiltration goal; the remainder is pre-incident abuse that evades detection until the response is triggered.
T1020.001responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, close, and perform post-incident analysis on an information security incident once underway, which directly matches the act of responding to an already-executing T1020.001 exfiltration technique; the named remainder is that some mirroring may complete data loss before containment.
T1021detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause) can surface T1021 once it has produced observable artifacts on the organization's estate, but pre-compromise acquisition of credentials or use of remote services entirely outside monitored boundaries yields no event for the team to respond to.
T1021prevents — A.5.26 requires a designated competent team to respond to incidents (including containment, evidence collection, escalation, forensic analysis, root-cause identification, and vulnerability/weakness management), which prevents the T1021 technique from continuing or recurring once it has begun as an incident.
T1021responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, escalate, and close an information security incident once underway, which directly matches the `responds` verb against an adversary's use of remote services for lateral movement or code execution.
T1021.001detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause review) surface the RDP session and its artifacts once it has occurred on the organization's estate, but the pre-compromise acquisition of valid accounts and the technique's outbound initiation sit outside the incident-response surface, leaving a large slice of the technique unseen until after execution
T1021.001prevents — A.5.26's designated competent team and explicit procedures for containing spread (a), escalation/crisis invocation (c), coordination (f), and vulnerability/weakness management (j) directly stop the RDP technique from continuing or succeeding once detected, with the bounded remainder being pre-response lateral movement already completed before the incident response lane activates.
T1021.001responds — A.5.26 explicitly requires a competent team to respond to incidents (including containment, eradication, escalation, logging, communication and post-incident root-cause/vulnerability management) once they are underway, which directly matches the act of responding to an adversary's successful RDP session and its follow-on actions.
T1021.002detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause, vulnerability management) surface the SMB share interaction once it has produced observable artifacts on the organization's estate, but the pre-compromise acquisition of a valid account and the technique's use of legitimate admin shares can occur with no incident declared or evidence generated.
T1021.002prevents — A.5.26's designated competent team, containment (a), coordination (f), and vulnerability/weakness management (j) directly stop the SMB share technique from continuing or recurring once underway, with a bounded remainder in pre-incident credential hygiene not covered here.
T1021.002responds — A.5.26 explicitly requires a designated competent team to respond to incidents (including containment, eradication, evidence collection, logging, escalation, and post-incident root-cause/vulnerability management once the SMB lateral-movement technique is already underway), matching the `responds` verb definition.
T1021.003detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause investigation and communicating details once an incident is underway; DCOM lateral movement using a valid account produces observable artifacts (RPC traffic, process creation, registry accesses) that can be surfaced on the organization's estate, but pre-compromise acquisition of the account or purely external reconnaissance leaves no internal event for the response team to detect.
T1021.003prevents — A.5.26's designated competent team, containment (a), coordination (f), and post-incident root-cause/vulnerability management (i,j) directly stop the DCOM lateral-movement technique from continuing or recurring once it has begun, which satisfies `prevents` per the event-lane definition; the named remainder is that it cannot stop the initial use of a valid account against a DCOM object that has not yet been observed as an incident.
T1021.003responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, escalate, close, and perform post-incident/root-cause analysis on an information security incident once underway, which directly matches the act of responding to T1021.003 lateral movement that has already begun.
T1021.004detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause identification and communicating details once an incident is underway, which can surface SSH logins performed with valid accounts when those logins trigger an observable incident on the organization's estate; it does not detect the technique itself when the login is quiet or pre-incident.
T1021.004prevents — A.5.26 requires a designated competent team and explicit procedures that include containing spread, coordinating with parties to minimize consequences, and addressing root causes/vulnerabilities that enabled the incident; this constrains successful SSH use of valid accounts by stopping or limiting the post-authentication actions the adversary can complete.
T1021.004responds — A.5.26 explicitly requires a designated competent team to respond to incidents (including containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis, and vulnerability management once the incident is underway), which directly matches the act of responding to an adversary's successful use of valid accounts over SSH.
T1021.005detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause review and communicating details once an incident is underway, which surfaces knowledge of VNC-based remote control when it occurs on the organization's estate; however, the technique can be used entirely outside monitored scope or pre-compromise (e.g. initial access or lateral movement on unmanaged assets), leaving a large slice undetected.
T1021.005prevents — A.5.26's designated competent team, containment (a), coordination (f), and post-incident root-cause/vulnerability management (i,j) directly stop the VNC abuse technique from continuing or recurring once detected, with a bounded remainder for undetected initial access via valid accounts or unpatched VNC flaws.
T1021.005responds — A.5.26 explicitly requires a competent team to contain (a), eradicate via root-cause/vuln fixes (i,j), log/analyze (d,i), and communicate/escalate (e,f) an incident once underway, which directly matches the definition of `responds` for an in-progress VNC remote-control technique.
T1021.006detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause) can surface WinRM-based lateral movement once it has produced observable artifacts on the organization's estate, but the technique itself occurs on managed Windows systems and many pre-compromise or low-signal uses (e.g. valid-account WinRM to run benign commands) fall outside the incident-response trigger.
T1021.006prevents — A.5.26 requires a designated competent team and explicit procedures that include containing spread (a), coordinating with parties to minimize consequences (f), and identifying/managing the vulnerabilities/weaknesses that enabled the incident (j); this directly stops the WinRM technique from continuing or succeeding once triggered by a valid account, though it does not stop the initial use of the account itself.
T1021.006responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis, and vulnerability management — all of which directly address an in-progress or realized T1021.006 technique (remote interaction via valid accounts and WinRM) without preventing its initial execution.
T1021.007detects — A.5.26's response activities include collecting evidence, logging, communicating, coordinating, closing/recording, root-cause analysis and managing weaknesses once an incident is underway; T1021.007 use of valid/federated accounts to access cloud services can produce observable artifacts (e.g. anomalous logins, management actions) on the organization's estate that engage those activities, but pre-compromise acquisition or use outside monitored scopes (e.g. purely external SaaS without internal signals) leaves a real slice undetected.
T1021.007prevents — A.5.26's designated competent team, containment (a), coordination (f), and post-incident root-cause/vulnerability management (i,j) directly stop the adversary's continued use of the valid account in the cloud control plane once the incident is underway, with the bounded remainder being the initial authentication step itself.
T1021.007responds — A.5.26 explicitly requires a designated competent team to respond to incidents (once underway) via containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis, and vulnerability/weakness management — all of which directly address an in-progress or realized T1021.007 cloud-service access event.
T1021.008detects — A.5.26's response activities (evidence collection, logging, post-incident analysis, root cause) can surface the use of cloud VM console access once it has occurred on the organization's estate, but pre-compromise acquisition of access or use on non-owned infrastructure yields no observable event for the control to act on.
T1021.008prevents — A.5.26's designated competent team following defined procedures for containment, evidence collection, escalation, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that enabled the incident (item j) stops the Direct Cloud VM Connections technique from being repeatable or successful again in the same way.
T1021.008responds — A.5.26 explicitly requires a designated competent team to respond to incidents (including containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis, and vulnerability management), which matches the post-breach response to an adversary already using T1021.008 for direct cloud VM access and pivoting.
T1025recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability management in j, forensic collection, and formal closure) enable recovery actions that restore the organization from the data-collection technique's realized impact, with the named remainder being any data already exfiltrated before response begins.
T1027prevents — A.5.26's designated competent team responding to an incident (including containment, evidence collection, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that enabled it) directly stops the obfuscation technique from continuing or recurring in the environment.
T1027.003detects — A.5.26 requires a designated competent team to respond to incidents (including detection, containment, analysis, and post-incident root-cause/vulnerability identification per items b, h, i, j); this surfaces steganography use once the incident is underway, with the bounded remainder being fully stealthy cases never escalated as incidents.
T1027.003prevents — A.5.26's designated competent team and explicit procedures for containing spread, coordinating with external parties, forensic analysis, root-cause identification, and managing the vulnerabilities/weaknesses that enabled the incident (including those that failed to prevent it) stop the steganography technique from continuing or recurring once it has begun, which satisfies `prevents` per the event-lane boundary (cf. A.5.26 vs T1486 mostly `responds`; A.5.1 vs T1486 `recovers` none).
T1027.003recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability/weakness management in j, forensic analysis, formal closure) enable recovery of organizational state and prevention of recurrence after a steganography-based hiding technique has already run and succeeded in concealing data/commands.
T1027.003responds — A.5.26 requires a competent team to respond to incidents once underway (containment, eradication, evidence collection, logging, escalation, post-incident root-cause analysis, and vulnerability/weakness management), which directly addresses an in-progress steganography technique per the event-lane definition of responds.
T1027.004prevents — A.5.26's designated competent incident-response team, once the technique has begun (delivery of uncompiled source), contains spread, coordinates externally, performs forensic/root-cause analysis, and explicitly identifies/manages the vulnerabilities/weaknesses that enabled the delivery — which stops the same technique from recurring on the same or other systems.
T1027.005responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment (a), evidence collection (b), logging (d), coordination (f), forensic analysis (h), root-cause review (i), and vulnerability/weakness remediation (j), which directly matches the technique's post-detection modification and re-use cycle; the named remainder is that the initial detection trigger itself lives in separate monitoring controls.
T1027.006detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause, and vulnerability management) can surface HTML smuggling once it has produced observable artifacts on the organization's estate (e.g. dropped payload, anomalous JS execution), but the technique's pre-compromise delivery and deobfuscation steps often leave no internal event for the incident-response team to act on.
T1027.006prevents — A.5.26's designated competent team and explicit steps (a) contain spread, (b) collect evidence, (c) escalate/invoke continuity, (f) coordinate externally, and (j) identify/manage the vulnerabilities/weaknesses that enabled the smuggling directly stop the technique from completing its delivery and impact when the incident is underway.
T1027.006recovers — A.5.26 response procedures (containment, evidence, escalation, logging, communication, forensics, post-incident analysis, root-cause handling) act on the incident once underway but do not restore any destroyed or altered state after the HTML smuggling technique has succeeded; recovery is outside its defined scope (see A.8.13 anchor for contrast).
T1027.006responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, analyze root cause/vulnerabilities/weaknesses that enabled the incident, and formally close it once addressed — all core to responding once an HTML-smuggling delivery has occurred and is underway.
T1027.007responds — MYTHOS ORDER 2026-09-15 02:40 §2. Rejected on one call in the v1.38 regrade, held 5/5 on replay at k=5 with grades partial/mostly/partial/mostly/mostly — weakest-among-holders gives `partial`. Written for the same reason as T1608: the single-call rejection was the outlier, not the five that followed it.
T1027.009recovers — A.5.26's post-incident analysis, root-cause documentation, vulnerability/weakness management (item j), and formal closure directly restore the organization's security posture after an embedded-payload technique has run, matching the recovers verb in the same way A.5.26 recovers mostly against T1486.
T1027.009responds — A.5.26's response activities (containment, evidence collection, logging, forensics, root-cause analysis, vulnerability management) engage once an embedded-payload technique has executed and left detectable artifacts or consequences on the estate, but the pre-execution concealment itself and many delivery vectors leave no incident surface for the designated team to contain or eradicate.
T1027.010prevents — A.5.26's designated competent incident-response team, once an obfuscated command is surfaced (by monitoring or other means), contains affected systems, eradicates the actor's foothold, coordinates externally, and explicitly identifies/manages the vulnerabilities/weaknesses (including failed controls) that enabled the obfuscated execution, thereby stopping that adversary technique from continuing or recurring on the same target.
T1027.010responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, analyze root cause, and close an information security incident once underway, which directly matches the act of responding to an adversary's use of command obfuscation during execution.
T1027.011detects — A.5.26 requires a designated competent team to respond to incidents (including detection via reported anomalies, evidence collection, logging, forensic analysis, and post-incident root-cause review), which surfaces some fileless storage artifacts once they trigger an incident; however, the control is scoped to incident response rather than continuous proactive detection of stealthy fileless techniques, leaving most pre-incident or non-escalated cases unreached.
T1027.011prevents — incident response procedures that contain spread, collect evidence, log activity, coordinate externally, perform forensics, analyze root cause, and explicitly identify/manage the vulnerabilities/weaknesses (including failed controls) that enabled the fileless storage directly stop the technique from continuing or recurring in the same form
T1027.011responds — A.5.26's response activities (contain, eradicate, log, analyze, close) engage once fileless storage is discovered as part of an incident, but most of the technique's core mechanics (storing/obfuscating in Registry, WMI, /dev/shm, etc.) leave no incident-triggering event for the team to contain or eradicate
T1027.012detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause, vulnerability management) can surface LNK Icon Smuggling once it has executed on an organizational Windows host or endpoint, but the technique's pre-compromise delivery (e.g. phishing LNK) and post-compromise execution often leave no guaranteed observable within the clause's scoped activities, leaving a large remainder
T1027.012prevents — A.5.26's designated competent team and explicit procedures for containing spread (a), coordinating with external parties to minimize consequences (f), and identifying/managing the vulnerabilities/weaknesses that caused/contributed/failed to prevent the incident (j) stop LNK Icon Smuggling from succeeding when the incident is already underway or recurring, which is what `prevents` asserts for a post-compromise technique; the named remainder is pre-delivery phishing vectors that have not yet triggered an observable incident.
T1027.012recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability management in j, formal closure) enable recovery from the technique's impact once it has run, with the named remainder being any unaddressed pre-containment payload execution or lateral movement.
T1027.012responds — A.5.26's response activities (containment, evidence collection, logging, communication, coordination, closure, forensics, root-cause analysis, and managing related vulnerabilities) engage once the LNK-smuggled payload has executed and delivered malware, but several core steps have an empty object because the technique itself is pre-compromise delivery that leaves no affected system until invocation occurs.
T1027.013detects — A.5.26 requires a designated competent team to respond to incidents (including detection, containment, analysis, and post-incident root-cause/vulnerability identification), which surfaces the use of encrypted/encoded files once they contribute to a detectable incident, but the control is scoped to incident response rather than continuous proactive detection of the obfuscation technique itself.
T1027.013prevents — A.5.26's designated incident-response team, containment (a), evidence collection (b), forensic analysis (h), root-cause identification (i), and explicit remediation of vulnerabilities/weaknesses that failed to prevent the incident (j) stop the Encrypted/Encoded File technique from continuing or recurring in the same form once it has been surfaced.
T1027.013recovers — A.5.26's post-incident analysis, root-cause identification, vulnerability/weakness management (item j), and formal closure directly restore the organization's ability to detect and block the obfuscated artifacts that T1027.013 hides, after the technique has already run.
T1027.013responds — A.5.26's response activities (containment, evidence collection, logging, forensic analysis, root-cause, vulnerability management) engage once an encrypted/encoded artifact is already present and used in an intrusion, but many of its core steps (e.g. system containment, crisis escalation, business continuity invocation) have no object when the technique is only static obfuscation of a file that has not yet executed or spread
T1027.014prevents — A.5.26's designated competent team, containment (a), forensic analysis (h), root-cause identification (i), and explicit remediation of the vulnerabilities/weaknesses that enabled the incident (j) stop polymorphic code from being (re)used after the first successful execution is detected.
T1027.014responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment (a), evidence collection (b), escalation (c), logging (d), communication (e), coordination (f), closure (g), forensics (h), root-cause analysis (i), and vulnerability/weakness management (j) — all of which apply to a polymorphic-code incident in flight, with only the named remainder of already-realized impact (e.g., payload already delivered) falling to recovers.
T1027.015detects — A.5.26's response activities (evidence collection, logging, forensic analysis, post-incident root cause) can surface the use of compression as part of an already-underway incident on the organization's estate, but the technique's pre-compromise delivery (e.g. spearphishing archives) and adversary-side actions fall outside response scope
T1027.015prevents — A.5.26's designated competent team, containment (a), forensic/root-cause analysis (h/i), vulnerability/weakness management (j), and coordination explicitly stop the compression-obfuscation technique from completing its full effect once an incident is recognized, with a bounded remainder for pre-detection use of the technique.
T1027.015responds — A.5.26's response activities (containment, evidence collection, logging, communication, coordination, closure, forensics, root-cause analysis, and managing related weaknesses) engage once compression has occurred in an incident, but many uses (e.g., pre-delivery obfuscation in spearphishing attachments or self-extracting archives) leave no on-estate artifact or spread to contain until a later technique executes, so only a slice of the technique triggers real response actions.
T1027.017prevents — A.5.26's designated competent incident-response team, with its explicit steps to contain spreading consequences (a), coordinate with external parties to minimize consequences for others (f), and identify/manage the vulnerabilities/weaknesses that enabled the incident (j), directly stops SVG smuggling techniques from continuing or succeeding once detected, though it does not stop the initial delivery or embedding of the SVG itself.
T1027.017recovers — A.5.26's post-incident analysis, root-cause documentation, vulnerability/weakness management (including failed controls), and formal closure directly restore organizational state after the smuggling technique has run and delivered its payload.
T1027.017responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment (a), evidence collection (b), escalation (c), logging (d), communication (e), coordination (f), closure (g), forensics (h), root-cause analysis (i), and vulnerability/weakness management (j) — all of which directly address an in-flight SVG-smuggling incident and its artifacts.
T1027.018prevents — A.5.26's designated competent incident-response team, with its explicit steps to contain spread, collect/analyze evidence, perform forensic analysis, identify root cause, and manage the vulnerabilities/weaknesses (incl. controls) that allowed the incident, directly stops the Unicode-obfuscation technique from continuing or recurring once it has begun.
T1027.018responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, analyze root cause, and close an information security incident once underway, which directly matches the act of responding to an adversary's use of invisible Unicode (T1027.018) as an already-realized technique.
T1030detects — A.5.26 requires a competent incident response team to handle incidents (including detection/escalation of anomalous activity and post-incident root cause analysis), which can surface this exfiltration technique once it triggers an incident but does not mandate ongoing monitoring or anomaly detection for sub-threshold transfers themselves.
T1030prevents — A.5.26's designated competent team and explicit procedures for containing spread, coordinating with parties, minimizing consequences, and addressing root causes/vulnerabilities that enabled the incident directly stop the adversary's chunked exfiltration technique from completing its goal once underway, with a bounded remainder only in the initial undetected packets before response begins.
T1030responds — A.5.26's response activities (contain spread, collect/analyze evidence, log, communicate, coordinate, close, forensics, root-cause, manage weaknesses) engage once exfiltration is underway; the technique runs and is responded to, with the named remainder being the already-exfiltrated data slice that cannot be un-sent.
T1036detects — A.5.26 explicitly requires a designated competent team to respond to incidents (including detection triggers, evidence collection, logging, forensic analysis, and post-incident root-cause work), which surfaces masquerading when it is treated as (or triggers) an information security incident.
T1036prevents — A.5.26 requires a designated competent team to respond to incidents once underway (containment, eradication, root-cause analysis, vulnerability remediation), which stops the masquerading technique from continuing or succeeding further; it does not stop the initial rename/artifact manipulation from occurring.
T1036responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment (a), evidence collection (b), logging (d), escalation (c), communication (e), coordination (f), forensic analysis (h), root-cause post-incident review (i), and vulnerability/weakness remediation (j), which bounds and eradicates an active masquerading technique and its effects.
T1036.001detects — A.5.26 requires a competent incident response team to detect, contain and analyze security incidents (including post-incident root-cause work and forensic analysis); an invalid-code-signature artifact can be one observable indicator surfaced during that response, but the clause does not mandate any specific detection mechanism or coverage of this technique.
T1036.001prevents — incident response procedures that contain spread, collect evidence, log activity, coordinate externally, close formally, perform forensics, analyze root cause, and explicitly identify/manage the vulnerabilities/weaknesses that allowed the incident (including failed controls) directly stop the T1036.001 technique from continuing or recurring in the environment
T1036.002detects — A.5.26 requires a designated competent team to respond to incidents (including detection via reported anomalies, evidence collection, logging, and post-incident root-cause analysis), which surfaces some RTLO-based disguises once they trigger an observable incident but does not mandate proactive or broad detection of the technique itself.
T1036.002prevents — A.5.26's designated competent incident-response team, once notified of an incident that has already used an RTLO-disguised payload, contains spread (a), coordinates externally (f), performs forensic/root-cause analysis (h,i), and explicitly identifies/manages the underlying vulnerability/weakness that allowed the disguised file to be trusted and executed (j), which directly stops the technique from being repeatable in the same form.
T1036.002responds — A.5.26 explicitly requires a designated competent team to respond to incidents (including containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis, and vulnerability management once the technique has run and produced an incident), which matches the `responds` verb; the named remainder is that some early RTLO-based social-engineering executions may be caught only as policy violations rather than declared incidents.
T1036.003detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause identification) can surface renamed-utility execution once it has produced observable artifacts on the organization's estate, but the technique itself occurs pre-execution or in non-monitored build/rename steps with no guaranteed incident trigger.
T1036.003prevents — A.5.26's designated competent team responding to an incident (including containment, evidence collection, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that allowed it) directly stops the renamed-utility technique from continuing or recurring in the environment.
T1036.003responds — A.5.26's designated competent team and procedures (containment, evidence collection, logging, escalation, forensic analysis, post-incident root-cause review) act on the incident once the renamed-utility technique is already underway, containing spread and eradicating the actor's foothold.
T1036.004detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause investigation) can surface the masquerading task/service once it has executed and produced observable artifacts, but the clause's scope is limited to post-incident response on the organization's estate and does not mandate proactive detection of the naming manipulation itself.
T1036.004prevents — A.5.26's designated competent team responding to an incident (including containment, evidence collection, escalation, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that enabled it) stops the masquerading task/service from continuing to run or achieve its full effect, which is what `prevents` asserts for a technique already in flight; the named remainder is that the initial naming deception itself is not stopped before the technique executes.
T1036.004responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment, evidence collection, escalation, logging, communication, coordination, forensic analysis, root-cause identification, and post-incident remediation of related vulnerabilities/weaknesses, which directly matches the act of responding to a running T1036.004 masquerading technique (with the named remainder being any pre-containment impact already realized).
T1036.005detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause identification) can surface the technique once it has produced observable artifacts on the organization's estate, but the pre-compromise placement of a masquerading resource often leaves no event for the incident response team to engage until downstream activity occurs.
T1036.005prevents — A.5.26's designated competent team and explicit steps (a) contain spread, (b/c) collect/escalate/eradicate, (i/j) root-cause and fix the enabling weakness (naming deception) once the incident is underway, so the technique does not recur — matching the event-lane anchor for A.5.26 vs T1486 (responds mostly, with the pre-containment slice as named remainder).
T1036.006prevents — A.5.26's designated competent incident-response team, once the disguised executable is opened and the incident is underway, contains spread (a), coordinates with parties to minimize consequences (f), and identifies/manages the enabling weakness (j) — which stops the technique from succeeding again in the same environment.
T1036.007detects — A.5.26 requires a designated competent team to respond to incidents (including detection via reported anomalies or logs) and mandates collecting evidence, logging activities, forensic analysis, and post-incident root-cause identification, which can surface the double-extension masquerading technique once it has triggered an incident; this is only a slice because the control is scoped to incident response rather than continuous proactive detection of the technique in email attachments or file systems before execution.
T1036.007prevents — A.5.26's incident response (containment, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that caused/contributed/failed to prevent the incident) stops the double-extension technique from succeeding again once it has been observed and analyzed.
T1036.007responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, analyze root cause, close, and manage related vulnerabilities once an incident is underway, which directly matches the act of responding to a realized double-extension execution incident.
T1036.008prevents — A.5.26's designated competent team response to an incident (containing spread, evidence collection, escalation, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that allowed the incident) directly stops the masquerading technique from continuing or recurring in the environment once it has been surfaced.
T1036.008recovers — A.5.26's post-incident analysis, root-cause documentation, vulnerability/weakness management (including failed controls), and formal closure directly restore the security posture after a masquerading technique has succeeded, matching the recovers verb; the named remainder is that it does not itself restore any corrupted or lost data.
T1036.008responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, analyze root cause, close, and manage related vulnerabilities once an incident is underway, which directly matches the act of responding to a T1036.008 masquerading event that has already executed.
T1036.009detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause identification and managing weaknesses once an incident is underway, which can surface the PPID-spoofing behavior if it is part of a detected incident on the organization's estate; however the technique itself occurs pre-compromise on adversary-controlled or external systems with no guaranteed observable artifact inside the monitored scope, so only a slice is covered.
T1036.009prevents — A.5.26's designated competent team responding to an incident (including containment, evidence collection, escalation, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that allowed it) stops the T1036.009 technique from continuing or recurring once it has been surfaced, which is what `prevents` asserts in the event-lane anchors; the named remainder is that the initial double-fork/daemon detachment can still complete before detection triggers response.
T1036.009recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability management in j, formal closure) recover from the evasion's effects by restoring visibility and addressing the broken process-tree state after the technique has run.
T1036.009responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, analyze root cause, and formally close an incident once underway, which directly matches the act of responding to a T1036.009 technique that has already executed on a Linux/macOS endpoint.
T1036.010detects — A.5.26 requires a designated competent team to respond to incidents (including detection via reported anomalies, evidence collection, logging, and post-incident root-cause analysis), which surfaces masquerade account creation as part of an ongoing incident but does not mandate proactive detection mechanisms for the technique itself.
T1036.010prevents — A.5.26 requires a designated competent team to respond to incidents once underway (containment, eradication, root-cause analysis, vulnerability/weakness remediation including failed controls); this directly prevents the masquerade technique from persisting or being reused after the incident is addressed, though it does not stop the initial creation/renaming step before detection.
T1036.010responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis, and vulnerability/weakness management — all of which directly address an already-executed masquerade-account-name technique (and its downstream effects) per the event-lane definition of responds.
T1036.011detects — A.5.26 requires a designated competent team to respond to incidents (including detection via reported anomalies or logs per its procedures), which can surface this in-memory argument overwrite when it triggers observable incident indicators, but the control itself does not mandate or perform proactive detection of the technique.
T1036.011prevents — A.5.26's designated competent team and explicit steps (a) contain spread, (b) collect evidence, (d) log activities, (e/f) communicate, (i) root-cause analysis, and (j) identify/manage the exact vulnerability/weakness that enabled the technique all act to stop the adversary's goal of sustained masquerading before or while it runs, with only the narrow remainder of an already-successful, fully-contained rename that leaves no further actionable residue.
T1036.011responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, analyze root cause, and close an information security incident once underway, which directly matches the act of responding to an in-progress T1036.011 masquerading technique; the named remainder is that forensic identification of the exact memory overwrite (item h) is only 'as required' rather than mandatory for every case.
T1037detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause identification and communicating the incident once it has occurred, which can surface T1037 when the boot/logon script execution produces observable artifacts on the organization's estate; however the technique's pre-compromise setup (especially on non-organizational boot media or outside monitored scopes) leaves a large slice unseen, matching the partial rung set by A.5.26 vs T1595.002
T1037prevents — A.5.26's designated competent team following defined procedures for containment, evidence collection, escalation, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that caused/contributed/failed to prevent the incident directly stops the persistence technique from continuing or recurring on affected systems.
T1037responds — A.5.26 explicitly requires a competent team to contain (a), eradicate via root-cause/vuln fixes (i,j), log/analyze (d,i), and close (g) an incident once underway, which matches the `responds` verb against T1037's persistence/escalation via boot-logon scripts.
T1037.001detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause identification and communicating the incident once it has occurred, all of which surface the use of a Windows logon script when that script executes at logon; the pre-compromise acquisition and registry-write steps remain outside any response surface.
T1037.001prevents — A.5.26's designated competent incident-response team, containment (a), root-cause analysis (i), and explicit identification/management of the vulnerabilities/weaknesses that caused/contributed/failed-to-prevent the incident (j) stop the logon-script persistence technique from being (re)used after the first occurrence.
T1037.001responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis and vulnerability management — all of which apply once a T1037.001 logon-script persistence mechanism has activated at logon.
T1037.002prevents — A.5.26's incident-response procedures (containment, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that caused/contributed/failed to prevent the incident) stop the Login Hook persistence from surviving or recurring once it has been surfaced, which is what `prevents` asserts for a post-compromise technique; the named remainder is that the control activates only after the hook has already been planted and executed at least once.
T1037.002responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, analyze root cause, close, and manage related vulnerabilities once an incident (including persistence via login hook) is underway, matching the `responds` verb; the named remainder is that the technique's initial execution may complete before response begins.
T1037.003detects — A.5.26's response activities include collecting evidence, logging, forensic analysis and post-incident root-cause work that can surface the use of a network logon script once it has executed on an observed system; however the technique's pre-compromise setup (assigning a script via AD/GPO) occurs outside organizational monitoring scope and many executions produce no observable incident
T1037.003prevents — A.5.26's designated competent team following defined procedures (including containment, evidence handling, escalation, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that allowed the incident) directly stops the persistence technique from continuing or being reused after the first execution, which is what `prevents` asserts for an already-deployed technique; the named remainder is that it cannot stop the very first run before detection occurs.
T1037.003responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis and vulnerability/weakness remediation — all of which directly address an already-executed T1037.003 persistence technique.
T1037.004detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause identification) can surface the RC-script modification once it has executed and left observable artifacts on the monitored estate, but the pre-compromise technique occurs on the adversary's infrastructure or during an unmonitored boot and many lightweight/embedded platforms in its scope have no logging or response surface at all
T1037.004prevents — A.5.26's designated competent team, containment, forensic analysis, root-cause identification, and explicit management of vulnerabilities/weaknesses that failed to prevent the incident directly stop RC-script persistence from being (re)introduced or surviving post-detection in the incident workflow.
T1037.004responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, analyze root cause, close the incident and address related vulnerabilities/weaknesses once the persistence technique has executed and is underway.
T1037.005detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause, and post-incident vulnerability management) can surface the startup item artifact once it has executed or is present on a monitored macOS system, but the control's scope is limited to incidents that have already been identified and does not mandate proactive detection of the technique itself.
T1037.005prevents — A.5.26's designated competent team and procedures for containing spread, coordinating with parties, managing related vulnerabilities/weaknesses, and post-incident root-cause work (including those that failed to prevent) stop the persistence technique from achieving lasting access in the bulk of cases once it is recognized, with the named remainder being the initial undetected execution window before response begins.
T1037.005responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, analyze root cause, close, and address vulnerabilities/weaknesses once an incident (including persistence via startup items) is underway.
T1039prevents — A.5.26's designated competent team responding to an already-detected incident (containing spread, coordinating, closing, and addressing root causes/vulnerabilities) stops the adversary from completing further collection from additional network shares once the incident is underway, which is what `prevents` asserts for this post-compromise technique; the initial search on already-compromised systems is the bounded remainder.
T1039recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability management in j, forensic analysis, and formal closure) enable recovery of control posture and organizational state after the data-collection technique has run, with the named remainder being any already-exfiltrated data itself
T1039responds — A.5.26 requires a designated competent team to respond to incidents (once underway) via containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis, and vulnerability management — all of which apply to an adversary already searching shares on a compromised system (T1039), with the named remainder being any pre-response data already collected.
T1040detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause) can surface network sniffing once it has produced observable artifacts on the organization's estate, but the technique is passive, pre-compromise, and often occurs outside monitored boundaries (e.g. on external networks, cloud mirroring targets, or before any incident is declared), leaving most executions unseen.
T1040prevents — A.5.26's designated competent team responding to incidents (including containment, evidence collection, forensic analysis, root-cause identification, and managing the vulnerabilities/weaknesses that enabled the incident) directly stops network sniffing from continuing or recurring once detected, which is what `prevents` asserts for an already-possible technique; the named remainder is that passive sniffing can complete and exfiltrate data before response begins.
T1040recovers — A.5.26's post-incident analysis, root-cause documentation, vulnerability/weakness management (item j), and formal closure directly restore organizational state after sniffing has occurred by addressing the captured data's consequences and preventing recurrence.
T1040responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, analyze root cause, and close an information security incident once it is underway, which directly matches the act of responding to network sniffing that has already begun.
T1041detects — A.5.26's response activities (evidence collection, logging, communication, coordination, root-cause analysis) engage once the exfiltration is observable in C2 traffic or logs on the organization's estate, but the control's scope is limited to post-detection response and does not itself perform detection.
T1041prevents — A.5.26's designated competent team and explicit steps (a) contain spread, (b) collect evidence, (c) escalate/invoke continuity, (f) coordinate externally, and (j) identify/manage the vulnerabilities/weaknesses that enabled the exfiltration all act to stop the ongoing technique from continuing or recurring, which satisfies `prevents`; the named remainder is that the initial exfiltration of already-stolen data can complete before response begins.
T1041responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis and vulnerability management — all of which directly address an exfiltration-over-C2 event that has already begun.
T1046detects — A.5.26's response activities (evidence collection, logging, root-cause analysis, vulnerability identification) can surface network service discovery when it produces observable artifacts on the organization's estate, but the technique is often pre-compromise reconnaissance with no affected system or incident to respond to.
T1046prevents — A.5.26's designated competent team responding to an incident (including containment, evidence collection, escalation, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that caused/contributed/failed to prevent it) stops the discovery technique from continuing or recurring once it has been detected as part of an incident.
T1046responds — A.5.26's response activities (evidence collection, logging, communication, coordination, root-cause analysis, vulnerability management) engage once discovery scanning is detected on the estate, but core containment/eradication steps have no object since the technique is non-destructive reconnaissance that leaves no persistent artifact to eradicate.
T1047detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause, communicating) can surface WMI abuse once it has produced observable effects on the organization's estate, but the control's scope is limited to post-occurrence response on affected systems and does not mandate proactive monitoring of WMI execution itself.
T1047prevents — A.5.26's designated competent team and communicated procedures for incident response (including containment, evidence collection, escalation, logging, coordination, forensic analysis, root-cause identification, and explicit management of vulnerabilities/weaknesses that enabled the incident) prevent the adversary's successful abuse of WMI for execution, discovery, or follow-on techniques such as T1490 by stopping the technique's consequences once it begins.
T1047responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment (a), evidence collection (b), escalation (c), logging (d), communication (e), coordination (f), closure (g), forensics (h), root-cause analysis (i), and vulnerability/weakness management (j) — all of which directly address an in-progress or realized T1047 abuse (e.g. WMI-based execution, discovery, or T1490) without preventing the technique itself.
T1048detects — A.5.26's response activities include collecting evidence, logging, communicating, coordinating, closing/recording, root-cause analysis and managing weaknesses once an incident is underway; T1048 exfiltration over an alternate protocol produces observable artifacts (network traffic, logs, anomalous transfers) on the organization's estate that can trigger those activities, but pre-compromise outbound exfil (especially to cloud/SaaS consoles or non-monitored protocols) has no affected system or evidence for the team to act on.
T1048prevents — A.5.26's designated competent team and explicit steps (a: contain spread; f: coordinate to minimize consequences; j: identify/manage vulns/weaknesses that failed to prevent) stop the exfiltration technique from completing or recurring once the incident is underway, with the bounded remainder being pre-detection exfil already sent before response begins.
T1048responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, communicate, coordinate, close, forensically analyze, and post-analyze an information security incident once underway, which directly matches the act of responding to an exfiltration event that has already begun.
T1048.001detects — A.5.26's response activities (evidence collection, logging, communication, coordination, root-cause analysis, forensic analysis) can surface the exfiltration once it has produced observable effects on the organization's estate, but the technique occurs entirely on outbound channels that may be outside real-time monitoring scope and the clause itself sets no detection requirements.
T1048.001prevents — A.5.26's designated competent team, containment (a), coordination (f), and explicit post-incident identification/management of the vulnerabilities/weaknesses (j) that enabled the exfiltration directly stop the technique from recurring on future runs of the same campaign.
T1048.001responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, analyze root cause, and close an information security incident once underway, which directly matches the act of responding to an exfiltration event that has already begun.
T1048.002detects — A.5.26's response activities (evidence collection, logging, communication, coordination, root-cause analysis, forensic analysis) can surface the exfiltration once it has produced observable artifacts on the organization's estate, but the technique occurs on outbound traffic to an external non-C2 endpoint using a legitimate-looking protocol that may generate no incident-triggering signal at all.
T1048.002prevents — A.5.26 requires a designated competent team to respond to incidents once underway (containment, evidence, escalation, communication, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that allowed the incident), which stops the exfiltration technique from continuing or recurring; the named remainder is data already sent before response begins.
T1048.002responds — A.5.26 explicitly requires a designated competent team to respond to incidents (once underway) via containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis and vulnerability management — all of which directly address an exfiltration event that has already begun.
T1048.003detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause review) surface the exfiltration once it has produced observable artifacts on the organization's estate, but the technique occurs entirely on outbound traffic to an external non-C2 destination with no required compromise or persistence, so many instances produce no internal evidence the incident-response team can collect or analyze.
T1048.003prevents — A.5.26's designated competent team responding to an incident (with containment, evidence collection, escalation, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that allowed it) stops the exfiltration technique from continuing or recurring once it has begun, which satisfies `prevents` per the event-lane definition and the A.5.26 vs T1486 anchor; the named remainder is that it does not stop the initial execution before detection/response begins.
T1048.003responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment (a), evidence collection (b), escalation (c), logging (d), communication (e), coordination (f), closure (g), forensics (h), root-cause analysis (i), and vulnerability management (j), which directly matches the act of responding to an exfiltration event that has already begun.
T1049detects — A.5.26's response activities (evidence collection, logging, post-incident analysis, root-cause identification) can surface T1049 when it occurs on the organization's estate and is noticed as anomalous, but the technique is a pre-compromise discovery action with no guaranteed observable event on the organization's systems, and many executions (e.g. on compromised cloud VMs, network devices, or external systems) leave nothing for the incident response team to detect.
T1052prevents — incident response procedures that contain spread, collect evidence, coordinate externally, and address root-cause vulnerabilities can stop a physical-medium exfiltration campaign that is already in progress or prevent recurrence of the same vector, satisfying the `prevents` verb for a genuine but minority slice of the technique (the remainder being one-off or undetected uses that never trigger response).
T1052.001detects — A.5.26 requires monitoring for and response to incidents (including logging, evidence collection, and post-incident analysis that can surface the exfiltration), but its scope is set by organizational procedures and does not mandate specific detection of USB-based exfiltration.
T1052.001prevents — A.5.26's designated competent team, containment (a), coordination (f), and explicit post-incident identification/management of vulnerabilities/weaknesses (j) that failed to prevent the incident stop the USB exfiltration technique from recurring on future runs of the same vector.
T1052.001responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, analyze root cause/vulnerabilities/weaknesses, and formally close an already-underway incident, which directly matches the act of responding to an exfiltration event that has begun via USB device.
T1053detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause identification) can surface a scheduled task/job once it has executed or is recurring on the organization's estate, but the technique's pre-compromise creation (especially on remote systems or outside monitored scope) has no affected system or evidence for the team to respond to.
T1053prevents — A.5.26's designated competent team responding to an incident (containing spread, eradicating artifacts, closing the incident, and addressing the root cause including any enabling vulnerabilities/weaknesses) stops the scheduled task from continuing to run or recurring, which is what `prevents` asserts for a technique that has already executed at least once.
T1053responds — A.5.26 explicitly requires a designated competent team to respond to incidents (once underway) via containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis and vulnerability/weakness management — all of which directly address an in-flight or realized T1053 execution.
T1053.002detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause, vulnerability management) can surface the scheduled at job once it has executed or is observable on the organization's estate, but the technique's pre-execution setup (especially on Linux/macOS via allow/deny files or remote WMI) and many non-incident-surfacing uses sit outside any response trigger.
T1053.002prevents — A.5.26's designated competent team and explicit steps (a) contain spread, (c) escalate/invoke continuity, (f) coordinate externally, and (j) identify/manage the vulnerabilities/weaknesses that enabled the at-abuse technique, stopping it from recurring on the same or other systems.
T1053.002responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, analyze root cause, close, and coordinate on an information security incident once it is underway, which directly matches the act of responding to an adversary's use of at for persistence, execution, lateral movement, or privilege escalation.
T1053.003detects — A.5.26 requires monitoring for and response to incidents (including logging, analysis, and root-cause identification), which can surface cron-based persistence after it has executed, but the control's scope is set by organizational procedures and does not mandate specific detection of cron abuse.
T1053.003responds — A.5.26 requires a competent team to respond to incidents (once underway) via containment, eradication, evidence collection, logging, escalation, and post-incident root-cause/vulnerability analysis — directly addressing a realized cron-based persistence technique per the event-lane definition of responds.
T1053.005detects — A.5.26 requires a designated competent team to respond to incidents (including detection via reported anomalies, evidence collection, logging, forensic analysis, and post-incident root-cause identification), which surfaces scheduled task abuse once it has occurred as part of the incident response process.
T1053.005prevents — A.5.26's incident response procedures (containment, forensic analysis, root-cause identification, and managing the vulnerabilities/weaknesses that allowed the incident) can prevent the scheduled-task technique from recurring after it has already been used once, but do nothing to stop its first use or initial execution.
T1053.005responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, analyze root cause, and close an information security incident once underway, which directly matches the act of responding to an adversary's abuse of scheduled tasks (persistence, execution, lateral movement, or hidden artifacts) after it has begun.
T1053.006detects — A.5.26 requires a designated competent team to respond to incidents (including detection via reported anomalies or logs per its procedures), which can surface systemd timer abuse once it has executed as a scheduled malicious task, but the control's scope is post-incident response rather than proactive or continuous monitoring of timer installations/activations.
T1053.006responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, analyze root cause, close, and manage related vulnerabilities once an incident is underway, which directly matches the act of responding to a realized systemd-timer persistence technique.
T1053.007detects — A.5.26's monitoring, logging, evidence collection, forensic analysis and post-incident root-cause steps can surface the anomalous CronJob or container deployment once it runs on the organization's estate, but the technique's pre-compromise creation (on registrar or external orchestration infrastructure) and many in-cluster executions fall outside the control's scope, exactly as in the A.5.26 vs T1595.002 partial anchor.
T1053.007prevents — A.5.26's designated competent incident-response team, with its explicit steps to contain spread (a), coordinate with internal/external parties (f), identify/manage vulnerabilities/weaknesses that contributed or failed to prevent the incident (j), and perform root-cause analysis (i), directly stops the scheduled malicious container-orchestration job from continuing or recurring once the incident is underway.
T1053.007responds — A.5.26 requires a designated competent team to respond under communicated procedures — containment, eradication, evidence handling, escalation, logging, communication, forensic analysis, root-cause review and vulnerability/weakness remediation of an incident already underway, which directly matches the act `responds` names for a scheduled malicious container job that has executed.
T1055detects — A.5.26 requires a designated competent team to respond to incidents (including detection via reported anomalies or alerts) and mandates logging, evidence collection, forensic analysis, and post-incident root-cause review, which surfaces process injection once underway or after the fact.
T1055responds — A.5.26 explicitly requires a competent team to contain (a), eradicate via root-cause/vuln fixes (i,j), and log/analyze (d,i) an incident once underway, which matches the `responds` verb; the named remainder is that some injection techniques may complete their full effect (e.g. privilege use or exfil) before containment begins.
T1055.001detects — A.5.26 requires a designated competent team to respond to incidents (including detection via anomalous behaviour, evidence collection, logging, and forensic analysis), which surfaces DLL injection once underway as part of incident response.
T1055.001prevents — A.5.26's designated competent team, containment (a), coordination (f), forensic/root-cause work (h–j) and explicit post-incident identification of failed or missing controls that enabled the incident directly stop the DLL-injection technique from recurring on the same or similar vectors.
T1055.001responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, analyze root cause/vulnerabilities/weaknesses, and formally close an incident once underway, which matches the `responds` verb for a technique that has already executed in a live process.
T1055.002detects — A.5.26's monitoring, logging, evidence collection, forensic analysis and post-incident root-cause steps can surface in-flight or post-facto signs of PE injection when it occurs on the organization's estate, but the clause's scope is set by business requirements and many injection variants leave no user-visible or procedure-triggering artifact for a human response team to observe.
T1055.002prevents — A.5.26 requires a designated competent team to respond under communicated procedures — containment and eradication of an event ALREADY UNDERWAY, which is the act `responds` names. The ransomware ran; responding bounds its spread and removes the foothold. `mostly`, with the remainder that marks the boundary to `recovers`: data encrypted BEFORE containment is not un-encrypted by responding to the incident
T1055.002responds — A.5.26 explicitly requires a designated competent team to respond to incidents (once underway) via containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis and vulnerability/weakness remediation — all of which match the post-execution phase of a PE injection technique that has already run and is masked inside a legitimate process.
T1055.003detects — A.5.26's monitoring, logging, evidence collection, forensic analysis and post-incident root-cause steps can surface in-flight or post-facto signs of thread hijacking on the organization's estate, but the technique occurs inside a live process with no guaranteed observable artifact at the scope the control actually sets.
T1055.003prevents — A.5.26's designated competent team responding to an incident (including containment of spreading consequences, coordination to minimize impact on other orgs, and addressing related vulnerabilities/weaknesses) stops the thread hijacking technique from continuing or succeeding once underway, though it does not stop the initial injection itself.
T1055.003recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability management in j, formal closure) enable recovery from the technique's effects once it has run, with the named remainder being any unaddressed persistence or unrecovered state prior to response completion.
T1055.003responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment (a), evidence collection (b), logging (d), escalation (c), communication/coordination (e/f), forensic analysis (h), root-cause review (i), and vulnerability/weakness remediation (j), which matches the `responds` verb for an in-flight T1055.003 execution; the named remainder is impact already realized before containment (e.g., privilege escalation or evasion already achieved).
T1055.004detects — A.5.26's monitoring, logging (d), evidence collection (b), forensic analysis (h) and anomaly-response activities can surface APC injection once it is underway on the organization's estate, but the control's scope is set by business requirements and many in-process APC injections (especially early-bird or atom-bombing variants) produce no user-visible or network-visible artifact for the incident-response team to observe.
T1055.004prevents — A.5.26's designated competent team and procedures for containing spreading incidents, coordinating with parties, and managing related vulnerabilities directly stop APC injection techniques from completing or recurring when the incident is underway or detected early.
T1055.004responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, analyze root cause, and close an incident once underway, which matches the `responds` verb against an in-flight APC injection technique.
T1055.005detects — A.5.26's monitoring, logging (d), evidence collection (b), forensic analysis (h) and post-incident root-cause steps (i) can surface TLS callback injection once it has executed inside a monitored process on the organization's estate, but the technique occurs pre-compromise during process startup with no guaranteed observable artifact on every implementation, and the control's scope is set by organizational requirements rather than mandating universal process-memory instrumentation.
T1055.005prevents — A.5.26 requires a designated competent team to respond under communicated procedures — containment and eradication of an event ALREADY UNDERWAY, which is the act `responds` names. The ransomware ran; responding bounds its spread and removes the foothold. `mostly`, with the remainder that marks the boundary to `recovers`: data encrypted BEFORE containment is not un-encrypted by responding to the incident
T1055.005recovers — A.5.26's incident response (containment, eradication, forensic analysis, post-incident root-cause/vulnerability fixes) restores the affected process/system state after the TLS callback injection has executed, matching the recovers verb; mostly because the control's scope is incident-level and leaves a named remainder for non-incident or undetected cases.
T1055.005responds — A.5.26 explicitly requires a competent team to contain (if spreading), eradicate via forensic/root-cause/vuln management steps, and formally close an incident once underway, which matches the `responds` verb against an in-flight T1055.005 execution.
T1055.008detects — A.5.26 requires monitoring for and response to incidents (including logging, forensic analysis, and post-incident root-cause identification), which can surface ptrace-based injection once it is underway as anomalous behavior, but the clause's scope is set by organizational requirements and does not mandate the specific telemetry or host-level instrumentation needed to reliably catch it.
T1055.008prevents — A.5.26's designated competent team responding to an incident (including containment, evidence collection, escalation, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that enabled it) stops the ptrace injection technique from continuing or recurring on the affected system(s), though it does not stop the initial execution of the technique before detection/response.
T1055.008responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, analyze root cause/vulnerabilities/weaknesses, and formally close an incident once underway, which matches the `responds` verb against a live ptrace injection technique.
T1055.009detects — A.5.26's monitoring, logging (d), evidence collection (b), forensic analysis (h) and anomaly-response activities can surface proc memory injection once it is underway on the organization's Linux estate, but the technique occurs entirely inside a process with no guaranteed user-visible or network-visible artifact, so detection depends on whether host/process instrumentation is in the response scope.
T1055.009prevents — A.5.26's designated competent team responding to an incident (including containment of spreading consequences, coordination to minimize impact, and addressing related vulnerabilities/weaknesses) stops the proc-memory-injection technique from completing its full effect once it has begun running, which matches the prevents verb per the event-lane anchors (cf. A.8.5 vs T1110.001 mostly and A.5.26 vs T1486 responds mostly).
T1055.009recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability/weakness management in j, forensic analysis, and formal closure) enable recovery of organizational state and prevention of recurrence after the T1055.009 technique has executed and impacted a process.
T1055.009responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, analyze root cause, and formally close an information security incident once underway, which directly matches the act of responding to a live proc memory injection (T1055.009) that has already executed in a legitimate process.
T1055.011detects — A.5.26 requires a designated competent team to respond to incidents (including detection via reported anomalies, evidence collection, logging, forensic analysis, and post-incident root-cause identification), which surfaces EWM injection once underway as part of the incident response process.
T1055.011prevents — A.5.26's designated competent team responding to an incident (containing spread, coordinating, closing, and addressing root causes/vulnerabilities per j) stops the EWM injection technique from continuing or recurring once it has begun running, which satisfies `prevents` per the event-lane definition and A.5.26 vs T1486 anchor.
T1055.011recovers — A.5.26's post-incident analysis, root-cause identification, vulnerability management (item j), and formal closure directly restore control and organizational state after the EWM injection technique has run, matching the recovers verb in the event lane.
T1055.011responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate via forensic/root-cause/vuln management steps, log, escalate, and formally close an incident once underway, which matches the `responds` verb against this in-memory injection technique.
T1055.012detects — A.5.26's monitoring, logging (d), evidence collection (b), forensic analysis (h) and post-incident root-cause steps (i) can surface process-hollowing artifacts once they occur on the organization's estate, but the technique executes entirely in-process with no guaranteed observable at the network, user or boundary surfaces the clause scopes to, and pre-compromise acquisition of the hollowed process is invisible.
T1055.012prevents — A.5.26's designated competent team and explicit procedures for containing spread (a), coordinating with parties to minimize consequences (f), and managing vulnerabilities/weaknesses that failed to prevent the incident (j) stop process hollowing from completing or succeeding in most cases once the technique begins, satisfying the `prevents` definition used in the A.8.5 vs T1110.001 anchor.
T1055.012recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability management, formal closure) enable recovery of organizational state and prevention of recurrence after the hollowing technique has already run and achieved its impact.
T1055.012responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, analyze root cause, and formally close an information security incident once underway, which directly matches the act of responding to a process-hollowing execution that has already begun.
T1055.013detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause identification and communicating the incident once it is underway; these surface knowledge of process doppelgänging when it occurs on the organization's estate, but the pre-compromise technique (TxF transaction + section creation) has no inherent organizational event until execution, and the clause's scope is limited to designated response rather than continuous monitoring instrumentation.
T1055.013prevents — A.5.26's designated competent team responding to an incident (with containment, evidence collection, escalation, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that enabled it) stops the T1055.013 technique from continuing or recurring on the affected systems, which is what `prevents` asserts; the named remainder is that it cannot stop the technique from being attempted in the first place on uncompromised systems.
T1055.013recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability management, formal closure, and coordination with continuity plans) enable recovery of affected systems and organizational state after the doppelgänging technique has executed and impacted a live process.
T1055.013responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, analyze root cause/vulnerabilities/weaknesses, and formally close an information security incident once underway, which matches the `responds` verb for a process-injection technique that has already executed.
T1055.014detects — A.5.26's monitoring, logging, evidence collection, forensic analysis and post-incident root-cause steps can surface VDSO hijacking once it is underway on the organization's Linux estate, but the technique occurs entirely inside a live process with no guaranteed user-visible or network-visible artifact, so detection depends on whether the incident-response scope includes the necessary host/process telemetry.
T1055.014prevents — A.5.26 requires a designated competent team to respond to incidents once underway (containment, eradication, root-cause analysis, vulnerability/weakness remediation), which stops the VDSO hijacking technique from continuing or recurring; the named remainder is that the initial injection can still succeed before response is triggered.
T1055.014recovers — A.5.26's post-incident analysis, root-cause identification, vulnerability/weakness management (including failed controls), and formal closure directly restore the security posture after a VDSO hijacking technique has run, matching the recovers verb in the event lane.
T1055.014responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, analyze root cause/vulnerabilities/weaknesses, and formally close an incident once underway, which matches the `responds` verb against an in-flight VDSO hijacking technique.
T1055.015detects — A.5.26 requires a designated competent team to respond to incidents (including detection, containment, analysis, and post-incident root-cause/vulnerability identification), which surfaces ListPlanting once it has executed in a live process; this matches the detects verb on the event lane, with a bounded remainder for incidents that evade initial logging or monitoring before response procedures engage.
T1055.015prevents — A.5.26 requires a designated competent team to respond to incidents once underway (containment, eradication, root-cause analysis, vulnerability management), which stops the ListPlanting technique from continuing or recurring; the named remainder is that the initial injection and execution can still occur before detection/response is triggered.
T1055.015responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, analyze root cause, and formally close an information security incident once underway, which matches the definition and timing of `responds` for a process-injection technique like ListPlanting.
T1056detects — A.5.26's response activities (evidence collection, logging, root-cause analysis, forensics) can surface input-capture artifacts once the technique has run on the organization's estate, but the clause's scope is limited to post-incident response on affected systems and does not mandate proactive monitoring that would detect the technique in all cases (e.g. pre-compromise or on non-owned platforms).
T1056prevents — A.5.26's designated competent team and explicit steps (a) contain spread, (c) escalate/invoke continuity, (f) coordinate externally, and (j) identify/manage the vulnerabilities/weaknesses that enabled the input-capture technique, which together stop it from recurring on the same or other systems — satisfying `prevents` with the named remainder that the initial capture can still complete before response begins.
T1056.001detects — A.5.26's monitoring, logging (d), evidence collection (b), forensic analysis (h) and post-incident root-cause steps (i) can surface keylogging once it is running on an endpoint inside the organization's estate, but the technique has no inherent organizational event footprint until credentials are used and many implementations limit scope to network or perimeter anomalies rather than host-level input capture.
T1056.001prevents — A.5.26's designated competent team and explicit steps (a) contain spread, (b) collect evidence early, (e) communicate per need-to-know, (f) coordinate externally, and (j) identify/manage the vulnerabilities/weaknesses that enabled the keylogger directly stop the technique from continuing or succeeding on additional systems/users, though it does not stop initial installation of a keylogger.
T1056.001responds — A.5.26 requires a competent team to respond to incidents (once underway) via containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis and vulnerability management — all of which directly address an active keylogging incident per the event-lane definition of `responds`.
T1056.002detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause review) can surface the credential prompt or its artifacts once the technique has run on the organization's estate, but the pre-compromise technique itself occurs on user endpoints with no guaranteed monitoring scope or vantage point, leaving a large remainder untouched
T1056.002prevents — A.5.26's designated competent team and procedures for containing spread, coordinating with parties, managing vulnerabilities/weaknesses that contributed or failed to prevent, and post-incident root-cause analysis directly stop the GUI prompt technique from succeeding or recurring in most cases once underway or after initial execution.
T1056.002responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, analyze root cause, and close an information security incident once underway, which directly matches the act of responding to a successful GUI Input Capture technique that has already collected credentials.
T1056.003detects — A.5.26's response activities (evidence collection, logging, root-cause analysis, forensics) can surface the installed capture code or anomalous credential-harvesting behavior once the incident is known, but the technique occurs on an external portal and many of its pre-compromise or stealthy executions leave no internal event for the designated team to detect.
T1056.003prevents — A.5.26's designated competent incident-response team, once aware of the web-portal credential-capture (via monitoring or other detection), contains the affected portal, collects evidence, coordinates with external parties, identifies the installed malicious code/vulnerability, and removes it — thereby stopping the technique from continuing to run and capture further credentials.
T1056.003responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, analyze root cause, close, and communicate an incident once underway, which directly matches the post-compromise execution of T1056.003 (credential capture via compromised portal) with a named remainder being pre-containment data already exfiltrated.
T1056.004detects — A.5.26's monitoring, logging (d), evidence collection (b), forensic analysis (h) and post-incident root-cause steps (i) can surface credential API hooking when it occurs on an instrumented/observed system, but the control's scope is limited to incidents already underway or reported and does not mandate continuous detection instrumentation.
T1056.004prevents — A.5.26 requires a designated competent team to respond to incidents (including containment, evidence collection, forensic analysis, root-cause identification, and vulnerability/weakness management that contributed to or failed to prevent the incident); this directly prevents the credential-hooking technique from completing its goal when the incident is detected early enough to contain it before credentials are exfiltrated, with the named remainder being fully successful hooks that finish before response begins.
T1056.004responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, analyze root cause/vulnerabilities/weaknesses, and formally close an information security incident once underway, which matches the `responds` verb for a running credential-hooking technique.
T1057detects — A.5.26's monitoring, logging (d), evidence collection (b), forensic analysis (h) and post-incident root-cause steps (i) can surface process-discovery activity once it occurs on the organization's estate, but the clause's scope is limited to declared incidents and many low-and-slow discovery actions produce no observable event that triggers response.
T1057responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, analyze root cause, and close an information security incident once underway, which directly matches the `responds` verb against an adversary technique already executing (here, T1057 process enumeration).
T1059detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause identification and communicating details once an incident is underway, which surfaces command/script interpreter abuse when it produces observable effects on the organization's estate; however the technique can execute entirely outside monitored scope (e.g. in adversary-controlled IaaS, containers, or pre-compromise payloads) so only a slice is detected.
T1059prevents — A.5.26 requires a designated competent team to respond under communicated procedures — containment and eradication of an event ALREADY UNDERWAY, which is the act `responds` names. The ransomware ran; responding bounds its spread and removes the foothold. `mostly`, with the remainder that marks the boundary to `recovers`: data encrypted BEFORE containment is not un-encrypted by responding to the incident
T1059responds — A.5.26 explicitly requires a designated competent team to respond to incidents (including containment, eradication, evidence collection, logging, escalation, and post-incident root-cause/vulnerability management), which directly matches the `responds` verb once the T1059 technique is already underway.
T1059.001detects — A.5.26's monitoring, logging (d), evidence collection (b), forensic analysis (h) and post-incident root-cause steps (i) can surface PowerShell abuse once it has occurred on the organization's estate, but the clause's scope is set by business requirements and many T1059.001 executions (e.g. in-memory, non-escalating, or outside monitored processes) produce no observable event for the incident response team to act on.
T1059.001prevents — A.5.26 requires a designated competent team to respond to incidents (including containment, evidence collection, escalation, forensic analysis, root-cause identification, and vulnerability/weakness management), which prevents the T1059.001 technique from continuing or recurring once it has begun as part of an incident.
T1059.001responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway (containment, eradication, evidence collection, logging, escalation, forensic analysis, post-incident root-cause work), which directly matches the `responds` verb against an in-progress T1059.001 execution; the named remainder is that some PowerShell activity may complete its full effect before response begins.
T1059.002detects — A.5.26's monitoring, logging (d), evidence collection (b), forensic analysis (h) and post-incident root-cause steps (i) can surface AppleScript execution when it occurs on an organization's monitored macOS estate and produces observable artifacts, but the control's scope is limited to incident response after an event is already known or suspected rather than continuous detection of the technique itself, and many execution paths (e.g. local-only scripts, NSAppleScript in binaries) leave no guaranteed observable within the clause's defined activities.
T1059.002prevents — A.5.26's designated competent team following defined procedures (including containment, escalation, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that enabled the incident) stops the AppleScript abuse technique from recurring on the affected systems and similar ones, though it does not stop the first-time use of the technique.
T1059.002responds — A.5.26 explicitly requires a designated competent team to respond to incidents (including containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis, and vulnerability management once the technique has executed and is underway), which matches the `responds` verb; the named remainder is that some AppleScript behaviors (e.g., already-launched reverse shells or fake dialogs) may realize impact before containment.
T1059.003detects — A.5.26's response activities include collecting evidence, logging, forensic analysis and post-incident root-cause work that can surface cmd.exe abuse once it has occurred on the organization's estate; this is genuine detection but only a slice, as the clause's core is incident handling rather than proactive monitoring and many T1059.003 executions (especially non-interactive or pre-compromise) leave no incident for the team to respond to.
T1059.003responds — A.5.26 explicitly requires a designated competent team to respond to incidents (including containment, eradication, logging, escalation, and post-incident root-cause/vulnerability management once the technique is already running), which matches the `responds` verb; the named remainder is that some T1059.003 executions may be too brief or stealthy to trigger formal incident response.
T1059.004detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause identification and communicating details of an already-underway incident, which surfaces knowledge of Unix shell abuse when it occurs on the organization's estate; this is partial because pre-compromise or external shell activity (e.g. on adversary infrastructure or non-monitored network devices) leaves nothing for the response team to observe.
T1059.004prevents — A.5.26 requires a designated competent team and explicit procedures that include containing spread (a), coordinating to minimize consequences (f), and identifying/managing the vulnerabilities/weaknesses that enabled the incident (j) — directly stopping the Unix shell technique from continuing or recurring on affected and peer systems.
T1059.004responds — A.5.26 explicitly requires a designated competent team to respond to incidents (including containment, eradication, evidence collection, logging, escalation, and post-incident root-cause/vulnerability management once the technique has executed), which matches the `responds` verb; the named remainder is that some Unix shell abuse (e.g., non-incident persistence or one-off commands) may not trigger formal incident response.
T1059.005detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause identification) can surface VB-based execution when it has produced an observable incident on the organization's estate, but the technique itself occurs in pre-compromise delivery/automation steps (e.g. malicious Office macros or VBScript in attachments) that produce no affected system, evidence or artifact for most of the listed activities to act on.
T1059.005prevents — A.5.26's designated competent team following defined procedures (including containment, evidence handling, escalation, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that enabled the incident) stops the T1059.005 technique from recurring on the same or similar vectors once it has been observed.
T1059.005responds — A.5.26 explicitly requires a designated competent team to respond to incidents (including containment, eradication, evidence collection, logging, escalation, and post-incident root-cause/vulnerability management once the technique has executed), which matches the `responds` verb; the named remainder is that some early-execution or non-incident-classified VB abuse may fall outside declared incident response triggers.
T1059.006detects — A.5.26's monitoring, logging (d), evidence collection (b), forensic analysis (h), and post-incident root-cause steps (i) can surface Python-based execution when it produces observable anomalies or artifacts on the organization's estate, but the technique's pre-compromise scripting, interactive use, or execution entirely outside monitored scope leaves a large unaddressed slice
T1059.006prevents — incident response procedures that contain spread, collect evidence, escalate, and identify/manage the vulnerabilities/weaknesses that enabled the Python abuse (including failed controls) can stop the technique from recurring or succeeding again, but do not stop the initial execution of Python commands/scripts
T1059.006responds — A.5.26 explicitly requires a designated competent team to respond to incidents (once underway) via containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis and vulnerability management — all of which directly address an in-flight or realized Python-abuse execution per the event-lane definition of responds.
T1059.007detects — A.5.26's monitoring, logging (d), evidence collection (b), forensic analysis (h), and post-incident root-cause steps (i) can surface JavaScript abuse when it produces observable artifacts on the organization's estate (e.g. anomalous osascript, suspicious JScript in Windows processes, or script-based payloads in logs), but the technique's pre-compromise delivery (web-hosted scripts, drive-by) and in-memory execution often leave no detectable event on the estate until after impact.
T1059.007prevents — A.5.26's designated competent team responding to an incident (containing spread, coordinating, closing, and addressing root causes/vulnerabilities per j) stops the JavaScript execution technique from continuing or recurring once it has begun, which satisfies `prevents` for the bulk of its post-execution lifecycle on all listed platforms.
T1059.007responds — A.5.26 explicitly requires a designated competent team to respond to incidents (including containment, eradication, evidence collection, logging, escalation, and post-incident root-cause/vulnerability analysis), which directly matches the `responds` verb once a T1059.007 JavaScript execution technique is already underway.
T1059.008detects — A.5.26's response activities (evidence collection, logging, post-incident analysis, root cause, forensic analysis) can surface CLI abuse on managed network devices once it has occurred and produced observable artifacts, but the technique occurs on the device itself with no guaranteed monitoring vantage and many pre-compromise or in-band uses leave no incident for the team to respond to.
T1059.008prevents — A.5.26 requires a designated competent team to respond to incidents once underway (containment, eradication, root-cause analysis, vulnerability management), which stops the adversary from continuing to abuse the network device CLI after initial access; this is the act `prevents` names in the event-lane anchors, with a named remainder being the initial abuse that occurs before response begins.
T1059.008responds — A.5.26 requires a designated competent team to respond to incidents (including containment, eradication, evidence collection, logging, escalation, and post-incident root-cause/vulnerability management once the technique is already underway), which directly matches the event-lane definition of responds for an executed T1059.008 abuse of network device CLI.
T1059.009detects — A.5.26's response activities (evidence collection, logging, post-incident analysis, root-cause identification) can surface cloud API abuse once it has produced observable artifacts on the tenant, but the technique occurs on external cloud infrastructure with no guaranteed organizational vantage point for real-time detection.
T1059.009prevents — A.5.26's designated competent team and explicit procedures for containing spread, coordinating with parties, invoking continuity plans, and managing vulnerabilities/weaknesses that enabled the incident directly stop the T1059.009 technique from continuing or succeeding once underway, with a bounded remainder of pre-response execution that the control does not address.
T1059.009responds — A.5.26 explicitly requires a designated competent team to respond to incidents (once underway) via containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis, and vulnerability/weakness management — all of which directly address an in-flight or realized T1059.009 abuse of cloud APIs.
T1059.010detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause identification and post-incident review, all of which can surface the use of AHK/AutoIT scripts once they have executed on an endpoint; however the clause's scope is limited to incident response after an event is already known or suspected, so it does not instrument or monitor for the technique in flight across the enterprise.
T1059.010prevents — A.5.26's designated competent team and procedures for containing spread, coordinating with parties, and addressing the incident (including forensic/root-cause steps that can lead to blocking the technique) prevent the T1059.010 automation script from achieving its full malicious effect once underway, though it does not stop initial execution or all variants.
T1059.010responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis and vulnerability management — all of which apply once an AutoHotKey/AutoIT technique has executed malicious code or payloads.
T1059.011detects — A.5.26's monitoring, logging (d), evidence collection (b), forensic analysis (h), and post-incident root-cause steps (i) can surface Lua-based execution when it produces observable artifacts on the organization's estate, but the technique's pre-compromise acquisition/abuse of interpreters (especially on network devices or embedded contexts) often leaves no detectable event inside the control's scope.
T1059.011responds — A.5.26 explicitly requires a designated competent team to respond to incidents (once underway) via containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis and vulnerability management — all of which directly address a Lua-based execution technique that has already executed.
T1059.012prevents — A.5.26's designated competent team following defined procedures for containment, coordination, escalation, forensic analysis, root-cause identification, and explicit management of vulnerabilities/weaknesses that failed to prevent the incident stops the hypervisor CLI abuse technique from continuing or recurring in most cases.
T1059.013detects — A.5.26's monitoring, logging (d), evidence collection (b), forensic analysis (h), and post-incident root-cause steps (i) can surface anomalous CLI/API usage once it occurs on the organization's estate, but the technique's pre-compromise reconnaissance and external image pulls have no organizational event to detect, and scope is limited to what the incident response team is configured to observe.
T1059.013prevents — A.5.26 requires a designated competent team to respond to incidents (including containment, evidence collection, escalation, forensic analysis, root-cause identification, and vulnerability/weakness management), which prevents the T1059.013 technique from continuing or recurring once it has begun as part of an incident.
T1059.013responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, escalate, and formally close an already-underway incident, which directly matches the act of responding to an adversary abusing container CLI/API to execute commands.
T1068detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause, communicating) can surface T1068 once it has run on the organization's estate, but pre-compromise exploitation (e.g. BYOVD delivery) and many post-escalation effects sit outside the incident-response surface, leaving a large remainder
T1068prevents — A.5.26's designated competent team response (containment, escalation, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that caused/contributed/failed to prevent the incident) stops the T1068 exploitation technique from completing its privilege-escalation goal once it has begun, which is what `prevents` asserts in the event-lane anchors; the named remainder is that the initial vulnerability exploitation step itself can still occur before response is triggered.
T1068responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, analyze root cause/vulnerabilities/weaknesses that enabled the incident, and formally close it once addressed — all core to responding once T1068 privilege-escalation exploitation is already underway.
T1069.003prevents — A.5.26's incident response (containment, escalation, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that caused/contributed/failed to prevent the incident) stops the discovery technique from continuing or recurring once it has been detected as part of an incident.
T1069.003responds — A.5.26 explicitly requires a designated competent team to respond to incidents (once underway) via containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis and vulnerability/weakness management — all of which apply once T1069.003 enumeration has begun in a cloud environment.
T1070detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause investigation and post-incident review, all of which can surface the selective deletion or modification of indicators once the incident is known or suspected; however, the control's scope is limited to response after an incident is already recognized and does not require proactive detection of the removal technique itself.
T1070prevents — A.5.26's designated competent team responding to an incident (including containment, evidence collection, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that allowed it) stops the adversary from continuing to selectively delete or modify further artifacts once the response begins, which is what `prevents` asserts for this technique; the named remainder is that the technique may have already succeeded on some artifacts before response is triggered.
T1070recovers — A.5.26's post-incident analysis, root-cause documentation, vulnerability/weakness management, and formal closure directly restore the organization's security posture and knowledge after T1070 has erased or altered artifacts, though some forensic reconstruction challenges may remain as named residue.
T1070responds — A.5.26 explicitly requires a designated competent team to contain, collect/analyze evidence (including forensics), log activities, escalate, close the incident, and perform post-incident root-cause analysis once the incident is underway, which matches the `responds` verb; the named remainder is that selective artifact modification can still complicate full forensic reconstruction and attribution even after response activities.
T1070.003detects — A.5.26's response activities include collecting evidence, logging response actions, forensic analysis, and post-incident root-cause work that can surface command-history clearing once it is known or investigated, but the technique itself is a local post-compromise concealment act with no guaranteed observable event on the organization's monitored estate or in the incident-response workflow.
T1070.003prevents — A.5.26's incident response procedures (containment, evidence collection, logging of response activities, forensic analysis, root-cause identification, and explicit management of vulnerabilities/weaknesses that failed to prevent the incident) act to stop the concealment technique from completing its goal once the broader intrusion is known, with a bounded remainder on fully isolated or undetected local executions before response begins.
T1070.003responds — A.5.26 explicitly requires a designated competent team to contain, log, analyze, close and post-process an information security incident once underway, which directly matches the containment/eradication/response lane for an already-executing T1070.003 technique that conceals prior actions.
T1070.004detects — A.5.26 explicitly requires logging all response activities, collecting evidence, conducting forensic analysis, and performing post-incident analysis to identify root cause, which surfaces the file deletion technique (or its artifacts) once the incident is underway.
T1070.004prevents — A.5.26's designated competent team following defined procedures (including containment, evidence handling, coordination, forensic analysis, root-cause identification, and explicit management of vulnerabilities/weaknesses that failed to prevent the incident) stops the post-intrusion cleanup technique from completing its footprint-minimization goal in the majority of cases once the incident is underway and detected.
T1070.004recovers — A.5.26's post-incident analysis, root-cause identification, vulnerability/weakness management (item j), and formal closure directly support recovering from the adversary's footprint-minimization technique by restoring a clean state after the deletion has occurred.
T1070.004responds — A.5.26 requires a competent team to respond to incidents already underway via containment, evidence collection, logging, escalation, communication, forensic analysis, root-cause review and explicit post-incident remediation of the vulnerabilities/weaknesses that enabled the incident, which directly matches the post-intrusion cleanup phase of T1070.004; the named remainder is that the control does not itself perform the adversary's deletion act.
T1070.005detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause identification and post-incident review, all of which can surface the share-removal action when it occurs on an monitored Windows system; however the technique is a post-compromise cleanup step that leaves no persistent artifact and may occur entirely outside the organization's monitored estate or before response is invoked, so only a slice is covered.
T1070.005recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability management in j, formal closure) enable recovery actions that restore a cleaned environment after the cleanup technique has run, with the named remainder being any unaddressed lateral-movement artifacts outside the incident scope.
T1070.005responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment, evidence collection, logging, escalation, coordination, forensic analysis, root-cause identification, and post-incident vulnerability/weakness management, which directly matches responding to (and bounding the effects of) an adversary's T1070.005 cleanup of share-connection traces during an already-active operation.
T1070.006detects — A.5.26 requires logging of response activities, evidence collection, forensic analysis and post-incident root-cause work that can surface timestomping artifacts once an incident is already declared, but the clause itself is scoped to declared-incident response rather than continuous or proactive detection of the technique before or independent of an incident
T1070.006recovers — post-incident root-cause analysis, forensic work, vulnerability/weakness management and formal closure (including any associated restoration steps) recover from the effects and artifacts of timestomping once it has run
T1070.006responds — A.5.26 explicitly requires a designated competent team to respond to incidents (once underway) via containment, evidence collection, logging, escalation, forensic analysis, root-cause identification, and post-incident vulnerability/weakness management, which directly addresses timestomping artifacts in an active incident.
T1070.007detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause identification and post-incident review, all of which can surface the clearing activity or its artifacts once it has occurred on the organization's estate; it does not instrument or observe the act itself in real time, and pre-compromise clearing on external infrastructure is unreachable.
T1070.007prevents — A.5.26's designated competent team, containment (a), evidence collection (b), logging (d), coordination (f), forensic analysis (h), root-cause post-incident review (i), and explicit identification/management of the vulnerabilities/weaknesses that enabled the incident (j) directly stop the adversary technique of clearing network connection history/configs from completing its concealment goal once an incident is recognized.
T1070.007recovers — A.5.26's post-incident analysis, root-cause identification, vulnerability/weakness management (item j), and formal closure directly restore defensive visibility and control posture after the adversary's T1070.007 cleanup has erased artifacts, recovering the organization's ability to monitor/analyze network connections that the technique destroyed.
T1070.007responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment (a), evidence collection (b), logging (d), escalation (c), communication (e), coordination (f), forensic analysis (h), root-cause post-incident review (i), and vulnerability/weakness remediation (j), which directly matches the `responds` verb of acting on an in-flight T1070.007 cleanup technique to bound spread, eradicate artifacts/foothold, and address root causes.
T1070.008detects — A.5.26 requires a designated competent team to respond to incidents (including detection via reported anomalies or logs) and mandates collecting/analyzing evidence plus post-incident root-cause work that can surface the mailbox-clearing technique after it runs; this is genuine but only a minority slice because the control's core is response procedures rather than proactive or broad detection instrumentation.
T1070.008prevents — A.5.26's designated competent team, containment (a), evidence collection (b), logging (d), coordination (f), forensic analysis (h), root-cause analysis (i), and explicit management of vulnerabilities/weaknesses that failed to prevent the incident (j) directly stop the adversary technique from completing its goal of removing evidence once an incident is recognized.
T1070.008recovers — A.5.26's post-incident analysis, root-cause identification, vulnerability/weakness management (including failed controls), evidence collection, and formal closure enable recovery of the mailbox-evidence state by restoring logs, metadata, and detection artifacts after the clearing technique has run.
T1070.008responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, analyze root cause, and formally close an information security incident once underway, which directly matches the post-execution response to T1070.008's evidence-removal activity (with the named remainder being that the control does not itself perform the forensic or vulnerability-management sub-steps listed in its own sub-bullets).
T1070.009detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause identification and post-incident review, all of which can surface the cleanup actions that constitute T1070.009 once they occur on the organization's estate; the remainder is pre-compromise or non-organizational cleanup that leaves nothing observable to respond to.
T1070.009prevents — A.5.26's designated competent team, containment (a), evidence collection (b), logging (d), coordination (f), forensic analysis (h), root-cause post-incident analysis (i), and explicit identification/management of vulnerabilities/weaknesses that failed to prevent the incident (j) directly stop the adversary technique of clearing persistence artifacts from completing its goal of removing defender evidence.
T1070.009recovers — A.5.26's post-incident analysis, root-cause identification, vulnerability/weakness management (including failed controls), formal closure, and coordination directly enable recovery of a clean state after the T1070.009 cleanup technique has run and removed persistence artifacts.
T1070.009responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment, evidence collection, logging, escalation, forensic analysis, root-cause identification, and vulnerability/weakness management — directly addressing the post-persistence cleanup technique in flight to bound spread, eradicate artifacts/footholds, and prevent recurrence.
T1070.010detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause identification and post-incident review, all of which can surface the relocation of malware artifacts once it has occurred on the organization's estate; it does not instrument or observe the act itself in real time, leaving the pre-response slice (and any relocation outside monitored systems) unreached.
T1070.010prevents — A.5.26's designated competent team, containment (a), evidence collection (b), logging (d), coordination (f), forensic analysis (h), root-cause identification (i), and explicit management of vulnerabilities/weaknesses that failed to prevent the incident (j) stop the relocate-malware technique from completing its evasion, evidence-removal, and persistence-establishment goals once the incident is underway.
T1070.010recovers — A.5.26's post-incident analysis, root-cause identification, vulnerability/weakness management (including failed controls), formal closure, and coordination steps enable recovery of a clean state after the relocation technique has run and its artifacts (moved payloads, deleted evidence) are present.
T1070.010responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, analyze root cause, and close an information security incident once underway, which directly matches the post-delivery evasion technique of relocating malware to remove evidence or avoid defenses.
T1071detects — A.5.26's response activities (evidence collection, logging, post-incident analysis, root-cause identification) can surface T1071 once it is already running on the organization's estate, but the clause's scope is limited to incidents that have already been recognized as such and does not mandate proactive monitoring instrumentation.
T1071prevents — A.5.26's designated competent team following defined procedures (including containment, escalation, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that enabled the incident) stops the T1071 C2 channel from continuing or recurring once it has been surfaced, which is what `prevents` asserts for an incident-response control; the named remainder is that the initial setup of the blended protocol traffic can succeed before any response is triggered.
T1071responds — A.5.26's response activities (containment, evidence collection, logging, communication, coordination, closure, forensics, root-cause analysis, and managing the vulnerabilities that enabled the incident) engage once C2 traffic is detected on the estate; the technique has already run and produced observable artifacts, but pre-compromise outbound blending leaves no affected system to contain or eradicate in most cases.
T1071.001detects — A.5.26's response activities (evidence collection, logging, communication, coordination, root-cause analysis, forensic analysis) can surface the C2 traffic once it is already occurring on the organization's estate, but the clause's scope is limited to incident response after detection rather than continuous monitoring, and pre-compromise or non-incident web traffic falls outside its triggered activities.
T1071.001prevents — A.5.26's designated competent team responding to an incident (with containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis, and vulnerability management) prevents the T1071.001 C2 technique from continuing or recurring once it has been detected as an incident.
T1071.001responds — A.5.26's ten activities (contain, evidence, escalate, log, communicate, coordinate, close, forensics, root-cause, remediate weaknesses) engage once T1071.001 C2 is underway on the victim's estate; the technique runs and is then bounded/eradicated by the designated competent team.
T1071.002detects — A.5.26's response activities (evidence collection, logging, post-incident analysis, root-cause identification) can surface the use of file transfer protocols once an incident is known or suspected, but the clause's scope is limited to already-underway incidents rather than continuous monitoring of network traffic for this technique.
T1071.002prevents — A.5.26's designated competent team and explicit procedures for containing spread (a), coordinating with parties to minimize consequences (f), and identifying/managing vulnerabilities/weaknesses that failed to prevent the incident (j) stop the T1071.002 C2 channel from continuing or recurring once detected, which is what `prevents` asserts for an already-launched technique; the named remainder is that the initial protocol-abuse blend-in is not stopped before it begins.
T1071.002responds — A.5.26 requires a designated competent team to respond to incidents (containment, eradication, evidence collection, escalation, logging, communication, forensic analysis, root-cause identification, and vulnerability/weakness management once the incident is underway), which directly matches the act of responding to an adversary's use of file transfer protocols for C2 once detected.
T1071.003detects — A.5.26's response activities (evidence collection, logging, communication, coordination, root-cause analysis) can surface the C2 traffic once it is observed in the organization's estate, but the technique occurs on external mail infrastructure and many implementations limit monitoring scope to internal systems only.
T1071.003prevents — A.5.26's designated competent team responding to an incident (containing spread, coordinating with parties, addressing root causes/vulnerabilities) stops the ongoing T1071.003 C2 channel from continuing, which is what `prevents` asserts for a technique already in flight; the named remainder is that it does not stop the initial setup or first use before detection/response begins.
T1071.003responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway (containment, eradication, evidence collection, escalation, logging, communication, forensic analysis, post-incident root-cause work and vulnerability management), which directly matches the act of responding to an in-flight T1071.003 C2 channel; the named remainder is that the technique may complete its objective before containment begins.
T1071.004detects — A.5.26's response activities (evidence collection, logging, post-incident analysis, root-cause identification) can surface DNS tunneling once it has produced observable anomalies or incidents on the organization's estate, but the clause's scope is limited to incident response after the fact and does not mandate proactive monitoring of DNS traffic itself.
T1071.004prevents — A.5.26's designated competent team following defined procedures for containment, escalation, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that allowed the incident (including failed controls) stops the DNS-tunneling C2 channel from continuing or recurring, which is what `prevents` asserts for a technique already in flight; the bounded remainder is that the initial setup of the beacon is not stopped before the incident is recognized.
T1071.004responds — A.5.26 explicitly requires a designated competent team to respond to incidents (including containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis, and vulnerability management once the incident is underway), which directly matches the act of responding to an active T1071.004 DNS tunneling/beaconing C2 technique; the named remainder is that pre-response detection is outside this clause.
T1071.005detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause identification) can surface pub/sub C2 once it is already running on the organization's estate, but the technique's pre-compromise broker registration, external traffic blending, and lack of named affected system make most of the verb's core empty.
T1071.005prevents — A.5.26's designated competent team, containment (a), coordination (f), and vulnerability/weakness management (j) directly stop the pub/sub C2 channel from continuing or spreading once the incident is recognized, which is what `prevents` asserts for an already-launched technique; the named remainder is that the initial setup of the channel (before any incident is declared) is outside the incident-response lane.
T1071.005responds — A.5.26's designated competent team and enumerated activities (contain affected systems, collect/analyze evidence, eradicate artifacts, close/record, root-cause, manage related weaknesses) act on an in-progress or realized pub/sub C2 channel once it is detected on the estate, which is exactly what `responds` names; the named remainder is pre-compromise adversary infrastructure (brokers, topics) outside the organization that cannot be contained or eradicated by these response steps.
T1072detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause identification and post-incident review, all of which can surface use of enterprise deployment tools once the technique is underway on the organization's estate; partial because pre-compromise acquisition of credentials or external SaaS abuse leaves no organizational event for the team to detect.
T1072prevents — A.5.26's designated competent team, containment (a), escalation/crisis invocation (c), coordination (f), and post-incident root-cause/vulnerability management (i,j) directly stop the T1072 technique from completing its full lateral-move or mass-effect run once initial access has occurred, with the bounded remainder being pre-compromise credential theft that the incident response process itself does not address.
T1072responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, close, and post-analyze an incident once underway, which directly matches the `responds` verb against an adversary's use of deployment tools to execute commands or cause effects.
T1074detects — A.5.26's response activities include collecting evidence (b), logging (d), forensic analysis (h), root-cause analysis (i) and communicating details (e), all of which surface and document the staging activity once it has occurred on the organization's estate; partial because pre-compromise or external staging (e.g. on attacker-controlled cloud instances) leaves no organizational event for the team to detect.
T1074prevents — A.5.26's designated competent team following defined procedures (including containment, evidence handling, escalation, logging, communication, coordination, closure, forensics, root-cause analysis, and explicit identification/management of the vulnerabilities/weaknesses that enabled the incident) stops the T1074 staging technique from completing or recurring once it has begun, which satisfies `prevents` per the event-lane anchors; the named remainder is that the control activates only after the technique has already run to some degree.
T1074recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability management in j, formal closure) enable recovery actions that restore from the staging technique's preparatory impact once the incident is contained and addressed.
T1074responds — A.5.26 explicitly requires a designated competent team to respond to incidents (once underway) via containment, evidence collection, logging, escalation, communication, coordination, forensic analysis, root-cause identification, and post-incident remediation of related vulnerabilities/weaknesses — all of which directly address an in-progress or realized T1074 staging activity as part of incident handling.
T1074.001detects — A.5.26's response activities include collecting evidence, logging, forensic analysis and post-incident root-cause work that can surface local data staging once it has occurred on the organization's estate; this is genuine detection but only a slice, as the pre-compromise acquisition and staging of data (especially on non-organizational systems or before any incident is declared) leaves most of the technique outside the control's scope.
T1074.001prevents — A.5.26's designated competent team following defined procedures (including containment, evidence handling, escalation, logging, communication, coordination, closure, forensics, root-cause analysis, and explicit identification/management of the vulnerabilities/weaknesses that enabled the incident) stops the adversary technique from completing its full intended effect in the large majority of cases, with only a bounded remainder (e.g., fully stealthy staging that evades all detection and response triggers) left unaddressed.
T1074.001recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability management in j, formal closure) enable recovery of organizational state after the staging technique has run, aligning with the event-lane recovers verb (cf. A.5.26 vs T1486 mostly anchor).
T1074.001responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment (a), evidence collection (b), logging (d), coordination (f), forensic analysis (h), root-cause post-incident review (i), and vulnerability/weakness remediation (j), which directly matches the event-lane definition of `responds` for a data-staging technique that has already executed; the named remainder is that pure pre-staging detection lives in other controls.
T1074.002detects — A.5.26's monitoring, logging (d), evidence collection (b), forensic analysis (h), and post-incident root-cause steps (i) can surface the staging activity or its artifacts once present on an organizational system/instance, but the technique occurs entirely within adversary-controlled or transient cloud instances with no guaranteed organizational vantage point.
T1074.002prevents — A.5.26's designated competent team and explicit steps (a: contain spread; b: collect evidence early; f: coordinate to minimize consequences; j: identify/manage vulnerabilities/weaknesses that enabled the incident) act to stop the staging technique from completing or reaching exfiltration once underway, which satisfies `prevents` per the event-lane anchors (cf. A.5.26 vs T1486 mostly).
T1074.002recovers — A.5.26's post-incident analysis, root-cause identification, vulnerability management (item j), and formal closure directly support recovering from the data-staging technique once it has run, by addressing the breach artifacts and enabling restoration of a secure state.
T1078responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, escalate, communicate and formally close an information security incident once it is underway, which matches the `responds` verb against an adversary abusing valid accounts.
T1078detects — A.5.26's response activities (evidence collection, logging, post-incident analysis, root-cause identification) can surface use/abuse of valid accounts once underway on the organization's estate, but pre-compromise acquisition, inactive-account abuse outside monitored scope, and purely external pivots have no event for the team to respond to.
T1078prevents — A.5.26's incident response procedures (containment, escalation, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that caused/contributed/failed to prevent the incident) stop the adversary from successfully abusing the valid account for Initial Access, Persistence, Privilege Escalation or Defense Evasion once the compromise is known.
T1078recovers — A.5.26 requires incident response that includes containment, eradication of the actor's foothold, formal closure after successful addressing, and post-incident root-cause analysis that explicitly identifies and manages the vulnerabilities/weaknesses (including failed controls) that enabled the credential abuse, thereby restoring the security posture after the T1078 event.
T1078.001prevents — A.5.26's designated competent incident-response team, with its explicit steps to contain spread (a), coordinate externally (f), identify/manage the vulnerabilities/weaknesses that enabled the incident (j), and perform root-cause analysis (i), directly stops default-account abuse from continuing or recurring once the incident is underway.
T1078.001responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, analyze root cause, close, and manage vulnerabilities/weaknesses once an incident (including default-account abuse) is underway, matching the `responds` definition with a named remainder of pre-containment impact.
T1078.002detects — A.5.26's response activities (evidence collection, logging, root-cause analysis, forensic analysis) surface the use/abuse of a compromised domain account once it produces observable effects on the organization's estate; pre-compromise acquisition (e.g. via external credential dumping) and purely internal lateral use with no triggered anomaly sit outside the response scope.
T1078.002prevents — A.5.26's designated competent team following defined procedures (including containment, evidence handling, escalation, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that caused/contributed/failed to prevent the incident) stops the domain-account abuse technique from continuing or recurring once it has begun, which is what `prevents` asserts in the event-lane anchors; the named remainder is that it does not stop the initial compromise before the incident is recognized.
T1078.002recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability/weakness management in j, forensic analysis, and formal closure) restore the security posture after the domain-account abuse technique has already run and succeeded, which is exactly what `recovers` names; the named remainder is that it does not itself restore any data or system state destroyed by follow-on impact.
T1078.002responds — A.5.26 explicitly requires a competent team to contain, eradicate, log, escalate, communicate and formally close an information security incident once it is underway, which directly matches the act of responding to an adversary abusing a compromised domain account.
T1078.003detects — A.5.26 explicitly requires a designated competent team to respond to incidents (including detection triggers, evidence collection, logging, forensic analysis, and post-incident root-cause work), which surfaces local-account abuse once it is underway as an information security incident.
T1078.003prevents — A.5.26's designated competent team responding to an incident (containing spread, evidence collection, escalation, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that caused/contributed/failed to prevent it) stops the local-account abuse technique from continuing or recurring, which is what `prevents` asserts; the named remainder is that the initial credential compromise can still occur before detection/response begins.
T1078.003recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability/weakness management in j, formal closure) restore the security posture after the local-account abuse technique has already run and succeeded, which is what recovers asserts; the named remainder is that it does not itself restore any deleted/disrupted data or system state (that is A.8.13).
T1078.003responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, analyze root cause, close, and manage related vulnerabilities once an incident (including local-account abuse for initial access/persistence/escalation) is underway, matching the `responds` verb; the named remainder is impact already realized before containment (e.g., credentials already harvested and reused).
T1078.004detects — A.5.26 requires a designated team to respond to incidents (including detection via reported anomalies, evidence collection, logging, and post-incident root-cause analysis), but its scope is limited to already-identified or reported incidents rather than proactive, broad-spectrum detection of the T1078.004 technique itself.
T1078.004prevents — A.5.26 requires a designated competent team to respond to incidents (including containment, evidence collection, escalation, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that caused/contributed/failed to prevent the incident); this directly stops the T1078.004 technique from continuing or recurring once it has begun, which satisfies `prevents` per the event-lane definition and the A.5.26 vs T1486 anchor.
T1078.004recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability/weakness management in j, formal closure) enable recovery actions that restore the environment after the T1078.004 technique has run and achieved its effects (e.g., persistence via added credentials or lateral movement).
T1078.004responds — A.5.26 explicitly requires a designated competent team to respond to incidents (including containment, eradication, escalation, forensic analysis, root-cause identification, and vulnerability/weakness management once the incident is underway), which directly matches the post-compromise response to adversary use of valid cloud accounts for initial access, persistence, privilege escalation or lateral movement.
T1080detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause identification and communicating details once an incident is underway, which can surface T1080 when it has already tainted shared content and affected systems; however, the pre-compromise acquisition and tainting of shared storage (especially on external or registrar-like infrastructure) has no affected system or evidence on the organization's estate for these activities to engage.
T1080prevents — A.5.26's designated competent team and explicit steps (a: contain spread; f: coordinate to minimize consequences; j: identify/manage vulnerabilities/weaknesses that failed to prevent) stop the lateral-movement technique from continuing or recurring once it has begun, which is what `prevents` asserts for an already-underway event; the named remainder is that it does not stop the initial tainting of shared content before any incident is recognized.
T1080responds — A.5.26 explicitly requires a designated competent team to contain spreading incidents, eradicate artifacts (including tainted shared content), log/analyze, close formally, and address root causes/vulnerabilities once the technique is underway, matching the `responds` verb; the named remainder is that some early propagation may complete before containment.
T1087prevents — A.5.26's designated competent team responding to incidents (including containment, evidence collection, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that caused/contributed/failed to prevent the incident) stops the discovery technique from completing or recurring in the same environment.
T1087.002prevents — incident response procedures that contain spread, collect evidence, escalate, log, communicate, coordinate, close, forensically analyze, identify root causes, and manage resulting vulnerabilities can constrain or stop the follow-on behaviors that domain account enumeration enables (e.g., by rapid containment or privilege-account isolation), but do not stop the enumeration technique itself from running
T1087.003prevents — A.5.26's designated competent team responding to incidents (including containment, evidence collection, escalation, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that allowed the incident) stops the adversary technique from completing or recurring after it has begun, which satisfies `prevents` per the event-lane definition and A.5.26 vs T1486 anchor; the remainder is that it does not stop the initial authenticated execution of Get-GlobalAddressList before detection/response begins.
T1090detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause identification and communicating details once an incident is underway; these can surface proxy usage when it appears in logs, network artifacts or as part of an already-running C2 channel on the organization's estate, but the control's scope is limited to post-detection response and does not instrument or guarantee discovery of the proxy technique itself.
T1090prevents — A.5.26's incident response procedures (containment, coordination with external parties, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that enabled the incident) prevent the T1090 proxy technique from recurring once it has been observed and addressed.
T1090responds — A.5.26 requires a designated competent team to respond under communicated procedures — containment and eradication of an event ALREADY UNDERWAY, which is the act `responds` names; the proxy technique can be contained/eradicated once detected.
T1090.001detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause investigation and communicating details once an incident is underway; an internal proxy that produces observable anomalies (e.g. unexpected traffic redirection, new listening services, or anomalous SMB flows) on the organization's estate can therefore be detected as part of incident response, but the control's scope is limited to post-occurrence response on owned systems and does not instrument or surface the proxy technique itself across the full denominator of platforms and stealthy p2p uses.
T1090.001prevents — A.5.26's designated competent team and explicit procedures for containing spread (a), coordinating with parties to minimize consequences (f), and managing vulnerabilities/weaknesses that contributed or failed to prevent (j) stop the internal proxy technique from continuing or succeeding in its C2 redirection goals once the incident is recognized.
T1090.001responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment, eradication, evidence collection, logging, escalation, and post-incident root-cause/vulnerability management, which bounds and removes an active internal proxy C2 technique (and its artifacts) without preventing its initial setup.
T1090.002detects — A.5.26's response activities include collecting evidence, logging, communicating, coordinating, root-cause analysis and identifying weaknesses once an incident is underway; an external proxy in active C2 use can produce observable anomalies (e.g. unexpected outbound connections, traffic patterns) that fall inside those logged/analyzed activities on the victim estate, but pre-compromise proxy acquisition, non-victim proxies, and purely passive forwarding often leave no detectable event on the organization's systems.
T1090.002prevents — A.5.26's designated competent team following defined procedures (including containment, coordination with external parties, and vulnerability/weakness management) stops the external-proxy technique from continuing or succeeding once the incident is underway, with a bounded remainder of undetected or pre-containment use.
T1090.002responds — A.5.26 requires a designated competent team to respond to incidents (containment, eradication, coordination, post-incident analysis, and vulnerability management), which acts on an already-underway T1090.002 C2 proxy technique once detected, bounding its spread and removing footholds per the event-lane definition of responds.
T1090.003detects — A.5.26 requires monitoring for and response to incidents (including logging, forensic analysis, and root-cause identification), which surfaces multi-hop proxy C2 as anomalous behavior once underway.
T1090.003responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, analyze root cause, and close an incident once underway, which directly matches the act of responding to a multi-hop proxy C2 channel that has already reached the network.
T1091detects — A.5.26 requires a designated competent team to respond to incidents (including detection via reported anomalies or indicators), but its core is post-detection response procedures rather than proactive or broad detection mechanisms for T1091's media-based replication technique.
T1091prevents — A.5.26's designated competent team and procedures (including containment, evidence collection, escalation, forensic analysis, root-cause identification, and explicit management of vulnerabilities/weaknesses that caused/contributed/failed to prevent the incident) act to stop replication-through-removable-media from recurring after first occurrence, which is what `prevents` asserts; the named remainder is that it cannot stop the very first execution on a new target before the incident is known.
T1091responds — A.5.26 requires a designated competent team to respond to incidents (containment, eradication, evidence collection, logging, escalation, post-incident root-cause analysis, and vulnerability/weakness management), which directly addresses an already-underway T1091 replication event once detected.
T1092prevents — A.5.26's designated competent team and procedures for containing spread, coordinating with parties, and managing vulnerabilities/weaknesses that failed to prevent the incident directly stop the C2 relay via removable media once the incident is recognized, with a bounded remainder for pre-detection execution on air-gapped systems.
T1095detects — A.5.26 requires monitoring for and response to incidents (including logging, analysis, and root-cause identification), which can surface anomalous non-application-layer protocol use once it triggers an incident, but the control is silent on proactive detection of the technique itself and the VMCI variant is explicitly invisible to standard monitoring.
T1095prevents — A.5.26's designated competent team and procedures for containing spread, coordinating with parties, managing vulnerabilities/weaknesses that enabled the incident, and post-incident root-cause work prevent the T1095 technique from continuing or recurring once it has begun, though they do not stop the initial use of a non-application-layer protocol before detection.
T1095responds — A.5.26's designated team and enumerated activities (contain spread, collect/analyze evidence, log, communicate, coordinate, close, forensics, root-cause, manage weaknesses) engage once T1095 C2 or lateral traffic is underway on the estate, exactly as the verb requires; the named remainder is pre-compromise reconnaissance or traffic that never reaches monitored organizational assets.
T1098detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause, communicating) can surface account manipulation once it has produced observable artifacts on the organization's estate, but the technique's pre-compromise acquisition and many of its stealthy modifications (especially on non-organizational platforms like IaaS, SaaS, or identity providers) leave no event for the incident response team to engage.
T1098prevents — A.5.26 requires a designated competent team to respond to incidents once underway (containment, eradication, root-cause analysis, vulnerability/weakness remediation including failed controls), which stops the adversary from continuing to manipulate the account to maintain or escalate access; the technique has already run to initial compromise, leaving a bounded remainder of pre-response manipulation that is outside the incident-response lane.
T1098responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment (a), evidence collection (b), escalation/crisis handling (c), logging (d), communication (e), coordination (f), formal closure (g), forensics (h), root-cause analysis (i), and vulnerability/weakness management (j) — all of which directly address an in-progress T1098 manipulation that has already succeeded in gaining initial access.
T1098.001detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause identification) can surface the addition of cloud credentials once it has occurred and is treated as an incident, but the technique itself occurs pre-compromise on cloud-provider infrastructure with no guaranteed organizational vantage point until the credential is used.
T1098.001prevents — A.5.26's designated competent team and explicit steps (a) contain spread, (c) escalate/invoke continuity, (f) coordinate externally, and (j) identify/manage the vulnerabilities/weaknesses that enabled the credential-addition directly stop the technique from completing its persistence goal once the incident is underway.
T1098.001responds — A.5.26 explicitly requires a designated competent team to respond to incidents (once underway) via containment, evidence collection, escalation, logging, communication, coordination, forensic analysis, root-cause identification, and post-incident vulnerability/weakness management — all of which directly address an already-executed T1098.001 persistence technique and its consequences.
T1098.002detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause identification) can surface the permission change once it has occurred on the organization's estate, but the technique itself occurs in the cloud tenant or Exchange configuration with no guaranteed observable event on every implementation's monitored scope.
T1098.002prevents — A.5.26's designated competent team and explicit steps (a: contain spread; c: escalate/invoke continuity; f: coordinate to minimize consequences; j: identify/manage vulns/weaknesses that enabled the incident) act on an ongoing BEC/persistent-access incident to stop further permission grants, lateral use of the delegate mailbox, and related techniques before full impact.
T1098.002responds — A.5.26 requires a designated competent team to respond to incidents already underway (containment, eradication, evidence collection, escalation, logging, communication, forensic analysis, root-cause review, and vulnerability/weakness remediation), which directly matches the persistent-access and BEC incidents that employ T1098.002; the named remainder is that the control does not itself perform the final technical remediation steps it directs.
T1098.003detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause identification and post-incident review, all of which can surface the addition of cloud roles once it has occurred and is visible in logs or audit trails; however, the technique can be performed entirely outside the organization's monitored estate (e.g., on an external adversary-controlled tenant) or before any response trigger, leaving a substantial slice undetected.
T1098.003prevents — A.5.26's designated competent team and explicit steps (a: contain spread; j: identify/manage vulnerabilities/weaknesses that caused/contributed/failed to prevent; plus root-cause and forensic work) stop the persistence technique from completing or recurring once the incident is underway, with a bounded remainder for stealthy cases that evade initial detection.
T1098.003responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, escalate, close, and perform root-cause/post-incident analysis on an information security incident once underway, which directly matches the act of responding to an adversary adding cloud roles/permissions (T1098.003) after it has begun.
T1098.004detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause, vulnerability management) can surface the authorized_keys modification once it is an incident on the organization's estate, but the pre-compromise technique occurs on external infrastructure (cloud APIs, registrar-like) or outside monitored scope for many cases, leaving a large unobservable slice
T1098.004prevents — A.5.26 requires a designated competent team to respond to incidents (including containment, evidence collection, escalation, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that caused/contributed/failed to prevent the incident); when the SSH authorized_keys modification is treated as (or surfaces during) an information security incident, these steps stop the persistence technique from continuing or recurring on the affected host(s).
T1098.004responds — A.5.26 explicitly requires a designated competent team to respond to incidents (once underway) via containment, evidence collection, escalation, logging, communication, coordination, forensic analysis, root-cause post-incident review, and vulnerability/weakness management — all of which directly map to containing/eradication steps once an SSH authorized_keys modification has occurred.
T1098.005detects — A.5.26's response activities include collecting evidence, logging, communicating, coordinating, closing/recording, root-cause analysis and identifying related weaknesses/vulnerabilities, all of which can engage once a device registration is known; however the technique occurs on an external MFA/IdP or Entra ID tenant (often pre-compromise or without touching monitored organizational systems), leaving many cases with no observable event on the estate for the response team to act on.
T1098.005prevents — A.5.26's designated competent team and explicit procedures for containing spread, coordinating with parties, managing related vulnerabilities/weaknesses, and invoking continuity plans (when the registration enables persistence or further compromise) stop the technique from achieving or sustaining its full impact in most cases once underway.
T1098.005responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment (a), evidence collection (b), escalation (c), logging (d), communication (e), coordination (f), closure (g), forensics (h), root-cause analysis (i), and vulnerability/weakness management (j) — all of which directly map to an in-progress device registration incident that has already bypassed MFA or conditional access.
T1098.006detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause identification, vulnerability management) can surface the post-compromise role-binding or ABAC change once it is an incident on the organization's estate, but the technique's pre-compromise execution (creating bindings on registrar-like external orchestration infrastructure) has no affected system or evidence inside the response scope
T1098.006prevents — A.5.26's designated competent team following defined procedures for containment, escalation, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses (item j) that enabled the permission-addition technique stops it from achieving or sustaining the persistent-access outcome in most cases.
T1098.006responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment (a), escalation/crisis handling (c), coordination (f), forensic/root-cause analysis (h/i), and post-incident vulnerability/weakness management (j), which directly matches responding to an in-progress privilege-escalation technique like T1098.006; the named remainder is that the technique may already have succeeded before response begins.
T1098.007detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause, and vulnerability management) can surface the group-addition once it has occurred on the organization's estate, but pre-compromise reconnaissance, the addition command itself, and additions performed entirely outside the monitored estate (e.g. on external domain controllers or before the account is used) are unreachable by the incident-response mechanism.
T1098.007prevents — A.5.26's designated competent team and explicit step (j) to identify/manage vulnerabilities/weaknesses (including failed controls) that contributed to an incident, plus containing/escalating once underway, stops the persistence technique from continuing or recurring in the same form on affected systems.
T1098.007responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, analyze root cause, and close an information security incident once underway, which directly matches the act of responding to an adversary adding groups for persistence (the technique has already run and produced its artifact).
T1102detects — A.5.26's response activities (evidence collection, logging, post-incident analysis, root-cause identification) can surface the use of a web service for C2 once an incident is already known or suspected, but the clause's scope is limited to declared incidents rather than continuous monitoring of all outbound traffic or anomalous connections, leaving the majority of stealthy, low-and-slow uses undetected until impact occurs.
T1102prevents — A.5.26's designated competent team responding to an incident (including containment, evidence collection, escalation, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that enabled it) stops the T1102 C2 channel from continuing or recurring, which is what prevents asserts; the named remainder is that the initial compromise and channel setup can still occur before any incident is detected.
T1102responds — A.5.26 explicitly requires a designated competent team to respond to incidents already underway via containment, eradication, escalation, logging, communication, coordination, forensic analysis, root-cause identification, and formal closure — all of which directly address an in-progress T1102 C2 channel once detected.
T1102.001detects — A.5.26's response activities include collecting evidence, logging, communicating, coordinating, root-cause analysis and identifying related weaknesses; a dead-drop resolver that produces observable artifacts (e.g. anomalous outbound connections or embedded indicators in logs) on the organization's estate can therefore be detected as part of incident response, but the technique's pre-compromise, external-web-service nature means many instances produce no organizational event at all.
T1102.001prevents — A.5.26's designated competent team responding to an incident (including containment, evidence collection, escalation, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that enabled it) directly stops the dead-drop resolver technique from continuing to run or being reused in the same environment.
T1102.001responds — A.5.26's response activities (a-j) engage once the dead-drop resolver is already in use by infected victims: evidence collection, logging, communication, coordination, forensic analysis, root-cause identification, and managing the enabling vulnerabilities/weaknesses all apply to an event underway on the estate, but containment/escalation/closure have limited or no object because the technique itself never touches organizational systems.
T1102.002detects — A.5.26's response activities include collecting evidence, logging, communicating, coordinating, closing/recording, root-cause analysis and identifying weaknesses once an incident is underway; T1102.002's bidirectional C2 over common web services (e.g. posts, pull requests, updates) can produce observable artifacts on the organization's estate that engage several of those activities, but the pre-compromise acquisition and much of the low-and-slow traffic sits outside the organization's vantage point, leaving a large slice unseen.
T1102.002prevents — A.5.26's designated competent team following defined procedures (including containment, coordination with external parties, and vulnerability/weakness management) stops the bidirectional C2 channel from continuing or succeeding once the incident is recognized, which is what `prevents` asserts for a technique already in flight; the named remainder is pre-detection use that blends into expected traffic.
T1102.002responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis and vulnerability management — all of which directly address an active T1102.002 C2 channel that has already compromised a system.
T1102.003detects — A.5.26's response activities (evidence collection, logging, post-incident analysis, root-cause identification) can surface the use of one-way Web-service C2 once it has produced observable artifacts on the organization's estate, but the upstream acquisition and setup of the legitimate external service occurs entirely outside the organization's visibility and many one-way implementations produce no detectable return traffic.
T1102.003prevents — A.5.26's designated competent team, containment (a), coordination (f), and post-incident root-cause/vulnerability management (i,j) directly stop the adversary's one-way C2 channel from continuing or being reused once the incident is underway, with only the pre-detection slice as bounded remainder.
T1102.003responds — A.5.26 requires a designated competent team to respond to incidents (containment, eradication, evidence, escalation, logging, communication, post-incident analysis, and managing related vulnerabilities/weaknesses) once the T1102.003 C2 technique is already underway; the named remainder is that some one-way C2 may complete its full effect before containment occurs.
T1104detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause, communicating) can surface the multi-stage C2 once any stage reaches or affects the organization's estate, but the upstream setup of separate non-overlapping stages (especially pre-compromise or on external infrastructure) has no event on the estate for the team to respond to or detect.
T1104responds — A.5.26's designated competent team and enumerated activities (contain spread, collect/analyze evidence, log, escalate, communicate, coordinate, close, perform root-cause and manage resulting weaknesses) directly engage an already-underway multi-stage C2 channel once any stage is detected on the estate, bounding its effects and eradicating footholds; the named remainder is that early undetected stages can complete their redirect before response begins.
T1105detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause, vulnerability management) can surface the presence of an ingress tool once it has arrived on the estate, but the technique itself occurs on external infrastructure or via allowed C2 channels that the incident-response procedure has no vantage point on until after transfer succeeds.
T1105responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, analyze root cause/vulnerabilities/weaknesses, and formally close an incident once underway, which directly matches the `responds` verb against an already-executed T1105 tool ingress.
T1106detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause, vulnerability management) can surface the use of native APIs once the incident is known or underway, but the clause's scope is limited to declared incidents rather than continuous monitoring of API calls, and many stealthy direct-syscall uses leave no observable incident trigger.
T1106prevents — A.5.26's designated competent team responding to an incident (containing spread, eradicating foothold, coordinating, closing) stops the adversary's ongoing or repeated abuse of native APIs once the technique has begun, which is what `prevents` asserts in the event-lane anchors; the named remainder is the initial execution before detection/response.
T1110detects — A.5.26's response activities (evidence collection, logging, post-incident analysis, root-cause identification) can surface brute-force attempts once they trigger detectable events on the organization's estate, but the technique's pre-compromise guessing (especially offline or on external infrastructure) has no affected system or evidence for the control to observe.
T1110prevents — A.5.26's designated competent team responding to an incident (including containment, evidence collection, escalation, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that allowed the incident) stops a brute-force campaign from continuing or succeeding further once it is detected as an underway information security incident.
T1110recovers — A.5.26 requires a designated competent team to respond under communicated procedures — containment and eradication of an event ALREADY UNDERWAY, which is the act `responds` names. The ransomware ran; responding bounds its spread and removes the foothold. `mostly`, with the remainder that marks the boundary to `recovers`: data encrypted BEFORE containment is not un-encrypted by responding to the incident
T1110responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, analyze root cause, and close an information security incident once underway, which directly matches the `responds` verb against an in-progress brute-force campaign.
T1110.001detects — A.5.26 requires a designated competent team to respond to incidents under communicated procedures, which necessarily includes detection of the incident (e.g. via failed logins, account lockouts, or anomalous auth attempts described in the technique) in order to trigger containment, evidence collection, escalation, logging, and post-incident analysis; this covers most but not all instances such as stealthy guessing that evades initial notice.
T1110.001prevents — A.5.26 requires a designated competent team and explicit procedures that include containing spread, escalation, account lockouts via failed-attempt handling, and post-incident root-cause fixes that directly stop password-guessing from succeeding or recurring; the named remainder is that the control activates only after the guessing has begun and produced detectable failures.
T1110.001responds — A.5.26 explicitly requires a designated competent team to respond to incidents (including containment, escalation, evidence collection, logging, communication, coordination, forensic analysis, root-cause identification, and post-incident vulnerability management) once an information security incident such as password guessing is underway.
T1110.002prevents — A.5.26's designated competent team responding to an incident (including containment, evidence collection, escalation, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that allowed the incident) stops the cracking technique from completing its goal of producing usable plaintext credentials that grant access.
T1110.002recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability/weakness management in j, forensic analysis, and formal closure) enable recovery of credentials by addressing the cracked passwords and related weaknesses after the technique has run.
T1110.002responds — A.5.26 requires a designated competent team to respond under communicated procedures — containment and eradication of an event ALREADY UNDERWAY, which is the act `responds` names; the cracking technique can be underway (e.g., offline on adversary systems) before detection triggers response actions such as containment, evidence collection, escalation, and post-incident root-cause/vulnerability management.
T1110.003detects — A.5.26's response activities (evidence collection, logging, post-incident analysis, root-cause identification) can surface password-spraying attempts that have already reached the organization's estate (e.g. via monitored auth logs on targeted services), but the technique's pre-compromise reconnaissance, external throttling, and targeting of non-owned identity providers or cloud services lie outside any response trigger.
T1110.003prevents — A.5.26's designated competent team responding to an incident (including containment, evidence collection, escalation, forensic analysis, root-cause identification, and vulnerability/weakness management) stops a password-spraying campaign that is already underway from continuing or succeeding further, which satisfies the `prevents` verb per the event-lane anchors; the remainder is that it does not stop the technique from being attempted in the first place.
T1110.003recovers — A.5.26 is strictly an incident response procedure that acts once the spraying technique is already underway (containment, evidence, escalation, logging, communication, forensic analysis, post-incident root-cause work); it asserts nothing about restoring any pre-incident state that the technique destroyed.
T1110.003responds — A.5.26 explicitly requires a designated competent team to respond to incidents (including containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis, and vulnerability management once the spraying has produced a detectable breach or compromise), matching the `responds` verb for an event already underway.
T1110.004detects — A.5.26's response activities (evidence collection, logging, post-incident analysis, root-cause identification) can surface credential-stuffing attempts that reach the estate and produce observable failures or anomalies, but the technique's pre-compromise acquisition of dumps and its execution against external services often leave no organizational event to detect.
T1110.004prevents — A.5.26's designated competent team responding to an incident (including containment, evidence collection, escalation, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that caused/contributed/failed to prevent it) stops credential-stuffing attacks that are already underway or repeating from the same breach dump, which is what `prevents` asserts for this technique; the named remainder is first-use stuffing attempts that succeed before any incident is declared.
T1110.004recovers — A.5.26 requires a competent team to respond to incidents (including credential-stuffing breaches) with containment, evidence collection, escalation, logging, communication, coordination, formal closure, forensics, root-cause analysis, and explicit identification/management of the vulnerabilities/weaknesses that enabled the incident, which restores organizational security posture after the technique has run.
T1110.004responds — A.5.26 requires a competent team to respond to incidents once underway (containment, eradication, evidence, escalation, logging, communication, post-incident root-cause analysis and vulnerability management), which directly matches the technique running and producing an observable security incident.
T1111detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause review) surface and document an MFA-interception incident once it has produced observable effects on the organization's estate, but the upstream technique (e.g. keylogger on token input or SMS-service compromise) can complete without ever triggering those activities if the adversary never produces a detectable incident on monitored systems.
T1111recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability/weakness management in j, formal closure, and coordination) enable recovery from realized MFA-interception impacts once the incident is underway, matching the recovers verb in the event-lane anchors (e.g., A.5.26 vs T1486).
T1111responds — A.5.26 explicitly requires a designated competent team to respond to incidents (including containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis, and vulnerability management), which directly matches the act of responding once an MFA-interception technique is already underway.
T1112detects — A.5.26 requires monitoring for and response to incidents (including logging, forensic analysis, and post-incident root-cause identification), which can surface Registry-modification activity once it triggers an observable incident, but the control is scoped to incident response rather than continuous or proactive detection of the technique itself.
T1112prevents — A.5.26's designated competent team responding to an incident (including containment, root-cause analysis, vulnerability/weakness management in j, and post-incident actions) stops the adversary technique from continuing or recurring once it has begun, which satisfies `prevents` per the event-lane anchors; the remainder is that it does not stop the initial execution before detection.
T1113detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause) can surface screen-capture artifacts once they exist on the organization's estate, but the technique itself produces no mandatory observable event on monitored boundaries and many instances (e.g., local post-compromise use of native APIs with no exfil) leave nothing for the incident-response team to detect.
T1113prevents — A.5.26's designated competent team and explicit procedures for containing spread (a), coordinating to minimize consequences (f), and managing vulnerabilities/weaknesses that failed to prevent the incident (j) stop the screen-capture technique from continuing or succeeding once the incident is recognized, with the bounded remainder being captures completed before response begins.
T1113recovers — A.5.26 response procedures (containment, evidence, escalation, logging, communication, forensics, post-incident analysis, root-cause fixes) act on the incident once underway but do not restore any pre-incident state destroyed by screen capture; recovery is outside its defined scope (see A.8.13 anchors for contrast)
T1113responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment, evidence collection, logging, escalation, communication, forensic analysis, root-cause review and vulnerability remediation — all of which directly address an in-progress or just-completed T1113 screen-capture action.
T1114detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause, communicating) can surface the fact and details of email collection once it has produced observable artifacts on the organization's estate, but the technique's core acquisition step (e.g. server-side forwarding rules or client exfiltration) often leaves no required event inside the control's human/procedural mechanism.
T1114prevents — A.5.26's designated competent team, containment (a), escalation (c), coordination (f), forensic/root-cause work (h/i) and explicit post-incident vulnerability/weakness management (j) stop the adversary from successfully completing further email collection once an incident is recognized, which is what `prevents` asserts for a technique already in flight; the named remainder is collection that finishes before detection/response begins.
T1114recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability/weakness management, formal closure, and coordination) restore organizational posture and limit further collection after T1114 has run, matching the recovers verb; the named remainder is that it does not itself restore already-exfiltrated email data.
T1114responds — A.5.26 explicitly requires a designated competent team to respond to incidents (including containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis, and vulnerability management), which directly addresses an in-progress T1114 collection that may expose or leverage incident-response details, bounding its spread and enabling eradication once underway.
T1114.001detects — A.5.26's response activities include collecting evidence, logging, communicating, coordinating, closing/recording, root-cause analysis and identifying weaknesses once an incident is underway; local email collection on a Windows endpoint can produce observable artifacts (e.g. anomalous file access or process behavior) that would be captured inside those activities when the incident reaches the organization's estate, but the control's scope is strictly post-compromise response and does not instrument or surface the technique itself pre-incident.
T1114.001prevents — A.5.26 requires a designated competent team and explicit procedures that include containing spread, evidence collection, escalation, logging, communication, coordination, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that enabled the incident — which directly stops the T1114.001 collection technique from completing or recurring once the incident is recognized.
T1114.001recovers — A.5.26's post-incident steps (forensic analysis, root-cause identification, vulnerability management, and formal closure) enable recovery of the email data and environment after the T1114.001 collection has occurred, with the named remainder being any data exfiltrated before containment
T1114.001responds — A.5.26 explicitly requires a designated competent team to respond to incidents (including containment, evidence collection, logging, escalation, communication, forensic analysis, root-cause review and vulnerability/weakness remediation once the incident is underway), which directly matches the post-collection response to a realized T1114.001 email-theft event.
T1114.002detects — A.5.26's response activities (evidence collection, logging, communication, coordination, root-cause analysis, forensic analysis) can surface the technique once it has run and produced observable artifacts on organizational email systems or logs, but many collection events (especially external credentialed access with no internal footprint) leave no event for the incident response team to engage.
T1114.002prevents — A.5.26's designated competent team following defined procedures (including containment, evidence handling, escalation, coordination with external parties, and vulnerability/weakness management) prevents the technique from completing or spreading once detected, though initial credential compromise and collection can still occur before response begins.
T1114.002recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability management, formal closure, and coordination) enable recovery of organizational posture and minimize further consequences after the email collection technique has run, though they do not restore the already-exfiltrated data itself.
T1114.002responds — A.5.26 requires a competent team to respond to incidents already underway via containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis and vulnerability management — all of which directly address an in-progress or completed remote email collection (T1114.002) once detected, with the named remainder being any pre-containment data exfiltration that has already succeeded.
T1114.003detects — A.5.26's response activities (evidence collection, logging, post-incident analysis, root-cause identification) can surface the forwarding rule or its effects once the incident is known or underway, but the control's scope is limited to incident response rather than continuous monitoring of rule creation or mail flow.
T1114.003prevents — A.5.26's designated competent team and explicit steps (a) contain spread, (b) collect evidence early, (e) communicate per need-to-know, (f) coordinate externally, and (j) identify/manage the vulnerabilities/weaknesses that enabled the rule setup directly stop the technique from completing its collection/persistence goals in most cases once triggered.
T1114.003recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability management in j, formal closure) enable recovery of the forwarding rule's effects by removing the persistent collection mechanism after the incident has run.
T1114.003responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, analyze root cause/vulnerabilities/weaknesses, and formally close an incident once underway, which directly matches the act of responding to an already-executed T1114.003 setup that has begun exfiltrating or persisting via forwarded mail.
T1115recovers — A.5.26's post-incident analysis, root-cause identification, vulnerability management (item j), and formal closure enable recovery actions that restore affected systems or data after the clipboard collection has occurred.
T1119detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause identification) can surface the automated collection once it is underway and logged or investigated, but the clause's scope is incident response after detection rather than continuous monitoring of collection activity itself, leaving most pre-escalation instances unseen.
T1119prevents — A.5.26's designated competent team, containment (a), coordination (f), and post-incident root-cause/vulnerability management (i,j) directly stop automated collection from continuing or recurring once the incident is underway, which satisfies `prevents` for the bulk of the technique's post-establishment execution; the named remainder is collection that completes before response begins.
T1119recovers — A.5.26's post-incident analysis, root-cause documentation, vulnerability/weakness management (including failed controls), and formal closure enable recovery of organizational state and prevention of repeat automated collection after the technique has run.
T1119responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis, and vulnerability management — all of which directly address an already-running automated collection technique (T1119) by bounding its spread, capturing artifacts, and removing footholds, with the named remainder being impact (data already exfiltrated) that falls to recovers.
T1123detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause) can surface audio-capture artifacts once they produce observable effects on the organization's estate, but the technique's core action (silent microphone access via API) often leaves no detectable event until exfiltration or user-visible side effects occur, and pre-compromise acquisition leaves nothing on the estate to respond to.
T1123prevents — A.5.26's designated competent team and explicit procedures for containing spread, coordinating with parties, and managing vulnerabilities/weaknesses that enabled the incident directly stop ongoing or repeated T1123 audio capture once detected, though they do not stop the initial technique execution before incident declaration.
T1123recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability management in j, formal closure) enable recovery of organizational state after the audio-capture technique has run and produced its effect.
T1123responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, analyze root cause, and close an information security incident once underway, which directly matches the act of responding to an adversary's ongoing audio capture technique.
T1125detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause, vulnerability management) can surface video-capture artifacts once they exist on the organization's estate, but the technique's core action (API-driven device access) often leaves no observable event until exfiltration or user-visible symptoms appear, and pre-compromise acquisition leaves nothing on the estate to detect.
T1125prevents — A.5.26's designated competent team and explicit steps (a) contain spread, (b) collect evidence early, (f) coordinate externally, and (j) identify/manage the vulnerabilities/weaknesses that enabled the incident directly stop the video-capture technique from continuing or recurring once it has begun, which satisfies the `prevents` verb for this post-breach technique; the named remainder is that it does not stop the very first execution before any response is triggered.
T1125recovers — A.5.26's post-incident analysis, root-cause identification, vulnerability management (j), and formal closure act after the video-capture technique has run, restoring organizational state by addressing the exploited weaknesses that enabled it.
T1127detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause identification) can surface the use of trusted developer utilities once the incident is underway on the organization's estate, but pre-compromise proxy execution of arbitrary code (especially via signed LOLBins) often leaves no observable event inside the control's scope until after impact or lateral movement.
T1127prevents — A.5.26's designated competent team and explicit procedures for containing spread (a), coordinating with parties to minimize consequences (f), and managing vulnerabilities/weaknesses that failed to prevent the incident (j) stop the T1127 technique from completing its full effect in most cases once underway, though it does not stop the initial proxy execution itself.
T1127recovers — A.5.26's incident response (containment, eradication, forensic analysis, root-cause identification, and post-incident vulnerability/weakness management) restores the system from the effects of a T1127-based execution once it has occurred, matching the recovers verb; the named remainder is that it does not itself restore data or state destroyed by any follow-on impact.
T1127responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment (a), evidence collection (b), logging (d), escalation (c), communication (e), coordination (f), forensic analysis (h), root-cause post-incident review (i), and vulnerability/weakness remediation (j), which matches the `responds` verb for a T1127 execution event; the named remainder is impact already realized before containment.
T1127.001detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause identification) can surface MSBuild abuse once it has produced observable artifacts on the organization's estate, but the technique's pre-compromise build of a project file and its proxy execution via a trusted signed binary often leave no incident-triggering event for the designated team to respond to.
T1127.001prevents — A.5.26 requires a designated competent team to respond to incidents once underway (containment, eradication, root-cause analysis, vulnerability management), which prevents the MSBuild proxy technique from continuing or recurring after initial execution.
T1127.001recovers — A.5.26's post-incident analysis, root-cause documentation, vulnerability/weakness management (including failed controls), and formal closure directly restore the security posture after the MSBuild proxy execution has run, matching the recovers verb (with the named remainder of any unaddressed lateral impact or data loss).
T1127.001responds — A.5.26 requires a competent team to respond to incidents already underway (containment, eradication, evidence, escalation, logging, communication, forensic analysis, post-incident root-cause work and vulnerability management), which directly matches the act of responding to T1127.001 once the MSBuild abuse has begun; the named remainder is impact already realized before containment.
T1127.002detects — A.5.26's response activities (evidence collection, logging, forensic analysis, post-incident root-cause) can surface the technique once it has executed on an organizational endpoint, but the pre-compromise acquisition/execution often occurs outside monitored estate or via user action with no guaranteed observable artifact.
T1127.002prevents — A.5.26's designated competent team, containment (a), coordination (f), and post-incident root-cause/vulnerability management (i,j) directly stop the ClickOnce proxy technique from recurring or spreading once underway, with the bounded remainder being the initial user-execution vector before response is triggered.
T1127.002recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability management in j, formal closure) enable recovery of organizational state and prevention of recurrence after the ClickOnce proxy execution has already run, matching the recovers verb in the event lane.
T1127.002responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, analyze root cause/vulnerabilities/weaknesses, close, and coordinate on an incident once underway, which directly matches the act of responding to T1127.002 execution.
T1127.003detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause identification) can surface the JamPlus abuse once it has executed on an endpoint, but the technique occurs pre-compromise on a build tool with no guaranteed observable artifact inside the clause's defined scope
T1127.003prevents — A.5.26's designated competent team following defined procedures for containment, evidence handling, escalation, logging, communication, coordination, closure, forensics, root-cause analysis, and explicit identification/management of the vulnerabilities/weaknesses that enabled the incident (including failed controls) stops the JamPlus abuse technique from continuing or recurring in the environment.
T1127.003responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment, evidence collection, escalation, logging, communication, coordination, forensic analysis, post-incident root-cause review, and vulnerability/weakness management — all of which directly address an in-flight JamPlus abuse technique (including its subverted-app-control artifact) with the named remainder being impact already realized before containment.
T1129detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause, vulnerability management) can surface the loading of a malicious shared module once it has executed on an organizational asset, but the technique occurs inside a process with no guaranteed observable artifact on the monitored estate and many executions (e.g. in build pipelines or non-instrumented hosts) stay outside the control's scope.
T1129prevents — A.5.26's designated competent team responding to an incident (including containment, evidence collection, escalation, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that allowed the incident) stops the T1129 technique from continuing or recurring on affected systems, though it does not stop the initial execution of the technique before detection/response begins.
T1129responds — A.5.26 requires a designated competent team to respond to incidents (once underway) via containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis, and vulnerability/weakness management — all of which directly address an in-flight T1129 module-loading execution that has already begun.
T1132.001detects — A.5.26 explicitly requires a designated competent team to respond to incidents (including detection triggers, logging, forensic analysis, and post-incident root-cause work), which surfaces encoded C2 traffic once it has produced observable incident indicators.
T1132.001responds — A.5.26 requires a competent team to respond to incidents once underway (containment, eradication, evidence, escalation, logging, communication, forensic analysis, post-incident root-cause work), which directly addresses an in-flight T1132.001-encoded C2 channel as an information security incident; the named remainder is that the technique may already have succeeded in exfiltrating data or establishing persistence before response begins.
T1132.002prevents — A.5.26's designated competent incident-response team, once the non-standard encoding C2 is underway, contains affected systems (a), coordinates with external parties (f), identifies and manages the enabling vulnerabilities/weaknesses (j), and performs root-cause analysis (i), which together prevent the technique from continuing or recurring in most cases.
T1132.002responds — A.5.26's designated team and enumerated activities (contain spread, collect/analyze evidence, log, communicate, coordinate, close, forensics, root-cause, manage weaknesses) engage once a non-standard C2 encoding technique is already running and observable in traffic or artifacts, exactly as the verb `responds` requires; the named remainder is pre-detection stealth where the encoding evades initial notice entirely.
T1133prevents — A.5.26's designated competent team, containment (a), escalation/crisis invocation (c), coordination (f), vulnerability/weakness management (j) and post-incident root-cause work directly stop the adversary's external-remote-service access or persistence technique from continuing or recurring, with the bounded remainder being the initial undetected foothold before response is triggered.
T1133responds — A.5.26 explicitly requires a designated competent team to respond to incidents (including containment, eradication, escalation, forensic analysis, and post-incident root-cause/vulnerability management once the technique has run and an incident is underway), which matches the `responds` verb; the named remainder is that some T1133 access vectors (e.g., unauthenticated exposed services or pre-compromise persistence setup) may not always trigger a detectable incident.
T1134detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause, vulnerability management) can surface token manipulation once it has produced observable effects on the organization's estate, but the pre-compromise technique itself (API calls on a registrar-like external surface or inside an already-privileged process with no mandatory user-visible artifact) sits outside the control's defined scope in the same way the event-lane anchors grade A.5.26 none against T1583.001 and T1596.002.
T1134prevents — A.5.26's designated competent team responding to an incident (with containment, evidence collection, escalation, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that allowed the incident) stops the T1134 technique from continuing or recurring once it has begun, which satisfies `prevents` for the bulk of its post-execution lifetime; the named remainder is that it does not stop the initial execution before detection.
T1134responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, analyze root cause, and close an information security incident once underway, which directly matches the `responds` verb against an in-progress T1134 technique.
T1134.001detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause) can surface token impersonation once it has produced observable effects on the organization's estate, but the technique itself occurs in-process with no guaranteed user-visible artifact and many executions stay below the threshold that triggers response
T1134.001prevents — A.5.26's designated competent team, containment (a), coordination (f), forensic/root-cause analysis (h/i), and explicit identification+management of the vulnerabilities/weaknesses (j) that enabled the incident directly stop Token Impersonation/Theft from recurring on the affected systems and similar vectors elsewhere.
T1134.001recovers — A.5.26's incident response (containment, eradication, post-incident root-cause/vuln management, and formal closure) restores control after the privilege-escalation technique has run, matching the recovers verb in the event lane.
T1134.001responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, analyze root cause, and close an information security incident once underway, which directly matches the act of responding to a T1134.001 execution that has already succeeded in escalating privileges.
T1134.002detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause review) can surface the technique once it has run on the organization's estate, but the pre-compromise acquisition of a token (via duplication or creation) and many Windows process-creation events sit outside the control's defined scope and response triggers.
T1134.002prevents — A.5.26's designated competent team and procedures for containing spread, coordinating with parties, managing related vulnerabilities/weaknesses, and post-incident root-cause work (including those that failed to prevent) stop most instances of this Windows privilege-escalation technique from succeeding or recurring, with a bounded remainder in pre-response execution and non-incident paths.
T1134.002recovers — A.5.26's post-incident analysis, root-cause documentation, vulnerability/weakness management (including failed controls), and formal closure act after the privilege-escalation technique has run, restoring a secure state by addressing the exploited weaknesses that enabled it.
T1134.002responds — A.5.26 requires a competent team to respond to incidents once underway via containment, eradication, escalation, logging, coordination, forensic analysis, root-cause review and vulnerability management — all of which directly address an in-progress or completed T1134.002 execution (e.g., containing the elevated process, collecting evidence, closing the incident, and fixing the token/privilege weakness that enabled it), with the named remainder being any pre-containment impact already realized.
T1134.003detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause identification and communicating details once an incident is underway, which can surface token impersonation on Windows systems that reach the monitored estate; however, the technique occurs pre-compromise during privilege escalation with no guaranteed observable event on the organization's estate, leaving most executions outside response scope.
T1134.003prevents — A.5.26 requires a designated competent team to respond to incidents once underway (containment, eradication, root-cause analysis, vulnerability management), which stops the token-making/impersonation technique from continuing or succeeding further; the named remainder is that the technique can still run and achieve initial access before response begins.
T1134.003recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability management in j, formal closure) restore the security posture after the token-impersonation technique has already run and succeeded, which is exactly what `recovers` names; the named remainder is that it does not itself restore any specific assets the technique may have already accessed or altered.
T1134.003responds — A.5.26 requires a competent team to respond to incidents once underway via containment, eradication, escalation, logging, coordination and post-incident root-cause/vulnerability management, which directly matches the act of responding to a T1134.003 token-creation event that has already executed.
T1134.004detects — A.5.26 requires a designated competent team to respond to incidents (including detection via reported anomalies, evidence collection, logging, forensic analysis, and root-cause identification), which surfaces PPID-spoofing techniques once they trigger an observable incident.
T1134.004prevents — A.5.26's designated competent team and explicit procedures for containing spreading incidents, coordinating with parties, and managing vulnerabilities/weaknesses that failed to prevent the incident directly stop PPID spoofing techniques from completing their evasion or privilege-escalation goals once underway.
T1134.004responds — A.5.26's response activities (contain, eradicate, log, analyze root cause, manage related weaknesses) engage once PPID-spoofing is detected in flight on the estate, but the core technique (API call to CreateProcess) has no artifact that is contained or eradicated by response, leaving most of the verb's protective weight on post-fact administrative/follow-up steps only
T1134.005detects — A.5.26 requires a designated competent team to respond to incidents (including detection, containment, evidence collection, logging, and post-incident root-cause analysis), which surfaces SID-History Injection once underway as anomalous privileged behavior or lateral movement.
T1134.005prevents — A.5.26's designated competent team and explicit steps (a) contain spread, (c) escalate/crisis/BCP invocation, (f) coordinate externally, and (j) identify/manage the vulnerabilities/weaknesses that enabled the SID-History injection, stopping the technique from completing its privilege-escalation and lateral-movement goals in most cases once the incident is underway.
T1134.005responds — A.5.26 requires a competent team to respond to incidents already underway via containment, eradication, evidence collection, logging, escalation, communication, and post-incident root-cause/vulnerability management, which directly matches the technique once it has executed to escalate privileges or enable lateral movement.
T1136prevents — A.5.26's designated competent incident response team, once an incident is underway, contains spread (a), coordinates to minimize consequences (f), and explicitly identifies/manages the vulnerabilities/weaknesses that caused/contributed/failed to prevent it (j) — which directly stops the adversary's Create Account persistence technique from continuing or recurring on affected systems.
T1136responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment, evidence collection, escalation, logging, communication, coordination, forensic analysis, root-cause identification, and vulnerability/weakness management (including those that allowed the incident), which directly matches the `responds` verb for an already-executed T1136 account creation.
T1136.001prevents — A.5.26's designated competent team responding to an incident (including containment, evidence collection, escalation, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that enabled it) stops the adversary from successfully using the newly-created local account for persistence.
T1136.001responds — A.5.26 requires a designated competent team to respond to incidents (including containment, eradication, forensic analysis, root-cause identification, and vulnerability/weakness management per items a–j), which directly addresses an already-underway T1136.001 account-creation event once detected; the named remainder is that the technique may complete and the account may be used before response begins.
T1136.002prevents — A.5.26's designated competent team responding to an incident (including containment, evidence collection, escalation, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that allowed the incident) stops the adversary from successfully using the newly-created domain account for persistence, which is what `prevents` asserts for this post-compromise technique.
T1136.002responds — A.5.26 requires a competent team to respond to an already-underway incident (containment, eradication, evidence, escalation, closure, root-cause analysis, and managing the vulnerabilities/weaknesses that enabled it), which directly matches the post-creation persistence technique of T1136.002 once it has executed.
T1136.003prevents — A.5.26's designated competent team and explicit steps (a) contain spread, (c) escalate/invoke continuity, (f) coordinate externally, and (j) identify/manage the vulnerabilities/weaknesses that enabled the account creation directly stop the technique from completing its persistence goal in most cases once the incident is underway.
T1136.003responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, close, and perform post-incident analysis on an information security incident once underway, which directly matches the act of responding to an adversary-created cloud account (T1136.003) that has already been deployed for persistence.
T1137detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, post-incident root-cause analysis and communicating details once an incident is underway, which can surface Office-application startup persistence (e.g. via anomalous add-in behavior or macro execution) when it produces observable artifacts on the organization's estate; it does not detect pre-compromise setup of the mechanisms themselves.
T1137prevents — A.5.26's designated competent team responding to an incident (including containment, eradication via vulnerability/weakness management in (j), root-cause analysis, and closure) stops the T1137 persistence from surviving or recurring after it has been used to start an Office application, which is what `prevents` asserts for a post-compromise technique; the named remainder is that it does not stop the initial abuse before detection.
T1137responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis and vulnerability management — all of which directly address an already-realized T1137 persistence technique without preventing its initial execution.
T1137.001detects — A.5.26 requires monitoring for and response to incidents (including logging, forensic analysis, and post-incident root-cause identification), which can surface the execution of a malicious Office template macro as an incident; however, the control's scope is set by organizational procedures and does not mandate detection of this specific persistence technique.
T1137.001prevents — A.5.26's incident-response procedures (containment, evidence collection, root-cause analysis, vulnerability/weakness remediation including failed controls) can prevent the T1137.001 persistence technique from recurring after an initial incident, but do nothing to stop its first use on a clean system.
T1137.001responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment (a), evidence collection (b), escalation (c), logging (d), communication (e), coordination (f), closure (g), forensics (h), root-cause analysis (i), and vulnerability/weakness management (j) — all of which apply once a T1137.001 persistence macro has executed on startup.
T1137.002detects — A.5.26 requires monitoring for and response to incidents (including logging, forensic analysis, and post-incident root-cause identification), which can surface the anomalous Office Test Registry abuse once it has executed and manifested as an incident, but does not mandate proactive detection mechanisms or coverage of this specific persistence technique.
T1137.002prevents — A.5.26's incident-response procedures (containment, evidence collection, escalation, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that caused/contributed/failed-to-prevent the incident) can stop the Office Test persistence from being (re)established after first detection, which is what `prevents` asserts for a post-compromise technique; the slice is genuine but minority because the control activates only after the technique has already run at least once.
T1137.002responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis and vulnerability management — all of which apply once the Office Test persistence technique has executed and is detected as an information security incident.
T1137.003detects — A.5.26 requires a designated team to respond to incidents (including detection triggers, logging, analysis, and post-incident root-cause/vuln identification), which surfaces the T1137.003 persistence technique once it has executed via crafted email or Outlook startup; scope is limited to incident response rather than continuous proactive detection.
T1137.003prevents — A.5.26's incident response procedures (containment, forensic analysis, root-cause identification, vulnerability/weakness management including failed controls) directly prevent the T1137.003 persistence technique from recurring after initial compromise by addressing the malicious form and related weaknesses.
T1137.003responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis and vulnerability management — all of which directly address an in-progress T1137.003 persistence technique that has already placed malicious forms.
T1137.004detects — A.5.26 explicitly requires logging of response activities, communicating incident details, conducting forensic analysis, performing post-incident root-cause analysis, and identifying related vulnerabilities/weaknesses, all of which surface knowledge of an already-executing T1137.004 persistence technique.
T1137.004prevents — A.5.26's incident-response procedures (containment, evidence collection, escalation, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that caused/contributed/failed-to-prevent the incident) can stop the T1137.004 persistence from being (re)established after initial discovery, but the clause is silent on proactive blocking of the initial mailbox modification or HTML execution that plants the technique.
T1137.004responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis and vulnerability/weakness remediation — all of which directly address an in-progress T1137.004 persistence technique that has already executed malicious code on folder load.
T1137.005detects — A.5.26's response activities include collecting evidence, logging, communicating, coordinating, closing/recording, root-cause analysis and identifying related weaknesses, all of which can surface the presence of malicious Outlook rules once the crafted email has triggered them on the compromised system; however, the technique's pre-compromise setup (rule creation) and its execution on the victim's client have no guaranteed observable event inside the organization's monitored estate, so only a slice is detected.
T1137.005prevents — A.5.26's incident response procedures (containment, escalation, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that enabled the incident) stop the Outlook Rules persistence technique from continuing or recurring once it has been detected.
T1137.005responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis and vulnerability management — all of which directly address an active T1137.005 persistence technique that has already been deployed via malicious Outlook rules.
T1137.006detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause identification and post-incident review, all of which can surface the presence of a malicious Office add-in once it has executed on a compromised system; however, the technique's pre-execution installation (registry, file drop) and its Office-startup trigger sit outside the organization's monitored estate until triggered, and the clause's scope is set by business requirements rather than mandating universal coverage of persistence mechanisms.
T1137.006prevents — A.5.26's incident response procedures (containment, forensic analysis, root-cause identification, vulnerability/weakness management) directly prevent the add-in persistence technique from continuing or recurring once it has been detected as an incident.
T1137.006responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis and vulnerability management — all of which directly address an already-installed add-in executing on application start.
T1176prevents — A.5.26's designated competent team and procedures for containing spread (a), coordinating with external parties (f), identifying/managing vulnerabilities/weaknesses that caused/contributed/failed to prevent the incident (j), and post-incident root-cause work directly stop the T1176 technique from achieving or sustaining persistence once underway.
T1176responds — A.5.26 explicitly requires a designated competent team to respond to incidents (including containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis and vulnerability/weakness management), which matches the post-breach response lane for a T1176 extension-based persistence incident once it is underway.
T1176.001detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, post-incident root-cause work and communicating details once an incident is known; these can surface a malicious browser extension that has already achieved persistence or is actively stealing data/C2, but the clause has no mechanism to observe pre-compromise installation steps (e.g. silent file edits or app-store masquerading) and many extensions produce no observable incident until later misuse.
T1176.001prevents — A.5.26's designated competent team and procedures for containing spread (a), coordinating with parties to minimize consequences (f), and identifying/managing vulnerabilities/weaknesses that caused/contributed/failed to prevent the incident (j) stop the browser-extension technique from achieving its persistence, C2, or stealth goals once underway, with a bounded remainder of pre-response installation and impact.
T1176.001responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, close, and perform post-incident/root-cause analysis on an already-underway incident, which matches the `responds` verb once a malicious browser extension has achieved persistence or is executing.
T1176.002prevents — A.5.26's designated competent incident-response team, containment (a), evidence collection, escalation, logging, coordination, forensic analysis, root-cause identification, and explicit management of vulnerabilities/weaknesses that contributed to or failed to prevent the incident directly stop the IDE-extension persistence technique from continuing or recurring once it has begun.
T1185detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause identification and communicating details once an incident is underway; browser session hijacking (especially via process injection or proxying inside the browser) produces observable artifacts on the victim's Windows system that can be surfaced by competent incident response, but the pre-compromise acquisition of the domain or initial foothold sits outside the organization's estate and many of the ten listed activities have no object to act on.
T1185prevents — A.5.26's designated competent team and explicit steps (a) contain spread, (c) escalate/invoke continuity, (f) coordinate to minimize consequences, and (j) identify/manage the vulnerabilities/weaknesses that enabled the hijacking directly stop the technique from completing its full effect once underway, though the initial injection may still occur before response begins.
T1185recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability management in j, formal closure) enable recovery of security posture after the hijacking technique has run, with the named remainder being direct restoration of any hijacked sessions, cookies or browser state.
T1185responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, analyze root cause/vulnerabilities/weaknesses, and formally close an incident once underway, which matches the `responds` verb against a realized T1185 hijacking.
T1187detects — A.5.26's response activities (evidence collection, logging, forensic analysis, post-incident root-cause) can surface the forced-authentication event and its artifacts once it occurs on the organization's estate, but the technique's pre-compromise delivery (e.g. external spearphishing link or .SCF on public share) often leaves no internal vantage point until after credential material has already left the boundary.
T1187prevents — incident response procedures that contain affected systems, coordinate with parties, manage related vulnerabilities/weaknesses, and invoke continuity plans can stop the forced-authentication technique from completing or recurring after initial detection
T1187responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, analyze root cause, and close an information security incident once underway, which directly matches the `responds` verb for a technique that has already executed to harvest credentials.
T1189detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause identification and communicating the incident once it has occurred, which surfaces knowledge of a realized drive-by compromise; however the pre-compromise delivery (watering-hole site compromise, malvertising, push-notification abuse) sits outside organizational monitoring scope and leaves most of the technique unseen until after execution.
T1189prevents — A.5.26 requires a designated competent team and explicit procedures that include containing spread (a), coordinating to minimize consequences (f), and identifying/managing the vulnerabilities/weaknesses that enabled the incident (j) — directly stopping a successful drive-by from achieving its full intended effect or recurring, though the initial browser exploit step itself is not blocked by response procedures.
T1189responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, escalate, communicate, coordinate, close, forensically analyze, and post-analyze an information security incident once underway, which matches the definition and bounds of `responds` for a realized drive-by compromise.
T1190detects — A.5.26's response activities (evidence collection, logging, post-incident analysis, root-cause identification, and vulnerability management) can surface the fact that a public-facing exploit occurred once it has reached the organization, but pre-compromise reconnaissance, the exploit delivery itself, and many edge/appliance cases produce no organizational event for the incident team to observe.
T1190prevents — A.5.26 requires a designated competent team and explicit procedures that include containing spread (a), coordinating to minimize consequences (f), identifying/managing the vulnerabilities/weaknesses that caused or failed to prevent the incident (j), and post-incident root-cause work; this stops the T1190 technique from completing its full intended effect in most cases once underway, though it does not stop the initial exploit attempt itself.
T1190responds — A.5.26's response activities (contain, evidence, log, communicate, coordinate, close, forensics, root-cause, manage weaknesses) engage once an exploit has occurred on the organization's estate, but many T1190 cases (e.g., initial access via edge appliances, cloud metadata, or non-owned public apps) leave no affected internal system or artifact for the core contain/eradicate steps to act on.
T1195prevents — A.5.26's designated competent team, containment (a), coordination with suppliers/clients (f), vulnerability/weakness management (j), and post-incident root-cause work directly stop the technique from completing or recurring in the supply chain once an incident is recognized.
T1195responds — A.5.26's response activities (containment, evidence collection, logging, communication, coordination, closure, forensics, root-cause analysis, and managing related vulnerabilities) engage once a supply-chain compromise reaches the organization, but several pre-receipt or second-order stages (e.g., factory-infected media, compromised open-source dependencies before integration, or upstream distribution manipulation) leave no affected internal system, artifact, or evidence for the designated team to act on.
T1195.001prevents — A.5.26's designated competent incident-response team, containment (a), escalation/crisis invocation (c), coordination with suppliers/clients (f), and explicit post-incident identification/management of the vulnerabilities/weaknesses that caused or failed to prevent the incident (j) stop the supply-chain technique from reaching further victims or second-order compromise once the first instance is known.
T1195.001responds — A.5.26's response activities (containment, evidence collection, logging, coordination, root-cause analysis, vulnerability management) engage once a supply-chain compromise reaches an affected build pipeline, repo or runtime environment on the organization's estate, but the pre-receipt and distributed nature of the technique leaves many instances with no reachable affected system or artifact for core containment/eradication.
T1195.002prevents — A.5.26's designated competent incident-response team, containment (a), coordination with suppliers/clients (f), vulnerability/weakness management (j), and post-incident root-cause work directly stop the supply-chain manipulation technique from reaching additional victims or completing its downstream effects once initial compromise indicators appear.
T1195.002responds — A.5.26's response activities (contain, eradicate, log, communicate, root-cause, manage weaknesses) engage once a supply-chain compromise reaches the organization, but several core mechanics (pre-receipt manipulation of source, updates, or builds) leave no on-premises artifact, affected system, or evidence for containment/eradication/forensics, making the verb's core only a slice.
T1195.003prevents — A.5.26's incident response procedures (containment, forensic analysis, root-cause identification, vulnerability management) can prevent the supply-chain backdoor from achieving its full effect once discovered, but do not stop the adversary from initially manipulating hardware/firmware in the supply chain before any incident occurs.
T1197detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause, vulnerability management) can surface BITS job abuse once it has produced observable artifacts on the organization's estate, but the pre-compromise technique (creating/managing jobs via COM/PowerShell) has no guaranteed event on the estate and many activities have an empty object
T1197prevents — A.5.26's designated competent team and explicit procedures for containing spread, coordinating with parties, managing vulnerabilities/weaknesses that enabled the incident, and performing root-cause analysis directly constrain the successful execution or persistence of a BITS abuse technique once it is recognized as (or while becoming) an information security incident.
T1197recovers — A.5.26's post-incident analysis, root-cause documentation, vulnerability/weakness management (including failed controls), and formal closure directly enable recovery of organizational state and prevention of recurrence after a BITS abuse incident has run its course.
T1197responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, escalate, close, and perform post-incident/root-cause analysis on an information security incident once underway, which directly matches the act of responding to a BITS-abuse technique that has already executed.
T1199prevents — A.5.26's designated competent team, containment (a), coordination with suppliers/clients (f), and explicit management of vulnerabilities/weaknesses that failed to prevent the incident (j) stop the trusted-relationship technique from reaching or spreading to the victim organization in the great majority of cases once the initial breach of the third party is known.
T1199responds — A.5.26's response activities (containment, evidence collection, logging, communication, coordination, closure, root-cause analysis, vulnerability management) engage once a trusted-relationship breach has occurred on the victim's estate, but several core scenario elements (e.g. compromise of an external partner's account or delegated admin offer before it reaches the victim) sit outside the victim's observable incident surface and cannot be contained or eradicated by them.
T1201prevents — A.5.26's incident response (containment, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that allowed the incident) directly stops the adversary from completing the discovery -> password-list -> brute-force chain once the technique has begun, which is what `prevents` asserts in the event-lane anchors; the named remainder is pre-incident discovery that has not yet triggered response.
T1203detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause identification) surface the incident once exploitation has occurred and is underway, but the pre-compromise technique (vulnerability research and delivery) has no affected system or evidence on the organization's estate until execution succeeds
T1203prevents — A.5.26's designated competent team, containment (a), coordination (f), vulnerability/weakness management (j) and post-incident root-cause work directly stop the client-execution technique from completing or recurring once it has begun, with the bounded remainder being the initial exploit delivery that occurs before response is triggered.
T1203responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, analyze root cause/vulnerabilities/weaknesses that enabled the incident, and formally close it once addressed — all core to responding once T1203 exploitation is underway.
T1204detects — A.5.26's response activities (evidence collection, logging, post-incident analysis, root-cause identification) can surface that a user executed malicious code, but only after the technique has already succeeded and produced observable incident artifacts; pre-execution or in-flight detection of the user action itself is outside its scope.
T1204prevents — A.5.26's designated competent team, containment (a), coordination (f), forensic/root-cause analysis (h/i), and explicit post-incident identification+management of the vulnerabilities/weaknesses that enabled the incident (j) directly stop the user-execution technique from recurring on the affected systems and across the organization.
T1204responds — A.5.26 explicitly requires a competent team to respond to incidents (including containment, eradication, logging, escalation, and post-incident root-cause/vulnerability management once the user-execution technique has run and delivered impact), matching the `responds` verb definition; the named remainder is that some social-engineering delivery vectors may be contained before full execution occurs.
T1204.001detects — A.5.26's response activities (evidence collection, logging, post-incident analysis, root-cause identification) can surface the user click and follow-on execution once the incident is underway, but the pre-compromise delivery (social engineering, link click) has no affected system or evidence on the estate until after execution occurs
T1204.001prevents — A.5.26's designated competent team responding to an incident (including containment, evidence collection, escalation, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that caused/contributed/failed to prevent it) stops the malicious-link technique from completing its full intended effect in most cases once the initial click has occurred.
T1204.001responds — A.5.26 requires a designated competent team to respond to incidents (containment, eradication, evidence collection, escalation, post-incident root-cause analysis, and vulnerability/weakness remediation), which directly addresses a T1204.001 execution event once the malicious link has been clicked and follow-on code execution or exploitation is underway.
T1204.002detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause identification) can surface the user-opened malicious file once it has executed and produced observable effects, but the technique's core delivery (user opening the file) occurs with no guaranteed organizational event or vantage point for many delivery vectors.
T1204.002prevents — A.5.26's designated competent team and explicit procedures for containing spread (a), coordinating with parties to minimize consequences (f), and identifying/managing the vulnerabilities/weaknesses that enabled the incident (j) stop the malicious-file technique from completing its full intended effect in most cases once it is underway, satisfying the verb as used for incident-response controls in the event-lane anchors.
T1204.002responds — A.5.26 explicitly requires a designated competent team to respond to incidents (including containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis, and vulnerability management once the incident is underway), which directly matches the act of responding to a T1204.002 execution event that has already occurred.
T1204.003detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause identification) can surface the malicious image once it has executed and produced observable effects on the affected system, but the technique's pre-execution upload and naming steps occur entirely outside the organization's estate with no required vantage point in the clause.
T1204.003prevents — A.5.26's designated competent team and procedures for containing spread (a), coordinating with external parties (f), identifying/managing vulnerabilities/weaknesses that contributed or failed to prevent (j), and post-incident root-cause work directly stop the malicious-image technique from succeeding or recurring at scale once an incident is recognized.
T1204.003responds — A.5.26 requires a competent team to respond to incidents (once underway) via containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis and vulnerability management — all of which directly address a T1204.003 execution event that has already occurred in an IaaS/container environment.
T1204.004detects — A.5.26's response activities include collecting evidence, logging, communicating, coordinating, closing/recording, root-cause analysis and identifying related weaknesses, all of which engage once a user has performed the copy-paste execution and an incident is underway on the organization's estate; it does not detect the social-engineering lure or pre-execution stage itself.
T1204.004prevents — A.5.26 requires a designated competent team to respond to incidents once underway (containment, eradication, root-cause analysis, vulnerability/weakness remediation per item j), which stops the T1204.004 social-engineering technique from completing its full objective on affected systems and prevents recurrence via identified controls; it does not stop the initial user copy-paste action itself.
T1204.004responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment (a), evidence collection (b), escalation (c), logging (d), communication (e), coordination (f), closure (g), forensics (h), root-cause analysis (i), and vulnerability/weakness management (j), which directly matches the post-execution response lane for a social-engineering-driven execution technique like T1204.004; the named remainder is that the initial user action and foothold may already be realized before response begins.
T1204.005detects — A.5.26 requires a designated competent team to respond to incidents (including detection via reported anomalies or indicators), but its scope is limited to post-occurrence response procedures rather than proactive or broad detection of malicious library installation techniques.
T1204.005prevents — A.5.26's designated competent incident-response team, with its explicit steps to contain spread (a), coordinate with suppliers/clients (f), identify/manage vulnerabilities/weaknesses that contributed or failed to prevent the incident (j), and perform root-cause analysis (i), directly stops the malicious-library technique from completing its full execution chain in most observed cases once the installation is noticed as an incident.
T1204.005responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment (a), evidence collection (b), logging (d), escalation (c), communication (e), coordination (f), forensic analysis (h), root-cause post-incident review (i), and vulnerability/weakness remediation (j), which matches the definition of responds for a supply-chain library installation technique that has already executed malicious code.
T1205detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause) can surface the signaling packets or triggered behavior once they reach the organization's monitored estate, but the technique's pre-compromise, external, or embedded-device signaling (e.g. port knocking on closed ports, raw sockets, Wake-on-LAN, network-device crafted packets) frequently has no organizational event or vantage point for the incident response team to observe.
T1205responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment, evidence collection, escalation, logging, communication, coordination, forensic analysis, root-cause identification, and post-incident remediation of related vulnerabilities/weaknesses, which directly matches the act of responding to an in-flight T1205 technique (e.g., containing spread, analyzing signals, closing the incident).
T1205.001detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause identification) can surface port-knocking signals or the opened port once the sequence is observed on the organization's estate, but the pre-compromise knock itself occurs on external infrastructure or via raw sockets/libpcap that may lie outside the defined monitoring scope, leaving a large slice undetected.
T1205.001responds — A.5.26 requires a designated competent team to respond to incidents (containment, eradication, evidence collection, logging, escalation, post-incident root-cause analysis and vulnerability management), which directly addresses a realized T1205.001 port-knocking incident once underway; the named remainder is that the initial hidden-port activation itself is not undone by response.
T1205.002detects — A.5.26 explicitly requires logging of response activities, forensic analysis, post-incident root-cause analysis, and communication of incident details, all of which surface the socket-filter technique once it has triggered (via packet receipt and backdoor activation).
T1205.002prevents — A.5.26's designated competent team and procedures for containing spread (a), coordinating with external parties (f), and managing vulnerabilities/weaknesses that caused/contributed/failed to prevent the incident (j) stop the socket filter technique from completing its activation of backdoors/C2/persistence in most cases once any observable precursor or partial execution occurs.
T1205.002recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability/weakness management in j, formal closure) restore the system to a secure state after the T1205.002 technique has run and activated its backdoor.
T1205.002responds — A.5.26's designated competent team and enumerated activities (contain spread, collect/analyze evidence, log, escalate, communicate, coordinate, close/record, forensics, root-cause, manage resulting weaknesses) engage once the filter is present and the triggering packet arrives, acting on the realized backdoor/persistence/C2 event.
T1207prevents — A.5.26's designated competent team and explicit procedures for containing spread (a), evidence collection (b), forensic analysis (h), root-cause identification (i), and managing the vulnerabilities/weaknesses that enabled the incident (j) directly stop a rogue-DC registration from completing or replicating when the incident is recognized in flight, with the bounded remainder being the stealth/evasion slice that bypasses logging before detection occurs.
T1207recovers — A.5.26's post-incident analysis, root-cause documentation, vulnerability/weakness management (including failed controls), and formal closure directly enable recovery of the AD environment after a rogue DC has been used to inject/persist changes.
T1207responds — A.5.26 explicitly requires a competent team to contain (a), collect/analyze evidence and perform forensics (b,h), log activities (d), escalate/invoke continuity (c), communicate (e,f), close/record (g), identify root cause (i), and manage the vulnerabilities/weaknesses that enabled the incident (j) — all of which match the post-registration manipulation, logging bypass, forensic obstruction, and persistence-backdoor aspects of T1207 once the technique is underway.
T1210detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause identification and communicating the incident once it is underway, which can surface T1210 exploitation of remote services that has reached the organization's estate; however, the technique's pre-compromise discovery and initial exploitation steps (e.g. on external or registrar infrastructure) provide no affected system or evidence for those activities to engage.
T1210prevents — A.5.26's designated competent team, containment (a), coordination (f), forensic/root-cause analysis (h/i), and explicit identification+management of the vulnerabilities/weaknesses that caused/contributed/failed to prevent the incident (j) directly stop the same exploitation technique from recurring on the affected and peer systems.
T1210responds — A.5.26 explicitly requires a designated competent team to contain (a), eradicate via root-cause/vuln fixes (i,j), log/analyze (d,i), and coordinate (f) an incident once underway, which directly matches the `responds` verb for a post-compromise lateral-movement exploit technique.
T1211prevents — A.5.26's designated competent team, containment, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that caused/contributed/failed to prevent the incident directly stops the stealth-exploitation technique from continuing or recurring once it has begun.
T1211recovers — A.5.26's post-incident analysis, root-cause identification, vulnerability management (j), forensic work and formal closure directly restore visibility, re-enable suppressed logging/monitoring, and address the stealth foothold after the exploitation technique has already run.
T1211responds — A.5.26's designated competent team and procedures for containment, eradication, evidence collection, logging, coordination, forensic analysis, root-cause identification, and vulnerability management directly act on an in-flight T1211 exploitation to bound its spread, remove the foothold/stealth artifacts, and address enabling weaknesses once the incident is underway.
T1212detects — A.5.26 explicitly requires a designated competent team to respond to incidents (including detection triggers, evidence collection, logging, forensic analysis, and post-incident root-cause identification), which surfaces T1212 exploitation once it has produced observable incident indicators.
T1212prevents — A.5.26's designated competent team, containment (a), forensic/root-cause analysis (h/i), vulnerability identification (j), and coordination directly stop the exploitation technique from completing or recurring once underway, with a named remainder that the incident must first be detected to trigger response.
T1212recovers — A.5.26's post-incident analysis, root-cause identification, vulnerability management (j), forensic work and formal closure directly restore control posture and organizational state after the credential-exploitation technique has run, matching the recovers verb; the named remainder is any already-stolen credentials whose direct misuse cannot be undone by response alone.
T1212responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, analyze root cause, and close an information security incident once underway, which directly matches the act of responding to T1212 exploitation that has already occurred.
T1213detects — A.5.26 explicitly requires logging response activities, evidence collection, forensic analysis, and post-incident root-cause analysis, all of which surface the T1213 technique (and its artifacts) once it has run.
T1213recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability/weakness management in j, formal closure, and coordination) enable recovery of the repository's security posture and data access controls after the mining technique has run, though the already-exfiltrated information itself is not restored.
T1213responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, analyze root cause, and close an information security incident once underway, which directly matches the `responds` verb against an adversary mining or exfiltrating data from an information repository.
T1213.001prevents — A.5.26 requires a designated competent team to respond to incidents once underway (containment, eradication, root-cause analysis, vulnerability remediation), which prevents the T1213.001 technique from continuing or recurring by removing the adversary's access and fixing the exposure that enabled repository mining.
T1213.001recovers — A.5.26 requires post-incident root-cause analysis, vulnerability/weakness remediation (including failed controls), and formal closure; this restores the organization's defensive posture after the Confluence mining technique has already succeeded in exfiltrating information.
T1213.001responds — A.5.26's designated team and enumerated activities (contain, evidence, log, communicate, coordinate, close, forensics, root-cause, manage weaknesses) engage once an adversary is already mining Confluence for information; the technique has run and response bounds its spread and eradicates footholds.
T1213.002prevents — A.5.26 requires a designated competent team to respond to incidents once underway (containment, evidence, escalation, communication, forensic analysis, root-cause identification, and explicit remediation of the vulnerabilities/weaknesses that caused/contributed/failed to prevent it), which stops the SharePoint mining technique from continuing or recurring; the named remainder is the initial exfiltration of already-mined data before response begins.
T1213.002recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability management in j, formal closure) restore organizational readiness and address the exposure of mined SharePoint data after the technique has run, though they do not restore the already-exfiltrated information itself.
T1213.003prevents — A.5.26's designated competent team, containment (a), escalation (c), coordination (f), and post-incident root-cause/vulnerability management (i,j) directly stop the adversary's ongoing collection from the repository and prevent successful follow-on exploitation of harvested code or credentials.
T1213.003recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability/weakness management in j, forensic analysis, and formal closure) enable recovery of the repository's integrity and prevent re-exfiltration after the data-collection technique has run.
T1213.004prevents — A.5.26's designated competent team, containment (a), coordination (f), and post-incident root-cause/vulnerability management (i,j) directly stop the adversary's post-breach mining of CRM data from continuing or recurring, though the technique can still run before response is invoked.
T1213.004recovers — A.5.26 response procedures (containment, evidence, escalation, logging, communication, forensics, post-incident analysis, root-cause fixes) act on the incident once underway but do not restore any pre-incident state destroyed by T1213.004 data mining
T1213.005detects — A.5.26's response activities (evidence collection, logging, post-incident analysis, root-cause identification, and forensic analysis) can surface the use of messaging apps for data mining or IR evasion once the incident is already underway on the organization's estate, but pre-compromise external acquisition or use outside monitored internal channels leaves most of the technique unseen.
T1213.005prevents — A.5.26's procedures for containing spread, coordinating with parties, communicating need-to-know, and managing vulnerabilities/weaknesses that failed to prevent the incident directly stop the adversary from successfully leveraging messaging data to evade ongoing IR or improve targeting, though some initial mining may occur before response activates.
T1213.005recovers — A.5.26's post-incident analysis, root-cause identification, vulnerability/weakness management (including failed controls), and formal closure directly restore organizational posture after the technique has run and data has been mined from messaging apps (e.g., by addressing exposed credentials, leaked proprietary data, or IR-evasion insights).
T1213.005responds — A.5.26 explicitly requires a designated competent team to respond to incidents (including containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis, and vulnerability management), which directly addresses the T1213.005 sub-technique of adversaries leveraging messaging apps to mine discussions about ongoing incident response efforts in order to evade them.
T1213.006prevents — A.5.26's designated competent team, containment (a), escalation (c), coordination (f), forensic/root-cause analysis (h/i), and explicit post-incident identification+management of the vulnerabilities/weaknesses that enabled the incident (j) directly stop the database-mining technique from continuing or recurring on the same or similar vectors.
T1213.006recovers — A.5.26 response procedures (containment, evidence, escalation, logging, communication, forensics, post-incident analysis, root-cause fixes) act on the incident once underway but do not restore any pre-incident state destroyed by database mining/exfiltration; recovery of data or systems is outside its defined scope (see A.8.13 anchors for the recovers lane).
T1213.006responds — A.5.26 explicitly requires a designated competent team to respond to incidents (including containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis, and vulnerability management), which directly matches the post-breach response lane once database mining (T1213.006) is already underway.
T1216detects — A.5.26's response activities (evidence collection, logging, forensic analysis, post-incident root cause) can surface T1216 once it has run on the organization's estate, but the clause's scope is limited to incidents that have already been identified and does not mandate proactive monitoring that would reliably catch the technique in flight.
T1216prevents — A.5.26's designated competent incident-response team, once an incident is underway, contains spread (a), coordinates to minimize consequences (f), and explicitly identifies/manages the vulnerabilities/weaknesses that enabled the incident (j) — which for T1216 means removing or hardening the signed proxy scripts that allow bypass, thereby stopping the technique from succeeding again.
T1216recovers — A.5.26's post-incident analysis, root-cause documentation, vulnerability/weakness management (including failed controls), and formal closure directly restore the security posture after a T1216 execution has occurred.
T1216responds — A.5.26 requires a competent team to respond to incidents once underway via containment, eradication, evidence collection, logging, escalation, and post-incident root-cause/vulnerability management, which directly matches the technique's execution and its bypass of controls.
T1216.001detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause investigation and communicating details of an incident that has already occurred; these can surface the use of PubPrn.vbs as the delivery or execution vector once it has run on a Windows system inside the monitored estate, but the control's scope is limited to post-occurrence response and does not instrument or observe the technique itself.
T1216.001prevents — A.5.26's designated competent team following defined procedures for containment, evidence collection, escalation, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that enabled the incident (item j) stops the PubPrn proxy-execution technique from being repeatable on the affected systems.
T1216.001recovers — A.5.26 response procedures (containment, evidence, escalation, logging, communication, forensics, post-incident analysis, root-cause fixes) act on the incident once underway but do not restore any pre-incident state destroyed by the T1216.001 technique
T1216.001responds — A.5.26's response activities (containment, evidence collection, logging, coordination, root-cause analysis, vulnerability management) engage once a PubPrn proxy-execution incident is underway on the estate, but several core steps (e.g. containing spread, crisis escalation, forensics) have limited or no object when the technique is a local signed-script abuse that does not spread or leave obvious artifacts
T1216.002detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause, vulnerability management) can surface the technique once it has executed on an organizational Windows system, but the pre-compromise technique occurs on the adversary's infrastructure or via signed LOLBin proxying that leaves no guaranteed observable on the victim's estate until after execution
T1216.002prevents — A.5.26's designated competent team and documented procedures for containing spreading incidents, coordinating with parties, and managing vulnerabilities/weaknesses that enable the technique (including failed controls) stop most instances of this signed LOLBin proxy execution from succeeding or recurring, with the named remainder being pre-containment execution that has already occurred.
T1216.002responds — A.5.26's designated competent team and enumerated activities (contain spread, collect/analyze evidence, log, communicate, coordinate, close/record, root-cause, manage related weaknesses) engage once the SyncAppvPublishingServer.vbs abuse is underway on the estate; the named remainder is that the pre-compromise delivery step itself is outside response scope.
T1217prevents — A.5.26's designated competent team, containment (a), evidence collection (b), logging (d), coordination (f), forensic analysis (h), root-cause post-incident review (i), and explicit identification/management of vulnerabilities/weaknesses that failed to prevent the incident (j) directly stop the T1217 discovery technique from completing or recurring once an incident is recognized.
T1218prevents — A.5.26's designated competent incident-response team, once an incident is underway, contains spread (a), coordinates to minimize consequences (f), and explicitly identifies/manages the vulnerabilities/weaknesses (including failed controls) that enabled the proxy-execution technique (j), thereby stopping further instances of T1218 from succeeding.
T1218responds — A.5.26 requires a designated competent team to respond to incidents once underway (containment, eradication, evidence, escalation, logging, closure, root-cause analysis), which directly matches the act of responding to a T1218 execution that has already occurred.
T1218.001detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause identification and communicating details of an already-underway incident; these surface knowledge of T1218.001 execution (e.g. via hh.exe anomalies or CHM payload artifacts on the victim's estate) but the pre-compromise acquisition and delivery steps sit outside the organization's observable boundary, leaving a large remainder untouched.
T1218.001prevents — A.5.26's designated competent team and explicit procedures for containing spread, coordinating with parties, and managing the vulnerabilities/weaknesses that enabled the incident (including those that failed to prevent it) stop the T1218.001 technique from completing its full effect in most cases once underway.
T1218.001recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability management, formal closure, and coordination) enable recovery of organizational state and resilience after the T1218.001 technique has run and delivered impact.
T1218.001responds — A.5.26 explicitly requires a designated competent team to respond to incidents (once underway) via containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis and vulnerability/weakness management — all of which directly address a T1218.001 execution that has already occurred.
T1218.002detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause identification and communicating details of an already-underway incident, which can surface the use of control.exe / .cpl as the delivery or execution vector; however the technique occurs pre-compromise on the victim's workstation with no guaranteed organizational vantage (e.g. no boundary crossing, no mandatory telemetry on every .cpl load), so only a slice is detectable under the clause's scoped procedures.
T1218.002prevents — A.5.26's designated competent team and documented procedures for containing spread, coordinating with parties, and managing vulnerabilities/weaknesses that failed to prevent the incident constrain the T1218.002 technique once underway (especially delivery/execution phases), preventing full success in most cases per the event-lane anchor for the identical control vs T1486.
T1218.002recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability management in j, formal closure) enable recovery of control posture and organizational state after the T1218.002 execution has occurred, matching the recovers verb in the event lane.
T1218.002responds — A.5.26's designated competent team and enumerated activities (contain spread, collect/analyze evidence, log, communicate, coordinate, close/record, root-cause, manage related weaknesses) directly address a realized T1218.002 execution on the estate once underway, with the named remainder being pre-compromise delivery (e.g. the phishing vector) that falls to other verbs.
T1218.003detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause identification and post-incident review, all of which can surface CMSTP abuse once it has executed on an endpoint; however the clause's scope is set by organizational requirements and does not mandate endpoint telemetry that would reliably observe the technique, leaving a large remainder of undetected executions.
T1218.003prevents — A.5.26's designated competent team following defined procedures for containment, evidence handling, escalation, logging, communication, coordination, closure, forensics, root-cause analysis, and explicit identification/management of the vulnerabilities/weaknesses (including control failures) that enabled the CMSTP abuse directly stops the technique from recurring or spreading in the environment.
T1218.003responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, escalate, and formally close an incident once underway, which directly matches the act of responding to T1218.003 execution.
T1218.004detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause identification) can surface InstallUtil proxy execution when it has already occurred on the organization's estate, but the clause's scope is limited to post-incident response and does not require proactive monitoring of process execution or LOLBin usage.
T1218.004prevents — A.5.26 requires a designated competent team and explicit procedures that include containing spread, coordinating with parties to minimize consequences, and identifying/managing the vulnerabilities/weaknesses that allowed the incident; this directly stops the InstallUtil proxy-execution technique from completing its full intended effect once it begins, though it does not stop the initial execution itself.
T1218.004responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis and vulnerability management — all of which directly address an in-flight InstallUtil proxy-execution technique per the event-lane definition of responds.
T1218.005detects — A.5.26's response activities include collecting evidence, logging, communicating, coordinating, closing/recording, root-cause analysis and identifying weaknesses once an incident is underway; mshta.exe abuse on Windows is observable via process execution, command-line args or anomalous script behavior on the organization's estate, engaging several of those steps, but the pre-compromise acquisition/launch of the technique (and any incident that never reaches response) sits outside the control's scope.
T1218.005prevents — A.5.26's designated competent team following defined procedures for containment, evidence collection, escalation, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that enabled the incident (item j) stops mshta.exe abuse from recurring as a technique.
T1218.005recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability/weakness management in j, formal closure) enable recovery of organizational state and prevention of recurrence after the mshta abuse technique has run, with the named remainder being direct data/system restoration addressed by separate backup controls
T1218.005responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis and vulnerability management — all of which directly address an mshta.exe abuse incident that has already executed.
T1218.007detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause identification) can surface msiexec.exe abuse once it has occurred on the organization's estate, but the technique's pre-compromise acquisition/execution of an MSI or DLL has no inherent incident for the team to respond to until it produces observable effects.
T1218.007prevents — A.5.26's designated competent team and explicit procedures for containing spread, coordinating with parties, and managing vulnerabilities/weaknesses that enable the technique (including control failures) stop most instances of msiexec abuse from succeeding or recurring, though the clause is silent on hardening the AlwaysInstallElevated policy or application control ahead of time.
T1218.007responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis and vulnerability management — all of which apply once an adversary has already begun abusing msiexec.exe to proxy execution.
T1218.008detects — A.5.26's response activities include collecting evidence, logging, forensic analysis and post-incident root-cause work that can surface the use of a living-off-the-land binary such as odbcconf.exe once it has already executed on an endpoint; this is genuine detection of the technique, but only a slice because the clause's core is incident handling rather than continuous monitoring or endpoint telemetry and many executions will complete without triggering an incident response workflow.
T1218.008prevents — A.5.26's designated competent team and explicit procedures for containing spreading incidents, coordinating with parties, and managing the vulnerabilities/weaknesses that enabled the incident (including control failures) stop the T1218.008 technique from completing its full effect once it begins, though the initial proxy execution can still occur before response.
T1218.008responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment, evidence collection, escalation, logging, communication, coordination, forensic analysis, root-cause identification, and vulnerability/weakness management — all of which directly address an in-flight or post-execution proxy-execution technique like T1218.008.
T1218.009detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause identification and communicating details of an already-underway incident, which can surface the use of Regsvcs/Regasm when it occurs on the organization's estate; however the technique can be launched from outside the organization (e.g. via phishing or supply-chain compromise) with no local artifact for the response team to observe.
T1218.009prevents — A.5.26's designated competent incident-response team, once notified of the technique's use, contains affected systems (a), coordinates with internal parties to block further proxy execution, and identifies/manages the enabling vulnerability/weakness (j), stopping the technique from continuing or recurring on those systems.
T1218.009responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment, evidence collection, escalation, logging, communication, coordination, forensic analysis, root-cause identification, and post-incident vulnerability/weakness management, which directly matches the act of responding to a T1218.009 execution that has already occurred.
T1218.010detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause) can surface the technique once it has executed on an organizational Windows system, but the pre-compromise acquisition/execution step itself leaves no guaranteed observable on the organization's estate and many of the ten listed activities have an empty object.
T1218.010prevents — A.5.26 requires a designated competent team to respond to incidents once underway (containment, eradication, root-cause analysis, vulnerability/weakness remediation), which stops the Regsvr32 technique from continuing or recurring; it does not stop the initial execution.
T1218.010responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis and vulnerability management — all of which directly address an in-progress Regsvr32 abuse (T1218.010) without preventing its initial execution.
T1218.011detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause identification and post-incident review, all of which can surface rundll32.exe abuse once it has executed on an organizational Windows system; however the technique occurs entirely inside the organization's estate so the control's scope reaches it, but the clause itself only triggers on declared incidents and does not mandate continuous monitoring or specific detection instrumentation, leaving the majority of stealthy or pre-escalation uses unseen until they are already treated as incidents.
T1218.011prevents — A.5.26's designated competent team following defined procedures that explicitly include containing spread (a), coordinating to minimize consequences (f), identifying/managing the vulnerabilities/weaknesses that enabled the incident (j), and performing root-cause analysis (i) directly stops the rundll32 proxy technique from continuing or recurring in the environment once it has begun to run.
T1218.011responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment (a), evidence collection (b), escalation (c), logging (d), communication (e), coordination (f), closure (g), forensics (h), root-cause analysis (i), and vulnerability management (j), which bounds and eradicates an in-progress T1218.011 execution (e.g. proxying malicious DLL/script via rundll32) while the named remainder (impact already realized before containment) is handled by recovers controls such as backups.
T1218.012detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, and post-incident root-cause work that can surface the use of verclsid.exe as the proxy mechanism once it has executed on an endpoint; this is genuine but only a slice because the clause's core (containment, escalation, communication, coordination) has no object when the technique is pre-compromise living-off-the-land execution with no spreading consequences or affected systems yet identified.
T1218.012prevents — A.5.26's designated competent incident-response team, once notified of the technique (via monitoring or other means), contains spread (a), coordinates with parties to minimize consequences (f), and explicitly identifies/manages the enabling vulnerability/weakness (j) — which stops the proxy-execution technique from being repeatable; the named remainder is that the initial execution can still occur before response is triggered.
T1218.012responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment, evidence collection, escalation, logging, communication, coordination, forensic analysis, root-cause identification, and post-incident remediation of related vulnerabilities/weaknesses, all of which directly address an in-flight T1218.012 execution and its artifacts.
T1218.013detects — A.5.26's response activities include collecting evidence, logging, forensic analysis and post-incident root-cause work that can surface mavinject.exe abuse once it has produced observable artifacts on the organization's estate; the remainder is pre-compromise acquisition and use that leaves no organizational event to respond to.
T1218.013prevents — A.5.26 requires a designated competent team to respond under communicated procedures — containment and eradication of an event ALREADY UNDERWAY, which is the act `responds` names. The ransomware ran; responding bounds its spread and removes the foothold. `mostly`, with the remainder that marks the boundary to `recovers`: data encrypted BEFORE containment is not un-encrypted by responding to the incident
T1218.013recovers — A.5.26 response procedures (containment, evidence, escalation, logging, communication, forensics, post-incident analysis, root-cause fixes) act on the incident once underway but do not restore any pre-incident state destroyed by the T1218.013 technique
T1218.013responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment, evidence collection, escalation, logging, communication, coordination, forensic analysis, root-cause identification, and vulnerability/weakness management — all of which directly address an in-flight or realized T1218.013 abuse of mavinject.exe (with the named remainder being impact already realized before containment, bounded by the recovers verb).
T1218.014detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause identification and communicating details of an already-underway incident; these surface knowledge of MMC abuse (e.g. anomalous .msc execution or wbadmin catalog deletion) when it reaches the organization's estate, but the technique can be prepared and launched entirely outside monitored scope (e.g. pre-built malicious .msc on external systems or non-organizational infrastructure).
T1218.014prevents — A.5.26's designated competent team following defined procedures for containment, evidence handling, escalation, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that enabled the incident (including those that failed to prevent it) stops the MMC abuse technique from recurring on future attempts.
T1218.014recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability/weakness management in j, formal closure, and coordination) enable recovery from the technique's realized impact (e.g., deleted backup catalog via T1490) once the incident is contained and addressed.
T1218.014responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment (a), evidence collection (b), escalation (c), logging (d), communication (e), coordination (f), closure (g), forensics (h), root-cause analysis (i), and vulnerability/weakness management (j), which bounds and eradicates an in-progress T1218.014 abuse (e.g. after malicious .msc execution or wbadmin catalog deletion) with a named remainder of pre-containment impact already realized.
T1218.015detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause identification and communicating details once an incident is underway; these can surface Electron abuse when it produces observable artifacts on the organization's estate (e.g. anomalous child processes of teams.exe or Slack), but the technique's pre-compromise acquisition and planting of malicious JS occurs outside the organization's visibility and many executions leave no distinct incident trigger.
T1218.015prevents — A.5.26's designated competent team, containment (a), coordination (f), and post-incident root-cause/vulnerability management (i,j) directly stop the technique from recurring by addressing the abused Electron component or planted JS, with the named remainder being the initial execution before response begins.
T1218.015recovers — A.5.26's post-incident analysis, root-cause documentation, vulnerability/weakness management (including failed controls), and formal closure directly restore organizational state after the Electron-abuse technique has run, matching the recovers verb in the event lane (with the named remainder being any unaddressed data or system impact outside the incident closeout).
T1218.015responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment (a), evidence collection (b), escalation (c), logging (d), communication (e), coordination (f), closure (g), forensics (h), root-cause analysis (i), and vulnerability/weakness management (j) — all of which directly address an in-flight Electron abuse technique (T1218.015) without preventing its initial execution.
T1219detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause, communicating) can surface the presence and use of remote access tools once the incident is underway on the organization's estate, but many pre-compromise or external C2 uses of RATs (especially on non-owned infrastructure) leave no event for the team to respond to.
T1219prevents — A.5.26's designated competent incident response team, with procedures that explicitly include containing spread (a), coordinating with internal/external parties to minimize consequences (f), and identifying/managing vulnerabilities/weaknesses that failed to prevent the incident (j), directly stops legitimate remote access tools from being (further) abused post-compromise as a C2 channel.
T1219responds — A.5.26 explicitly requires a designated competent team to respond to incidents (including containment, eradication, coordination, and post-incident root-cause/vulnerability management once the technique is already underway), which matches the `responds` verb; the named remainder is that some post-compromise RAT use may be treated as authorized activity rather than an incident.
T1219.001detects — A.5.26 requires monitoring for and response to incidents (including logging, forensic analysis, and post-incident root-cause identification), which can surface IDE tunneling when treated as an incident but only within the scope of declared incident-response triggers and competencies, leaving broad undetected use outside that boundary
T1219.002detects — A.5.26's response activities (evidence collection, logging, post-incident analysis, root cause) can surface the use of remote desktop software once it has produced observable artifacts on the organization's estate, but pre-compromise acquisition/setup of the tool (outside the estate) and many in-band legitimate uses leave large slices undetected.
T1219.002prevents — A.5.26's designated competent team and explicit procedures for containing spread (a), coordinating with parties to minimize consequences (f), and managing vulnerabilities/weaknesses that failed to prevent the incident (j) stop legitimate desktop support software from being (re)used as C2 once detected, which is what `prevents` asserts for this technique; the named remainder is that the initial unauthorized installation/use can still occur before any response is triggered.
T1219.002responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis and vulnerability management — all of which directly address an active T1219.002 C2 session that has already begun.
T1219.003prevents — A.5.26's designated competent team and explicit procedures for containing spread (a), coordinating with parties (f), and managing vulnerabilities/weaknesses that failed to prevent the incident (j) stop the hardware C2 channel from continuing or being reused once the incident is recognized, which is what `prevents` asserts for a post-compromise technique; the named remainder is that it cannot stop the initial physical installation itself.
T1219.003responds — A.5.26's designated-team procedures for containment, eradication, evidence collection, logging, escalation, and post-incident root-cause/vulnerability management act on an already-underway T1219.003 hardware implant once detected, bounding spread and removing the actor's foothold while the named remainder (pre-containment impact already realized) is left for recovery controls.
T1220detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause, vulnerability management) can surface the technique once it has executed on the organization's Windows estate, but the pre-compromise acquisition/embedding of the XSL and the technique's use of trusted built-in binaries (msxsl.exe, wmic) leave large slices unseen by incident response.
T1220prevents — A.5.26's designated competent team, containment (a), coordination (f), and post-incident root-cause/vulnerability management (i,j) directly stop the XSL-scripting technique from recurring once it has been observed and escalated, which is what `prevents` asserts for an already-known technique; the named remainder is first-time/unobserved use before any incident exists to respond to.
T1221detects — A.5.26 requires a designated competent team to respond to incidents (including detection via reported anomalies, evidence collection, logging, and post-incident root-cause analysis), which surfaces T1221 once the document is opened and the template payload executes or forces auth; the remainder is pre-execution static concealment that evades typical indicators until fetch.
T1221prevents — A.5.26's designated competent team and documented procedures for containing spreading incidents, coordinating with external parties, and identifying/managing the vulnerabilities/weaknesses that caused or failed to prevent the incident directly stop T1221's post-delivery execution and further impact (including forced auth) once the document is opened, though it does not stop the initial document modification or delivery itself.
T1221recovers — A.5.26's post-incident analysis, root-cause identification, vulnerability management (j), forensic work and formal closure directly enable recovery actions that restore the organization from the effects of a realized T1221 incident (e.g., credential theft, executed payload, or follow-on compromise).
T1221responds — A.5.26's response activities (contain, evidence, log, communicate, coordinate, close, forensics, root-cause, manage weaknesses) engage once a delivered template-injected document is opened and the technique runs on the victim's system, but several core steps (a containment, h forensics, j weakness management) have no named artifact or system when the payload is fetched remotely via URL, leaving a large slice of the technique's mechanics untouched.
T1222prevents — A.5.26's designated competent incident-response team, once an incident is underway, contains affected systems (a), coordinates to minimize consequences (f), and explicitly identifies/manages the vulnerabilities/weaknesses (j) that enabled the permission modification, thereby stopping the T1222 technique from continuing or succeeding further.
T1222.002prevents — A.5.26's designated competent team responding to an incident (including containment, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that enabled it) stops the T1222.002 permission-modification technique from being repeatable by the same actor in the same environment.
T1222.002recovers — A.5.26's post-incident analysis, root-cause identification, vulnerability/weakness management (including failed controls), and formal closure enable recovery of the permission state altered by the T1222.002 technique once the incident is addressed.
T1480.001responds — A.5.26's response activities (containment, evidence collection, logging, forensics, root-cause analysis, vulnerability management) engage once an environmentally keyed payload executes and is detected on the estate, but the technique's core purpose is pre-execution concealment that slows or prevents discovery, leaving most of the verb's object (the incident itself) unrealized or invisible.
T1480.002prevents — incident response procedures that contain affected systems, collect evidence, coordinate externally, perform forensic/root-cause analysis, and explicitly identify/manage the vulnerabilities/weaknesses (including failed controls) that enabled the mutex-based instance check directly stop the technique from recurring on the same or other systems
T1484detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause identification) can surface the modification once it has occurred on the organization's estate, but the technique's pre-compromise nature (especially on external identity providers or registrar-like infrastructure) leaves many instances outside any organizational vantage point, matching the partial rung set by A.5.26 vs T1595.002.
T1484prevents — A.5.26's designated competent team and procedures for containing spread, coordinating with parties, managing related vulnerabilities/weaknesses, and post-incident root-cause work (including fixing failed controls) prevent the technique from recurring or succeeding at scale in future incidents, though initial execution before response begins is outside its scope.
T1484recovers — A.5.26's post-incident analysis, root-cause documentation, vulnerability/weakness management (including failed controls), and formal closure enable recovery of the secure state after T1484's policy modification has been executed and its malicious outcomes realized.
T1484responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, analyze root cause, close, and manage related vulnerabilities once an incident is underway, which directly matches the act of responding to T1484 after the policy modification has occurred.
T1484.001detects — A.5.26 requires monitoring for and response to incidents (including logging, forensic analysis, and post-incident root-cause identification), which can surface GPO modification as an incident but only after the technique has already run and only where the organization has chosen to instrument the relevant AD/SYSVOL paths and logs.
T1484.001prevents — A.5.26's designated competent team and explicit steps (a) contain spread, (c) escalate/invoke continuity, (f) coordinate externally, and (j) identify/manage the vulnerabilities/weaknesses that enabled the GPO modification directly stop the technique from completing its privilege-escalation or downstream-abuse goals once the incident is recognized.
T1484.001recovers — A.5.26's post-incident analysis, root-cause documentation, vulnerability/weakness management (including failed controls), and formal closure directly restore the intended GPO access-control state after the modification technique has run.
T1484.001responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, escalate, coordinate, close, and perform post-incident/root-cause analysis on an information security incident once underway, which directly matches the act of responding to an adversary's completed GPO-modification technique (and any downstream behaviors it enables).
T1484.002detects — A.5.26 explicitly requires a designated competent team to respond to incidents (including detection triggers, evidence collection, logging, forensic analysis, and post-incident root-cause identification), which surfaces trust modifications once they are treated as an information security incident.
T1484.002prevents — A.5.26's designated competent team responding to an incident (including containment, evidence collection, escalation, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that enabled it) stops the adversary from completing or repeating the trust-modification technique once it has begun, which satisfies `prevents` per the event-lane definition and the A.5.26 vs T1486 anchor.
T1484.002responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, analyze root cause, and close an information security incident once underway, which directly matches responding to an adversary's trust modification technique that has already executed.
T1485detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, post-incident root-cause analysis and communicating the incident, all of which surface and document a realized data-destruction event on the organization's estate; partial because pre-compromise or fully external destruction (e.g. cloud objects deleted without touching monitored systems) leaves nothing for the response team to detect.
T1485prevents — A.5.26's designated competent team, containment (a), escalation/crisis invocation (c), coordination (f), and explicit post-incident identification/management of the vulnerabilities/weaknesses that enabled the incident (j) stop the T1485 technique from completing or spreading further once underway, with a bounded remainder of already-destroyed data that cannot be un-destroyed.
T1485recovers — A.5.26's post-incident steps (forensic analysis, root-cause identification, vulnerability/weakness management, and formal closure) enable recovery actions that restore availability after T1485's destructive impact, matching the recovers verb in the event lane.
T1485responds — A.5.26 explicitly requires a designated competent team to respond to incidents (once underway) via containment (a), evidence collection (b), escalation/crisis invocation (c), logging (d), communication (e), coordination (f), formal closure (g), forensics (h), root-cause analysis (i), and vulnerability/weakness management (j) — all of which match the post-execution response lane for a realized T1485 data-destruction event, with the named remainder being any impact (e.g., already-destroyed data) that falls to recovery controls instead.
T1485.001detects — A.5.26 requires a designated competent team to respond to incidents (including detection, containment, eradication, and post-incident analysis per its listed steps), which surfaces lifecycle-triggered deletion once it runs as an information security incident.
T1485.001prevents — A.5.26's designated competent team, containment (a), coordination (f), and post-incident root-cause/vulnerability management (i–j) directly stop the adversary technique from completing or recurring when the incident is already underway or has just succeeded, which is what `prevents` asserts in the event-lane anchors; the named remainder is the pre-detection window in which the PutLifecycleConfiguration call can still succeed.
T1485.001recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability management, formal closure, and coordination with continuity plans) enable recovery actions that restore from the deletion's impact, with a named remainder in pre-closure data loss windows.
T1485.001responds — A.5.26 requires a competent team to respond to incidents once underway via containment, eradication, escalation, forensic analysis, root-cause review, and vulnerability/weakness management — directly addressing a completed T1485.001 deletion (e.g., containing spread, logging, closing the incident, and fixing the permission weakness that enabled it), with the named remainder being pre-response data loss already realized.
T1486detects — A.5.26 explicitly requires a designated competent team to respond to incidents (including detection triggers, evidence collection, logging, forensic analysis, and post-incident root-cause identification), which surfaces the ransomware encryption technique once underway.
T1486prevents — A.5.26 requires a designated competent team and explicit procedures that include immediate containment (a), escalation/crisis invocation (c), coordination (f), and post-incident root-cause/vulnerability management (i–j); these directly stop ransomware propagation, further encryption, and re-infection, preventing the full technique from completing even though initial encryption may have already occurred.
T1486recovers — A.5.26 explicitly requires invoking business continuity plans, performing post-incident analysis, formally closing the incident, and (via j) identifying/managing the vulnerabilities that enabled the encryption, which together restore availability after the T1486 impact has occurred.
T1486responds — A.5.26 explicitly requires a designated competent team to respond to incidents (including containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis, and vulnerability management), which directly matches the act of responding once a T1486 ransomware encryption event is underway.
T1489detects — A.5.26's response activities include collecting evidence, logging, forensic analysis and post-incident root-cause work that can surface a service-stop event once it has occurred on the organization's estate; the pre-compromise acquisition or the cloud API call that never touches the estate remains unseen.
T1489prevents — A.5.26's designated competent incident-response team, containment (a), escalation/crisis invocation of continuity plans (c), coordination (f), and post-incident root-cause/vulnerability management (i–j) directly stop the T1489 technique of disabling services to inhibit or stop incident response from succeeding.
T1489recovers — A.5.26's post-incident analysis, root-cause handling, vulnerability management, and formal closure (with possible BCP invocation) restore operational state after T1489 has disabled services to inhibit response or enable further impact, matching the recovers verb in the event lane.
T1489responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, analyze root cause, and close an incident once underway, which directly counters T1489's explicit goal of inhibiting or stopping incident response by disabling services.
T1490recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability management, formal closure, and coordination with continuity plans) enable recovery actions that restore recoverability after T1490 has run, matching the event-lane recovers anchor for backup/continuity controls vs T1490/T1486; mostly because it stops short of directly executing the restore itself.
T1490responds — A.5.26 explicitly requires a designated competent team to contain spreading incidents, eradicate the actor's effects, coordinate with parties, log everything, perform forensics/root-cause analysis, and address the vulnerabilities/weaknesses (including failed controls) that enabled the incident — which directly matches the `responds` verb once T1490 is underway.
T1491detects — A.5.26's response activities (evidence collection, logging, forensic analysis, post-incident root cause) surface and document a realized defacement once it has occurred on the organization's estate, but the pre-compromise acquisition and staging of defacement content (outside the estate) and many internal-only cases leave a large slice unseen.
T1491recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability/weakness management in j, formal closure) plus its explicit allowance for invoking business continuity plans enable recovery of the defaced visual content and affected systems after the technique has run.
T1491responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, close, and post-analyze an already-underway information security incident such as defacement, which matches the `responds` verb; the named remainder is that some defacements (e.g., external non-enterprise website changes) may fall outside the organization's incident scope.
T1491.001detects — A.5.26's response activities include collecting evidence, logging, communicating, coordinating, closing/recording, root-cause analysis and identifying related weaknesses, all of which engage once internal defacement (a visible, realized event on the organization's estate) is known; however, the clause's scope is set by business/security requirements and does not mandate instrumentation that would surface the defacement in the first place, leaving detection dependent on other controls or user reports.
T1491.001prevents — A.5.26 requires a designated competent team and explicit procedures that include containing spread, coordinating with parties to minimize consequences, and identifying/managing the vulnerabilities/weaknesses that enabled the incident; this directly stops the technique from completing or recurring once presence is known, with the bounded remainder being the initial execution that occurs before detection/response begins.
T1491.001recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability management in j, formal closure, and coordination) enable recovery of system integrity and user trust after internal defacement has occurred.
T1491.001responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment (a), evidence collection (b), escalation (c), logging (d), communication (e), coordination (f), closure (g), forensics (h), root-cause analysis (i), and vulnerability management (j), which directly matches the post-intrusion nature of T1491.001 (often after other goals) with a named remainder only for any pre-response impact already realized.
T1491.002detects — A.5.26's response activities (evidence collection, logging, forensic analysis, post-incident root cause) surface the defacement once it has occurred on the organization's externally-facing assets, but the technique's pre-compromise reconnaissance, initial access, and execution on third-party/registrar infrastructure are invisible to the control.
T1491.002prevents — A.5.26's designated competent team, containment (a), coordination (f), and post-incident root-cause/vulnerability management (i,j) directly stop the defacement technique from recurring or spreading to additional external assets once first detected.
T1491.002recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability management in j, formal closure) plus its explicit allowance to invoke business continuity plans enable recovery of trust/integrity after external defacement, with a named remainder of unaddressed user distrust that may persist beyond the incident response.
T1491.002responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis and vulnerability management — all of which directly address an already-executed external defacement (T1491.002) with only the pre-response propaganda impact as named remainder.
T1495prevents — A.5.26's designated competent team, containment (a), coordination (f), forensic/root-cause analysis (h/i), and explicit identification+management of the vulnerabilities/weaknesses that caused/contributed/failed to prevent the incident (j) directly stop the T1495 technique from recurring on the affected and peer systems.
T1495recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability management, formal closure, and coordination with continuity plans) enable recovery actions after firmware corruption has rendered devices inoperable, though the control itself does not perform the restore.
T1495responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, analyze root cause, close the incident, and manage related vulnerabilities once the firmware corruption technique is already underway, which is exactly what `responds` names; the named remainder is that some firmware corruption (e.g. bricked non-recoverable hardware) may exceed full eradication scope even after response.
T1496detects — A.5.26's response activities include collecting evidence, logging, communicating, coordinating, root-cause analysis and identifying weaknesses once an incident is underway, which can surface resource hijacking on the organization's own estate (e.g. anomalous compute, bandwidth or SMS use); however the technique can be launched entirely from co-opted third-party systems outside the organization's monitoring scope, leaving no event for the team to respond to.
T1496prevents — A.5.26's designated competent team, containment (a), coordination (f), vulnerability/weakness management (j) and post-incident root-cause work directly stop the hijacking technique from continuing or recurring on the co-opted systems.
T1496recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability management in j, formal closure) enable recovery of hijacked resources once the incident is contained and addressed, though the control's primary focus is response rather than full restoration of availability.
T1496responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment (a), evidence collection (b), escalation/crisis handling (c), logging (d), communication (e), coordination (f), formal closure (g), forensics (h), root-cause analysis (i), and vulnerability/weakness management (j) — all of which directly address an active resource-hijacking incident (e.g. cryptomining or proxying already consuming resources) without preventing its initial execution.
T1496.001detects — A.5.26's response activities (evidence collection, logging, post-incident analysis, root-cause identification) can surface compute hijacking once it is underway on the organization's estate, but pre-compromise acquisition of external resources and many container/IaaS stealth techniques sit outside the incident-response surface.
T1496.001prevents — A.5.26's incident response procedures (containment of spreading impact, coordination to minimize consequences, vulnerability/weakness management post-incident) can stop compute hijacking from continuing or recurring on affected systems, though this is reactive after initial compromise and does not stop the technique from first executing.
T1496.001recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability management in j, formal closure) enable recovery actions that restore availability after compute-hijacking impact, with the named remainder being immediate resource restoration not explicitly required by the clause.
T1496.001responds — A.5.26 requires a designated competent team to respond to incidents (including containment, eradication, forensic analysis, root-cause identification, and vulnerability/weakness management once the incident is underway), which directly matches the post-breach response to an active Compute Hijacking campaign that is already consuming resources.
T1496.002detects — A.5.26's response activities include collecting evidence, logging, communicating, coordinating, closing/recording, root-cause analysis and identifying related weaknesses, all of which engage once bandwidth hijacking (or its effects) is known on the organization's estate; however the pre-compromise scanning/internet-wide probing slice and purely external botnet/proxyjacking use of co-opted non-organizational systems sit outside any response trigger.
T1496.002prevents — A.5.26's designated competent team and procedures for containing spread (a), coordinating with parties to minimize consequences (f), and managing vulnerabilities/weaknesses that failed to prevent the incident (j) stop bandwidth hijacking from continuing or recurring in most cases once detected.
T1496.002recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability management in j, formal closure) enable recovery from bandwidth-hijacking impacts such as availability loss, financial costs, and reputational damage once the incident is contained.
T1496.002responds — A.5.26 explicitly requires a designated competent team to respond to incidents (including containment, eradication, evidence collection, logging, escalation, and post-incident root-cause/vulnerability management), which directly addresses an in-flight Bandwidth Hijacking technique once underway.
T1496.003detects — A.5.26 requires a designated competent team to respond to incidents (including detection and logging of the event once underway), which surfaces SMS-pumping fraud when it manifests as anomalous messaging volume or cost spikes, but the control's scope is limited to post-occurrence response rather than proactive or comprehensive detection of the technique itself.
T1496.003prevents — A.5.26's designated competent team, containment (a), coordination (f), and post-incident root-cause/vulnerability management (i,j) directly stop the SMS-pumping technique from continuing or recurring once it is recognized, which satisfies `prevents`; the named remainder is that the control activates only after the technique has already begun (per the event-lane boundary with `responds` and the explicit negative anchor for A.5.26 vs T1486).
T1496.003recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability management in j, formal closure) enable recovery of service availability and cost impact after the SMS-pumping event has been contained, matching the recovers verb in the event lane.
T1496.003responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment (a), escalation/crisis invocation (c), logging (d), communication (e), coordination (f), formal closure (g), forensics (h), root-cause analysis (i), and vulnerability/weakness management (j), all of which directly map to an active SMS-pumping fraud incident that is already generating traffic, overwhelming channels, and incurring costs.
T1496.004detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause identification and communicating details of an already-underway incident, which can surface SaaS hijacking when it produces observable effects (e.g. anomalous email volume, billing spikes or LLM proxy traffic) on the victim's estate; however the technique's core act (enabling/hijacking an external SaaS service) often occurs outside organizational monitoring scope, leaving a large slice undetected until impact is realized.
T1496.004prevents — A.5.26's designated competent team and explicit procedures for containing spread (a), coordinating with external parties to minimize consequences (f), and identifying/managing the vulnerabilities/weaknesses that enabled the incident (j) stop the SaaS hijacking technique from continuing or recurring once the incident is recognized, which is what `prevents` asserts on the event lane; the bounded remainder is that it cannot stop the initial compromise or first use before detection.
T1496.004recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability/weakness management, formal closure, and coordination) enable recovery from the financial, quota, and availability impacts of SaaS hijacking once the technique has run.
T1496.004responds — A.5.26 explicitly requires a designated competent team to contain (a), eradicate via root-cause/vuln fixes (i,j), log/analyze (d,i), communicate/escalate (e,f), and formally close (g) an incident once underway, which directly matches the act of responding to T1496.004 after the SaaS hijacking has begun; the named remainder is that early detection/escalation may still be needed before full response procedures engage.
T1498detects — A.5.26's response activities include collecting evidence, logging, communicating, coordinating, root-cause analysis and identifying weaknesses once an incident is underway; a network DoS that reaches organizational assets produces observable effects (traffic volume, service degradation, logs) that engage those steps, but pre-compromise external flooding (e.g. volumetric DDoS against upstream ISP or non-owned infrastructure) has no organizational event for the team to detect or respond to.
T1498prevents — A.5.26's designated competent team, containment (a), coordination (f), and post-incident root-cause/vulnerability management (i,j) directly stop the ongoing malicious traffic flood from continuing or recurring, though the initial exhaustion of bandwidth can still occur before response begins.
T1498recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability/weakness management, formal closure) plus explicit invocation of business continuity plans enable recovery of availability after a Network DoS has exhausted bandwidth and realized impact.
T1498responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, escalate, communicate, coordinate externally, close, forensically analyze, and post-analyze a security incident once underway, which matches the `responds` verb against an in-progress Network DoS; the named remainder is impact (availability loss) already realized before containment, which is left for recovery controls.
T1498.001detects — A.5.26's response activities include collecting evidence, logging, communicating, coordinating, root-cause analysis and managing the incident once underway; a network flood that reaches the organization's estate produces observable artifacts (traffic volume, service degradation) that can be logged, escalated and forensically examined, but the control's scope is limited to incidents on the organization's own systems and the upstream flood generation (botnet C2, compromised reflectors) lies outside that estate.
T1498.001prevents — A.5.26's designated competent team, containment (a), coordination (f), and post-incident root-cause/vulnerability management (i,j) directly stop the flood technique from continuing or recurring once underway, with the bounded remainder being pre-impact prevention of botnet build-out or initial packet emission.
T1498.001recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability management in j, formal closure) plus its explicit allowance for invoking business continuity plans enable recovery of service availability after a direct network flood DoS has occurred.
T1498.001responds — A.5.26 explicitly requires a competent team to contain spreading consequences, log/analyze, escalate, communicate, coordinate externally, close the incident, perform forensics/root-cause analysis, and manage related vulnerabilities once the incident (including a direct network flood) is underway.
T1498.002detects — A.5.26's response activities include collecting evidence, logging, communicating, coordinating, root-cause analysis and identifying weaknesses once an incident is underway; a reflection amplification flood that reaches the organization's own estate produces observable network anomalies, inbound traffic spikes or service degradation that can be logged and escalated, but the technique's pre-compromise reconnaissance, spoofed packets and third-party reflectors often occur outside organizational visibility, and the clause sets scope by business requirements rather than mandating universal detection instrumentation.
T1498.002prevents — A.5.26's designated competent team and procedures for containing spreading incidents, coordinating with external parties (e.g. to block reflectors), and managing related vulnerabilities directly stop many reflection amplification attacks from succeeding or recurring, though some initial traffic may still reach the target before containment.
T1498.002recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability management, formal closure, and coordination with continuity plans) enable recovery of availability after a reflection-amplification flood has already succeeded, matching the recovers verb in the event lane.
T1498.002responds — A.5.26's response activities (containment, evidence collection, logging, communication, coordination, closure, forensics, root-cause analysis, and vulnerability management) engage against the realized DoS impact on the organization's own systems or network, but the pre-attack reflector/amplifier probing and spoofed-packet generation occur entirely outside the organization and therefore trigger none of those activities.
T1499detects — A.5.26's response activities include collecting evidence, logging, communicating, coordinating, closing/recording, root-cause analysis and identifying weaknesses once an incident is underway, which surfaces the DoS event on the organization's own estate; however, the pre-compromise reconnaissance, botnet build-out and external saturation steps occur outside organizational visibility with no affected system or artifact inside the response scope.
T1499prevents — A.5.26's designated competent team, containment (a), escalation/crisis invocation (c), coordination (f), and post-incident root-cause/vulnerability management (i,j) directly stop the technique from continuing or recurring once underway, with the bounded remainder being the initial resource exhaustion or crash that has already succeeded before response begins.
T1499recovers — A.5.26 requires post-incident root-cause analysis, vulnerability remediation, and (via invoked continuity plans) restoration of affected services, which recovers availability after an Endpoint DoS has already succeeded.
T1499responds — A.5.26's response activities (containment, evidence collection, logging, communication, coordination, closure, forensics, root-cause analysis, and managing resulting weaknesses) engage once an Endpoint DoS is underway on the organization's estate, but core containment/eradication is empty for pure availability attacks that do not spread or leave persistent artifacts, leaving only the administrative/follow-up slice
T1499.001detects — A.5.26's response activities include collecting evidence, logging, communicating, coordinating, closing/recording, root-cause analysis and managing weaknesses once an incident is underway; an OS-exhaustion flood on the organization's own endpoints produces observable effects (sluggishness, unresponsiveness, connection failures) that can be logged and escalated, engaging several of those steps, but the pre-compromise reconnaissance or external flood generation itself sits outside the organization's estate and yields no internal evidence until impact begins.
T1499.001prevents — A.5.26's designated competent team and procedures for containing spreading incidents, coordinating with external parties, and managing related vulnerabilities directly stop the OS-exhaustion flood technique from continuing or succeeding once underway, with a bounded remainder for pre-response impact already realized.
T1499.001recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability/weakness management in j, formal closure) enable recovery from the realized DoS impact once contained, matching the recovers verb in the event lane.
T1499.001responds — A.5.26's response activities (containment, evidence collection, logging, communication, coordination, closure, forensics, root-cause analysis, and managing related weaknesses) engage against an in-progress OS-exhaustion flood on the organization's estate, but core containment/eradication is empty for a non-persistent flood that ends when the attacker stops, leaving only the administrative/follow-up slice
T1499.002detects — A.5.26's response activities include collecting evidence, logging, communicating, coordinating, closing/recording, root-cause analysis and identifying weaknesses once an incident is underway, all of which engage when a service-exhaustion flood produces observable effects on the organization's own estate; the pre-compromise acquisition of botnets or infrastructure lies outside any response activity.
T1499.002prevents — A.5.26's designated competent team and procedures for containing spreading incidents, coordinating with external parties, and managing related vulnerabilities directly stop many service-exhaustion floods from succeeding or recurring, though some volumetric attacks may still realize impact before containment.
T1499.002recovers — A.5.26 requires incident response that includes escalation/invoking business continuity plans, post-incident root-cause analysis, and managing the vulnerabilities/weaknesses that enabled the incident, which together restore service availability after a T1499.002 flood has already succeeded.
T1499.002responds — A.5.26's response activities (containment, evidence collection, logging, communication, coordination, closure, forensics, root-cause analysis, and managing weaknesses) engage against a realized service-exhaustion flood on the organization's estate, but core containment/eradication is empty for a non-persistent volumetric attack that ends when the flood stops, leaving only the administrative/follow-up slice
T1499.003detects — A.5.26's response activities include collecting evidence, logging, communicating, coordinating, closing/recording, root-cause analysis and identifying weaknesses once an incident is underway, all of which surface knowledge of an application-exhaustion flood that reaches the organization's estate; it does not detect pre-compromise reconnaissance or floods that produce no observable event on monitored systems.
T1499.003prevents — A.5.26's designated competent team and procedures for containing spreading incidents, coordinating with parties, and managing related vulnerabilities directly stop the flood's impact from propagating or recurring, though some initial resource exhaustion can still occur before response activates.
T1499.003recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability management in j, formal closure) enable recovery from the realized DoS impact once the flood is contained, matching the recovers verb in the event lane.
T1499.003responds — A.5.26's response activities (containment, evidence, logging, communication, coordination, closure, forensics, root cause, vulnerability management) engage on the realized exhaustion event and its artifacts, but capacity-based DoS vectors often leave no containable compromise or eradicable foothold once underway, limiting the core respond verb to a slice per the A.8.14 contrast anchor.
T1499.004detects — A.5.26's response activities include collecting evidence, logging, communicating, coordinating, closing/recording, root-cause analysis and identifying weaknesses once an incident is underway, which surfaces the exploitation when it produces observable effects on the organization's estate; however this is only a slice because the technique can be entirely pre-incident or produce no detectable incident on monitored assets before impact.
T1499.004prevents — A.5.26's designated competent team, containment (a), coordination (f), vulnerability/weakness management (j) and post-incident root-cause work directly stop the re-exploitation loop that turns a single crash into persistent DoS, which is the technique's defined success condition; the initial exploit itself is outside the incident-response lane so the remainder is bounded.
T1499.004recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability management in j, formal closure, and coordination with continuity plans in c) directly support restoring availability after a successful exploitation/crash has occurred, though the control stops short of mandating full system restoration mechanisms like backups or failover.
T1499.004responds — A.5.26's response activities (containment, evidence, logging, communication, coordination, closure, forensics, root-cause, vulnerability management) engage on the realized DoS event and its side-effects, but core containment/eradication is empty for a non-persistent exploitation that has already succeeded and whose impact (crash/DoS) is not undone by response procedures.
T1505detects — A.5.26 requires a designated competent team to respond to incidents (including detection, containment, evidence collection, logging, and post-incident root-cause analysis that surfaces the installed malicious server component), but its scope is limited to declared incidents rather than continuous proactive detection of the technique itself.
T1505prevents — A.5.26's designated competent incident-response team, with its explicit steps to contain spread (a), collect evidence and perform forensics (b,h), identify and manage the vulnerabilities/weaknesses that enabled the incident (j), and close it out, directly stops the T1505 persistence technique from continuing or recurring once it has begun.
T1505responds — A.5.26 explicitly requires a designated competent team to respond to incidents (including containment, eradication via vulnerability/weakness management in (j), forensic analysis, root-cause identification, and formal closure), which directly matches the act of responding to a T1505 technique that has already run and established persistence.
T1505.001detects — A.5.26 requires a designated competent team to respond to incidents (including detection, containment, analysis, and post-incident root-cause/vulnerability identification), which surfaces the T1505.001 persistence technique once it has executed and is underway; this is a genuine but bounded slice because the control's scope is set by communicated procedures and does not mandate proactive instrumentation that would catch all abuse of stored procedures or CLR assemblies.
T1505.001prevents — A.5.26's designated competent team and procedures for containing spread, coordinating with parties, managing related vulnerabilities/weaknesses, and post-incident root-cause work (including forensic analysis) prevent the persistence technique from achieving or retaining access in most cases once the incident is underway.
T1505.002detects — A.5.26 requires a designated competent team to respond to incidents (including detection, containment, analysis, and post-incident root-cause/vulnerability identification), which surfaces the malicious transport agent once its email-triggered persistence or actions are treated as an incident; partial because the control's scope is limited to declared incidents rather than continuous proactive detection of the technique itself.
T1505.002prevents — A.5.26's designated competent team following defined procedures for containment, evidence collection, escalation, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that enabled the incident (item j) directly stops the persistence technique from continuing or being (re)established once it has been surfaced.
T1505.002responds — A.5.26 explicitly requires a designated competent team to respond to incidents (including containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis, and vulnerability/weakness management), which directly matches the act of responding once the malicious transport agent persistence technique has executed and is underway.
T1505.003detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause identification) surface a web shell once it is already present and used on the organization's estate; the pre-compromise installation step on external infrastructure is outside its scope, yielding only a slice rather than a bounded remainder.
T1505.003prevents — A.5.26's designated competent team following defined procedures (including containment, evidence handling, escalation, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that enabled the incident) stops the web-shell technique from achieving or retaining persistent access once it has begun running, which is what `prevents` asserts in the event-lane anchors; the named remainder is that it does not stop initial placement of the shell before detection/response begins.
T1505.003responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment (a), evidence collection (b), escalation (c), logging (d), communication (e), coordination (f), closure (g), forensics (h), root-cause analysis (i), and vulnerability management (j), which directly matches the act of responding to a deployed web shell TTP that has already achieved persistence.
T1505.004detects — A.5.26 requires a designated competent team to respond to incidents (including detection via reported anomalies, evidence collection, logging, and post-incident root-cause analysis), which surfaces the IIS component installation once it triggers an observable incident, but the clause's scope is limited to incident response rather than proactive or comprehensive monitoring of all possible installation vectors.
T1505.004prevents — A.5.26's designated competent team and explicit steps (a: contain spread; f: coordinate to minimize consequences for others; j: identify/manage vulnerabilities/weaknesses that failed to prevent) act to stop the persistence technique from completing its full effect once the installation is detected in flight, though it does not stop the initial malicious component installation itself.
T1505.004responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, close, and perform post-incident root-cause/vulnerability analysis on an already-underway incident, which directly matches the act of responding to an installed malicious IIS component.
T1505.005detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause investigation) can surface the modified termsrv.dll or anomalous RDP behavior once the incident is underway on the organization's estate, but pre-compromise adversary DLL replacement (T1505.005) on a non-organizational system or without triggering an observable incident yields no event for the team to respond to.
T1505.005prevents — A.5.26's designated competent team, containment (a), forensic/root-cause analysis (h/i), vulnerability/weakness management (j), and coordination directly stop the technique from achieving or retaining persistent access via termsrv.dll modification once the incident is underway.
T1505.005responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment (a), evidence collection (b), escalation (c), logging (d), communication (e), coordination (f), closure (g), forensics (h), root-cause analysis (i), and vulnerability/weakness management (j) — all of which directly address an already-executed T1505.005 persistence implant.
T1505.006prevents — A.5.26's designated competent team and explicit steps (a) contain spread, (b/c) collect/escalate evidence, (f) coordinate externally, and (j) identify/manage the vulnerabilities/weaknesses that enabled the VIB abuse directly stop the technique from achieving or retaining persistent access once the incident is underway.
T1505.006responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, escalate, close, and perform post-incident/root-cause analysis on an already-underway incident, which directly matches the act of responding to a deployed malicious VIB persistence technique once it has executed on an ESXi host.
T1518detects — A.5.26's response activities (evidence collection, logging, post-incident analysis, root-cause identification) can surface the execution of software discovery once it has occurred on the organization's estate, but pre-compromise external discovery, non-incident enumeration, and techniques leaving no logged artifact fall outside the control's scope
T1518prevents — A.5.26's incident response (containment, evidence collection, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that caused/contributed/failed to prevent the incident) stops the adversary from successfully using discovered software information to shape or execute follow-on actions such as privilege escalation or lateral movement.
T1518.001detects — A.5.26 requires a designated competent team to respond to incidents (including detection via reported anomalies or indicators) once underway, and the technique's observable execution (commands, API calls) would surface as part of incident response procedures, with a named remainder for pre-response stealthy discovery that evades initial logging or reporting.
T1518.001responds — A.5.26's response activities (evidence collection, logging, communication, coordination, root-cause analysis, vulnerability management) engage once discovery occurs and is noticed, but core containment/eradication steps have no object since the technique is non-destructive reconnaissance that leaves no artifact or spread to contain.
T1518.002detects — A.5.26 requires a competent incident response team and procedures that include detection-oriented steps such as evidence collection, logging of activities, forensic analysis, and post-incident root-cause identification, which can surface the T1518.002 discovery technique once it has produced observable artifacts or anomalies during an incident.
T1525detects — A.5.26 requires monitoring for and response to incidents (including logging, evidence collection, forensic analysis, and post-incident root-cause identification), which can surface the post-implant use or effects of a malicious image as an incident but does not mandate detection of the implant action itself in a registry.
T1525prevents — A.5.26's designated competent team and explicit steps (a) contain spread, (b) collect evidence, (c) escalate/invoke continuity, (f) coordinate externally, and (j) identify/manage the vulnerabilities/weaknesses that enabled the implant directly stop the technique from achieving or retaining persistence once it has begun running in the victim's environment.
T1525responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, close, and perform post-incident analysis on an already-underway incident, which directly matches the `responds` verb once an implanted image has been used for persistence.
T1528detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause, vulnerability management) can surface the theft or use of a stolen token once it has produced observable effects on the organization's estate, but the technique's upstream acquisition (OAuth phishing, IMDS requests, container compromise) often occurs outside monitored scope or before any organizational event is created.
T1528prevents — A.5.26's designated competent team, containment (a), coordination (f), and post-incident root-cause/vulnerability management (i,j) directly stop the technique from completing its full impact chain once an incident is recognized, with the bounded remainder being the initial social-engineering or container-compromise vector that precedes detection.
T1528recovers — A.5.26's post-incident analysis, root-cause identification, vulnerability management (item j), and formal closure directly support recovering from the access and privilege-escalation impact of a stolen token once the incident is underway.
T1528responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, analyze root cause, close, and coordinate on an information security incident once underway, which directly matches the post-compromise response to a T1528 token-theft event that has already succeeded via container compromise, CI/CD breach, IMDS abuse, or OAuth phishing.
T1529detects — A.5.26 requires a designated competent team to respond to incidents (including detection/escalation of the incident itself), which surfaces T1529 once underway as part of containing, logging, forensic analysis, and post-incident root-cause work; mostly because the control's scope is set by defined procedures and does not mandate universal instrumentation depth for every possible shutdown vector.
T1529recovers — A.5.26's post-incident analysis, root-cause documentation, vulnerability/weakness management (including failed controls), and coordination with continuity plans directly enable recovery of availability after a shutdown/reboot technique has completed its impact.
T1529responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, escalate (including invoking continuity plans), communicate, coordinate, close, forensically analyze, and post-analyze incidents once underway, which directly matches responding to a T1529 shutdown/reboot that has already executed and is impeding response/recovery.
T1530detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause post-incident review) can surface T1530 once the access has occurred and left observable artifacts on the organization's estate, but many instances (e.g. purely external anonymous bucket access with no internal logs or alerts) produce no event the incident response team can detect.
T1530prevents — A.5.26's designated competent team, containment (a), escalation/crisis invocation (c), coordination (f), and explicit post-incident identification/management of the vulnerabilities/weaknesses (j) that enabled the incident (including misconfigurations and leaked credentials) stop the T1530 technique from successfully completing or recurring in the same way.
T1530recovers — A.5.26's post-incident steps (g, i, j) include formally closing the incident after addressing it, performing root-cause analysis, and managing the vulnerabilities/weaknesses that enabled the T1530 access, which restores organizational security posture after the data-access event.
T1530responds — A.5.26 explicitly requires a designated competent team to respond to incidents (including containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis, and vulnerability management), which directly matches the act of responding once a T1530 data-access incident is already underway.
T1531detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause identification and communicating the incident, all of which can surface T1531 once it has run on the organization's own estate (e.g. via anomalous account changes or lockouts visible in logs); however the technique can be executed entirely on external SaaS/IaaS platforms or pre-compromise, leaving no organizational event for the response team to observe.
T1531prevents — A.5.26's designated competent team, containment (a), escalation/crisis/continuity invocation (c), coordination (f), and explicit post-incident identification+management of the vulnerabilities/weaknesses that enabled the incident (j) stop the T1531 technique from completing or recurring in the same form, with the bounded remainder being the initial execution that has already occurred before response begins.
T1531recovers — A.5.26's post-incident analysis, root-cause identification, vulnerability/weakness management (including failed controls), forensic work, formal closure, and coordination with continuity plans directly enable recovery of legitimate account access after T1531 has run, with the named remainder being any unrecoverable pre-incident window or data already destroyed by linked Impact techniques.
T1531responds — A.5.26 explicitly requires a designated competent team to respond to incidents (including containment, escalation, forensic analysis, root-cause identification, and managing related vulnerabilities/weaknesses) once underway, which directly addresses T1531 when it is used to impede incident response/recovery in ransomware attacks.
T1534detects — A.5.26's response activities include collecting evidence, logging, communicating, coordinating, closing/recording, root-cause analysis and managing weaknesses once an incident is underway; internal spearphishing produces observable artifacts (e.g. anomalous internal messages, login redirects, or credential-capture attempts) that can be surfaced on the organization's estate, but the pre-compromise acquisition of the initial account and purely external delivery steps lie outside the response scope, making coverage a genuine but incomplete slice.
T1534prevents — A.5.26's designated competent team, containment (a), escalation (c), coordination (f), and post-incident root-cause/vulnerability management (i,j) directly stop the multi-staged internal spearphishing campaign from spreading or repeating once initial compromise occurs, though the technique's first-stage entry (external phish or device compromise) sits outside this incident-response lane.
T1534responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment (a), evidence collection (b), escalation (c), logging (d), communication (e), coordination (f), closure (g), forensics (h), root-cause analysis (i), and vulnerability/weakness management (j), which matches the `responds` verb against an internal spearphishing campaign that has already begun.
T1535prevents — A.5.26's designated competent incident-response team, containment (a), coordination (f), forensic analysis (h), root-cause identification (i), and explicit remediation of the vulnerabilities/weaknesses that enabled the incident (j) directly stop the adversary from continuing to operate undetected in the unused region once the technique has begun, which is what `prevents` asserts for an already-launched technique; the bounded remainder is that the initial creation step itself is not stopped before it runs.
T1535recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability management in j, formal closure) enable recovery of the affected cloud environment after the unused-region technique has run and been contained.
T1535responds — A.5.26's response activities (contain, eradicate, log, communicate, forensics, root-cause, close) engage once an unused-region instance is discovered on the estate, but most of the technique's mechanics (account compromise, region creation, crypto mining) sit pre-compromise or outside the monitored estate, leaving the core response surface a minority slice
T1537detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, post-incident root cause, and communicating details once an incident is known; these can surface T1537 when it triggers an already-recognized incident on the defender's estate, but the control's mechanism is human/team response rather than proactive monitoring and provides no vantage on pre-incident or stealthy intra-cloud transfers that blend as normal API traffic.
T1537prevents — A.5.26's designated competent team and explicit procedures for containing spread (a), coordinating with parties to minimize consequences (f), and managing vulnerabilities/weaknesses that failed to prevent the incident (j) stop the T1537 exfiltration technique from completing or recurring in most observed forms (API blending, backups, SAS shares).
T1537responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment (a), evidence collection (b), escalation (c), logging (d), communication (e), coordination (f), closure (g), forensics (h), root-cause analysis (i), and vulnerability management (j), which directly matches the act of responding to an observed T1537 exfiltration event (including backups to another account) without preventing or recovering from it.
T1538detects — A.5.26's response activities (evidence collection, logging, root-cause analysis, vulnerability identification) can surface the post-compromise use of a stolen-credential dashboard when it produces observable artifacts on the organization's estate, but the technique itself occurs entirely within the cloud provider's GUI with no guaranteed detectable event on the victim's monitored scope.
T1538prevents — A.5.26's designated competent team responding to an incident (containing spread, collecting evidence, escalation, forensic analysis, root-cause identification, and explicitly managing the vulnerabilities/weaknesses that allowed the incident) stops the T1538 technique from continuing or recurring once it has begun, which satisfies `prevents` for the post-breach phase of this discovery technique; the named remainder is that it does not stop the initial credential theft or first use of the dashboard.
T1538responds — A.5.26's response activities (containment, evidence collection, logging, communication, coordination, closure, forensics, root-cause analysis, and managing resulting weaknesses) engage once the adversary is using stolen credentials in the dashboard; however, the core technique (viewing information via GUI) produces no spreading consequence to contain, no artifact to eradicate, and no system impact to bound, leaving most of the verb's protective substance empty while the administrative/follow-up half still applies.
T1539detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause post-incident review) can surface the theft or use of a stolen session cookie once it has produced observable effects on the organization's estate, but the upstream acquisition (local malware, JS injection, malicious proxy) often leaves no organizational vantage point and many downstream uses never trigger an incident response workflow.
T1539prevents — A.5.26 requires a designated competent team and explicit procedures that contain spreading consequences, coordinate externally, and address root causes/vulnerabilities/weaknesses that enabled the incident, which stops the T1539 technique from continuing or succeeding further once underway (the technique ran but is prevented from achieving its full impact).
T1539recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability/weakness management in j, formal closure) enable recovery of the authentication posture after the session-cookie theft has already succeeded and been used.
T1539responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, analyze root cause/vulnerabilities/weaknesses, and formally close an information security incident once underway, which directly matches the act of responding to a realized T1539 theft and its post-compromise use.
T1542prevents — A.5.26's designated competent team and procedures for containing spread, coordinating externally, managing vulnerabilities/weaknesses that contributed or failed to prevent, and post-incident root-cause work directly stop the persistence technique from completing its full effect in many cases (especially post-compromise or multi-stage attacks), though a pure pre-OS boot compromise can occur before incident response is triggered.
T1542recovers — A.5.26's post-incident analysis, root-cause identification, vulnerability management (item j), forensic work, and formal closure directly enable recovery actions that restore systems from Pre-OS Boot persistence (e.g., by replacing compromised firmware/BIOS/UEFI), with the named remainder being any unaddressed persistence that evades detection or analysis.
T1542responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, analyze root cause/vulnerabilities/weaknesses, and formally close an incident once underway, which matches the `responds` verb for a T1542 persistence event that has already executed at boot.
T1542.001prevents — A.5.26's designated competent team and procedures for containing spread, evidence collection, escalation, forensic analysis, root-cause identification, and explicit management of vulnerabilities/weaknesses that caused/contributed/failed to prevent the incident directly stop the firmware modification technique from completing or recurring as persistence.
T1542.001recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability management in j, forensic analysis, formal closure) enable recovery actions that address the firmware modification's effects and prevent recurrence, though the control itself does not directly restore firmware state.
T1542.001responds — A.5.26 explicitly requires a designated competent team to contain (a), eradicate via root-cause/vuln fixes (i,j), log/analyze (d,i), and close (g) an incident once underway, which matches the `responds` verb; the firmware technique is in scope as any information security incident, with only the pre-containment impact as named remainder.
T1542.002detects — A.5.26 requires monitoring for and response to incidents (including logging, forensic analysis, and post-incident root-cause identification), which can surface component firmware modification once it triggers observable effects or is investigated, but the control's scope is set by organizational procedures and does not mandate specific detection of firmware tampering itself.
T1542.002prevents — A.5.26's designated competent incident-response team, once notified of anomalous firmware behavior (via monitoring or other detection), contains spread (a), escalates (c), coordinates (f), and explicitly identifies/manages the firmware vulnerability/weakness that enabled the persistence (j), stopping the technique from achieving or sustaining its full effect on additional systems or re-infection paths.
T1542.002recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability management, formal closure, and coordination with continuity plans) enable recovery from the persistence and evasion left by malicious component firmware, though the control itself does not perform the actual state restoration (that is A.8.13).
T1542.002responds — A.5.26 requires a designated competent team to respond to incidents (once underway) via containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis, and vulnerability/weakness management — all of which directly map to an in-progress T1542.002 firmware compromise, with the named remainder being pre-containment persistence that may already be realized before response begins.
T1542.003prevents — A.5.26's designated competent team, containment (a), forensic analysis (h), root-cause identification (i), and explicit management of vulnerabilities/weaknesses that failed to prevent the incident (j) directly stop a suspected bootkit from achieving or retaining persistence once the incident is underway.
T1542.003recovers — A.5.26's post-incident analysis, root-cause identification, vulnerability management (j), forensic work and formal closure directly enable recovery actions that address the bootkit's persistence and lower-layer modifications once the incident is underway.
T1542.003responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, close, perform root-cause and post-incident analysis, and manage the vulnerabilities/weaknesses that enabled the incident once it is underway, which matches the `responds` verb; the bootkit's low-level persistence and remediation difficulty is a named remainder that does not negate the control's defined response actions.
T1542.004detects — A.5.26 requires a designated competent team to respond to incidents (including detection, containment, evidence collection, logging, forensic analysis, and post-incident root-cause identification), which surfaces ROMMONkit persistence when it triggers an observed incident but does not mandate proactive or continuous monitoring of boot/firmware integrity.
T1542.004prevents — A.5.26's designated competent incident-response team, with its explicit steps to contain spread (a), collect/analyze evidence and perform forensics (b,h), identify root cause plus the vulnerabilities/weaknesses that allowed the incident (i,j), and coordinate to minimize consequences, directly prevents the ROMMONkit persistence technique from completing or recurring once any part of the attack is underway or detected.
T1542.004recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability management in j, forensic analysis, formal closure) enable recovery actions that can restore device state after ROMMONkit persistence is addressed, though the control itself does not directly perform the restore.
T1542.004responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, analyze root cause, close, and coordinate on an information security incident once underway, which directly matches the response lane for a ROMMON firmware overwrite persistence technique that has already executed.
T1542.005prevents — A.5.26's designated competent team following defined procedures for containment, evidence collection, escalation, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that caused/contributed/failed to prevent the incident directly stops the TFTP-boot technique from recurring on the affected network device.
T1542.005recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability management in j, formal closure) enable recovery actions that restore the network device from the unauthorized TFTP-booted image and related backdoors, though the control itself does not perform the restore.
T1542.005responds — A.5.26 requires a designated competent team to respond to incidents once underway (containment, eradication, evidence, escalation, logging, closure, root-cause analysis, and vulnerability management), which directly matches the post-compromise handling of a T1542.005 netboot that has already succeeded in loading a malicious image.
T1543detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause, vulnerability management) can surface the creation/modification of a system process once it has occurred and is part of an incident, but the clause's scope is limited to incidents already underway and does not mandate proactive monitoring of process creation itself.
T1543prevents — A.5.26's designated competent team responding to an incident (including containment, evidence collection, escalation, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that allowed the incident) stops the adversary technique from completing its persistence goal in the large majority of cases once it is underway or detected.
T1543responds — A.5.26 requires a competent team to respond to incidents once underway via containment, eradication, evidence collection, logging, escalation, and post-incident root-cause/vulnerability management, which directly addresses an already-executed T1543 persistence technique (the service/daemon/agent now running).
T1543.001detects — A.5.26 requires a designated competent team to respond to incidents (including detection via reported anomalies or logs per its procedures), which surfaces the persistence technique once it has executed and is observable, but only for incidents that are escalated or reported rather than proactively scanning for all such agents.
T1543.001prevents — A.5.26's designated competent team responding to an incident (including containment, evidence collection, escalation, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that enabled it) stops the adversary technique from achieving repeated/persistent execution once it has begun running.
T1543.001responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, close, and perform post-incident analysis on an already-underway incident, which directly matches the `responds` verb once the Launch Agent persistence technique has executed.
T1543.002detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause identification and managing the weaknesses that enabled the incident; when a systemd service modification occurs on an organizational asset these can surface the technique (especially post-execution via logs or anomalies), but pre-compromise creation on external infrastructure or fully stealthy in-memory changes leave real gaps, matching the partial rung set by the A.5.26 vs T1595.002 anchor.
T1543.002prevents — A.5.26 requires a designated competent team to respond to incidents (including containment, evidence collection, escalation, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that caused/contributed/failed to prevent the incident), which directly stops the persistence technique from continuing to execute once it has been observed.
T1543.002responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, escalate, close, and perform post-incident/root-cause analysis on an already-underway incident, which directly matches the act of responding to a T1543.002 persistence technique once it has executed.
T1543.003detects — A.5.26 requires a designated competent team to respond to incidents (including detection, containment, analysis, and post-incident root-cause/vulnerability identification), but its core focus is the response process once an incident is known rather than proactive or broad detection of the T1543.003 technique itself.
T1543.003prevents — A.5.26's designated competent team and explicit steps (a) contain spread, (b/c) collect/escalate evidence, (e/f) communicate/coordinate, (i/j) perform root-cause analysis plus identify/manage the vulnerabilities/weaknesses that enabled the service creation, directly stops the persistence technique from continuing or recurring on the affected estate.
T1543.003responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, analyze root cause, close the incident and address related vulnerabilities once the service-creation technique is already underway, matching the `responds` definition with a named remainder on pre-containment impact.
T1543.004detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause identification) can surface a Launch Daemon once it has executed or is observed as anomalous, but the technique occurs pre-compromise on the adversary's infrastructure or via local privilege escalation with no guaranteed observable event on the organization's estate.
T1543.004prevents — A.5.26's designated competent team and procedures for containing spread (a), coordinating with parties to minimize consequences (f), and identifying/managing the vulnerabilities/weaknesses that caused or failed to prevent the incident (j) stop the persistence technique from completing its full effect in most cases once underway, per the event-lane anchor treating the identical clause as responds mostly against T1486.
T1543.004responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, escalate, close, and perform post-incident/root-cause analysis on an already-underway incident, which matches the `responds` verb once a Launch Daemon persistence technique has executed.
T1543.005detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause identification) can surface the creation/modification of container services when it occurs on the organization's estate, but pre-compromise acquisition and many container-specific artifacts sit outside the incident-response scope that the clause actually exercises.
T1543.005prevents — A.5.26's designated competent team and explicit procedures for containing spread (a), coordinating with parties to minimize consequences (f), and identifying/managing the vulnerabilities/weaknesses that caused or failed to prevent the incident (j) stop the T1543.005 technique from completing its persistence/escalation goal in most cases once underway.
T1543.005responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, analyze root cause/vulnerabilities/weaknesses that enabled the incident, and formally close it once addressed — which directly matches the `responds` verb once the T1543.005 technique (service modification for persistence/escalation) is already underway.
T1546detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause identification) can surface T1546 artifacts once the triggered execution has produced observable events on the organization's estate, but pre-compromise or external trigger creation (e.g. on SaaS/IaaS platforms) leaves no object for response and many triggers produce no detectable incident until later misuse.
T1546prevents — A.5.26's designated competent team and procedures for containing spread, coordinating, and addressing the incident (including forensic/root-cause steps that can identify and manage the abused trigger mechanism) stop the repeated/persistent execution of the malicious payload once the technique has begun running, which is what `prevents` asserts in the event-lane anchors.
T1546responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, analyze root cause, close, and address vulnerabilities/weaknesses once an incident is underway, which directly matches the `responds` verb against an already-established T1546 persistence or privilege-escalation artifact.
T1546.001detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause identification and post-incident review, all of which can surface the registry change or anomalous file-association behavior once it has executed on an organizational Windows system; the remainder is pre-compromise adversary activity on external infrastructure or associations altered without triggering any monitored artifact inside the organization's estate.
T1546.001prevents — A.5.26 requires a designated competent team to respond to incidents once underway (containment, eradication, root-cause analysis, vulnerability management including those that enabled the incident); this bounds the persistence technique after it has run and prevents its continued or repeated success, with a named remainder that the initial execution can still occur before response begins.
T1546.002detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause identification and managing weaknesses once an incident is underway, which can surface the screensaver persistence artifact on the organization's estate; however, the technique's pre-compromise setup (registry changes with no immediate execution) and its reliance on user inactivity provide no guaranteed observable event for the response team, leaving a large slice undetected until activation or other indicators appear.
T1546.002prevents — A.5.26 requires a designated competent team to respond to incidents once underway (containment, eradication, root-cause analysis, vulnerability management), which stops the persistence technique from continuing to execute after it has activated; this is the act `prevents` names in the event-lane anchors, with a named remainder that the initial activation can still occur before response begins.
T1546.002responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment (a), evidence collection (b), escalation (c), logging (d), communication (e), coordination (f), closure (g), forensics (h), root-cause analysis (i), and vulnerability/weakness management (j) — all of which directly address an already-executing T1546.002 persistence technique, with the named remainder being impact realized before containment.
T1546.003detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause identification and communicating the incident once it has occurred, which can surface a running WMI event subscription; however the technique's pre-compromise registration of the subscription (on the adversary's infrastructure or via MOF) has no affected system or observable artifact inside the organization's estate until the trigger fires.
T1546.003prevents — A.5.26's designated competent team and communicated procedures for incident response (including containment, evidence collection, escalation, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that caused/contributed/failed to prevent the incident) stop the T1546.003 persistence technique from continuing to run once it has been observed, which is what `prevents` asserts on the event-lane; the named remainder is that the initial subscription/execution can still occur before detection/response begins.
T1546.003responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment, evidence collection, escalation, logging, communication, coordination, forensic analysis, root-cause identification, and vulnerability/weakness management — all of which directly address a running T1546.003 persistence technique and its consequences.
T1546.004detects — A.5.26 requires a designated competent team to respond to incidents (including detection, containment, analysis, and post-incident root-cause/vulnerability identification), which surfaces this persistence technique once it has executed and triggered; the clause sets scope by business/security requirements rather than mandating universal coverage of all possible shell config modifications.
T1546.004prevents — A.5.26's designated competent team and procedures for containing spread, coordinating with parties, managing related vulnerabilities/weaknesses, and performing root-cause/post-incident analysis that leads to fixing the configuration-modification vector mostly stops the persistence technique from recurring, though the clause itself is reactive and does not proactively block initial insertion into shell config files.
T1546.004responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, close, and perform post-incident root-cause/vulnerability analysis on an already-underway incident, which directly matches the act of responding to a realized T1546.004 persistence technique.
T1546.005detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause identification) can surface a trap-based persistence mechanism once it has executed and produced observable artifacts on the monitored estate, but the pre-compromise registration of the trap itself occurs without an incident event on the organization's systems and many of the clause's ten activities have no object to act on.
T1546.005prevents — A.5.26's designated competent team and procedures for containing spread, coordinating with parties, managing vulnerabilities/weaknesses that contributed or failed to prevent, and post-incident root-cause work stop the trap-based persistence technique from being (re)established in most cases once an incident is underway.
T1546.005responds — A.5.26 requires a designated competent team to respond to incidents once underway (containment, eradication, evidence, escalation, logging, communication, forensic analysis, post-incident root-cause work and vulnerability management), which directly matches the act of responding to a deployed T1546.005 persistence mechanism; the named remainder is that the control does not itself perform the final eradication step on every possible trap artifact.
T1546.006detects — A.5.26 requires monitoring for and response to incidents (including logging, forensic analysis, and post-incident root-cause identification), which can surface this persistence technique once it has executed and produced observable effects, but the clause's scope is set by organizational procedures and does not mandate specific detection mechanisms or coverage of this macOS-specific binary modification.
T1546.006prevents — A.5.26 requires a designated competent team and explicit procedures that include containing spread, coordinating with parties to minimize consequences, identifying/managing vulnerabilities/weaknesses that caused/contributed/failed to prevent the incident, and post-incident root-cause work; this directly constrains the T1546.006 persistence technique from running successfully at scale in an organization that follows the control.
T1546.006responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, analyze root cause, and close an information security incident once underway, which directly matches the act of responding to an already-executed T1546.006 persistence technique.
T1546.007detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause identification) can surface the Netsh Helper DLL persistence artifact once the technique has run and netsh.exe executes, but the pre-compromise registration in the registry and many of the clause's core response steps have no object to act on.
T1546.007prevents — A.5.26's designated competent team and communicated procedures for incident response (including containment, root-cause analysis, vulnerability management, and closing the incident) prevent the Netsh Helper DLL persistence technique from continuing to execute on subsequent netsh.exe runs once it has been initially detected.
T1546.007responds — A.5.26 requires a competent team to respond to incidents once underway via containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis and vulnerability management — all of which directly address a realized Netsh Helper DLL persistence incident (T1546.007) with only the pre-containment impact as named remainder
T1546.008detects — A.5.26 requires a designated competent team to respond to incidents (including detection, containment, evidence collection, logging, forensic analysis, and post-incident root-cause/vulnerability identification), which surfaces this persistence technique once it has executed and is underway.
T1546.008prevents — A.5.26's designated competent team responding to an incident (containing spread, collecting evidence, escalation, forensic analysis, root-cause identification, and explicitly managing the vulnerabilities/weaknesses that caused/contributed/failed to prevent it) directly stops the persistence technique from continuing to provide unauthenticated SYSTEM-level access or privilege escalation.
T1546.008responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, escalate, close, and perform post-incident/root-cause analysis on an already-underway incident, which directly matches the `responds` verb once the accessibility-feature backdoor has executed.
T1546.009detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause identification and managing the weaknesses once an incident is underway, which can surface AppCert DLL abuse when it triggers observable process or registry anomalies on the organization's estate; it does not detect the pre-compromise Registry write itself.
T1546.009prevents — A.5.26's designated competent team following defined procedures (including containment, escalation, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that caused/contributed/failed to prevent the incident) stops the AppCert DLL persistence/elevation technique from continuing or recurring on the affected Windows systems.
T1546.009responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, analyze root cause, and close an information security incident once it is underway, which directly matches the act of responding to an already-executing T1546.009 persistence/elevation technique.
T1546.010detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause identification) can surface the technique once it has executed and produced observable artifacts on the organization's estate, but the pre-compromise registry edit and DLL loading occur without an incident necessarily being declared or responded to, and many instances remain outside the scope of declared incidents.
T1546.010prevents — A.5.26's designated competent team and procedures for containing spread, coordinating with parties, managing related vulnerabilities/weaknesses, and performing root-cause/post-incident analysis that leads to fixing the AppInit DLL registry abuse (a control failure) mostly stops the technique from recurring or succeeding at scale.
T1546.010responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment (a), evidence collection (b), logging (d), escalation (c), communication (e), coordination (f), forensic analysis (h), root-cause post-incident review (i), and vulnerability/weakness remediation (j), all of which directly address an AppInit DLLs persistence/elevation technique that has already executed.
T1546.011detects — A.5.26 explicitly requires a designated competent team to respond to incidents (including detection triggers, evidence collection, logging, forensic analysis, and post-incident root-cause identification), which surfaces application shimming when it manifests as malicious behavior or an observable incident.
T1546.011prevents — A.5.26's designated competent team responding to an incident (containing spread, eradicating artifacts, closing the incident, and addressing the root cause including any enabling vulnerability/weakness) stops the shim-based persistence/elevation technique from continuing or recurring, though it does not stop the initial installation/execution of a malicious shim.
T1546.011responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, analyze root cause, and close an incident once underway, which directly matches the act of responding to a T1546.011-based attack that has already executed.
T1546.012detects — A.5.26's response activities (evidence collection, logging, forensic analysis, post-incident root-cause) can surface IFEO Registry changes or anomalous debugger launches once they occur on the organization's estate, but pre-compromise setup of IFEO (especially via external tools or at login) often leaves no observable event inside the control's scope until triggered.
T1546.012prevents — A.5.26's designated incident-response team, containment (a), forensic/root-cause analysis (h/i), vulnerability/weakness management (j) and coordination directly stop the IFEO technique from completing its persistence/privilege-escalation/impaired-defense goals once it has begun, with a bounded remainder of pre-detection technique instances that have already succeeded before response is invoked.
T1546.012responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, analyze root cause, close the incident and address related vulnerabilities/weaknesses once the IFEO-triggered technique is already underway, which is exactly what `responds` names.
T1546.013detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause identification) can surface the profile modification or its execution artifact once it has run on the organization's estate, but the technique's pre-compromise setup (modifying a .ps1 on disk) and many execution paths sit outside any incident response trigger or monitoring scope.
T1546.013prevents — A.5.26's designated competent team responding to an incident (containing spread, collecting evidence, forensic analysis, root-cause identification, and explicitly managing the vulnerabilities/weaknesses that allowed the incident) directly stops the persistence technique from continuing to execute on affected systems and prevents re-occurrence via the identified root cause.
T1546.013responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, analyze root cause, close, and manage related vulnerabilities once an incident is underway, which directly matches responding to a realized T1546.013 persistence technique.
T1546.014detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause identification and communicating the incident; these surface knowledge of an emond rule that has already executed on a monitored macOS system, but the technique occurs pre-compromise on the adversary's own infrastructure or during initial persistence with no guaranteed observable on the victim's estate.
T1546.014prevents — A.5.26's incident-response procedures (containment, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that enabled the incident) can stop the emond rule from being (re)written or from triggering again once discovered, but do not stop the initial abuse of the technique.
T1546.014responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, analyze root cause, and close an information security incident once it is underway, which directly matches the act of responding to an emond-based persistence or privilege-escalation technique that has already executed.
T1546.015detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause identification and managing the weaknesses that caused the incident; these surface the COM hijacking once it has produced observable effects on the organization's estate (e.g. anomalous Registry changes, unexpected process execution or TypeLib redirection), but the pre-compromise registry manipulation itself occurs locally before any incident is declared and many stealthy instances produce no detectable event within the clause's scope.
T1546.015prevents — A.5.26's designated competent team responding to an incident (including containment, evidence collection, root-cause analysis, vulnerability/weakness management in j, and coordination) prevents the hijacked COM reference from remaining as active persistence by addressing and removing it once the technique has run.
T1546.015responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, analyze root cause, close the incident and address related vulnerabilities/weaknesses once the COM-hijacking persistence technique is already underway.
T1546.016detects — A.5.26's response activities (evidence collection, logging, forensic analysis, post-incident root-cause) can surface the post-install execution or anomalous installer behavior once it has occurred on the organization's estate, but the technique's pre-compromise acquisition and initial execution of a tampered package often leaves no observable event inside the monitored scope until after impact
T1546.016prevents — A.5.26's designated competent team responding to an incident (containing spread, forensic analysis, root-cause identification, vulnerability/weakness management including failed controls) stops the persistence and privilege-escalation technique from continuing or recurring, with the bounded remainder being the initial execution that occurs before detection/response begins.
T1546.016responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment (a), evidence collection (b), escalation (c), logging (d), communication (e), coordination (f), closure (g), forensics (h), root-cause analysis (i), and vulnerability/weakness management (j) — all of which apply to an in-progress or realized T1546.016 installer-script execution, with the named remainder being any pre-containment impact already realized.
T1546.017detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause identification) can surface udev rule abuse once it has executed and left observable artifacts on the organization's Linux estate, but the technique occurs pre-compromise during persistence setup with no guaranteed event on the monitored estate.
T1546.017prevents — A.5.26's designated competent team and procedures for containing spread, coordinating with parties, managing related vulnerabilities/weaknesses, and post-incident root-cause work (including those that failed to prevent) stop the udev-rule persistence technique from continuing or recurring in most cases once it has begun, though it does not stop initial rule installation by a root-level adversary.
T1546.017responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, analyze root cause, and close an information security incident once it is underway, which directly matches the act of responding to a T1546.017 persistence technique that has already executed via udev rules.
T1546.018detects — A.5.26 requires monitoring for and response to incidents (including logging, forensic analysis, and post-incident root-cause identification), which can surface Python startup hook abuse once it triggers observable anomalous behavior, but the control's scope is set by organizational requirements and does not mandate detection of this specific persistence technique.
T1546.018prevents — A.5.26's incident-response procedures (containment, evidence handling, root-cause analysis, vulnerability/weakness remediation) can prevent the persistence technique from surviving or recurring once it has been detected as an incident, but do not stop the initial abuse of Python startup hooks before it runs.
T1546.018responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, analyze root cause, close, and coordinate on an incident once underway, which directly matches the act of responding to a T1546.018 persistence technique that has already executed on Python startup.
T1547prevents — A.5.26's designated competent team responding to an incident (including containment, root-cause analysis, vulnerability/weakness management in j, and coordination) stops the adversary from completing or repeating the T1547 configuration step that would have achieved persistence.
T1547.001detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause identification) can surface the persistence artifact once the technique has executed and an incident is declared, but the clause's scope is limited to declared incidents rather than continuous monitoring of registry/startup changes, and many executions produce no detectable incident.
T1547.001prevents — A.5.26's designated competent team responding to an incident (including containment, evidence collection, root-cause analysis, vulnerability/weakness remediation in j, and coordination) stops the persistence technique from continuing to execute on future logins/reboots once discovered, which is what prevents asserts for an already-deployed technique; the named remainder is that it does not stop the initial placement before detection occurs.
T1547.001responds — A.5.26 explicitly requires a designated competent team to contain (a), eradicate via root-cause/vulnerability fixes (i,j), log/analyze (d,i), and close (g) an already-underway incident that used T1547.001 for persistence; the named remainder is that the initial execution may complete before response begins.
T1547.002detects — A.5.26's response activities include collecting evidence, logging, forensic analysis and post-incident root-cause work that can surface the LSA authentication package registry change or anomalous DLL load once it has occurred on an organizational Windows system.
T1547.002prevents — A.5.26's incident response procedures (containment, root-cause analysis, vulnerability/weakness management in j) directly prevent the persistence technique from re-establishing after detection by addressing the registry modification and related weaknesses that enabled it.
T1547.002responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment, evidence collection, escalation, logging, communication, coordination, forensic analysis, root-cause identification, and vulnerability/weakness management, which bounds and eradicates an in-progress T1547.002 persistence technique (with the named remainder being impact already realized before containment).
T1547.003detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause identification) can surface the time-provider registration or anomalous DLL load at boot if it is treated as an incident, but the control's scope is post-incident response rather than continuous monitoring of the registry or service startup, leaving most pre-response instances undetected.
T1547.003prevents — A.5.26's incident response procedures (containment, forensic analysis, root-cause identification, vulnerability/weakness management) directly prevent the persistence technique from surviving or recurring once it has been detected.
T1547.003responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, analyze root cause, close, and address vulnerabilities/weaknesses of an incident already underway, which matches the definition of responds once the time-provider persistence technique has executed at boot.
T1547.004detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause identification) can surface the persistence artifact or anomalous logon behavior once the technique has executed, but the clause's scope is incident response after an event is known rather than proactive monitoring of registry or Winlogon activity, leaving most pre-incident or undetected instances outside its mechanism.
T1547.004prevents — A.5.26's designated competent team and explicit procedures for containing spread (a), coordinating with parties to minimize consequences (f), and identifying/managing the vulnerabilities/weaknesses that caused or failed to prevent the incident (j) stop the Winlogon Helper DLL persistence technique from completing its repeated-execution goal in most cases once it is recognized as an incident.
T1547.004responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment (a), evidence collection (b), escalation (c), logging (d), communication (e), coordination (f), closure (g), forensics (h), root-cause analysis (i), and vulnerability/weakness management (j) — all of which directly address an already-executing Winlogon Helper DLL persistence technique, with the named remainder being impact realized before containment.
T1547.005detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause identification and managing the weaknesses exposed by an incident that has already occurred; these surface the SSP abuse once it has executed at boot, but the pre-compromise technique (Registry modification) sits outside organizational monitoring scope and leaves no affected system or artifact until after the fact.
T1547.005prevents — A.5.26's incident response procedures (containment, escalation, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that caused/contributed/failed to prevent the incident) stop the SSP-abuse technique from recurring on future boots once it has been observed.
T1547.005responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment, evidence collection, escalation, logging, communication, coordination, forensic analysis, root-cause identification, and post-incident vulnerability management, which directly matches responding to an SSP abuse technique that has executed at boot.
T1547.006detects — A.5.26 requires a designated competent team to respond to incidents (including detection via reported anomalies, evidence collection, logging, forensic analysis, and post-incident root-cause identification), which surfaces kernel module-based persistence/escalation once underway; mostly because the clause scopes response to known/reported incidents rather than mandating proactive kernel-level monitoring for all possible LKM/kext loads.
T1547.006prevents — A.5.26's designated competent team and explicit steps (a) contain spread, (b) collect evidence, (h) forensic analysis, (i) root-cause identification, and (j) manage the vulnerabilities/weaknesses that enabled the LKM/kext rootkit directly stop the persistence/privilege-escalation technique from continuing or recurring on affected systems.
T1547.006responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, escalate, coordinate, close, and perform post-incident/root-cause analysis on an information security incident once underway, which matches the act of responding to a T1547.006 kernel-module rootkit that has already achieved persistence/privilege-escalation.
T1547.007prevents — A.5.26's designated competent team and procedures for containing spread (a), coordinating with parties to minimize consequences (f), and identifying/managing vulnerabilities/weaknesses that failed to prevent the incident (j) stop the plist modification from achieving its persistence goal in most cases once the technique is detected in flight.
T1547.008detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause identification and managing the weaknesses exposed by an incident that has already occurred, which surfaces the LSASS driver modification once it is present on the estate; this is genuine detection but only a slice because the technique can be deployed pre-compromise or on systems outside the incident-response scope, and the control's core (containment/eradication) is not the detection act itself.
T1547.008prevents — A.5.26's designated competent team following defined procedures for containment, evidence collection, escalation, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that caused/contributed/failed to prevent the incident directly stops the LSASS driver modification technique from achieving or retaining persistence on future systems.
T1547.008responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, analyze root cause, close, and address vulnerabilities/weaknesses once an incident (including LSASS driver persistence) is underway, matching the `responds` verb with a named remainder for pre-containment impact.
T1547.009detects — A.5.26 requires a designated team to respond to incidents (including detection via reported anomalies or logs per its procedures and subpoints d/h/i), which surfaces T1547.009 once the shortcut modification has executed and persistence is active, but does not mandate proactive monitoring or specific detection of the technique itself.
T1547.009prevents — A.5.26's incident response procedures (containment, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that caused/contributed/failed to prevent the incident) stop the T1547.009 persistence technique from continuing or recurring once it has been observed.
T1547.009responds — A.5.26 requires a competent team to respond to incidents once underway via containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis and vulnerability/weakness management — all of which directly address an already-executed T1547.009 persistence technique (e.g. containing spread, removing the malicious shortcut, patching the exploited weakness).
T1547.010detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause identification) can surface the port monitor DLL or registry change once it has executed on an organizational Windows system, but the technique occurs pre-compromise during boot with no guaranteed observable event on the organization's estate in all cases.
T1547.010prevents — A.5.26's designated competent team and procedures for containing spread, coordinating externally, and managing the vulnerabilities/weaknesses that enabled the incident (including the persistence mechanism itself) stop the port-monitor technique from achieving its persistence or privilege-escalation goal in the great majority of cases once it is recognized.
T1547.010responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, analyze root cause, and close an information security incident once it is underway, which directly matches the act of responding to a T1547.010 persistence technique that has already executed at boot.
T1547.012detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause investigation and identifying related weaknesses once an incident is underway, which can surface a print-processor DLL load during boot/spooler restart if it triggers observable anomalies or is investigated; however the technique's pre-boot installation (registry + file drop) and SYSTEM-level execution often leave no incident-triggering event on the organization's estate until after impact, and the clause's scope is limited to declared incidents rather than continuous monitoring of boot artifacts.
T1547.012prevents — A.5.26's designated competent team and procedures for containing spread, coordinating with parties, managing related vulnerabilities/weaknesses, and post-incident root-cause work (including those that failed to prevent) stop the persistence/privilege-escalation technique from achieving lasting impact in most cases once it is known or underway.
T1547.012responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, analyze root cause/vulnerabilities/weaknesses that enabled the incident, and formally close it once addressed — which matches the `responds` act of containment and eradication once the persistence technique has already run.
T1547.013detects — A.5.26 requires a designated competent team to respond to incidents (including detection via reported anomalies, evidence collection, logging, and post-incident root-cause analysis), which surfaces the T1547.013 persistence technique once it has executed at login; the remainder is that purely proactive/pre-execution detection lives in other controls such as monitoring or scanning.
T1547.013prevents — A.5.26's incident response procedures (containment, forensic analysis, root-cause identification, vulnerability/weakness management including failed controls) directly prevent the persistence technique from surviving or recurring once it has been executed and detected.
T1547.013responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment (a), evidence collection (b), logging (d), escalation (c), communication (e), coordination (f), forensic analysis (h), root-cause post-incident review (i), and vulnerability/weakness remediation (j), which matches the `responds` verb for an already-executed persistence technique; the named remainder is that the autostart entry itself may already have executed before response begins.
T1547.014detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause identification) can surface the Active Setup Registry key or its execution artifact once the technique has run and produced observable effects on the organization's estate, but the clause's scope is limited to post-incident response rather than continuous monitoring of logins or Registry changes, and many instances (e.g., on unmanaged endpoints or before any incident is declared) go unseen.
T1547.014prevents — A.5.26 requires a designated competent team to respond to incidents once underway (containment, eradication, root-cause analysis, vulnerability remediation), which prevents the T1547.014 persistence from surviving or recurring after the initial login execution.
T1547.014responds — A.5.26 requires a competent team to respond to incidents once underway via containment, eradication, logging, escalation, forensic analysis, root-cause identification, and vulnerability/weakness management — directly addressing an already-established Active Setup persistence technique per the event-lane definition of responds.
T1547.015detects — A.5.26 requires a designated competent team to respond to incidents (including detection via reported anomalies or observed effects of persistence), but its core focus is post-detection response procedures rather than proactive or broad detection mechanisms for the technique itself.
T1547.015prevents — A.5.26's incident response procedures (containment, forensic analysis, root-cause identification, vulnerability/weakness management including failed controls) directly prevent the persistence technique from continuing to execute on subsequent logins once the incident is underway.
T1547.015responds — A.5.26 explicitly requires a designated competent team to respond to incidents (including containment, evidence collection, escalation, logging, communication, coordination, forensic analysis, root-cause identification, and post-incident vulnerability/weakness management), which matches the act of responding once the T1547.015 persistence technique has already run and is underway.
T1548prevents — A.5.26's designated competent team responding to an incident (including containment, root-cause analysis, vulnerability management in j, and closing the incident) stops the T1548 technique from continuing or succeeding further once it has begun, which satisfies the `prevents` verb per the event-lane anchors (cf. A.5.26 vs T1486 mostly and A.8.5 vs T1110.001 mostly).
T1548.001detects — A.5.26 requires a designated competent team to respond to incidents (including detection, containment, evidence collection, logging, and post-incident root-cause analysis), which surfaces setuid/setgid abuse once it has produced observable incident effects, but the clause does not mandate proactive monitoring or detection of the technique itself before impact.
T1548.001prevents — A.5.26's designated competent team and procedures for containing spread (a), coordinating with parties to minimize consequences (f), and identifying/managing vulnerabilities/weaknesses that caused/contributed/failed to prevent the incident (j) stop the setuid/setgid abuse technique from completing its privilege-escalation goal in most cases once underway.
T1548.002detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause identification) can surface a realized UAC bypass once it has produced observable effects on the estate, but the pre-compromise technique itself (and many of its in-memory or auto-elevation variants) has no guaranteed footprint inside the control's defined scope or response triggers.
T1548.002prevents — A.5.26's designated competent team, containment (a), coordination (f), forensic/root-cause analysis (h/i), and explicit identification+management of the vulnerabilities/weaknesses that caused/contributed/failed to prevent the incident (j) directly stop the UAC-bypass technique from recurring on the affected and peer systems.
T1548.002responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, analyze root cause, and close an information security incident once it is underway, which directly matches the `responds` verb for a UAC-bypass technique that has already executed to elevate privileges.
T1548.003detects — A.5.26 requires a designated competent team to respond to incidents (including detection via reported anomalies or logs per its subpoints on evidence collection, logging, and post-incident analysis), which surfaces some sudo caching/sudoers abuse once it triggers an observable incident, but the control's scope is limited to incident response rather than proactive or comprehensive technique detection.
T1548.003prevents — A.5.26's designated competent team and explicit step (j) to identify/manage vulnerabilities/weaknesses (including controls that failed to prevent the incident) directly stops the poor sudo/sudoers configuration from being left exploitable after an observed incident, and its containment/escalation steps bound further abuse of an active sudo-cache technique; this is genuine prevention for the bulk of the class with only the pre-detection first abuse as named remainder.
T1548.003responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, analyze root cause, and close an information security incident once it is underway, which matches the `responds` verb against an in-progress sudo-caching or sudoers-abuse privilege-escalation technique.
T1548.004detects — A.5.26 requires a designated competent team to respond to incidents (including detection via reported/escalated events, evidence collection, logging, and post-incident analysis), but its scope is limited to incidents already underway or reported rather than proactive detection of the macOS API abuse technique itself.
T1548.004prevents — A.5.26's designated competent team and procedures for containing spread (a), coordinating with parties to minimize consequences (f), and managing vulnerabilities/weaknesses that failed to prevent the incident (j) stop the technique from completing its full privilege-escalation and persistence outcome in most cases once underway, per the event-lane anchor that grades the identical control mostly for responds against the closely related T1486.
T1548.004responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, analyze, close and post-process an information security incident once it is underway, which matches the `responds` verb against an in-progress privilege-escalation technique.
T1548.005detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause identification) can surface the abuse of temporary elevated access once it occurs on the organization's estate, but pre-compromise reconnaissance, misconfiguration enabling the path, and purely external just-in-time requests have no organizational event for the team to respond to.
T1548.005prevents — A.5.26's designated competent team, containment (a), escalation/crisis invocation, coordination, forensic/root-cause analysis, and explicit identification+management of the vulnerabilities/weaknesses that caused/contributed/failed to prevent the incident directly stop the misconfigured just-in-time/impersonation/pass-role paths from being (re)used after the first occurrence.
T1548.005responds — A.5.26 explicitly requires a designated competent team to respond to incidents (once underway) via containment, escalation, evidence collection, logging, communication, coordination, forensic analysis, root-cause review, and vulnerability/weakness management — all of which directly address an in-progress or realized T1548.005 abuse of temporary elevated cloud access.
T1548.006detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause identification and communicating the incident, all of which can surface TCC manipulation once it has produced observable effects on a monitored macOS system; however the technique occurs pre-compromise on the local TCC.db with no guaranteed system-level artifact, so only a slice is detectable.
T1548.006prevents — A.5.26's designated competent team, containment (a), coordination (f), and post-incident root-cause/vulnerability management (i,j) directly stop the TCC-manipulation technique from completing or recurring once it is known, with the bounded remainder being the initial undetected abuse before response is triggered.
T1548.006responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, analyze root cause, and close an information security incident once underway, which directly matches the act of responding to a TCC manipulation technique that has already executed.
T1550detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause identification and communicating the incident once it is underway, which can surface use of stolen alternate auth material (e.g. via anomalous access or credential-use telemetry) on the organization's own estate; it does not detect the technique when it occurs entirely outside that estate (e.g. on external identity providers, SaaS, or during pre-compromise reconnaissance).
T1550prevents — A.5.26's designated competent team responding to an incident (containing spread, coordinating, closing, and addressing root causes/vulnerabilities per j) stops the adversary's ongoing use of stolen alternate auth material for lateral movement once the incident is detected.
T1550responds — A.5.26 explicitly requires a designated competent team to respond to incidents (including containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis, and vulnerability management), which directly addresses an in-flight or realized T1550 use of stolen alternate auth material once underway.
T1550.001detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause identification and communicating the incident, all of which can surface use of a stolen application access token once it is already in use on the organization's estate; the pre-compromise acquisition step itself is invisible to these activities.
T1550.001prevents — A.5.26 requires a designated competent team to respond to incidents (including containment, evidence collection, escalation, forensic analysis, root-cause identification, and vulnerability/weakness management), which prevents the T1550.001 technique from continuing or succeeding further once it has begun (e.g., by revoking tokens, fixing misconfigurations, or addressing the initial compromise).
T1550.001responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, escalate, communicate, and close an information security incident once underway, which directly matches the `responds` verb against an adversary technique that has already succeeded in using a stolen token.
T1550.002prevents — A.5.26's designated competent team responding to an incident (with containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis, and vulnerability/weakness management) prevents the PtH technique from continuing to run or spreading once it has begun, though it does not stop the initial hash theft or first use.
T1550.002responds — A.5.26 requires a designated competent team to respond to incidents (including containment, eradication, forensic analysis, root-cause identification, and vulnerability management once underway), which directly addresses a realized PtH lateral-movement incident per the event-lane definition of responds.
T1550.003detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause identification and post-incident review, all of which can surface PtT once it has occurred on the organization's estate; however the technique's pre-compromise acquisition of tickets (via credential dumping) and its use on remote systems can occur outside monitored scope or before any incident is declared, leaving a genuine slice undetected.
T1550.003prevents — A.5.26's incident response procedures (containment of affected systems, coordination, vulnerability/weakness management including failed controls, and post-incident root-cause fixes) stop PtT from recurring after the initial credential theft, though they do not stop the first successful ticket capture or use.
T1550.003responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, escalate, communicate, and close an information security incident once underway, which directly matches the `responds` verb against an in-progress PtT lateral-movement technique.
T1550.004detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause identification and communicating details once an incident is underway, which can surface use of a stolen web session cookie as part of an already-realised breach on the organization's estate; it does not detect the upstream cookie theft itself or pre-compromise acquisition.
T1550.004prevents — A.5.26's designated competent team, containment (a), coordination (f), and post-incident root-cause/vulnerability management (i,j) directly stop the adversary's ongoing use of the stolen cookie once the incident is detected, preventing further access or actions; the named remainder is that it cannot stop the initial cookie theft or first use before the incident is recognized.
T1550.004responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, analyze root cause, and close an information security incident once underway, which directly matches the act of responding to an adversary's use of a stolen web session cookie (T1550.004) after it has begun.
T1552detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause identification and managing the weaknesses exposed by an incident; when an unsecured-credential artifact is left on a compromised system it is observable in those steps, but the clause's core (containment/escalation/communication of an already-underway incident) has no object until after the search succeeds, and pre-compromise credential searches on external systems leave nothing on the organization's estate to detect.
T1552prevents — A.5.26's designated competent team responding to an incident (containing spread, forensic analysis, root-cause identification, and explicitly managing the vulnerabilities/weaknesses that allowed the incident) stops unsecured-credential artifacts from remaining available for further adversary use on the compromised system(s).
T1552recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability/weakness management in j, forensic analysis, and formal closure) enable recovery of the unsecured-credential state by identifying and addressing the specific insecure storage that allowed the technique, with the named remainder being immediate credential replacement or rotation that lives in other controls.
T1552responds — A.5.26 requires a designated competent team to respond to incidents (including containment, evidence collection, logging, coordination, forensic analysis, root-cause review and vulnerability remediation), which directly acts on an already-underway T1552 event to bound its spread, remove footholds and address related weaknesses.
T1552.001detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause, and vulnerability management) can surface credentials-in-files when the incident is already underway or when logs/configs are examined, but the technique occurs pre-compromise on adversary-controlled or external infrastructure with no guaranteed organizational event to respond to.
T1552.001prevents — A.5.26's designated competent team responding to an incident (containing spread, forensic analysis, root-cause identification, and explicitly managing the vulnerabilities/weaknesses that allowed the incident) stops the T1552.001 search technique from continuing or recurring on affected systems.
T1552.001recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability management in j, formal closure) enable recovery actions that remove the insecure credential files or the credentials themselves after the technique has run.
T1552.001responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, analyze root cause, and close an information security incident once underway, which directly matches the act of responding to T1552.001 credential searches that have already occurred.
T1552.002prevents — A.5.26's designated competent team responding to an incident (including containment, evidence collection, escalation, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that allowed the incident) stops insecure credential storage from being repeatedly queried for new credentials on the same or other systems.
T1552.002recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability management in j, formal closure) enable recovery actions that restore secure state after the credential-search technique has run and credentials may have been exfiltrated.
T1552.003detects — A.5.26 requires a designated competent team to respond to incidents (including detection, containment, analysis, and post-incident root-cause work that surfaces how the adversary obtained credentials via shell history), which directly detects the T1552.003 technique once it has run as part of an incident.
T1552.003prevents — A.5.26's designated competent team responding to an incident (including containment, evidence collection, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that enabled it) stops the adversary technique from being repeatable on the same or similar systems, which is what `prevents` asserts for an already-compromised environment; the bounded remainder is that it does not stop the initial credential-leakage behavior before the first incident is detected.
T1552.003recovers — A.5.26's post-incident analysis, root-cause identification, vulnerability/weakness management (item j), and formal closure directly enable recovery actions that remove the insecure shell-history credential artifacts after the T1552.003 search has already run.
T1552.003responds — A.5.26 requires a designated competent team to respond to incidents (once underway) via containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis, and vulnerability/weakness management; this directly matches the post-compromise discovery and exploitation of shell history for credentials as an information security incident.
T1552.004prevents — A.5.26's designated competent team, containment (a), forensic analysis (h), root-cause identification (i), and explicit management of vulnerabilities/weaknesses that caused/contributed/failed to prevent the incident (j) stop the T1552.004 search-and-exfil technique from completing or recurring once the incident is underway.
T1552.005detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause, vulnerability management) can surface the technique once it has produced observable artifacts on the organization's estate, but many executions (especially SSRF-based queries from outside the instance) leave no internal evidence for the incident response process to engage.
T1552.005prevents — A.5.26's designated competent team, containment (a), coordination (f), and vulnerability/weakness management (j) directly stop the technique from succeeding or recurring when the incident is already underway or has been detected, with the bounded remainder being pre-compromise prevention of initial presence or SSRF that lives in other controls.
T1552.005recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability management in j, formal closure) enable recovery actions that restore security posture after the metadata API access technique has run and credentials exfiltrated, with the named remainder being direct data restoration (e.g. credential rotation or secret invalidation) handled by other controls.
T1552.005responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, analyze root cause, and close an information security incident once underway, which directly matches the act of responding to an adversary already accessing the Instance Metadata API via presence on the instance or SSRF.
T1552.006detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause, vulnerability management) can surface the post-compromise use of this technique on the organization's estate, but the technique's core (enumerating/decrypting GPP files from SYSVOL) can occur entirely via legitimate domain-user access with no observable incident trigger, and pre-compromise discovery leaves nothing for response to act on.
T1552.006prevents — A.5.26's designated competent team and explicit steps (a) contain spread, (b) collect evidence, (c) escalate/invoke continuity, (e-f) communicate/coordinate, (i-j) perform root-cause analysis and manage the vulnerabilities/weaknesses that caused/contributed/failed-to-prevent the incident directly stop the GPP credential-exposure technique from recurring in the environment.
T1552.006recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability management in j, formal closure) enable recovery actions that restore secure state after the GPP credential exposure has occurred, with the named remainder being that the control itself does not perform the actual credential rotation or SYSVOL remediation.
T1552.006responds — A.5.26 explicitly requires a designated competent team to respond to incidents (including containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis, and vulnerability management), which directly matches the post-exploitation credential-harvesting technique once it is underway.
T1552.007detects — A.5.26's monitoring, logging (d), evidence collection (b), forensic analysis (h), and post-incident root-cause steps (i) can surface the API access and credential-gathering activity once it touches the organization's estate, but the technique's pre-compromise reconnaissance and external API calls (especially on registrar or unmanaged infrastructure) leave a large slice undetected.
T1552.007prevents — A.5.26's designated competent team responding to an incident (including containment, evidence collection, escalation, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that caused/contributed/failed to prevent it) stops the T1552.007 technique from continuing or recurring in the same environment.
T1552.007recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability/weakness management in j, formal closure) restore the organization's security posture after the credential-gathering technique has run, which is what recovers asserts; the named remainder is that it does not itself restore any exfiltrated credentials or data.
T1552.007responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis and vulnerability management — all of which directly address an in-progress or realized T1552.007 credential-gathering event in a container environment.
T1552.008detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause identification) can surface credentials already exfiltrated via chat messages on the organization's estate, but the technique's upstream acquisition (e.g. on external SaaS servers, public channels, or pre-compromise) has no affected system or observable event for the response team to act on.
T1552.008prevents — A.5.26's designated competent team following defined procedures for containment, evidence handling, escalation, communication, coordination, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that enabled the incident (item j) stops the T1552.008 technique from successfully completing its follow-on abuse (lateral movement, privilege escalation) in the large majority of cases once the chat-message credential exposure has begun.
T1552.008recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability management in j, formal closure) enable recovery from the credential-exposure event once it has run, with the named remainder being any unaddressed credentials already exfiltrated and abused before response begins.
T1552.008responds — A.5.26 explicitly requires a designated competent team to respond to incidents (including containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis, and vulnerability remediation), which directly matches the post-breach response lane once T1552.008 credential collection has occurred and is underway.
T1553detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause identification) surface and document the subverted trust controls once the technique has run on the organization's estate, but the pre-compromise acquisition of certificates or the modification steps themselves occur outside monitored scope and yield no incident until execution.
T1553prevents — A.5.26's designated competent team and explicit steps (a: contain spread; b: collect evidence; h: forensics; i: root-cause analysis; j: identify/manage the vulnerabilities/weaknesses that caused/contributed/failed to prevent) directly stop the T1553 technique from completing or recurring once it has begun, with the named remainder being the initial subversion act that has already succeeded before response is invoked.
T1553recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability/weakness management in j, forensic analysis, formal closure) act after the T1553 subversion has succeeded to restore trust posture and prevent recurrence, exactly as the recovers verb names; the named remainder is that it does not itself restore any already-compromised system state or data.
T1553responds — A.5.26 requires a designated competent team to respond to incidents (containment, eradication, root-cause analysis, vulnerability management) once underway; this bounds the impact of a T1553 subverted-trust technique that has already executed and is the exact act `responds` names, with the named remainder being pre-containment damage already realized.
T1553.001prevents — A.5.26's designated competent team response to an incident (containing spread, evidence collection, escalation, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that enabled the incident) directly stops the T1553.001 technique from continuing or recurring on affected systems.
T1553.002prevents — A.5.26's designated competent incident response team (with containment, evidence collection, forensic analysis, root-cause identification, and explicit management of vulnerabilities/weaknesses that caused/contributed/failed to prevent the incident) directly stops the T1553.002 technique from continuing or recurring once it has begun, which satisfies `prevents` per the event-lane definition and A.5.26 vs T1486 anchor.
T1553.002responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, analyze root cause, and close an information security incident once underway, which directly matches the `responds` verb against an adversary's use of stolen or forged code-signing materials to run malware.
T1553.003detects — A.5.26 requires a designated competent team to respond to incidents (including detection via reported anomalies, evidence collection, logging, forensic analysis, and post-incident root-cause identification), which surfaces SIP/trust provider hijacking once it is recognized as an incident, but the control's scope is limited to response after the fact rather than continuous monitoring or proactive detection of the technique.
T1553.003prevents — A.5.26's incident response procedures (containment, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that caused/contributed/failed to prevent the incident) stop the SIP/trust-provider hijack technique from continuing or recurring once it has been detected as an information security incident.
T1553.003responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, analyze root cause, close, and coordinate on an information security incident once underway, which directly matches the act of responding to a T1553.003 hijacking that has already occurred.
T1553.004detects — A.5.26 requires a designated competent team to respond to incidents (including detection via reported anomalies, evidence collection, logging, forensic analysis, and post-incident root-cause identification), which surfaces the T1553.004 technique once it has run on a compromised system; however, the control's scope is limited to incident response procedures rather than continuous proactive monitoring or scanning that would catch the technique universally.
T1553.004prevents — A.5.26's designated competent team, containment (a), forensic analysis (h), root-cause identification (i), and explicit management of vulnerabilities/weaknesses that caused/contributed/failed to prevent the incident (j) directly stop the post-compromise technique from completing or recurring on affected systems.
T1553.005detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause, and vulnerability management) can surface the bypass once it has produced observable artifacts on the organization's estate, but the pre-execution technique itself occurs on external download/mount surfaces outside the incident-response scope, leaving a large remainder undetected until impact.
T1553.005prevents — A.5.26 requires a designated competent team to respond to incidents once underway (containment, eradication, root-cause analysis, vulnerability management), which stops the MOTW-bypass technique from completing its full intended effect on the affected systems; the named remainder is that the technique can still initially succeed before detection/response begins.
T1553.005recovers — A.5.26's post-incident steps (i, j) plus formal closure and root-cause handling restore the organization's security posture after a MOTW-bypass technique has already run and delivered its payload.
T1553.005responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, analyze root cause, close, and manage the vulnerabilities/weaknesses that enabled the incident once it is already underway, which matches the `responds` verb for a technique that has executed.
T1553.006detects — A.5.26 requires a designated competent team to respond to incidents (including detection, containment, evidence collection, logging, forensic analysis, and post-incident root-cause work), which surfaces the T1553.006 technique once it has run and produced observable artifacts; the scope is limited to incidents already underway rather than proactive detection of all policy modifications.
T1553.006prevents — A.5.26's designated competent team responding to an incident (containing spread, forensic analysis, root-cause identification, and explicitly managing the vulnerabilities/weaknesses that allowed the incident) directly stops the adversary technique from continuing or recurring on affected systems, though the initial policy modification has already succeeded before response begins.
T1553.006responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, analyze root cause, close, and manage related vulnerabilities once an incident is underway, which directly matches the act of responding to a T1553.006 technique that has already run on a compromised system.
T1554detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause, vulnerability management) can surface the binary modification once it is active or during investigation of related effects, but the clause's scope is incident response after occurrence rather than proactive monitoring of binaries or file integrity, leaving most stealthy or pre-impact modifications unseen.
T1554prevents — A.5.26's designated competent team response (containment, evidence collection, escalation, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that caused/contributed/failed to prevent the incident) stops the T1554 technique from completing its persistence goal once underway, with a bounded remainder for pre-response execution that already achieved the modification.
T1554responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, analyze root cause, close, and address the incident once underway, which matches the `responds` verb for an already-executed T1554 binary modification.
T1555prevents — A.5.26's designated competent team responding to an incident (including containment, evidence collection, escalation, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that allowed the incident) stops the T1555 technique from continuing or recurring once it has begun, which satisfies `prevents` for the bulk of the technique's post-execution lifetime; the named remainder is that it does not stop the initial search-and-exfil step before the incident is recognized.
T1555recovers — A.5.26 requires a designated competent team to respond under communicated procedures — containment, eradication, root-cause analysis, vulnerability management and formal closure of an already-underway incident; this restores organizational posture after T1555 has succeeded in stealing credentials (the technique ran; responding bounds spread and removes the actor's foothold).
T1555responds — A.5.26 requires a competent team to respond to incidents once underway via containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis and vulnerability management — all of which directly address an in-progress or realized T1555 credential-theft incident.
T1555.001detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause identification and communicating the incident once it occurs, which can surface Keychain credential access on the organization's own macOS estate; however, the technique can be performed entirely outside monitored scope (e.g. on unmanaged endpoints or pre-compromise) and the clause sets response scope rather than mandating universal detection instrumentation.
T1555.001prevents — A.5.26's designated competent team, containment (a), forensic analysis (h), root-cause identification (i), and explicit management of vulnerabilities/weaknesses that failed to prevent the incident (j) stop the Keychain credential-acquisition technique from recurring on the affected and coordinated systems.
T1555.001recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability management, formal closure, and coordination) enable recovery of credentials or systems after the Keychain dump has occurred, with the named remainder being that it does not itself restore the stolen credentials.
T1555.001responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, analyze root cause, close, and manage vulnerabilities/weaknesses of an information security incident once underway, which directly matches the credential-acquisition technique T1555.001 when it is detected as an incident.
T1555.002prevents — A.5.26's designated competent team, containment (a), forensic analysis (h), root-cause identification (i), and explicit management of vulnerabilities/weaknesses that failed to prevent the incident (j) directly stop the T1555.002 technique from recurring on affected and similar systems.
T1555.002recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability management in j, formal closure) enable recovery of credentials or systems after the memory-read technique has succeeded, with the named remainder being that it does not itself restore the specific stolen keychain material.
T1555.002responds — A.5.26 explicitly requires a designated competent team to contain (a), eradicate via root-cause/vuln fixes (i,j), and formally close an already-underway incident such as credential dumping from securityd memory, with the named remainder being impact realized before containment.
T1555.003detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause, and vulnerability management) can surface browser-credential theft once it has produced observable artifacts on the organization's estate, but the pre-compromise technique itself (reading browser files or process memory) has no inherent incident trigger and many instances remain invisible to response procedures.
T1555.003prevents — A.5.26's designated competent team responding to an incident (including containment, evidence collection, escalation, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that enabled it) stops the credential-acquisition technique from continuing or recurring on affected systems, with the named remainder being undetected incidents that never trigger the response process.
T1555.003recovers — A.5.26's post-incident steps (forensic analysis, root-cause identification, vulnerability/weakness management in j, and formal closure) enable recovery actions that restore credential hygiene and limit further use of stolen browser credentials, though the technique's initial execution and data exfiltration are not undone by response alone.
T1555.003responds — A.5.26 requires a designated competent team to respond to incidents (including containment, evidence collection, logging, escalation, communication, forensic analysis, root-cause identification, and vulnerability/weakness management once the incident is underway), which directly matches the post-acquisition phase of T1555.003 credential theft from browsers.
T1555.004detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause, vulnerability management) can surface the technique once it has run on an organizational Windows system, but the pre-compromise acquisition of credentials from Credential Manager (including via vaultcmd, file reads, or APIs) has no guaranteed observable event on the organization's estate and many of the clause's ten activities have an empty object
T1555.004prevents — A.5.26's designated competent team, containment (a), forensic/root-cause analysis (h/i), vulnerability/weakness management (j), and coordination directly stop the technique from successfully acquiring credentials once an incident is underway, with a named remainder of pre-detection thefts that succeed before response begins.
T1555.004recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability management in j, formal closure) enable recovery actions that can restore credentials or replace compromised ones after the T1555.004 theft has occurred.
T1555.004responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, analyze root cause, and close an information security incident once underway, which directly matches the act of responding to T1555.004 credential theft after it has begun.
T1555.005detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause identification) can surface the in-memory extraction or brute-force attempt once it has touched the organization's estate, but the technique's core act (credential extraction from a third-party password manager) can occur entirely outside monitored scope or pre-compromise with no affected system or observable artifact on the estate.
T1555.005prevents — A.5.26 requires a designated competent team to respond to incidents (including containment, evidence collection, forensic analysis, root-cause identification, and vulnerability/weakness management that caused/contributed/failed to prevent the incident); this directly prevents the T1555.005 technique from completing successfully when the incident (e.g., memory extraction or brute-force of the master password) is detected in flight.
T1555.005recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability management in j, formal closure) enable recovery of credentials or systems after T1555.005 has succeeded, with the named remainder being that it does not itself restore the stolen credentials or undo the compromise.
T1555.005responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, analyze root cause, and close an information security incident once underway, which directly matches the act of responding to an adversary technique that has already executed to steal credentials from a running password manager.
T1555.006detects — A.5.26's response activities (evidence collection, logging, post-incident analysis, root-cause identification) can surface the technique once it has run on the organization's IaaS estate, but pre-compromise acquisition of secrets (e.g. via compromised high-priv accounts) often leaves no organizational event for the team to respond to.
T1555.006prevents — A.5.26's designated competent team, containment (a), escalation/crisis invocation (c), coordination (f), and explicit post-incident identification/management of the vulnerabilities/weaknesses that enabled the incident (j) stop the T1555.006 technique from continuing or recurring once it has begun, which is what `prevents` asserts on the event lane.
T1555.006recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability management in j, formal closure) enable recovery actions that restore the pre-incident state after credential theft via secrets manager access, with the named remainder being any unaddressed root vulnerabilities that could allow re-occurrence.
T1555.006responds — A.5.26 explicitly requires a designated competent team to respond to incidents (once underway) via containment, evidence collection, escalation, logging, communication, coordination, forensic analysis, root-cause identification, and post-incident remediation of related vulnerabilities/weaknesses — all of which directly address an in-progress or realized T1555.006 credential theft from a cloud secrets manager.
T1556detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause identification) can surface the modification once it has produced observable effects on the organization's estate, but the technique's upstream execution (e.g. on external identity providers, SaaS, or non-monitored network devices) lies outside the control's scope and produces no incident for the team to respond to.
T1556prevents — A.5.26's designated competent team and explicit steps (a) contain spread, (c) escalate/invoke continuity, (f) coordinate externally, and (j) identify/manage the vulnerabilities/weaknesses that enabled the authentication-process modification, stopping the technique from achieving or sustaining its access goal in most cases once underway.
T1556responds — A.5.26 requires a designated competent team to respond to incidents (including containment, eradication, forensic analysis, root-cause identification, and vulnerability/weakness management per items a–j), which directly addresses an already-underway T1556 modification of authentication once detected.
T1556.001detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause identification and managing the weaknesses exposed by an incident that has already occurred on the estate; a domain-controller authentication patch (Skeleton Key) produces detectable artifacts once it runs and is used, but the pre-compromise acquisition and the technique itself sit outside organizational monitoring scope, so only a slice is engaged.
T1556.001prevents — A.5.26's designated competent team following defined procedures for containment (a), evidence collection, escalation, forensic analysis (h), root-cause identification (i), and explicit management of the vulnerabilities/weaknesses that enabled the incident (j) stops the Skeleton Key patch from persisting or being reused after detection, which is what `prevents` asserts for this technique.
T1556.001recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability/weakness management in j, forensic analysis, formal closure) enable recovery of the authentication process and domain controller state after the T1556.001 patch is addressed and removed.
T1556.001responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, analyze root cause, and close an information security incident once underway, which directly matches the act of responding to a live T1556.001 compromise on a domain controller.
T1556.002detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause identification and post-incident review, all of which can surface the registration and use of a malicious password filter DLL once it has executed on a monitored Windows system; however, the technique occurs entirely within the LSA/authentication process on domain controllers or endpoints, and the control's scope is set by organizational requirements rather than mandating host-level instrumentation that would reliably catch it pre- or mid-execution.
T1556.002prevents — A.5.26's designated competent team and procedures for containing spread, collecting evidence, escalation, forensic analysis, root-cause identification, and explicitly managing/closing vulnerabilities and weaknesses that caused/contributed/failed to prevent the incident directly stop the registration and ongoing use of a malicious password filter DLL once the incident is underway.
T1556.002recovers — A.5.26's post-incident analysis, root-cause identification, vulnerability management (item j), and formal closure directly restore control and organizational state after the credential-harvesting technique has run, matching the recovers verb in the event lane (cf. A.5.26 vs T1486 recovers mostly anchor).
T1556.002responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, analyze root cause, and close an information security incident once underway, which directly matches the act of responding to a T1556.002 compromise that has already registered and is harvesting via a malicious filter DLL.
T1556.003detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause investigation and post-incident review, all of which can surface PAM modifications or anomalous authentication once the technique has produced observable artifacts on the organization's estate; the remainder is pre-compromise PAM patching or credential harvesting that leaves no detectable event until first use.
T1556.003prevents — A.5.26 requires a designated competent team to respond to incidents once underway (containment, eradication, root-cause analysis, vulnerability remediation), which stops the PAM backdoor from continuing to enable access/credential theft; the technique has already run, but the control prevents its ongoing or repeated success, with a named remainder (pre-compromise detection not guaranteed).
T1556.003recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability/weakness management in j, forensic analysis, formal closure) enable recovery of the authentication mechanism and accounts after the PAM modification technique has run, with the named remainder being any unaddressed residual compromise of credentials already harvested.
T1556.003responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, analyze root cause, close, and manage vulnerabilities/weaknesses once an incident (such as a PAM modification/backdoor) is underway, matching the `responds` verb definition.
T1556.004recovers — A.5.26's post-incident analysis, root-cause identification, vulnerability management (item j), and formal closure enable recovery of the network device to a non-backdoored state once the incident is underway.
T1556.005detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause identification) can surface the AD property change or resulting credential exposure once it has occurred on the organization's estate, but the technique's pre-compromise setup (e.g. via FGPP or PowerShell on a domain controller) often leaves no observable event inside the clause's defined scope until after credentials are abused.
T1556.005prevents — A.5.26's designated competent team, containment, forensic analysis, root-cause identification, and explicit step (j) to identify/manage the vulnerabilities/weaknesses (reversible encryption setting) that caused/contributed/failed to prevent the incident directly stops the technique from being (re)used after the first occurrence.
T1556.005recovers — A.5.26 requires post-incident root-cause analysis, forensic work, vulnerability/weakness remediation (including controls that failed to prevent the incident), and formal closure; this directly restores the reversible-encryption configuration and related credential-exposure state once the technique has already run, matching the recovers verb (with the named remainder that immediate containment steps in the same list are not recovery).
T1556.005responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, analyze root cause, and close an information security incident once underway, which directly matches the act of responding to an adversary abusing reversible encryption (T1556.005) after it has begun.
T1556.006detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause identification and communicating the incident, all of which can surface the MFA modification once it has produced observable effects on the organization's estate; however the technique can be performed entirely outside monitored scope (e.g. on an external IdP or SaaS tenant with no internal logs or alerts triggered), so only a slice is detected.
T1556.006prevents — A.5.26's designated competent team and explicit steps (a) contain spread, (c) escalate/invoke continuity, (f) coordinate externally, and (j) identify/manage the MFA-disabling vulnerabilities/weaknesses that enabled the technique, stopping it from achieving or sustaining persistent access in most cases once underway.
T1556.006recovers — A.5.26's post-incident analysis, root-cause identification, vulnerability/weakness management (including failed controls), and formal closure directly restore MFA defenses after the T1556.006 modification/disablement has occurred, matching the recovers verb; the named remainder is that immediate containment/escalation steps precede full recovery.
T1556.006responds — A.5.26 requires a competent team to respond to incidents already underway via containment, eradication, escalation, logging, coordination, closure, forensics, root-cause analysis, and explicit management of the vulnerabilities/weaknesses (including failed controls) that enabled the incident; this directly matches responding to an adversary technique that has already succeeded in disabling/modifying MFA for persistence.
T1556.007detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause identification and post-incident review, all of which can surface the hybrid-identity backdoor once it is used in an authentication event on the organization's estate; the pre-compromise registration or DLL injection itself sits outside organizational monitoring scope and is unreachable by these activities.
T1556.007prevents — A.5.26's designated competent team and explicit steps (a) contain spread, (b/c) collect/escalate evidence, (e/f) communicate/coordinate, (i/j) perform root-cause analysis plus identify/manage the exact vulnerabilities/weaknesses that enabled the backdoor directly stop the T1556.007 technique from completing or recurring; the named remainder is that the initial compromise enabling the patch must already have occurred for response to trigger.
T1556.007recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability/weakness management in j, formal closure) enable recovery of the authentication process and identities after the backdoor has been addressed, matching the recovers verb in the event lane (with named remainder on unaddressed cloud-side or persistent credential impacts).
T1556.007responds — A.5.26's designated competent team and enumerated activities (contain spread, collect/analyze evidence, log, escalate, communicate, coordinate, close/record, forensics, root-cause, manage resulting weaknesses) engage once the hybrid-identity backdoor is present and in use, with the named remainder being pre-compromise discovery or purely cloud-side registration that leaves no on-premises artifact for the response team to contain or eradicate.
T1556.008detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause, vulnerability management) can surface the malicious DLL or anomalous credential-capture behavior once the technique has run on the organization's estate, but pre-compromise registration of the provider and many logon events fall outside the incident-response scope.
T1556.008prevents — A.5.26's incident response procedures (containment, evidence collection, escalation, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that enabled the incident) stop the T1556.008 technique from continuing or recurring once it has begun to run, which satisfies the `prevents` verb per the event-lane anchors that separate it from `responds` and `recovers`.
T1556.008recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability management in j, formal closure) enable recovery of the credential-theft foothold once the technique has run, with the named remainder being any already-compromised credentials that cannot be un-stolen.
T1556.008responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, analyze root cause, close, and manage related vulnerabilities once an incident (such as credential-capturing via a planted Network Provider DLL) is underway.
T1556.009detects — A.5.26's response activities include collecting evidence, logging, communicating, coordinating, closing/recording, root-cause analysis and identifying weaknesses once an incident is underway, which can surface the modification of conditional access policies when it triggers an observable security incident on the organization's estate; however, the technique can occur pre-compromise entirely outside the organization's visibility (e.g. on an external IdP console) with no affected system or evidence to respond to.
T1556.009prevents — A.5.26's designated competent team responding to an incident (including containment, escalation, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that enabled it) stops the adversary from completing or sustaining the T1556.009 modification in the live environment, with the named remainder being pre-response persistence already achieved.
T1556.009recovers — A.5.26's post-incident analysis, root-cause documentation, vulnerability/weakness management (including failed controls), and formal closure directly restore the conditional-access policy state after the adversary's modification has already succeeded.
T1556.009responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, close, and post-analyze an information security incident once underway, which directly matches the act of responding to an adversary modifying conditional access policies (T1556.009) to maintain persistence.
T1557detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause identification) surface an in-progress or completed AiTM when it produces observable effects on the organization's estate, but the technique's upstream positioning (e.g. ARP/DNS poisoning on external or non-monitored segments) has no affected system or artifact for the team to engage.
T1557prevents — A.5.26 requires a designated competent team to respond to incidents (including containment, evidence collection, escalation, forensic analysis, root-cause identification, and vulnerability/weakness remediation), which prevents the AiTM technique from completing its full objectives or recurring when the response addresses the positioning, intercepted traffic, or enabling weaknesses (e.g., via post-incident fixes).
T1557recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability/weakness management in j, formal closure) enable recovery from realized AiTM positioning and its follow-on effects once the incident is underway.
T1557responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, analyze root cause, and formally close an information security incident once underway, which directly matches the `responds` verb against an in-progress AiTM positioning and its follow-on behaviors.
T1557.001detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause identification) can surface the poisoning/relay once it produces observable artifacts on the organization's estate, but the pre-compromise technique itself occurs on the wire outside monitored boundaries in many cases and has no guaranteed event object for the procedure to act on.
T1557.001prevents — A.5.26's designated competent team and procedures (including containment, coordination, forensic analysis, root-cause identification, and explicit management of vulnerabilities/weaknesses that caused/contributed/failed to prevent the incident) stop the name-resolution-poisoning technique from recurring on the network once it has been observed, which is what `prevents` asserts; the remainder is the initial occurrence before any response is mounted.
T1557.001recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability/weakness management in j, formal closure) enable recovery of the poisoned name-resolution state and any resulting compromise once the incident is underway, matching the recovers lane anchor for A.5.26 vs T1486.
T1557.001responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment, evidence collection, escalation, logging, communication, coordination, forensic analysis, root-cause review, and vulnerability/weakness management — all of which directly address an in-progress name-resolution poisoning + relay technique that has already begun responding to LLMNR/NBT-NS/mDNS traffic.
T1557.002detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause) can surface ARP cache poisoning once it is underway on the organization's estate, but the pre-compromise technique (gratuitous ARP replies on a local segment) has no guaranteed observable on the victim side until downstream effects appear, and the clause's scope is set by organizational requirements rather than mandating ARP-specific monitoring.
T1557.002prevents — A.5.26's incident-response procedures (containment, escalation, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that enabled the incident) stop ARP cache poisoning from recurring after the first occurrence, but do nothing to stop the initial technique from running on a network that still lacks static ARP entries, port security, or cryptographic protections.
T1557.002recovers — A.5.26 is strictly an incident-response procedure that acts while the technique is underway or immediately after; it contains, eradicates, logs, analyzes root cause, and manages residual vulnerabilities, but performs no restoration of pre-incident state (that is the separate act performed by backup/restoration controls such as A.8.13).
T1557.002responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, analyze root cause, close, and manage related vulnerabilities once an incident is underway, which directly matches responding to an in-progress ARP cache poisoning MITM technique.
T1557.003detects — A.5.26's response activities (evidence collection, logging, forensic analysis, post-incident root-cause) can surface DHCP spoofing once it produces observable network anomalies or AiTM effects on the organization's estate, but the pre-compromise technique (rogue server on external infrastructure or early broadcast phase) often leaves no internal event for the designated team to detect.
T1557.003prevents — A.5.26 requires a designated competent team to respond to incidents once underway (containment, evidence, escalation, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that enabled the incident), which stops a successful DHCP spoofing technique from continuing or recurring — satisfying `prevents` for the bulk of the technique's realized impact, with a named remainder being the initial undetected execution before response begins.
T1557.003recovers — A.5.26's post-incident analysis, root-cause identification, vulnerability/weakness management (including failed controls), and formal closure directly enable recovery of the network state after DHCP-spoofing AiTM or exhaustion has occurred.
T1557.003responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, analyze root cause, close, and manage related vulnerabilities once an incident is underway, which matches the `responds` verb against a realized DHCP spoofing technique.
T1557.004detects — A.5.26 explicitly requires a designated competent team to detect, log, analyze, and respond to incidents (including forensic analysis, root-cause identification, and vulnerability management), which surfaces an Evil Twin Wi-Fi attack once it is underway as an information security incident.
T1557.004prevents — A.5.26's designated competent team and explicit steps (a) contain spread, (b/c) collect/escalate evidence, (e/f) communicate/coordinate, and (j) identify/manage the vulnerabilities/weaknesses that enable evil twin setup directly stop the technique from completing or recurring when the incident is underway or just after, per the event-lane anchor that grades the identical clause `responds` mostly against T1486 while the same clause grades `prevents` mostly against T1110.001.
T1557.004recovers — A.5.26 response procedures (containment, evidence, escalation, logging, communication, forensics, post-incident analysis, vulnerability management) address an incident once underway but do not restore any pre-incident state destroyed by the evil twin technique
T1557.004responds — A.5.26's designated competent team and enumerated activities (contain spread, collect/analyze evidence, log, communicate, coordinate, close, root-cause, manage related weaknesses) engage once an evil-twin network is deployed and victims connect, exactly matching the `responds` rung for an already-underway technique.
T1558detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause, vulnerability management) can surface T1558 once it has produced observable artifacts on the organization's estate, but the technique's upstream acquisition and use of tickets often occurs without triggering those activities and the clause's scope is limited to post-incident response rather than proactive detection.
T1558prevents — A.5.26's designated competent team following defined procedures (including containment, evidence collection, escalation, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that enabled the incident) stops the T1558 technique from completing or recurring in the same form once it has begun, which satisfies the `prevents` verb per the event-lane anchors; the named remainder is that the initial theft/forgery can still occur before response is triggered.
T1558recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability management in j, formal closure) enable recovery of security posture after the T1558 technique has run and succeeded, though the control's primary focus is incident response rather than full system/data restoration.
T1558responds — A.5.26 explicitly requires a competent team to contain, eradicate, log, analyze root cause, close, and coordinate on an incident once underway, which matches the `responds` verb against an in-progress T1558 theft/forgery event.
T1558.001detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause identification) can surface a golden ticket once used in authentication or access, but the technique's core (offline KRBTGT hash theft and offline ticket forgery) occurs without touching organizational systems or logs until TGS requests are made
T1558.001prevents — A.5.26's designated competent team, containment (a), escalation/crisis invocation (c), coordination (f), and post-incident root-cause/vulnerability management (i,j) directly stop the golden-ticket technique from continuing or succeeding further once the incident is recognized, with the bounded remainder being the initial KRBTGT-hash theft that precedes detection.
T1558.001recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability management in j, formal closure) enable recovery actions that restore secure state after a golden-ticket compromise, though the control itself does not directly perform restoration of accounts, tickets or systems.
T1558.001responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment, escalation, evidence collection, logging, communication, coordination, forensic analysis, root-cause identification, and post-incident vulnerability/weakness management, which directly matches responding to a golden ticket incident (e.g., containing spread via forged TGS access, forensics on KRBTGT compromise, and addressing related credential-dumping weaknesses).
T1558.002prevents — A.5.26's incident response procedures (containment, escalation, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that caused/contributed/failed to prevent the incident) stop silver-ticket usage from continuing or recurring once the initial compromise that supplied the hash is known.
T1558.002recovers — A.5.26 requires a competent incident response team that contains spread, eradicates the actor's foothold (including forged silver tickets), coordinates, closes the incident, performs root-cause analysis, and explicitly identifies/manages the vulnerabilities/weaknesses that enabled it, thereby recovering from the realized technique.
T1558.002responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis and vulnerability management — all of which directly address a realized silver-ticket technique (T1558.002) with only the already-realized access/impact as named remainder
T1558.003detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause identification) can surface Kerberoasting artifacts once the technique has run on the organization's estate (e.g. anomalous TGS requests or cracked service-account hashes), but the technique's core actions occur on a DC or in network traffic that may fall outside the incident-response scope, and pre-compromise reconnaissance leaves no affected system to respond to.
T1558.003prevents — A.5.26's designated competent team and explicit steps (a) contain spread, (c) escalate/invoke continuity, (f) coordinate to minimize consequences for others, and (j) identify/manage the vulnerabilities/weaknesses that enabled the Kerberoasting directly stop the technique from completing its full effect (obtaining crackable hashes that enable persistence/escalation/lateral movement).
T1558.003recovers — A.5.26's post-incident analysis, root-cause documentation, vulnerability management (item j), and formal closure directly restore security posture after a Kerberoasting incident by addressing the cracked credentials, weak SPN accounts, and enabling controls.
T1558.003responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, analyze root cause, close, and manage vulnerabilities/weaknesses once an incident is underway, which directly matches the `responds` verb for a technique that has already executed to obtain crackable TGS tickets.
T1558.004detects — A.5.26 requires a designated competent team to respond to incidents (including detection, containment, analysis, and post-incident root-cause/vulnerability identification), which surfaces AS-REP roasting activity once underway as an information security incident.
T1558.004prevents — A.5.26's designated competent team responding to incidents (including containing spread, forensic analysis, root-cause identification, and managing the vulnerabilities/weaknesses that allowed the incident) directly stops AS-REP Roasting from completing its full chain to credential exposure and downstream tactics when the technique is detected in flight.
T1558.004recovers — A.5.26's post-incident analysis, root-cause documentation, vulnerability/weakness management (including failed controls), and formal closure directly enable recovery of the authentication posture after AS-REP roasting has succeeded and credentials are cracked.
T1558.005detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause identification and communicating the incident once it is underway; ccache theft on Linux/macOS produces observable artifacts (file reads in /tmp, klist/kinit usage, anomalous Kerberos activity) that can be surfaced by competent incident response, but the pre-compromise acquisition step itself has no affected system or evidence on the organization's estate until the ticket is used.
T1558.005prevents — A.5.26's designated competent team, containment (a), coordination (f), and explicit post-incident identification/management of the vulnerabilities/weaknesses (j) that enabled the ccache theft directly stop the technique from recurring on the same or similar vectors.
T1558.005recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability management in j, formal closure) enable recovery of the credential-theft impact by addressing the exploited weakness and restoring secure state, matching the recovers verb in the event lane (cp-9 vs T1486 and A.8.13 vs T1486 anchors) with a named remainder of immediate session-impersonation effects that may persist until tickets expire.
T1558.005responds — A.5.26's designated competent team and enumerated activities (contain affected systems, collect/analyze evidence and logs, perform forensics, close/record the incident, identify root cause and manage related weaknesses) directly engage an in-progress or just-completed credential-theft event on Linux/macOS systems where ccache files were accessed or exfiltrated.
T1559detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause identification) can surface IPC abuse once it has produced observable artifacts on the organization's estate, but the technique's pre-compromise local execution (via sockets, pipes, COM, DDE) often leaves no incident for the designated team to respond to at all.
T1559prevents — A.5.26's designated competent team and explicit steps (a) contain spread, (c) escalate/invoke continuity, (f) coordinate externally, and (j) identify/manage the vulnerabilities/weaknesses that enabled the IPC abuse all act to stop the technique from completing its full intended effect once underway, with a bounded remainder in the window before response begins.
T1559responds — A.5.26 requires a designated competent team to respond to incidents (once underway) via containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis and vulnerability management — which directly matches the act of responding to an in-flight T1559 abuse of IPC for local code/command execution, with the named remainder being any pre-containment impact already realized.
T1559.001detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause identification and communicating details once an incident is underway, which can surface COM-based local code execution when it produces observable effects on the organization's estate; however, the technique can be used silently for privilege escalation or persistence with no incident triggered, and pre-compromise or non-escalating uses fall outside response scope.
T1559.001prevents — A.5.26 requires a designated competent team and explicit procedures that contain spreading incidents (including those abusing COM for local execution), collect evidence, escalate, log, communicate, coordinate externally, close formally, perform forensics/root-cause analysis, and explicitly identify/manage the vulnerabilities/weaknesses that enabled the incident — which directly stops the technique from continuing or recurring in most cases once underway.
T1559.001responds — A.5.26 explicitly requires a designated competent team to respond to incidents (once underway) via containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis, and vulnerability/weakness management — all of which directly address an in-flight T1559.001 COM abuse event per the event-lane definition of responds.
T1559.002detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause investigation and communicating details once an incident is underway; DDE command execution on a compromised Windows host produces observable artifacts (process creation, Office child processes, registry activity) that can be surfaced in an incident, but the control's scope is limited to post-occurrence response on the organization's estate and does not mandate proactive detection mechanisms.
T1559.002prevents — A.5.26's designated competent team, containment (a), escalation/crisis invocation (c), coordination (f), and post-incident root-cause/vulnerability management (i,j) directly stop the DDE technique from completing or recurring once an incident is recognized, with the named remainder being the pre-detection delivery (e.g. via phishing/CSV) that lives in other controls.
T1559.002responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, escalate, close, and perform post-incident/root-cause analysis on an already-underway incident, which directly matches the `responds` verb once T1559.002 execution has begun.
T1559.003detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause identification and communicating details once an incident is underway, which can surface XPC service abuse on the organization's macOS estate; however, the technique occurs locally inside processes with no guaranteed observable artifact at the organization's chosen monitoring scope, leaving a large slice unseen.
T1559.003prevents — A.5.26's designated competent team and procedures for containing spread, coordinating with parties, managing related vulnerabilities/weaknesses, and post-incident root-cause work (including those that failed to prevent) stop the XPC abuse technique from recurring or succeeding at scale once known, though initial exploitation can still occur before response is triggered.
T1559.003responds — A.5.26's response activities (contain, eradicate via j, forensics, root-cause, close) engage once an XPC-abuse incident is underway on the estate, but several core steps (a,c,h) have limited or conditional applicability to this local macOS privilege-escalation technique.
T1560detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause, vulnerability management) can surface the archive artifact or anomalous compression/encryption behavior once it has occurred on the organization's estate, but the technique itself executes pre-exfiltration with no guaranteed observable event on monitored systems and many steps fall outside response scope.
T1560prevents — A.5.26's designated competent team responding to an incident (including containment, evidence collection, escalation, coordination, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that enabled it) stops the adversary from completing the T1560 technique on collected data that has not yet been exfiltrated.
T1560recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability management in j, forensic analysis, and formal closure) enable recovery actions that remove or neutralize the adversary's collected/archived artifacts after the technique has run.
T1560responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, analyze root cause, and close an information security incident once it is underway, which directly matches the act of responding to an adversary's T1560 data-archiving step during exfiltration preparation.
T1560.001detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause review) can surface the use of archiving utilities when the incident is already underway and reported, but the clause's scope is limited to declared incidents rather than continuous monitoring of process execution or file activity that would catch the technique in most cases.
T1560.001prevents — Incident response procedures that include containment (a), coordination (f), and vulnerability/weakness management (j) stop the adversary from completing the packaging step in most cases once collection has begun, preventing the exfiltration-prep technique from succeeding; the named remainder is preemptive blocking of all such utilities before any incident starts.
T1560.001recovers — A.5.26 response procedures (containment, evidence, escalation, logging, communication, forensics, post-incident analysis, root-cause fixes) act on the incident once underway but do not restore any state destroyed by the prior data collection and archiving step itself
T1560.001responds — A.5.26 requires a designated competent team to respond to incidents (including containment, evidence collection, logging, coordination, forensic analysis, root-cause review and vulnerability/weakness remediation), which directly addresses an already-underway T1560.001 execution during exfiltration preparation; the named remainder is impact already realized before containment (addressed by recovers controls).
T1560.002recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability management in j, formal closure) enable recovery actions that restore from the data-archiving technique's effects once addressed, matching the event-lane recovers anchor for the related T1486 ransomware impact.
T1560.003detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause, communicating) can surface the custom-archived artifact once it is present on the organization's estate, but the technique itself occurs in adversary-controlled collection space before any organizational boundary is crossed and many instances leave no observable event inside the incident-response scope
T1560.003prevents — A.5.26's designated competent team following defined procedures (including containment, evidence handling, escalation, forensic analysis, root-cause identification, and explicit management of vulnerabilities/weaknesses that contributed to or failed to prevent the incident) stops the custom archival technique from completing its purpose when the incident is detected in flight.
T1560.003recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability management in j, forensic analysis, and formal closure) enable recovery actions that restore from the data-archival technique's effects once the incident is contained.
T1560.003responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, analyze root cause, and close an information security incident once underway, which directly matches the act of responding to an adversary's custom archival of collected data prior to exfiltration.
T1561detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause identification and communicating the incident once it occurs, which surfaces disk-wipe activity that has reached the organization's estate; partial because pre-compromise propagation, network-device CLI wipes outside monitored scope, and purely destructive events with no surviving evidence fall outside what the incident-response team can observe.
T1561prevents — A.5.26's designated competent team following defined procedures (including containment, escalation, coordination, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that caused/contributed/failed to prevent the incident) stops the worm-like propagation and further disk-wipe executions across the network, which is what `prevents` asserts for this technique; the initial local execution on already-compromised systems remains a named remainder.
T1561recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability management, formal closure, and coordination with continuity plans) enable recovery of affected systems after the wipe has occurred, matching the recovers verb; mostly because the control itself does not perform the actual data/system restoration (that lives in A.8.13).
T1561responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, close, and post-analyze an incident once underway, which matches the `responds` verb for a disk-wipe event that has already begun.
T1561.001detects — A.5.26's monitoring, logging (d), evidence collection (b), forensic analysis (h) and post-incident root-cause steps (i) can surface disk-wipe activity once it has begun on the organization's estate, but the technique's pre-compromise acquisition of raw-disk drivers or propagation via valid accounts/SMB shares occurs outside the organization's observable boundary and is unseen by incident response procedures.
T1561.001prevents — A.5.26's designated competent team following defined procedures for containment (a), escalation/crisis invocation of continuity plans (c), coordination (f), and post-incident root-cause/vulnerability management (i,j) directly stops the worm-like propagation and further disk-wipe spread that defines T1561.001's network-wide availability goal; the technique that already ran on initial hosts is the bounded remainder addressed by recovers (A.8.13).
T1561.001recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability management, formal closure) plus explicit invocation of business continuity plans enable recovery of wiped systems and data once the incident is contained, matching the event-lane anchor for A.5.26 vs T1486.
T1561.001responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, close, and post-analyze an incident once underway, which matches the `responds` verb against a disk-wipe technique that has already executed.
T1561.002detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause identification and communicating the incident once it occurs, which surfaces knowledge of a realized disk-structure wipe; however the technique executes pre-compromise on external or non-monitored infrastructure in many cases (e.g. worm-like propagation or network-device reformatting), leaving a large slice unseen.
T1561.002prevents — A.5.26's designated competent team, containment (a), escalation/crisis invocation of continuity plans (c), coordination (f), and post-incident root-cause/vulnerability management (i,j) directly stop the worm-like propagation that maximizes T1561.002's network-scale impact, though the initial local wipe on a single already-compromised host remains possible.
T1561.002recovers — A.5.26 requires post-incident activities that include invoking business continuity plans, performing root-cause analysis, identifying and managing the vulnerabilities/weaknesses that enabled the incident, and formally closing it, which together enable recovery from the availability loss caused by T1561.002 (with the named remainder being that actual data restoration lives in separate backup controls such as A.8.13).
T1561.002responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, close, and perform post-incident/root-cause analysis on an information security incident once underway, which directly matches the act of responding to a T1561.002 Disk Structure Wipe that has already executed and impacted availability.
T1563detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause identification and communicating details of an already-underway incident, all of which surface knowledge of a session-hijacking event that reaches the organization's estate; it does not detect pre-compromise acquisition of the session.
T1563prevents — A.5.26's designated competent team, containment (a), coordination (f), and post-incident root-cause/vulnerability management (i,j) directly stop the hijacking technique from completing or recurring once detected, with the named remainder being the initial undetected hijack before response begins.
T1563responds — A.5.26 explicitly requires a competent team to respond to incidents once underway via containment (a), evidence collection (b), escalation (c), logging (d), communication (e), coordination (f), closure (g), forensics (h), root-cause analysis (i), and vulnerability management (j), which matches the `responds` verb for an in-flight session-hijacking technique; the named remainder is impact already realized before containment.
T1563.001detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause identification and communicating details once an incident is underway, which can surface SSH session hijacking on the organization's estate; however, the pre-compromise acquisition of access (e.g. via agent/socket compromise on Linux/macOS) and many lateral movements occur without triggering organizational response triggers, leaving a large slice unseen.
T1563.001prevents — A.5.26's designated competent team, containment (a), coordination (f), and post-incident root-cause/vulnerability management (i,j) directly stop the SSH agent/socket compromise technique from completing lateral movement once an incident is declared, with a bounded remainder for undetected pre-response hijacks.
T1563.001responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, analyze root cause, and close an information security incident once underway, which directly matches the act of responding to an in-progress SSH hijacking technique.
T1563.002detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause identification) surface the hijacking once it has produced observable effects on the organization's estate, but the pre-compromise technique (stealing a session via tscon.exe) can occur without triggering any of those activities if it stays within an already-authenticated RDP session that never crosses monitored boundaries or generates anomalies.
T1563.002prevents — A.5.26's designated competent team following defined procedures for containment, coordination, escalation, and vulnerability/weakness management (including failed controls) stops the RDP hijacking technique from completing its lateral movement and privilege-escalation goals once underway, with a bounded remainder of techniques that evade detection or response entirely.
T1563.002responds — A.5.26 explicitly requires a competent team to contain (a), log (d), communicate (e), coordinate (f), close (g), forensically analyze (h), perform root-cause analysis (i), and manage related vulnerabilities/weaknesses (j) once an incident is underway, which directly matches the act of responding to an in-progress RDP hijacking technique.
T1564detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause identification and post-incident review, all of which can surface hidden artifacts once the incident is known; however the control's scope is strictly post-detection response on the organization's estate and cannot observe pre-compromise hiding techniques (e.g. isolated virtualization regions or stealthy file attributes) that leave no triggered incident.
T1564prevents — A.5.26's designated competent team responding to an incident (with containment, evidence collection, escalation, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that allowed it) stops the adversary's ongoing hiding of artifacts from continuing or succeeding further, which is what `prevents` asserts for a technique already in flight; the named remainder is that it does not stop the initial act of hiding before detection/response begins.
T1564recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability/weakness management in j, formal closure) act after the hiding technique has run and its artifacts exist, enabling recovery of visibility and control by addressing the evasion's effects.
T1564responds — A.5.26 requires a competent team to respond to incidents once underway via containment, eradication, evidence collection, logging, escalation, and post-incident root-cause/vulnerability analysis, which directly addresses an in-progress T1564 hiding of artifacts (e.g., containing spread, forensic analysis to uncover hidden items, and fixing related weaknesses).
T1564.001detects — A.5.26 requires a designated competent team to respond to incidents (including detection via reported anomalies or indicators), with explicit steps for evidence collection, logging, forensic analysis, and post-incident root-cause identification that surface the hidden-file technique once it is used in an incident.
T1564.001prevents — A.5.26's designated competent team responding to an incident (including containment, evidence collection, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that enabled it) stops the adversary's ongoing use of hidden files/directories from continuing to evade detection or achieve further impact.
T1564.001recovers — A.5.26 response procedures (containment, evidence, escalation, logging, communication, forensics, post-incident analysis, root-cause handling) act on an already-underway incident but do not restore any system state destroyed or altered by the T1564.001 hiding technique itself
T1564.001responds — A.5.26 requires a designated competent team to respond to incidents (containment, eradication, evidence collection, forensic analysis, root-cause identification, and vulnerability/weakness management once the incident is underway), which directly addresses an in-progress T1564.001 use that has already hidden artifacts to evade detection.
T1564.002detects — A.5.26 requires a designated competent team to respond to incidents (including detection, containment, evidence collection, logging, forensic analysis, and post-incident root-cause identification), which surfaces hidden-user techniques once they trigger an observable incident; partial because the control's scope is limited to declared incidents rather than continuous proactive detection of stealthy account hiding.
T1564.002prevents — A.5.26's designated competent team responding to an incident (including containment, evidence collection, root-cause analysis, and explicit identification/management of the vulnerabilities/weaknesses that enabled it) stops the hidden-user technique from continuing or recurring on affected systems, though it does not stop the initial creation of a hidden user before detection occurs.
T1564.003detects — A.5.26 requires a designated competent team to respond to incidents (including detection via reported anomalies or logs per its procedures and subpoints d/h/i), which surfaces hidden-window techniques once they produce observable incident indicators, but the control's scope is post-incident response rather than proactive or comprehensive detection of stealthy concealment methods.
T1564.003prevents — incident response procedures that contain affected systems, collect evidence, escalate, communicate, coordinate, close incidents, perform forensics, analyze root causes, and manage related vulnerabilities can interrupt or block ongoing hidden-window concealment during active incidents, but do not stop the technique from being initially executed or prevent its use in non-incident scenarios
T1564.004detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause identification and managing the weaknesses the incident exposed; an NTFS ADS hiding technique on a monitored Windows estate produces observable artifacts (unusual streams, MFT anomalies, process-file interactions) that can be surfaced during those steps once the incident is underway.
T1564.004recovers — post-incident analysis, root-cause identification, vulnerability management, and formal closure (including forensic evidence handling) enable recovery actions that restore a clean state after the NTFS hiding technique has already run
T1564.004responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, analyze root cause, and close an information security incident once underway, which directly matches the `responds` verb against an adversary technique already in execution.
T1564.005detects — A.5.26 requires a designated competent team to respond to incidents (including detection via reported anomalies, evidence collection, forensic analysis, and post-incident root-cause identification), which surfaces hidden file system usage once it is treated as an incident.
T1564.005recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability/weakness management in j, forensic analysis, formal closure) enable recovery of the affected environment from the hidden file system technique once it has run, with the named remainder being any data or state destroyed before containment that is outside the incident-response scope.
T1564.005responds — A.5.26 requires a designated competent team to respond to incidents (once underway) via containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis, and vulnerability/weakness management — all of which directly address a hidden file system technique that has already executed to conceal malicious components.
T1564.006detects — A.5.26 requires a designated competent team to respond to incidents (including detection via reported anomalies or logs per its procedures), which surfaces some uses of hidden virtual instances once they trigger observable effects, but does not mandate or perform monitoring of virtualization activity itself.
T1564.006prevents — A.5.26's designated competent team responding to an incident (containing spread, evidence collection, escalation, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that enabled it) stops the T1564.006 technique from continuing or recurring on the affected systems.
T1564.006recovers — A.5.26 is strictly an incident-response procedure (containment, evidence, escalation, logging, communication, post-incident root-cause analysis); it contains no backup, restoration, or state-recovery actions that would recover from artifacts hidden inside a virtual instance.
T1564.006responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment (a), evidence collection (b), logging (d), escalation (c), communication/coordination (e/f), forensic analysis (h), root-cause review (i), and vulnerability/weakness remediation (j), which matches the `responds` verb against an in-flight T1564.006 technique; the named remainder is impact already realized before containment (e.g., hidden artifacts or executed payload).
T1564.007prevents — A.5.26's designated competent incident-response team, once an incident is recognized, contains affected systems (a), coordinates with internal parties to minimize consequences (f), and explicitly identifies/manages the underlying vulnerabilities/weaknesses that caused/contributed/failed to prevent the incident (j) — directly stopping VBA-stomping techniques from continuing or recurring in the environment.
T1564.008detects — A.5.26 requires a designated competent team to respond to incidents (including detection via reported alerts or anomalies) and mandates logging, evidence collection, forensic analysis, and post-incident root-cause work that can surface the use of hiding rules impairing visibility of security alerts or C2; this is a genuine but minority slice of the technique's full scope (e.g., local client rules or org-wide transport rules evading initial notice).
T1564.008prevents — A.5.26's designated competent team responding to incidents (including containment, evidence collection, escalation, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that allowed the incident) directly stops the T1564.008 technique from continuing to hide or delete further security-alert/C2/incident-notification emails once the compromise that enabled rule creation is known and acted upon.
T1564.008recovers — A.5.26's post-incident analysis, root-cause documentation, vulnerability/weakness management (including failed controls), and formal closure directly enable recovery of detection capability after the hiding technique has already run and impaired visibility of alerts/C2/internal phish.
T1564.008responds — A.5.26 explicitly requires a designated competent team to contain, escalate, communicate, coordinate, log, forensically analyze, close, and post-analyze an information security incident once underway, directly addressing the T1564.008 technique that has already run to hide alerts/C2/internal-spearphishing mail; the named remainder is that the already-deleted or moved emails are not restored by response alone.
T1564.009detects — A.5.26 requires a designated competent team to respond to incidents (including detection via reported anomalies or indicators), but its scope is limited to post-occurrence response procedures rather than proactive or broad detection of the resource-fork hiding technique itself.
T1564.009prevents — A.5.26's designated competent team and explicit steps (a) contain spread, (b/c) collect/escalate evidence, (f) coordinate externally, and (j) identify/manage the exact vulnerabilities/weaknesses that enabled the forking technique, stopping it from recurring on the affected and peer systems.
T1564.009recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability/weakness management in j, formal closure) enable recovery of organizational state and prevention of recurrence after the resource-fork hiding technique has already run, matching the recovers verb in the event lane.
T1564.009responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment (a), evidence collection (b), logging (d), escalation (c), communication (e), coordination (f), forensic analysis (h), root-cause post-incident review (i), and vulnerability/weakness remediation (j), all of which directly address a resource-fork hiding technique that has already executed on macOS.
T1564.010detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause identification and post-incident review, all of which can surface the PEB overwrite once it has occurred and is observable in process memory or logs; however the technique executes entirely in-process on the local Windows host with no guaranteed network, boundary or external artifact, so detection depends on whether the organization's incident-response instrumentation (telemetry feeding the response team) actually captures process-memory anomalies, leaving a large slice of implementations that see nothing.
T1564.010prevents — A.5.26's designated competent team following defined procedures for containment (a), evidence collection, escalation, forensic analysis (h), root-cause identification (i), and explicit management of vulnerabilities/weaknesses that failed to prevent the incident (j) stops the argument-spoofing technique from completing its evasion goal in most cases once it is underway.
T1564.010responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, analyze root cause, and formally close an information security incident once underway, which directly matches the act of responding to T1564.010 after it has executed to evade detection.
T1564.011detects — A.5.26's response activities (evidence collection, logging, forensic analysis, post-incident root cause) can surface the use of nohup/-ErrorAction/etc. once an incident is already underway on the organization's estate, but the technique itself occurs in adversary-controlled process execution with no guaranteed observable artifact on monitored systems.
T1564.011prevents — A.5.26's designated competent team responding to incidents (with containment, eradication, root-cause analysis, and vulnerability/weakness management) stops the ignore-process-interrupts technique from continuing to run or succeeding once it is recognized as part of an incident, though it does not stop the initial execution of nohup/silentlyContinue-style commands before detection.
T1564.011responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, analyze root cause, and formally close an information security incident once underway, which directly matches the act of responding to an in-flight T1564.011 technique that has already executed to evade termination signals.
T1564.012detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause, vulnerability management) can surface the presence of an excluded artifact once an incident is already known or under investigation, but the technique itself occurs pre-compromise on the adversary's drop and has no guaranteed observable event on the organization's estate that the procedure is required to monitor.
T1564.012prevents — A.5.26's designated competent team responding to an incident (including containment, evidence collection, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that allowed it) stops the adversary technique from continuing to succeed once it has been surfaced, which is what `prevents` asserts in the event-lane anchors; the named remainder is that the initial drop into a pre-existing exclusion is not stopped before it occurs.
T1564.012recovers — A.5.26 response procedures (containment, evidence, escalation, logging, communication, forensics, post-incident analysis, root-cause handling) act on the incident once underway but do not restore any state destroyed by the T1564.012 technique of dropping payloads into AV-excluded paths.
T1564.012responds — A.5.26 requires a designated competent team to respond to incidents (containment, eradication, root-cause analysis, vulnerability management) once underway; this bounds the impact of T1564.012 artifacts already present and hidden via exclusions, with the named remainder being pre-containment effects already realized (addressed by recovers controls).
T1564.013detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause identification and post-incident review, all of which can surface the anomalous bind-mount behavior once it is present in monitored logs, process tables or forensic artifacts on the organization's estate; it is partial because the technique is pre-compromise, occurs on Linux hosts that may lie outside routine monitoring scope, and many of the ten listed activities (containment, escalation, crisis invocation, communication) have no object to act on until downstream effects appear.
T1564.013prevents — A.5.26's designated competent team and documented procedures for containing spreading incidents, forensic analysis, root-cause identification, and explicit management of vulnerabilities/weaknesses that failed to prevent the incident directly stop the bind-mount hiding technique from completing or recurring once detected.
T1564.013recovers — A.5.26's post-incident analysis, root-cause identification, vulnerability/weakness management (item j), and formal closure directly restore the organization's ability to detect and respond to the hidden process after the bind-mount technique has run, addressing the realized impact on visibility and controls.
T1564.013responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, analyze root cause/vulnerabilities/weaknesses, and formally close an incident once underway, which directly matches the act of responding to a T1564.013 bind-mount hiding technique that has already executed.
T1564.014detects — A.5.26 explicitly requires collecting evidence, logging all response activities, conducting forensic analysis as required, and performing post-incident analysis to identify root cause — all of which surface the xattr abuse technique once it has run.
T1564.014prevents — A.5.26's designated competent team responding to an incident (containing spread, forensic analysis, root-cause identification, and explicitly managing the vulnerabilities/weaknesses that allowed the incident) stops the xattr-hiding technique from continuing or recurring on affected systems, though it does not stop the initial abuse before detection occurs.
T1564.014recovers — A.5.26's post-incident analysis, root-cause documentation, vulnerability/weakness management (item j), and formal closure directly restore the organization's security posture after the xattr-hiding technique has run and been contained.
T1564.014responds — A.5.26's designated team and enumerated activities (contain spread, collect/analyze evidence, log, communicate, coordinate, close/record, forensics, root-cause, manage related weaknesses) directly engage an in-progress or realized T1564.014 event on the organization's estate, performing the core containment/eradication/follow-up that `responds` names; the named remainder is pre-compromise discovery-only uses of xattrs that never trigger an incident.
T1565detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause identification and post-incident review, all of which can surface data-manipulation artifacts once they have occurred and are known to the organization; partial because the clause's scope is limited to incidents already declared or escalated to the response team, leaving pre-escalation or undetected manipulation outside its mechanism.
T1565prevents — A.5.26 requires a designated competent team to respond to incidents once underway (containment, eradication, root-cause analysis, vulnerability/weakness remediation), which stops the adversary's ongoing data manipulation technique from continuing or succeeding further — the technique runs but does not achieve its full intended impact, which is what `prevents` asserts in the event-lane anchors.
T1565recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability management in j, formal closure) enable recovery of integrity after T1565 manipulation has occurred, with the named remainder being direct data restoration itself (which lives in backup/recovery controls).
T1565responds — A.5.26 requires a designated competent team to respond to incidents (including containment, eradication, evidence collection, logging, escalation, and post-incident root-cause/vulnerability analysis per items a–j), which directly addresses an already-underway T1565 data manipulation once detected.
T1565.001detects — A.5.26's response activities (evidence collection, logging, forensic analysis, post-incident root cause) surface the manipulation after it has occurred on the organization's estate, but pre-compromise acquisition and many offline/external manipulations leave no observable event for the incident response team.
T1565.001prevents — A.5.26's designated competent team, containment (a), forensic/root-cause analysis (h/i), vulnerability/weakness management (j), and coordination explicitly stop the adversary technique from completing its manipulation or from achieving repeated/sustained success on the same target.
T1565.001recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability management, formal closure, and coordination) enable recovery of organizational state and decision-making integrity after stored-data manipulation has occurred, with a named remainder around direct data restoration itself (handled by separate backup controls).
T1565.001responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, analyze root cause, close, and manage related vulnerabilities once an incident is underway, which directly matches the act of responding to a T1565.001 data-manipulation event that has already occurred.
T1565.002detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause identification) can surface transmitted-data manipulation once it has produced observable effects on the organization's estate, but the technique's core act (intercept-and-alter in transit) often leaves no local artifact until downstream impact appears and many pre-impact or external-link manipulations stay outside the incident-response vantage.
T1565.002prevents — A.5.26's designated competent team, containment (a), coordination (f), and explicit post-incident identification/management of the vulnerabilities/weaknesses that enabled the incident (j) stop transmitted-data manipulation from recurring once the first instance has been responded to.
T1565.002recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability management in j, formal closure) enable recovery of organizational state and decision-making integrity after transmitted-data manipulation has already occurred, with the named remainder being direct restoration of the altered data itself (addressed by backups or other controls).
T1565.002responds — A.5.26 explicitly requires a designated competent team to respond to incidents (once underway) via containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis and vulnerability/weakness remediation — all of which directly address an in-flight or realized T1565.002 data-manipulation incident.
T1565.003detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause identification and post-incident review, all of which can surface runtime data manipulation once it has produced observable effects or anomalies on the organization's estate; however the technique can be performed silently on non-monitored binaries or during information-gathering phases with no incident triggered, so only a slice is detected.
T1565.003prevents — A.5.26's designated competent team, containment (a), coordination (f), and explicit post-incident identification/management of the vulnerabilities/weaknesses (j) that enabled the runtime manipulation directly stop the technique from recurring or succeeding on subsequent attempts.
T1565.003recovers — A.5.26's post-incident analysis, root-cause identification, vulnerability management (j), forensic work, and formal closure directly support restoring organizational understanding/decision-making integrity after runtime data manipulation has occurred.
T1565.003responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment (a), evidence collection (b), escalation (c), logging (d), communication (e), coordination (f), closure (g), forensics (h), root-cause analysis (i), and vulnerability remediation (j), which matches the `responds` verb for an integrity-impacting runtime manipulation technique that has already executed.
T1566detects — A.5.26 requires a designated team to respond to incidents (including detection/escalation steps and post-incident root-cause analysis that surfaces the phishing vector), but the clause itself does not mandate or perform proactive detection of the phishing technique before or during delivery.
T1566prevents — A.5.26's designated competent team and explicit procedures for containing spread (a), coordinating to minimize consequences (f), and managing vulnerabilities/weaknesses that failed to prevent the incident (j) stop most phishing deliveries from achieving initial access or further impact once the first instance is underway, though the technique can still succeed against unaware recipients before any response triggers.
T1566responds — A.5.26 explicitly requires a designated competent team to respond to information security incidents (including containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis, and vulnerability management once the incident is underway), which directly matches the act of responding to a realized phishing incident per the event-lane definition.
T1566.001detects — A.5.26's response activities include collecting evidence, logging, communicating, coordinating, closing/recording, root-cause analysis and managing weaknesses once an incident is underway; a spearphishing attachment that reaches and is acted on by a user creates detectable artifacts and evidence on the estate, but the pre-compromise delivery step itself (email sent by external adversary) has no affected system or evidence for the response team to act on until after delivery succeeds.
T1566.001prevents — A.5.26 requires a designated competent team and explicit procedures that include containing spread (a), evidence collection, escalation, logging, communication, coordination, forensic analysis, root-cause identification, and explicitly identifying/managing the vulnerabilities/weaknesses that caused/contributed/failed to prevent the incident — directly stopping the T1566.001 technique from completing its access goal in the great majority of cases once the incident is recognized.
T1566.001responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis and vulnerability management — all of which directly address a realized spearphishing-attachment incident (T1566.001) with the named remainder that pre-delivery social-engineering elements are outside the incident-response boundary.
T1566.002detects — A.5.26's response activities include collecting evidence, logging, communicating, coordinating, closing/recording, root-cause analysis and managing weaknesses once an incident is underway; a spearphishing-link email that reaches a user and is clicked creates detectable artifacts on the recipient's estate (e.g. anomalous link clicks, email logs, browser events) that engage several of those steps, but the pre-delivery reconnaissance, crafting and external sending of the email occur outside organizational monitoring scope and produce no internal event until delivery or execution.
T1566.002prevents — A.5.26 requires a designated competent team and explicit procedures that contain affected systems, collect evidence, escalate, communicate, coordinate externally, close the incident, perform forensics/root-cause analysis, and explicitly identify/manage the vulnerabilities/weaknesses (including failed controls) that enabled the incident — directly stopping the T1566.002 technique from completing or recurring.
T1566.002responds — A.5.26 explicitly requires a designated competent team to respond to incidents (including containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis, and vulnerability management once the spearphishing link has been delivered and executed), matching the `responds` verb for an event already underway.
T1566.003detects — A.5.26's response activities include collecting evidence, logging, communicating, coordinating, root-cause analysis and identifying weaknesses once an incident is underway; a spearphishing-via-service delivery that reaches an organizational user or endpoint produces observable artifacts (e.g. anomalous messages, clicked links, executed payloads) that can be surfaced by the designated response team, but pre-compromise reconnaissance, fake-account creation and delivery entirely on third-party services lie outside the organization's estate and produce no event for the procedure to act on.
T1566.003prevents — A.5.26's designated competent team following defined procedures for containment, evidence collection, escalation, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that allowed the incident directly stops the T1566.003 technique from completing its access objective once the social-engineering delivery has begun, with the bounded remainder being pre-delivery account-creation and rapport-building steps that sit outside incident response.
T1566.003responds — A.5.26 explicitly requires a competent team to contain (if spreading), eradicate, log, escalate, communicate, coordinate externally, close, forensically analyze, and post-analyze an information security incident once underway, which matches the definition of responds against an executed T1566.003 phishing event; the named remainder is that the initial social-engineering rapport-building and message delivery phase has already succeeded before response begins.
T1566.004detects — A.5.26's response activities include collecting evidence, logging, communicating, coordinating, root-cause analysis and identifying weaknesses once an incident is underway; vishing can produce observable artifacts (e.g. reported calls, anomalous MFA prompts, or user-reported voice contact) that trigger those activities on the victim's estate, but the technique's pre-compromise delivery (adversary calling the user) has no system event for the organization to instrument or observe until after the user has already been reached.
T1566.004prevents — A.5.26 requires designated competent response (incl. containment, evidence collection, escalation, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that caused/contributed/failed to prevent the incident), which directly stops the social-engineering chain from completing into system access when the vishing call is recognized and handled before the user executes the directed action.
T1566.004responds — A.5.26 explicitly requires a designated competent team to respond to incidents (including containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis, and vulnerability management), which directly matches the act of responding once a T1566.004 voice-phishing incident is already underway.
T1567detects — A.5.26's response activities (evidence collection, logging, communication, coordination, root-cause analysis, forensic analysis) can surface the exfiltration event once underway on the organization's estate, but the technique's use of legitimate SSL/TLS web services (with pre-existing firewall rules and high cover) means much of it occurs outside monitored scope or blends with normal traffic, leaving a large slice undetected.
T1567prevents — A.5.26's designated competent team responding to an incident (containing spread, coordinating with external parties, identifying/managing vulnerabilities that enabled it) stops the exfiltration technique from continuing or recurring, though the initial data loss before response begins is a named remainder
T1567responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis and vulnerability management — all of which directly address an exfiltration event that has already begun.
T1567.001detects — A.5.26's response activities (evidence collection, logging, communication, coordination, root-cause analysis, forensic analysis) can surface the exfiltration event once it has occurred on the organization's estate, but the technique's use of legitimate HTTPS APIs to popular external services (often already allowed) leaves a large slice of stealthy or low-and-slow cases outside routine incident detection scope
T1567.001prevents — A.5.26's incident response procedures (containment, escalation, coordination with external parties, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that enabled the incident) act to stop the exfiltration technique from continuing or recurring once it has begun, which satisfies `prevents` with a named remainder of pre-detection exfiltration volume.
T1567.001responds — A.5.26 explicitly requires a designated competent team to respond to incidents (once underway) via containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis and vulnerability/weakness management — all of which directly address an exfiltration event that has already begun.
T1567.002detects — A.5.26's response activities (evidence collection, logging, communication, coordination, root-cause analysis, forensic analysis) can surface the exfiltration event once it has occurred on the organization's estate, but the technique's outbound nature to a commonly-allowed cloud service (Dropbox/Google) and pre-compromise acquisition of the storage target leave a large slice unseen by incident response.
T1567.002prevents — A.5.26's designated competent team, containment (a), coordination (f), and vulnerability/weakness management (j) directly stop the exfiltration technique from completing or recurring when the incident is detected in flight or shortly after initiation.
T1567.002responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment (a), evidence collection (b), escalation (c), logging (d), communication (e), coordination (f), closure (g), forensics (h), root-cause analysis (i), and vulnerability management (j), all of which directly address an exfiltration incident that has already begun.
T1567.003detects — A.5.26's response activities include collecting evidence, logging, communicating, coordinating, closing/recording, root-cause analysis and managing weaknesses once an incident is underway; an exfiltration to a text storage site that reaches the organization's estate (e.g., observable outbound traffic, logs or anomalies) can therefore be detected and responded to, but the technique can also complete entirely outside monitored scope (e.g., from a compromised external asset or via encrypted paid features), so only a slice is covered.
T1567.003prevents — A.5.26's incident-response procedures (containment of spreading consequences, coordination with external parties, vulnerability/weakness management post-incident) can stop the exfiltration technique from completing or recurring when the incident is detected in flight or shortly after, though this is not a preventive barrier before the technique begins and leaves a remainder when the exfil is one-shot and completes before response triggers.
T1567.003responds — A.5.26 requires a competent team to respond to incidents once underway via containment, eradication, escalation, logging, communication, coordination, closure, forensics, root-cause analysis, and vulnerability/weakness management — all of which directly address an exfiltration incident that has already occurred.
T1567.004detects — A.5.26's response activities include collecting evidence, logging, communicating, coordinating, closing/recording, root-cause analysis and identifying weaknesses once an incident is underway; an exfiltration-over-webhook event on the organization's estate produces observable artifacts (e.g. outbound HTTPS, SaaS API calls, anomalous webhook registrations) that can be surfaced by competent incident response, but the pre-compromise setup of an adversary-owned webhook or the exfiltration payload itself can occur entirely outside the organization's visibility on external SaaS infrastructure.
T1567.004prevents — A.5.26's designated competent team, containment (a), coordination (f), and post-incident root-cause/vulnerability management (i,j) directly stop webhook exfiltration once detected, with the named remainder being the initial outbound push that blends with normal HTTPS/SaaS traffic before response begins.
T1567.004responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment (a), evidence collection (b), escalation (c), logging (d), communication (e), coordination (f), closure (g), forensics (h), root-cause analysis (i), and vulnerability management (j), which directly matches the `responds` verb for an exfiltration technique that has already begun.
T1568detects — A.5.26's response activities include collecting evidence, logging, communicating, coordinating, closing/recording, root-cause analysis and identifying weaknesses once an incident is underway; dynamic resolution (e.g. algorithmically generated C2 domains/ports observable in network artifacts or logs) can trigger these on an affected estate, but pre-compromise acquisition and many fallback cases produce no organizational event to detect.
T1568prevents — A.5.26's designated competent team following defined procedures (including containment, coordination with external parties, vulnerability management in j, and root-cause work in i) stops the dynamic-resolution technique from successfully re-establishing or sustaining C2 once it is detected as an incident, which is what prevents asserts; the named remainder is that the initial algorithm-driven lookup can still occur before the incident is recognized.
T1568responds — A.5.26 requires a designated competent team to respond to incidents (once underway) via containment, eradication, evidence collection, logging, escalation, communication, forensic analysis, root-cause identification, and vulnerability/weakness management; this directly matches the event-lane definition of responds for a C2 technique like T1568 that has already executed to establish/evade via dynamic resolution.
T1568.001detects — A.5.26's response activities include collecting evidence, logging, communicating, coordinating, closing/recording, root-cause analysis and identifying related weaknesses; these can engage once fast-flux C2 traffic or anomalous DNS is observed on the organization's estate, but the upstream domain registration and rapid IP shuffling occur entirely outside organizational visibility on registrar infrastructure, leaving a large slice of the technique unseen.
T1568.001prevents — A.5.26's designated competent team responding to an incident (including containment, coordination with external parties, and vulnerability/weakness management) stops the fast-flux C2 channel from continuing once detected, which is what prevents asserts; the named remainder is that the technique can complete initial setup and C2 beaconing before any response is triggered.
T1568.001responds — A.5.26's response activities (containment, evidence collection, logging, communication, coordination, closure, forensics, root-cause analysis, and managing related weaknesses) engage once a Fast Flux C2 channel is detected on the organization's estate, but the core technique (external DNS fluxing of attacker-controlled IPs) has no internal system/artifact for containment or eradication, leaving most of the verb's protective half empty while administrative/follow-up steps still apply.
T1568.002prevents — incident response procedures that contain spread, collect evidence, escalate, communicate, coordinate externally, close incidents, perform forensics, analyze root causes, and manage resulting vulnerabilities can constrain or block successful DGA-based C2 fallback channels once initial detection occurs, but do not stop adversaries from generating and attempting DGA domains in the first place
T1568.003detects — A.5.26 requires monitoring for and response to anomalous security events (including incident detection via logs, evidence collection, and post-incident analysis), which can surface DNS-calculation C2 as an observed anomaly, but only where it falls inside the organization's defined scope and telemetry — not guaranteed for this specific technique.
T1568.003prevents — A.5.26's designated competent team responding to an incident (including containment, forensic analysis, root-cause identification, and vulnerability/weakness management) stops the DNS-calculation C2 channel from continuing or recurring once it has been observed, which is what `prevents` asserts for an already-deployed technique; the named remainder is that the initial outbound connection must still occur for detection/response to trigger.
T1568.003responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, analyze root cause, and close an information security incident once underway, which directly matches the act of responding to a live T1568.003 C2 channel.
T1569detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause review) can surface T1569 once the service-abuse event is already underway on the organization's estate, but many pre-compromise or non-incident instances (e.g., benign service creation) fall outside the incident-response trigger and scope.
T1569prevents — A.5.26's designated competent team responding to an incident (with containment, evidence collection, escalation, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that allowed it) stops the T1569 abuse technique from continuing or recurring on the affected systems.
T1569responds — A.5.26 requires a competent team to respond to incidents once underway (containment, eradication, evidence, escalation, closure), which directly addresses an in-progress T1569 abuse of system services; the named remainder is impact already realized before containment (e.g., executed payload effects).
T1569.001detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause identification and communicating details of an already-underway incident; on macOS these can surface launchctl abuse (e.g. anomalous launchd activity in logs or process telemetry) when it reaches the organization's estate, but the control's scope is limited to post-occurrence response and does not instrument or guarantee detection of the technique itself.
T1569.001prevents — A.5.26's designated competent team and procedures for containing spread (a), coordinating with parties (f), and managing vulnerabilities/weaknesses that failed to prevent the incident (j) stop the launchctl abuse technique from continuing or recurring on affected macOS systems.
T1569.001responds — A.5.26's ten activities (contain, evidence, escalate, log, communicate, coordinate, close, forensics, root-cause, fix weaknesses) engage once the launchctl technique has run on the victim's macOS estate; the only real remainder is that some pre-compromise reconnaissance uses of launchctl fall outside the post-incident response window.
T1569.002detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause review) can surface the service-control-manager abuse once it has produced observable artifacts on the organization's estate, but the technique's pre-compromise acquisition of sc.exe/PsExec and its remote execution surface sit outside the control's incident-response scope
T1569.002prevents — A.5.26 requires a designated competent team to respond to incidents once underway (containment, eradication, root-cause analysis, vulnerability remediation), which stops the T1569.002 execution technique from continuing or recurring; it does not stop the initial abuse of services.exe/sc.exe/PsExec.
T1569.002responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis and vulnerability management — all of which directly address an in-progress or realized T1569.002 service execution.
T1569.003detects — A.5.26 requires monitoring for and response to incidents (including logging, escalation, forensic analysis and post-incident root-cause work) that can surface the use of systemctl as part of an incident, but the clause's scope is set by the organization's defined procedures and does not mandate instrumentation that would catch every invocation on every Linux host.
T1569.003prevents — A.5.26's designated competent team and procedures for containing spread, coordinating with parties, and managing vulnerabilities/weaknesses that failed to prevent the incident constrain the post-exploitation abuse of systemctl (a technique that runs only after initial access), preventing full technique success in most cases per the event-lane anchor for A.5.26 vs T1486.
T1569.003responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment, escalation, evidence collection, logging, communication, coordination, forensic analysis, root-cause identification, and post-incident vulnerability management, which directly addresses an in-progress T1569.003 abuse of systemctl (e.g., containing spread via service manipulation and eradicating the actor's foothold).
T1570detects — A.5.26's response activities (evidence collection, logging, forensic analysis, post-incident root cause) can surface lateral tool transfer once it has occurred on the organization's estate, but pre-compromise acquisition/transfer steps and many internal lateral movements leave no required object for response actions.
T1570prevents — A.5.26's designated competent team, containment (a), coordination (f), and explicit post-incident identification/management of vulnerabilities/weaknesses (j) that enabled the incident stop the lateral-tool-transfer technique from continuing or recurring in the same environment.
T1570responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment (a), evidence collection (b), logging (d), coordination (f), forensic analysis (h), root-cause review (i), and vulnerability/weakness remediation (j), which directly matches the post-compromise lateral-tool-transfer technique in an active incident.
T1571detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause identification and communicating details once an incident is underway; non-standard port usage is observable in network telemetry or logs that would surface during an actual incident response, but the clause itself does not mandate any monitoring or detection instrumentation and many pre-incident or stealthy uses of T1571 would never reach the response team.
T1571prevents — A.5.26's incident response procedures (containment, evidence collection, logging, coordination, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that allowed the incident) directly stop the non-standard port technique from continuing or recurring once it has begun, with the bounded remainder being pre-incident prevention of the initial configuration change itself.
T1571responds — A.5.26's response activities (containment, evidence collection, logging, communication, coordination, closure, forensics, root-cause analysis, and vulnerability management) engage once a non-standard port C2 channel is detected on the estate, but several core response steps (a, c, h) have limited or empty objects against this stealth technique that avoids triggering boundary or anomaly controls in the first place.
T1572detects — A.5.26's response activities include collecting evidence, logging, forensic analysis and post-incident root-cause work that can surface protocol tunneling once it has produced observable artifacts on the organization's estate; this is genuine detection but only a slice, as the technique can be entirely pre-compromise, external, or encrypted in ways that leave no internal evidence for the incident team to collect or analyze.
T1572prevents — A.5.26's designated competent team and explicit procedures for containing spread (a), coordinating to minimize consequences (f), and addressing the incident (including forensic/root-cause work that surfaces tunneling) stop the technique from continuing or succeeding once detected, which is what `prevents` asserts for an in-flight technique; the named remainder is that it cannot stop the initial setup or first packets before response begins.
T1572responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, analyze root cause, and close an information security incident once underway, which directly matches the act of responding to T1572 tunneling that has already begun.
T1573.001prevents — A.5.26's designated competent incident-response team, with its explicit steps to contain spread (a), coordinate externally (f), identify/manage vulnerabilities/weaknesses that failed to prevent the incident (j), and perform root-cause analysis (i), directly stops the symmetric-crypto C2 channel from continuing once it is recognized as an active incident.
T1574detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause identification and communicating details of an already-underway incident, which surfaces knowledge of hijack-execution-flow techniques when they produce observable artifacts on the organization's estate; this is genuine but partial because pre-compromise or non-escalating hijacks (e.g. purely in-memory or supply-chain) leave no incident for the team to respond to.
T1574prevents — A.5.26's designated competent team responding to an incident (containing spread, evidence collection, escalation, forensic analysis, root-cause identification, and explicitly managing the vulnerabilities/weaknesses that allowed the incident) stops the hijacked execution flow from continuing or recurring as persistence/elevation/evasion, which is what `prevents` asserts for a technique already in flight; the named remainder is that it does not stop the initial hijack before the incident is detected.
T1574recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability/weakness management in j, forensic analysis, formal closure) restore the system to a known-good state after a hijack has already succeeded, exactly as the recovers verb requires on the event lane.
T1574responds — A.5.26 requires a competent team to respond to incidents already underway via containment, eradication, evidence collection, logging, escalation, and post-incident root-cause/vulnerability fixes, which directly addresses an in-progress T1574 hijack (e.g. containing affected systems and remediating the poisoned execution path).
T1574.001detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause identification) can surface DLL sideloading/hijacking once it has produced observable artifacts on the organization's estate, but the pre-compromise technique (planting a malicious DLL) often leaves no event until execution and many instances sit outside the incident-response scope.
T1574.001prevents — A.5.26's designated competent team responding to an incident (containing spread, collecting evidence, escalation, forensic analysis, root-cause identification, and explicitly managing the vulnerabilities/weaknesses that caused/contributed/failed to prevent it) stops the T1574.001 technique from continuing or recurring on affected systems.
T1574.001recovers — A.5.26 requires designated competent response including containment, evidence handling, escalation (possibly invoking continuity plans), forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that enabled the incident — which restores control after a realized T1574.001 execution.
T1574.001responds — A.5.26 explicitly requires a designated competent team to contain spreading incidents, collect/analyze evidence (including forensics), log activities, escalate, communicate, coordinate externally, close the incident, perform root-cause analysis, and manage related vulnerabilities/weaknesses once the incident is underway.
T1574.004detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause identification and communicating details once an incident is underway, which can surface dylib hijacking when it produces observable effects on the organization's estate; however, the technique's pre-execution placement of a dylib (often outside monitored paths or before any incident is declared) and its execution masked under a legitimate process leave a large slice unseen by response procedures.
T1574.004prevents — A.5.26's designated competent team and explicit steps (a: contain spread; b/h: evidence & forensics; i: root-cause analysis; j: identify/manage the vulnerabilities/weaknesses that caused/contributed/failed to prevent) directly stop the hijacking technique from recurring once it has been observed, with the named remainder being first-time or undetected instances before any incident is declared.
T1574.004recovers — A.5.26's post-incident analysis, root-cause documentation, vulnerability/weakness management (including failed controls), and formal closure enable recovery of organizational state and prevention of recurrence after the hijacking technique has run and delivered its impact.
T1574.004responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, analyze root cause/vulnerabilities/weaknesses that enabled the incident, and formally close it once addressed — all core to responding once a dylib hijacking execution is already underway.
T1574.005detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause identification and managing the weaknesses that caused the incident, all of which surface knowledge of an in-progress or completed installer-weakness exploitation on the organization's estate; the pre-compromise acquisition of a vulnerable installer itself is outside the incident-response scope, producing a genuine but bounded remainder
T1574.005prevents — A.5.26's designated competent team response (containment of spreading consequences, forensic/root-cause analysis, vulnerability/weakness management including controls that failed to prevent) directly stops the installer-weakness technique from completing its full effect or recurring, though the initial hijacking may occur before response is triggered.
T1574.005recovers — A.5.26's post-incident analysis, root-cause identification, vulnerability/weakness management (item j), and formal closure directly restore the system to a secure state after the installer-weakness technique has already run and achieved its impact (privilege escalation/persistence).
T1574.005responds — A.5.26 explicitly requires a designated competent team to contain (a), eradicate via root-cause/vulnerability fixes (i,j), log/analyze (d,i), and coordinate (f) an incident once underway, which matches the `responds` verb against this post-exploitation technique.
T1574.006detects — A.5.26 requires a designated competent team to respond to incidents (including detection via reported anomalies or forensic analysis per clauses b/h/i), but its core focus is post-detection response rather than proactive or broad detection of the technique itself.
T1574.006prevents — A.5.26's designated competent team and procedures for containing spread (a), coordinating to minimize consequences (f), and managing vulnerabilities/weaknesses that caused/contributed/failed to prevent the incident (j) stop the hijacking technique from completing its full effect in most cases once underway, per the event-lane anchor definition of prevents.
T1574.006recovers — A.5.26's post-incident analysis, root-cause documentation, vulnerability/weakness management (including failed controls), and formal closure directly restore the security posture after a T1574.006 hijacking has run, matching the recovers verb; the named remainder is that it does not itself restore any already-compromised process memory or resources.
T1574.006responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, analyze root cause, close, and manage related vulnerabilities once an incident is underway, which matches the `responds` verb for a technique that has already executed under a legitimate process.
T1574.007detects — A.5.26's monitoring, logging (d), evidence collection (b), forensic analysis (h) and post-incident root-cause steps (i) can surface the anomalous binary execution or PATH modification once it occurs on the organization's estate, but the pre-compromise technique (modifying PATH or planting the binary) has no guaranteed observable on the victim side and many instances sit outside any response scope.
T1574.007prevents — A.5.26's designated competent team responding to an incident (including containment, evidence collection, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that caused/contributed/failed to prevent it) stops the PATH-interception technique from continuing or recurring on affected systems.
T1574.007recovers — A.5.26 requires post-incident root-cause analysis, vulnerability/weakness management (including controls that failed to prevent the incident), formal closure, and coordination that can invoke business continuity plans; this restores the environment after a realized PATH-interception execution (the technique has already run and delivered its payload).
T1574.007responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, analyze root cause, and close an information security incident once it is underway, which matches the `responds` verb against an executed T1574.007 technique; the named remainder is that pre-containment impact (e.g., already-executed malicious binary) is not undone by response itself.
T1574.008detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause identification and communicating details once an incident is underway; search-order hijacking on Windows produces observable artifacts (suspicious processes, anomalous file execution in program directories) that can be surfaced by competent incident response when it reaches the estate, but the pre-compromise technique itself (placing a file) has no guaranteed organizational vantage point and many hijacks never trigger a detectable incident.
T1574.008prevents — A.5.26's designated competent team responding to an incident (with containment, evidence collection, escalation, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that caused/contributed/failed to prevent it) stops the search-order-hijacking technique from continuing or recurring on affected systems.
T1574.008recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability/weakness management in j, forensic analysis, formal closure) enable recovery of control posture and organizational state after the hijacking technique has run, with the named remainder being direct restoration of any corrupted executables or system state (handled by separate recovery controls).
T1574.008responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, analyze root cause/vulnerabilities/weaknesses that enabled the incident, and formally close it once addressed — all core to responding once T1574.008 is underway.
T1574.009detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause identification) can surface the anomalous executable launch or path-resolution artifact once the technique has run on the organization's estate, but the pre-compromise registry/service/shortcut configuration step itself occurs outside monitored runtime scope and leaves no guaranteed observable until execution.
T1574.009prevents — A.5.26's designated competent team and procedures for containing spread, coordinating with parties, managing related vulnerabilities/weaknesses, and post-incident root-cause work prevent the technique from recurring or succeeding at scale once initially surfaced, though they do not stop the first execution of an unquoted-path hijack.
T1574.009recovers — A.5.26's post-incident analysis, root-cause identification, vulnerability/weakness management (including failed controls), and formal closure directly restore the system to a secure state after the path-interception technique has run, matching the recovers verb; the named remainder is that immediate containment/escalation steps sit in the responds lane instead.
T1574.009responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, analyze root cause, and close an information security incident once underway, which directly matches the act of responding to a T1574.009 execution that has already occurred.
T1574.010detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause identification and managing the weaknesses that caused the incident, all of which surface knowledge of a realized T1574.010 hijack on the organization's estate; the pre-compromise acquisition of the weak service binary itself is outside the organization's visibility and yields no event to respond to.
T1574.010prevents — A.5.26's incident response (containment, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that caused/contributed/failed to prevent the incident) stops the hijacking technique from recurring after the first occurrence.
T1574.010recovers — A.5.26 requires incident response that includes containment, eradication of the actor's foothold (replacing the hijacked binary), forensic analysis, root-cause identification, and explicit management of the exploited vulnerability/weakness, which restores the system from the realized impact of this persistence/elevation technique.
T1574.010responds — A.5.26 explicitly requires a designated competent team to contain (a), eradicate via vulnerability/weakness management (j), log/analyze (d,i), and close (g) an incident once underway, which matches the `responds` verb; the named remainder is that it does not itself perform the forensic or root-cause steps (h,i) that live in 5.27/5.28.
T1574.011detects — A.5.26 requires a designated competent team to respond to incidents (including detection via reported anomalies, evidence collection, logging, and post-incident root-cause analysis), which surfaces this technique once it has produced observable incident artifacts, but the control's scope is limited to incident response rather than proactive or comprehensive monitoring of registry changes.
T1574.011prevents — A.5.26's incident response procedures (containment, root-cause analysis, vulnerability/weakness management in (j), and post-incident fixes) stop the Registry-permissions technique from recurring after it has been observed, which satisfies `prevents` for the class of permission-flaw persistence; the named remainder is first-time abuse before any incident has occurred.
T1574.011responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, analyze root cause, close, and manage the vulnerabilities/weaknesses that caused or enabled the incident once it is underway, which matches the `responds` verb against this persistence/privilege-escalation technique.
T1574.012detects — A.5.26 explicitly requires designated-team response that includes collecting evidence, logging all activities, forensic analysis, and post-incident root-cause identification, all of which surface the COR_PROFILER abuse once it has executed in a .NET process.
T1574.012prevents — A.5.26's designated competent team and explicit procedures for containing spread, coordinating with parties, managing vulnerabilities/weaknesses that caused/contributed/failed to prevent the incident, and post-incident root-cause work directly stop the COR_PROFILER technique from achieving persistence, privilege escalation, or defense impairment in future .NET processes.
T1574.012recovers — A.5.26's post-incident analysis, root-cause documentation, vulnerability/weakness management (including failed controls), and formal closure directly enable recovery of the affected environment and prevention of recurrence after the COR_PROFILER hijack has run.
T1574.012responds — A.5.26's designated competent team and enumerated activities (contain spread, collect/analyze evidence and logs, perform forensics, eradicate via vuln/weakness management in (j), close/record) directly address a realized in-memory or registry-based COR_PROFILER hijack on Windows once underway, with the named remainder being pre-compromise persistence that has not yet produced observable incident artifacts.
T1574.013detects — A.5.26's monitoring, logging (d), evidence collection (b), forensic analysis (h) and post-incident root-cause steps (i) can surface the anomalous callback-table modification or the resulting execution under a legitimate process when that activity reaches the organization's monitored estate, but the pre-compromise technique occurs inside an already-compromised process and many instances remain invisible to organizational response procedures.
T1574.013prevents — A.5.26 requires a designated competent team to respond to incidents once underway (containment, eradication, root-cause analysis, vulnerability remediation), which stops the KernelCallbackTable hijack technique from completing its full effect or recurring; the named remainder is that the initial execution flow hijack must already have succeeded for the incident to be declared.
T1574.013recovers — A.5.26's post-incident analysis, root-cause identification, vulnerability/weakness management (item j), and formal closure directly restore the affected process/system state after the hijack has run, matching the recovers verb; the named remainder is that it does not itself perform the data or execution restoration that a backup or revert control would.
T1574.013responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, analyze root cause, and formally close an incident once underway, which matches the act `responds` names for a technique that has already executed.
T1574.014detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause investigation and post-incident review, all of which can surface AppDomainManager hijacking once it has executed inside a monitored Windows process; however the control's scope is set by organizational requirements and many implementations will lack the process-level telemetry or .NET-specific indicators needed to catch it reliably.
T1574.014prevents — A.5.26's designated competent team and explicit procedures for containing affected systems, coordinating with parties, and managing vulnerabilities/weaknesses that contributed to or failed to prevent the incident directly stop the technique from achieving its full effect once underway, though the initial hijacking may still occur before response begins.
T1574.014recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability management in j, formal closure) restore the affected environment after the AppDomainManager injection has run, matching the recovers verb; the named remainder is that it does not itself restore any lost data or state (that is A.8.13).
T1574.014responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, analyze root cause, and close an information security incident once underway, which directly matches the act of responding to an in-flight AppDomainManager injection technique.
T1578detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause identification) can surface the modification once it has produced observable effects on the organization's estate, but the technique's pre-compromise or stealthy execution on external IaaS infrastructure often leaves no internal event for the incident response process to observe.
T1578prevents — A.5.26's designated competent team and explicit steps (a: contain spread; c: escalate/invoke continuity; f: coordinate to minimize consequences; j: identify/manage vulnerabilities/weaknesses that failed to prevent) act to stop the T1578 technique from completing or succeeding once detected, with a named remainder that some infrastructure modifications (e.g., stealthy deletion of snapshots or evidence) may complete before response begins.
T1578recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability/weakness management in j, forensic collection, formal closure) restore the environment's defended posture after T1578's modification has already run and altered infrastructure.
T1578responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis, and managing related vulnerabilities — directly addressing an in-progress T1578 modification of cloud infrastructure (e.g., containing spread, removing footholds, and post-incident cleanup).
T1578.001detects — A.5.26 requires a designated competent team to respond to incidents (including detection via reported anomalies or indicators), which surfaces the snapshot-creation technique once it has begun as part of incident handling.
T1578.001recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability management in j, formal closure) enable recovery from the evasion technique's effects once the snapshot has been created and used.
T1578.001responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, analyze root cause, and close an information security incident once underway, which directly matches the act of responding to an adversary's T1578.001 snapshot creation (an already-executed evasion technique) with the named remainder being pre-containment impact that is bounded to recovery controls.
T1578.002detects — A.5.26's response activities include collecting evidence, logging, communicating, coordinating, closing/recording, root-cause analysis and identifying weaknesses once an incident is underway; a created cloud instance can produce observable artifacts (new VM events, anomalous compute usage, or attached snapshots) that engage those activities on the organization's estate, but pre-compromise creation with no further activity leaves no incident for the team to respond to.
T1578.002prevents — A.5.26's designated competent team following defined procedures (including containment, escalation, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that enabled the incident) stops the T1578.002 technique from completing its evasion and downstream effects once it is underway, which is what `prevents` asserts in the event-lane anchors.
T1578.002recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability/weakness management in j, formal closure) restore the environment after the T1578.002 technique has run and created the evasive instance, with the named remainder being any unaddressed residual cloud assets or configurations.
T1578.002responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment (a), evidence collection (b), escalation (c), logging (d), communication (e), coordination (f), closure (g), forensics (h), root-cause analysis (i), and vulnerability management (j), all of which apply to an in-progress T1578.002 cloud-instance creation that has already begun evading defenses or enabling further malice.
T1578.003detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause identification and communicating the incident, all of which can surface the deletion (and its forensic gap) once it occurs on the organization's IaaS estate; however the pre-compromise acquisition/creation of the instance and purely external deletions leave a real slice unseen.
T1578.003prevents — A.5.26's designated competent team and explicit procedures for containment (a), evidence collection (b), forensic analysis (h), root-cause post-incident review (i), and vulnerability/weakness remediation (j) directly stop the adversary's post-activity deletion technique from completing its evasion goal in the large majority of cases where the incident is already detected and response is underway.
T1578.003recovers — A.5.26 requires post-incident root-cause analysis, forensic collection, evidence handling, and explicit identification/management of the vulnerabilities/weaknesses (including failed controls) that enabled the incident, which directly supports recovery of forensic artifacts and situational awareness lost when the cloud instance is deleted.
T1578.003responds — A.5.26 explicitly requires a designated competent team to respond to incidents already underway via containment (a), evidence collection (b,h), logging (d), escalation (c), communication/coordination (e,f), formal closure (g), root-cause analysis (i), and vulnerability/weakness management (j), which directly matches responding to T1578.003 once the deletion technique has run.
T1578.004detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause identification and post-incident review, all of which can surface the snapshot-revert action once it has occurred on the organization's IaaS estate; however the technique executes entirely within the cloud provider's management plane and leaves no guaranteed observable on the organization's own monitored systems, so only a slice is covered.
T1578.004prevents — A.5.26's designated competent team, containment (a), evidence collection (b), logging (d), coordination (f), forensic analysis (h), post-incident root-cause work (i), and explicit vulnerability/weakness management (j) directly stop the adversary from successfully completing the revert-and-erase action in the large majority of cases where the incident is already underway or the snapshot mechanism is reachable.
T1578.004recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability management, formal closure, and coordination) enable recovery actions that can restore affected cloud instances from clean snapshots after the revert technique has run, though the control itself does not perform the restore.
T1578.004responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment (a), evidence collection (b), logging (d), escalation (c), communication (e), coordination (f), forensic analysis (h), root-cause post-incident review (i), and vulnerability/weakness remediation (j), which directly matches responding to T1578.004's post-activity reversion that has already run to erase evidence.
T1578.005detects — A.5.26's response activities include collecting evidence, logging, communicating, coordinating, closing/recording, root-cause analysis and identifying weaknesses once an incident is underway; a quota/policy/region change that enables abuse can surface in logs or as anomalous resource requests on the victim's estate, engaging several of those steps, but many modifications (especially pre-abuse or on provider-side approval flows) leave no detectable event inside the organization's monitored scope.
T1578.005prevents — A.5.26's designated competent team responding to an incident (including containment, escalation, coordination, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that enabled it) stops the adversary from completing or sustaining the configuration modification technique once it is detected as an incident.
T1578.005recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability/weakness management in j, formal closure) enable recovery of the modified cloud configuration to a secure baseline after the technique has run.
T1578.005responds — A.5.26's designated competent team and procedures for containing, eradicating, coordinating, and closing an information security incident (once underway) directly address responding to an adversary's in-progress T1578.005 modification of cloud quotas/policies/regions, with the named remainder being pre-containment abuse already realized.
T1583.001prevents — A.5.26's designated incident-response team (with containment, evidence collection, escalation, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that caused/contributed/failed to prevent the incident) directly stops the adversary from completing the technique's intended follow-on use (phishing, C2, drive-by, etc.) once any part of the domain-acquisition activity is detected as an information security incident.
T1583.003prevents — A.5.26's designated competent incident-response team, with its explicit steps to contain spread, collect evidence, coordinate with providers/authorities, identify and manage the vulnerabilities/weaknesses that enabled the incident, and perform root-cause analysis, directly prevents adversaries from successfully retaining or reusing rented VPS infrastructure for targeting/C2 by forcing its detection, disruption, and remediation once acquired and employed.
T1583.005prevents — A.5.26's designated competent team, containment, coordination with external parties (including suppliers/clients), vulnerability/weakness management, and post-incident root-cause analysis directly stop acquisition and use of botnets (especially EOL/unsupported IoT/routers) from succeeding or recurring, with only a bounded remainder for pre-response acquisition.
T1583.006prevents — Incident response procedures that include containment, coordination with external parties (e.g. service providers), vulnerability/weakness management, and post-incident root-cause analysis can prevent the adversary from successfully reusing the registered web service in later attack stages, but this is a minority slice of the pre-attack registration technique itself.
T1583.007prevents — A.5.26's designated competent incident-response team, with its explicit steps to contain spread (a), coordinate with external parties (f), and manage the vulnerabilities/weaknesses that enabled the incident (j), directly stops adversaries from completing the purchase-and-configuration of serverless infrastructure for operational use once the activity is recognized as an information security incident.
T1583.008prevents — A.5.26's designated competent team, containment, coordination with external parties (including suppliers/clients), vulnerability/weakness management, and post-incident root-cause analysis directly stop the malvertising technique from recurring at scale once initially detected, though initial purchase and ad placement can still occur before response triggers.
T1583.008responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, escalate, communicate, coordinate externally, close, forensically analyze, and perform post-incident root-cause/vulnerability management on an information security incident that is already underway, which directly matches the act of responding to a realized malvertising-driven compromise (e.g., Drive-by Compromise).
T1584prevents — A.5.26's designated competent team, containment (a), coordination (f), vulnerability/weakness management (j), and post-incident root-cause analysis directly stop the technique from completing or recurring when an incident is underway or has been detected, with the bounded remainder being fully stealthy/pre-incident compromises that evade all response triggers.
T1584.001prevents — A.5.26's designated competent incident response team, containment (a), forensic analysis (h), root-cause identification (i), and explicit management of vulnerabilities/weaknesses that failed to prevent the incident (j) directly stop domain hijacking techniques from completing or recurring once detected in flight, with the bounded remainder being pre-compromise registration/social-engineering vectors that sit outside the incident-response lane.
T1584.001responds — A.5.26's response activities (containment, evidence collection, logging, communication, coordination, closure, forensics, root-cause analysis, and managing related weaknesses) engage against a realized domain hijacking on the organization's estate, but several core steps (a containment, c escalation/continuity, h forensics) have empty objects when the hijack is purely pre-compromise reconnaissance or external subdomain takeover with no internal system affected.
T1584.002prevents — A.5.26's designated competent incident-response team, with its explicit steps to contain spreading consequences, collect evidence, coordinate with external parties (including suppliers), identify and manage the vulnerabilities/weaknesses that enabled the incident, and perform root-cause analysis, directly stops the post-compromise use and persistence of a compromised third-party DNS server (T1584.002) in the great majority of cases once the compromise is known.
T1584.003prevents — A.5.26's designated competent team and procedures for containing spread, coordinating with external parties (e.g. providers), forensic analysis, root-cause identification, and managing the vulnerabilities/weaknesses that enabled the compromise directly stop the adversary technique from completing or recurring on the affected VPS infrastructure.
T1584.004prevents — A.5.26's designated competent team, containment (a), escalation/crisis invocation (c), coordination (f), and post-incident root-cause/vulnerability management (i,j) directly stop the adversary's post-compromise use of the already-compromised third-party server for C2/staging/operations, though the initial compromise step itself sits outside the incident-response lane.
T1584.005prevents — A.5.26's designated competent team, containment (a), coordination (f), and post-incident root-cause/vulnerability management (i,j) directly stop the adversary from building, taking over, or using the botnet for follow-on activity once an incident is underway.
T1584.006prevents — A.5.26's designated competent team, containment (a), coordination (f), vulnerability/weakness management (j) and post-incident root-cause work directly stop the adversary from completing the compromise of legitimate web-service accounts and from reusing them as infrastructure, with the bounded remainder being pre-compromise account takeover vectors that sit outside the incident-response lane.
T1584.007prevents — A.5.26's designated competent team, containment (a), coordination (f), and vulnerability/weakness management (j) directly stop the adversary's ability to leverage a compromised serverless runtime for C2/proxy/hiding once the incident is detected, preventing the technique from continuing or succeeding in its targeting purpose.
T1584.008prevents — A.5.26's designated competent team, containment (a), coordination (f), vulnerability/weakness management (j), and post-incident root-cause work directly stop the adversary's ongoing use of already-compromised third-party network devices for follow-on operations (phishing hosting, C2 proxy/botnet, credential harvesting), which is what `prevents` asserts for this technique; the named remainder is that it does not stop the initial compromise itself.
T1584.008responds — A.5.26's response activities (contain, eradicate, log, analyze root cause, manage related weaknesses) engage once an incident is underway on the organization's estate, but this pre-compromise technique against third-party devices leaves no affected organizational system, evidence, or artifact for most of those activities to act on.
T1585.001prevents — A.5.26's designated competent incident-response team, containment, coordination with external parties (including forums and suppliers), vulnerability/weakness management, and post-incident root-cause analysis that feeds control improvements can prevent the technique from being (re)used in future targeting once an initial social-media persona or connection is discovered as part of an incident.
T1585.002prevents — A.5.26's designated competent incident-response team, containment, escalation, coordination with external parties (including suppliers/clients/forums), and explicit identification/management of the vulnerabilities/weaknesses that caused/contributed/failed-to-prevent the incident directly stop the adversary's created email accounts from being leveraged for follow-on T1598/T1566 phishing, T1583 infrastructure acquisition, or persona cultivation once any of those behaviors trigger an incident.
T1586prevents — A.5.26 requires a designated competent team and explicit procedures that include containing spread, evidence collection, escalation, logging, communication, coordination, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that caused/contributed/failed to prevent the incident — directly stopping the T1586 account-compromise technique (and its downstream use) from continuing or recurring.
T1586.001prevents — A.5.26's designated competent team, containment, coordination with external parties (including suppliers/clients), and explicit identification/management of vulnerabilities/weaknesses that failed to prevent the incident directly stop the adversary technique from completing or being leveraged further in most cases (e.g., by revoking access, notifying platforms, or fixing the compromise vector).
T1586.002prevents — A.5.26's designated competent team, containment, escalation, coordination with external parties (including suppliers/clients), and explicit management of vulnerabilities/weaknesses that contributed to or failed to prevent the incident directly stop the adversary's ability to acquire and operationally use a compromised email account in most cases once the incident is underway.
T1586.003prevents — A.5.26's designated competent team, containment (a), escalation/crisis invocation (c), coordination with external parties (f), and explicit post-incident identification/management of the vulnerabilities/weaknesses (j) that enabled the cloud-account compromise stop the technique from completing or recurring in most cases once any part of it is underway.
T1587.001prevents — A.5.26's designated competent team, containment, forensic analysis, root-cause identification, and explicit management of vulnerabilities/weaknesses that failed to prevent the incident directly stop the adversary's malware-development technique from reaching operational use in most cases once any precursor activity is known.
T1587.002prevents — A.5.26's designated competent incident-response team, with its explicit steps to contain spread, collect evidence, perform forensic analysis, identify root causes/vulnerabilities/weaknesses that allowed the incident, and coordinate to minimize consequences, directly stops the adversary technique from completing its targeting objective in the large majority of cases once it is underway.
T1587.003prevents — incident response procedures that include identifying/managing vulnerabilities and weaknesses (including those that failed to prevent the incident) can constrain or deter reuse of self-signed certs created in a prior incident, but do not stop the initial creation act itself
T1587.004prevents — A.5.26's post-incident analysis, root-cause identification, and explicit step (j) to identify/manage the vulnerabilities/weaknesses that caused/contributed/failed to prevent the incident directly stops the adversary from reusing or further developing that same exploit in subsequent targeting.
T1588prevents — A.5.26's designated competent incident response team, containment, evidence collection, forensic analysis, root-cause identification, and explicit management of vulnerabilities/weaknesses that contributed to or failed to prevent the incident directly stops the adversary from successfully using stolen/bought capabilities in follow-on targeting once the acquisition event is detected.
T1588.001prevents — A.5.26's incident response procedures (including post-incident root-cause analysis, vulnerability/weakness management in j, and coordination with external parties in f) can prevent reuse of the same acquired malware in future targeting by addressing the enabling weaknesses, but this is a minority slice of the pre-attack acquisition technique itself.
T1588.002prevents — A.5.26's designated competent team following defined procedures for containment, evidence collection, escalation, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that enabled the incident directly stops the adversary technique of acquiring tools for post-compromise use from recurring or succeeding at scale.
T1588.003prevents — A.5.26's designated competent incident-response team, containment, evidence collection, forensic analysis, root-cause identification, and explicit step (j) to identify/manage the vulnerabilities/weaknesses (including failed controls) that enabled the incident directly prevent the adversary from reusing stolen or purchased code-signing certificates in future operations.
T1588.004prevents — A.5.26's designated competent team, containment, coordination with external parties (including suppliers/CAs), vulnerability/weakness management, and post-incident root-cause actions directly stop the technique from completing or recurring when it surfaces as an incident (e.g. stolen certs, CA compromise, or post-install C2/AiTM use).
T1588.005prevents — A.5.26's designated competent team, containment, coordination with external parties (including suppliers/clients), vulnerability management, and post-incident root-cause analysis directly stop the acquired exploit from being used in downstream ATT&CK phases (T1190 etc.), though the pre-acquisition monitoring/purchase/steal step itself is outside the incident-response window and remains a named remainder.
T1588.005responds — A.5.26 explicitly requires a designated competent team to respond to incidents (including containment, evidence collection, escalation, forensic analysis, root-cause identification, and vulnerability/weakness management once the incident is underway), which directly matches the post-acquisition use of purchased/stolen exploits in the adversary lifecycle.
T1589prevents — A.5.26's incident response (containment, evidence collection, escalation, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that enabled the incident) directly stops the adversary from completing or repeating T1589 once any part of it has begun, with the bounded remainder being fully passive pre-compromise OSINT that never triggers an observable incident.
T1589.001prevents — A.5.26's designated competent team, containment, evidence collection, escalation, forensic analysis, root-cause identification, and explicit management of vulnerabilities/weaknesses that failed to prevent the incident directly stop credential-gathering techniques (phishing, site compromise, leaks, dark-web purchases) from succeeding or recurring when the incident is already underway.
T1589.003prevents — A.5.26's incident response procedures (containment, evidence handling, escalation, forensic analysis, root-cause identification, and explicit management of vulnerabilities/weaknesses that enabled the incident) act to prevent successful follow-on use of gathered employee names in reconnaissance, phishing, or initial-access techniques once an incident involving T1589.003 is detected.
T1591.004prevents — A.5.26's designated competent incident-response team, containment, evidence handling, escalation, logging, communication, coordination, forensic analysis, root-cause identification, and explicit step (j) to identify/manage vulnerabilities/weaknesses that failed to prevent the incident directly stops the reconnaissance technique from completing its targeting objective once any incident (including elicitation or data exposure) is underway.
T1592.002prevents — A.5.26's designated competent incident-response team, containment, evidence collection, forensic analysis, root-cause identification, and explicit step (j) to identify/manage vulnerabilities/weaknesses (including those that failed to prevent the incident) directly stops the pre-attack reconnaissance technique from proceeding to successful exploitation or further operations once any incident is triggered.
T1593.001prevents — A.5.26's incident response procedures (including post-incident root-cause analysis, vulnerability/weakness management in j, and coordination in f) can prevent the T1593.001 technique from recurring after it has been used in a prior incident, by addressing the enabling weaknesses that allowed social media reconnaissance to succeed.
T1595detects — A.5.26 requires a designated competent team to respond to incidents (including detection via reported anomalies or logs per its procedures), which surfaces active scanning once observed as an information security incident, but the clause's scope is limited to post-detection response rather than mandating broad proactive detection of reconnaissance.
T1595.001detects — A.5.26 requires monitoring for and response to incidents (including logging, analysis, and root-cause identification), which can surface scanning activity once it triggers an observable incident or anomaly, but the control is scoped to post-incident response rather than proactive or comprehensive detection of reconnaissance techniques.
T1595.001responds — A.5.26's response activities (evidence collection, logging, communication, coordination, root-cause analysis, vulnerability management) engage once the scan produces observable artifacts on the organization's estate; containment/escalation/forensics are empty because the pre-compromise scan has no affected system or realized impact, leaving a genuine but minority slice of the verb.
T1595.002detects — A.5.26 requires a designated team to respond to incidents (including detection via reported anomalies or logs) once they are underway, but the control's scope is post-detection response and does not mandate or perform proactive detection of pre-attack reconnaissance like vulnerability scanning on the PRE platform.
T1595.002responds — OWNER RULING 2026-09-14, per-item. The scan reaches the organization's hosts and harvests banners and listening ports, so unlike the WHOIS pair there is a real event on the estate and real evidence in the logs. Engaged: evidence, logging, communication, coordination, closure, root cause, and managing the weaknesses the scan exposed. Empty: containment (nothing spread), escalation to crisis management, forensics (no artifact). The core of the verb as the lane defines it -- contain and eradicate once underway -- is empty while the administrative half engages. OWNER ADDED, and it is why this is `partial` not `none`: A.5.26 does not enumerate them, but response to a scan can include deceptive measures and automated IP blocking, which under the faithful-implementation baseline are available and are genuine response actions. This row is now an ANCHOR (EVENT_LANE_ANCHORS, v1.38).
T1595.003detects — A.5.26 requires a designated competent team to respond to incidents (including detection, containment, analysis, and post-incident root-cause/vulnerability identification), but its scope is limited to declared information security incidents rather than proactively detecting pre-incident reconnaissance like wordlist scanning on PRE platforms.
T1595.003responds — A.5.26's response activities (evidence collection, logging, communication, coordination, root-cause analysis, vulnerability management) engage on the organization's estate when its servers answer the scan, but core containment/eradication is empty as no compromise has occurred.
T1596.002responds — OWNER RULING 2026-09-14, per-item, with the control's full guidance and the technique's full ATT&CK text in front of him. A WHOIS query goes to a regional Internet registry's server and never touches the organization, so every one of A.5.26's ten response activities has an empty object: no affected system to contain, no evidence on the estate to collect, no artifact to eradicate, nothing to close. This row is now an ANCHOR (EVENT_LANE_ANCHORS, v1.38) teaching the `none` rung, which `responds` had never been shown -- the verb's two prior anchors were both `mostly` and both on T1486, and the corpus returned 0 `none` and 0 `full` across all 3,498 `responds` rows.
T1598prevents — A.5.26 requires a designated competent team and explicit procedures that include containing spread, evidence collection, escalation, logging, communication, coordination with external parties, forensic analysis, root-cause identification, and explicit remediation of the vulnerabilities/weaknesses (including failed controls) that enabled the incident; this directly stops the phishing-for-information technique from recurring once it has been detected and processed as an incident.
T1598.001prevents — A.5.26's designated competent team following defined procedures for containing spread, evidence collection, escalation, communication, coordination with external parties, forensic analysis, root-cause identification, and explicit management of vulnerabilities/weaknesses that failed to prevent the incident directly stops the social-engineering elicitation from succeeding or recurring when the incident is underway or has just occurred.
T1598.001responds — A.5.26's response activities (evidence collection, logging, communication, coordination, root-cause analysis, vulnerability management) engage once the spearphishing message has been sent and received, but core containment/escalation/forensics steps have no object because the technique ends at the pre-compromise delivery surface with no compromised system or artifact inside the organization.
T1598.002detects — A.5.26 requires a designated competent team to respond to incidents (including detection, containment, analysis, and post-incident root-cause/vulnerability identification), which surfaces spearphishing attachment events once they have begun; this is a genuine but minority slice because the control's scope is set by communicated procedures and does not mandate proactive detection mechanisms for all social-engineering lures before impact.
T1598.002prevents — A.5.26's designated competent team, containment, escalation, coordination with external parties, and post-incident root-cause/vulnerability management (including controls that failed to prevent the incident) stop most spearphishing-attachment deliveries from succeeding when the procedure is followed, with the bounded remainder being pre-delivery social-engineering lures that never reach the incident-response stage.
T1598.002responds — A.5.26's response activities (a-j) engage once the spearphishing attachment reaches the recipient and is acted on (evidence collection, logging, communication, coordination, root-cause analysis, vulnerability management), but pre-compromise delivery and most social-engineering steps have no affected system/artifact inside the organization to contain or eradicate, leaving a large empty slice of the technique.
T1598.003detects — A.5.26's response activities (evidence collection, logging, communication, coordination, post-incident analysis, root-cause identification) can surface the spearphishing link once a recipient reports it or it is noticed in logs/telemetry, but the pre-compromise technique occurs entirely outside the organization with no guaranteed internal artifact until interaction
T1598.003prevents — A.5.26's designated competent team, containment, escalation, coordination with external parties, and post-incident root-cause/vulnerability management directly stop the spearphishing technique from succeeding or recurring when the incident is underway or has just occurred, though it does not stop the initial delivery of the message itself.
T1598.003responds — A.5.26's response activities (evidence collection, logging, communication, coordination, root-cause analysis, vulnerability management) engage once the spearphishing link is received or clicked and information is elicited, but core containment/escalation/forensics are empty because no organizational system is compromised at this pre-compromise stage.
T1598.004prevents — A.5.26's designated competent team and explicit procedures for containing spread, communicating warnings, coordinating with external parties, and performing post-incident root-cause/vulnerability analysis (including controls that failed to prevent) directly stop most vishing successes from yielding usable information or further compromise, though the initial social-engineering call itself can still occur before response is triggered.
T1598.004responds — A.5.26's response activities (contain, evidence, log, communicate, coordinate, close, forensics, root-cause, manage weaknesses) engage once a vishing call has occurred and information is elicited on the victim's side; partial because pre-compromise reconnaissance, spoofing and the call delivery itself have no affected system/artifact inside the organization to contain/eradicate, leaving only the administrative/follow-up slice (as in the T1595.002 anchor).
T1599detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause identification) can surface the compromise of a boundary device once it has occurred on the organization's estate, but the technique's upstream/pre-compromise nature (adversary acquiring and reconfiguring an external or perimeter device before bridging) leaves a large slice outside any response trigger.
T1599prevents — A.5.26's designated competent team and procedures for containing spread (a), coordinating with parties to minimize consequences (f), and managing vulnerabilities/weaknesses that caused/contributed/failed to prevent the incident (j) stop the boundary-bridging technique from completing its full effect once an incident is recognized, though this is reactive to an already-initiated compromise rather than stopping initial device takeover.
T1599recovers — A.5.26's post-incident analysis, root-cause identification, vulnerability management (j), forensic work, and formal closure enable recovery of the compromised boundary device and restoration of intended segmentation after the bridging technique has run.
T1599responds — A.5.26 explicitly requires a designated competent team to contain spreading incidents, log/analyze/eradicate them, coordinate with parties, close the incident, and address root causes/vulnerabilities once underway, which matches the `responds` verb against boundary-bridging T1599.
T1599.001prevents — A.5.26's designated competent team responding to an incident (including containment of affected systems, coordination to minimize consequences, and identifying/managing the vulnerabilities/weaknesses that enabled the incident) stops the NAT-traversal technique from continuing or succeeding further once it has begun, which satisfies the `prevents` verb per the event-lane anchors (cf. A.5.26 vs T1486 mostly and A.8.5 vs T1110.001 mostly).
T1599.001recovers — A.5.26's post-incident analysis, root-cause identification, vulnerability management (j), and formal closure act after the NAT-traversal technique has run, restoring control posture and addressing the exploited boundary weakness much as A.5.26 recovers from realized impact in the T1486 anchor.
T1599.001responds — A.5.26 explicitly requires a designated competent team to respond to incidents (once underway) via containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis, and managing the vulnerabilities/weaknesses that enabled the incident — directly matching the post-breach response lane for an already-executed T1599.001 technique that has bridged networks or obscured activity.
T1600prevents — A.5.26's designated competent team following defined procedures (including containment, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that caused/contributed/failed to prevent the incident) stops the T1600 technique from completing or recurring on affected devices, with the bounded remainder being the initial compromise window before response begins.
T1600recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability/weakness management in j, forensic analysis, and formal closure) enable recovery of encryption capability on the compromised network device after the T1600 technique has run.
T1600responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment (a), evidence collection (b), escalation (c), logging (d), communication (e), coordination (f), closure (g), forensics (h), root-cause analysis (i), and vulnerability/weakness management (j), which directly matches the `responds` verb for an encryption-weakening incident on network devices.
T1600.001prevents — A.5.26's designated competent team responding to an incident (including containment, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that caused/contributed/failed to prevent it) stops the Reduce Key Space technique from continuing or recurring on the affected device(s).
T1600.001recovers — A.5.26's post-incident analysis, root-cause identification, vulnerability management (item j), and formal closure after addressing the incident enable recovery actions that restore stronger encryption parameters on the affected network device.
T1601prevents — A.5.26's designated competent team following defined procedures (including containment, forensic analysis, root-cause identification, and explicit management of vulnerabilities/weaknesses that caused/contributed/failed to prevent the incident) stops the T1601 technique from completing or recurring on affected embedded devices.
T1601recovers — post-incident root-cause analysis, vulnerability management, and formal closure (including forensic steps) enable recovery of device integrity by replacing the modified monolithic image and restoring defenses after the technique has run
T1601responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, close, and post-analyze an incident once underway, which directly matches the act of responding to a T1601 technique that has already executed on a network device.
T1601.001prevents — A.5.26's designated competent team, containment (a), forensic analysis (h), root-cause identification (i), and explicit management of vulnerabilities/weaknesses that failed to prevent the incident (j) stop the adversary from completing or repeating the patch technique on affected or similar network devices.
T1601.001recovers — A.5.26 response procedures (containment, evidence, escalation, logging, communication, forensic analysis, post-incident root-cause review, and vulnerability management) act on an already-underway incident but do not restore the pre-incident state of the network-device OS image; recovery of that state is outside the listed steps and belongs to separate continuity/backup controls.
T1601.001responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, analyze root cause, close, and manage related vulnerabilities once an incident is underway, which directly matches the act of responding to a live T1601.001 technique that has already modified a device OS image.
T1601.002prevents — A.5.26's incident response (containment, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that caused/contributed/failed to prevent the incident) stops the downgrade technique from completing its goal when it is treated as a security incident, with the bounded remainder being pre-response execution on unmonitored or non-escalated devices.
T1601.002recovers — A.5.26's post-incident analysis, root-cause identification, vulnerability management (item j), and formal closure directly enable recovery of the device to a hardened image after the downgrade technique has run and been contained.
T1602prevents — A.5.26's designated competent team, containment (a), coordination (f), and post-incident root-cause/vulnerability management (i,j) directly stop the adversary technique from completing or recurring once an incident is recognized.
T1602recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability management in j, forensic analysis, formal closure) enable recovery actions that restore the configuration repository's integrity and security posture after the T1602 exfiltration has occurred.
T1602responds — T1602 is a pre-compromise discovery technique that never touches the organization; no affected system exists to contain, no artifact to eradicate, and none of A.5.26's ten response activities have an object, exactly as ruled for the identical control against the pre-compromise T1596.002 anchor
T1602.001detects — A.5.26's response activities (evidence collection, logging, post-incident analysis, root-cause identification) can surface the SNMP MIB query once it has occurred on the organization's network devices, but the pre-compromise reconnaissance technique itself produces no affected system, artifact or incident on the estate for most of the clause's core response steps to engage.
T1602.001prevents — A.5.26's designated competent team following defined procedures (including containment, evidence handling, escalation, coordination with external parties, forensic analysis, root-cause identification, and explicit management of vulnerabilities/weaknesses that enabled the incident) directly stops the SNMP MIB dump technique from completing or recurring when the incident is underway or has just occurred.
T1602.002detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause identification) can surface the configuration dump once it has occurred on the organization's own network devices, but the technique's pre-compromise reconnaissance nature on external or unmanaged infrastructure leaves a large slice outside any response trigger.
T1602.002prevents — A.5.26's designated competent team responding to an incident (including containment, evidence collection, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that enabled it) stops the T1602.002 technique from continuing or recurring on the affected network devices.
T1602.002recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability management in j, forensic analysis, formal closure) enable recovery of the network device and its configuration state after the dump has occurred.
T1602.002responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, analyze root cause, and close an information security incident once underway, which directly matches the act of responding to an adversary technique that has already executed to dump network device configuration.
T1606prevents — A.5.26's designated competent team responding to an incident (including containment, evidence collection, escalation, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that caused/contributed/failed to prevent it) stops the adversary's ongoing use of the forged web credential and prevents the technique from continuing or recurring.
T1606recovers — A.5.26's post-incident analysis, root-cause identification, vulnerability management (item j), and formal closure directly enable recovery of the security posture after a T1606 forgery has been used, matching the recovers verb in the event-lane anchors (e.g., A.5.26 vs T1486).
T1606responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, analyze root cause, and close an information security incident once underway, which directly matches the `responds` verb against an adversary forging and then using web credentials.
T1606.001detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause, vulnerability management) can surface the use of a forged cookie once it is observed in logs, alerts or an ongoing incident on the organization's estate, but the technique's pre-compromise generation (often external to monitored systems) and many SaaS/IaaS scenarios leave a large slice unseen.
T1606.001prevents — A.5.26's designated competent team responding to an incident (containing spread, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis, and vulnerability/weakness management) stops forged-cookie techniques from continuing or recurring once underway, which satisfies `prevents` per the event-lane anchors; the named remainder is that it does not stop the initial forgery before first use.
T1606.001recovers — A.5.26 response procedures (containment, evidence, escalation, logging, communication, closure, forensics, root-cause analysis) act on an already-underway incident but do not restore any destroyed or altered state after the forged-cookie access succeeds; recovery of service or data is outside its defined scope (see A.8.13 anchors for the recovers lane).
T1606.001responds — A.5.26 requires a competent team to respond to incidents once underway via containment, eradication, escalation, logging, communication, coordination, forensic analysis, root-cause identification, and post-incident vulnerability/weakness management, which directly matches the act of responding to a successful T1606.001 cookie-forging incident (with the named remainder being pre-containment impact already realized).
T1606.002detects — A.5.26 explicitly requires a designated competent team to respond to incidents (including detection triggers, evidence collection, logging, forensic analysis, and post-incident root-cause identification), which surfaces the SAML token forgery technique once it is underway or has produced observable effects.
T1606.002prevents — A.5.26's designated competent team and explicit steps (a) contain spread, (c) escalate/invoke continuity, (f) coordinate to minimize consequences, and (j) identify/manage the vulnerabilities/weaknesses that enabled the forgery together stop the SAML-token technique from succeeding or recurring, with only the already-issued token's immediate use as a bounded remainder.
T1606.002recovers — A.5.26's post-incident analysis, root-cause documentation, vulnerability/weakness management (item j), and formal closure directly restore the security posture after a forged-SAML incident has occurred, matching the recovers verb; the named remainder is that it does not itself restore any concrete assets (e.g. accounts or sessions) altered by the forged token.
T1606.002responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, analyze root cause, close, and coordinate on an incident once underway, which directly matches the act of responding to a SAML token forgery that has already succeeded and is in use.
T1608responds — MYTHOS ORDER 2026-09-15 02:40 §2. This pair was REJECTED on a single call in the v1.38 regrade and then held 5/5 — unanimous the other way — when replayed at k=5 (dbadmin/measure_rejection_stability.py). A single call is a sample, not a verdict. Under the estate's own write rule a 5/5 hold writes, so it is written, at the grade its five replicates agreed on.
T1608.003prevents — A.5.26's designated competent team and explicit steps (a) contain spread, (c) escalate/invoke continuity, (f) coordinate externally, and (j) identify/manage the vulnerabilities/weaknesses that enabled the certificate installation directly stop the technique from completing or recurring on affected or like infrastructure.
T1608.004prevents — A.5.26's designated competent team, containment (a), coordination (f), vulnerability/weakness management (j), and post-incident root-cause work directly stop the drive-by staging technique from completing or recurring once underway or after first discovery.
T1608.005prevents — A.5.26's designated competent team, containment (a), coordination (f), vulnerability/weakness management (j), and post-incident root-cause analysis directly stop the pre-phish setup of link targets (cloned sites, malicious domains, shortened URLs, IPFS hosting) from reaching victims or recurring, though some infrastructure acquisition may complete before response triggers.
T1608.005responds — A.5.26's response activities (evidence collection, logging, communication, coordination, root-cause analysis, vulnerability management) engage once a spearphishing link target is used against the organization, but core containment/eradication steps have no object because the pre-compromise setup occurs entirely outside the organization's estate.
T1608.006prevents — A.5.26's designated competent team, containment, coordination with external parties (including forums and suppliers), forensic/root-cause analysis, and explicit identification/management of the vulnerabilities/weaknesses that caused/contributed to/failed to prevent the incident directly stop SEO poisoning (a pre-attack staging technique on compromised or planted sites) from succeeding or recurring, with the bounded remainder being the initial compromise step that plants the poisoned content.
T1608.006responds — A.5.26's response activities (containment, evidence collection, logging, communication, coordination, closure, forensics, root-cause analysis, and managing related weaknesses) engage once an incident is underway on the organization's estate; however, the pre-compromise T1608.006 poisoning of external search results or in-site developer searches has no affected internal system to contain/eradicate and only a thin slice (post-click victim-side incident or supply-chain follow-on) triggers real response actions.
T1609detects — A.5.26 requires monitoring for and response to incidents (including logging, escalation, forensic analysis, and post-incident root-cause identification), which can surface container admin command abuse once it triggers an observable incident, but the clause's scope is set by organizational procedures and does not mandate specific detection of this technique.
T1609prevents — A.5.26's designated competent team, containment (a), coordination (f), and post-incident root-cause/vulnerability management (i,j) directly stop the T1609 technique from completing or recurring once underway, with a bounded remainder for pre-response successful execution.
T1609responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis and vulnerability management — all of which directly address an in-progress or realized T1609 execution without preventing the initial abuse.
T1610detects — A.5.26 requires a designated competent team to respond to incidents (including detection, containment, analysis, and post-incident root-cause/vulnerability identification), which surfaces container deployment as an anomalous or malicious event once underway.
T1610prevents — A.5.26's designated competent incident-response team, with its explicit steps to contain spread (a), coordinate with parties to minimize consequences (f), identify/manage vulnerabilities/weaknesses that contributed or failed to prevent (j), and invoke continuity plans (c), stops the T1610 technique from completing its full effect in most cases once underway, though some initial deployment may succeed before response activates.
T1610responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, close, and post-analyze an incident once underway, which directly matches the act of responding to a T1610 container deployment that has already occurred.
T1611detects — A.5.26 explicitly requires a designated competent team to respond to incidents (including detection triggers, evidence collection, logging, forensic analysis, and post-incident root-cause work), which surfaces T1611 once the escape is underway or has succeeded.
T1611prevents — A.5.26's designated competent team and explicit steps (a) contain spread, (b) collect evidence, (c) escalate/invoke continuity, (f) coordinate externally, and (j) identify/manage the vulnerabilities/weaknesses that enabled the escape directly stop the technique from completing its full breakout and follow-on objectives in most cases once underway.
T1611responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, close, and post-analyze an information security incident once underway, which directly matches the act of responding to a realized container/host escape (T1611) with the named remainder that impact already realized before containment is not undone by response itself.
T1612detects — A.5.26's response activities include collecting evidence, logging, forensic analysis, root-cause identification and managing the weaknesses exposed by an incident that has already occurred; a build occurring on the host is an observable event on the organization's estate that can surface in logs or anomalies once underway, but the control's scope is limited to post-occurrence response rather than proactive detection of the build itself.
T1612prevents — A.5.26's designated competent team responding to incidents (including containment, evidence collection, escalation, forensic analysis, root-cause identification, and explicit management of vulnerabilities/weaknesses that caused/contributed/failed to prevent the incident) stops the T1612 technique from completing or recurring once it is underway or has been initially observed.
T1612recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability management in j, formal closure) enable recovery of the environment after the build-image technique has run and produced its malicious container image.
T1612responds — A.5.26's response activities (a-j) engage once a build-image event is underway on the estate: evidence collection, logging, communication, coordination, forensic analysis, root-cause, and managing the resulting vulnerable image/weakness all apply, but containment/escalation/closing have limited or no object when the build itself is the initial undetected step.
T1619prevents — A.5.26's designated competent team responding to an incident (with containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis, and vulnerability/weakness management) prevents the adversary from completing follow-on behaviors that rely on the discovery results, such as requesting and accessing enumerated cloud storage objects.
T1620detects — A.5.26's response activities include collecting evidence, logging, forensic analysis and post-incident root-cause work that can surface reflective code loading once it has occurred on an instrumented system; however the clause's scope is set by organizational requirements and many of its core response steps (containment, escalation, crisis invocation) have no object when the technique executes entirely in-process with no separate artifact or spread.
T1620prevents — A.5.26's designated competent incident-response team, once aware of the technique (via monitoring or anomaly), contains affected systems (a), escalates, coordinates externally, and explicitly identifies/manages the enabling vulnerabilities/weaknesses (j) that allowed reflective loading, stopping further or repeated use of the technique.
T1620responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, analyze root cause/vulnerabilities, and formally close an information security incident once underway, which matches the `responds` verb against T1620's in-memory execution technique.
T1621detects — A.5.26's response activities (evidence collection, logging, communication, coordination, post-incident analysis, root-cause identification) can surface the MFA fatigue or push-bombardment pattern once it is underway on organizational systems or logs, but the technique's upstream credential use, SSPR abuse, and generation of requests occur on external IdP/registrar infrastructure outside the organization's monitoring scope, leaving a large slice unseen.
T1621prevents — A.5.26 requires a designated competent team to respond to incidents once underway (containment, eradication, root-cause analysis, vulnerability management), which stops the MFA-fatigue technique from succeeding further and prevents the full account takeover that the technique aims for; the named remainder is that the initial push-bombardment and user approval can still occur before response begins.
T1621recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability management, formal closure, and coordination) enable recovery of the account and restoration of secure state after the MFA-fatigue technique has succeeded in gaining access.
T1621responds — A.5.26 explicitly requires a competent team to contain, eradicate, log, escalate, communicate and close an information security incident once it is underway, which directly matches the act of responding to an in-progress MFA-fatigue or push-bombardment attack.
T1647detects — A.5.26 requires monitoring for and response to incidents (including logging, forensic analysis, and post-incident root-cause identification), which can surface plist modifications once they trigger observable incident indicators, but the control's scope is set by organizational procedures and does not mandate detection of this specific low-level file technique.
T1647recovers — A.5.26's post-incident analysis, root-cause identification, vulnerability management (item j), and formal closure directly enable recovery of the affected system state after plist modification has enabled persistence or evasion.
T1647responds — A.5.26 explicitly requires a designated competent team to respond to incidents (once underway) via containment, evidence collection, escalation, logging, communication, coordination, forensic analysis, root-cause post-incident review, and vulnerability/weakness management — all of which directly address a plist-modification technique that has already executed to enable persistence or evasion.
T1648detects — A.5.26 requires a designated competent team to respond to incidents (including detection via reported anomalies, evidence collection, logging, and post-incident root-cause analysis), which surfaces some serverless abuse techniques once they trigger observable events, but the clause's scope is limited to declared incidents rather than proactive or comprehensive detection of stealthy serverless execution.
T1648prevents — A.5.26's designated competent team and explicit steps (a) contain spread, (c) escalate/invoke continuity, (f) coordinate to minimize consequences, and (j) identify/manage the vulnerabilities/weaknesses that enabled the serverless abuse, directly stopping the technique from completing its full effect in most cases once triggered.
T1648responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, analyze root cause, close, and manage vulnerabilities/weaknesses of an information security incident once underway, which directly matches the act of responding to adversary abuse of serverless execution (e.g. containing crypto-mining functions, revoking backdoored roles/credentials, or remediating event-triggered persistence).
T1649detects — A.5.26 explicitly requires a designated competent team to respond to incidents (including detection triggers, evidence collection, logging, forensic analysis, and post-incident root-cause identification), which surfaces the certificate theft/forgery technique once it is underway or has produced observable artifacts.
T1649prevents — A.5.26's designated competent team, containment (a), coordination (f), vulnerability/weakness management (j), and post-incident root-cause work directly stop certificate theft/forgery techniques from continuing or recurring in the victim environment.
T1649recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability/weakness management in j, formal closure) enable recovery actions that restore secure authentication posture after certificate theft/forgery has occurred.
T1649responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, analyze root cause, close, and manage vulnerabilities/weaknesses once an incident is underway, which directly matches the `responds` verb against certificate theft/forgery techniques that have already executed.
T1650prevents — A.5.26's designated competent team, containment, coordination with external parties (including suppliers/clients), and explicit identification/management of the vulnerabilities/weaknesses that caused/contributed to the incident (item j) directly stop the purchased foothold from being leveraged further or sold onward, closing the bulk of the technique while leaving a bounded remainder around the initial broker transaction itself.
T1651detects — A.5.26's response activities (evidence collection, logging, post-incident analysis, root-cause identification) can surface the abuse of cloud admin services once it has produced observable artifacts on the organization's estate, but the technique's pre-compromise acquisition of admin access (especially via trusted relationships or provider compromise) often leaves no event on the estate for the designated team to detect.
T1651prevents — A.5.26's designated competent team, containment (a), escalation/crisis invocation (c), coordination (f), and post-incident root-cause/vulnerability management (i,j) directly stop the T1651 technique from continuing or recurring once the incident is underway, with a named remainder that the initial abuse can still occur before response begins.
T1651responds — A.5.26 explicitly requires a designated competent team to respond to incidents (once underway) via containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis, and vulnerability/weakness management — all of which directly address an in-progress T1651 execution that has already leveraged admin or trusted access.
T1653detects — A.5.26's response activities (evidence collection, logging, forensic analysis, post-incident root cause) can surface the power-setting abuse once it has produced observable effects on the estate, but the pre-compromise technique itself occurs with no affected system or incident to respond to until after persistence is achieved.
T1653prevents — A.5.26's designated competent team responding to an incident (including containment, eradication, root-cause analysis, and fixing the vulnerabilities/weaknesses that enabled it) stops the T1653 technique from continuing or recurring on the affected systems.
T1653responds — A.5.26 requires a designated competent team to respond to incidents (once underway) via containment, eradication, forensic analysis, root-cause identification, and post-incident remediation of the vulnerabilities/weaknesses that enabled the incident, which directly matches responding to T1653's impairment of power/hibernation settings that has already occurred on an infected machine.
T1654detects — A.5.26's response activities include collecting evidence, logging response actions, forensic analysis, and post-incident root-cause work that can surface log-enumeration activity once it has touched the organization's estate or its incident-response artifacts; this is genuine but only a slice because the technique can run entirely pre-compromise or against external/centralized logging infrastructure outside the incident-response scope, and the control's core is response rather than proactive detection.
T1654prevents — A.5.26's designated competent incident response team, containment, real-time monitoring of the incident, and post-incident root-cause/vulnerability analysis (including controls that failed to prevent it) directly stops adversaries from safely enumerating logs to track and evade response procedures, which is the technique's explicit purpose in the final paragraph; the remainder is pre-compromise or non-response-related log enumeration for discovery.
T1654responds — A.5.26's response activities (containment, evidence collection, logging, forensics, root-cause analysis, vulnerability management) engage once enumeration is underway and can bound its spread or remove artifacts/footholds, but the core technique (querying logs for discovery) often completes before response begins and many instances (e.g., real-time monitoring of IR itself or bulk export to adversary infrastructure) leave no containable system or eradicable artifact on the estate.
T1657detects — A.5.26's response activities (evidence collection, logging, forensic analysis, post-incident root-cause) surface and document the financial theft once it has occurred on the victim's estate, but the technique's upstream acquisition, social engineering, and external transfer steps often leave no detectable artifact inside the organization until impact is realized.
T1657prevents — A.5.26's designated competent team, containment (a), escalation/crisis invocation (c), coordination (f), and post-incident root-cause/vulnerability management (i,j) directly stop the financial-theft technique (ransomware extortion, BEC transfers, etc.) from completing its monetary objective once an incident is underway, with a bounded remainder for pre-detection thefts that succeed before response begins.
T1657recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability/weakness management in j, formal closure, and coordination) enable organizational recovery from the monetary and operational impact of financial theft incidents, though the control itself does not directly restore stolen funds.
T1657responds — A.5.26 explicitly requires a designated competent team to respond to incidents (including containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis, and vulnerability management), which directly matches the post-incident handling of financial theft events (ransomware extortion, BEC fraud, etc.) once underway; the named remainder is that some pre-impact social-engineering slices may not yet register as an 'incident'.
T1659detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause identification) can surface content injection once it has produced observable effects on the organization's estate, but the upstream/ISP-level channel compromise described in the technique often leaves no detectable artifact inside organizational boundaries.
T1659prevents — A.5.26's designated competent team and procedures for containing spread (a), coordinating with external parties (f), and identifying/managing the upstream vulnerabilities/weaknesses (j) that enable ISP-level or channel-compromised content injection directly stop the technique from reaching victims in most cases once the incident is known.
T1659responds — A.5.26's response activities (containment, evidence collection, logging, communication, coordination, closure, forensics, root-cause analysis, and managing related weaknesses) engage once content injection is underway on the victim's systems, but several core response steps (e.g., containing spread, crisis escalation, business continuity invocation) have limited or no object when the technique is upstream ISP-level or pre-compromise channel manipulation rather than an on-premises incident.
T1665detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause, vulnerability management) can surface the hiding artifacts or anomalous traffic once an incident is known, but the clause's scope is limited to post-incident response on the organization's estate and does not instrument or discover the upstream infrastructure concealment itself.
T1665prevents — A.5.26's designated competent team, containment (a), evidence collection (b), escalation/crisis invocation (c), logging (d), communication (e), coordination with external parties (f), forensic analysis (h), root-cause analysis (i), and explicit identification/management of the vulnerabilities/weaknesses that enabled the incident (j) collectively act to stop the adversary's ongoing hiding of C2 infrastructure from succeeding further once the incident is underway, with the bounded remainder being pre-detection infrastructure that evades all monitoring.
T1665responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, escalate, coordinate with external parties, close, and perform post-incident/root-cause analysis on an information security incident once underway, which directly matches responding to adversary infrastructure-hiding techniques (e.g., filtering responder traffic, evading sandboxing) that have already manifested as detectable C2 activity.
T1666prevents — A.5.26's designated competent team and procedures for containing spread, coordinating with parties, managing vulnerabilities/weaknesses that failed to prevent the incident, and invoking continuity plans directly stop the hierarchy-modification technique from completing its evasion goal in many cases (e.g. rapid detection+containment before LeaveOrganization/CreateAccount fully severs policies or hijacks subscriptions).
T1666responds — A.5.26's response activities (containment, evidence collection, logging, coordination, root-cause analysis, vulnerability management) engage once hierarchy modification is detected on the victim's estate, but several core mechanics (e.g. subscription hijacking to an external tenant or LeaveOrganization severing policies) leave little or no affected system/artifact inside the organization to contain or eradicate.
T1667detects — A.5.26's response activities (evidence collection, logging, post-incident analysis, root-cause identification) can surface the flooding once it reaches organizational mail systems or is reported, but the upstream signup and delivery occurs on external services with no required organizational vantage point.
T1667prevents — A.5.26's designated competent team, containment (a), coordination (f), and post-incident root-cause/vulnerability management (i,j) directly stop the flooding technique from continuing or recurring once detected, with the named remainder being the initial wave that lands before response begins.
T1667recovers — A.5.26's post-incident steps (analysis, root-cause identification, vulnerability/weakness management, formal closure) enable recovery of normal email operations and inbox hygiene after the flooding has occurred.
T1667responds — A.5.26 explicitly requires a designated competent team to contain, escalate, eradicate, log, communicate and formally close an information security incident once it is underway, which directly matches the definition of responds for an active email-bombing flood that has already begun disrupting operations.
T1669prevents — A.5.26's designated competent team and procedures for containing spread, coordinating with parties, and managing vulnerabilities/weaknesses that enabled the incident (including those failing to prevent it) stop most T1669 executions from achieving or sustaining initial access once underway, with a named remainder of pre-detection proximity-based connections that succeed before response activates.
T1671detects — A.5.26's response activities (evidence collection, logging, forensic analysis, post-incident root-cause, and vulnerability identification) can surface the malicious OAuth integration once it is used for access or exfiltration on the organization's estate, but the technique's creation/consent often occurs outside monitored scope on the SaaS provider or registrar-like infrastructure.
T1671prevents — A.5.26's designated competent team and explicit steps (a) contain spread, (c) escalate/invoke continuity, (f) coordinate externally, and (j) identify/manage the vulnerabilities/weaknesses that enabled the OAuth integration directly stop the persistence technique from continuing or recurring.
T1671responds — A.5.26's ten activities (contain, evidence, escalate, log, communicate, coordinate, close/record, forensics, root-cause, manage weaknesses) engage once the malicious OAuth integration is present and in use; the technique has already run to achieve persistence/exfiltration, and response bounds spread, eradicates the integration, and addresses root causes.
T1673detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause, vulnerability management) can surface the VM enumeration once it has produced observable artifacts on the monitored estate, but the pre-compromise discovery technique itself often leaves no affected system or real-time event for the incident response team to engage until a later impact stage.
T1675detects — A.5.26's monitoring, logging (d), evidence collection (b), forensic analysis (h) and post-incident root-cause steps (i) can surface the technique once it runs on the organization's ESXi estate, but the pre-compromise acquisition of admin access and many guest-VM behaviors lie outside the incident-response surface.
T1675prevents — A.5.26's incident response procedures (containment, escalation, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that enabled the incident) stop the T1675 technique from continuing or recurring once it has been detected, which satisfies `prevents` for the bulk of the technique's realized impact; the named remainder is that it does not stop the initial abuse of ESXi guest-management APIs before the incident is recognized.
T1675responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment, evidence collection, escalation, logging, communication, coordination, forensic analysis, root-cause identification, and vulnerability/weakness management — all of which directly address an in-progress T1675 abuse of ESXi services on guest VMs.
T1677detects — A.5.26 requires a designated competent team to respond to incidents (including detection via reported anomalies, evidence collection, logging, forensic analysis, and post-incident root-cause identification), which surfaces poisoned-pipeline execution once it has produced observable security effects; this is a genuine but minority slice because the control is scoped to declared incidents rather than continuous proactive detection of the build-manipulation technique itself.
T1677prevents — A.5.26's designated competent team, containment (a), forensic/root-cause analysis (h/i), vulnerability/weakness management (j), and coordination with suppliers/clients directly stop the pipeline-poisoning technique from completing or recurring when the incident is already underway or has just succeeded, which is what `prevents` asserts in the event-lane anchors; the named remainder is pre-incident insertion that has not yet triggered detection.
T1677responds — A.5.26's response activities (contain, eradicate via j, forensics, root-cause, close) engage once a poisoned pipeline runs and produces an incident on the estate (e.g. credential exfil, lateral movement, or malicious artifact shipped), but the pre-compromise Public Pipeline Execution vector (malicious PR from fork) and many indirect cases leave no on-estate artifact until downstream impact, mirroring the partial split in the T1595.002 anchor.
T1679detects — A.5.26's response activities (evidence collection, logging, forensic analysis, post-incident root cause, and vulnerability management) can surface the selective-exclusion artifact or behavior once the broader incident is underway, but the technique itself occurs pre-impact on the adversary's infrastructure with no guaranteed observable on the victim's estate.
T1679recovers — A.5.26's post-incident analysis, root-cause identification, vulnerability/weakness management (including failed controls), and formal closure directly enable recovery of organizational state and prevention of recurrence after the selective-exclusion technique has run as part of a ransomware event.
T1679responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, analyze root cause, and close an information security incident once underway, which directly matches the ransomware/malicious-payload execution context of T1679; the named remainder is that selective-exclusion technique itself is not contained or eradicated by the response steps.
T1680detects — A.5.26 requires a designated competent team to respond to incidents (including detection via reported anomalies or logs) once underway; this surfaces the reconnaissance technique in the incident-response context, with a named remainder for pre-incident discovery that never triggers an incident.
T1681prevents — A.5.26's designated competent team, containment, evidence collection, escalation, logging, communication, coordination, forensic analysis, root-cause post-incident review, and explicit identification/management of the vulnerabilities/weaknesses that enabled the incident directly stop the adversary's T1681 reconnaissance on their own campaigns from yielding actionable changes in behavior or removal of indicators.
T1683prevents — A.5.26's designated competent incident-response team, containment, coordination with external parties, and explicit step (j) to identify/manage vulnerabilities/weaknesses that failed to prevent the incident directly stops the content-generation technique from continuing or recurring once it has been detected as part of an information security incident.
T1683.002responds — A.5.26's response activities (containment, evidence collection, logging, communication, coordination, closure, forensics, root-cause analysis, and managing related weaknesses) engage once an incident using fabricated audio-visual content is underway on the organization's estate, but many pre-compromise uses (e.g., external phishing lures or account establishment) leave no affected system or artifact for the team to contain or eradicate.
T1684detects — A.5.26 explicitly requires a designated competent team to respond to incidents (including detection triggers, evidence collection, logging, forensic analysis, and post-incident root-cause identification), which surfaces social engineering techniques once they produce observable security incidents or anomalies.
T1684prevents — A.5.26's designated competent team and explicit steps (a) contain spread, (c) escalate/crisis-manage, (e-f) communicate/coordinate, and (j) identify/manage the vulnerabilities/weaknesses that enabled the social engineering directly stop the technique from completing its full unauthorized-access or payload-execution outcome in most cases once the incident is recognized.
T1684responds — A.5.26 explicitly requires a designated competent team to respond to incidents (including containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis, and vulnerability management once the social-engineering technique has already run and produced its effects), matching the `responds` verb definition.
T1684.001detects — A.5.26's response activities (evidence collection, logging, communication, coordination, post-incident analysis, root-cause identification) surface and document an impersonation campaign once it has produced an incident on the organization's estate, but the pre-compromise reconnaissance, domain acquisition, and initial social-engineering delivery occur outside the organization's visibility and produce no guaranteed internal artifact for the team to detect.
T1684.001prevents — OWNER RULING 2026-09-18, contrast pair. The impersonation succeeds at the moment the target believes the message; A.5.26 begins after somebody notices. Nothing it does reaches back to that moment. Under Mythos's 2026-09-17 definition -- `prevents` means the technique does not achieve its own effect -- A.5.26 has no purchase here at all.
T1684.001recovers — A.5.26's post-incident analysis, root-cause documentation, vulnerability/weakness management (including failed controls), and formal closure directly restore organizational state after the impersonation technique has run and caused impact (e.g., fraud or data loss), matching the recovers verb; the named remainder is that financial theft or divulged information already realized before response cannot always be undone.
T1684.001responds — OWNER RULING 2026-09-18, contrast pair, REVISED BY HIM FROM `mostly`. Data proposed `mostly` with the remainder 'it cannot undo what already happened'; the owner rejected that reasoning because it would require a RESPONSE control to PREVENT in order to reach `full`, which is the prevents question smuggled into the responds remainder. He then proposed reporting to customers and regulators as the true remainder, and WITHDREW that too: A.5.26 can plausibly be read to address notification (it requires communicating the incident to relevant internal and external interested parties, and coordinating with authorities and clients). With no remainder that is a missing piece of RESPONSE, the grade is `full`.
T1684.002detects — A.5.26's response activities (evidence collection, logging, forensic analysis, post-incident root-cause) can surface the spoofed email once delivered and reported, but the technique occurs pre-compromise on external infrastructure with no guaranteed organizational vantage until after the fact, leaving most instances unseen.
T1684.002prevents — A.5.26's designated competent team and procedures for containing, coordinating, escalating, and closing incidents (including forensic/root-cause work that can drive DMARC policy fixes) stop most spoofed emails from achieving their full social-engineering or phishing objective once detected, though the technique itself can still run and deliver to inboxes before response begins.
T1684.002responds — A.5.26 explicitly requires a designated competent team to contain, escalate, eradicate, log, communicate, close, and post-analyze an information security incident once it is underway, which matches the `responds` verb against an Email Spoofing technique that has already reached the victim inbox.
T1685detects — A.5.26's response activities (evidence collection, logging, root-cause analysis, forensic analysis, vulnerability identification) can surface the tampering or its effects once underway on the organization's estate, but pre-compromise tool disablement (especially on external or non-monitored infrastructure) and many advanced bypasses leave no observable event for the incident team to engage.
T1685prevents — A.5.26's designated competent team following defined procedures for containment, coordination, escalation, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses (including failed controls) that enabled the incident directly stops the T1685 technique from completing its full effect once underway, with a bounded remainder in pre-incident tool tampering that evades initial detection.
T1685recovers — A.5.26's post-incident analysis, root-cause identification, vulnerability/weakness management (including failed controls), formal closure, and coordination explicitly restore defensive posture and visibility after T1685 has impaired tools/telemetry, matching the recovers verb (with named remainder on immediate tool restoration before analysis completes).
T1685responds — A.5.26 explicitly requires a designated competent team to respond to incidents (once underway) via containment, evidence collection, escalation, logging, communication, coordination, forensic analysis, root-cause review, and vulnerability/weakness remediation — directly addressing an in-progress T1685 that has already impaired defensive tools, with the named remainder being any pre-containment impact already realized.
T1685.001detects — A.5.26's response activities include collecting evidence, logging response actions, forensic analysis, and post-incident root-cause work that can surface the disabling of Event Log (via anomalies, missing expected logs, or forensic artifacts), but the core technique occurs pre-compromise on the local system with no guaranteed observable event on the organization's estate until after the fact, and several listed activities (containment, escalation, coordination) have no object here.
T1685.001prevents — A.5.26's designated competent team and explicit procedures for containing spread, coordinating with parties, performing forensic/root-cause analysis, and identifying/managing the vulnerabilities/weaknesses (including failed controls) that enabled the incident directly stop the T1685.001 technique from completing or recurring once response is invoked, with the bounded remainder being the narrow pre-response window before the team acts.
T1685.001recovers — A.5.26's post-incident analysis, root-cause identification, vulnerability management (j), forensic work and formal closure enable recovery of logging capability and audit policy after the adversary's disable/modify technique has run.
T1685.001responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, analyze root cause, and formally close an already-underway incident (including forensic and post-incident steps), which directly matches the act of responding to an adversary technique that has disabled/modified Event Log; the named remainder is that the control does not itself perform the technical eradication steps (e.g. re-enabling the service).
T1685.002detects — A.5.26 requires a designated competent team to respond to incidents (including detection via reported anomalies or logs), which surfaces the logging-disabling technique once it has produced an observable incident or anomaly, though it does not guarantee proactive detection of the modification itself.
T1685.002prevents — A.5.26's designated competent team and explicit procedures for containing spread, collecting evidence, logging response activities, coordinating with parties, forensic analysis, and post-incident root-cause/vulnerability management (including controls that failed to prevent) directly stop the adversary's logging-disruption technique from completing or persisting once underway in most cases, though the control's governance/response focus leaves a bounded remainder where the technique evades initial detection before response begins.
T1685.002recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability management, formal closure, and coordination) enable recovery of logging integrity and visibility after the T1685.002 modification has already succeeded, with the named remainder being any unrecoverable pre-response data gaps.
T1685.002responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment (a), evidence collection (b), logging of response (d), escalation (c), communication (e), coordination (f), forensic analysis (h), root-cause post-incident review (i), and vulnerability/weakness remediation (j), which directly matches the containment/eradication act of `responds` against an already-executing T1685.002 technique; the named remainder is that the control cannot retroactively restore already-suppressed logs.
T1685.003prevents — A.5.26's designated competent team, containment (a), escalation (c), coordination (f), and post-incident root-cause/vulnerability management (i–j) directly stop the spoofed-UI technique from succeeding in its goal of delaying detection and response once the incident is known.
T1685.003responds — A.5.26 requires a competent team to respond to incidents (once underway) via containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis and vulnerability management — all of which directly address an in-progress T1685.003 that has already impaired visibility and delayed response, with the named remainder being any pre-containment impact already realized.
T1685.004detects — A.5.26's response activities include collecting evidence, logging response actions, forensic analysis, and post-incident root-cause work that can surface the disabling of auditd (when the incident is already known via other means), but the clause has no monitoring or detection mechanism of its own and many stealthy modifications produce no observable event on the organization's estate
T1685.004prevents — A.5.26's designated competent team responding to an incident (including containment, evidence collection, forensic analysis, root-cause identification, and managing the vulnerabilities/weaknesses that allowed it) stops the adversary technique from completing its full objective of sustained undetected activity.
T1685.004recovers — A.5.26's post-incident analysis, root-cause documentation, vulnerability/weakness management (including failed controls), and formal closure act after the technique has run to restore logging capability and address the disabled audit state.
T1685.004responds — A.5.26 explicitly requires a designated competent team to contain, log, analyze, escalate, and formally close an already-underway information security incident (including forensic and post-incident root-cause steps), which directly matches the act of responding to an adversary's T1685.004 technique once it has executed to disable/modify auditd logging.
T1685.005detects — A.5.26 requires a designated competent team to respond to incidents (including detection of the incident itself via contained evidence collection, logging, forensic analysis, and post-incident root-cause review), which surfaces the log-clearing technique once it has run.
T1685.005prevents — A.5.26's designated competent team responding to an incident (including containment, evidence collection, logging of response activities, coordination, and post-incident root-cause/vulnerability management) directly stops the adversary from successfully completing the log-clearing technique to hide intrusion activity once it is detected as an incident.
T1685.005recovers — A.5.26's post-incident analysis, root-cause identification, vulnerability management, and formal closure (with logging of response activities) enable recovery of the logging capability and visibility after the clearing technique has run, though the already-lost historical events remain unrecoverable.
T1685.005responds — A.5.26 explicitly requires a designated competent team to respond to incidents (once underway) via containment, evidence collection, logging of response activities, escalation, forensic analysis, root-cause identification, and vulnerability/weakness management — all of which directly address an already-executed T1685.005 that has erased prior logs, with the named remainder being any pre-containment loss of forensic data that cannot be restored by response alone.
T1685.006detects — A.5.26's response activities include collecting evidence, logging response actions, forensic analysis, and post-incident root-cause work that can surface the log-clearing technique once it has run and left detectable traces (e.g. missing logs or anomalies in remaining records), but the clause's core is incident handling after the fact rather than proactive detection and many log-clearing actions leave no observable event inside the organization's monitored estate.
T1685.006prevents — A.5.26's designated competent team, containment, evidence collection, logging of response activities, coordination, forensic analysis, post-incident root-cause work and explicit identification/management of the vulnerabilities/weaknesses that allowed the incident (including failed preventive controls) together stop the adversary technique from achieving its goal of permanently hiding intrusion evidence.
T1685.006recovers — A.5.26's post-incident analysis, root-cause identification, vulnerability/weakness management (item j), and formal closure directly restore the logging capability that the technique destroyed, with the named remainder being any logs already cleared before response begins.
T1685.006responds — A.5.26 explicitly requires a designated competent team to respond to incidents (once underway) via containment, evidence collection, logging of response activities, escalation, communication, coordination, forensic analysis, root-cause post-incident review, and formal closure — all of which directly address an adversary's log-clearing technique that has already run to hide intrusion evidence.
T1686detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause identification) can surface the firewall tampering once it has occurred on the organization's estate, but the technique can be executed pre-compromise on external infrastructure (e.g. network devices, unmanaged ESXi) with no organizational event to respond to.
T1686prevents — A.5.26 requires a designated competent team to respond to incidents (including containment, eradication, forensic analysis, root-cause identification, and vulnerability/weakness management that contributed to or failed to prevent the incident); this constrains the T1686 technique once it has begun by limiting its success and further impact, which is what `prevents` asserts in the event-lane anchors (see A.5.26 vs T1486 mostly and A.8.5 vs T1110.001 mostly).
T1686recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability management in j, formal closure) enable recovery of defensive posture after the firewall has been disabled/modified, though the control's primary focus is incident response rather than explicit system restoration.
T1686responds — A.5.26 explicitly requires a designated competent team to respond to incidents (once underway) via containment, evidence collection, escalation, logging, communication, coordination, forensic analysis, root-cause identification, and vulnerability/weakness management — all of which directly address an in-progress or realized T1686 technique that has already impaired defenses.
T1686.001detects — A.5.26's response activities (evidence collection, logging, root-cause analysis, forensic analysis, communicating the incident) can surface the firewall modification once it has produced observable effects on the organization's estate, but the pre-compromise technique itself occurs on the cloud provider's control plane with no guaranteed artifact inside the clause's scope.
T1686.001prevents — A.5.26's designated competent team responding to an incident (including containment, escalation, coordination, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that enabled it) stops the adversary technique from completing or recurring once it has begun, which satisfies `prevents` per the event-lane anchors; the remainder is that it does not stop the initial permission abuse that lets the technique start.
T1686.001recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability management in j, formal closure) enable recovery of the security posture after the firewall modification technique has run, with the named remainder being any already-realized impact (e.g., data exfiltration or cryptomining) that the response itself does not undo.
T1686.001responds — A.5.26 requires a competent team to respond to incidents once underway via containment, eradication, escalation, logging, coordination, closure, forensics, root-cause analysis and vulnerability management — all of which directly address an in-progress or realized T1686.001 firewall modification (contain spread, collect evidence, log actions, close the incident, fix the introduced weakness).
T1686.002detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause identification) can surface the firewall rule change or anomalous traffic once it occurs on the organization's estate, but the technique's pre-compromise acquisition of the network device (via valid accounts or exploits) and the change itself often leave no local event for the incident response team to observe.
T1686.002prevents — A.5.26's designated competent team and explicit procedures for containing spread (a), coordinating to minimize consequences (f), and managing the vulnerabilities/weaknesses that enabled the incident (j) stop the firewall-disable technique from achieving its full effect once the incident is underway, with the bounded remainder being pre-containment actions already taken by the adversary.
T1686.002recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability/weakness management in j, forensic analysis, formal closure) enable recovery of a hardened network-device firewall posture after the T1686.002 modification has already succeeded.
T1686.002responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, escalate, and formally close an already-underway incident such as firewall rule tampering that has enabled C2 or lateral movement.
T1686.003detects — A.5.26's response activities (evidence collection, logging, forensic analysis, root-cause identification) can surface the firewall modification once it has occurred on the organization's estate, but the technique's pre-compromise execution (registry changes, netsh, Control Panel) has no guaranteed observable on the target system and many steps sit outside response scope
T1686.003prevents — A.5.26's designated competent team responding to an incident (including containment, escalation, coordination, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that enabled it) stops the adversary technique from completing its full intended effect in most cases once it is underway.
T1686.003recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability management in j, formal closure) enable recovery of a hardened firewall state after the T1686.003 modification has occurred, with the named remainder being immediate containment/escalation that is not itself recovery.
T1686.003responds — A.5.26 explicitly requires a designated competent team to respond to incidents (once underway) via containment, evidence collection, escalation, logging, communication, coordination, closure, forensics, root-cause analysis, and managing the vulnerabilities/weaknesses that enabled the incident — which directly matches the act of responding to a T1686.003 technique that has already run.
T1687prevents — A.5.26's designated competent team, containment (a), coordination (f), forensic/root-cause work (h/i), and explicit patching of vulnerabilities/weaknesses that enabled the incident (j) stop most Exploitation for Defense Impairment techniques from reaching or sustaining their impairing effect on response capabilities.
T1687recovers — A.5.26's post-incident analysis, root-cause identification, vulnerability management (j), forensic work, formal closure, and lessons-learned steps act after the T1687 exploitation has already impaired defenses, restoring defensive posture and organizational readiness.
T1687responds — A.5.26 explicitly requires a designated competent team to respond to incidents (including containment, eradication, forensic analysis, root-cause identification, and vulnerability/weakness management per items a–j), which directly addresses an Exploitation for Defense Impairment technique that has already begun running and is impairing defensive components.
T1688detects — A.5.26 requires a designated competent team to respond to incidents (including detection via reported anomalies or indicators), which surfaces safe-mode abuse once it has occurred as part of incident handling.
T1688prevents — A.5.26's designated competent team responding to an incident (including containment, escalation, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that allowed it) stops the safe-mode technique from being repeatable on the same host, which is what `prevents` asserts; the named remainder is that it cannot stop the first abuse before detection occurs.
T1688recovers — A.5.26's post-incident steps (root-cause analysis, vulnerability management, formal closure, and coordination with continuity plans) enable recovery from the technique's effects once the incident is underway, with the named remainder being any unaddressed persistence mechanisms like modified BCD or registry values that survive basic response.
T1688responds — A.5.26 explicitly requires a designated competent team to contain (if spreading), eradicate, log, analyze root cause, close, and manage related vulnerabilities once an incident is underway, which directly matches responding to a T1688 technique that has already executed to disable defenses.
T1689prevents — A.5.26's designated competent team responding to an incident (including containment, evidence collection, root-cause analysis, vulnerability management in j, and post-incident fixes) stops the downgrade technique from continuing or recurring once it has begun, which satisfies `prevents` for the bulk of its post-execution lifetime; the named remainder is that it cannot stop the initial execution before detection.
T1689responds — A.5.26 explicitly requires a designated competent team to contain, eradicate, log, analyze root cause, and close an information security incident once it is underway, which directly matches the act of responding to a downgrade attack that has already executed to impair defenses or bypass controls.
T1690detects — A.5.26 requires a designated competent team to respond to incidents (including detection, containment, evidence collection, logging of activities, forensic analysis, and post-incident root-cause review), which surfaces the T1690 technique once it has run and left detectable artifacts or anomalies; however, the control is scoped to declared incidents rather than continuous proactive monitoring of all command-history tampering, leaving a large slice of silent or pre-escalation cases unreached.
T1690prevents — A.5.26's designated competent team responding to an incident (including containment, evidence collection, forensic analysis, root-cause identification, and explicit management of the vulnerabilities/weaknesses that allowed it) directly stops the adversary's ongoing technique of disabling command-history logging from continuing or recurring on the affected systems.
T1690responds — A.5.26 explicitly requires a designated competent team to respond to incidents once underway via containment (a), evidence collection (b), logging of response activities (d), escalation (c), communication (e), coordination (f), forensic analysis (h), root-cause post-incident analysis (i), and vulnerability/weakness management (j) — all of which directly address an already-executed T1690 that has impaired logging to hide commands.

Prevented OWASP Web Top 10 (2025) risks (18)

OWASP Web Top 10 (2025) risk categories this ISO control helps prevent or mitigate — our AI-authored analysis (authority llm_unverified, under review).

Direction: ← other covers this; → this covers other (F/M/P = full / mostly / partial). gov = governs / implements (a mandate, not coverage).

A01←P →P A02→P A03→P A05→P A06←P A08→P A09→P A10→P

Why these map — AI rationale (under review)

A01mitigates — Incident response (containment, evidence, escalation, forensics, root-cause analysis, and fixing the failed/weak controls) bounds the realized impact of a broken-access-control incident and prevents recurrence, but does not limit blast radius of an in-progress exploitation.
A02mitigates — Incident response (including containment, forensic analysis, root-cause review and explicit remediation of the vulnerabilities/weaknesses that enabled the incident) bounds the blast radius and downstream consequences of a realized security misconfiguration without preventing the configuration weakness itself.
A03remediates — A.5.26(j) explicitly requires identifying and managing (i.e. correcting) vulnerabilities/weaknesses that caused/contributed/failed to prevent the incident, which directly removes supply-chain failures once they have materialized as an incident; the remainder of the control is incident handling that does not itself remove the underlying dependency or pipeline defect.
A05mitigates — Incident response (containment, evidence, forensics, root-cause analysis, vulnerability management) bounds the realized impact of an injection that has already succeeded, without stopping the injection itself.
A08mitigates — Incident response (containment, evidence, forensics, root-cause analysis, vulnerability management) bounds the consequences of realized integrity failures (e.g., after a supply-chain compromise or unsigned update) without preventing the trust-without-verification defect itself.
A09mitigates — A.5.26's response activities (containment, evidence collection, logging of response, post-incident analysis, vulnerability management) bound the consequences of undetected incidents once discovered by other means, but do not address the core weakness of missing logs/alerts/integrity that allows incidents to go undetected in the first place.
A10mitigates — Incident response (containment, evidence, logging, forensic analysis, root-cause review, and explicit remediation of the vulnerabilities/weaknesses that enabled the incident) bounds the consequence of mishandled exceptions that have already occurred, but does not address the design or implementation defects that produce fail-open states or information leaks.

Control IDs, short titles and the structured attribute table (control type, CIA properties, cybersecurity-concept, operational capability, security domain) are facts from ISO/IEC 27001:2022 Annex A / ISO/IEC 27002:2022. The full implementation guidance prose lives in ISO/IEC 27002:2022 — not reproduced here. Cross-walks to NIST 800-53, NIST CSF 2.0, OWASP ASVS, CWE, MITRE ATT&CK and OWASP Web Top 10 are our own AI-authored analysis (authority llm_unverified, under review), not an ISO, NIST, MITRE or OWASP product — how ours compare.