Cyber Resilience

← ISO 27001 Annex A

A.5.24 Organizational

Information security incident management planning and preparation

AttributesCorrective C·I·A Respond Recover Governance 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-1←M IR-2←P →P IR-3←P IR-4←M →M IR-5←P IR-6←M →P IR-7←P IR-8←F →M

Why these map — AI rationale (under review)

IR-4mostlyaligns with — Both controls establish the core incident handling lifecycle—detection, analysis, containment, eradication, recovery, and post-incident review—while requiring defined roles, escalation paths, and coordination with internal and external parties.
IR-4mostlycovers — A.5.24's explicit focus on planning/preparation for quick/effective/consistent/orderly response (incl. comms) accounts for the bulk of IR-4's preparation and coordination elements, but leaves a real residual of detection/analysis/containment/eradication/recovery/lessons-learned activities that sit outside the source control's defined scope.
IR-8mostlyaligns with — Both require a documented incident response plan that addresses roles, responsibilities, communication procedures, and integration with continuity and crisis management activities.
IR-8mostlycovers — A.5.24's explicit focus on planning/preparation for quick/effective/consistent incident response (incl. communication) accounts for the bulk of IR-8's requirements for developing a plan that provides roadmap/structure/approach, but leaves a residual on organization-unique mission/size requirements not directly addressed in the 27002 text.
IR-2partialaligns with — Both emphasize training and competence requirements for personnel who will execute incident response procedures.
IR-3partialaligns with — Both stress the need to test and exercise incident response capabilities to validate procedures and identify improvements.
IR-5partialaligns with — Both require ongoing monitoring and tracking of incidents to support timely detection, classification, and management.
IR-6partialaligns with — Both address the requirement to report incidents to appropriate internal and external stakeholders within defined time frames.
IR-6partialcovers — A.5.24's planning/preparation for orderly response (incl. communication) addresses the organizational incident-response capability slice of IR-6 but leaves the specific personnel reporting obligation, defined time window, and external reporting destinations mostly uncovered.
IR-3covers — 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.
IR-5covers — 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 (27)

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).

DE.AE-08gov GV.RR-02gov ID.IM-02gov ID.IM-04gov PR.AT-02gov RS.AN-03gov RS.CO-03gov RS.MA-01gov RS.MA-03gov

Why these map — AI rationale (under review)

GV.RR-02mostlyaligns with — Both emphasize defining, communicating, and ensuring understanding of roles, responsibilities, and authorities for cybersecurity risk management activities, including incident handling.
ID.IM-04mostlyaligns with — Both require the establishment, communication, and maintenance of incident response plans and related procedures that affect operations.
RS.MA-01mostlyaligns with — Both require the organization to execute a documented incident response plan in coordination with relevant internal and external parties once an incident is declared.
PR.AT-02partialaligns with — Both require providing specialized training and ongoing professional development to personnel who perform incident response duties.
RS.AN-03partialaligns with — Both call for root-cause analysis to determine what occurred during an incident and why.
RS.CO-03partialaligns with — Both require sharing incident-related information with designated internal and external stakeholders.
GV.RR-02implements — 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.
ID.IM-04implements — A.5.24's explicit purpose is to plan and prepare for orderly incident response (including communication), which directly operationalizes the exact requirements that ID.IM-04 names for establishing, communicating, maintaining, and improving incident response plans.
PR.AT-02implements — 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.24's planning/preparation for orderly incident response (incl. analysis) directly operationalizes the RS.AN-03 outcome within the response-analysis domain, though without naming root-cause analysis explicitly
RS.CO-03implements — A.5.24's explicit focus on planning/preparation for orderly incident response (including communication) directly operationalizes the sharing of incident information required by RS.CO-03 within the response-coordination domain
RS.MA-01implements — A.5.24's planning/preparation for quick/effective/consistent incident response (incl. communication) directly operationalizes the coordinated execution of an incident response plan with third parties once declared; both sit in the same incident-response domain, though the ISO control does not name third-party coordination explicitly.

Related OWASP ASVS 5.0 requirements (11)

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.1.1←P →M V16.2.3→P V16.3.1←P V16.3.3←M →P V16.3.4←M →P V16.4.2←P V16.4.3←P →P

Why these map — AI rationale (under review)

V16.1.1mostlyaligns with — The ISO control's requirement to document logging activities, security events, and incident procedures directly supports the ASVS mandate for an inventory of logging performed at each application layer.
V16.2.3partialaligns with — Defining which systems and services receive or store incident-related logs corresponds to the ISO directive that incident management activities are only logged to documented locations.
V16.3.3partialaligns with — Establishing procedures to log attempts to bypass security controls and defined security events mirrors the ISO expectation that incident management procedures capture such events and bypass attempts.
V16.3.4partialaligns with — The ISO control's emphasis on logging incident management activities and failures supports the ASVS requirement to log unexpected errors and security control failures such as backend TLS issues.
V16.4.3partialaligns with — The ISO requirement to coordinate incident handling and communicate with internal and external parties aligns with the ASVS need to securely transmit logs to a separate system for analysis and escalation.

Related weaknesses / CWE (3)

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-400→P CWE-508→P

Why these map — AI rationale (under review)

CWE-200finds — Formal evidence handling, controlled recovery, and post-incident communication procedures limit the window during which sensitive data could be inadvertently disclosed while responders restore systems.
CWE-400finds — Pre-agreed severity-based prioritization and resource allocation during incident triage reduce the likelihood that an attacker-induced resource exhaustion will overwhelm the organization before corrective action is taken.
CWE-508finds — Incident-management planning supports detection and response to non-replicating malware incidents.

Mitigated MITRE ATT&CK techniques (1840)

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→M T1003.001→M T1003.002→M T1003.003→M T1003.004→M T1003.005→M T1003.006→M T1003.007→M T1003.008→M T1005→M T1006←M →M T1007→M T1008←M →M T1010→M T1011←M →M T1011.001→M T1012→M T1014←M →M T1016→M T1016.001→M T1016.002→M T1018→M T1020←M →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 →M T1021.008→M T1025→M T1027→M T1027.001←M →P T1027.002←M →M T1027.003←M →M T1027.004→M T1027.005←M →M T1027.006←M →M T1027.007←M →M T1027.008←M →M T1027.009←M →M T1027.010←M →M T1027.011←M →M T1027.012→M T1027.013←M →M T1027.014←M →M T1027.015→M T1027.016←M →P T1027.017←M →M T1027.018←M →M T1029←M →M T1030←M →M T1033→M 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 →M T1036.011←M →M T1036.012←M →M T1037→M T1037.001→M T1037.002→M T1037.003→M T1037.004→M T1037.005→M T1039→M T1040→M T1041←M →M T1046→M T1047→M T1048←M →M T1048.001→M T1048.002←M →M T1048.003←M →M T1049→M T1052←M →M 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 →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 →M T1069.001→P T1069.002→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 →M T1071.001←M →M T1071.002←M →M T1071.003←M →M T1071.004←M →M T1071.005←M →M T1072→M T1074←M →M T1074.001→M T1074.002←M →M T1078→M T1078.001→M T1078.002→M T1078.003←M →M T1078.004→M T1080→M T1082→M T1083→M T1087→M T1087.001→M T1087.002→M T1087.003→M T1087.004→M T1090←M →M T1090.001←M →M T1090.002←M →M T1090.003←M →M T1090.004←M →P T1091←M →M T1092←M →M T1095←M →M 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 →M T1102.002←M →M T1102.003←M →M T1104←M →M 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←M →M T1115→M T1119→M T1120→P T1123→M T1124→M T1125→M T1127←M →M T1127.001←M →M T1127.002→M T1127.003←P →M T1129→M T1132←M →M T1132.001←M →M T1132.002←M →M T1133←M →M T1134←M →M T1134.001←M →M T1134.002←M →M T1134.003←P →M T1134.004←M →M T1134.005→M T1135→M T1136→M T1136.001→M T1136.002→M T1136.003→M T1137←M →M T1137.001→M T1137.002→M T1137.003→M T1137.004→M T1137.005→M T1137.006→M T1140←M →M T1176←M →M T1176.001→M T1176.002→M T1185←M →M T1187→M T1189→M T1190→M T1195→M T1195.001→M T1195.002←M →M T1195.003→M T1197←M →M T1199←M →M T1200→M T1201→P T1202←M →M T1203→M T1204→M T1204.001→M T1204.002←M →M T1204.003←M →M T1204.004←M →M T1204.005→M T1205→M T1205.001←M →M T1205.002←M →M T1207←M →M T1210→M T1211←M →M T1212→M T1213→M T1213.001→M T1213.002→M T1213.003→M T1213.004→M T1213.005→M T1213.006→M T1216←M →M T1216.001←M →M T1216.002←M →M T1217→M T1218←M →M T1218.001→M T1218.002→M T1218.003←M →M T1218.004→M T1218.005←M →M T1218.007←M →M T1218.008←M →M T1218.009←M →M T1218.010←M →M T1218.011←M →M T1218.012←P →M T1218.013←M →M T1218.014→M T1218.015→M T1219←M →M T1219.001→M T1219.002→M T1219.003←M →M T1220←M →M T1221←M →M T1222←M →M T1222.001←M →M T1222.002←M →M T1480→P T1480.001←M →P T1480.002→M T1482→M T1484←M →M T1484.001←M →M T1484.002←M →M T1485→M T1485.001←P →M T1486→M T1489→M T1490←M →M T1491→M T1491.001→M T1491.002→M T1495→M T1496←P →M T1496.001←M →M T1496.002→M T1496.003→M T1496.004→M T1497←M →P T1497.001←M →P T1497.002←M →P T1497.003→M T1498→M T1498.001→M T1498.002←P →M T1499→M T1499.001←P →M T1499.002→M T1499.003→M T1499.004→M T1505→M T1505.001→M T1505.002→M T1505.003→M T1505.004→M T1505.005→M T1505.006→M T1518→M T1518.001→M T1518.002→M T1525→M T1526→M T1528→M T1529←M →M T1530→M T1531→M T1534→M T1535←M →M T1537←M →M T1538→M 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 →M T1543←M →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→M T1546.012←M →M T1546.013→M T1546.014→M T1546.015←M →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 T1547.013→M T1547.014→M T1547.015→M T1548←M →M T1548.001→P T1548.002←M →M T1548.003←P →M T1548.004→M T1548.005→M T1548.006←M →M T1550←F →M T1550.001←F →M T1550.002←F →M T1550.003←F →M T1550.004←F →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 →P T1553.002←M →M T1553.003←M →M T1553.004←M →M T1553.005←M →M T1553.006←M →P T1554←P →M T1555←M →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←P →M T1556.006←M →M T1556.007←M →M T1556.008←P →M T1556.009←M →M T1557→M T1557.001→M T1557.002→M T1557.003→M T1557.004→M T1558→M T1558.001→M T1558.002←M →M T1558.003→M T1558.004→M T1558.005→M T1559→M T1559.001→M T1559.002→M T1559.003→M T1560←M →M T1560.001←M →M T1560.002→M T1560.003→M T1561←M →M T1561.001←M →M T1561.002←P →M T1563→M T1563.001→M T1563.002→M T1564←M →M T1564.001→M T1564.002→M T1564.003→M T1564.004←M →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→M 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 →M T1567.003→M T1567.004→M T1568←M →M T1568.001←M →M T1568.002←M →M T1568.003←P →M T1569→M T1569.001→M T1569.002→M T1569.003→M T1570→M T1571←M →M T1572←M →M T1573←M →M T1573.001→M T1573.002→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 →M T1574.011→M T1574.012←P →M 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 T1580→M T1583→P T1583.001→M T1583.002→M T1583.003→P T1583.004→P T1583.005→M T1583.006→P T1583.007←M →P T1583.008←P →M T1584→M T1584.001→M T1584.002→M T1584.003←M →M T1584.004→M T1584.005→M T1584.006←M →M T1584.007←M →M T1584.008→M T1585→P T1585.001→P T1585.002→M T1585.003→P T1586→M T1586.001→M T1586.002→M T1586.003→M T1587.001←M T1587.002→P T1587.003→M T1588→M T1588.001←M →M T1588.002→M T1588.003→P T1588.004→M T1588.005→M T1588.006→P T1588.007→M T1589→P T1589.001→M T1589.002→P T1589.003→M T1590→M T1590.001→P T1590.002→P T1590.003→M T1590.004→M T1590.005→M T1590.006→P T1591→P T1591.001→P T1591.002→M T1591.003→P T1591.004→P T1592→P T1592.001→P T1592.002→M T1592.003→P T1592.004→M T1593→P T1593.001→M T1593.002→P T1593.003→P T1594→P T1595→M T1595.001→M T1595.002→M T1595.003→M T1596→P T1596.001→P T1596.002→P T1596.003→P T1596.005→P T1597→P T1597.001→M T1597.002→P T1598→M T1598.001→M T1598.002→M T1598.003→M T1598.004→M T1599←M →M T1599.001←M →M T1600←M →M T1600.001←P →M T1600.002→M T1601←P →M T1601.001←M →M T1601.002←M →P T1602→M T1602.001→M T1602.002→M T1606←M →M T1606.001←F →M T1606.002←M →M T1608→P T1608.001→M T1608.002→P T1608.003→P T1608.004→P T1608.005→M T1608.006→P T1609→M T1610←P →M T1611←M →M T1612←M →M T1613→M T1614→M T1614.001→M T1615→M T1619→M T1620←M →M T1621←M →M T1622←F →M T1647←P →M T1648→M T1649→M T1650→M T1651←M →M T1652→M T1653←M →M T1654→M T1657→M T1659→M T1665←M →M T1666←M →M T1667←P →M T1668←P T1669→M T1671→M T1673→M T1674→M T1675→M T1677←P →M T1678←M →M T1679←P →P T1680→M T1681←M →P T1682→P T1683→M T1683.001→M T1683.002→M T1684←M →M T1684.001→M T1684.002←M →M T1685←M →M T1685.001←M →M T1685.002←M →M T1685.003←M →M T1685.004←M T1685.005←M →M T1685.006←M →M T1686←M →P T1686.001←M →M T1686.002←M →M T1686.003←M →M T1687←P →M T1688←M →M T1689←M →M T1690←M →M

Why these map — AI rationale (under review)

T1001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by automatic means), which surfaces T1001 obfuscated C2 traffic as an incident when observed.
T1001responds — A.5.24 explicitly builds and exercises the incident response process (assessing, responding to, containing, eradicating, escalating, and learning from incidents), which directly matches the `responds` verb once a T1001-obfuscated C2 event is underway.
T1001.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by automatic means) as part of the incident management plan, which surfaces T1001.001 C2 traffic when it is treated as an observable event, but the control's scope is limited to what the organization elects to monitor per its requirements and does not mandate detection of this specific obfuscation technique.
T1001.001responds — A.5.24 explicitly builds and exercises an incident response process that contains, eradicates, escalates, coordinates, and learns from security incidents once they are underway, which directly matches the `responds` verb against an in-progress C2 technique.
T1001.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by automatic means), which surfaces hidden C2 traffic when the steganography produces observable anomalies or patterns, but the control's scope is set by organizational priorities and does not mandate instrumentation that reliably uncovers every steganographic concealment technique.
T1001.002responds — A.5.24 explicitly builds and activates an incident response process that contains, eradicates, escalates, coordinates, and learns from security incidents (including C2 traffic) once they are underway, which matches the `responds` verb; the named remainder is that steganography's concealment may delay detection and therefore the start of response.
T1001.003detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via 8.16 cross-reference), which surfaces disguised C2 traffic once it occurs, but the control is scoped to organization-chosen criteria, tools and priorities rather than mandating detection of every impersonation variant.
T1001.003responds — A.5.24 explicitly builds and exercises an incident response process that activates on detected events, contains/escalates according to incident type/category, coordinates parties, logs, handles evidence, performs root-cause, and drives improvements — all core to responding once T1001.003 C2 impersonation is underway.
T1003detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for security events/incidents, which surfaces OS credential dumping when it triggers an observable event.
T1003responds — A.5.24 explicitly builds and activates an incident response process (assessment, response/escalation per 5.26, coordination, containment to conclusion, recovery activation, lessons learned) once an incident such as credential dumping is underway.
T1003.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities that surface LSASS credential-dumping techniques (process memory access, dumps via procdump/comsvcs/WerFault, SSP modifications) once they occur.
T1003.001responds — A.5.24 explicitly builds and exercises an incident response process that includes detection, triage, analysis, response/escalation, coordination, evidence handling, root-cause, lessons learned, and controlled recovery once an incident is underway; this directly matches the `responds` verb for a credential-dumping technique that has already executed.
T1003.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including those involving credential access like SAM extraction), providing broad detection coverage once the technique runs.
T1003.002responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, escalating, coordinating, recovering, learning) once an incident is underway, which directly matches the `responds` verb for a credential-dumping technique that has already executed.
T1003.003detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities that surface the T1003.003 technique (or its artifacts) once it is underway.
T1003.003responds — A.5.24 explicitly builds and activates an incident response process that includes detection/classification of events, managing incidents to conclusion with response/escalation, coordination, root-cause analysis, and controlled recovery, which directly acts on T1003.003 once underway to contain/eradicate it.
T1003.004detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including those involving credential access like T1003.004), providing broad detection capability once the technique runs.
T1003.004responds — A.5.24 explicitly builds and activates an incident response process that contains, eradicates, escalates, coordinates, recovers in controlled fashion, logs, and learns from an already-underway incident such as credential dumping via LSA Secrets.
T1003.005detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause/post-mortem of information security events and incidents (including those involving credential access), which surfaces T1003.005 once it runs.
T1003.005responds — A.5.24 explicitly builds and activates an incident response process that includes detection, triage, analysis, response/escalation, coordination, root-cause, lessons learned and controlled recovery once an incident is underway, which directly matches the `responds` verb for an adversary technique that has already executed to obtain credentials.
T1003.006detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for information security events and incidents (including those from privileged credential access like DCSync), providing broad detection coverage once the technique runs.
T1003.006responds — A.5.24 explicitly builds and exercises an incident response process (assess/respond/learn, escalation per 5.26, coordination, controlled recovery) that activates once a DCSync event is classified as an incident, containing/eradicated the actor's foothold and bounding spread.
T1003.007detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities that surface credential-gathering techniques from procfs once they occur.
T1003.007responds — A.5.24 explicitly builds and exercises the incident response process (assessing, responding to, containing, eradicating, learning from, and coordinating on incidents), which directly matches the `responds` verb once a T1003.007 credential-gathering event has begun; the named remainder is that pure detection/classification steps sit upstream in the same clause.
T1003.008detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities that surface the technique (or its artifacts) once it runs, with the bounded remainder being fully stealthy in-memory or non-logged execution outside the defined detection scope.
T1003.008responds — A.5.24 explicitly builds and exercises the incident response process (assessing, responding to, escalating, containing, recovering from, learning from, and coordinating on incidents), which directly matches the `responds` verb once credential-dumping is underway as an information security incident.
T1005detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including those involving local data access), which surfaces the T1005 technique when it triggers an observable event.
T1005responds — A.5.24 explicitly builds and activates an incident response process that contains, eradicates, escalates, coordinates, recovers from, and learns from an information security incident once it is underway, which directly matches the `responds` verb against an adversary technique that has already executed to collect data from the local system.
T1006detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, logging and reporting of information security events and incidents (including those involving bypass of file system monitoring), but the clause's scope is set by organizational priorities and does not mandate instrumentation that would catch every possible direct-volume technique on every platform.
T1006responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, escalating, coordinating, recovering from, and learning from incidents), which directly matches the `responds` verb once T1006 volume-access activity is underway as an incident.
T1007detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (by human or automatic means), which surfaces T1007 reconnaissance when it triggers an observable event or anomaly within the defined incident management scope.
T1007responds — A.5.24 builds and readies the incident response process (roles, procedures, detection/triage/analysis/escalation, coordination, evidence handling, post-mortem) that activates once discovery activity is recognized as an incident, enabling containment/eradication of the actor and technique while underway.
T1008detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities that surface an adversary's use of fallback C2 channels once they become active.
T1008responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, escalating, and learning from incidents once underway), which directly matches the `responds` verb when a fallback channel is observed as part of an active C2 incident.
T1010detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for information security events and incidents, which can surface T1010 when it triggers an observable event meeting the organization's incident criteria, but the control's scope is limited to events that rise to incident-management thresholds rather than all stealthy discovery activity.
T1010responds — A.5.24 explicitly builds and activates an incident response process (assessing, responding to, containing, escalating, coordinating, recovering from, and learning from incidents), which directly matches the `responds` verb once T1010 enumeration is underway as part of a larger incident.
T1011detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including coordination and evidence handling), which surfaces T1011 exfiltration when observed as an anomalous event but only within the scope of the organization's defined detection processes and does not guarantee coverage of all alternative mediums.
T1011responds — A.5.24 explicitly builds and exercises an incident response process (assess, respond to, contain, eradicate, escalate, recover, learn) that activates once an exfiltration incident is underway, directly matching the `responds` verb.
T1011.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, logging and reporting of information security events and incidents (including by automatic means), which surfaces the Bluetooth exfiltration technique when it occurs within the defined scope of monitoring; the remainder is that the clause sets scope by business/security requirements rather than mandating universal Bluetooth-specific instrumentation, so an implementation can be fully conformant yet miss it (cf. A.8.16 vs T1055 anchor).
T1011.001responds — A.5.24 explicitly builds and activates an incident response process that contains, eradicates, escalates, coordinates, and learns from any realized information security incident, including one that uses Bluetooth exfiltration once underway.
T1012detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by automatic means), which surfaces the T1012 technique when it triggers observable events, but the control's scope is limited to events that meet incident criteria rather than all possible registry queries.
T1012responds — A.5.24 explicitly builds and exercises an incident response process that includes detection, triage, analysis, response/escalation, coordination, and learning once an incident is underway; querying the registry as part of discovery can trigger that process when observed as an event.
T1014detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by automatic means), which surfaces rootkit techniques once they produce observable events, but the control's scope is limited to what the organization has chosen to instrument and does not guarantee detection of stealthy kernel/boot-level rootkits that evade those mechanisms.
T1014responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, learning from, and coordinating on incidents), which directly matches the `responds` verb once a rootkit technique is already running.
T1016detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting and logging of information security events and incidents (including those arising from adversary discovery activity), providing the organization with detection capability once the technique runs.
T1016responds — A.5.24 explicitly builds and exercises an incident response process that contains, eradicates, escalates, coordinates, and learns from security incidents once they are underway, which directly matches the `responds` verb for an adversary technique that has already executed.
T1016.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (by human or automatic means), which surfaces the Internet Connection Discovery technique when performed as part of an incident or anomalous event.
T1016.001responds — A.5.24 explicitly builds and activates an incident response process (assessing, responding to, containing, eradicating, escalating, and learning from incidents once underway), which directly matches the `responds` verb for a discovery technique that has already executed on a compromised system.
T1016.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by human or automatic means) as part of the incident management plan, which would surface Wi-Fi discovery activity when it qualifies as an event or incident per the defined criteria.
T1016.002responds — A.5.24 builds and exercises the incident response process that, once an incident is underway, contains/eradicates the actor performing T1016.002 (e.g. via triage, analysis, escalation, coordination, evidence handling, and recovery activation), with the named remainder being impact already realized before containment.
T1018detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by automatic means), which surfaces T1018 activity once it occurs.
T1018responds — A.5.24 explicitly builds and exercises an incident response process that activates on detected events, contains/escalates the incident (including lateral-movement activity), coordinates parties, logs, preserves evidence, and drives post-incident learning, which matches the `responds` verb once T1018 has begun.
T1020detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities that surface automated exfiltration (and its companion exfil techniques) once underway.
T1020responds — A.5.24 explicitly builds and exercises an incident response process that activates on detected events, contains/eradicates the incident (including automated exfiltration), escalates, coordinates parties, logs, preserves evidence, and feeds lessons back — all core to `responds` once the technique is underway; the named remainder is that pure-prevention or post-impact recovery sit in other controls.
T1020.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via automatic means), which surfaces the traffic duplication technique when it triggers an observable event.
T1020.001responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, escalating, coordinating, recovering from, and learning from incidents), which directly acts on an already-underway T1020.001 exfiltration event once detected.
T1021detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for information security events and incidents, which directly surfaces T1021 remote-service logins when they qualify as reportable events.
T1021responds — A.5.24 explicitly builds and exercises the incident response process (assessing, responding to, escalating, containing, recovering from, and learning from incidents), which directly acts on T1021 once the remote-service technique is underway.
T1021.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by automatic means), plus logging and root-cause activities that surface RDP-based lateral movement when it occurs.
T1021.001responds — A.5.24 explicitly builds and activates an incident response process (assessing, responding to, escalating, containing via crisis/continuity plans, coordinating parties, and learning) once an RDP-based incident is underway, matching the `responds` verb; mostly because the control's scope is limited to declared incidents rather than every possible RDP session.
T1021.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including coordination and post-incident root-cause work), which surfaces SMB/Windows Admin Shares lateral movement when it occurs; the remainder is that detection depends on chosen scope, tools, and event criteria rather than mandating universal coverage of this technique.
T1021.002responds — A.5.24 explicitly builds and exercises incident response processes (assessing, responding to, containing, eradicating, escalating, coordinating, recovering from, and learning from incidents), which directly matches the `responds` verb once the SMB lateral-movement technique is underway.
T1021.003detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for information security events and incidents (including those using valid accounts and remote execution like DCOM), providing broad coverage once the technique is in flight.
T1021.003responds — A.5.24 explicitly builds and exercises the incident response process (assessing, responding to, escalating, coordinating, recovering from, and learning from incidents), which directly contains and eradicates an in-progress DCOM-based lateral-movement technique once detected.
T1021.004detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by automatic means), plus logging and root-cause activities that surface SSH-based remote access by valid accounts once underway.
T1021.004prevents — A.5.24 requires establishing incident management processes, detection/monitoring capabilities, classification, response/escalation procedures, and coordination that can stop an ongoing SSH session (e.g. via kill, network isolation, or credential revocation) before the adversary completes post-login actions, but this is reactive after the login has already succeeded and does not stop the initial use of valid accounts over SSH.
T1021.004responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, escalating, and learning from incidents including those using valid accounts over SSH), which matches the `responds` verb once the technique is underway.
T1021.005detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for information security events and incidents, which surfaces VNC-based remote control (including anomalous use of valid accounts or brute-force attempts) once it occurs.
T1021.005responds — A.5.24 explicitly builds and exercises the incident response process (assess, respond to, contain, eradicate, escalate, recover, learn) that activates once a VNC-abuse event is underway, matching the `responds` verb definition.
T1021.006detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for information security incidents and events, which directly surfaces WinRM-based lateral movement when it occurs.
T1021.006responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, escalating, coordinating, recovering from, and learning from incidents), which directly acts on an in-flight T1021.006 execution once detected.
T1021.007detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces the T1021.007 technique when it triggers an observable event, but the control's scope is limited to events that meet the organization's defined criteria and does not mandate detection of all possible instances of this technique.
T1021.007responds — A.5.24 explicitly builds and exercises an incident response process (assess, respond to, escalate, contain, recover, learn) that activates once an incident — including adversary use of valid cloud accounts via T1021.007 — is underway, matching the `responds` verb definition.
T1021.008detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including those involving cloud infrastructure access), but the control is scoped to organization-defined criteria, processes, and competent personnel rather than mandating universal coverage of every possible T1021.008 instance.
T1021.008responds — A.5.24 explicitly builds and activates an incident response process (assessing, responding to, escalating, containing, recovering from, and learning from incidents) that directly applies once an adversary has leveraged valid accounts for direct cloud VM console access, with only the pre-incident planning slice outside this verb.
T1025detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for information security incidents and events, which can surface the T1025 technique once it has run on removable media, but only as part of broader incident handling rather than dedicated detection of the collection activity itself.
T1025responds — A.5.24 explicitly builds and activates an incident response process (assessing, responding to, containing, eradicating, escalating, recovering from, and learning from incidents) that directly acts on T1025 once it has run and data collection from removable media is underway.
T1027detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including post-incident root-cause analysis), which surfaces obfuscated payloads or commands once they trigger observable events, but does not guarantee detection of the obfuscation itself before or without an incident.
T1027responds — A.5.24 explicitly builds and exercises the incident response process (assess, respond to, contain, eradicate, escalate, recover, learn) once an obfuscated payload or command is treated as an incident, with only the pre-detection boundary as named remainder
T1027.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by automatic means), which surfaces the binary-padding technique when it produces observable anomalies or is caught by configured detection tooling, but the control's scope is set by organizational priorities and does not mandate coverage of every evasion method or large-file scanning gap.
T1027.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by automatic means), which surfaces packed binaries as anomalous artifacts or during incident triage, but the clause is scoped to incident management rather than mandating broad proactive detection mechanisms for this specific technique.
T1027.002responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, learning from, and coordinating on incidents), which directly matches the `responds` verb once a packed binary has executed and triggered detection as an information security incident.
T1027.003detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means) as part of the incident management plan, which surfaces steganography use once it produces observable events, but does not mandate any specific detection capability tuned to hidden data in media.
T1027.003responds — A.5.24 explicitly builds and activates an incident response process that includes detection/classification/analysis of events, response/escalation to incidents (including coordination and controlled recovery), which directly acts on a steganography technique once it has run and is underway.
T1027.004detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by automatic means), which surfaces the delivery and/or compilation activity once it occurs within the organization's scope, but does not guarantee coverage of all delivery vectors, obfuscated payloads, or pre-execution source code on every platform.
T1027.004responds — A.5.24 explicitly builds and exercises an incident response process (assess, respond to, learn from incidents; manage to conclusion with escalation, recovery, root-cause, lessons learned) that activates once the compiled-after-delivery payload executes as an incident.
T1027.005detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by automatic means), which surfaces the presence of a modified tool that evades prior detection; this is a genuine but bounded slice of the technique because the control's detection is scoped to events/incidents that meet the organization's classification criteria rather than guaranteeing discovery of every indicator-removal action.
T1027.005responds — A.5.24 explicitly builds and exercises the incident response process (assessing, responding to, containing, eradicating, escalating, and learning from incidents), which directly matches the `responds` verb once the adversary's indicator-removal technique has already run and been detected.
T1027.006detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by automatic means), which surfaces HTML smuggling when observed as part of an incident but does not mandate instrumentation that would reliably catch the technique in benign HTML/JS before or during delivery.
T1027.006responds — A.5.24 explicitly builds and exercises an incident response process (assess, respond to, learn from incidents; manage to conclusion with escalation, recovery, root-cause, lessons learned) that activates once an HTML-smuggling delivery has produced a detectable event or incident.
T1027.007detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by automatic means), which surfaces the runtime behavior of dynamic API resolution as part of incident detection and triage, but does not guarantee coverage of the specific static-obfuscation or hashing artifacts in all cases.
T1027.007responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, learning from, and coordinating on incidents), which directly matches the `responds` verb once the T1027.007 technique has executed and is underway.
T1027.008detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces stripped-payload techniques when they produce observable anomalies or are caught during incident triage/analysis, but the control's scope is limited to events that have already been triggered rather than proactively scanning for stripped artifacts in all payloads.
T1027.008responds — A.5.24 explicitly builds and activates an incident response process that includes detection, analysis, classification, response/escalation, root-cause, lessons-learned and controlled recovery once a stripped-payload incident is underway, matching the `responds` verb; the named remainder is that the technique's pre-response evasion of static analysis is not itself undone by response actions.
T1027.009detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including logging and root-cause work), which surfaces embedded-payload techniques once they trigger observable events, but the control is silent on any specific detection mechanisms or coverage depth for this concealment method.
T1027.009responds — A.5.24 explicitly builds and exercises the incident response process (assessing, responding to, containing, eradicating, learning from, and coordinating on incidents), which directly matches the `responds` verb once an embedded-payload technique has executed and produced detectable malicious effect.
T1027.010detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (by human or automatic means) as core incident management capabilities, which surfaces command obfuscation techniques once they execute as observable events.
T1027.010responds — A.5.24 explicitly builds and activates an incident response process that assesses, contains, eradicates, escalates, coordinates, logs, and learns from security incidents (including those using obfuscated commands), once the technique has already executed.
T1027.011detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause/post-mortem of incidents (including those using fileless storage as a concealment technique), but the control is scoped to incident management after an event is recognized rather than broad proactive detection of the storage technique itself.
T1027.011responds — A.5.24 explicitly builds and exercises an incident response process (assess, respond to, learn from incidents; manage to conclusion with escalation, containment via continuity/crisis plans, root-cause, lessons learned) that activates once fileless storage is part of a detected incident, exactly matching the `responds` verb.
T1027.012detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (by human or automatic means) plus logging and root-cause activities, which surfaces LNK Icon Smuggling when it triggers an observable event but does not guarantee coverage of every stealthy or post-compromise use of the technique.
T1027.012responds — A.5.24 explicitly builds and exercises the incident response process (assess, respond to, learn from incidents; manage to conclusion with escalation, recovery, root-cause, lessons learned) once an event is underway, which directly matches the post-compromise use of LNK Icon Smuggling to download further payloads.
T1027.013detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including those involving malicious files), but this is scoped to the incident management process rather than mandating specific detection of the obfuscation technique itself across all file artifacts.
T1027.013responds — A.5.24 explicitly builds and exercises an incident response process that includes detection/classification/analysis of events, managing incidents to conclusion with response/escalation, root-cause/post-mortem, and lessons-learned improvements once an obfuscated-file technique is underway.
T1027.014detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by automatic means), which surfaces polymorphic code when observable as part of an incident but does not guarantee detection of the technique itself in all cases or before impact.
T1027.014responds — A.5.24 explicitly builds and activates an incident response process (assessing, responding to, containing, eradicating, escalating, and learning from incidents) that directly engages once polymorphic-code malware has executed and is detected as an information security incident.
T1027.015detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by automatic means), which surfaces the use of compression for obfuscation when it is observable as part of an incident, but the control is scoped to incident management rather than continuous or preventive detection of the technique itself.
T1027.015responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, learning from, and coordinating on incidents), which directly matches the `responds` verb once a compressed-payload technique has executed and is underway.
T1027.016detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by automatic means), which surfaces the presence of junk-code-obfuscated malware as part of incident detection and triage, but does not guarantee detection of the obfuscation technique itself.
T1027.017detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (by human or automatic means) as part of the incident management plan, which would surface SVG smuggling when treated as an event; this is a genuine but bounded slice because the control sets scope by organisational priorities rather than mandating universal detection of every possible smuggling vector.
T1027.017responds — A.5.24 explicitly builds and exercises an incident response process that includes detection, triage, analysis, escalation, coordination, evidence handling, root-cause review and controlled recovery once an incident is underway, which directly matches the `responds` verb against any delivered technique such as SVG smuggling.
T1027.018detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by automatic means) as part of the incident management plan, which surfaces the use of invisible Unicode as an anomalous or malicious event once it occurs.
T1027.018responds — A.5.24 explicitly builds and exercises an incident response process that includes detection, triage, analysis, response/escalation, coordination, evidence handling, root-cause, lessons learned, and controlled recovery once an incident is underway; this directly matches the `responds` verb for a Unicode-obfuscation technique that has already executed.
T1029detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including by automatic means), which surfaces scheduled exfiltration when it triggers as an observable event.
T1029responds — A.5.24 explicitly builds and activates an incident response process that contains, eradicates, escalates, coordinates, and learns from an information security incident once it is underway, which directly matches the `responds` verb for a scheduled exfiltration that has already begun.
T1030detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via 8.16 cross-reference), which surfaces the low-and-slow exfiltration technique once it produces observable network or host artifacts; the remainder is that the control's scope is set by organizational requirements and does not mandate instrumentation depth sufficient to catch every stealthy chunking implementation.
T1030responds — A.5.24 explicitly builds and exercises an incident response process that includes detection, triage, analysis, escalation, coordination, containment via response/escalation (5.26), and learning — all of which act on an exfiltration event once underway to bound its spread and remove the actor's foothold.
T1033detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces the T1033 discovery activity when it qualifies as an event or incident per the plan's criteria, but only for the subset of executions that cross that threshold rather than all instances.
T1033responds — A.5.24 explicitly builds and activates an incident response process (assessing, responding to, containing, eradicating, escalating, and learning from incidents once underway), which directly matches the `responds` verb for a discovery technique that has already executed.
T1036detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by automatic means), which surfaces masquerading when it is treated as or triggers an observable event, but the control's scope is set by organizational priorities, criteria and chosen detection methods rather than mandating coverage of every masquerading artifact or technique.
T1036responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, escalating, coordinating, recovering from, and learning from incidents), which directly acts on a T1036 event once underway to contain/eradicate it per the event-lane definition of responds.
T1036.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by automatic means), which surfaces the anomalous invalid-signature files once they appear; the remainder is that the control does not mandate signature-validation sensors or depth of analysis that would catch every mimicry case.
T1036.001responds — A.5.24 explicitly builds and exercises an incident response process that includes detection, triage, analysis, classification, response/escalation, coordination, recovery, root-cause, lessons-learned and evidence handling once an incident is underway; T1036.001 is a post-compromise technique whose artifacts (masquerading binaries) are directly visible to those incident-management activities.
T1036.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (by human or automatic means) as part of the incident management plan, which surfaces the anomalous disguised filename as an event; this is a genuine but minority slice because the control is scoped to post-event incident handling rather than proactive file-system or email scanning that would catch the RTLO before user execution.
T1036.002responds — A.5.24 explicitly builds and exercises an incident response process that assesses, contains, eradicates, escalates, coordinates, logs, and learns from security incidents once they are underway, which directly matches the `responds` verb for an RTLO-based social-engineering or execution event.
T1036.003detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including logging and root-cause work), which surfaces renamed-utility evasion when the rename produces observable anomalies, but the control's scope is set by organizational priorities and does not mandate coverage of every possible rename variant or path-based masquerade.
T1036.003responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, learning from, and coordinating on incidents), which directly matches the `responds` verb once the rename-and-evade technique has executed and produced a detectable security incident.
T1036.004detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces masquerading of tasks/services as part of incident detection/triage; this is a genuine but bounded slice because the control's scope is set by organizational priorities, event criteria and chosen monitoring (per cross-references to 8.15/8.16), not mandating coverage of every possible masquerade artifact.
T1036.004responds — A.5.24 explicitly builds and activates an incident response process that assesses, contains, eradicates, escalates, coordinates, logs, and learns from incidents (including those using masquerading to persist or evade), once the technique has already run.
T1036.005detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces the anomalous resource name/location when it is treated as an event.
T1036.005responds — A.5.24 explicitly builds and exercises an incident response process that contains, eradicates, escalates, coordinates, and learns from incidents (including those using masquerading to evade detection), once the technique has already run and produced observable events or artifacts.
T1036.006detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (by human or automatic means) as part of the incident management plan, which would surface this technique when observed as an anomalous event.
T1036.006responds — A.5.24 explicitly builds and exercises an incident response process (assess/respond/learn, escalation per 5.26, coordination, recovery activation) that activates once a disguised executable is executed or reported as an event, containing/eradicated the incident in flight.
T1036.007detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces the double-extension masquerading technique when it occurs as part of an incident, but the control is scoped to incident management rather than continuous or preventive detection of every instance.
T1036.007responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, learning from, and communicating about incidents), which directly matches the `responds` verb once a double-extension payload has executed and become an observable security incident.
T1036.008detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means) as part of the incident management plan, which surfaces masquerading activity once it occurs; this is bounded by the control's governance/planning focus rather than mandating specific detection mechanisms for file-signature or extension anomalies.
T1036.008responds — A.5.24 explicitly builds and exercises an incident response process (assess/respond/learn, escalation per 5.26, coordination, controlled recovery, root-cause, lessons learned) that activates once a masqueraded payload has been delivered and is in play as an information security incident.
T1036.009detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by automatic means), which surfaces the PPID-spoofing/double-fork technique when it occurs, but the clause's scope is set by organizational priorities and does not mandate instrumentation depth sufficient to catch every stealthy variant on every platform.
T1036.009responds — A.5.24 explicitly builds and exercises an incident response process (assess/respond/learn, escalation per 5.26, coordination, controlled recovery) that activates once an incident is recognized, containing/eradicating the actor's foothold and behavior even after the PPID-break technique has run.
T1036.010detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including post-incident root-cause and lessons-learned steps), which surfaces masquerading account names once they trigger observable events, but the control is scoped to chosen business/security requirements and does not mandate instrumentation that would catch every possible masquerade.
T1036.010responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, escalating, coordinating, recovering, and learning from incidents), which directly matches the `responds` verb once the masquerading account technique has run and is underway.
T1036.011detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, logging and reporting of information security events and incidents (including by automatic means), which surfaces anomalous process arguments or masquerading behavior once it occurs.
T1036.011responds — A.5.24 explicitly builds and exercises the incident response process (assessing, responding to, containing, eradicating, escalating, coordinating, recovering from, and learning from incidents), which directly matches the `responds` verb once the T1036.011 technique has executed and is underway.
T1036.012detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by automatic means), which surfaces anomalous or spoofed browser fingerprinting traffic when it matches defined event/incident criteria, but the control's scope is limited to events that meet the organization's incident thresholds rather than all instances of the technique.
T1036.012responds — A.5.24 explicitly builds and activates an incident response process (assessing, responding to, containing, eradicating, escalating, coordinating, and learning from incidents once underway), which directly matches the `responds` verb for a detected T1036.012 masquerading event; the named remainder is that some stealthy fingerprinting may complete its evasion before response begins.
T1037detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for security events and incidents, which surfaces T1037 execution (boot/logon script activity) once it occurs.
T1037responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, escalating, and learning from incidents) that activates once a boot/logon script persistence technique is detected as an information security incident.
T1037.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for security events/incidents (including those establishing persistence), but the control is scoped by organizational priorities, event criteria, and chosen instrumentation rather than mandating detection of every possible logon-script technique.
T1037.001responds — A.5.24 explicitly builds and activates an incident response process (assessing, responding to, containing, eradicating, escalating, and learning from incidents) that directly acts on a persistence technique once it has executed at logon.
T1037.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including via human or automatic means), which surfaces the login-hook persistence technique once it has been set or triggered.
T1037.002responds — A.5.24 explicitly builds and exercises an incident response process that includes detection, triage, analysis, response/escalation, coordination, recovery activation, root-cause, lessons-learned and evidence handling once an incident is underway, which directly matches the act of responding to a realized T1037.002 persistence technique.
T1037.003detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities that surface the execution or anomalous use of network logon scripts as an incident
T1037.003responds — A.5.24 explicitly builds and exercises an incident response process that includes detection, triage, analysis, escalation, containment via response procedures, coordination, recovery activation, root-cause review and lessons-learned improvements once an incident is underway; this directly matches the `responds` verb for a persistence technique that has already executed at logon.
T1037.004detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including those from persistence mechanisms like modified RC scripts), but the control's scope is set by organizational priorities and does not mandate universal coverage of every possible technique or platform.
T1037.004responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, escalating, coordinating, recovering from, and learning from incidents), which directly matches the `responds` verb once the RC-script persistence technique has executed and been detected.
T1037.005detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for security events/incidents, which surfaces the technique when it triggers (or its artifacts are observed), but only within the scope of events the organization has instrumented and prioritized.
T1037.005responds — A.5.24 explicitly builds and exercises an incident response process that includes detection, triage, analysis, response/escalation, coordination, recovery, root-cause, lessons-learned and evidence handling once an incident is underway, which directly matches the `responds` verb for a persistence technique that has already executed at boot.
T1039detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including those involving data access from network shares), which surfaces the T1039 technique when it runs.
T1039responds — A.5.24 explicitly builds and activates an incident response process (assessing, responding to, containing, eradicating, escalating, and learning from incidents) that directly acts on T1039 once it is underway as a detected information security incident.
T1040detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including those from network activity), which surfaces T1040 when it occurs.
T1040responds — A.5.24 explicitly builds and activates an incident response process that assesses, contains, eradicates, escalates, coordinates, and learns from realized incidents (including those surfaced by network sniffing), with only the post-containment impact boundary left for recovers.
T1041detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for information security incidents and events, which directly surfaces T1041 exfiltration when performed over a monitored C2 channel.
T1041responds — A.5.24 explicitly builds and exercises an incident response process (assess, respond to, learn from incidents; manage to conclusion with escalation, controlled recovery, root-cause, lessons learned) that directly acts on an exfiltration event once underway.
T1046detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (by human or automatic means), which surfaces network service discovery activity once it occurs.
T1046responds — A.5.24 explicitly builds and exercises an incident response process that activates on detected events, contains/escalates the actor performing network service discovery, coordinates eradication, and learns from it once the technique is underway.
T1047detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including those using WMI for execution or T1490), providing broad detection capability once the technique runs.
T1047responds — A.5.24 explicitly builds and exercises the incident response process (assessing, responding to, containing, eradicating, escalating, coordinating, recovering, and learning from incidents), which directly matches the `responds` verb once a T1047-based event is underway.
T1048detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including those involving data exfiltration), providing broad detection coverage across the technique's platforms and methods, with only a bounded remainder for fully stealthy or out-of-scope events.
T1048responds — A.5.24 explicitly builds and exercises the incident response process (assessing, responding to, containing, eradicating, escalating, and learning from incidents), which directly acts on an exfiltration event once underway per the event-lane definition of responds.
T1048.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security incidents and events (including those arising from data exfiltration), providing broad detection coverage of the technique once it runs.
T1048.001responds — A.5.24 explicitly builds and activates an incident response process (assessing, responding to, escalation per 5.26, containment via crisis/continuity activation, recovery, root-cause, lessons) once an exfiltration incident is underway, matching the `responds` verb; mostly because the control is scoped to declared incidents rather than every stealthy exfil event.
T1048.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including those tied to data exfiltration), providing broad detection capability once the technique is underway.
T1048.002responds — A.5.24 explicitly builds and exercises the incident response process (assessing, responding to, containing, eradicating, escalating, coordinating, recovering, and learning from incidents), which directly acts on an exfiltration event once underway.
T1048.003detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including those tied to data exfiltration), providing broad detection capability once the technique is underway.
T1048.003responds — A.5.24 explicitly builds and exercises an incident response process that includes detection, triage, analysis, response/escalation, coordination, recovery, root-cause, and lessons-learned steps once an exfiltration event is underway, directly matching the `responds` verb.
T1049detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (by human or automatic means), which surfaces T1049 execution as an observable event during the discovery phase.
T1049responds — A.5.24 explicitly builds and activates an incident response process (including detection, triage, analysis, response/escalation per 5.26, coordination, and recovery) that acts on an already-underway discovery technique such as T1049 once it is observed as an event or incident.
T1052detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for information security events and incidents, which surfaces physical-medium exfiltration when it triggers an observable event inside the defined incident-management scope.
T1052responds — A.5.24 explicitly builds and exercises incident response processes that contain, eradicate, escalate and recover from an already-underway information security incident, which directly matches the `responds` verb once T1052 exfiltration has begun.
T1052.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including via human or automatic means), which surfaces T1052.001 exfiltration activity when observed, but only within the scope of the organization's defined incident management processes and does not mandate specific USB-focused detection mechanisms.
T1052.001responds — A.5.24 explicitly builds and exercises the incident response process (assess, respond to, contain, eradicate, escalate, recover, learn) once an incident is underway, which directly matches the `responds` verb for an exfiltration event that has already begun.
T1053detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for security events/incidents, which surfaces scheduled-task abuse when it triggers observable events, but the clause's scope is set by organizational priorities and does not mandate instrumentation that reliably catches all stealthy or pre-execution scheduling on every platform.
T1053responds — A.5.24 explicitly builds and exercises an incident response process (assess/respond/learn, escalation, containment via crisis/continuity activation, root-cause, lessons-learned) that activates once a scheduled-task technique is detected as an incident
T1053.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for information security events and incidents (including those arising from scheduled tasks), which surfaces the technique once it runs.
T1053.002responds — A.5.24 explicitly builds and exercises the incident response process (assessing, responding to, containing, eradicating, escalating, and learning from incidents), which directly matches the `responds` verb once the at-scheduled malicious code has executed and become an incident.
T1053.003detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, logging and reporting of information security events and incidents (including by automatic means), which surfaces cron-based persistence when it manifests as an observable event, but the control's scope is set by organisational priorities and does not mandate instrumentation that guarantees detection of every possible cron abuse.
T1053.003responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, escalating, and learning from incidents) that activates once a scheduled malicious cron job is detected as an information security incident.
T1053.005detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for security events/incidents, which surfaces scheduled-task abuse when it triggers observable events, but the control's scope is set by organizational priorities and does not mandate instrumentation that reliably catches all stealthy/hidden variants or creation methods.
T1053.005responds — A.5.24 explicitly builds and activates an incident response process that assesses, contains, eradicates, escalates, coordinates, and learns from incidents (including those using scheduled tasks for persistence/lateral movement/execution), once the technique has already run.
T1053.006detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for security events/incidents, which surfaces the systemd-timer technique when it triggers observable events, but the control's scope is set by organizational priorities and does not mandate instrumentation that would catch all stealthy or pre-execution timer installations.
T1053.006responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, escalating, containing, recovering from, and learning from incidents), which directly matches the `responds` verb once a systemd-timer persistence technique has executed and is underway.
T1053.007detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for security events/incidents (including via human or automatic means), which surfaces this technique when it triggers an observable incident but does not mandate coverage of all container-orchestration-specific indicators or pre-incident detection.
T1053.007responds — A.5.24 explicitly builds and activates an incident response process (assessing, responding to, containing, escalating, coordinating, recovering from, and learning from incidents), which directly acts on a T1053.007 technique once it has executed and is underway.
T1055detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by automatic means), which surfaces process injection when it occurs as an observable event.
T1055responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, escalating, and learning from incidents), which directly matches the `responds` verb once T1055 is underway; the named remainder is that some stealthy injections may complete their objective before response is triggered.
T1055.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for information security events and incidents (including those from process injection techniques), providing broad detection coverage with only a bounded remainder for unmonitored edge cases.
T1055.001responds — A.5.24 explicitly builds and activates an incident response process (assessing, responding to, escalating, containing via crisis/continuity activation, controlled recovery, root-cause, lessons learned) once an incident is underway, which directly matches the `responds` verb for a technique already running.
T1055.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (by human or automatic means) as part of the incident management plan, which surfaces T1055.002 in flight as an observable technique.
T1055.002responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, escalating, coordinating, recovering from, and learning from incidents), which directly matches the `responds` verb once a PE-injection technique is underway.
T1055.003detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means) as part of the incident management plan, which surfaces T1055.003 when observed but does not mandate instrumentation depth or coverage of all in-process behaviors.
T1055.003responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, learning from incidents) that activates once the hijacking technique is underway, matching the `responds` verb definition.
T1055.004detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by automatic means) as part of the incident management plan, which surfaces APC injection when observed as an event, but the control is governance-oriented and does not mandate specific detection mechanisms or instrumentation depth for this technique.
T1055.004responds — A.5.24 explicitly builds and exercises the incident response process (assessing, responding to, containing, eradicating, escalating, coordinating, recovering, and learning from incidents), which directly matches the `responds` verb once an in-flight APC injection technique is underway.
T1055.005detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means) as part of building incident management capability, which surfaces T1055.005 when observed but does not mandate instrumentation depth or coverage of in-process memory manipulation.
T1055.005responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, escalating, coordinating, recovering, and learning from incidents), which directly matches the `responds` verb once a T1055.005 injection event is underway.
T1055.008detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including via human or automatic means), which surfaces ptrace-based process injection when observed, but the control's scope is set by organizational priorities and does not mandate instrumentation depth that would guarantee catching all variants of this Linux-specific technique.
T1055.008responds — A.5.24 explicitly builds and exercises an incident response process (assess/respond/learn, escalation, containment via 5.26 cross-ref, controlled recovery, root-cause, lessons) that activates once a ptrace injection is recognized as an incident, exactly matching the `responds` verb.
T1055.009detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means) as part of the incident management plan, which surfaces the technique once it produces observable events, but the control's scope is set by organizational priorities and does not mandate instrumentation that necessarily catches /proc-based memory injection in all cases.
T1055.009responds — A.5.24 explicitly builds and exercises an incident response process that includes detection, triage, analysis, response/escalation, coordination, evidence handling, root-cause, lessons learned, and controlled recovery once an incident is underway, which directly matches the `responds` verb for a Linux proc-memory injection that has already executed.
T1055.011detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by automatic means) as part of the incident management plan, which surfaces EWM injection when observed but does not mandate instrumentation depth sufficient to catch all variants or instances.
T1055.011responds — A.5.24 explicitly builds and exercises the incident response process (assess, respond to, learn from incidents; manage to conclusion with escalation, containment via crisis/continuity activation, root-cause, lessons learned) once an in-flight technique such as EWM injection has produced a detectable event.
T1055.012detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, logging and reporting of information security events and incidents (including by automatic means), which surfaces process hollowing when it is treated as an incident, but the control is governance-oriented and does not mandate any specific detection mechanisms or instrumentation that would reliably catch the technique.
T1055.012responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, escalating, and learning from incidents) that activates once a process-hollowing technique is detected as an information security incident.
T1055.013detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means) as part of the incident management plan, which surfaces the technique once it produces observable events.
T1055.013responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, learning from incidents, escalation, coordination, evidence handling, root-cause) that activates once a T1055.013 execution is underway or detected, exactly matching the `responds` verb; the named remainder is that the control does not itself perform the on-the-wire or memory-level containment steps.
T1055.014detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (by human or automatic means) as part of the incident management plan, which surfaces VDSO hijacking once it occurs as an anomalous event, but the control's scope is limited to what the organization chooses to instrument and does not mandate coverage of this specific low-level Linux technique.
T1055.014responds — A.5.24 explicitly builds and exercises the incident response process (assessing, responding to, containing, eradicating, escalating, and learning from incidents once underway), which directly matches the `responds` verb for a technique that has already executed in a live process.
T1055.015detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means) as part of the incident management plan, which surfaces ListPlanting when observed as an anomalous event but does not mandate instrumentation depth sufficient to catch all stealthy in-process variations.
T1055.015responds — A.5.24 explicitly builds and exercises the incident response process (assess, respond to, contain, eradicate, escalate, recover, learn) once an information security incident is underway, which directly matches the `responds` verb against a technique that has already executed inside a hijacked process.
T1056detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for information security events and incidents, which directly surfaces T1056-style input-capture techniques once they execute.
T1056responds — A.5.24 explicitly builds and exercises an incident response process (assess, respond to, contain, eradicate, escalate, recover, learn) that activates once an input-capture incident is underway, matching the `responds` verb; the named remainder is that the control stops at procedural readiness and does not itself perform the on-the-wire containment or eradication steps.
T1056.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by automatic means), which surfaces keylogging techniques once they are in flight.
T1056.001responds — A.5.24 explicitly builds and activates an incident response process (assess/respond/learn, escalation per 5.26, coordination, controlled recovery) once an incident is underway, directly addressing a realized keylogging event per its defined scenarios and procedures.
T1056.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces GUI input capture techniques when observed as anomalous events.
T1056.002responds — A.5.24 explicitly builds and activates an incident response process (assess/respond/learn, escalation per 5.26, coordination, controlled recovery) that acts on an already-underway GUI Input Capture event once detected as an incident.
T1056.003detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for information security events and incidents, which directly surfaces this post-compromise or initial-compromise credential-capture technique when it triggers an observable event.
T1056.003responds — A.5.24 explicitly builds and exercises the incident response process (assessing, responding to, containing, eradicating, escalating, and learning from incidents), which directly matches the `responds` verb once the web-portal credential-capture technique is underway.
T1056.004detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (by human or automatic means) as part of the incident management plan, which surfaces credential API hooking when it triggers observable events.
T1056.004responds — A.5.24 explicitly builds and exercises an incident response process that contains, eradicates, escalates, coordinates, recovers from, and learns from security incidents once they are underway, which directly matches the `responds` verb against an in-progress credential-hooking technique.
T1057detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (by human or automatic means), which surfaces process-discovery activity when it qualifies as (or triggers) an event or incident.
T1057responds — A.5.24 explicitly builds and activates an incident response process that assesses, contains, eradicates, escalates, coordinates, and learns from incidents (including those surfaced by discovery activity), once the technique has already run.
T1059detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces the use/abuse of interpreters as an incident; this is a genuine but bounded slice of the broad technique that can also occur without triggering an event or crossing monitored boundaries.
T1059responds — A.5.24 explicitly builds and activates an incident response process (assessing, responding to, escalating, containing, recovering from, and learning from incidents) once an event is classified as an incident, which directly matches the `responds` verb for a technique already underway.
T1059.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by automatic means), which surfaces PowerShell abuse when it qualifies as an event/incident under the plan, but the control is scoped to incident-management detection rather than comprehensive technique-specific detection of all T1059.001 executions.
T1059.001responds — A.5.24 explicitly builds and exercises an incident response process (assess/respond/learn, escalation per 5.26, coordination, recovery activation) that activates once a T1059.001 execution is recognized as an incident, containing/eradication it per the event-lane definition of responds; the named remainder is that some in-memory or stealthy PowerShell abuse may finish before detection triggers response.
T1059.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by human or automatic means) as part of the incident management plan, which surfaces AppleScript abuse when it manifests as an observable event.
T1059.002responds — A.5.24 explicitly builds and exercises the incident response process (assessing, responding to, containing, eradicating, escalating, coordinating, recovering from, and learning from incidents), which directly matches the `responds` verb once an AppleScript-based execution technique is already underway.
T1059.003detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for information security events and incidents, which surfaces abuse of the Windows command shell when it manifests as a detectable event.
T1059.003responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, escalating, and learning from incidents) that activates once a T1059.003 execution is detected as an information security incident.
T1059.004detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including those from shell abuse as execution), providing broad coverage with only a bounded remainder for undetected edge cases like fully offline or non-monitored embedded systems.
T1059.004responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, escalating, and learning from incidents) that activates once a T1059.004 abuse is underway, matching the `responds` verb; the named remainder is that the control stops at procedural readiness and does not itself perform the on-the-wire containment or eradication actions.
T1059.005detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for information security events and incidents, which surfaces VB-based execution when it triggers an observable incident but does not guarantee coverage of all stealthy or non-incident VB abuse.
T1059.005responds — A.5.24 explicitly builds and exercises incident response processes (assess/respond/learn, escalation per 5.26, coordination, recovery activation, root-cause, lessons-learned) that act on an already-underway execution technique such as VB abuse.
T1059.006detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for security events/incidents (including those from malicious script execution), but the clause sets scope by organisational priorities rather than mandating universal instrumentation depth, leaving gaps for unmonitored Python abuse on some platforms or in non-prioritised scenarios.
T1059.006responds — A.5.24 explicitly builds and activates an incident response process (assessing, responding to, containing, eradicating, escalating, and learning from incidents) that directly acts on an in-flight technique such as Python-based execution once it is detected as an information security incident.
T1059.007detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for information security events and incidents (including those arising from script execution), providing broad detection coverage of T1059.007 across platforms with only a bounded remainder for undetected stealthy or non-event-triggering cases.
T1059.007responds — A.5.24 explicitly builds and exercises an incident response process (assess/respond/learn, escalation per 5.26, coordination, recovery activation, post-mortem) that acts on an already-underway execution technique such as JavaScript abuse once it is classified as an incident.
T1059.008detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including those on network devices), which surfaces the T1059.008 technique when it occurs, but only within the scope and instrumentation chosen by the organization.
T1059.008responds — A.5.24 explicitly builds and activates an incident response process (assessment, response/escalation per incident type, coordination, controlled recovery, root-cause, lessons learned) that directly acts on an in-flight T1059.008 execution once detected, containing/eradicated the actor's foothold and effects on the network device.
T1059.009detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities that surface cloud API abuse as an information security event or incident once it occurs.
T1059.009responds — A.5.24 explicitly builds and exercises the incident response process (assessing, responding to, escalating, containing, recovering from, and learning from incidents), which directly matches the `responds` verb once an adversary has begun abusing cloud APIs to run malicious commands.
T1059.010detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by automatic means), which surfaces use of AHK/AutoIT scripts as anomalous or malicious behavior when observed.
T1059.010responds — A.5.24 explicitly builds and exercises the incident response process (assessing, responding to, containing, eradicating, escalating, and learning from incidents), which directly matches the `responds` verb once an AutoHotKey/AutoIT technique is underway.
T1059.011detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities that surface Lua-based command/script execution as an information security event or incident.
T1059.011responds — A.5.24 explicitly builds and exercises the incident response process (assessing, responding to, escalating, coordinating, recovering from, and learning from incidents), which directly matches the `responds` verb once a Lua-based execution technique is underway.
T1059.012detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, logging and reporting of information security events and incidents (including by automatic means), which surfaces the hypervisor CLI abuse when it occurs within the organization's defined detection scope.
T1059.012responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, escalating, coordinating, recovering, and learning from incidents) that activates once a hypervisor-CLI abuse event is underway, matching the `responds` verb; mostly because the control is scoped to declared incident-management scenarios and competent personnel rather than guaranteeing every possible hypervisor-CLI TTP variant is caught and bounded in real time.
T1059.013detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for information security events and incidents (including those arising from container environments), but the clause sets scope by organisational priorities rather than mandating universal instrumentation depth, leaving some container CLI/API abuse outside chosen detection coverage.
T1059.013responds — A.5.24 explicitly builds and exercises incident response processes that contain, eradicate, escalate, recover from, and learn from security incidents (including those abusing container CLIs/APIs to run malicious commands), once the technique is already underway.
T1068detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities that surface exploitation attempts (including BYOVD and kernel-mode indicators) once they occur, covering the bulk of observable instances across supported platforms with only narrow remainder outside chosen scope.
T1068responds — A.5.24 explicitly builds and activates an incident response process (assessing, responding to, escalating, containing, recovering from, and learning from incidents), which directly engages an in-flight privilege-escalation exploit once it is classified as an incident.
T1069.001responds — A.5.24 establishes incident management processes that include detection, triage, analysis, response/escalation, coordination, and learning from incidents; once T1069.001 reconnaissance runs and is observed as an event, the control's defined response workflow directly contains, eradicates, and learns from it.
T1069.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting and logging of information security events and incidents (including by human or automatic means), which surfaces the reconnaissance technique when it triggers an observable event or anomaly within the defined scope.
T1069.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including by human or automatic means), which surfaces the execution of discovery commands like net group /domain, ldapsearch or dscacheutil that match this technique.
T1069.002responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, escalating, and learning from incidents), which directly matches the `responds` verb once discovery of domain groups is underway as part of an active attack.
T1069.003detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces the reconnaissance technique when it triggers an observable event, but the clause's scope is set by organizational priorities and does not mandate coverage of every cloud enumeration vector.
T1069.003responds — A.5.24 explicitly builds and activates an incident response process (assessing, responding to, escalating, containing, recovering from, and learning from incidents) that directly engages once a T1069.003 enumeration is detected as an information security incident.
T1070detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, root-cause analysis and post-mortem of incidents and events, which surfaces T1070 activity (e.g. anomalous log deletion or artifact tampering) once it occurs; partial because detection scope is set by the organisation's own criteria and procedures rather than mandating universal coverage of every possible indicator-removal technique.
T1070responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, learning from incidents, escalation, controlled recovery, root-cause, lessons-learned) that activates once an incident is recognized, directly addressing T1070's post-facto artifact tampering as an in-flight or realized technique.
T1070.003detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging and root-cause/post-mortem of incidents and events, which surfaces command-history clearing when it is treated as (or accompanies) a detectable security event or incident.
T1070.003responds — A.5.24 explicitly builds and exercises an incident response process that includes detection, triage, analysis, response/escalation, coordination, evidence handling, root-cause, lessons learned, and controlled recovery once an incident is underway; clearing command history is a post-intrusion concealment step that such a process would detect, contain, investigate, and remediate as part of managing the incident to conclusion.
T1070.004detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause/post-mortem of incidents (including those involving adversary cleanup activity), but this is scoped to events that meet incident criteria rather than reliably surfacing the T1070.004 technique itself in all cases.
T1070.004responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, and learning from incidents, including root-cause analysis and controlled recovery), which directly acts on a T1070.004 cleanup technique once it has begun as part of an intrusion.
T1070.005detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities that surface the technique when it occurs as part of an incident
T1070.005responds — A.5.24 explicitly builds and requires an incident response process (assessing, responding to, containing, eradicating, escalating, and learning from incidents once underway), which directly matches the `responds` verb for a post-execution cleanup technique that is part of an active adversary operation.
T1070.006detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, logging and reporting of information security events and incidents (including post-incident root-cause and lessons-learned steps), which surfaces timestomping when it is treated as an event, but the control is silent on any specific detection mechanism or coverage for timestamp anomalies themselves.
T1070.006responds — A.5.24 explicitly builds and exercises an incident response process that includes detection/classification/analysis, response/escalation, root-cause/post-mortem, evidence handling, and learning/improvement once an incident is underway; timestomping (an anti-forensic technique that runs after initial compromise) is surfaced and contained by those steps, with the named remainder being pre-detection stealth impact already realized before response begins.
T1070.007detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, root-cause analysis and post-mortem of incidents and events, which surfaces the T1070.007 clearing activity once it occurs.
T1070.007responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, learning from incidents, escalation, coordination, evidence handling, root-cause) that activates once the T1070.007 cleanup technique has run and left detectable artifacts or anomalies.
T1070.008detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause/post-mortem of incidents and events (including those that could surface mailbox-clearing artifacts), but the control is scoped to incident-management processes rather than continuous or real-time detection of the TTP itself.
T1070.008responds — A.5.24 explicitly builds and exercises the incident response process (assessing, responding to, containing, eradicating, learning from, and coordinating on incidents), which directly matches the `responds` verb once the mailbox-clearing technique has run and is underway.
T1070.009detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, root cause analysis and post-mortem of incidents (including those that clean persistence artifacts), providing broad detection coverage once the technique runs.
T1070.009responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, learning from incidents, escalation, coordination, evidence handling, root-cause) that activates once persistence-cleanup activity is recognized as an incident, directly matching the `responds` verb; the named remainder is that the control does not itself perform the on-the-wire or host-level containment/eradication actions.
T1070.010detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause/post-mortem of incidents and events (including those that could encompass relocation as an evasion or evidence-removal step), but the control is scoped to incident-management processes rather than continuous real-time detection of the technique itself.
T1070.010responds — A.5.24 explicitly builds and exercises an incident response process (assess, respond to, contain, eradicate, escalate, recover, learn) that activates once an incident is underway, directly addressing relocation as part of post-delivery evasion and evidence-removal techniques.
T1071detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by automatic means), which surfaces T1071 command-and-control traffic when it manifests as anomalous application-layer behavior.
T1071responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, escalating, and learning from incidents) that activates once T1071 C2 traffic is treated as an event, meeting the `responds` definition of acting on a technique already underway.
T1071.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by automatic means), which surfaces anomalous web-protocol C2 blending in with legitimate traffic as part of incident detection/triage.
T1071.001responds — A.5.24 explicitly builds and activates an incident response process (assessing, responding to, containing, eradicating, escalating, coordinating, and learning from incidents once underway), which directly matches the `responds` verb for a C2 technique that has already executed and is communicating.
T1071.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by automatic means), which surfaces the use of common file-transfer protocols for C2 blending in with legitimate traffic.
T1071.002responds — A.5.24 explicitly builds and exercises the incident response process (assessing, responding to, containing, eradicating, escalating, and learning from incidents) once an event is classified as an incident, which directly matches the `responds` verb for a C2 technique already in flight.
T1071.003detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by automatic means), which surfaces anomalous use of common protocols such as SMTP/POP3/IMAP for C2; this is a genuine but bounded slice of the technique because detection depends on what the organization elects to monitor and the anomaly criteria it sets.
T1071.003responds — A.5.24 explicitly builds and activates an incident response process (assessing, responding to, escalating, containing via crisis/continuity activation, controlled recovery, and learning) once an incident is underway, which directly matches the `responds` verb for a C2 technique already operating inside the network.
T1071.004detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by automatic means), plus root-cause and lessons-learned steps that surface the technique once it has produced observable events.
T1071.004responds — A.5.24 explicitly builds and activates an incident response process (assessment, response/escalation per incident type, coordination, controlled recovery, root-cause, lessons learned) that activates once a DNS-tunneling event is classified as an incident, directly matching the `responds` verb.
T1071.005detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by automatic means), which surfaces anomalous use of pub/sub protocols when it falls inside the defined scope of what constitutes an incident.
T1071.005responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, escalating, and learning from incidents) that activates once a pub/sub C2 event is detected and classified as an incident.
T1072detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for information security events and incidents, which would surface abuse of deployment tools as anomalous admin activity or lateral movement once it triggers an observable event.
T1072responds — A.5.24 explicitly builds and activates an incident response process (assessing, responding to, escalating, containing via crisis/continuity plans, coordinating parties, and learning) once an incident is underway, which directly matches the `responds` verb for an adversary's abuse of deployment tools that has already begun.
T1074detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities that surface the staging technique (or its artifacts) once it runs, with only a bounded remainder for fully stealthy or non-event-triggering cases.
T1074responds — A.5.24 explicitly builds and activates an incident response process that contains, eradicates, escalates, coordinates, recovers from, and learns from an information security incident once it is underway, which directly matches the `responds` verb for an adversary technique that has already executed.
T1074.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities that surface the local staging technique when it occurs as part of an incident, but the control's scope is limited to events already routed into the incident management process rather than continuous detection of all staging activity.
T1074.001responds — A.5.24 explicitly builds and activates an incident response process that contains, eradicates, escalates, coordinates, and learns from an information security incident once it is underway, which directly matches the `responds` verb against an adversary technique that has already executed to stage data.
T1074.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including by automatic means), which surfaces the staging activity once it occurs.
T1074.002responds — A.5.24 explicitly builds and activates an incident response process that includes assessing, responding to, containing, eradicating, escalating, and learning from incidents (including coordination and recovery activation), which directly matches the `responds` verb once the T1074.002 staging activity is underway as part of a larger intrusion.
T1078detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities that surface use/abuse of valid accounts (including inactive ones and anomalous pivots) once the technique is underway.
T1078responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, escalating, coordinating, recovering from, and learning after incidents), which directly matches the `responds` verb once a T1078 abuse of valid accounts is underway as an information security incident.
T1078.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces default-account abuse when it manifests as a detectable event, but the control's scope is limited to what the organization has chosen to instrument and does not guarantee coverage of every default-account usage vector across all platforms.
T1078.001responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, escalating, coordinating, recovering from, and learning after an incident), which directly matches the `responds` verb once a default-account abuse technique is already underway.
T1078.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for information security events and incidents, which surfaces domain-account abuse when it triggers observable events, but the control's scope is limited to what the organization has defined as reportable events and does not guarantee coverage of stealthy or non-event-based abuse of valid domain credentials.
T1078.002responds — A.5.24 explicitly builds and activates an incident response process (assessing, responding to, containing, eradicating, escalating, coordinating, recovering from, and learning from incidents), which directly matches the `responds` verb once a domain-account abuse technique is underway.
T1078.003detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for information security events and incidents, which surfaces local-account abuse when it triggers observable events, but the control's scope is set by organizational priorities and does not mandate instrumentation that would catch every stealthy or low-signal use of a local account.
T1078.003responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, escalating, recovering from, and learning from incidents), which directly matches the `responds` verb once the local-account abuse technique is already underway.
T1078.004detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities that surface cloud-account abuse (e.g. anomalous use of valid credentials, privilege escalations, or persistence via additional credentials) once the technique is in flight.
T1078.004responds — A.5.24 explicitly builds and exercises incident response processes (assess/respond/learn, escalation per 5.26, coordination, recovery activation, post-mortem) that act on an already-underway T1078.004 compromise once detected.
T1080detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause/post-mortem of incidents (including those from tainted shared content once execution or lateral movement occurs), but does not mandate detection of the pre-execution tainting action itself on shared storage.
T1080responds — A.5.24 explicitly builds and exercises the incident response process (assessing, responding to, containing, eradicating, escalating, coordinating, recovering from, and learning from incidents), which directly matches the `responds` verb once T1080 has executed and tainted shared content.
T1082detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces T1082 activity when it triggers an event meeting the organization's incident criteria; this is a genuine but scoped slice because detection depends on the chosen criteria, logging, and tools rather than mandating universal coverage of all discovery behaviors.
T1082responds — A.5.24 explicitly builds and activates an incident response process (assessing, responding to, containing, escalating, coordinating, recovering from, and learning from incidents), which directly matches the `responds` verb once T1082 has run and is underway as part of a broader attack.
T1083detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including those from host/network activity), which surfaces T1083 execution as an observable event.
T1083responds — A.5.24 explicitly builds and activates an incident response process (assessing, responding to, containing, eradicating, escalating, and learning from incidents once underway), which directly matches the `responds` verb for a discovery technique already in flight.
T1087detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting and logging of information security events and incidents (including by human or automatic means), which surfaces account discovery activity once it occurs.
T1087responds — A.5.24 explicitly builds and activates an incident response process that contains, eradicates, escalates, coordinates, and learns from an information security incident once it is underway, which directly matches the `responds` verb for an already-executing T1087 enumeration.
T1087.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces the account enumeration technique when it triggers defined detection criteria, but the control's scope is limited to events that meet incident thresholds rather than all instances of the technique.
T1087.001responds — A.5.24 explicitly builds and activates an incident response process that includes detection, classification, analysis, response/escalation, coordination, and learning once an information security incident (including discovery/enumeration activity matching T1087.001) is underway.
T1087.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (by human or automatic means) as part of the incident management plan, which surfaces the account enumeration technique when it occurs.
T1087.002responds — A.5.24 explicitly builds and activates an incident response process (assessing, responding to, containing, eradicating, escalating, and learning from incidents) that activates once discovery or detection of T1087.002 occurs, directly matching the `responds` verb.
T1087.003detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for information security events and incidents, which surfaces the T1087.003 technique (authenticated enumeration of email accounts via cmdlets or directory services) once it runs.
T1087.003responds — A.5.24 explicitly builds and activates incident response processes (assess/respond/escalate to conclusion per incident type, including coordination and recovery) that directly contain and eradicate an in-progress account-enumeration technique once detected.
T1087.004detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities that surface an information security incident, which includes the T1087.004 discovery technique once it runs and is observable as an event.
T1087.004responds — A.5.24 builds and activates an incident response process that contains, eradicates, escalates, coordinates, and learns from an already-underway discovery technique once it is classified as an incident
T1090detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including those that could involve proxy-based C2), but the control is about building the overall incident management capability and process rather than mandating any specific detection mechanisms for this technique.
T1090responds — A.5.24 explicitly builds and activates an incident response process (assessing, responding to, containing, eradicating, escalating, coordinating, and learning from incidents once underway), which directly matches the `responds` verb for a T1090 proxy C2 channel that has already been established.
T1090.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via 8.16 references), which surfaces internal proxy C2 redirection when it triggers observable anomalies, but the control is scoped by organizational priorities and does not mandate instrumentation that reliably catches all stealthy p2p/SMB-blended cases.
T1090.001responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, escalating, and learning from incidents) that activates once an internal-proxy C2 technique is detected inside the environment.
T1090.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via 8.16 references), which surfaces proxy-based C2 as anomalous network behaviour, but the control is scoped by organisational priorities and does not mandate universal coverage of all proxy techniques or platforms.
T1090.002responds — A.5.24 explicitly builds and activates an incident response process (assessing, responding to, containing, escalating, coordinating, recovering from, and learning from incidents), which directly acts on an in-flight T1090.002 C2 proxy once detected as part of managing the broader incident.
T1090.003detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by automatic means), which surfaces multi-hop proxy traffic as anomalous when observed within the organization's monitored scope, but does not guarantee detection of all prior hops, decentralized P2P/blockchain variants, or fully obfuscated chains.
T1090.003responds — A.5.24 explicitly builds and exercises incident response processes (assess, respond to, contain, eradicate, escalate, recover, learn) that activate once a multi-hop proxy C2 channel is detected as an active incident, directly addressing the technique once underway.
T1090.004detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via 8.16 references), which surfaces domain fronting when it manifests as anomalous HTTPS traffic or is caught in incident triage, but the control is silent on the specific indicators of mismatched SNI/Host headers or CDN routing abuse and does not mandate network-layer instrumentation that would reliably catch it.
T1091detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including logging), which surfaces T1091 activity once the media is inserted and executes, but only as part of a broader incident management process rather than dedicated detection mechanisms.
T1091responds — A.5.24 explicitly builds and exercises an incident response process (assess/respond/learn, escalation per 5.26, coordination, recovery activation, root-cause/lessons) that activates once the removable-media replication technique has executed and delivered malware, containing/eradicating it per the defined scenarios.
T1092detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for information security incidents and events, which would surface the observable use of removable media for C2 (especially when crossing air gaps or during lateral movement), but only for incidents that meet the organization's classification criteria and within the scoped monitoring (see 8.16).
T1092responds — A.5.24 explicitly builds and exercises the incident response process (assess, respond to, contain, eradicate, escalate, recover, learn) that activates once an adversary technique such as T1092 is underway, matching the `responds` verb definition.
T1095detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by automatic means), which surfaces non-application-layer protocol C2 as anomalous behaviour when it is within the defined scope of monitoring, but the control's scope is set by organisational requirements rather than mandating coverage of all such traffic (e.g. VMCI or unmonitored ICMP).
T1095responds — A.5.24 explicitly builds and activates an incident response process that assesses, contains, eradicates, escalates, coordinates, recovers from, and learns from security incidents (including those using non-application-layer C2 such as ICMP/VMCI), which is exactly what `responds` names once the technique is already running.
T1098detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for information security events and incidents, which directly surfaces account manipulation when it triggers an observable incident.
T1098responds — A.5.24 explicitly builds and activates an incident response process (assessing, responding to, containing, eradicating, escalating, coordinating, recovering from, and learning from incidents), which directly matches the `responds` verb once account manipulation is underway as an information security incident.
T1098.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (by human or automatic means) as core incident management activities, which surfaces the addition of adversary-controlled cloud credentials as an anomalous event.
T1098.001responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, escalating, coordinating, recovering, and learning from incidents), which directly matches the `responds` verb once the credential-addition technique has executed and is underway.
T1098.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (by human or automatic means) as core incident management activities, which surfaces the permission-granting technique when it occurs as an event or incident.
T1098.002responds — A.5.24 explicitly builds and exercises an incident response process (assess, respond to, contain, eradicate, escalate, recover, learn) that directly acts on incidents already underway, including those using T1098.002 for persistence or BEC; the named remainder is that the control does not itself perform the on-the-wire containment/eradication steps.
T1098.003detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for security events and incidents (including those involving account/role changes), but the control's scope is set by organizational priorities and does not mandate coverage of every stealthy cloud IAM modification on every platform.
T1098.003responds — A.5.24 explicitly builds and exercises the incident response process (assessing, responding to, escalating, coordinating, recovering from, and learning from incidents), which directly contains and eradicates an in-progress T1098.003 persistence action once detected.
T1098.004detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause/post-mortem of incidents (including those from persistence techniques like authorized_keys modification), but detection depends on the chosen scope, tools, and event criteria rather than mandating coverage of this specific technique.
T1098.004responds — A.5.24 explicitly builds and exercises the incident response process (assessing, responding to, containing, eradicating, escalating, coordinating, recovering from, and learning from incidents), which directly matches the `responds` verb once the SSH authorized_keys modification technique has run and is underway.
T1098.005detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting and logging of information security events and incidents (including those involving unauthorized device registration as a form of account compromise or policy bypass), which surfaces the technique in flight.
T1098.005prevents — A.5.24 requires establishing incident management processes, detection/monitoring, classification, response/escalation, and learning/improvements that can stop the technique from completing or persisting in many scenarios (e.g., rapid detection of anomalous device enrollment followed by revocation), but leaves gaps such as self-enrollment with stolen credentials before any event is raised and does not mandate preventive enrollment controls.
T1098.005responds — A.5.24 explicitly builds and requires an incident response process (assessing, responding to, containing, eradicating, escalating, and learning from incidents) that directly matches the `responds` verb once the device-registration technique has run and produced an incident.
T1098.006detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for information security events and incidents, which would surface this post-compromise permission-addition technique when it triggers an observable event, but the control's scope is set by organizational priorities and does not mandate coverage of every container-specific or cloud-RBAC variant.
T1098.006responds — A.5.24 explicitly builds and exercises an incident response process (assess, respond to, contain, eradicate, escalate, recover, learn) that activates once an incident is declared, directly addressing the post-compromise privilege-addition technique while it is underway.
T1098.007detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including those that could surface group-addition activity), but the control is scoped to incident management processes rather than mandating specific detection mechanisms for this persistence technique.
T1098.007responds — A.5.24 explicitly builds and activates an incident response process that contains, eradicates, escalates, coordinates, and learns from security incidents (including those realizing persistence via group additions), once the technique has run and is underway.
T1102detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including coordination and post-incident root-cause work), which surfaces T1102 C2 activity when it triggers an observable event, but the control's scope is limited to events that meet the organization's defined criteria and does not guarantee detection of all stealthy web-service C2 hidden in legitimate traffic.
T1102responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, escalating, and learning from incidents once underway), which directly matches the `responds` verb against a live T1102 C2 channel.
T1102.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces dead-drop resolver activity once it manifests as observable events, but the control's scope is limited to what the organization has chosen to instrument and does not guarantee detection of all stealthy uses of common web services.
T1102.001responds — A.5.24 explicitly builds and exercises the incident response process (assessing, responding to, containing, eradicating, learning from, and coordinating on incidents), which directly matches the `responds` verb once the dead-drop technique has executed and produced observable effects.
T1102.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (by human or automatic means) plus logging, which surfaces T1102.002 C2 activity once it occurs.
T1102.002responds — A.5.24 explicitly builds and exercises the incident response process (assess, respond to, contain, eradicate, escalate, recover, learn) once an incident is underway, directly addressing T1102.002 C2 once detected.
T1102.003detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via 8.16 references), which surfaces the use of legitimate web services for one-way C2 as anomalous behavior once it occurs.
T1102.003responds — A.5.24 explicitly builds and exercises the incident response process (assessing, responding to, escalating, coordinating, recovering from, and learning from incidents), which directly matches the `responds` verb once a T1102.003 C2 event is underway.
T1104detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via automated means), which surfaces multi-stage C2 activity once it produces observable events, but the control is scoped to what the organization chooses to monitor and does not guarantee coverage of all obfuscated stages or fallback channels.
T1104responds — A.5.24 explicitly builds and exercises an incident response process (assess, respond to, contain, eradicate, escalate, recover, learn) that activates once a multi-stage C2 channel is detected as an incident, directly matching the `responds` verb.
T1105detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (by human or automatic means) as core incident management capabilities, which surfaces the tool-transfer technique once it runs.
T1105responds — A.5.24 explicitly builds and exercises an incident response process (assess, respond to, contain, eradicate, escalate, recover, learn) that activates once an ingress-tool-transfer incident is underway, matching the `responds` verb; the named remainder is that the control stops at procedural readiness and does not itself perform the on-the-wire containment.
T1106detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for security events and incidents, which surfaces T1106 abuse when it triggers an observable incident but does not guarantee coverage of all stealthy syscall or unhooking variants.
T1106responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, escalating, and learning from incidents once underway), which directly matches the `responds` verb against any executed technique including T1106.
T1110detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for information security events and incidents, which directly surfaces brute-force attempts (online guessing, failed logins, anomalous auth patterns) once they occur.
T1110prevents — planning, procedures, training, detection, response/escalation and post-incident improvements can constrain or stop some brute-force executions (e.g. via rapid detection+lockout or learned controls), but the control is governance/preparation only and does not itself stop the guessing technique from running
T1110responds — A.5.24 explicitly builds and activates an incident response process (assess/respond/learn, escalation per 5.26, coordination, recovery activation) once a brute-force event is classified as an incident, containing and eradicating the actor's foothold while the technique is underway.
T1110.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for information security events and incidents, which directly surfaces password-guessing attempts (especially those producing observable failures or anomalies on targeted services).
T1110.001prevents — A.5.24 requires establishing incident management processes, detection/monitoring capabilities, classification, response/escalation procedures, and account lockout handling that directly stop password guessing from succeeding or continuing (per the technique's own discussion of lockout policies and authentication failures), with a bounded remainder for exempted/legacy services that bypass those controls.
T1110.001responds — A.5.24 explicitly builds and activates an incident response process (assess, respond to, contain, eradicate, escalate, recover, learn) once an information security incident is declared from authentication failures or guessing attempts, matching the `responds` verb definition.
T1110.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces password-cracking activity when it triggers observable events inside organizational scope.
T1110.002prevents — A.5.24 requires establishing incident management processes, detection/monitoring, classification, response/escalation, and lessons-learned improvements that can constrain or deter reuse of cracked credentials in some scenarios, but the control acts after hashes are obtained and cracking occurs externally, so it does not stop the core technique.
T1110.002responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, learning from, and coordinating on incidents), which directly matches the `responds` verb once a password-cracking event has begun; the remainder is that cracking performed entirely offline on adversary systems may finish before detection/response is triggered.
T1110.003detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces password spraying attempts against authentication services before or while they succeed.
T1110.003prevents — A.5.24 mandates establishing incident management processes, detection/monitoring capabilities, classification, response/escalation procedures, and competent personnel — which (per the A.8.5 anchor) stops password spraying from yielding valid credentials when MFA, throttling, or lockout mechanisms are enacted as part of those procedures.
T1110.003responds — A.5.24 explicitly builds and activates an incident response process (assess, respond, escalate, contain to conclusion, coordinate, learn) once an information security incident is declared, which matches the `responds` verb for a spraying campaign once detected.
T1110.004detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including credential-related ones), providing broad detection capability once the technique is underway.
T1110.004prevents — A.5.24 requires establishing incident management processes, detection/monitoring, classification, response/escalation, and learning/improvements that can stop credential-stuffing campaigns once initial events are spotted, but does not stop the technique from being attempted or succeeding on the first try before any incident is declared.
T1110.004responds — A.5.24 explicitly builds and activates an incident response process (assessing, responding to, escalating, containing, recovering from, and learning from incidents), which directly acts on credential-stuffing events once underway per the event-lane definition of responds.
T1111detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for security events and incidents, which surfaces T1111 (MFA interception) once it produces observable artifacts such as anomalous authentication, keylogger indicators, or out-of-band compromise.
T1111responds — A.5.24 explicitly builds and exercises an incident response process (assess, respond to, contain, eradicate, escalate, recover, learn) that activates once an MFA-interception incident is underway, matching the `responds` verb; the named remainder is that the control stops at procedural readiness and does not itself perform the on-the-wire containment.
T1112detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for information security events and incidents, which can surface Registry modifications when they trigger observable events meeting the organization's incident criteria, but does not mandate specific detection mechanisms for this technique.
T1112responds — A.5.24 explicitly builds and exercises an incident response process that includes detection, triage, analysis, response/escalation, coordination, recovery, root-cause, lessons-learned and evidence handling once an incident is underway; T1112's post-compromise Registry modifications (defense evasion, persistence, lateral movement) are observable events that trigger exactly those activities.
T1113detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including by automatic means), which surfaces T1113 screen-capture activity once it occurs.
T1113responds — A.5.24 explicitly builds and activates an incident response process that contains, eradicates, escalates, coordinates, recovers from, and learns from an information security incident once it is underway, which directly matches the `responds` verb for a post-compromise screen-capture technique that has already executed.
T1114detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for information security events and incidents, which surfaces T1114 when it produces observable events (e.g. anomalous forwarding, unusual mail-server access, or exfiltration of incident-response emails).
T1114responds — A.5.24 explicitly builds and exercises the incident response process (assess, respond to, contain, eradicate, escalate, recover, learn) once an incident is underway, directly addressing the T1114 technique when it surfaces as part of an incident (e.g. via monitoring/detection of email exfil or discovery of forwarded mailboxes revealing IR details).
T1114.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including via human or automatic means), which surfaces local email collection when it registers as an observable event or anomaly within the defined incident criteria and scope.
T1114.001responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, learning from incidents) that activates once an information security incident — including local collection of sensitive data such as email files — is underway.
T1114.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities that surface remote email collection when it registers as an information security event or incident.
T1114.002responds — A.5.24 explicitly builds and activates incident response processes (assessment, response/escalation per 5.26, coordination, containment to conclusion, recovery activation, post-mortem) once an incident is underway, which directly matches the `responds` verb for an email-collection technique that has already succeeded.
T1114.003detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces the creation or presence of email forwarding rules as an incident.
T1114.003responds — A.5.24 explicitly builds and exercises an incident response process (assess, respond to, learn from incidents; manage to conclusion with escalation, containment via continuity/crisis activation, root-cause, lessons learned) that directly acts on T1114.003 once the forwarding rule is created and operating.
T1115detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting and logging of information security events and incidents (including by human or automatic means), which surfaces clipboard-data collection when it triggers an observable event or anomaly within the defined incident criteria and scope.
T1115responds — A.5.24 explicitly builds and exercises an incident response process that contains, eradicates, escalates, coordinates, and learns from security incidents once they are underway, which directly matches the `responds` verb against an adversary technique that has already executed.
T1119detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including automated means), which surfaces automated collection activity once it is underway.
T1119responds — A.5.24 explicitly builds and activates an incident response process (assessment, response/escalation per 5.26, coordination, controlled recovery) that acts on an already-underway automated collection event to contain it, eradicate the actor's collection capability, and learn from it.
T1120detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by human or automatic means) as part of the incident management plan, which surfaces T1120 when it is treated as an event.
T1123detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (by human or automatic means) as part of the incident management plan, which surfaces T1123 audio capture when it registers as an event.
T1123responds — A.5.24 explicitly builds and exercises an incident response process (assess/respond/learn, escalation, containment via crisis/continuity activation, recovery, root-cause and lessons-learned) that activates once an audio-capture incident is underway, exactly matching the `responds` verb.
T1124detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by automatic means), which surfaces T1124 activity when it is treated as an event, but the control's scope is limited to declared incidents rather than all reconnaissance and the detection is not required to be universal or real-time.
T1124responds — A.5.24 explicitly builds incident response processes that include detection, triage, analysis, response/escalation, coordination, and learning once an information security incident (including discovery activity) is underway.
T1125detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (by human or automatic means) as part of the incident management plan, which surfaces T1125 activity once it occurs.
T1125responds — A.5.24 explicitly builds and exercises the incident response process (assess, respond to, contain, eradicate, escalate, recover from, learn from incidents), which directly matches the `responds` verb once a T1125 video-capture incident is underway.
T1127detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including by automatic means), which surfaces T1127 activity once it occurs, but the control is scoped to organization-defined processes rather than mandating specific detection coverage for this technique.
T1127responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, learning from, and coordinating on incidents), which directly matches the `responds` verb once the T1127 technique has executed and produced detectable effects.
T1127.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by automatic means), which surfaces the MSBuild abuse technique when it occurs within the organization's defined detection scope.
T1127.001responds — A.5.24 explicitly establishes incident response processes, procedures for detection/classification/analysis/escalation/response to conclusion, coordination, and learning from incidents, which directly acts on an in-flight technique like T1127.001 once underway for containment/eradication.
T1127.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for information security events and incidents (including those from malicious code execution), but the clause's scope is set by organizational priorities and does not mandate instrumentation that would necessarily surface every ClickOnce abuse vector (e.g. disguised user-driven installation or startup-folder persistence).
T1127.002responds — A.5.24 explicitly builds and exercises the incident response process (assessing, responding to, containing, eradicating, escalating, and learning from incidents), which directly matches the `responds` verb once a T1127.002-based event is underway.
T1127.003detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for security events/incidents, which surfaces T1127.003 when it triggers an observable incident but does not guarantee detection of every stealthy or non-incident-classified abuse of a build tool.
T1127.003responds — A.5.24 explicitly builds and activates incident response processes (assessment, response/escalation per 5.26, coordination, containment via crisis/continuity activation, root-cause, lessons learned) once an event is classified as an incident, which directly matches the `responds` verb for a post-execution technique.
T1129detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including by automatic means), which surfaces T1129 activity once it occurs, but the control is scoped to organization-defined processes and does not mandate instrumentation depth or coverage of all module-loading vectors.
T1129responds — A.5.24 explicitly builds and activates an incident response process (assessing, responding to, containing, eradicating, escalating, and learning from incidents) that directly acts on T1129 once the shared-module loading technique is underway.
T1132detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces encoded C2 traffic as an anomalous event when it is observable, but the control's scope is limited to incident-management processes rather than mandating specific detection mechanisms for encoding obfuscation.
T1132responds — A.5.24 explicitly builds and activates an incident response process that contains, eradicates, escalates, coordinates, recovers from, and learns from security incidents (including C2 traffic), once the encoded technique is already underway.
T1132.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by automatic means), which surfaces encoded C2 traffic as an anomalous event once it occurs, but the control is scoped to incident management processes rather than mandating specific detection mechanisms for encoding techniques.
T1132.001responds — A.5.24 explicitly builds and activates an incident response process that includes detection, triage, analysis, response/escalation, coordination, root-cause, lessons-learned and controlled recovery once an encoded-C2 incident is underway, satisfying the `responds` verb with only the usual named remainder that some early undetected events may complete their full effect before response begins.
T1132.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by automatic means) as part of the incident management plan, which surfaces non-standard encoding in C2 traffic once it occurs.
T1132.002responds — A.5.24 explicitly builds and activates an incident response process that contains, eradicates, escalates, coordinates, and learns from security incidents (including C2 traffic), once the non-standard encoding technique has already run and produced detectable events.
T1133detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for information security events and incidents, which surfaces T1133 usage (including anomalous external remote service access) once it occurs.
T1133responds — A.5.24 explicitly builds and exercises incident response processes (assess/respond/learn, escalation, containment via 5.26 cross-ref, recovery activation, root-cause, lessons) that act on an already-underway T1133 compromise once detected.
T1134detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for information security events and incidents (including those from privileged token manipulation), providing broad detection coverage once the technique is in flight.
T1134responds — A.5.24 explicitly builds and exercises an incident response process that includes detection, triage, analysis, response/escalation, coordination, recovery, root-cause, and lessons-learned steps once an incident is underway, which directly matches the `responds` verb for a technique that has already executed.
T1134.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for security events/incidents (including those from human or automatic means), which surfaces token impersonation when it triggers an observable incident but does not guarantee coverage of all stealthy or pre-incident uses of the technique.
T1134.001responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, escalating, and learning from incidents once underway), which directly matches the `responds` verb for a Windows token-theft technique that has already executed.
T1134.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for security events and incidents (including those from privilege-escalation techniques like token misuse), but the clause sets scope by organisational priorities rather than mandating universal coverage of every Windows token-creation artifact.
T1134.002responds — A.5.24 explicitly builds and exercises the incident response process (assessing, responding to, containing, eradicating, escalating, and learning from incidents), which directly matches the `responds` verb once T1134.002 is underway; the named remainder is that the control stops at procedural readiness and does not itself perform the runtime containment action.
T1134.003detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, logging and reporting of information security events and incidents (including by automatic means), which surfaces token-creation/impersonation activity once it occurs.
T1134.003prevents — A.5.24 requires establishing incident management processes, detection/monitoring, response/escalation, and learning/improvements that can constrain or stop the technique from completing its full privilege-escalation impact once an event is surfaced, but does not stop the initial creation/impersonation of the token itself.
T1134.003responds — A.5.24 explicitly builds and exercises an incident response process (assess/respond/learn, escalation per type/category, coordination, controlled recovery) that activates once a token-impersonation incident is underway, containing/eradicating it per the event-lane definition of responds.
T1134.004detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces PPID-spoofing activity when observed as part of incident detection workflows, but the control is silent on any specific instrumentation, telemetry, or detection mechanisms for this technique.
T1134.004responds — A.5.24 explicitly builds and exercises an incident response process that includes detection, triage, analysis, escalation, containment via response/escalation procedures, coordination, evidence handling, root-cause, and lessons-learned once an incident is underway; PPID spoofing (a post-execution evasion technique) is surfaced and acted on inside that workflow, with the named remainder being any pre-containment privilege impact already realized.
T1134.005detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for information security incidents and events, which can surface SID-History Injection as a privilege-escalation incident once it occurs, but the control is scoped to incident management rather than continuous or preventive detection of the technique itself.
T1134.005responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, escalating, coordinating, recovering, and learning from incidents), which directly matches the `responds` verb once a SID-History Injection technique is underway.
T1135detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting and logging of information security events and incidents (including by automatic means), which surfaces T1135 network-share-discovery activity once it occurs.
T1135responds — A.5.24 explicitly builds and activates an incident response process (assessing, responding to, containing, eradicating, escalating, and learning from incidents) that applies once discovery activity is recognized as an information security incident
T1136detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities that surface the creation of accounts (as an event/incident) once it occurs.
T1136responds — A.5.24 explicitly builds and activates an incident response process (assessing, responding to, containing, eradicating, escalating, coordinating, recovering from, and learning from declared incidents), which directly matches the `responds` verb once the account-creation technique has run and been classified as an incident.
T1136.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including those that could surface new local accounts), but the control is scoped to what the organization chooses to instrument and does not mandate detection of every possible local-account creation vector across all platforms.
T1136.001responds — A.5.24 explicitly builds and activates an incident response process (assess/respond/learn, escalation per 5.26, coordination, controlled recovery) once an incident is underway, which directly matches the `responds` verb for containing/eradication of T1136.001 account creation when it is detected as an incident.
T1136.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for information security events and incidents, which surfaces the creation of a domain account when it is treated as (or triggers) an incident.
T1136.002responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, escalating, and learning from incidents) that activates once a domain-account creation event is classified as an incident, directly matching the `responds` verb.
T1136.003detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for information security events and incidents, which surfaces the creation and use of a cloud account as an anomalous or unauthorized event once it occurs.
T1136.003responds — A.5.24 explicitly builds and exercises an incident response process (assess, respond to, contain, eradicate, escalate, recover, learn) that activates once an incident is declared, directly addressing the post-creation persistence and privilege-escalation use of a T1136.003 cloud account; the named remainder is that the account may already have achieved its persistence goal before response begins.
T1137detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces T1137-style Office persistence when it manifests as an observable event, but the clause's scope is set by organizational priorities and does not mandate coverage of every persistence technique.
T1137prevents — planning, training, procedures and detection/response processes lower the chance the persistence technique is introduced or survives but do not stop an adversary from abusing Office features for persistence
T1137responds — A.5.24 explicitly builds and activates an incident response process (assessing, responding to, containing, eradicating, escalating, and learning from incidents once underway), which directly matches the `responds` verb for a realized T1137 persistence technique.
T1137.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means) as part of the incident management plan, which surfaces this persistence technique once it has executed on startup; this is a genuine but bounded slice because the control's detection is scoped to events that meet the organization's defined criteria for incidents rather than mandating universal coverage of all possible macro-based template abuses.
T1137.001prevents — A.5.24 requires establishing incident management processes, detection/monitoring, classification, response/escalation, root-cause analysis, and lessons-learned improvements that can constrain or block the macro-persistence technique in some scenarios (e.g., rapid detection leading to removal before reuse, or post-incident hardening of macro policies), but does not stop the initial template modification or macro execution on startup.
T1137.001responds — A.5.24 explicitly builds and activates an incident response process (assess, respond to, contain, eradicate, escalate, recover, learn) once an incident is underway, directly addressing T1137.001 persistence once triggered.
T1137.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for information security events and incidents (including those enabling persistence), but the control is scoped by organizational priorities, criteria, and procedures rather than mandating universal coverage of this specific Registry-abuse technique.
T1137.002prevents — A.5.24 requires establishing incident management processes, detection/monitoring capabilities, classification, response/escalation procedures, and lessons-learned improvements that can prevent the persistence technique from achieving long-term success by enabling rapid detection and eradication before it is relied upon, but does not stop the initial Registry modification itself.
T1137.002responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, escalating, coordinating, recovering from, and learning from incidents), which directly matches the `responds` verb once the persistence technique has executed and is underway.
T1137.003detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for information security events and incidents, which surfaces the T1137.003 persistence technique once it has executed via a crafted email or Outlook startup.
T1137.003prevents — A.5.24 mandates establishing incident management processes, detection/monitoring, classification, response/escalation, root-cause analysis, and lessons-learned improvements that can constrain or block the persistence technique from completing its full effect in many scenarios, but does not stop the initial addition of malicious forms or their loading/execution on Outlook startup.
T1137.003responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, escalating, coordinating, recovering, and learning from incidents), which directly matches the `responds` verb once the T1137.003 persistence technique has executed and is underway.
T1137.004detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by automatic means) as part of the incident management plan, which surfaces the T1137.004 persistence technique once it has executed and produced observable activity.
T1137.004prevents — A.5.24 requires establishing incident management processes, detection/monitoring capabilities, classification, response/escalation procedures, and learning/improvements that can stop the persistence technique from achieving long-term effect once the malicious Home Page is present and Outlook loads it.
T1137.004responds — A.5.24 explicitly builds and exercises an incident response process that contains, eradicates, escalates, coordinates, and learns from an already-underway security incident, directly matching the `responds` verb once the malicious Outlook Home Page persistence has activated.
T1137.005detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces the malicious Outlook rule when it triggers on a crafted email, but the clause's scope is set by organizational priorities and does not mandate instrumentation that would catch rule creation or loading before execution.
T1137.005prevents — A.5.24 mandates establishing incident management processes, training, detection, classification, response/escalation, root-cause analysis and lessons-learned improvements that can constrain or block the successful use of malicious Outlook rules once the technique is recognized as an incident vector, but does not stop the initial creation or loading of the rules themselves.
T1137.005responds — A.5.24 explicitly builds and exercises an incident response process (assess/respond/learn, escalation per 5.26, coordination, recovery activation) that activates once the malicious Outlook rule has executed on a crafted email, containing/eradicated the persistence and its effects.
T1137.006detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by automatic means) as part of the incident management plan, which surfaces the add-in persistence technique when it triggers on application start; this is a genuine but scoped slice because detection depends on the chosen criteria, tooling and scope rather than mandating coverage of all Office add-in abuse vectors.
T1137.006prevents — A.5.24 requires establishing incident management processes, detection/monitoring, classification, response/escalation, root-cause analysis, and lessons-learned improvements that can constrain or block the add-in persistence technique from succeeding or recurring, but this is governance/preparation that does not itself remove the add-in mechanism or block its initial execution.
T1137.006responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, learning from, and coordinating on incidents), which directly matches the `responds` verb once the add-in persistence technique has executed and is underway.
T1140detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces the deobfuscation technique when it is treated as (or triggers) an observable event; this is a genuine but scoped slice because the control's detection is limited to what the organization's defined criteria, tools and scope classify as an incident rather than guaranteeing detection of every instance of T1140.
T1140responds — A.5.24 explicitly builds and exercises an incident response process that includes detection, triage, analysis, response/escalation, root-cause, lessons learned, and coordination once an event is underway; deobfuscation/decode steps (T1140) are observable artifacts or actions during an active intrusion that this process is designed to contain and eradicate.
T1176detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means) as part of the incident management plan, which surfaces the T1176 technique once it has produced observable events, but the control's scope is limited to events that meet defined incident criteria and does not mandate instrumentation that would catch stealthy or blended extension abuse.
T1176responds — A.5.24 explicitly builds and exercises an incident response process (assess, respond to, learn from incidents; escalation, containment via crisis/continuity activation, root-cause, lessons learned) that activates once a malicious-extension persistence incident is underway, exactly matching the `responds` verb.
T1176.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means) as part of the incident management plan, which surfaces the technique once it has produced observable events; this is a genuine but bounded slice given the control's post-event focus and dependence on other controls (e.g. 8.16) for detection mechanisms.
T1176.001responds — A.5.24 explicitly builds and exercises the incident response process (assess, respond to, contain, eradicate, escalate, recover, learn) once an incident is underway, which directly matches the `responds` verb for a technique that has already achieved persistence via malicious browser extensions.
T1176.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including logging), which surfaces the technique once the malicious/benign extension executes on launch, but the clause's scope is set by organizational priorities and does not mandate coverage of all IDE-extension behaviors or installation vectors.
T1176.002responds — A.5.24 explicitly builds and exercises an incident response process (assess/respond/learn, escalation per 5.26, coordination, controlled recovery, root-cause, lessons-learned) that activates once an installed malicious IDE extension is detected as an incident, containing/eradication it with only the already-realized persistence impact left for recovery controls.
T1185detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for security events and incidents, which surfaces browser session hijacking (process injection into browser, anomalous pivoting, or inherited sessions) once it occurs.
T1185responds — A.5.24 explicitly builds and activates an incident response process that contains, eradicates, escalates, coordinates, and learns from an already-underway information security incident such as browser session hijacking.
T1187detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces the forced-authentication technique when it triggers observable events such as anomalous SMB/WebDAV connections or authentication attempts.
T1187responds — A.5.24 explicitly builds and exercises the incident response process (assess, respond to, contain, eradicate, learn from incidents including credential theft via forced auth), acting once the technique is underway; the named remainder is that early undetected collection of the hash may already enable offline cracking or relay before response begins.
T1189detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including those from drive-by compromise), but the control is scoped to an organization-chosen set of procedures rather than mandating universal coverage of every possible drive-by vector or platform.
T1189responds — A.5.24 explicitly builds and exercises the incident response process (assessing, responding to, containing, eradicating, escalating, coordinating, recovering from, and learning from incidents), which directly matches the `responds` verb once a drive-by compromise has executed and is underway.
T1190detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including those from public-facing applications), which surfaces the T1190 technique once attempted or successful.
T1190responds — A.5.24 explicitly builds and exercises the incident response process (assess, respond to, contain, eradicate, escalate, recover, learn) once an exploited-public-facing-application incident is underway, with only the pre-incident planning slice outside the verb
T1195detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including those from supply chain vectors), but this is scoped to post-receipt organizational detection rather than upstream supply chain stages, leaving a large remainder of the technique (e.g., pre-delivery manipulation of tools, open-source deps, or factories) outside its view.
T1195prevents — A.5.24 builds incident management planning, detection, response, and learning processes that enable organizations to identify and block many supply-chain compromise techniques (e.g., via monitoring, triage, and coordinated response before full impact), but cannot stop the adversary action at the pre-receipt supply-chain stage itself.
T1195responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, escalating, coordinating, recovering from, and learning from incidents), which directly matches the `responds` verb once a supply-chain compromise event is underway.
T1195.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means) as part of the incident management plan, which surfaces supply-chain compromise techniques once manifested as observable events; this is limited to a post-compromise detection slice rather than the pre-receipt manipulation itself.
T1195.001responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, escalating, coordinating, recovering from, and learning from incidents), which directly matches the `responds` verb once a supply-chain compromise technique has executed and is underway.
T1195.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces supply-chain compromise events once they reach the victim organization, but does not address pre-receipt detection in the supply chain itself.
T1195.002responds — A.5.24 explicitly builds and activates an incident response process (assessing, responding to, containing, eradicating, escalating, coordinating, recovering, and learning from incidents), which directly matches the `responds` verb once a supply-chain compromise has occurred and is underway.
T1195.003detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), plus root-cause/post-mortem and lessons-learned steps that can surface supply-chain hardware compromises once manifested as observable events; this is genuine detection capability but only a minority slice of the class because the technique is designed to be difficult to detect, occurs pre-deployment outside organizational visibility, and many hardware backdoors produce no detectable event until activation.
T1195.003responds — A.5.24 explicitly builds and exercises an incident response process (assess, respond to, contain, eradicate, escalate, recover, learn) that activates once a supply-chain hardware backdoor manifests as a detectable event or incident, independent of the pre-delivery insertion technique itself.
T1197detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for security events/incidents (including those using background mechanisms like BITS jobs), but the control is scoped by organizational priorities, event criteria, and chosen detection scope rather than mandating universal coverage of this technique.
T1197responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, escalating, coordinating, recovering from, and learning from incidents), which directly matches the `responds` verb once a BITS-abuse technique is underway.
T1199detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for information security events and incidents, which surfaces T1199 activity once the trusted-relationship abuse produces observable events (e.g. anomalous access or compromise of the third-party account), but the control's scope is limited to events the organization has chosen to monitor and does not guarantee detection of stealthy or pre-compromise supply-chain activity.
T1199prevents — A.5.24's incident management planning, detection, response, coordination with third parties, and lessons-learned improvements can constrain or deter some supply-chain/third-party compromise paths (e.g., via better monitoring of trusted relationships and post-incident hardening), but does not stop the initial abuse of an existing trusted connection or valid account.
T1199responds — A.5.24 explicitly builds and exercises incident response processes (assessing, responding to, containing, eradicating, escalating, coordinating parties, and learning from incidents) that activate once a trusted-relationship breach is underway, matching the `responds` verb; the named remainder is that the control does not itself perform the on-the-wire containment or eradication steps.
T1200detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means) as part of the incident management plan, which would surface many hardware additions once they trigger observable events, but this is limited to post-introduction detection of effects rather than the physical insertion itself and depends on the chosen scope of monitoring.
T1200responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, escalating, and learning from incidents) that activates once a hardware addition has been introduced and is operating as an access vector.
T1201detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces discovery activity when it registers as an anomalous security event; this is a genuine but minority slice because most password-policy-discovery executions are indistinguishable from legitimate admin activity and fall outside typical event criteria.
T1202detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for information security events and incidents, which surfaces T1202 abuse when it triggers an observable incident (e.g. via anomalous command execution), but the control is silent on specific detection of stealthy indirect execution techniques or their pre-incident indicators.
T1202responds — A.5.24 explicitly builds and exercises incident response processes (detection/triage/analysis/escalation/response to conclusion, coordination, root-cause, lessons learned) that activate once an indirect command execution incident is underway, containing/eradicating it per the event-lane definition of responds; the named remainder is that some stealthy instances may complete their payload before response begins.
T1203detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (by human or automatic means) plus logging, which surfaces T1203 exploitation attempts or their immediate effects once they occur.
T1203responds — A.5.24 explicitly builds and exercises the incident response process (assess, respond to, contain, eradicate, escalate, recover, learn) once an exploitation incident is underway, matching the `responds` verb; mostly because the control stops at procedural readiness and competent execution while the technique's full impact (arbitrary code already running) may require separate recovery controls.
T1204detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for information security events and incidents, which directly surfaces user-execution techniques (e.g. opening malicious documents or enabling RATs) once they occur.
T1204prevents — planning, training, procedures, detection, response and lessons-learned for incidents directly constrain the social-engineering and user-action slice of T1204 that produces observable events, but leave the pre-incident delivery (e.g. phishing lure itself) and non-incident user errors untouched
T1204responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, escalating, coordinating, recovering from, and learning from incidents) that directly acts on T1204 once the user-executed payload has run and the incident is underway.
T1204.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including those from user actions like clicking malicious links), with logging and root-cause processes that surface the technique once it occurs.
T1204.001prevents — planning, training, procedures, detection, response and post-incident improvements for competent personnel reduce the likelihood and success rate of users clicking malicious links (especially via social engineering awareness and coordinated handling), but do not stop the technique from being attempted or always succeeding
T1204.001responds — A.5.24 explicitly builds and activates an incident response process (assessment, response/escalation per 5.26, coordination, controlled recovery, root-cause, lessons learned) that acts on an already-underway T1204.001 execution event once the malicious link is clicked and follow-on behavior is detected.
T1204.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities that surface information security incidents, which directly includes user execution of malicious files (T1204.002) once the technique has produced observable effects.
T1204.002prevents — planning, procedures, training, detection/classification, and response processes reduce the chance a user will open (or successfully execute) a malicious file and limit follow-on impact, but do not stop the social-engineering delivery or user action itself
T1204.002responds — A.5.24 explicitly builds and exercises an incident response process (assess, respond to, contain, eradicate, recover, learn) that activates once a malicious-file execution event is underway as an information security incident.
T1204.003detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means) as part of the incident management plan, which surfaces malicious-image execution once it occurs, but the control is silent on any specific detection mechanisms or coverage for image backdoors, container runtimes or IaaS platforms.
T1204.003responds — A.5.24 explicitly builds and exercises the incident response process (assess/respond/learn, escalation, containment via crisis/continuity activation, root-cause, lessons-learned) once a malicious-image execution event is classified as an incident, with only the pre-detection naming/deception slice left outside its scope.
T1204.004detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means) as part of the incident management plan, which would surface the social-engineering-driven execution that follows a successful copy-paste, but does not itself instrument or guarantee detection of the copy-paste social engineering vector before execution occurs.
T1204.004responds — A.5.24 explicitly builds and exercises incident response processes (assess/respond/learn, escalation, containment via crisis/continuity activation, root-cause, lessons-learned) that activate once a user has executed the pasted malicious command and the technique is underway.
T1204.005detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces malicious library installation as an event when it occurs within monitored scope, but the control's detection is scoped by organizational priorities rather than mandating coverage of supply-chain library ingestion.
T1204.005responds — A.5.24 explicitly builds and exercises an incident response process (assess, respond to, contain, eradicate, learn) that activates once a malicious-library installation event is classified as an incident, matching the `responds` verb; the named remainder is that the control does not itself perform the on-the-wire or endpoint-level containment actions (those live in 5.26 and technical controls).
T1205detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces traffic signaling when observed as an anomalous event, but the control's scope is set by organizational priorities and does not mandate instrumentation that would reliably catch all variants (e.g. raw-socket, embedded-device, or Wake-on-LAN implementations).
T1205responds — A.5.24 explicitly builds and exercises an incident response process that activates on detected events, contains/eradicates the actor's signaling-based foothold, coordinates parties, logs, performs root-cause, and drives improvements once the technique is underway.
T1205.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via 8.16 references), which surfaces port-knocking signal packets as anomalous network behaviour when the chosen detection scope includes them.
T1205.001responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, learning from, and coordinating on incidents), which activates once a port-knocking-triggered persistence/C2 channel is detected as an information security incident.
T1205.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for security events/incidents (including those from network activity), but the technique's passive/low-activity/raw-socket nature is explicitly noted as difficult to detect, leaving a large residual slice unaddressed by the control's processes.
T1205.002responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, escalating, coordinating, recovering, and learning from incidents), which directly matches the `responds` verb once the socket-filter technique has executed and triggered its backdoor or C2.
T1207detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, root-cause analysis and post-mortem of incidents (including those that may bypass normal sensors), which surfaces rogue-DC registration and its downstream effects once they occur, but does not guarantee coverage of every stealth variant or pre-registration reconnaissance.
T1207responds — A.5.24 explicitly builds and exercises an incident response process (assess, respond to, learn from incidents; manage to conclusion with escalation, root-cause, lessons learned, and coordination), which directly acts on a T1207 event once underway to contain/eradicate it.
T1210detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (by human or automatic means) plus logging, root-cause analysis and post-mortem procedures, which directly surfaces T1210 exploitation attempts or artifacts once inside the network.
T1210responds — A.5.24 explicitly builds and exercises an incident response process (assess, respond to, contain, eradicate, escalate, recover, learn) that activates once an exploitation incident is underway, directly matching the `responds` verb; the named remainder is that it does not itself perform the on-the-wire containment that boundary-protection controls would add.
T1211detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities that surface stealthy exploitation used to suppress logging or hide in trusted components
T1211responds — A.5.24 explicitly builds and activates an incident response process (assessing, responding to, escalating, containing, recovering from, and learning from incidents), which directly engages once T1211 exploitation is detected as an information security incident.
T1212detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including those from exploitation), plus logging and root-cause activities that surface the technique.
T1212prevents — planning, training, procedures, detection, response, escalation, and post-incident improvements for credential-exploitation incidents constrain the technique's success window and reduce recurrence likelihood, but do not stop the initial vulnerability exploitation from occurring
T1212responds — A.5.24 explicitly builds and activates an incident response process (assessing, responding to, escalating, containing via crisis/continuity activation, controlled recovery, and learning) once an exploitation-for-credential-access incident is underway, matching the `responds` verb; the remainder is that not every credential-exploitation technique will trigger the full incident-management pipeline (e.g., undetected or low-severity cases).
T1213detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including those that could surface repository misuse or exfiltration), but this is only one slice of the broader incident management planning that does not guarantee detection of the technique itself.
T1213responds — A.5.24 explicitly builds and activates an incident response process (assessing, responding to, containing, eradicating, escalating, coordinating, recovering, and learning from incidents) that directly acts on T1213 once the repository exfiltration or abuse is underway.
T1213.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means) as part of the incident management plan, which surfaces adversary mining of a Confluence repository as an information security event.
T1213.001responds — A.5.24 explicitly builds and activates an incident response process (assessing, responding to, containing, eradicating, escalating, and learning from incidents) that directly engages once a Confluence data-mining event is classified as an incident, with only the pre-detection or non-incident slice left outside its scope.
T1213.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces adversary activity that mines SharePoint for sensitive information such as policies, diagrams, credentials or architecture details.
T1213.002responds — A.5.24 explicitly builds and activates an incident response process (assess/respond/learn, escalation per 5.26, coordination, recovery activation, post-mortem, lessons learned) once an information security incident is underway, which directly matches the `responds` verb for a data-exfiltration technique that has already succeeded in mining SharePoint.
T1213.003detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including those involving code repositories as data sources), but the control's scope is set by organizational priorities and does not mandate universal coverage of every possible repository access vector.
T1213.003responds — A.5.24 explicitly builds and activates an incident response process that contains, eradicates, escalates, coordinates, recovers from, and learns from security incidents (including those that began with repository access and data exfiltration), once the event is underway.
T1213.004detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including those involving data access in SaaS/CRM systems), which surfaces the T1213.004 technique once it is underway.
T1213.004responds — A.5.24 explicitly builds and exercises an incident response process (assess/respond/learn, escalation per 5.26, coordination, controlled recovery, root-cause/lessons) that activates once an incident is underway, containing/eradicating adversary activity that has already reached and is mining the CRM.
T1213.005detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting and logging of information security events and incidents (including those involving messaging apps as data sources or IR discussion leaks), but the control is scoped to organization-chosen criteria, tools and event types rather than mandating universal coverage of this specific adversary technique.
T1213.005responds — A.5.24 explicitly builds and activates an incident response process (including detection, triage, analysis, response/escalation per 5.26, coordination, root-cause, lessons learned) that directly contains and eradicates an adversary already mining chat data to evade ongoing IR efforts, with the named remainder being pre-response data already exfiltrated.
T1213.006detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including those involving data access from databases), which surfaces the T1213.006 technique when it triggers an observable event.
T1213.006responds — A.5.24 explicitly builds and activates an incident response process (assess/respond/learn, escalation, containment via crisis/continuity plans, recovery, root-cause, lessons) once an incident is underway, directly addressing database mining that has already succeeded and is producing exfiltration, extortion or lateral-movement impact.
T1216detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including by automatic means), which surfaces the proxy execution technique when it occurs.
T1216responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, escalating, recovering from, and learning from incidents), which directly matches the `responds` verb once T1216 execution is underway as an information security incident.
T1216.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for information security events and incidents (including those arising from abuse of signed scripts or proxy execution), but the control is scoped to organization-chosen criteria, tools, and telemetry rather than mandating coverage of this specific living-off-the-land technique.
T1216.001responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, escalating, coordinating, recovering from, and learning from incidents), which directly matches the `responds` verb once the PubPrn technique has executed and is underway.
T1216.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for information security events and incidents (including those arising from abuse of signed LOLBins such as SyncAppvPublishingServer.vbs to proxy PowerShell), but the clause sets scope by organisational priorities rather than mandating universal instrumentation depth, leaving detection of this technique dependent on whether the chosen monitoring covers the specific script invocation vector.
T1216.002responds — A.5.24 explicitly builds and exercises the incident response process (assessing, responding to, learning from incidents; escalation, containment via 5.26, root-cause, recovery activation) that activates once the T1216.002 technique has executed and produced a detectable security incident.
T1217detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting and logging of information security events and incidents (including by human or automatic means), which surfaces browser enumeration when treated as an event but does not mandate coverage of this specific technique or its artifacts.
T1217responds — A.5.24 explicitly builds and activates an incident response process that contains, eradicates, escalates, coordinates, and learns from security incidents once they are underway, directly addressing T1217 once browser enumeration has begun.
T1218detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by automatic means), which surfaces proxy execution of malicious content via trusted binaries as an observable event.
T1218responds — A.5.24 explicitly builds and exercises an incident response process that activates on detected events, contains/escalates the incident (including proxy-execution abuse of trusted binaries), coordinates parties, logs, performs root-cause, and drives improvements, which is the core meaning of `responds` once the technique is underway.
T1218.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (by human or automatic means) as core to the incident management plan, which surfaces T1218.001 abuse of hh.exe/CHM payloads once it occurs.
T1218.001responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, escalating, coordinating, recovering from, and learning from incidents), which directly matches the `responds` verb once a T1218.001 technique has executed and become an incident.
T1218.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (by human or automatic means) as part of the incident management plan, which surfaces this technique when it triggers an observable event.
T1218.002responds — A.5.24 explicitly builds and exercises the incident response process (assessing, responding to, containing, eradicating, escalating, and learning from incidents), which directly matches the `responds` verb once the T1218.002 technique has executed and produced a detectable security incident.
T1218.003detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including by automatic means), which surfaces CMSTP abuse as a malicious execution technique once it occurs.
T1218.003responds — A.5.24 explicitly builds and exercises an incident response process (assess/respond/learn, escalation per 5.26, coordination, root-cause, lessons-learned) that activates once the CMSTP abuse technique is underway, containing/eradicating the actor's foothold and bounding spread.
T1218.004detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by automatic means) as part of the incident management plan, which surfaces the InstallUtil proxy execution when observed but does not mandate coverage depth or specific detection for this technique.
T1218.004responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, escalating, and learning from incidents) that activates once the InstallUtil proxy-execution technique is underway.
T1218.005detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (by human or automatic means) as part of the incident management plan, which surfaces this technique when it occurs.
T1218.005prevents — A.5.24 requires establishing incident management processes, detection/monitoring capabilities, classification, response/escalation procedures, and training that can stop mshta-based execution from proceeding to full impact in many scenarios, but does not remove the underlying technique (e.g., no prohibition on mshta.exe or HTA execution) and leaves initial compromise vectors reachable.
T1218.005responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, escalating, coordinating, recovering from, and learning from incidents), which directly matches the `responds` verb once the mshta-based execution technique is underway.
T1218.007detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for information security events and incidents (including those from abuse of signed binaries like msiexec), but the control is scoped to organization-chosen criteria, tools, and competent personnel rather than mandating universal coverage of this specific technique.
T1218.007responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, escalating, and learning from incidents) that activates once the msiexec abuse technique is underway, matching the `responds` verb; the named remainder is that some execution paths (e.g., already-elevated SYSTEM payloads) may complete their impact before containment.
T1218.008detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting and logging of information security events and incidents (including by automatic means), which surfaces the anomalous use of a signed binary like odbcconf.exe for DLL execution; the remainder is that detection depends on what the organization actually instruments and tunes for this specific living-off-the-land technique.
T1218.008responds — A.5.24 explicitly builds and exercises incident response processes (assess/respond/learn, escalation per 5.26, coordination, controlled recovery) that activate once an abuse of a signed binary like odbcconf.exe is underway as an information security incident.
T1218.009detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including by automatic means), which surfaces this technique when it triggers an observable event, but the control's scope is set by organizational priorities, criteria, and procedures rather than mandating universal coverage of all possible Regsvcs/Regasm abuse.
T1218.009responds — A.5.24 explicitly builds and exercises an incident response process (assess/respond/learn, escalation per 5.26, coordination, controlled recovery) that activates once an incident is recognized, containing and eradicating the Regsvcs/Regasm proxy-execution technique while it is underway.
T1218.010detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities that surface the use of living-off-the-land binaries such as Regsvr32 for proxy execution, with the bounded remainder being detections that fall outside the organisation's defined scope or require specific telemetry not mandated by the clause.
T1218.010responds — A.5.24 explicitly builds and exercises the incident response process (assessing, responding to, containing, eradicating, escalating, coordinating, recovering from, and learning from incidents), which directly matches the `responds` verb once the Regsvr32 technique has executed and is underway.
T1218.011detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for security events/incidents (including those using proxy binaries like rundll32), but the control is governance-oriented and does not itself instrument or guarantee detection of this specific technique.
T1218.011responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, escalating, coordinating, recovering from, and learning from incidents), which directly matches the `responds` verb once the rundll32 proxy execution technique is underway as an information security incident.
T1218.012detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including by automatic means), which surfaces the anomalous use of verclsid.exe as a living-off-the-land binary proxy; the remainder is that the clause sets scope by organizational priorities rather than mandating universal depth of telemetry on every LOLBin invocation.
T1218.012responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, escalating, and learning from incidents once underway), which directly matches the `responds` verb for a technique that has already executed.
T1218.013detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting and logging of information security events and incidents (including by automatic means), which surfaces the mavinject.exe abuse when observed as an anomalous or malicious event.
T1218.013responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, escalating, coordinating, recovering from, and learning from incidents), which directly matches the `responds` verb once a living-off-the-land injection technique like T1218.013 is underway.
T1218.014detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities that surface the technique (MMC abuse of .msc/CLSID for proxy execution or downstream effects like T1490) once it runs.
T1218.014responds — A.5.24 explicitly builds and exercises incident response processes that contain, eradicate, escalate, coordinate, recover and learn from an incident once it is underway, which directly matches the `responds` verb against any technique (including this signed-binary proxy for malicious .msc execution).
T1218.015detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (by human or automatic means) as part of the incident management plan, which surfaces the technique when it manifests as an observable event.
T1218.015responds — A.5.24 explicitly builds and exercises incident response processes (assess/respond/learn, escalation, containment via crisis/continuity activation, root-cause, lessons-learned) that act on an already-underway technique once detected, exactly matching the `responds` verb; the named remainder is that some Electron abuse may complete its payload (e.g. calc.exe) before containment bounds further spread.
T1219detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for information security events and incidents, which directly surfaces post-compromise use (or abuse) of remote access tools as an incident
T1219responds — A.5.24 explicitly builds and exercises the incident response process (assessing, responding to, escalating, coordinating, recovering from, and learning from incidents), which directly contains and eradicates an active T1219 C2 session once detected as an incident.
T1219.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, logging and reporting of information security events and incidents (including via human or automatic means), which surfaces IDE tunneling when observed as anomalous but does not mandate coverage of all possible developer-workflow or extension-based instances.
T1219.001responds — A.5.24 explicitly builds and activates incident response processes (assessment, response/escalation per 5.26, coordination, containment via crisis/continuity activation, recovery, lessons learned) once an incident is underway, which directly matches the `responds` verb for an established C2/persistence technique like IDE tunneling.
T1219.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (by human or automatic means) as core incident management capabilities, which surfaces the use of remote desktop software for C2 once it occurs.
T1219.002responds — A.5.24 explicitly builds and exercises an incident response process (assess/respond/learn, escalation per 5.26, coordination, controlled recovery) that activates once an allowed legitimate remote-desktop C2 channel is underway as an incident.
T1219.003detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including post-compromise hardware use as an alternate C2 channel), but the control's scope is set by organizational priorities, criteria, and procedures rather than mandating universal coverage of all possible hardware-based techniques.
T1219.003responds — A.5.24 explicitly builds and exercises an incident response process (assess, respond to, contain, eradicate, escalate, recover, learn) that activates once an incident is declared, directly addressing post-compromise hardware C2 use as an ongoing event.
T1220detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for information security events and incidents (including those arising from execution techniques), which surfaces T1220 when it triggers an observable incident.
T1220responds — A.5.24 explicitly builds and exercises incident response processes that assess, contain, eradicate, escalate, recover from, and learn from realized incidents (including those using living-off-the-land binaries and script interpreters), which is the core meaning of `responds`; the named remainder is that the control is agnostic to the specific T1220 delivery vector.
T1221detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (by human or automatic means) plus logging, which surfaces template injection when it manifests as a detectable event, but the clause's scope is set by organizational priorities and does not mandate coverage of this specific technique.
T1221responds — A.5.24 explicitly builds and exercises the incident response process (assess, respond to, learn from incidents; manage to conclusion with escalation, recovery, root-cause, lessons learned) once an injected template document has triggered execution or forced authentication.
T1222detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for information security incidents and events, which surfaces T1222 when it triggers an observable incident (e.g. ransomware symlink tampering); it does not instrument or guarantee detection of every stealthy permission change that never escalates to an incident.
T1222responds — A.5.24 explicitly builds and exercises the incident response process (assessing, responding to, containing, eradicating, escalating, and learning from incidents), which directly matches the `responds` verb once T1222 has run as part of an information security incident.
T1222.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for information security events and incidents, which can surface T1222.001 when it triggers an observable event; the remainder is that many permission modifications are silent, non-incident, or below the event-classification threshold.
T1222.001responds — A.5.24 explicitly builds and exercises an incident response process that includes detection, classification, analysis, response/escalation, coordination, recovery, root-cause, and lessons-learned steps once an incident is underway; T1222.001's permission-modification artifact is directly addressable by those steps (e.g., contained, evidence-handled, rolled back, and learned from).
T1222.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for information security events and incidents, which can surface permission-modification activity when it is treated as an event (e.g. via anomalous chown/chmod or ACL changes), but the control is scoped to incident-management processes rather than mandating continuous host-level detection of every T1222.002 instance.
T1222.002responds — A.5.24 explicitly builds and exercises the incident response process (assessing, responding to, containing, eradicating, escalating, and learning from incidents), which directly addresses an in-flight T1222.002 permission modification once it is detected as part of a security incident.
T1480detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by automatic means), which surfaces guardrail-based execution as an anomalous or malicious event once it occurs.
T1480.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including those that slow or complicate response), which surfaces environmental keying when it triggers observable incident artifacts, but does not guarantee detection of the keying mechanism itself or its stealthy delivery.
T1480.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, logging and reporting of information security events and incidents (including by automatic means), which surfaces mutex-based single-instance checks when they produce observable artifacts or anomalous behavior within the defined scope of the incident management plan.
T1480.002responds — A.5.24 explicitly builds and exercises an incident response process (assess, respond to, learn from incidents; manage to conclusion with escalation, recovery, root-cause, lessons learned) that activates once a mutex-based instance check has already run and produced an infection event.
T1482detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by automatic means), which surfaces domain-trust discovery when treated as an event; the remainder is that the clause does not mandate instrumentation depth or coverage of every possible discovery method (e.g. specific LDAP queries or nltest usage).
T1482responds — A.5.24 explicitly builds and activates an incident response process that includes detection, classification, analysis, response/escalation, coordination, and learning once an information security incident (including discovery/enumeration activity) is underway.
T1484detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause/post-mortem of incidents (including those from policy modifications that enable broader attacks), providing broad detection coverage once the technique runs, with only a bounded remainder for stealthy or reverted changes that evade initial event criteria.
T1484responds — A.5.24 explicitly builds and exercises the incident response process (assessing, responding to, containing, eradicating, escalating, coordinating, recovering, and learning from incidents), which directly matches the `responds` verb once T1484 has executed and produced detectable policy-modification artifacts or downstream effects.
T1484.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for information security events and incidents (including those that could manifest as GPO modification), but the control is scoped to post-event incident management rather than continuous or preventive detection of the technique itself.
T1484.001responds — A.5.24 explicitly builds and exercises the incident response process (assess, respond to, contain, eradicate, escalate, recover, learn) once an incident is underway, directly addressing T1484.001 when it is detected as a security incident.
T1484.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for information security events and incidents (including those that could involve trust modifications), but the control is scoped to what the organization defines as an incident and does not mandate instrumentation that would surface the specific technique in all cases.
T1484.002responds — A.5.24 explicitly builds and activates an incident response process that contains, eradicates, escalates, coordinates, and learns from security incidents (including those that realize T1484.002), with only the already-realized privilege/escalation impact left for separate recovery controls.
T1485detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause/post-mortem procedures for information security incidents, which directly surfaces data-destruction events once they occur.
T1485recovers — A.5.24 explicitly requires procedures for controlled recovery from an incident, activation of continuity plans, root cause analysis, lessons learned, and restoration of availability after data destruction occurs.
T1485responds — A.5.24 explicitly builds and exercises incident response processes that assess, contain, eradicate, escalate, recover from, and learn from security incidents (including data-destruction events), which is the core meaning of `responds`; the named remainder is that the control stops at procedural readiness and does not itself perform the on-the-wire containment or eradication actions.
T1485.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for information security events and incidents, which surfaces lifecycle-policy modifications that destroy cloud objects (especially when tied to extortion, theft, or indicator removal).
T1485.001recovers — A.5.24 requires planning for controlled recovery from an incident (including activation of continuity plans) and post-incident root-cause/lessons-learned that can restore deleted objects via backups or other means, directly addressing the data destruction outcome of this technique.
T1485.001responds — A.5.24 explicitly builds and activates an incident response process (including detection, classification, response/escalation per 5.26, coordination, recovery activation, root-cause, and lessons-learned) that directly acts on a realized T1485.001 event once underway to contain, eradicate, communicate, and improve.
T1486detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities that surface an encryption-for-impact incident once it is underway or has occurred.
T1486recovers — A.5.24 explicitly requires procedures for controlled recovery from an incident, activation of continuity plans, root-cause analysis, lessons learned, and restoration of normal operations after a ransomware-style encryption event.
T1486responds — A.5.24 explicitly builds and exercises the incident response process (assessing, responding to, containing, eradicating, escalating, coordinating, recovering, learning) once an encrypting-ransomware incident is underway, matching the `responds` verb; the named remainder is that some early-impact encryption (pre-detection) cannot be undone by response alone.
T1489detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause/post-mortem of incidents (including those that stop critical services to inhibit response), providing broad detection coverage across the technique's scenarios.
T1489responds — A.5.24 explicitly builds and exercises incident response processes (assessing, responding to, containing, eradicating, escalating, coordinating, recovering, and learning from incidents), which directly counters T1489 when it is used to inhibit or stop incident response itself.
T1490detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including those that could match T1490 activity such as deletion of recovery features or backups), but detection is only one slice of the broader planning/preparation/control that also covers response, recovery, and procedures.
T1490recovers — A.5.24 explicitly requires planning/preparation of incident management that includes activation of continuity plans, controlled recovery from an incident, root-cause/post-mortem, lessons learned, and improvements to controls — directly addressing restoration after T1490 has run.
T1490responds — A.5.24 explicitly builds and activates incident response processes that include assessing, responding to, escalating, coordinating, and managing incidents to conclusion (including activating continuity plans and controlled recovery), which directly matches the `responds` verb once T1490 is underway.
T1491detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including those that could manifest as defacement), with procedures for evaluation, logging, root-cause analysis and post-incident learning that surface the technique once it has run.
T1491recovers — A.5.24 explicitly requires procedures for controlled recovery from an incident, root-cause analysis, lessons learned, and improvements that restore integrity and availability after a defacement (T1491) has altered visual content.
T1491responds — A.5.24 explicitly builds and exercises an incident response process that includes assessing, responding to, containing, escalating, coordinating, recovering from, and learning from incidents (including those that manifest as visible defacement), which matches the `responds` verb once the technique has run.
T1491.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including post-intrusion defacement as an integrity-impacting event), with procedures, logging, and competent personnel to surface it.
T1491.001recovers — A.5.24 explicitly requires procedures for controlled recovery from an incident, root-cause analysis, lessons learned, and improvements that restore system integrity after internal defacement has occurred.
T1491.001responds — A.5.24 explicitly builds and exercises incident response processes for assessing, responding to, containing, eradicating, escalating, and learning from security incidents (including those that discredit system integrity), once the defacement technique has already run.
T1491.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by automatic means), which surfaces external defacement when it occurs as an incident.
T1491.002recovers — A.5.24 explicitly requires procedures for controlled recovery from an incident, root-cause analysis, lessons learned, and improvements that restore trust/integrity after external defacement has occurred.
T1491.002responds — A.5.24 explicitly builds and exercises an incident response process (assess, respond to, contain, eradicate, communicate, recover, learn) that activates once an external defacement incident is underway, matching the `responds` verb; the named remainder is that the control does not itself perform the hands-on containment/eradication steps (those live in A.5.26).
T1495detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause/post-mortem of incidents (including those from firmware corruption that renders devices inoperable), but this is scoped to events that have already occurred and does not guarantee detection of the technique itself in all cases (e.g., pre-boot or non-monitored hardware).
T1495recovers — A.5.24 explicitly requires procedures for controlled recovery from an incident, activation of continuity plans, root-cause analysis, lessons learned, and restoration of affected systems after firmware corruption has occurred.
T1495responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, escalating, recovering from, and learning from incidents), which directly matches the `responds` verb once a T1495 firmware-corruption event is underway.
T1496detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by automatic means), which surfaces resource hijacking techniques once they are underway.
T1496recovers — A.5.24 explicitly requires procedures for controlled recovery from an incident, activation of continuity plans, root-cause analysis, lessons learned, and restoration of normal operations after resource-hijacking impacts availability.
T1496responds — A.5.24 explicitly builds and activates an incident response process (assessing, responding to, escalating, containing via crisis/continuity plans, controlled recovery, root-cause, lessons learned) once an incident such as resource hijacking is underway.
T1496.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by automatic means), which surfaces compute hijacking as anomalous resource consumption or malware behavior once it is underway.
T1496.001recovers — A.5.24 explicitly requires procedures for controlled recovery from an incident, activation of continuity plans, root-cause analysis, and post-incident improvements that restore availability after compute-hijacking impact (e.g., resource exhaustion and unresponsiveness) has occurred.
T1496.001responds — A.5.24 explicitly builds and exercises an incident response process (assess, respond to, contain, eradicate, escalate, recover, learn) that activates once a compute-hijacking incident is underway, matching the `responds` verb; the named remainder is that the control stops at procedural readiness and does not itself perform the on-the-wire containment or eradication steps.
T1496.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for information security incidents and events, which directly surfaces bandwidth-hijacking activity (DoS impact, anomalous traffic, botnet/proxy behavior) once it is underway.
T1496.002recovers — A.5.24 explicitly requires procedures for controlled recovery from an incident, activation of continuity plans, and post-incident root-cause/lessons-learned that restore availability after bandwidth-hijacking impact occurs.
T1496.002responds — A.5.24 explicitly builds and activates an incident response process that assesses, contains, eradicates, escalates, coordinates, recovers and learns from bandwidth-hijacking incidents once they are underway, matching the `responds` verb; the named remainder is that some proxyjacking or botnet activity may already have produced irreversible reputational or legal consequences before containment.
T1496.003detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by automatic means), which surfaces SMS pumping as anomalous messaging traffic or cost spikes before or while it overwhelms channels.
T1496.003prevents — A.5.24 requires establishing incident management processes, detection/monitoring, classification, response/escalation, and learning/improvements that can prevent SMS pumping from reaching full impact or recurrence once initial events are recognized as incidents, but does not stop the initial abuse of public forms or messaging infrastructure before it runs.
T1496.003recovers — A.5.24 explicitly requires procedures for controlled recovery from an incident, activation of continuity plans, and post-incident root-cause/lessons-learned that restore availability and communication channels overwhelmed by SMS pumping.
T1496.003responds — A.5.24 explicitly builds and exercises incident response processes that assess, contain, eradicate, escalate, recover from, and learn from security incidents (including availability-impacting abuse of messaging services), once the SMS-pumping event is already underway.
T1496.004detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces SaaS hijacking techniques that consume resources or enable spam/LLMJacking once they are underway.
T1496.004prevents — planning/roles/procedures/training for incident management (including detection, classification, response, escalation, and coordination) can stop the technique from completing or succeeding in many scenarios by enabling rapid detection and containment before full resource exhaustion or quota burn occurs, but this is only a slice of the class since the control does not address initial compromise, service enablement, or technical blocks on abuse.
T1496.004recovers — A.5.24 explicitly requires procedures for controlled recovery from an incident, activation of continuity plans, root cause analysis, lessons learned, and improvements that restore availability and service state after SaaS hijacking impacts quotas, costs, and hosted availability.
T1496.004responds — A.5.24 explicitly builds and requires an incident response process (assessing, responding to, containing, eradicating, escalating, coordinating, recovering from, and learning from incidents), which directly matches the `responds` verb once the SaaS-hijacking technique is underway as an information security incident.
T1497detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by automatic means), which surfaces sandbox/VME evasion artifacts when they trigger observable events, but the control is scoped to incident management rather than mandating comprehensive pre-execution or code-level detection of all evasion methods.
T1497.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means) as part of building incident management capability, which surfaces the T1497.001 technique when it manifests as observable system-check or discovery behavior during an event.
T1497.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by human or automatic means) as part of building detection and response capability; this surfaces the T1497.002 technique when it triggers observable events, but the control is scoped only to events the organization has chosen to monitor per its requirements and does not guarantee coverage of stealthy sandbox-evasion checks that produce no detectable incident.
T1497.003detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by automatic means), which surfaces sandbox-detection techniques like T1497.003 when they trigger an observable event, but the control's scope is limited to events that meet the organization's defined incident criteria rather than all possible sandbox checks.
T1497.003responds — A.5.24 explicitly builds and exercises an incident response process that contains, eradicates, escalates, coordinates, recovers and learns from security incidents once they are underway, which matches the `responds` verb against any technique (including time-based sandbox evasion) that has already executed inside a compromised environment.
T1498detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for security events and incidents, which surfaces Network DoS (a bandwidth-exhausting availability attack) once underway.
T1498recovers — A.5.24 explicitly requires procedures for controlled recovery from an incident, activation of continuity plans, root cause analysis, lessons learned, and restoration of service after a disruptive event such as Network DoS.
T1498responds — A.5.24 explicitly builds and activates an incident response process that assesses, contains, escalates, coordinates, recovers from, and learns from security incidents (including availability-impacting network events), which matches the `responds` verb once the DoS technique is underway.
T1498.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by automatic means), which surfaces a direct network flood once it is underway.
T1498.001recovers — A.5.24 explicitly requires procedures for controlled recovery from an incident, activation of continuity plans, root-cause analysis, lessons learned, and restoration of normal operations after a flood-induced availability loss.
T1498.001responds — A.5.24 explicitly builds and exercises an incident response process (assess, respond to, escalate, contain per type/category, coordinate, recover controllably, learn) that activates once a flood event is classified as an incident, matching the `responds` verb; the named remainder is that pure volumetric saturation can still realize impact before containment completes.
T1498.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by automatic means), which surfaces reflection amplification DoS in flight as an incident.
T1498.002recovers — A.5.24 explicitly requires procedures for controlled recovery from an incident, activation of continuity plans, and post-incident restoration of availability after a DoS event such as reflection amplification has occurred.
T1498.002responds — A.5.24 explicitly builds and exercises the incident response process (assess, respond to, contain, eradicate, escalate, recover, learn) once an information security incident is underway, which directly matches the verb `responds` for a realized reflection-amplification DoS event.
T1499detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for information security incidents (including availability-impacting ones like endpoint DoS), providing broad detection coverage once the technique is underway.
T1499prevents — planning, procedures, training, detection, response/escalation, and recovery steps in A.5.24 reduce the likelihood and success rate of an endpoint DoS technique reaching full impact, but do not stop the adversary from launching the resource-exhausting or crash-inducing actions themselves
T1499recovers — A.5.24 explicitly requires procedures for controlled recovery from an incident, activation of continuity plans, root-cause analysis, lessons learned, and restoration of service availability after an Endpoint DoS has occurred.
T1499responds — A.5.24 explicitly builds and exercises the incident response process (assess, respond to, contain, eradicate, escalate, recover, learn) once an Endpoint DoS incident is underway, matching the `responds` verb; the named remainder is that pure-prevention or pure-detection slices sit with other controls.
T1499.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by automatic means), which surfaces OS-exhaustion floods as incidents once underway.
T1499.001recovers — A.5.24 explicitly requires procedures for controlled recovery from an incident, activation of continuity plans, and post-incident root-cause/lessons-learned that restore service after an OS-exhaustion flood has occurred.
T1499.001responds — A.5.24 explicitly builds and exercises incident response processes (assess, respond, escalate, coordinate, recover, learn) that activate once an OS-exhaustion flood is underway as an information security incident.
T1499.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by automatic means), which surfaces service-exhaustion floods as incidents once they occur.
T1499.002recovers — A.5.24 explicitly requires procedures for controlled recovery from an incident, activation of continuity plans, root cause analysis, lessons learned, and restoration of service after a DoS flood exhausts resources.
T1499.002responds — A.5.24 explicitly builds and activates an incident response process that assesses, contains, escalates, coordinates, recovers from, and learns from security incidents (including availability-impacting DoS floods once underway), with only minor residual scope outside its defined scenarios.
T1499.003detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by automatic means), which surfaces application-exhaustion floods as incidents once they occur.
T1499.003prevents — planning, procedures, training, detection, response/escalation, and recovery steps in A.5.24 reduce the likelihood and duration of successful application-exhaustion floods by enabling faster triage and containment, but do not stop the initial technique from running or exhaust the resource-intensive features themselves
T1499.003recovers — A.5.24 explicitly requires procedures for controlled recovery from an incident, activation of continuity plans, and post-incident restoration to meet availability objectives after a DoS event like application exhaustion has occurred.
T1499.003responds — A.5.24 explicitly builds and activates an incident response process that contains, escalates, coordinates, recovers from, and learns from security incidents (including availability-impacting DoS events like application exhaustion floods) once they are underway.
T1499.004detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (by human or automatic means) plus logging and root-cause activities, which directly surfaces this DoS-via-exploitation technique once it manifests as a detectable event.
T1499.004recovers — A.5.24 explicitly requires procedures for controlled recovery from an incident, activation of continuity plans, root-cause analysis, lessons learned, and restoration of availability after a DoS-producing crash/exploitation has occurred.
T1499.004responds — A.5.24 explicitly builds and activates an incident response process (assessing, responding to, containing, escalating, coordinating, recovering from, and learning from incidents) that directly acts on an in-flight exploitation causing DoS once it is detected as an event/incident.
T1505detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for security events/incidents, which surfaces server software component abuse once it manifests as an observable incident (per 8.16 cross-references), but only a minority slice of T1505's stealthy/persistent installation techniques on diverse platforms falls inside typical incident detection scope.
T1505responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, escalating, and learning from incidents) that activates once a malicious server component is installed and running, directly matching the `responds` verb; the named remainder is that early/pre-install detection lives in monitoring clauses rather than response.
T1505.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for information security events and incidents, which surfaces the T1505.001 technique when it triggers an observable event (e.g. anomalous stored-procedure creation or execution), but the control's scope is limited to what the organization elects to instrument and does not guarantee detection of stealthy or non-event-triggering abuse.
T1505.001responds — A.5.24 explicitly builds and exercises an incident response process that assesses, contains, eradicates, escalates, coordinates, logs, and learns from security incidents (including those using malicious stored procedures for persistence), once the technique has already run.
T1505.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for information security events and incidents (including those that could arise from malicious registered transport agents providing persistence), but the control is scoped to the organization's defined criteria, processes, and competent personnel rather than guaranteeing detection of every possible T1505.002 implementation.
T1505.002responds — A.5.24 explicitly builds and exercises an incident response process (assess/respond/learn, escalation per 5.26, coordination, root-cause, lessons-learned) that activates once a malicious transport agent has been registered and triggered, containing/eradication the persistence mechanism while the technique is already underway.
T1505.003detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (by human or automatic means) as core incident management capabilities, which surfaces web shell persistence after it is placed.
T1505.003responds — A.5.24 explicitly builds and exercises the incident response process (assessing, responding to, containing, eradicating, escalating, and learning from incidents once underway), which directly matches the `responds` verb for a deployed web-shell persistence technique.
T1505.004detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities that surface IIS component installation and related anomalous behavior once the technique has run.
T1505.004responds — A.5.24 explicitly builds and exercises the incident response process (assessing, responding to, escalating, coordinating, recovering from, and learning from incidents), which directly contains and eradicates an already-underway T1505.004 persistence implant once it is classified as an incident.
T1505.005detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, logging and reporting of information security events and incidents (including those that could enable persistence), but the clause's scope is set by organizational priorities and does not mandate instrumentation that would necessarily surface a termsrv.dll modification or ServiceDll registry change.
T1505.005responds — A.5.24 explicitly builds and exercises the incident response process (assessing, responding to, containing, eradicating, escalating, coordinating, recovering, and learning from incidents), which directly matches the `responds` verb once the T1505.005 persistence technique has executed and is underway.
T1505.006detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause/post-mortem of incidents (including those from malicious VIB installation and persistence), but the control is scoped to incident management after the fact rather than continuous host/VMware-specific detection mechanisms.
T1505.006responds — A.5.24 explicitly builds and exercises incident response processes (assessment, response/escalation per 5.26, coordination, containment via crisis/continuity activation, recovery, root-cause, lessons learned) that act on an already-underway persistence technique once it is detected as an incident.
T1518detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces the T1518 technique when it triggers observable events, but the control's scope is limited to declared incident-management events rather than mandating broad telemetry that would catch all stealthy discovery executions.
T1518responds — A.5.24 explicitly builds and activates an incident response process (assessing, responding to, containing, eradicating, escalating, and learning from incidents) that activates once discovery activity is recognized as an information security incident, directly addressing the T1518 technique once underway.
T1518.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by automatic means), which surfaces the discovery technique when it produces observable events, but the control's scope is limited to events that meet incident criteria and does not mandate instrumentation of all possible discovery commands or API calls.
T1518.001responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, learning from, and coordinating on incidents), which activates once discovery of security software (or its absence) has already occurred and shaped follow-on adversary behavior.
T1518.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for information security events and incidents, which can surface backup-software discovery as anomalous behavior or as part of an incident, but the control is scoped to incident-management processes rather than continuous or comprehensive endpoint telemetry that would catch all instances of the technique.
T1518.002responds — A.5.24 explicitly builds and exercises an incident response process that includes detection/classification of events, managing incidents to conclusion with response/escalation, coordination, root-cause analysis, and learning/improvements once an incident is underway, which directly matches the `responds` verb against discovery techniques like T1518.002 that frequently precede ransomware impact.
T1525detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means) as part of the incident management plan, which surfaces the T1525 technique once the backdoored image is used or otherwise observable.
T1525responds — A.5.24 explicitly builds and exercises the incident response process (assess, respond to, contain, eradicate, learn from incidents including those from implanted images), matching the `responds` verb once the technique has run and is underway.
T1526detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces cloud service discovery as an anomalous event once it occurs.
T1526responds — A.5.24 establishes incident response processes, procedures for detection/classification/analysis/escalation of events, coordination, and learning from incidents, which directly enables responding to (containing/eradicating) T1526 once the enumeration is detected as an incident in flight.
T1528detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (by human or automatic means) plus logging, which surfaces token theft as an incident once it occurs.
T1528prevents — A.5.24 requires establishing incident management processes, detection/monitoring, classification, response/escalation, root-cause analysis, and lessons-learned improvements that can prevent recurrence of token-theft techniques (e.g., via OAuth phishing or container compromise) in future incidents, but this is governance/preparation that does not stop the initial technique from running.
T1528recovers — A.5.24 explicitly requires procedures for controlled recovery from an incident, activation of continuity plans, root cause analysis, lessons learned, and improvements that restore capabilities after token theft has occurred.
T1528responds — A.5.24 explicitly builds and exercises incident response processes (assess/respond/learn, escalation, containment via coordination/continuity plans, root-cause, lessons-learned) that activate once token theft is recognized as an incident, directly matching the `responds` verb; the named remainder is that some social-engineering paths may complete before detection/response begins.
T1529detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause/post-mortem of incidents (including those that impede response/recovery), which surfaces T1529 when it occurs as an incident.
T1529recovers — A.5.24 explicitly requires procedures for controlled recovery from an incident, activation of continuity plans, root-cause analysis, lessons learned, and restoration of operations after an incident (including one that used shutdown/reboot to impede recovery), which directly enacts the recovers verb against T1529's availability impact.
T1529responds — A.5.24 explicitly builds and exercises incident response processes that include assessing, responding to, containing/escalating, coordinating, and learning from incidents (including those that impair availability or recovery), which directly matches the `responds` verb once T1529 is underway.
T1530detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for information security events and incidents, which directly surfaces T1530 when it manifests as a detectable cloud-storage access event (misconfiguration, anomalous API call, or credential abuse).
T1530responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, escalating, coordinating, recovering, and learning from incidents), which directly matches the `responds` verb once a T1530 data-access event is underway.
T1531detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause/post-mortem of incidents (including those that impede response/recovery), which surfaces T1531 when it occurs as part of an incident.
T1531recovers — A.5.24 explicitly requires procedures for controlled recovery from an incident, root-cause analysis, lessons learned, and improvements that restore account access and related resources after T1531 has run, with the bounded remainder being any unaddressed pre-incident account states or external dependencies not covered in the plan.
T1531responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, escalating, coordinating, recovering from, and learning from incidents), which directly addresses containment/eradication once T1531 is underway as part of a ransomware or availability attack; the named remainder is that some pre-response impact (e.g., already-locked accounts) is bounded by the next verb (recovers).
T1534detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (by human or automatic means) plus logging and root-cause activities, which surface internal spearphishing campaigns once underway.
T1534prevents — A.5.24 requires establishing incident management processes, detection/monitoring, classification, response/escalation, and training that can stop an internal spearphishing campaign once the initial compromise or first phishing event is spotted, but does not stop the adversary's initial foothold, credential compromise, or the multi-staged phishing technique itself from being attempted or succeeding in the first place.
T1534responds — A.5.24 explicitly builds and exercises the incident response process (assess, respond to, learn from incidents; manage to conclusion with escalation, containment via crisis/continuity activation, root-cause, lessons learned) once an internal spearphishing event is underway, with the named remainder being pre-detection or pre-classification latency.
T1535detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via automatic means), which surfaces the creation and operation of resources in unused/unmonitored regions as an anomalous event, but only to the extent the organization's chosen detection scope and tooling actually covers those regions.
T1535responds — A.5.24 explicitly builds and exercises an incident response process (assess/respond/learn, escalation, coordination, root-cause, lessons learned) that activates once an incident is underway, containing/eradicating activity such as unauthorized cloud-instance creation in unused regions.
T1537detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including via human or automatic means), which surfaces T1537 activity once it occurs as an incident.
T1537prevents — A.5.24 requires establishing incident management processes, detection/monitoring capabilities, classification, response/escalation procedures, and coordination that can stop or contain an in-progress T1537 exfiltration (e.g., via detection of anomalous internal transfers or backups and rapid response), but this is after the technique has begun running and does not stop the adversary from initiating the transfer itself.
T1537responds — A.5.24 explicitly builds and activates an incident response process (assess/respond/learn, escalation per 5.26, coordination, controlled recovery) that directly acts on T1537 once the exfiltration event is underway, containing/eradicating it; mostly because the control's scope is bounded to declared incidents rather than every undetected internal-cloud transfer.
T1538detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including those from compromised credentials), which surfaces the dashboard-based enumeration technique once it is underway.
T1538responds — A.5.24 explicitly builds and activates an incident response process (assessing, responding to, escalating, containing, recovering from, and learning from incidents), which directly acts on T1538 once the adversary is using stolen credentials in the dashboard to enumerate cloud assets.
T1539detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for information security events and incidents, which directly surfaces T1539 behaviors such as malware stealing cookies, malicious JS injection, or proxy-based theft once they trigger observable events.
T1539responds — A.5.24 explicitly builds and activates an incident response process that assesses, contains, escalates, coordinates, recovers from, and learns from realized incidents (including those that steal session cookies), matching the `responds` verb once the technique has run.
T1542detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, root-cause analysis and post-mortem of incidents (including those from pre-OS persistence), but the control's scope is post-event organizational processes rather than real-time technical detection of firmware/bootkit artifacts that host defenses miss.
T1542recovers — A.5.24 explicitly requires procedures for controlled recovery from an incident, activation of continuity plans, root cause analysis, lessons learned, and improvements that can restore state after a Pre-OS Boot persistence technique has executed.
T1542responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, escalating, coordinating, recovering, learning) that activates once a pre-OS boot persistence technique has executed and is underway, with only the already-realized firmware overwrite remaining outside its direct containment boundary.
T1542.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, root cause analysis and post-mortem of incidents (including those from firmware modification), but this is scoped to events that have already manifested as detectable incidents rather than reliably catching the low-level, hard-to-observe firmware overwrite itself.
T1542.001responds — A.5.24 explicitly builds and activates an incident response process that contains, eradicates, escalates, coordinates, recovers and learns from incidents (including those using firmware persistence), once the technique has already run.
T1542.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, root-cause, and post-mortem of incidents (including those from firmware persistence), but this is scoped to events that have already manifested as detectable incidents rather than reliably catching the sophisticated, low-level firmware modification itself before or at the moment it occurs.
T1542.002recovers — A.5.24 explicitly requires procedures for controlled recovery from an incident, activation of continuity plans, root cause analysis, lessons learned, and improvements that restore state after a firmware compromise has occurred.
T1542.002responds — A.5.24 explicitly builds and exercises an incident response process (assess/respond/learn, escalation, containment via crisis/continuity activation, controlled recovery, evidence handling, root-cause, lessons-learned) that activates once a firmware-modification incident is underway, exactly matching the `responds` verb.
T1542.003detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means) as part of the incident management plan, which surfaces a bootkit once it triggers observable events, but the technique's pre-OS nature and low-level persistence leave many instances undetected until after execution or impact.
T1542.003recovers — A.5.24 explicitly requires procedures for controlled recovery from an incident, activation of continuity plans, root-cause analysis, lessons learned, and improvements that restore state after a bootkit has executed and persisted below the OS.
T1542.003responds — A.5.24 explicitly builds and exercises an incident response process that includes detection/classification, response/escalation, coordination, controlled recovery, root-cause analysis, and lessons-learned improvements once an incident is underway, directly addressing the bootkit's post-execution phase even though full remediation can remain difficult.
T1542.004detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause/post-mortem of incidents (including those from firmware/boot changes), but this is scoped to the organization's chosen detection criteria and does not guarantee coverage of stealthy ROMMON firmware manipulation on network devices.
T1542.004responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, escalating, coordinating, recovering, learning) once an incident is underway, which directly matches the `responds` verb for a ROMMONkit persistence technique that has already executed.
T1542.005detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause/post-mortem of incidents (including those from boot-time or configuration manipulation on network devices), but this is scoped to events that have already triggered an incident rather than reliably surfacing the pre-incident configuration change or TFTP abuse itself.
T1542.005responds — A.5.24 explicitly builds and exercises incident response processes that assess, contain, eradicate, communicate on, and learn from security incidents (including those involving unauthorized boot images or modified device state), once the technique has already run and produced impact.
T1543detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for security events/incidents, which surfaces T1543 when it manifests as a detectable incident but does not guarantee detection of all stealthy or pre-incident instances.
T1543responds — A.5.24 explicitly builds and activates an incident response process (assessment, response/escalation per 5.26, coordination, containment to conclusion, recovery activation) once an incident is underway, which directly matches the `responds` verb for a persistence technique that has already executed.
T1543.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means) as part of the incident management plan, which surfaces the technique when it manifests as a detectable event but does not mandate coverage of all possible persistence artifacts or automatic detection depth.
T1543.001responds — A.5.24 explicitly builds and exercises an incident response process (assess/respond/learn, escalation per 5.26, coordination, controlled recovery, root-cause, lessons learned) that activates once a persistence technique such as T1543.001 is detected as an incident.
T1543.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for security events/incidents, which surfaces the creation or modification of systemd services when observed as anomalous; this is limited to post-occurrence detection of the technique in flight or its effects rather than universal coverage of all variants (e.g., generators or symlinks).
T1543.002responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, escalating, coordinating, recovering from, and learning from incidents), which directly matches the `responds` verb once a systemd-service persistence technique is underway.
T1543.003detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for security events/incidents (including those from persistence techniques like malicious Windows services), but the control is scoped to incident-management processes rather than mandating specific detection instrumentation or coverage of all T1543.003 variants (e.g. hidden/masqueraded drivers).
T1543.003responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, escalating, containing, recovering from, learning from, and coordinating on incidents), which directly matches the `responds` verb once a T1543.003 persistence technique has executed and produced detectable service/driver artifacts.
T1543.004detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means) as part of the incident management plan, which surfaces the technique when observed but does not mandate coverage of all macOS-specific Launch Daemon artifacts or paths.
T1543.004responds — A.5.24 explicitly builds and exercises the incident response process (assessing, responding to, learning from incidents; escalation, containment via continuity/crisis activation, root-cause, lessons learned) once a persistence technique like Launch Daemon execution is underway and detected as an incident.
T1543.005detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for information security events and incidents (including those achieving persistence via modified container services), which surfaces the technique once it runs.
T1543.005responds — A.5.24 explicitly builds and activates an incident response process that contains, eradicates, escalates, coordinates, and learns from an already-underway security incident, which directly matches the `responds` verb once the T1543.005 persistence or privilege-escalation technique has executed on a container host.
T1546detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including those that could signal abuse of event-triggered mechanisms for persistence or privilege escalation), providing broad coverage of the technique once it is in flight.
T1546responds — A.5.24 explicitly builds and exercises an incident response process (assess/respond/learn, escalation per 5.26, coordination, recovery activation) that activates once an event-triggered execution has occurred and is detected as an incident.
T1546.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for information security events and incidents, which surfaces the technique once it has produced observable artifacts (e.g., anomalous registry changes or triggered execution), but does not mandate instrumentation depth that would reliably catch every stealthy or low-impact instance.
T1546.001responds — A.5.24 explicitly builds and exercises an incident response process (assess/respond/learn, escalation, coordination, recovery activation) that activates once the persistence technique has run and is detected as an incident.
T1546.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means) as part of the incident management plan, which surfaces the anomalous screensaver-based persistence technique once it executes.
T1546.002responds — A.5.24 explicitly builds and exercises an incident response process that activates on detected events, contains/eradicates the running technique (malicious screensaver execution), coordinates parties, logs, handles evidence, performs root-cause, and drives improvements once the persistence has triggered.
T1546.003detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, logging and reporting of information security events and incidents (including by automatic means), which surfaces the anomalous WMI event subscription activity once it occurs.
T1546.003prevents — A.5.24 requires establishing incident management processes, detection/monitoring capabilities, classification, response procedures, and training that can prevent the technique from achieving its persistence or privilege-escalation goals in many scenarios by enabling rapid detection and response before it fully succeeds, but does not stop the initial subscription creation or execution itself.
T1546.003responds — A.5.24 explicitly builds and exercises an incident response process that contains, eradicates, escalates, coordinates, recovers and learns from incidents once they are underway, which directly matches the `responds` verb against a persistence/elevation technique that has already executed.
T1546.004detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means) as part of the incident management plan, which surfaces this persistence technique when it triggers a detectable event; the remainder is that the control does not mandate instrumentation depth or coverage of all possible shell-configuration modification vectors.
T1546.004responds — A.5.24 explicitly builds and activates an incident response process that assesses, contains, escalates, coordinates, recovers from, and learns from security incidents (including those that used persistence techniques such as T1546.004), which is the core meaning of `responds` once the technique has executed.
T1546.005detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by automatic means), which surfaces the trap-based persistence when it manifests as an observable event.
T1546.005responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, learning from incidents once underway, including escalation, coordination, evidence handling, root-cause, and recovery activation), which directly matches the `responds` verb for a persistence technique that has already executed.
T1546.006detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for security events/incidents, which surfaces this persistence technique once it has executed on a monitored macOS system; the remainder is that the control's scope is set by organisational priorities and does not mandate universal instrumentation depth or pre-execution detection of binary-header tampering.
T1546.006responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, learning from, and coordinating on incidents), which directly matches the `responds` verb once the persistence technique has executed and is underway.
T1546.007detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via automatic means), which surfaces the anomalous Netsh Helper DLL registration/execution as an incident, but the control's scope is set by organizational priorities and does not mandate universal coverage of every persistence technique.
T1546.007responds — A.5.24 explicitly builds and exercises an incident response process that contains, eradicates, escalates, coordinates, recovers and learns from an already-underway incident, which directly matches the `responds` verb once the Netsh Helper DLL persistence has executed.
T1546.008detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including logging), which surfaces the technique when it triggers an observable event, but the control is scoped by organizational priorities, criteria, and procedures rather than mandating universal coverage of this specific persistence method.
T1546.008responds — A.5.24 explicitly builds and exercises the incident response process (assessing, responding to, learning from incidents; escalation, containment via continuity/crisis plans, root-cause, evidence handling, and coordinated communication) once an accessibility-feature persistence or privilege-escalation incident is underway.
T1546.009detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for information security events and incidents (including those that could manifest as persistence or privilege-escalation techniques), but the control is scoped to the organization's defined incident-management process and does not mandate instrumentation that would necessarily surface this specific low-level registry/API abuse in all environments.
T1546.009responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, escalating, and learning from incidents) that directly acts on T1546.009 once it has executed and is underway.
T1546.010detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for security events/incidents (including those from persistence techniques like AppInit DLLs), but detection scope is scoped by organizational requirements rather than mandating universal coverage of this specific technique.
T1546.010responds — A.5.24 explicitly builds and exercises an incident response process (assess/respond/learn, escalation per 5.26, coordination, controlled recovery, root-cause/lessons) that activates once an AppInit DLL persistence/elevation technique is already running as an incident.
T1546.011detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by automatic means), which surfaces the technique when it triggers an observable event, but the control is scoped to organization-defined criteria, processes and tools rather than mandating coverage of every possible shim invocation.
T1546.011responds — A.5.24 explicitly builds and exercises an incident response process (assess, respond to, contain, eradicate, learn from incidents including escalation, coordination, recovery activation and post-mortem), which directly matches the `responds` verb once the shim-based persistence/elevation technique has executed and is underway.
T1546.012detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for security events/incidents (including those from registry abuse or process anomalies), but the control is scoped to events that meet organizational criteria and does not mandate instrumentation that would reliably surface stealthy IFEO registry changes or silent-exit hooks before they trigger.
T1546.012responds — A.5.24 explicitly builds and exercises incident response processes that assess, contain, eradicate, escalate, coordinate, recover from, and learn from realized incidents (including those using IFEO for persistence, privilege escalation, or defense impairment), with only minor residual scope outside its defined scenarios.
T1546.013detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by automatic means), which surfaces the profile modification or anomalous PowerShell execution as an event; the remainder is that the control does not mandate instrumentation depth sufficient to catch every stealthy or non-anomalous profile change.
T1546.013responds — A.5.24 explicitly builds and exercises an incident response process (assess/respond/learn, escalation, coordination, root-cause, lessons-learned) that activates once a malicious PowerShell-profile execution is treated as an incident, containing/eradication steps matching the `responds` verb; the named remainder is that the profile's initial execution (persistence trigger) has already occurred before response begins.
T1546.014detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces emond rule abuse as an anomalous event once it triggers, but the control's scope is set by organizational priorities and does not mandate instrumentation depth that would guarantee catching the initial rule-write or plist placement.
T1546.014responds — A.5.24 explicitly builds and exercises the incident response process (assessing, responding to, containing, eradicating, learning from, and coordinating on incidents), which directly matches the `responds` verb once the emond persistence/privilege-escalation technique has executed and is underway.
T1546.015detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause/post-mortem of incidents (including those from persistence techniques like COM hijacking), but detection depends on the chosen scope, tools, and whether the stealthy Registry change or execution triggers observable events.
T1546.015responds — A.5.24 explicitly builds and exercises an incident response process (assess, respond to, learn from incidents; manage to conclusion with escalation, containment via crisis/continuity activation, root-cause, lessons learned) that activates once a COM-hijacking persistence technique has executed and is detected as an incident.
T1546.016detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including logging), which surfaces the technique when it manifests as an observable event, but the control is scoped to incident-handling processes rather than mandating specific detection mechanisms for installer-script abuse.
T1546.016responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, escalating, and learning from incidents) that directly activates once the installer-script technique has executed and produced malicious effects.
T1546.017detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including those from hardware events or rule changes), but this is scoped by organizational priorities and does not mandate coverage of all udev rule abuse vectors or persistence techniques.
T1546.017responds — A.5.24 explicitly builds and exercises an incident response process (assess/respond/learn, escalation, coordination, root-cause, lessons-learned) that activates once a persistence technique such as udev-rule execution is detected as an incident.
T1546.018detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by automatic means), which surfaces the technique when it triggers a detectable event, but the control's scope is set by organizational priorities and does not mandate instrumentation that would catch every stealthy or low-signal placement of a .pth or sitecustomize.py file.
T1546.018responds — A.5.24 explicitly builds and exercises an incident response process (assess/respond/learn, escalation, coordination, recovery activation, post-mortem, lessons learned) that activates once a persistence technique like T1546.018 has run and is detected as an incident.
T1547detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means) as part of the incident management plan, which surfaces T1547 when it manifests as a detectable event but does not mandate coverage of all possible boot/logon mechanisms or platforms.
T1547responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, escalating, containing, recovering from, and learning from incidents), which directly acts on T1547 once it has executed and the autostart mechanism has already run.
T1547.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (by human or automatic means) as core incident management capabilities, which surfaces the technique when it executes or leaves observable artifacts.
T1547.001responds — A.5.24 explicitly builds and exercises the incident response process (assessing, responding to, containing, eradicating, escalating, coordinating, recovering from, and learning from incidents), which directly matches the `responds` verb once a T1547.001 persistence artifact has executed and is detected.
T1547.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means) as part of the incident management plan, which surfaces the T1547.002 persistence technique when it triggers at boot; the remainder is that detection depends on chosen scope, tooling and event criteria rather than mandating coverage of this specific registry autostart vector.
T1547.002responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, escalating, coordinating, recovering from, and learning from incidents), which directly matches the `responds` verb once the T1547.002 persistence has activated and is underway.
T1547.003detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for security events/incidents, which surfaces the anomalous time-provider registration or boot-time DLL load when it occurs within the defined scope, but does not mandate coverage of every possible persistence vector or telemetry source.
T1547.003responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, escalating, and learning from incidents once underway), which directly matches the `responds` verb for a persistence technique that has already executed at boot.
T1547.004detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for security events/incidents (including those establishing persistence), but the control is scoped to organization-chosen criteria, competent personnel, and post-event handling rather than mandating specific detection of Winlogon registry abuse.
T1547.004responds — A.5.24 explicitly builds and exercises an incident response process (assess/respond/learn, escalation per 5.26, coordination, controlled recovery) that activates once a persistence technique like T1547.004 is detected as an incident
T1547.005detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, logging and reporting of information security events and incidents (including via human or automatic means), which surfaces SSP abuse when observed as anomalous boot-time DLL loading or registry modification, but the control's scope is set by organizational priorities and does not mandate instrumentation depth for every possible persistence vector.
T1547.005responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, escalating, coordinating, recovering from, and learning from incidents), which directly matches the `responds` verb once the SSP-abuse technique has executed and produced an incident.
T1547.006detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, root-cause analysis and post-mortem of incidents (including those from kernel-level persistence like malicious LKMs/kexts), but the control is scoped to incident management after the fact rather than continuous system-level detection of the technique itself.
T1547.006responds — A.5.24 explicitly builds and exercises an incident response process that assesses, contains, eradicates, escalates, coordinates, recovers from, and learns from security incidents (including those using kernel modules for persistence/privilege-escalation), once the technique has already run.
T1547.007detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including logging), which surfaces the plist modification and auto-reopen behavior once it occurs, but only within the scope of chosen detection methods and does not guarantee coverage of this specific macOS persistence technique.
T1547.007responds — A.5.24 explicitly builds and exercises an incident response process that contains, eradicates, escalates, coordinates, recovers and learns from an already-underway incident, which directly matches the `responds` verb once the plist-based persistence has executed.
T1547.008detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for security events/incidents (including those enabling persistence), but the control is governance-oriented planning/preparation rather than a technical detection mechanism and does not guarantee coverage of this specific LSASS driver technique.
T1547.008responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, escalating, and learning from incidents once underway), which directly matches the `responds` verb for a persistence technique that has already executed.
T1547.009detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including logging), which surfaces the technique when it triggers observable events but does not mandate coverage of all possible shortcut-modification vectors or stealthy cases.
T1547.009responds — A.5.24 explicitly builds and activates an incident response process that contains, eradicates, escalates, coordinates, recovers from, and learns from an already-underway incident (including persistence via shortcut modification), with only minor residual scope outside its defined scenarios.
T1547.010detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for security events/incidents (including those enabling persistence like boot-loaded DLLs), but detection depends on chosen scope, tools, and telemetry rather than mandating coverage of this specific technique.
T1547.010responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, escalating, and learning from incidents once underway), which directly matches the `responds` verb for a persistence/boot technique that has already executed.
T1547.012detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities that surface this boot-time print-processor abuse once it occurs.
T1547.012responds — A.5.24 explicitly builds and exercises an incident response process that assesses, contains, eradicates, escalates, coordinates, logs, and learns from security incidents once they are underway, which directly matches the `responds` verb for a persistence/privilege-escalation technique that has already executed at boot.
T1547.013detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including via human or automatic means), which surfaces the addition or execution of malicious XDG Autostart entries as an incident; partial because the control sets a process/scoping requirement rather than mandating specific detection mechanisms or coverage depth for this Linux persistence technique.
T1547.013responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, learning from, and communicating about incidents), which directly matches the `responds` verb once the autostart-based persistence has executed and is underway.
T1547.014detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for security events/incidents (including those enabling persistence), but does not mandate specific detection of this Windows Registry technique or its indicators.
T1547.014responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, escalating, and learning from incidents once underway), which directly matches the `responds` verb for a persistence technique that has already executed on login.
T1547.015detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means) as part of the incident management plan, which surfaces the addition and execution of malicious login items upon user login; this is a genuine but minority slice because the control's scope is set by organizational priorities, criteria, and procedures rather than mandating universal coverage of all possible persistence techniques on macOS.
T1547.015responds — A.5.24 explicitly builds and exercises the incident response process (assessing, responding to, containing, eradicating, escalating, coordinating, recovering from, and learning from incidents), which directly matches the `responds` verb once a T1547.015 persistence technique has executed and is underway.
T1548detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for security events/incidents, which surfaces T1548 privilege-escalation techniques when they trigger observable incidents, but only for those that meet the organization's detection scope and criteria rather than all instances.
T1548responds — A.5.24 explicitly builds and activates an incident response process (assessing, responding to, escalating, containing via crisis/continuity activation, controlled recovery, and learning) once an incident is underway, which directly matches the `responds` verb for a privilege-escalation technique that has already succeeded.
T1548.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means) as part of the incident management plan, which would surface setuid/setgid abuse when it manifests as a detectable event.
T1548.001responds — A.5.24 explicitly builds and activates an incident response process that assesses, contains, eradicates, escalates, coordinates, logs, and learns from security incidents (including those using setuid/setgid abuse), once the technique has already run.
T1548.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting and logging of information security events and incidents (including via human or automatic means), which surfaces UAC-bypass attempts once they occur as anomalous events, but does not mandate specific detection mechanisms for this technique and leaves many stealthy or low-impact bypasses outside routine scope.
T1548.002responds — A.5.24 explicitly builds and exercises an incident response process (assess/respond/learn, escalation per 5.26, coordination, controlled recovery) that activates once a UAC-bypass technique is detected as an incident, containing/eradicating it per the defined scenarios and priorities.
T1548.003detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for information security events and incidents, which surfaces sudo-caching or sudoers abuse when it triggers an observable event, but the clause's scope is set by organizational priorities and does not mandate coverage of every stealthy or configuration-only instance of this technique.
T1548.003responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, escalating, containing, recovering from, learning from, and coordinating on incidents), which directly matches the `responds` verb once a sudo-caching privilege-escalation technique is already underway.
T1548.004detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means) as part of the incident management plan, which surfaces the technique when it triggers an observable event.
T1548.004responds — A.5.24 explicitly builds and exercises the incident response process (assess, respond to, contain, eradicate, escalate, recover, learn) once an information security incident is underway, which directly matches the `responds` verb against this post-exploitation privilege-escalation technique.
T1548.005detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause/post-mortem of incidents (including those arising from permission misconfigurations that enable temporary elevation), providing broad coverage of the technique once it is exercised.
T1548.005responds — A.5.24 explicitly builds and requires an incident response process (assessing, responding to, containing, eradicating, escalating, coordinating, recovering from, and learning from incidents), which directly matches the `responds` verb once the temporary-elevation technique has executed and produced an incident.
T1548.006detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for information security events and incidents, which would surface TCC database manipulation or anomalous permission grants when observed, but the control's scope is set by organizational priorities and does not mandate instrumentation that necessarily catches every macOS-specific technique variant.
T1548.006responds — A.5.24 explicitly builds and exercises the incident response process (assess, respond to, contain, eradicate, learn from incidents including escalation, coordination, evidence handling, root-cause, and recovery activation), which directly matches the `responds` verb once a TCC-manipulation technique is underway.
T1550detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for security events and incidents, which directly surfaces use of stolen alternate auth material (a detectable post-authentication lateral movement technique) once it triggers observable anomalies.
T1550responds — A.5.24 explicitly builds and exercises an incident response process that contains, eradicates, escalates, coordinates, and learns from security incidents (including those using stolen alternate auth material), once the technique is already underway.
T1550.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for security events/incidents, which surfaces token abuse when it manifests as anomalous API behaviour or an identifiable incident, but the control's scope is set by organisational priorities and does not mandate instrumentation that would catch every stealthy or legitimate-looking token use.
T1550.001responds — A.5.24 explicitly builds and exercises the incident response process (assessing, responding to, escalating, containing, recovering from, and learning from incidents), which directly matches the `responds` verb once the token-abuse technique is already underway.
T1550.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for security events/incidents, which surfaces PtH lateral movement once it occurs, but only within the scope of the organization's chosen detection criteria and tooling (no universal guarantee of coverage for all PtH variants or platforms).
T1550.002responds — A.5.24 builds and exercises the incident response process (assess, respond to, contain, eradicate, learn) that activates once a PtH lateral-movement event is underway, exactly matching the `responds` verb.
T1550.003detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for security events/incidents (including those enabling lateral movement like PtT), but the control is scoped to an organization-chosen set of procedures rather than mandating instrumentation that necessarily surfaces PtT specifically.
T1550.003responds — A.5.24 explicitly builds and exercises an incident response process (assess/respond/learn, escalation per 5.26, coordination, controlled recovery) that activates once a PtT-based lateral movement event is underway, containing/eradicating it per the defined incident management plan.
T1550.004detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including logging and root-cause work), which surfaces use of a stolen session cookie once it manifests as anomalous behavior or an incident, but the clause's scope is set by organizational priorities rather than mandating universal coverage of this post-authentication technique.
T1550.004responds — A.5.24 explicitly builds and exercises an incident response process (assess, respond to, contain, eradicate, escalate, recover, learn) that activates once a session-cookie theft or reuse is detected as an incident, matching the `responds` verb; the named remainder is that the control does not itself perform the real-time containment/eradication steps (those live in A.5.26).
T1552detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including those from compromised systems), which surfaces T1552 activity once underway.
T1552responds — A.5.24 explicitly builds and activates an incident response process that contains, eradicates, escalates, coordinates, and learns from an already-underway incident (including credential-theft events), matching the `responds` verb; the named remainder is that it stops short of full eradication for every possible credential artifact before impact occurs.
T1552.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including those involving credential exposure), which surfaces T1552.001 when it occurs.
T1552.001responds — A.5.24 explicitly builds and activates an incident response process (assess, respond to, contain, eradicate, escalate, recover, learn) once an information security incident is underway, which directly matches the `responds` verb for a technique that has already executed and left credential files behind.
T1552.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means) as part of the incident management plan, which would surface Registry queries for credentials as anomalous events once the technique is underway.
T1552.002responds — A.5.24 explicitly builds and activates an incident response process (assessment, response/escalation per 5.26, coordination, controlled recovery, root-cause, lessons learned) that acts on an already-underway incident whose artifact is credential discovery in the Registry.
T1552.003detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces the technique when it occurs within the defined incident management scope, but the control's scope and detection mechanisms are set by organizational requirements rather than mandating coverage of all shell-history access.
T1552.003responds — A.5.24 explicitly builds and activates an incident response process that includes detection/classification/analysis of events, managing incidents to conclusion with response/escalation, root-cause/post-mortem, lessons learned, and coordination — all of which directly address a T1552.003 technique that has already run on a compromised system.
T1552.004detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces the adversary search/export activity described in T1552.004 once it is underway.
T1552.004responds — A.5.24 explicitly builds and exercises the incident response process (assessing, responding to, containing, eradicating, escalating, coordinating, recovering, and learning from incidents), which directly matches the `responds` verb once credential-theft via private-key search is already underway.
T1552.005detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including those involving credential access via metadata APIs), providing broad detection capability once the technique is underway.
T1552.005responds — A.5.24 explicitly builds and exercises incident response processes (detection, triage, analysis, response/escalation per 5.26, coordination, recovery, lessons learned) that activate once an incident is underway, containing and eradicating adversary access to the metadata API and its stolen credentials.
T1552.006detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (by human or automatic means), which surfaces the technique of enumerating and decrypting GPP XML files for credentials.
T1552.006responds — A.5.24 explicitly builds and exercises the incident response process (assessing, responding to, containing, eradicating, learning from, and coordinating on incidents), which directly matches the `responds` verb once the GPP credential-harvesting technique has already run and produced an incident.
T1552.007detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for information security events and incidents, which surfaces credential-gathering via container APIs (e.g. anomalous Docker/Kubernetes API calls) once it occurs.
T1552.007responds — A.5.24 explicitly builds and exercises the incident response process (assessing, responding to, containing, eradicating, escalating, coordinating, recovering from, and learning from incidents), which directly matches the `responds` verb once the credential-gathering technique has begun.
T1552.008detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including those involving credential exposure in chat services), providing broad detection coverage once the technique is underway.
T1552.008responds — A.5.24 explicitly builds and activates an incident response process (assess/respond/learn, escalation per 5.26, coordination, controlled recovery) that activates once a chat-credential exposure is classified as an incident, containing/eradicating the active collection and follow-on abuse.
T1553detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including those that could involve subverting trust controls), but this is only one slice of a broader incident management planning/preparation control whose dominant focus is response processes rather than detection mechanisms.
T1553responds — A.5.24 explicitly builds and activates an incident response process that contains, eradicates, escalates, coordinates, and learns from realized security incidents (including those that subvert trust controls), with only the pre-containment impact slice left for recovery controls.
T1553.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means) as part of the incident management plan, which would surface a Gatekeeper bypass when it is treated as an event or incident.
T1553.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces the use of stolen/compromised code-signing materials when treated as an incident
T1553.002responds — A.5.24 explicitly builds and activates an incident response process (assessing, responding to, escalating, containing via crisis/continuity plans, recovery, root-cause, lessons learned) once an incident is underway, which directly matches the `responds` verb for a technique that has already succeeded in signing and deploying malware.
T1553.003detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause/post-mortem of incidents (including those from tampering that could enable persistence or bypass of trust controls), but the control is scoped to incident management after an event occurs rather than continuous detection of the specific registry/DLL hijack technique itself.
T1553.003responds — A.5.24 explicitly builds and exercises an incident response process (assess/respond/learn, escalation per 5.26, coordination, recovery activation, root-cause, lessons) that activates once a hijacking technique is detected as an incident, containing/eradicating it and restoring trust mechanisms.
T1553.004detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including those tied to compromised systems or anomalous certificate trust), but does not mandate instrumentation that would reliably surface the specific low-level root-certificate installation action itself.
T1553.004responds — A.5.24 explicitly builds and exercises the incident response process (assess, respond to, learn from incidents; manage to conclusion with escalation, recovery, root-cause, lessons learned) that activates once an adversary technique such as T1553.004 is underway, containing/eradication its effects.
T1553.005detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including logging), which surfaces MOTW-bypass activity once it occurs as an observable event, but the clause's scope is set by organizational priorities and does not mandate instrumentation that would catch every container-based bypass.
T1553.005responds — A.5.24 explicitly builds and exercises an incident response process that includes detection, triage, analysis, response/escalation, coordination, evidence handling, root-cause, lessons learned and controlled recovery once an incident is underway; this directly matches the `responds` verb for a technique that has already succeeded in delivering and executing unmarked malicious payloads.
T1553.006detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for security events and incidents, which would surface policy-modification attempts that qualify as incidents (or their precursors), but the control is silent on depth or coverage of kernel-memory, registry, or boot-time changes that may evade standard detection.
T1554detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, root-cause analysis and post-mortem of incidents (including those from binary modifications establishing persistence), but this is scoped to events that have already triggered an incident rather than reliably detecting the binary modification technique itself in all cases.
T1554responds — A.5.24 explicitly builds and exercises an incident response process that activates on detection of events, manages incidents to conclusion (including response, escalation, coordination, evidence handling, root-cause, and lessons learned), which directly matches the `responds` verb once the T1554 technique has run and produced observable artifacts.
T1555detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including those involving credential access), providing broad organizational capability to surface T1555 when it occurs.
T1555responds — A.5.24 explicitly builds and exercises an incident response process (assess, respond to, contain, eradicate, escalate, recover, learn) that activates once credential theft from stores is detected as an incident, matching the `responds` verb; the named remainder is pre-response detection/triage steps that sit in the same clause but are not the response act itself.
T1555.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for information security incidents (including credential access events), but the control is scoped to incident management processes rather than mandating specific detection instrumentation for Keychain access techniques.
T1555.001responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, learning from, and communicating on incidents), which directly matches the `responds` verb once a T1555.001 credential-theft event is underway; the named remainder is that the control is agnostic to the specific technique and does not itself perform the on-the-wire containment or credential revocation steps.
T1555.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by automatic means), which surfaces the in-memory credential-gathering technique once it is underway.
T1555.002responds — A.5.24 explicitly builds and exercises an incident response process (assess, respond to, learn from incidents; manage to conclusion with escalation, containment via continuity/crisis plans, root-cause, lessons learned) that activates once a credential-theft technique like T1555.002 is underway or detected.
T1555.003detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for information security incidents (including credential theft as an incident), providing broad detection coverage of the technique once it runs; the bounded remainder is that purely file-based or in-memory access without triggering an observable event may fall outside automated detection scope until later analysis.
T1555.003responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, learning from, and coordinating on incidents), which directly matches the `responds` verb once credential theft from browsers is underway; the named remainder is that the control does not itself perform the technical containment/eradication steps.
T1555.004detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for information security events and incidents, which directly surfaces T1555.004 when it occurs as a detectable event (via anomalous credential access, API abuse, or tool execution) within the defined incident management scope.
T1555.004responds — A.5.24 establishes incident response processes, procedures for detection/classification/analysis/escalation/response to conclusion, coordination, root-cause, and lessons learned that directly address an in-progress credential-theft incident once underway.
T1555.005detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including those involving credential access from password managers), providing broad detection coverage across the technique's execution vectors.
T1555.005responds — A.5.24 explicitly builds and activates an incident response process (assessment, response/escalation per 5.26, coordination, controlled recovery, root-cause, lessons learned) that acts on an already-underway credential-theft incident from a password manager.
T1555.006detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities that surface the API-driven secret retrievals (and the prerequisite privilege abuse) once they occur.
T1555.006responds — A.5.24 explicitly builds and activates an incident response process (assess, respond to, contain, eradicate, escalate, recover, learn) once an information security incident is underway, which directly matches the `responds` verb for a credential-theft technique that has already succeeded in retrieving secrets.
T1556detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for security events/incidents, which surfaces T1556 modifications once they trigger observable events, but the clause's scope is set by organizational priorities and does not mandate instrumentation that reliably catches stealthy auth-process tampering across all platforms.
T1556responds — A.5.24 explicitly builds and exercises an incident response process (assess, respond to, learn from incidents; manage to conclusion with escalation, recovery, root-cause, lessons learned) that directly acts on T1556 once the authentication modification is detected and classified as an incident.
T1556.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, logging and reporting of information security events and incidents (including via human or automatic means), which surfaces the anomalous patching of LSASS and related authentication anomalies once they occur.
T1556.001responds — A.5.24 explicitly builds and exercises an incident response process (assess, respond to, contain, eradicate, escalate, recover, learn) that activates once the domain-controller authentication patch is detected as an incident.
T1556.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means) as part of the incident management plan, which would surface the registration and use of a malicious password filter DLL as an anomalous security event.
T1556.002responds — A.5.24 explicitly builds and exercises an incident response process (assess, respond to, learn from incidents; manage to conclusion with escalation, recovery, root-cause, lessons learned) that activates once a malicious password-filter registration is treated as an incident.
T1556.003detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for information security events and incidents, which surfaces PAM modifications or anomalous authentication behavior once it occurs, but only within the scope of events the organization has instrumented and prioritized.
T1556.003responds — A.5.24 explicitly builds and activates an incident response process (assessing, responding to, containing, eradicating, escalating, and learning from incidents including those that modify PAM components), which matches the `responds` verb once the technique has run.
T1556.004detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means) as part of the incident management plan, which surfaces the technique once it has produced observable events on a network device.
T1556.004responds — A.5.24 explicitly builds and activates an incident response process (assessing, responding to, containing, eradicating, escalating, coordinating, recovering, and learning from incidents), which directly matches the `responds` verb once the backdoored authentication technique has run and is underway.
T1556.005detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces the technique of enabling reversible encryption as a detectable event or incident.
T1556.005responds — A.5.24 explicitly builds and exercises an incident response process that activates on detected events, contains/escalates the incident (including credential-compromise scenarios), coordinates parties, logs, performs root-cause, and drives improvements — all core to `responds` once T1556.005 has run and credentials are exposed.
T1556.006detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for security events and incidents, which surfaces adversary MFA modification as an incident once it occurs or is observed.
T1556.006responds — A.5.24 explicitly builds and exercises an incident response process (assess, respond to, learn from incidents; manage to conclusion with escalation, controlled recovery, root-cause, lessons learned) that directly matches the `responds` verb once the MFA-disable technique has run and is underway.
T1556.007detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for information security events and incidents (including those involving authentication/hybrid identity backdoors), but the control is scoped to organization-chosen criteria, processes, and competent personnel rather than mandating universal coverage of this specific on-premises/cloud authentication technique.
T1556.007responds — A.5.24 explicitly builds and exercises incident response processes (assess, respond to, escalate, contain, recover from, learn from incidents including those that modify auth processes), which matches the `responds` verb once the T1556.007 backdoor is underway.
T1556.008detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including via human or automatic means), which surfaces the technique when it triggers a detectable event such as registry changes for credential managers or anomalous logon notifications.
T1556.008responds — A.5.24 explicitly builds and activates an incident response process (assessing, responding to, containing, escalating, coordinating, recovering from, and learning from incidents), which directly matches the `responds` verb once the T1556.008 technique has executed and produced detectable credential-capture artifacts.
T1556.009detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting and logging of information security events and incidents (including those that could involve policy modification), but its scope is set by organizational priorities and does not mandate instrumentation that would necessarily surface every conditional-access-policy change on every IaaS/IdP platform.
T1556.009prevents — A.5.24's incident management planning, detection, response, and learning processes (including coordination and post-incident improvements) can constrain or deter the technique in some scenarios by enabling quicker detection/response that limits persistence, but does not stop the adversary from disabling/modifying the policies themselves.
T1556.009responds — A.5.24 explicitly builds and activates an incident response process (assess/respond/escalate to conclusion per severity, including coordination, controlled recovery and post-incident lessons) that directly acts on an already-underway T1556.009 modification once it is classified as an incident.
T1557detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including those from network-protocol abuse), but the control is scoped to incident-management processes rather than mandating specific detection instrumentation for all AiTM variants.
T1557responds — A.5.24 explicitly builds and activates an incident response process (assess/respond/learn, escalation per 5.26, coordination, controlled recovery) that activates once an AiTM positioning or its follow-on behaviors (sniffing, manipulation, credential theft) are treated as an incident
T1557.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via automatic means), which surfaces name-resolution poisoning and relay activity once it occurs on the network.
T1557.001responds — A.5.24 explicitly builds and exercises incident response processes that assess, contain, eradicate, escalate, recover from, and learn from security incidents (including network-based ones like name resolution poisoning that produce observable events), once they are underway.
T1557.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces ARP cache poisoning when observed as anomalous network behavior, but only within the scope of the organization's defined incident management processes and priorities.
T1557.002responds — A.5.24 explicitly builds and exercises an incident response process (assess, respond to, contain, eradicate, escalate, recover, learn) that activates once an ARP-poisoning event is classified as an incident, matching the `responds` verb definition.
T1557.003detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means) as part of the incident management plan, which surfaces DHCP spoofing when observed as an anomalous event but does not mandate network-layer instrumentation that would catch it in all cases.
T1557.003responds — A.5.24 explicitly builds and exercises an incident response process (assess, respond to, learn from incidents; manage to conclusion with escalation, controlled recovery, root-cause, lessons learned) that activates once a DHCP-spoofing event is classified as an incident, matching the `responds` verb definition.
T1557.004detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces evil twin Wi-Fi deception once it is underway; this is a genuine but bounded slice because the control's scope is set by organizational priorities, event criteria, and chosen detection methods rather than mandating universal coverage of all possible rogue-AP techniques.
T1557.004responds — A.5.24 explicitly builds and activates an incident response process (assessment, response/escalation per 5.26, coordination, containment to conclusion, recovery activation, post-incident learning) that directly acts on an evil-twin event once underway, with the named remainder being any pre-containment data already sniffed/manipulated.
T1558detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for security events/incidents, which directly surfaces T1558 ticket theft or forgery when it occurs.
T1558responds — A.5.24 explicitly builds and activates an incident response process (assessing, responding to, containing, eradicating, escalating, coordinating, recovering, and learning from incidents once underway), which directly matches the `responds` verb for a T1558 event that has begun.
T1558.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities that surface golden-ticket forgeries once they interact with the KDC or produce anomalous Kerberos behavior.
T1558.001responds — A.5.24 explicitly builds and activates an incident response process (assessing, responding to, containing, escalating, coordinating, recovering from, and learning from incidents), which directly matches the `responds` verb once a golden-ticket technique is underway.
T1558.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, root-cause analysis and post-mortem of incidents, which surfaces silver-ticket usage once it occurs.
T1558.002responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, escalating, coordinating, recovering, and learning from incidents), which directly matches the `responds` verb once a silver-ticket technique is underway.
T1558.003detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via automatic means), plus logging and root-cause/post-mortem procedures, which directly surface Kerberoasting TGS requests, offline cracking indicators, and anomalous SPN usage.
T1558.003responds — A.5.24 explicitly builds and exercises the incident response process (assessing, responding to, containing, eradicating, learning from, and coordinating on incidents), which directly matches the `responds` verb once a Kerberoasting event is underway; the named remainder is that the control stops at procedural readiness and does not itself perform the on-the-wire containment or credential rotation.
T1558.004detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via automatic means), which surfaces AS-REP roasting activity when observed as an anomalous authentication or Kerberos event, but the control's scope is set by organizational priorities and does not mandate instrumentation depth that would guarantee catching every instance of this technique.
T1558.004responds — A.5.24 explicitly builds and exercises an incident response process (assess, respond to, contain, eradicate, learn from incidents including credential theft) once the AS-REP roasting event is underway, with the named remainder being pre-containment cracking already completed.
T1558.005detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including logging), which surfaces the technique of stealing ccache files when it occurs.
T1558.005responds — A.5.24 explicitly builds and exercises the incident response process (assess, respond to, contain, eradicate, escalate, recover, learn) once an information security incident is underway, which directly matches the `responds` verb against an adversary technique that has already executed.
T1559detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including those from human or automatic means), which surfaces T1559 abuse of IPC mechanisms once it occurs.
T1559responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, escalating, and learning from incidents) that activates once an IPC-abuse technique is underway, matching the `responds` verb; mostly because the control is agnostic to technique specifics and its effectiveness still depends on detection having already occurred.
T1559.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including those from human or automatic means), which surfaces COM-based local code execution when observed as an anomalous or malicious event, but the control is scoped by organizational priorities, criteria, and procedures rather than mandating universal detection of this specific technique.
T1559.001responds — A.5.24 explicitly builds and activates incident response processes (assess/respond/learn, escalation, coordination, recovery, post-mortem) once an incident is underway, which directly matches the `responds` verb for a technique that has already executed.
T1559.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces DDE-based command execution as an incident once observed.
T1559.002prevents — A.5.24 builds incident management processes, training, detection, triage, response/escalation, root-cause analysis and lessons-learned that can stop the DDE technique from recurring after first use, but does not stop the initial execution of DDE (the technique runs and succeeds before any incident process activates).
T1559.002responds — A.5.24 explicitly builds and exercises the incident response process (assessing, responding to, containing, eradicating, escalating, coordinating, recovering from, and learning from incidents), which directly matches the `responds` verb once a T1559.002 technique is underway; the named remainder is that the control stops at procedural readiness and competent personnel rather than guaranteeing every tactical containment step.
T1559.003detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (by human or automatic means) as part of the incident management plan, which surfaces XPC abuse when it manifests as an observable event.
T1559.003responds — A.5.24 explicitly builds and exercises the incident response process (assessing, responding to, containing, eradicating, learning from, and coordinating on incidents), which directly matches the `responds` verb once an XPC-abuse technique is underway.
T1560detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including those tied to data collection and exfiltration preparation), but this is scoped by organizational priorities, event criteria, and chosen detection methods rather than mandating coverage of every T1560 implementation (e.g. custom in-memory compression).
T1560responds — A.5.24 explicitly builds and activates an incident response process (assessing, responding to, containing, eradicating, escalating, and learning from incidents) that directly acts on T1560 once the archiving technique has run and is underway as part of data collection prior to exfiltration.
T1560.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including those tied to data handling prior to exfiltration), providing broad coverage of the technique when it manifests as observable activity.
T1560.001responds — A.5.24 explicitly builds and exercises an incident response process (assess, respond to, contain, eradicate, escalate, recover from, learn from incidents) that activates once an information security incident — including data collection and exfiltration staging via utilities — is underway.
T1560.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, logging and reporting of information security events and incidents (including those that could involve data archiving prior to exfiltration), but the control is scoped to an organization-chosen process rather than mandating universal instrumentation that would catch every possible library-based implementation on every platform.
T1560.002responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, learning from incidents; escalation, containment via crisis/continuity activation, controlled recovery, root-cause, lessons learned) that activates once an exfiltration-prep technique such as library-based archiving is underway and detected.
T1560.003detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, logging and reporting of information security events and incidents (including those that could involve custom archival prior to exfiltration), but the control is scoped to organization-chosen criteria, tools and telemetry rather than guaranteeing detection of every custom-method implementation.
T1560.003responds — A.5.24 explicitly builds and activates an incident response process that contains, eradicates, escalates, coordinates, recovers from, and learns from an information security incident once it is underway, which directly matches the `responds` verb against an adversary's custom archival step during data staging for exfiltration.
T1561detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause/post-mortem of incidents (including those that destroy availability via disk wipe), providing broad detection coverage once the technique executes.
T1561recovers — A.5.24 explicitly requires procedures for controlled recovery from an incident, activation of continuity plans, root cause analysis, lessons learned, and restoration of availability after a destructive event such as disk wipe.
T1561responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, escalating, recovering from, and learning from incidents), which directly matches the act of responding once a disk-wipe technique is underway.
T1561.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause/post-mortem of incidents (including destructive availability events like disk wipes), providing broad detection coverage once the technique executes.
T1561.001recovers — A.5.24 explicitly requires procedures for controlled recovery from an incident, activation of continuity plans, root-cause analysis, and post-incident improvements that restore availability after disk-wipe impact.
T1561.001responds — A.5.24 explicitly builds and exercises an incident response process that includes assessing, responding to, containing, escalating, and recovering from incidents (including destructive availability events like disk-wipe), with defined roles, procedures, coordination, evidence handling, and post-incident learning.
T1561.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause/post-mortem of incidents (including those matching T1561.002's destructive availability impact), providing broad detection coverage once the technique executes.
T1561.002recovers — A.5.24 explicitly requires procedures for controlled recovery from an incident, activation of continuity plans, root-cause analysis, lessons learned, and restoration of availability after a destructive availability event such as disk-structure wipe.
T1561.002responds — A.5.24 explicitly builds and exercises incident response processes that assess, contain, eradicate, escalate, recover from, and learn from incidents (including destructive availability attacks like disk-structure wipe once they are underway), with only the pre-incident planning slice left outside the verb `responds`.
T1563detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for information security events and incidents (including those enabling lateral movement like session hijacking), providing broad detection coverage once the technique is in flight.
T1563responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, escalating, coordinating, recovering, and learning from incidents), which directly matches the `responds` verb once a session-hijacking event is underway.
T1563.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause/post-mortem of incidents (including those from lateral movement techniques like SSH hijacking), providing broad coverage once the session hijack is underway or leaves observable artifacts.
T1563.001responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, escalating, coordinating, recovering, and learning from incidents), which directly matches the `responds` verb once the SSH-hijacking technique is underway.
T1563.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (by human or automatic means), which surfaces RDP session hijacking as it occurs.
T1563.002responds — A.5.24 explicitly builds and exercises incident response processes (assess, respond, escalate, contain to conclusion, coordinate, recover, learn) that activate once an RDP hijacking incident is underway, matching the `responds` verb; mostly because the control is scoped to declared incidents rather than every stealthy or pre-escalation hijack.
T1564detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, root-cause analysis and post-mortem of incidents and events, which surfaces many (but not all) hiding techniques once they produce observable artifacts or anomalies
T1564responds — A.5.24 explicitly builds and activates an incident response process (assessing, responding to, containing, eradicating, escalating, coordinating, recovering from, and learning from incidents), which directly matches the `responds` verb once a T1564 hiding technique has executed and produced detectable artifacts or anomalies.
T1564.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces the use of hidden files/directories when they are part of an incident but does not mandate instrumentation that would catch every instance of the technique in isolation
T1564.001responds — A.5.24 explicitly builds and activates an incident response process that includes detection/classification/analysis of events, managing incidents to conclusion with response/escalation, root-cause/post-mortem, and lessons-learned improvements once the hiding technique is underway.
T1564.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including via human or automatic means), which surfaces the technique when it manifests as a detectable event or anomaly, but the control is scoped by organizational priorities, criteria, and procedures rather than mandating universal coverage of all hidden-user manipulations across platforms.
T1564.002responds — A.5.24 explicitly builds and activates an incident response process that assesses, contains, eradicates, escalates, coordinates, logs, and learns from realized security incidents (including those that used hidden-user techniques), matching the `responds` verb once the technique has run.
T1564.003detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by human or automatic means) as part of the incident management plan, which surfaces hidden-window techniques once they produce observable events.
T1564.003responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, learning from, and communicating about incidents), which directly matches the `responds` verb once the hidden-window technique has executed and produced observable effects.
T1564.004detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, logging and reporting of information security events and incidents (including by automatic means), which surfaces the use of NTFS attributes/ADS as an anomalous or malicious event once it occurs.
T1564.004responds — A.5.24 explicitly builds and exercises an incident response process that includes detection/classification/analysis of events, managing incidents to conclusion with response/escalation, root-cause/post-mortem, and lessons learned, which directly acts on a T1564.004 technique once it has run and is underway.
T1564.005detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause/post-mortem of incidents (including via human or automatic means), which surfaces hidden file system usage once it produces observable events or anomalies, but does not guarantee coverage of all stealth implementations or pre-execution detection.
T1564.005responds — A.5.24 explicitly builds and activates an incident response process that includes detection, classification, analysis, response/escalation, coordination, evidence handling, root-cause, lessons learned, and controlled recovery once an incident (including hidden-file-system concealment of malicious components) is underway.
T1564.006detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, logging and reporting of information security events and incidents (including by automatic means), which surfaces the technique when it produces observable events inside the organization's defined scope, but the control's scope is set by business requirements and does not mandate instrumentation that reliably reaches inside virtual instances or rogue VMs.
T1564.006responds — A.5.24 explicitly builds and exercises incident response processes (assess/respond/learn, escalation, containment via 5.26 cross-ref, recovery activation, root-cause, lessons) that activate once a hidden virtualized malicious operation is treated as an incident.
T1564.007detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by automatic means) as part of the incident management plan, which surfaces the technique when it is observed as an event.
T1564.007responds — A.5.24 explicitly requires an incident response process and procedures for assessing, responding to, containing, eradicating, and learning from information security incidents (including escalation, coordination, evidence handling, root-cause analysis, and recovery), which directly matches the act of responding once a VBA-stomping technique has executed and produced an incident.
T1564.008detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for security events/incidents (including those that could be hidden by email rules), but the control is about planning/preparation processes rather than any concrete detection mechanism that would surface the rule-creation or the hidden emails themselves.
T1564.008responds — A.5.24 explicitly builds and exercises the incident response process (assessing, responding to, learning from incidents; escalation per 5.26; coordination; root-cause and lessons-learned) that activates once the hiding technique has already run and impaired visibility of alerts/C2/internal-phishing mail.
T1564.009detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by automatic means), plus logging and root-cause activities that surface the technique when it triggers an incident
T1564.009responds — A.5.24 explicitly builds and exercises the incident response process (assessing, responding to, containing, eradicating, escalating, and learning from incidents), which directly matches the `responds` verb once the resource-fork technique has executed and is underway.
T1564.010detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, logging and reporting of information security events and incidents (including via human or automatic means), which surfaces the technique when it is observed as part of an incident; this is a genuine but bounded slice because the control's scope and detection depth are set by the organization's chosen criteria, priorities and tooling rather than mandating universal coverage of in-memory PEB manipulation.
T1564.010responds — A.5.24 explicitly builds and exercises an incident response process (assess/respond/learn, escalation, containment via 5.26 cross-ref, root-cause, evidence handling) that activates once a spoofed-argument technique is detected in flight, containing/eradicating the actor's foothold while the event is underway.
T1564.011detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause/post-mortem of incidents (including those arising from evasion techniques like nohup or SilentlyContinue that allow malicious processes to survive interrupts), but the control is scoped to incident-level events rather than low-level process-signal telemetry that would catch the technique in flight.
T1564.011responds — A.5.24 explicitly builds and exercises an incident response process (assess/respond/learn, escalation per 5.26, coordination, controlled recovery) that activates once the ignore-interrupts technique is already running and has evaded normal termination signals.
T1564.012detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities that surface information security incidents (including those using known AV exclusions as hiding places), but does not mandate instrumentation that would catch the initial drop or the pre-existing exclusion itself.
T1564.012responds — A.5.24 explicitly builds and exercises the incident response process (assess, respond to, contain, eradicate, escalate, recover, learn) once an incident is underway, which directly matches the `responds` verb against an adversary technique already in flight.
T1564.013detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, root-cause analysis and post-mortem of incidents (including via human or automatic means), which surfaces the bind-mount hiding technique once it has produced observable anomalies or artifacts, but the control's scope is set by organizational priorities and does not mandate instrumentation that would reliably catch every stealthy /proc overlay on Linux.
T1564.013responds — A.5.24 explicitly builds and exercises the incident response process (assessing, responding to, containing, eradicating, escalating, coordinating, recovering from, and learning from incidents), which directly acts on a T1564.013 event once it is underway; the named remainder is that the technique's initial hiding may delay detection long enough for impact to occur before response begins.
T1564.014detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by automatic means), which surfaces the xattr abuse technique when it occurs within the defined scope of the incident management plan.
T1564.014responds — A.5.24 explicitly builds and exercises the incident response process (assessing, responding to, containing, eradicating, learning from, and coordinating on incidents), which directly matches the `responds` verb once an xattr-based hiding technique has executed and is underway.
T1565detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, root-cause analysis and post-mortem of incidents (including those from data manipulation affecting integrity/business outcomes), providing broad detection coverage once the technique has produced observable effects.
T1565responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, learning from, and communicating on incidents including data-integrity events), which directly matches the `responds` verb once T1565 manipulation is underway.
T1565.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, root-cause analysis and post-mortem of incidents (including those from data manipulation affecting integrity/business outcomes), providing broad detection coverage once the technique has produced an observable event.
T1565.001recovers — A.5.24 explicitly requires procedures for controlled recovery from an incident, root cause analysis, lessons learned, and improvements that restore affected data integrity and business processes after stored-data manipulation has occurred.
T1565.001responds — A.5.24 explicitly builds and exercises an incident response process that contains, eradicates, escalates, coordinates, recovers from, and learns from security incidents (including data-integrity events), which matches the `responds` verb once the manipulation technique has run and produced impact.
T1565.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for information security incidents and events, which would surface T1565.002 data manipulation when it triggers detectable integrity or process anomalies.
T1565.002responds — A.5.24 explicitly builds and exercises the incident response process (assess, respond to, contain, eradicate, escalate, recover from, learn from incidents including those affecting data integrity), which directly matches the `responds` verb once T1565.002 manipulation is underway.
T1565.003detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities that surface runtime data manipulation incidents once they occur, but only within the scope of events that meet the organization's defined criteria and monitoring coverage.
T1565.003responds — A.5.24 explicitly builds and exercises an incident response process (assess/respond/learn, escalation, containment via crisis/continuity activation, recovery, root-cause, lessons-learned) that activates once a runtime data manipulation incident is underway, exactly matching the `responds` verb.
T1566detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including those from phishing), with procedures, logging, and competent personnel to surface them once underway.
T1566responds — A.5.24 explicitly builds and exercises the incident response process (assessing, responding to, containing, eradicating, escalating, coordinating, recovering, and learning from incidents), which activates once a phishing-delivered event is triaged as an incident; the named remainder is that the control does not itself perform the on-the-wire containment or user-level eradication steps.
T1566.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (by human or automatic means), plus logging and root-cause activities that surface the spearphishing technique once it has produced an observable event.
T1566.001responds — A.5.24 explicitly builds and exercises the incident response process (assess, respond to, contain, eradicate, escalate, recover, learn) once an incident is underway, directly addressing the realized spearphishing-attachment event per the event-lane definition of responds.
T1566.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including those from social engineering like spearphishing links), with procedures, logging, and competent personnel to surface them once underway.
T1566.002prevents — A.5.24 requires establishing incident management processes, training, detection, triage, response/escalation, and learning/improvements that can stop a spearphishing link from succeeding when treated as an event (e.g., rapid user reporting, blocking the link, revoking tokens before use); this is genuine but only a minority slice of the technique, which lives in delivery/social-engineering and is primarily stopped by email filtering, user awareness, and link scanning rather than incident handling.
T1566.002responds — A.5.24 explicitly builds and exercises incident response processes that assess, contain, eradicate, escalate, recover from, learn from, and coordinate on realized incidents (including social-engineering/phishing vectors), which matches the `responds` verb once the spearphishing link technique has executed and produced an event.
T1566.003detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces spearphishing-via-service attempts once they reach the organization, but the control's scope is limited to events that have already arrived rather than proactively detecting the adversary's external account creation or pre-delivery activity.
T1566.003prevents — A.5.24 requires establishing incident management processes, training, detection, triage, response/escalation, root-cause analysis and lessons-learned improvements that can constrain or block recurrence of successful spearphishing-via-service (e.g. by hardening user awareness, tightening external-service policies, or updating controls), but the control itself is governance/preparation and does not directly stop the social-engineering delivery or initial compromise.
T1566.003responds — A.5.24 explicitly establishes incident response processes, procedures for detection/classification/analysis/escalation/response to incidents (including coordination, recovery, root-cause, and lessons learned), which directly enacts the `responds` verb once a spearphishing-via-service event is underway.
T1566.004detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces vishing attempts when they trigger observable events, but the control's scope is limited to post-event detection rather than proactively intercepting the social-engineering voice call itself.
T1566.004prevents — A.5.24 mandates planning, processes, training, detection, response, and learning for incidents (including social-engineering events), which lowers the chance the vishing technique succeeds or escalates but does not stop the initial voice call or user manipulation from occurring.
T1566.004responds — A.5.24 explicitly builds and exercises incident response processes (assess/respond/learn, escalation per 5.26, coordination, root-cause, lessons learned) that activate once a vishing-driven social-engineering event is underway, containing/eradicating it and recovering from realized impact.
T1567detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including those that could encompass data exfiltration), providing broad coverage of the technique once it runs.
T1567responds — A.5.24 explicitly builds and activates an incident response process (assessing, responding to, containing, eradicating, escalating, coordinating, recovering) once an exfiltration incident is underway, matching the `responds` verb; mostly because the control's scope is limited to declared incidents rather than every stealthy exfil event that may evade initial detection.
T1567.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including coordination and post-incident root-cause work), which surfaces T1567.001 exfiltration when it triggers an observable event, but the control's scope is set by organizational priorities and does not mandate coverage of every stealthy HTTPS API call to a legitimate-looking code repo.
T1567.001responds — A.5.24 explicitly builds and activates an incident response process that contains, eradicates, escalates, coordinates, and learns from an information security incident once it is underway, which directly matches the `responds` verb for an exfiltration event that has already begun.
T1567.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including those that could encompass data exfiltration to cloud storage), providing broad detection coverage with only a bounded remainder for undetected stealthy cases.
T1567.002responds — A.5.24 explicitly builds and activates an incident response process that contains, eradicates, escalates, coordinates, and learns from an information security incident once it is underway, which directly matches the `responds` verb for an exfiltration event that has already begun.
T1567.003detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including coordination and evidence handling), which surfaces exfiltration activity to text storage sites when it occurs.
T1567.003responds — A.5.24 explicitly builds and exercises the incident response process (assessing, responding to, containing, eradicating, escalating, coordinating, recovering, and learning from incidents), which directly matches the `responds` verb once an exfiltration event is underway.
T1567.004detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including those that could be exfiltration), which surfaces webhook-based data exfiltration when it occurs.
T1567.004responds — A.5.24 explicitly builds and exercises the incident response process (assessing, responding to, escalating, coordinating, recovering, learning) once an exfiltration incident is underway, directly matching the `responds` verb.
T1568detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (by human or automatic means) as core incident management procedures, which surfaces T1568 activity once underway.
T1568responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, escalating, containing, recovering from, and learning from incidents), which directly acts on a T1568-driven C2 event once underway to bound its spread and remove the foothold.
T1568.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (by human or automatic means) as part of the incident management plan, which surfaces Fast Flux DNS C2 activity once it occurs.
T1568.001responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, escalating, coordinating, recovering from, and learning from incidents), which directly acts on a Fast Flux C2 channel once it is detected and underway.
T1568.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces DGA-driven C2 as anomalous network behavior once underway.
T1568.002responds — A.5.24 explicitly builds and exercises the incident response process (assessing, responding to, containing, eradicating, learning from, and coordinating on incidents), which directly matches the `responds` verb once a DGA-based C2 fallback channel has already activated.
T1568.003detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by automatic means), which surfaces anomalous DNS-based C2 behaviors once they occur, but the control is scoped to organization-chosen criteria, procedures and tools rather than mandating coverage of this specific calculation technique.
T1568.003responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, escalating, and learning from incidents once underway), which directly matches the `responds` verb against any realized T1568.003 C2 channel.
T1569detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including those from system services abuse), providing broad detection coverage across the technique's platforms and execution modes with only narrow remainders outside the defined scope.
T1569responds — A.5.24 explicitly builds and exercises the incident response process (assessing, responding to, containing, eradicating, escalating, and learning from incidents), which directly acts on T1569 once the service-abuse technique is already underway.
T1569.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including those from human or automatic means), which surfaces launchctl abuse when it triggers observable events, but the control's scope is set by organizational priorities and does not mandate instrumentation depth for all macOS-specific technique artifacts.
T1569.001responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, escalating, and learning from incidents once underway), which directly matches the `responds` verb against an in-progress macOS technique that has already executed.
T1569.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for information security events and incidents (including those from service execution abuse), but the control is scoped by organizational priorities, criteria, and chosen instrumentation rather than mandating universal coverage of every possible T1569.002 indicator.
T1569.002responds — A.5.24 explicitly builds and exercises the incident response process (assessing, responding to, containing, eradicating, escalating, and learning from incidents), which directly matches the `responds` verb once T1569.002 execution is underway; the named remainder is that the control is planning/preparation rather than the live IR execution itself (A.5.26).
T1569.003detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities that surface the use of systemctl (or any other command) as part of an incident, providing broad coverage once the technique runs.
T1569.003responds — A.5.24 explicitly builds and exercises the incident response process (assessing, responding to, containing, eradicating, escalating, and learning from incidents), which directly matches the `responds` verb once the systemctl-based technique is underway.
T1570detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including those supporting lateral movement such as anomalous file transfers), providing broad detection capability with only a bounded remainder for transfers that produce no observable event.
T1570responds — A.5.24 explicitly builds and exercises an incident response process that contains, eradicates, escalates, coordinates, recovers from, and learns from security incidents (including those involving lateral tool movement once underway), with only minor named gaps such as purely preventive blocking of the transfer itself.
T1571detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via 8.16 references), which surfaces non-standard port usage as anomalous network behaviour when it occurs, but the control is scoped by organisational priorities and does not mandate universal coverage of all such protocol/port abuse.
T1571responds — A.5.24 explicitly builds and activates an incident response process (assessing, responding to, containing, eradicating, escalating, and learning from incidents once detected), which directly acts on T1571 once the non-standard-port C2 or lateral movement is underway.
T1572detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via 8.16 references), which surfaces protocol tunneling when observed as anomalous traffic or an incident, but the control is scoped to the organization's chosen detection requirements rather than mandating coverage of all tunneling variants.
T1572responds — A.5.24 explicitly builds and activates an incident response process (assessing, responding to, containing, eradicating, escalating, and learning from incidents once detected), which directly matches the `responds` verb for a technique that has already run and is underway.
T1573detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces encrypted C2 channels when they produce observable anomalies, but the control's scope is limited to events that meet incident criteria and does not guarantee detection of all stealthy or custom implementations.
T1573responds — A.5.24 explicitly builds and activates an incident response process (assessing, responding to, containing, eradicating, escalating, and learning from incidents) that directly acts on an already-underway T1573 C2 channel once detected.
T1573.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces the use of symmetric cryptography for C2 as anomalous encrypted traffic when observed.
T1573.001responds — A.5.24 explicitly builds and activates an incident response process (assessing, responding to, containing, eradicating, escalating, and learning from incidents once underway), which directly matches the `responds` verb for an observed T1573.001 C2 channel.
T1573.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces the use of asymmetric cryptography for C2 as an observable event when it aligns with defined detection criteria and scope.
T1573.002responds — A.5.24 explicitly builds and activates an incident response process (assessing, responding to, containing, eradicating, escalating, and learning from incidents including C2), which directly matches the `responds` verb once the asymmetric-C2 technique is underway.
T1574detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including those from hijacked execution flow), but the control's scope is set by organizational priorities, criteria, and chosen scenarios rather than mandating universal coverage of every T1574 sub-technique.
T1574responds — A.5.24 explicitly builds and exercises an incident response process (assess/respond/learn, escalation per 5.26, coordination, controlled recovery) that activates once a hijack-execution-flow incident is underway, containing/eradicating it per defined scenarios and priorities.
T1574.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for security events/incidents (including those from techniques like DLL abuse), but the control is governance-oriented planning/preparation rather than mandating specific detection mechanisms or coverage depth.
T1574.001responds — A.5.24 explicitly builds and exercises incident response processes that assess, contain, eradicate, escalate, coordinate, recover from, and learn from realized incidents (including those using DLL abuse for persistence/privilege-escalation/evasion), which is exactly what `responds` names; the named remainder is that the control stops at procedural readiness and competent execution rather than guaranteeing every possible DLL-based incident is caught and bounded before impact.
T1574.004detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including logging and post-mortem), which surfaces dylib hijacking when it occurs as an incident, but the clause's scope is set by organizational priorities rather than mandating universal instrumentation that would catch every instance on every macOS endpoint.
T1574.004responds — A.5.24 explicitly builds and exercises incident response processes (detection, triage, analysis, response/escalation per 5.26, coordination, recovery activation, root-cause, lessons learned) that act on an already-underway technique such as dylib hijacking once it is observed.
T1574.005detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including logging), which surfaces the technique when it triggers an observable event, but the control is scoped by organizational priorities, criteria and chosen detection mechanisms rather than mandating coverage of every installer-weakness manifestation.
T1574.005responds — A.5.24 explicitly builds and exercises an incident response process (assess, respond to, contain, eradicate, escalate, recover, learn) that activates once an incident is underway, directly addressing T1574.005 execution as a detectable event.
T1574.006detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means) as part of the incident management plan, which surfaces dynamic linker hijacking when it manifests as an observable event or anomaly.
T1574.006responds — A.5.24 explicitly builds and exercises the incident response process (assessing, responding to, containing, eradicating, escalating, coordinating, recovering from, and learning from incidents), which directly matches the `responds` verb once T1574.006 execution is underway; the named remainder is that the control does not itself perform the on-the-wire or in-process containment steps that live in other controls such as SI-4 or IR-4.
T1574.007detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means) as part of the incident management plan, which would surface PATH hijacking when it manifests as anomalous execution or an incident; this is limited to post-execution detection of the technique's impact rather than the setup or modification itself.
T1574.007responds — A.5.24 explicitly builds and exercises an incident response process (assess, respond to, contain, eradicate, escalate, recover, learn) that activates once an incident is declared, directly addressing a realized T1574.007 execution as one of the scenarios it must handle to conclusion.
T1574.008detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (by human or automatic means) plus logging, which surfaces search-order hijacking when it occurs as an incident.
T1574.008responds — A.5.24 explicitly builds and exercises the incident response process (assess, respond to, contain, eradicate, escalate, recover, learn) once an incident is underway, which directly matches the `responds` verb for a realized T1574.008 execution.
T1574.009detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for information security events and incidents, which surfaces path-interception behavior once it manifests as an observable event, but only within the scope of the organization's chosen detection criteria and tooling.
T1574.009responds — A.5.24 explicitly builds and exercises an incident response process that contains, eradicates, escalates, coordinates, and learns from security incidents once they are underway, which directly matches the `responds` verb for a technique that has already executed via path interception.
T1574.010detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for information security events and incidents (including those arising from permission weaknesses that enable binary hijacking), but the control is scoped to post-event detection rather than continuous or preventive instrumentation that would catch the permission flaw itself before exploitation.
T1574.010responds — A.5.24 explicitly builds and exercises an incident response process (assess, respond to, contain, eradicate, escalate, recover, learn) that activates once an incident is underway, directly addressing T1574.010 when it manifests as a detectable service-binary hijack.
T1574.011detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause/post-mortem of incidents (including those from Registry hijacks that trigger on service start), but this is scoped to events that have already become incidents rather than reliably surfacing the underlying permission weakness itself.
T1574.011responds — A.5.24 explicitly builds and requires an incident response process that includes detection, triage, analysis, response/escalation, coordination, root-cause, lessons learned, and controlled recovery once an incident is underway, which directly matches the definition of `responds` for a technique that has already succeeded in achieving persistence or privilege escalation.
T1574.012detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, logging and reporting of information security events and incidents (including via human or automatic means), which surfaces this technique when it triggers observable events, but the control is silent on specific detection of environment-variable or .NET-profiler abuse and many instances can complete without generating a detectable incident.
T1574.012responds — A.5.24 explicitly builds and exercises the incident response process (assess, respond to, contain, eradicate, escalate, recover, learn) once an incident is underway, which directly matches the `responds` verb against a technique that has already executed.
T1574.013detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for information security incidents (including those that could surface via anomalous execution flow), but the control is scoped to incident-management processes rather than mandating specific instrumentation that would reliably surface this low-level, stealthy in-process technique before or during its execution.
T1574.013responds — A.5.24 explicitly builds and exercises the incident response process (assess/respond/learn, escalation, containment via 5.26 cross-ref, root-cause, recovery activation) once an incident is underway, which matches the `responds` verb for a technique already running inside a legitimate process.
T1574.014detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, logging and reporting of information security events and incidents (including by automatic means), which surfaces AppDomainManager hijacking when observed as anomalous behavior, but the control's scope is set by organizational requirements and does not mandate instrumentation that would catch every possible in-process .NET technique.
T1574.014responds — A.5.24 explicitly builds and exercises an incident response process (assess/respond/learn, escalation, containment via crisis/continuity activation, controlled recovery, root-cause and lessons-learned) that activates once an AppDomainManager injection incident is underway, matching the `responds` verb; the named remainder is that the technique's initial execution and payload run before response begins.
T1578detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities that surface the T1578 technique (or its cloud-specific indicators) once it runs.
T1578responds — A.5.24 explicitly builds and activates an incident response process (assessing, responding to, containing, eradicating, escalating, coordinating, recovering, and learning from incidents), which directly matches the `responds` verb once T1578 is underway as a realized security incident.
T1578.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including via human or automatic means), which surfaces the snapshot-creation technique when it qualifies as an event or incident under the plan, but the control's scope is limited to what the organization has defined as reportable incidents rather than universal detection of the technique itself.
T1578.001responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, escalating, coordinating, and learning from incidents once underway), which directly matches the `responds` verb for a technique that has already executed to create the snapshot.
T1578.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by automatic means), which surfaces the creation of a cloud instance as an anomalous event when it occurs within monitored scope.
T1578.002responds — A.5.24 explicitly builds and activates an incident response process (assessing, responding to, escalating, containing via crisis/continuity activation, controlled recovery, and learning) once an incident is declared, which directly matches the `responds` verb for a cloud-instance-creation technique already underway.
T1578.003detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, root cause analysis and post-mortem of incidents (including those that delete evidence), which surfaces the T1578.003 technique or its immediate effects when the deletion itself is treated as or triggers an event, but only for incidents that are noticed and reported rather than fully evading all detection.
T1578.003recovers — A.5.24 explicitly requires procedures for controlled recovery from an incident, activation of continuity plans, root cause analysis, lessons learned, and restoration of normal operations after incident conclusion, which directly recovers from the evidence-destroying effects of the deleted cloud instance in the T1578.003 scenario.
T1578.003responds — A.5.24 explicitly builds and exercises an incident response process (assess, respond, escalate, coordinate, recover, learn) that activates once an incident is underway, directly addressing containment/eradication of a T1578.003 deletion event and its forensic impact.
T1578.004detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, root-cause analysis and post-mortem of incidents (including those from cloud reversion that leave observable artifacts), but the control's scope is limited to events that meet incident criteria and does not mandate instrumentation that would catch every stealthy snapshot-revert or ephemeral-reset on IaaS.
T1578.004responds — A.5.24 explicitly builds and exercises an incident response process (assess, respond to, learn from incidents; manage to conclusion with escalation, controlled recovery, root-cause, lessons learned) that directly acts on an in-flight or just-completed T1578.004 reversion once it is treated as an incident.
T1578.005detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause/post-mortem of incidents (including those from configuration changes), but this is scoped to events already judged as incidents rather than broadly detecting the stealthy pre-impact technique itself.
T1578.005responds — A.5.24 explicitly builds and exercises an incident response process that activates on detected events, contains/escalates the incident (including coordination and recovery activation), and learns from it; this bounds an in-progress T1578.005 modification once it surfaces as an incident, though the pre-detection configuration change itself sits in the named remainder handled by prevents or recovers verbs.
T1580detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces cloud infrastructure discovery performed by a compromised account as an anomalous event; the remainder is that passive discovery via legitimate-looking API calls often evades detection until correlated with other signals.
T1580responds — A.5.24 explicitly builds and activates an incident response process that assesses, responds to, escalates, contains, recovers from, and learns from information security incidents once they are underway, which directly matches the act of responding to a T1580 discovery event that has already begun.
T1583detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including coordination with external parties), which surfaces adversary acquisition of infrastructure when it triggers detectable events such as anomalous domain registrations, cloud provisioning, or traffic anomalies, but this is only a minority slice of a pre-compromise technique that can be conducted covertly with trials, residential proxies, or rapid churn.
T1583.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including those tied to adversary infrastructure like acquired domains used in phishing/C2), but this is scoped to events after they occur rather than proactively detecting the pre-attack domain acquisition itself.
T1583.001responds — A.5.24 explicitly builds and exercises an incident response process that includes detection/classification/analysis of events, managing incidents to conclusion with response/escalation, coordination, root-cause, lessons learned, and controlled recovery, which directly matches the `responds` verb once an adversary's domain-acquisition technique has produced observable events or incidents.
T1583.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces adversary setup and use of their own DNS servers as anomalous activity once it occurs in the monitored environment.
T1583.002responds — A.5.24 explicitly builds incident response processes that include detection, classification, analysis, response/escalation, coordination, and learning from incidents (including those using adversary-controlled infrastructure like custom DNS C2), acting once the technique is underway.
T1583.003detects — A.5.24 requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including coordination with external parties), which can surface anomalous VPS acquisitions or related pre-attack infrastructure activity when it triggers an event within the organization's defined scope, but the technique occurs entirely outside the organization on third-party cloud providers before any organizational event is observable.
T1583.004detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including coordination and logging), which surfaces adversary acquisition and use of servers in post-compromise or operational activity once it becomes an observable event.
T1583.005detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including coordination and logging), which surfaces botnet acquisition/preparation activity when it triggers observable events, but this is limited to post-compromise or in-flight indicators rather than the pre-attack acquisition itself on PRE platforms.
T1583.005responds — A.5.24 establishes incident management processes, response procedures, escalation, coordination, and learning that directly address an active botnet-driven incident (e.g. DDoS or phishing campaigns) once underway, enabling containment, eradication, and post-incident improvements.
T1583.006detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces adversary registration/abuse of web services when it manifests as observable events in the monitored environment, but this is scoped only to events the organization has chosen to instrument and does not guarantee coverage of the pre-compromise registration activity itself.
T1583.007detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces adversary use of serverless infrastructure as anomalous behavior or an incident once it occurs, but does not mandate coverage of pre-compromise infrastructure acquisition on PRE platforms.
T1583.008detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including those from external vectors like malicious ads), but this is scoped to organizational incident management processes rather than directly detecting the adversary's pre-compromise purchase and evasion of advertising networks.
T1583.008responds — A.5.24 explicitly builds and exercises the incident response process (assessing, responding to, containing, eradicating, learning from, and coordinating on incidents), which directly matches the `responds` verb once a malvertising-driven compromise or drive-by is underway.
T1584detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including those involving compromised infrastructure), but the control's scope is limited to events that have already triggered organizational detection mechanisms rather than proactively surfacing the pre-attack compromise itself.
T1584responds — A.5.24 explicitly builds and exercises incident response processes (assess, respond, contain, eradicate, escalate, recover, learn) that activate once an infrastructure compromise is treated as an incident, with the named remainder being pre-compromise adversary activity that never surfaces as a detectable event.
T1584.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces domain hijacking when it manifests as a detectable event, but the control is scoped to post-compromise incident detection rather than pre-positioning reconnaissance or the hijacking technique itself on PRE platforms.
T1584.001responds — A.5.24 explicitly builds and exercises the incident response process (assessing, responding to, containing, eradicating, escalating, coordinating, recovering, and learning from incidents), which directly matches the `responds` verb once a domain-hijacking event has begun; the only bounded remainder is that some pre-compromise hijacking vectors (e.g., registration gaps) may be caught only after impact is realized.
T1584.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including those involving third-party services), which surfaces the compromise of a DNS server or anomalous DNS behavior once it occurs.
T1584.002responds — A.5.24 explicitly builds and exercises an incident response process (assess, respond to, contain, eradicate, escalate, recover, learn) that activates once a DNS-server compromise or its downstream effects (traffic redirection, C2, domain hijack) are treated as an incident.
T1584.003detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including coordination and post-incident root-cause work), which surfaces adversary compromise of a third-party VPS as an information security incident when it is observable within the organization's scope.
T1584.003responds — A.5.24 explicitly builds and exercises an incident response process (assess/respond/learn, escalation, containment via crisis/continuity activation, recovery, root-cause, lessons learned) that activates once an incident is underway, directly addressing the T1584.003 technique when it is detected as an information security incident.
T1584.004detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via automatic means), which surfaces the compromise of third-party servers used in targeting once it becomes an observable event, but the control is scoped to the organization's own incident management and does not reach adversary pre-compromise activity on external third-party infrastructure.
T1584.004responds — A.5.24 explicitly builds and exercises an incident response process (assess, respond to, contain, eradicate, escalate, recover, learn) that activates once an incident is underway, directly addressing post-compromise server use for C2, staging or supporting T1189/T1566.
T1584.005detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including coordination and logging), which surfaces botnet-related activity once underway but only within the organization's own scope and does not address pre-compromise adversary reconnaissance or external botnet building.
T1584.005responds — A.5.24 explicitly builds and exercises incident response processes (assess/respond/learn, escalation, containment via coordination/continuity plans, root-cause, lessons learned) that act on an already-underway botnet takeover or its follow-on effects such as DDoS or phishing campaigns.
T1584.006detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including coordination and post-incident root-cause work), which surfaces adversary compromise of third-party web service accounts as an incident when observed, but only after the initial compromise and with scope limited to what the organization monitors internally or via its incident processes.
T1584.006responds — A.5.24 explicitly builds and exercises incident response processes (assess, respond to, contain, eradicate, escalate, recover, learn) that activate once an incident involving compromised web-service accounts is underway, directly addressing the T1584.006 technique in flight per the event-lane definition.
T1584.007detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via automatic means), which surfaces compromised/abused serverless infrastructure when it generates observable events, but the control's scope is limited to post-compromise incident detection rather than pre-positioning or the full range of stealthy attribution-hiding behaviors described.
T1584.007responds — A.5.24 explicitly builds and exercises the incident response process (assessing, responding to, containing, eradicating, escalating, and learning from incidents), which directly matches the `responds` verb once a T1584.007-compromised serverless function is detected as part of an active incident.
T1584.008detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including those involving compromised devices used for C2 or phishing support), but the control is scoped to the organization's own incident management processes and does not reach adversary compromise activity on third-party/pre-owned network devices outside its visibility.
T1584.008responds — A.5.24 explicitly builds and exercises incident response processes (assess/respond/learn, escalation per 5.26, coordination, recovery activation, post-mortem, lessons learned) that act on an already-underway compromise of a network device to contain, eradicate, and improve after the fact.
T1585detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including coordination with external parties), which surfaces adversary account-creation activity when it triggers an observable event, but the PRE platform and pre-compromise nature of T1585 leave the bulk of persona-building undetected by organizational incident processes.
T1585.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces adversary creation/cultivation of social media personas during the pre-attack phase when those activities produce observable events inside the organization's monitoring scope.
T1585.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including those tied to adversary behaviors like account creation for phishing/infra), but this is scoped to organizational systems and does not broadly cover pre-compromise adversary creation of external disposable email accounts on third-party providers.
T1585.002responds — A.5.24 explicitly builds and exercises an incident response process that includes detection, triage, analysis, response/escalation, coordination, evidence handling, root-cause, lessons learned, and recovery activation once an incident (including pre-attack behaviors surfaced as events) is underway.
T1585.003detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces adversary creation and use of cloud accounts as an information security event when it occurs within organizational scope or is observable through coordinated channels.
T1586detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces account compromises when they qualify as reportable events, but the control's scope is limited to post-compromise incident handling rather than proactively detecting the upstream methods (phishing, credential purchases, brute forcing) before the account is leveraged.
T1586responds — A.5.24 explicitly builds and activates an incident response process (assessing, responding to, escalating, containing, recovering from, and learning from incidents), which directly matches the `responds` verb once an account compromise event is underway.
T1586.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including those from external interested parties), which surfaces compromised social media accounts used in targeting when they trigger an observable event, but this is scoped only to the organization's own incident management processes and does not broadly detect the adversary's pre-compromise reconnaissance or credential theft.
T1586.001responds — A.5.24 explicitly establishes incident response processes, assessment/response/escalation to conclusion, coordination, and learning from incidents (including those from social engineering via compromised accounts), acting once the technique is underway.
T1586.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including those involving compromised accounts used for phishing/spam), but this is scoped to the organization's own incident management processes and does not address adversary pre-compromise reconnaissance or external account compromise on PRE platforms.
T1586.002responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, escalating, coordinating, recovering from, and learning from incidents), which directly matches the `responds` verb once an adversary has already compromised and begun using an email account in operations.
T1586.003detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including those that could surface compromised cloud accounts), but the control is scoped to post-compromise incident handling rather than proactive detection of the account-compromise techniques themselves.
T1586.003responds — A.5.24 explicitly builds and exercises an incident response process (assess, respond to, contain, eradicate, escalate, recover, learn) that activates once a cloud-account compromise is detected as an incident, matching the `responds` verb; the named remainder is that the control does not itself perform the response actions but ensures they exist and are executed by competent personnel.
T1587.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces the creation and use of self-signed code signing certificates as anomalous activity when it occurs within monitored scope, but the control's detection is scoped by organizational priorities rather than mandating universal coverage of pre-attack certificate development.
T1587.003detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces the creation and use of self-signed certificates when observed as anomalous events in the monitored scope, but does not guarantee detection of all pre-attack certificate creation on adversary-controlled infrastructure outside that scope.
T1587.003responds — A.5.24 explicitly builds incident response processes that assess, respond to, contain, eradicate, escalate, recover from, and learn from security incidents (including those using self-signed certs for C2, MitM, or trust abuse), once the technique has run and produced observable impact.
T1588detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting and logging of information security events and incidents (including coordination with external parties), which surfaces adversary acquisition of capabilities when it triggers detectable events such as anomalous downloads, marketplace interactions, or post-acquisition use; this is a genuine but bounded slice because much of the technique (e.g., offline purchases, closed-database raids, or pre-positioned thefts) can occur without generating observable organizational events.
T1588responds — A.5.24 explicitly builds and activates an incident response process that contains, eradicates, escalates, coordinates, and learns from realized incidents (including those involving stolen or purchased capabilities), matching the `responds` verb once the acquisition technique has run.
T1588.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces acquisition activity when it manifests as detectable events on organizational systems or networks, but the pre-compromise PRE platform technique of simply buying/stealing/downloading malware has no guaranteed observable footprint inside the organization.
T1588.001responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, learning from incidents) that activates once adversary-acquired malware is used in an attack, directly addressing the post-compromise behaviors the technique enables.
T1588.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces adversary tool acquisition when it triggers observable events, but this is limited to post-acquisition activity rather than the pre-compromise acquisition act itself on PRE platform.
T1588.002responds — A.5.24 explicitly builds and activates an incident response process that assesses, contains, eradicates, escalates, coordinates, and learns from realized incidents (including those using acquired tools post-compromise), matching the `responds` verb once the technique has run.
T1588.003detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces the purchase or theft of code signing certificates when treated as an incident or precursor event, but only within the scope of the organization's defined detection processes and does not guarantee coverage of all pre-attack acquisition activity.
T1588.004detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including coordination with external parties and evidence handling), which surfaces the acquisition or use of stolen/purchased certificates when it triggers an observable event, but the technique occurs in the pre-compromise phase outside organizational visibility and many acquisitions (e.g. free Let's Encrypt or front-organization purchases) leave no detectable event.
T1588.004responds — A.5.24 establishes incident management processes, response procedures, escalation, coordination, root-cause analysis, and learning that directly address an incident once the certificate acquisition technique has run and produced its artifact (e.g., stolen cert used in C2 or MitM).
T1588.005detects — A.5.24 requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including coordination and logging), which can surface adversary acquisition of exploits as an event when observable in the monitored environment, but this is limited to post-acquisition activity within organizational scope rather than the pre-compromise acquisition technique itself.
T1588.005responds — A.5.24 explicitly builds and exercises an incident response process (assess, respond to, contain, eradicate, learn from incidents including those from exploited vulnerabilities), which activates once an exploit has been used in an attack.
T1588.006detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces adversary activity that acquires vulnerability information through open/closed databases or targeting of research systems, but only for events that cross into detectable organizational telemetry rather than all pre-compromise reconnaissance.
T1588.007detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces adversary use of AI tools when that use produces observable events fitting the organization's incident criteria; this is genuine but only a minority slice because most pre-compromise AI-assisted targeting (e.g. private LLM use for recon, script generation or phishing content) leaves no detectable organizational event until downstream execution.
T1588.007responds — A.5.24 explicitly builds and exercises an incident response process that assesses, responds to, contains, escalates, coordinates, recovers from, and learns from information security incidents once they are underway, which directly matches the `responds` verb for an adversary technique already in execution.
T1589detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces the reconnaissance activity of gathering victim identity information when it triggers detectable events, but only a minority slice of T1589's passive OSINT, public leaks, or pre-compromise enumeration is likely to register as an organizational event.
T1589.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces credential-gathering activity once it produces observable events, but the control is scoped to post-event incident management rather than proactive detection of pre-compromise reconnaissance on external data sources or dark-web markets.
T1589.001responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, learning from, and coordinating on incidents), which directly matches the `responds` verb once credential-gathering has produced an observable security incident.
T1589.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces the adversary's email address gathering when it triggers observable events, but the control is scoped to post-event incident management rather than proactively detecting the reconnaissance technique itself across all cases.
T1589.003detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces the reconnaissance activity of gathering employee names when it triggers an observable event or crosses into incident criteria.
T1589.003responds — A.5.24 explicitly builds incident response processes that include detection/classification/analysis of events, response/escalation to incidents, coordination, root-cause, lessons learned and improvements once an incident is underway; gathering of employee names (a PRE reconnaissance technique) is surfaced and acted on when it triggers an incident such as a phishing campaign or data leak.
T1590detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces the T1590 reconnaissance activity once it produces observable events, but only within the scope of the organization's defined incident detection criteria and tooling.
T1590responds — A.5.24 explicitly builds incident management processes that include detection, triage, analysis, response/escalation, coordination, and learning once an information security event or incident is underway, which directly matches the act of responding to the reconnaissance technique T1590 when it manifests as a detectable event.
T1590.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces the reconnaissance activity once it triggers observable events, but the control's scope is limited to events that meet the organization's defined incident criteria and does not broadly instrument passive/public data gathering on PRE platforms.
T1590.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces reconnaissance activity such as DNS queries or zone transfers when observed as an event.
T1590.003detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces the reconnaissance activity when it triggers observable events, but the control's scope is limited to events that meet incident criteria and does not broadly instrument all pre-compromise OSINT or elicitation against network trust data.
T1590.003responds — A.5.24 explicitly requires an incident response process (assessing, responding to, and learning from incidents), managing incidents to conclusion with escalation/response per category, coordination with external parties, and activation of continuity plans, which directly addresses a PRE technique once the gathered trust-dependency information has enabled follow-on activity such as T1199 or T1584.
T1590.004detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces reconnaissance techniques like T1590.004 when they trigger observable events, but the control's scope is limited to events that meet incident criteria rather than all pre-compromise topology gathering.
T1590.004responds — A.5.24 explicitly builds incident management processes that include detection, classification, analysis, response/escalation, coordination, and learning from security incidents (including those surfaced via monitoring), which directly enacts the `responds` verb once reconnaissance like T1590.004 is underway as an information security event.
T1590.005detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces the reconnaissance technique once it produces observable events, but the control is scoped to incident management rather than continuous reconnaissance detection and the technique is pre-compromise with limited inherent events.
T1590.005responds — A.5.24 explicitly builds and activates an incident response process that assesses, contains, eradicates, escalates, coordinates, and learns from security incidents (including those triggered by discovered reconnaissance like IP-address gathering), which is the core meaning of `responds` once the technique has run.
T1590.006detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via 8.16 references), which surfaces reconnaissance activity against network security appliances when it registers as an observable event.
T1591detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces T1591 activity when it manifests as a detectable event such as phishing for information or anomalous data access, but the control's scope is limited to post-event/incident detection rather than passive OSINT gathering on public data sets.
T1591.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces the reconnaissance activity when it triggers observable events, but the control's scope is limited to post-event incident management rather than broad pre-incident detection of passive OSINT gathering on physical locations.
T1591.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including those tied to supply-chain or third-party relationships), which surfaces the reconnaissance activity once it produces observable events.
T1591.002responds — A.5.24 establishes incident management processes that include detection, classification, analysis, response/escalation, coordination with external parties, and learning from incidents, which directly enables responding to a realized T1591.002 reconnaissance activity (e.g., via phishing or exposed data leading to supply-chain follow-ons) once underway.
T1591.003detects — A.5.24 requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces reconnaissance activity such as business-tempo gathering when it triggers an observable event, but the control's scope is limited to events the organization has defined as reportable and does not guarantee coverage of passive/pre-compromise OSINT.
T1591.004detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including those arising from reconnaissance like role identification via phishing or public data exposure), providing detection capability once the technique surfaces as an observable event.
T1592detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces the reconnaissance activity once it produces observable events, but the control's scope is limited to post-event incident management rather than broad proactive detection of all pre-compromise T1592 vectors such as passive data-set exposure or non-event reconnaissance.
T1592.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces reconnaissance activity such as hardware information gathering when it triggers an observable event.
T1592.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces reconnaissance activity like T1592.002 when it triggers an observable event, but the control's scope is limited to events that meet incident criteria rather than all passive or external reconnaissance.
T1592.002responds — A.5.24 explicitly builds and exercises an incident response process that includes detection, triage, analysis, response/escalation, coordination, and learning once an information security incident is underway, which directly matches the `responds` verb for a pre-attack reconnaissance technique that has already executed.
T1592.003detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces reconnaissance activity such as firmware information gathering when it triggers an observable event.
T1592.004detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces reconnaissance activity such as client configuration gathering when it triggers an observable event.
T1592.004responds — A.5.24 explicitly builds and activates an incident response process that includes detection, classification, analysis, response/escalation, coordination, and learning once an information security incident is underway, which directly matches the `responds` verb for a pre-attack reconnaissance technique that has already begun gathering client configuration data.
T1593detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including those arising from open-source reconnaissance like T1593), but this is scoped to events that meet the organization's defined criteria for incidents rather than broadly detecting all instances of the pre-compromise technique.
T1593.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces the social-media reconnaissance technique when it triggers observable events inside the defined scope, but the control's detection is scoped only to declared incidents rather than passive OSINT harvesting itself.
T1593.001responds — A.5.24 explicitly builds and exercises an incident response process that activates on detected events (including those surfaced via monitoring/detection in 8.16), contains them through coordinated response/escalation, and learns from them; social-media reconnaissance that triggers an incident (e.g., spearphishing prep or fake-profile activity) falls inside that scope once underway.
T1593.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces the adversary's search-engine activity once it produces observable spillages or leaks, but the control is scoped to post-event incident management rather than proactive detection of all reconnaissance.
T1593.003detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces adversary searches of public code repositories when they trigger detectable events, but the control's scope is limited to events that meet the organization's defined incident criteria rather than broadly detecting all such reconnaissance.
T1594detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via automated means), which surfaces reconnaissance activity once it triggers observable events on monitored victim systems or networks, but the technique is defined as occurring in the pre-compromise stage against external victim-owned websites with no guaranteed telemetry inside organizational detection scope.
T1595detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by automatic means), which surfaces active scanning as anomalous network traffic before or during the technique.
T1595responds — A.5.24 builds and activates an incident response process that contains, eradicates and learns from detected scanning once it is underway (monitoring/detection/classification/response/escalation per the listed activities), with the named remainder that pre-attack reconnaissance on PRE platforms may finish before organizational detection/response can act.
T1595.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by automatic means), which surfaces scanning activity when it registers as an event inside the defined criteria and scope.
T1595.001responds — A.5.24 explicitly builds and activates an incident response process that contains, eradicates, escalates, coordinates, and learns from detected scanning once it is recognized as an information security incident.
T1595.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by automatic means), which surfaces vulnerability scanning activity as an information security event when observed.
T1595.002responds — A.5.24 explicitly builds and activates an incident response process that includes detection, analysis, classification, response/escalation, and coordination once an information security event (such as a vulnerability scan) is underway.
T1595.003detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means) as part of the incident management plan, which would surface wordlist scanning as anomalous probing or reconnaissance activity once it occurs.
T1595.003responds — A.5.24 explicitly builds and activates an incident response process (assessing, responding to, containing, eradicating, escalating, and learning from incidents) that directly addresses T1595.003 once the scanning is detected as an information security event/incident.
T1596detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by automatic means), which surfaces reconnaissance activity such as T1596 when it triggers observable events, but the control is scoped to incident management rather than continuous or proactive detection of all pre-incident reconnaissance.
T1596.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by automatic means), which surfaces reconnaissance activity such as DNS/passive DNS searches when it triggers an event or crosses a detection threshold, but the control is scoped to incident management rather than continuous reconnaissance-specific detection.
T1596.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces the WHOIS reconnaissance technique when it triggers an observable event inside the organization's defined detection scope.
T1596.003detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which can surface reconnaissance activity such as certificate data searches when it triggers observable events or anomalies, but this is scoped only to events the organization has defined as incidents and does not broadly instrument external public certificate lookups.
T1596.005detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including those from external sources), which surfaces reconnaissance activity such as scanning public databases when it triggers an observable event, but the control is scoped to incident management rather than continuous external threat-intelligence collection.
T1597detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces adversary activity that uses purchased closed-source data as part of the reconnaissance-to-initial-access chain once it triggers an observable event.
T1597.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting and logging of information security events and incidents (including coordination with external parties such as threat intel vendors), which surfaces adversary searches of private vendor data as an incident but only within the scope of events the organization already monitors or is notified about.
T1597.001responds — A.5.24 explicitly builds and activates an incident response process (assessing, responding to, learning from incidents; escalation, coordination, root-cause, lessons learned) that contains and eradicates an adversary's use of purchased threat-intel data once it surfaces as part of an incident.
T1597.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including those tied to reconnaissance like purchased data that may surface as anomalous activity), but this is scoped to organizational events post-purchase rather than reliably detecting the adversary's external purchase act itself on PRE platforms.
T1598detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including those from social engineering like phishing), but this is scoped to the organization's own incident management processes and does not address detection of the pre-compromise T1598 technique itself on external platforms.
T1598prevents — A.5.24's planning, training, detection, response processes, and awareness of social engineering reduce successful elicitation of information via phishing but do not stop the adversary from sending the messages or guarantee victims will not divulge data.
T1598responds — A.5.24 explicitly builds and activates an incident response process (assessment, response/escalation per 5.26, coordination, containment to conclusion) once a phishing-for-information event is classified as an incident, directly matching the `responds` verb on an event already underway.
T1598.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including those arising from social engineering like spearphishing), but the control's scope is limited to events that reach the organization and its defined criteria rather than all external/pre-delivery instances of the technique.
T1598.001prevents — A.5.24's planning, training, detection, response processes, and awareness of social engineering reduce successful elicitation via spearphishing but do not stop the adversary technique from being executed against users on third-party services.
T1598.001responds — A.5.24 explicitly builds and exercises the incident response process (assessing, responding to, containing, eradicating, learning from, and coordinating on incidents), which activates once a spearphishing-for-information event is underway and detected.
T1598.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (by human or automatic means) as part of the incident management plan, which surfaces spearphishing attachment events once they reach the organization.
T1598.002prevents — planning, training, competent personnel, detection/classification processes, and user reporting procedures reduce the chance the spearphishing succeeds or goes unnoticed, but do not stop the adversary from sending the message or guarantee the recipient will not be tricked
T1598.002responds — A.5.24 explicitly builds and activates an incident response process (assessing, responding to, containing, eradicating, escalating, coordinating, recovering from, and learning from incidents), which directly matches the `responds` verb once a spearphishing-attachment event is underway; the only bounded remainder is that purely pre-delivery social-engineering lures may be caught only after the message arrives and is recognized as an event.
T1598.003detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including those from social engineering like spearphishing links), with procedures for evaluation, logging, and coordination that surface the technique once underway.
T1598.003prevents — planning, training, detection processes, and procedures for evaluating/reporting events can stop some social-engineering lures from succeeding when users follow them, but cannot block the adversary from sending the messages or guarantee every recipient will recognize and avoid the link
T1598.003responds — A.5.24 explicitly builds and activates an incident response process (assess, respond to, learn from incidents; manage to conclusion with escalation, containment via crisis/continuity plans, root-cause, lessons learned) once a spearphishing event is classified as an incident, which matches the `responds` verb; the named remainder is pre-delivery reconnaissance and lure-crafting that sits outside post-event response.
T1598.004detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including social-engineering-driven ones like vishing that produce observable events), but the control's scope is limited to events that have already reached the organization and does not address pre-delivery detection of the vishing calls themselves.
T1598.004prevents — planning, training, detection, response processes, and awareness of vishing as a social-engineering vector lower the chance the technique succeeds (victims less likely to divulge), but do not stop the adversary from executing the call itself
T1598.004responds — A.5.24 explicitly builds and activates incident response processes (assessment, response/escalation per 5.26, coordination, containment to conclusion, root-cause, lessons learned) that act on a vishing event once underway, containing damage and removing the actor's foothold even though the elicitation may have already succeeded.
T1599detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for information security events and incidents, which would surface boundary-bridging activity once it manifests as a detectable event on perimeter or segmentation devices.
T1599responds — A.5.24 explicitly builds and exercises incident response processes (assess/respond/escalate to conclusion, coordinate parties, activate continuity plans, controlled recovery, root-cause/lessons) that act on a boundary-bridging incident once underway, containing/eradicating it per the event-lane definition of responds; the named remainder is that the technique has already succeeded in reconfiguring the device before response begins.
T1599.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for security events and incidents, which would surface anomalous NAT modifications on boundary devices as incidents once they occur or are observed.
T1599.001responds — A.5.24 explicitly builds and activates an incident response process (assessing, responding to, escalating, coordinating, recovering from, and learning from incidents), which directly matches the `responds` verb once the NAT-traversal technique is underway as an information security incident.
T1600detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces the T1600 technique or its indicators once it has occurred on a network device.
T1600responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, escalating, coordinating, recovering, and learning from incidents), which directly matches the `responds` verb once T1600 has run and encryption is already weakened.
T1600.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces the technique when it manifests as a detectable event on a network device.
T1600.001responds — A.5.24 explicitly builds and exercises an incident response process that includes detection, triage, analysis, response/escalation, coordination, root-cause, lessons learned and controlled recovery once an incident is underway, which directly matches the `responds` verb against an already-executed T1600.001 weakening of device crypto.
T1600.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces the disabling of crypto hardware as an anomalous event on network devices.
T1600.002responds — A.5.24 explicitly builds and exercises an incident response process (assess, respond to, learn from incidents; manage to conclusion with escalation, controlled recovery, root-cause, lessons learned) that activates once an incident is underway, directly addressing T1600.002 once the hardware-disable technique has executed on a compromised device.
T1601detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces the T1601 technique when it triggers observable events, but the control's scope is limited to defined incident-management processes rather than universal coverage of all possible modification vectors on embedded devices.
T1601responds — A.5.24 explicitly builds and exercises an incident response process that contains, eradicates, escalates, coordinates, and learns from an already-underway incident, which directly matches the `responds` verb once T1601 has executed and altered the system image.
T1601.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause/post-mortem of incidents (including those from modified device images that produce anomalous behavior or false output), but this is scoped to the incident-management process rather than continuous instrumentation that would catch the technique in all cases or before impact.
T1601.001responds — A.5.24 explicitly builds and exercises the incident response process (assess, respond to, contain, eradicate, escalate, recover, learn) once an incident is underway, directly addressing T1601.001 when it is detected as an information security incident.
T1601.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces the downgrade activity or its indicators once it occurs, but only within the scope of events the organization has defined as reportable incidents.
T1601.002responds — A.5.24 explicitly builds and exercises an incident response process that includes detection/classification of events, managing incidents to conclusion with response/escalation, root-cause analysis, and learning/improvements, which directly acts on an in-flight downgrade technique (once the anomalous image change or its effects are observed) to contain, eradicate, and learn from it.
T1602detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including those involving data exfiltration from repositories), which surfaces the T1602 technique when it triggers an observable event.
T1602responds — A.5.24 explicitly builds and activates an incident response process that contains, eradicates, escalates, coordinates, and learns from an information security incident once it is underway, which directly matches the `responds` verb against an adversary technique that has already succeeded in collecting data from a configuration repository.
T1602.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including via human or automatic means), which surfaces SNMP MIB queries as anomalous network or device activity.
T1602.001responds — A.5.24 explicitly builds and activates incident response processes (assessment, response/escalation per 5.26, coordination, containment via crisis/continuity plans, root-cause, lessons learned) that act on an already-underway SNMP MIB collection event to bound its spread and remove the adversary foothold.
T1602.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities that surface the technique (or its artifacts) once it runs on network devices.
T1602.002responds — A.5.24 explicitly builds and activates an incident response process that contains, eradicates, escalates, coordinates, and learns from an information security incident once it is underway, which matches the `responds` verb against an already-executing T1602.002 collection technique.
T1606detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including those involving forged credentials used for access), but the control is scoped to an incident-management process that activates on recognized events rather than continuous detection mechanisms for the forging technique itself.
T1606responds — A.5.24 explicitly builds and exercises an incident response process (assess, respond to, contain, eradicate, escalate, recover, learn) that activates once a forged-credential incident is underway, matching the `responds` verb; the named remainder is that the initial forgery act itself is not contained by the response process.
T1606.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including logging), which surfaces the technique when it manifests as a detectable event but does not guarantee coverage of all forgery vectors or post-access use.
T1606.001responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, escalating, coordinating, recovering from, and learning from incidents), which directly matches the `responds` verb once a forged-cookie incident is underway.
T1606.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces forged SAML token usage once it occurs as an anomalous security event, but the control's scope is set by organizational priorities and does not mandate instrumentation depth sufficient to catch all variants (e.g. those using legitimate-looking claims or external IdPs).
T1606.002responds — A.5.24 explicitly builds and exercises the incident response process (assess, respond to, contain, eradicate, escalate, recover, learn) once an incident is underway, directly addressing forged SAML tokens used for unauthorized access or privilege escalation.
T1608detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including those tied to adversary staging behaviors on infrastructure), but this is scoped only to the organization's own assets and does not extend to detecting adversary staging on external/pre-compromise infrastructure they control.
T1608.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces the upload/staging activity when it is treated as an event; this is only a slice of the PRE technique because detection occurs after upload and depends on scope, instrumentation and event-classification criteria rather than guaranteeing discovery of all adversary-controlled malware staging.
T1608.001responds — A.5.24 explicitly builds and exercises an incident response process that includes detection/classification/analysis of events, managing incidents to conclusion with response/escalation, coordination, root-cause, lessons learned, and controlled recovery, which directly matches the `responds` verb once an upload (or its downstream effects) is treated as an information security incident.
T1608.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces adversary upload activity when it triggers observable events on controlled infrastructure or during later targeting phases, but this is scoped only to the organization's own incident management detection surface and does not address pre-compromise or third-party staging.
T1608.003detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces the certificate-installation activity when it registers as an event or incident within the organization's defined scope.
T1608.004detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including those from web-borne delivery), but this is scoped only to events that reach the organization and does not address pre-deployment adversary staging on external infrastructure.
T1608.005detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including those tied to phishing links and malicious resources), but this is scoped to events after the link target resources are already in place and the technique has run, not the pre-deployment setup activity itself.
T1608.005responds — A.5.24 explicitly builds and exercises an incident response process that assesses, contains, eradicates, escalates, coordinates, logs, and learns from realized security incidents (including those triggered by users following malicious links), matching the `responds` verb once the technique has run.
T1608.006detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces SEO poisoning when it manifests as a detectable event such as anomalous content changes or suspicious redirects, but the control's scope is limited to post-event detection rather than proactively finding the pre-attack SEO manipulation itself on PRE platforms.
T1609detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via automatic means), which surfaces the technique when it triggers observable events but does not mandate coverage of all container-specific administration vectors or logs.
T1609responds — A.5.24 explicitly builds and exercises the incident response process (assess, respond to, contain, eradicate, learn) that activates once a container-administration technique is detected in flight, matching the `responds` verb and the IR-4 / A.5.26 event-lane anchors.
T1610detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including via human or automatic means), which surfaces the container deployment technique when it registers as an event, but the control's scope is limited to what the organization has defined as reportable incidents rather than universal detection of all T1610 instances.
T1610responds — A.5.24 explicitly builds and activates incident response processes that contain, eradicate, escalate, coordinate, recover from, and learn from an already-underway security incident, which directly matches the `responds` verb once a T1610-deployed container triggers detection.
T1611detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces container/host escape techniques once they trigger observable events, but the control's scope is set by organizational priorities and does not mandate instrumentation depth for all escape vectors (e.g., kernel-module loads or unshare abuse).
T1611responds — A.5.24 explicitly builds and exercises the incident response process (assess/respond/learn, escalation, containment via crisis/continuity activation, root-cause, lessons-learned) that activates once a container/host escape is underway, exactly matching the `responds` verb.
T1612detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via automatic means), which surfaces the build-image activity when it is treated as an event, but the clause's scope is set by organizational priorities and does not mandate instrumentation that would reliably catch a Docker build API call or the resulting malicious image on every container host.
T1612responds — A.5.24 explicitly establishes incident response processes, procedures for detection/classification/analysis/escalation/response to incidents (including coordination, root-cause, lessons learned), and activation of crisis/continuity plans once an event is underway, which directly matches the `responds` verb for containing/eradication of T1612 once the build or subsequent deployment is detected.
T1613detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting and logging of information security events and incidents (including via human or automatic means), which surfaces T1613 activity such as API queries or dashboard access when it occurs.
T1613responds — A.5.24 explicitly builds and activates an incident response process (assessing, responding to, containing, eradicating, escalating, and learning from incidents) that activates once discovery techniques like T1613 are underway as part of a broader incident.
T1614detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces the T1614 discovery activity once it occurs as an observable event.
T1614responds — A.5.24 explicitly builds and activates an incident response process that contains, eradicates, escalates, coordinates, and learns from security incidents once they are underway, which matches the `responds` verb for a discovery technique that has already executed.
T1614.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by automatic means), which surfaces the discovery technique when it manifests as observable anomalous behavior within the defined incident management scope.
T1614.001responds — A.5.24 explicitly builds and exercises an incident response process that contains, eradicates, escalates, coordinates, and learns from security incidents once they are underway, which directly matches the `responds` verb for a discovery technique that has already executed.
T1615detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including via human or automatic means), which surfaces Group Policy Discovery activity when it qualifies as an event or incident under the plan's criteria.
T1615responds — A.5.24 explicitly builds incident response processes that include detection, triage, analysis, classification, response/escalation, coordination, and learning from security incidents, which directly addresses an in-progress discovery technique once it is observed as an event.
T1619detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (by human or automatic means) as part of the incident management plan, which surfaces T1619-style discovery activity once it occurs.
T1619responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, escalating, and learning from incidents once underway), which directly matches the `responds` verb for a discovery technique that has already executed.
T1620detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, logging and reporting of information security events and incidents (including by automatic means), which surfaces reflective code loading when it is treated as an observable incident; the remainder is that the clause sets scope by organisational priorities rather than mandating instrumentation depth that reliably catches in-memory reflective loading across all processes.
T1620responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, learning from incidents) that activates once a reflective-loading event is classified as an incident, matching the `responds` verb; mostly because the control stops at procedural readiness and competent personnel rather than guaranteeing every in-flight T1620 instance is contained before impact.
T1621detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces MFA request generation and fatigue patterns as anomalous events once they occur.
T1621prevents — A.5.24 requires establishing incident management processes, detection/monitoring, classification, response/escalation procedures, training, and coordination that can interrupt or contain an ongoing MFA fatigue campaign (e.g., by quickly notifying users, rate-limiting, or activating response), but does not stop the adversary from generating the initial requests or prevent the technique from being attempted.
T1621responds — A.5.24 explicitly builds and exercises an incident response process (assess, respond to, learn from incidents; escalation per 5.26; coordination; root-cause and lessons-learned) that activates once an MFA-fatigue or push-bombardment event is recognized as an incident, containing/eradication steps follow the technique's run.
T1622detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means) as part of building incident management capability; this surfaces debugger-evasion artifacts when they manifest as observable events during analysis or response, but the control is silent on debugger-specific detection mechanisms or automated discovery of the technique itself.
T1622responds — A.5.24 explicitly builds and exercises the incident response process (assess, respond to, contain, eradicate, learn from incidents including those surfaced by dynamic analysis/debugger evasion artifacts), acting once the technique is underway.
T1647detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for information security events and incidents, which can surface plist modifications when they qualify as reportable events under the organization's criteria, but the control is agnostic to technique-specific observables and depends on what the organization elects to instrument.
T1647responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, learning from, and coordinating on incidents), which directly matches the `responds` verb once a plist-modification technique has executed and is underway.
T1648detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by automatic means) as part of the incident management plan, which surfaces serverless abuse when it registers as an event or incident but does not guarantee coverage of all stealthy or event-triggered serverless executions.
T1648responds — A.5.24 explicitly builds and exercises incident response processes (assess/respond/learn, escalation, containment via crisis/continuity activation, root-cause, lessons learned) that act on an already-underway serverless abuse technique exactly as the event-lane anchor defines `responds`.
T1649detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause/post-mortem of incidents (including those from certificate theft/forgery), but detection is scoped to events that have already triggered the incident-management pipeline rather than reliably surfacing the stealthy credential-theft or golden-certificate techniques themselves.
T1649responds — A.5.24 explicitly builds and activates an incident response process (assessing, responding to, escalating, containing via crisis/continuity plans, coordinating parties, root-cause, lessons learned) once an incident is underway, which directly matches the `responds` verb for a certificate theft/forgery event that has already occurred.
T1650detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces the acquisition of access when it manifests as a detectable event or incident, but the technique itself is a pre-compromise purchase that can occur without triggering any organizational event.
T1650responds — A.5.24 explicitly builds and activates an incident response process (assess/respond/escalate to conclusion, including coordination and recovery) once an acquired foothold manifests as a detectable event or incident.
T1651detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including those from cloud admin abuse), but the control is scoped by organizational priorities, criteria, and chosen instrumentation rather than mandating universal coverage of T1651.
T1651responds — A.5.24 explicitly builds and activates an incident response process (assessing, responding to, escalating, containing via crisis/continuity activation, controlled recovery, and learning) once an incident is underway, which directly matches the `responds` verb for a post-execution technique like T1651.
T1652detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, logging and reporting of information security events and incidents (including by automatic means), which surfaces the T1652 enumeration activity when it is treated as an event, but the clause's scope is set by organizational priorities and does not mandate instrumentation that would catch every possible driver-discovery method on every platform.
T1652responds — A.5.24 explicitly builds and exercises an incident response process that contains, eradicates, escalates, coordinates, and learns from security incidents once they are underway, which directly matches the `responds` verb for an adversary technique that has already executed on a victim host.
T1653detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including those that could match T1653's observable configuration changes or anomalous power-setting abuse), but this is scoped by organizational priorities, criteria, and procedures rather than mandating universal coverage of every possible technique.
T1653responds — A.5.24 explicitly builds and activates an incident response process that includes assessing, responding to, escalating, and managing incidents to conclusion (including coordination, recovery activation, root-cause, and lessons), which directly matches the `responds` verb once the T1653 technique has run and impaired power/hibernation settings.
T1654detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities that surface log enumeration (including real-time monitoring of IR itself) as an information security event or incident.
T1654responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, learning from incidents; escalation per 5.26; real-time monitoring of events) that directly counters an adversary monitoring logs to track and evade incident response, enabling containment/eradication once the technique is underway.
T1657detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities that surface financial theft incidents (including ransomware extortion, BEC, and related T1486/T1586 chains) once underway.
T1657prevents — planning/roles/training for incident management and response (including detection, triage, escalation, recovery activation, and coordination) can stop some financial theft techniques (e.g., by enabling rapid response to BEC, ransomware extortion, or unauthorized transfers before funds are fully lost), but leaves many others (social engineering, initial account compromise, or technical theft) untouched as this is a preparedness control, not a preventive one.
T1657recovers — A.5.24 requires incident management procedures that explicitly include controlled recovery from an incident, activation of continuity plans, root-cause analysis, lessons learned, and improvements that restore availability of monetary resources after financial theft events such as ransomware extortion or BEC fraud.
T1657responds — A.5.24 explicitly builds and exercises the incident response process (assess/respond/learn, escalation, containment via crisis/continuity activation, recovery, root-cause, lessons) that activates once financial-theft incidents (ransomware extortion, BEC fraud, etc.) are underway, matching the `responds` verb definition.
T1659detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via 8.16 references), which surfaces T1659 activity once it produces observable events, but the control is scoped to organizational incident management processes rather than mandating comprehensive network-level detection of upstream ISP or traffic-injection techniques.
T1659responds — A.5.24 explicitly builds and exercises an incident response process (assess, respond to, contain, eradicate, escalate, recover, learn) that activates once an injected-content event is classified as an incident, matching the `responds` verb; the named remainder is upstream ISP-level injection that may already have achieved persistence before organizational detection/response begins.
T1665detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for information security events and incidents, which surfaces adversary infrastructure-hiding techniques once they trigger observable events (e.g., anomalous traffic or C2 artifacts), but only within the scope of chosen detection criteria and does not guarantee coverage of all stealth methods or pre-event hiding.
T1665responds — A.5.24 explicitly builds and exercises the incident response process (assessing, responding to, escalating, coordinating, recovering from, and learning from incidents), which directly contains and eradicates an active T1665 campaign once its hidden C2 is discovered and the incident declared.
T1666detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for security events/incidents, which would surface anomalous hierarchy modifications (e.g. CreateAccount, LeaveOrganization, subscription transfers) as incidents once they occur, but only within the scope of events the organization has instrumented and prioritized.
T1666responds — A.5.24 explicitly builds and exercises an incident response process (assess, respond to, contain, eradicate, escalate, recover, learn) that activates once an incident is declared, directly addressing T1666 once the hierarchy modification has occurred and is underway.
T1667detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including via human or automatic means), which surfaces email bombing as an anomalous flood of messages or events.
T1667prevents — A.5.24 requires establishing incident management processes, detection/monitoring, classification, response/escalation, and coordination that can identify and contain an email bombing flood once underway, thereby preventing the full intended impact (buried alerts, disrupted operations, follow-on social engineering) in many scenarios, but does not stop the adversary technique itself from executing or the initial messages from arriving.
T1667recovers — A.5.24 explicitly requires procedures for controlled recovery from an incident, activation of continuity plans, root-cause analysis, lessons learned, and restoration of normal operations after an email-bombing DoS event buries legitimate mail.
T1667responds — A.5.24 explicitly builds and activates an incident response process (assessing, responding to, containing, escalating, coordinating, recovering from, and learning from incidents) that directly addresses an email-bombing event once underway, including triage, classification, communication, evidence handling, and post-incident improvements.
T1669detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means), which surfaces Wi-Fi connection attempts or anomalies as events when they occur within the organization's monitored scope.
T1669responds — A.5.24 explicitly builds and exercises an incident response process (assess, respond to, contain, eradicate, escalate, recover, learn) that activates once a Wi-Fi-based initial-access incident is underway, with only the pre-detection slice outside its scope
T1671detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for information security events and incidents, which surfaces the technique once it has created or leveraged a malicious OAuth integration (e.g. anomalous consent, persistent token use, or exfiltration), but the control's scope is set by organizational priorities and does not mandate coverage of every possible SaaS integration signal.
T1671responds — A.5.24 explicitly builds and exercises the incident response process (assessing, responding to, learning from incidents; escalation per 5.26; coordination; root-cause and lessons-learned) once an OAuth-integration persistence event is underway, exactly matching the `responds` verb.
T1673detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including by human or automatic means), which surfaces VM enumeration when treated as an event; the remainder is that the clause sets scope by organizational priorities rather than mandating universal instrumentation of every hypervisor CLI/GUI query.
T1673responds — A.5.24 explicitly builds and exercises incident response processes that contain, eradicate, escalate, coordinate, recover and learn from security events once underway, which directly matches the `responds` verb when the VM discovery technique has already executed as part of a larger attack (e.g. preceding Service Stop or Data Encrypted for Impact).
T1674detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by automatic means), which surfaces the T1674 technique when it manifests as a detectable event.
T1674responds — A.5.24 explicitly builds and activates an incident response process that assesses, contains, escalates, coordinates, recovers from, and learns from security incidents (including those launched via input injection), once the technique is already underway.
T1675detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for information security events and incidents, which surfaces T1675 when it triggers observable events on the ESXi/guest environment; partial because detection scope is set by the organization's chosen criteria, procedures, and tooling rather than mandating coverage of this specific technique.
T1675responds — A.5.24 explicitly builds and exercises the incident response process (assessing, responding to, containing, eradicating, escalating, coordinating, recovering, and learning from incidents), which directly matches the `responds` verb once an adversary has begun abusing ESXi administration services to run guest commands.
T1677detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, root-cause analysis and post-mortem of information security events and incidents (including those that could arise from poisoned pipelines), but the control is scoped to events that meet the organisation’s own criteria and does not mandate instrumentation that would catch every variant of pipeline poisoning (especially public/PR-based or self-hosted-runner scenarios).
T1677responds — A.5.24 explicitly builds and exercises an incident response process (assess/respond/learn, escalation, containment via crisis/continuity activation, root-cause, lessons learned) that activates once a poisoned-pipeline event is underway, matching the `responds` verb; the named remainder is that some early-execution scenarios (e.g. self-hosted runner takeover) may already achieve lateral movement or credential exfil before response begins.
T1678detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, logging and reporting of information security events and incidents (including via human or automatic means), which surfaces time-based delay techniques when they trigger observable events, but the control's scope is limited to those that meet incident-evaluation criteria and does not guarantee coverage of all stealthy or sandbox-only delay behaviors.
T1678responds — A.5.24 explicitly builds and activates an incident response process (assessing, responding to, escalating, containing, recovering from, and learning from incidents) that activates once a time-based delay technique is recognized as part of an incident, directly matching the `responds` verb.
T1679detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause/post-mortem of incidents (including ransomware scenarios), which surfaces the selective-exclusion behavior once it produces observable events or artifacts; it does not guarantee detection of every stealthy implementation.
T1680detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (by human or automatic means) as part of the incident management plan, which surfaces the reconnaissance technique when it occurs.
T1680responds — A.5.24 explicitly builds and exercises an incident response process that contains, eradicates, escalates, coordinates, and learns from incidents once they are underway, which directly matches the `responds` verb for a discovery technique that has already executed.
T1681detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including coordination with external parties such as threat intelligence sources), which surfaces adversary reconnaissance on their own reported activity as an incident, but only for events that cross the organization's detection thresholds or external reporting channels rather than all such PRE activity.
T1682detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by automatic means) as part of the incident management plan, which surfaces adversary use of public AI services when it manifests as observable events; this is a genuine but bounded slice given the technique's pre-compromise, external, and often low-and-slow reconnaissance nature that may not trigger internal detection mechanisms.
T1683detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including those tied to social engineering, phishing, or influence operations that leverage generated content), but this surfaces the downstream use of the content rather than the prior PRE technique of content generation itself.
T1683responds — A.5.24 explicitly builds and exercises an incident response process (assess, respond to, contain, eradicate, escalate, recover, learn) that activates once an incident is underway, directly addressing T1683-generated content when it is leveraged in phishing, social engineering or influence operations.
T1683.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including those arising from written-content lures used in phishing/social-engineering), but this is scoped to events that have already reached the organization and does not surface the pre-attack creation/tailoring activity itself on PRE platforms.
T1683.001responds — A.5.24 explicitly builds and activates incident response processes that contain, eradicate, escalate, communicate on, and learn from realized security incidents (including those launched via crafted written content such as phishing lures or social-engineering artifacts), satisfying the `responds` verb once the technique has run; the remainder is that some pre-attack written-content scenarios may stay below the incident threshold.
T1683.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including those from human or automatic means), which surfaces adversary use of synthetic audio-visual content when it triggers an event, but only for incidents that meet the organization's defined criteria and detection scope.
T1683.002responds — A.5.24 explicitly builds and activates an incident response process that assesses, contains, eradicates, escalates, coordinates, and learns from realized security incidents (including those using fabricated A/V content in phishing, social engineering, or impersonation), with the named remainder being pre-impact detection or purely preventive blocks on content generation itself.
T1684detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including those from social engineering), with procedures for evaluation, triage, root-cause analysis and evidence handling that surface the technique once it has produced an observable event.
T1684prevents — planning, training, procedures, and competent personnel for incident management and response reduce the success rate and impact of social engineering by enabling faster detection, triage, user reporting, and coordinated handling, but do not stop the technique from being executed against users
T1684responds — A.5.24 explicitly builds and activates incident response processes (assessing, responding to, escalating, containing, recovering from, and learning from declared incidents), which directly matches the `responds` verb once a social-engineering technique has produced an incident.
T1684.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including those from social engineering/impersonation via phishing or BEC), with procedures, logging, and competent personnel to surface them.
T1684.001prevents — planning, procedures, training, detection, response, and reporting for incidents (including social engineering and impersonation via phishing/spearphishing) reduce the likelihood the technique runs to completion, but do not stop the initial impersonation message from being sent or the target from being deceived
T1684.001responds — A.5.24 explicitly builds and activates an incident response process (assessing, responding to, containing, eradicating, escalating, and learning from incidents) that directly acts on impersonation once it is underway as a realized information security incident
T1684.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including via human or automatic means) as core to the incident management plan, which surfaces email spoofing as an event once it reaches the organization.
T1684.002responds — A.5.24 explicitly builds and exercises an incident response process (assess, respond to, learn from incidents; escalation per 5.26; coordination; root-cause and lessons-learned) that activates once a spoofed email has been delivered and is recognized as an event/incident, exactly matching the `responds` verb.
T1685detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause/post-mortem of incidents (including those that impair defensive tools), which surfaces T1685 once it runs.
T1685prevents — planning, procedures, training, detection, response, recovery, and logging requirements in A.5.24 constrain the success and impact of T1685 (including on logging/telemetry) once an event is recognized, but do not stop the adversary technique from being executed against tools and sensors in the first place
T1685responds — A.5.24 explicitly builds and exercises incident response processes (assessing, responding to, containing, eradicating, escalating, coordinating, recovering, and learning from incidents), which directly matches the `responds` verb once an adversary has begun disabling or modifying defensive tools.
T1685.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging and root-cause activities for security events and incidents, which surfaces the T1685.001 technique (or its effects) once it runs.
T1685.001responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, learning from incidents; escalation, coordination, controlled recovery, root-cause, lessons learned) that activates once an adversary technique like disabling the Event Log is already underway, containing/eradication impact per the event-lane definition of responds.
T1685.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including via human or automatic means), which surfaces the disabling/modification of cloud logging as a detectable event, but the control's scope is set by organizational priorities and does not mandate instrumentation that would catch every stealthy or preemptive tampering technique on every platform.
T1685.002prevents — A.5.24 requires establishing incident management processes, detection/monitoring capabilities, classification, response/escalation, and learning/improvements that can stop or deter the logging-disable technique from fully succeeding in avoiding detection in many scenarios, but does not mandate or enforce the underlying logging mechanisms themselves.
T1685.002responds — A.5.24 explicitly builds and exercises an incident response process (assess, respond to, contain, eradicate, escalate, recover, learn) that activates once an incident is declared, directly addressing T1685.002 once the logging modification has occurred and is underway.
T1685.003detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including by automatic means) as part of the incident management process, which surfaces the spoofed-UI technique once it produces observable anomalous signals, but the control's scope is limited to events that meet defined incident criteria and does not guarantee detection of all stealthy UI manipulations.
T1685.003prevents — planning, procedures, training, detection, monitoring, classification, response/escalation and post-incident learning directly equip the organization to catch falsified UIs faster and limit the delay they cause, but do not stop the adversary from executing the spoof in the first place
T1685.003responds — A.5.24 explicitly builds and exercises the incident response process (assessing, responding to, learning from incidents; escalation per 5.26; coordination; root-cause and lessons-learned) that activates once the spoofed-UI technique is already running and has impaired visibility, thereby containing/eradication the actor's foothold even though the initial concealment succeeded.
T1685.005detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging and root-cause/post-mortem of incidents (including via human or automatic means), which surfaces the T1685.005 clearing action once it occurs.
T1685.005recovers — A.5.24 explicitly requires procedures for controlled recovery from an incident, activation of continuity plans, root cause analysis, lessons learned, and improvements that restore logging capability and evidence after T1685.005 has erased Windows Event Logs.
T1685.005responds — A.5.24 explicitly builds and exercises an incident response process that includes detection/classification of events, managing incidents to conclusion with response/escalation, root-cause analysis, and coordination, which directly acts on a realized log-clearing technique (T1685.005) once underway to contain, eradicate, and learn from it.
T1685.006detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause/post-mortem of incidents (including those that delete evidence), which surfaces the log-clearing technique when it triggers an evaluable event, but only within the scope of the defined incident management process and detection mechanisms (see 8.16).
T1685.006responds — A.5.24 explicitly builds and activates an incident response process that includes managing incidents to conclusion, response/escalation, root-cause analysis, evidence handling and controlled recovery once an event is recognised as an incident, directly addressing the post-intrusion log-clearing technique while it is underway.
T1686responds — A.5.24 explicitly builds and activates an incident response process (assessing, responding to, escalating, coordinating, recovering from, and learning from incidents), which directly matches the `responds` verb once T1686 has run and impaired defenses.
T1686detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for security events/incidents (including those that could involve firewall tampering), but the clause sets scope by organisational priorities rather than mandating universal coverage of every T1686 variant across all platforms.
T1686.001detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for security events and incidents (including those that could involve cloud firewall changes), but the control is scoped to incident management processes rather than mandating specific detection mechanisms for this technique.
T1686.001responds — A.5.24 explicitly builds and activates an incident response process (including assessment, response/escalation per 5.26, coordination, controlled recovery, and learning) that acts on an already-underway incident such as firewall modification to contain it, eradicate the actor's changes/foothold, and bound further spread.
T1686.002detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause/post-mortem of incidents (including those from firewall rule changes on network devices), providing broad detection coverage once the technique has produced an observable event.
T1686.002responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, escalating, coordinating, recovering from, and learning from incidents), which directly matches the act of responding once the firewall-disable technique is already underway.
T1686.003detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause activities for security events and incidents, which surfaces firewall tampering when it triggers an observable event, but the clause sets scope by organisational priorities rather than mandating universal instrumentation of every registry, netsh, or Control Panel change.
T1686.003responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, escalating, coordinating, recovering from, and learning from incidents), which directly matches the `responds` verb once the firewall-disable technique is underway.
T1687detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of information security events and incidents (including those that impair defenses), with logging, root-cause analysis and post-mortem procedures that surface the exploitation technique once it has run.
T1687prevents — planning, procedures, competent trained personnel, detection/classification/response processes, and post-incident root-cause/lessons-learned directly enable orderly detection and response even after defensive tools are impaired, preventing the full technique success of continued unimpeded malicious activity
T1687responds — A.5.24 explicitly builds and exercises the incident response process (assessing, responding to, learning from incidents; escalation per 5.26; coordination; root-cause and lessons-learned) that activates once T1687 has begun impairing defenses, containing/eradication the actor's foothold and limiting further impairment.
T1688detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause/post-mortem of incidents (including those from safe-mode abuse that disable EDR), but this is scoped to the incident-management process after the technique has already run and produced observable effects rather than broad real-time detection of the BCD/registry/COM abuse itself.
T1688responds — A.5.24 explicitly builds and exercises an incident response process (assessing, responding to, containing, eradicating, learning from, and coordinating on incidents), which directly matches the `responds` verb once an adversary has forced safe-mode boot to disable defenses; the named remainder is that the control does not itself perform on-host containment/eradication steps.
T1689detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, logging, and root-cause/post-mortem of incidents (including those that impair defenses via downgrade), but this is scoped to events already classified as incidents rather than reliably surfacing the downgrade technique itself in all cases.
T1689responds — A.5.24 explicitly builds and exercises an incident response process (assess, respond to, learn from incidents; manage to conclusion with escalation, recovery, root-cause, lessons learned) that activates once a downgrade attack is recognized as an information security incident.
T1690detects — A.5.24 explicitly requires monitoring, detecting, classifying, analysing, reporting, and logging of information security events and incidents (including via human or automatic means), which surfaces the T1690 technique when it manifests as a detectable event or anomaly, but the control's scope is limited to events that meet the organization's incident criteria rather than guaranteeing detection of every possible instance of history manipulation.
T1690responds — A.5.24 explicitly builds and activates an incident response process that includes detection, triage, analysis, response/escalation, coordination, evidence handling, root-cause, lessons learned and controlled recovery once an incident is underway, which matches the `responds` verb for an adversary technique already executed on a compromised system.

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

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).

A06←P A07←P A08←P A09→P

Why these map — AI rationale (under review)

A09finds — A.5.24 explicitly requires monitoring, detecting, classifying, analysing and reporting of security events/incidents (by human or automatic means) plus root-cause and post-mortem procedures, which directly surfaces logging/alerting failures that allow incidents to go undetected.
A09mitigates — A.5.24's incident management processes (detection, triage, analysis, logging of events, escalation, root-cause) bound the realized consequences of undetected incidents by enabling faster response and recovery, but do not reduce the logging/alerting failure itself.

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.