Cyber Resilience

← ISO 27001 Annex A

A.8.27 Technological

Secure system architecture and engineering principles

AttributesPreventive C·I·A Protect Application security System and network security Protection

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 (24)

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

AC-10←P AC-6←P CM-7←P SA-4←M SC-24←P SC-3←P SC-7→P PL-8gov SA-17gov SA-3gov SA-8gov

Why these map — AI rationale (under review)

PL-8mostlyaligns with — Both controls require a documented security architecture that integrates controls across business, data, application, and technology layers to meet identified threats.
SC-2mostlyaligns with — The ISO control explicitly calls for separation of system and user functionality through principles such as least privilege and least functionality, matching SC-2's objective.
AC-6partialaligns with — A.8.27 requires least-privilege and dynamic access control techniques as core engineering principles, satisfying the same objective as AC-6.
CM-7partialaligns with — The ISO control lists least functionality among its mandated secure-engineering principles, directly supporting CM-7's goal of restricting systems to only essential capabilities.
SA-17partialaligns with — A.8.27 requires security-oriented design reviews and formal documentation of security controls, aligning with SA-17's focus on developer security architecture and design.
SC-7partialaligns with — Zero-trust guidance in A.8.27, including never-trust-always-verify and end-to-end encryption, aligns with SC-7's boundary-protection and information-flow objectives without replacing perimeter controls.
SA-8noneimplements — ISO A.8.27 mandates the establishment and application of security engineering principles across all architecture layers, directly encompassing the intent of SA-8 to embed security and privacy principles into system design and development.
AC-6covers — 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.
CM-7covers — 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.
PL-8implements — PL-8 is the technical control that directly operationalizes the secure architecture and engineering principles required by A.8.27 within the system development life cycle.
SA-17implements — A.8.27 directly requires secure architecture and engineering principles throughout the development life cycle, which sa-17 operationally enacts by mandating developer-produced security/privacy architecture and design specifications consistent with the organization's enterprise architecture.
SC-2covers — Assessed as NOT holding by the authoring instrument at v1.22-2026-08-29. This row records a tested non-relation; it is not a graded claim and carries no rationale, because the instrument produced none when the verb did not hold.

Aligned NIST CSF 2.0 outcomes (19)

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

GV.SC-05gov ID.AM-08gov ID.RA-05gov PR.AA-05gov PR.IR-01gov PR.PS-01gov PR.PS-06gov

Why these map — AI rationale (under review)

PR.AA-05mostlyaligns with — By requiring dynamic access control, contextual authorization, and least-privilege enforcement within system design, the control satisfies the CSF outcome of defining, managing, and enforcing access permissions and entitlements.
PR.IR-01mostlycovers — The control's emphasis on embedding security architecture principles such as defense-in-depth, least privilege, and zero-trust directly produces the outcome of protecting networks and environments from unauthorized logical access.
PR.PS-01mostlyaligns with — Mandating security-oriented design reviews, hardening, and formal documentation of controls that do not fully meet requirements aligns with establishing and applying configuration-management practices.
GV.SC-05partialaligns with — Extending the same security-engineering principles to suppliers via binding agreements aligns with establishing and integrating cybersecurity requirements into supplier contracts.
ID.RA-05partialaligns with — Analyzing the full range of required controls against identified threats and attack patterns supports the CSF outcome of using threats, vulnerabilities, likelihoods, and impacts to understand inherent risk and prioritize responses.
PR.PS-06partialaligns with — Requiring that secure engineering principles be applied to outsourced development through contracts integrates secure software-development practices into the system life cycle.
GV.SC-05implements — 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.RA-05implements — 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.
PR.AA-05implements — 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.
PR.PS-01implements — Assessed as NOT holding by the authoring instrument at v1.22-2026-08-29. This row records a tested non-relation; it is not a graded claim and carries no rationale, because the instrument produced none when the verb did not hold.
PR.PS-06implements — A.8.27 operationalizes secure design/engineering principles across the development life cycle, which directly gives effect to integrating and monitoring secure software development practices within PR.PS-06's domain (same-layer technical pair treated as implements per lane-B rule).

Related OWASP ASVS 5.0 requirements (15)

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

V1.2.4←P V1.3.6→P V13.2.4→P V15.2.3←P →P V16.5.3←P V2.2.1←M V2.2.2→P V6.3.3←M →P V7.2.1←P V8.2.1←M V8.2.4→M V8.3.1←M →M

Why these map — AI rationale (under review)

V8.2.4mostlycovers — Requiring dynamic access control based on contextual attributes such as user identity, device posture and data classification satisfies the ASVS expectation that authorization adapt to environmental and contextual factors.
V8.3.1mostlycovers — The ISO control's mandate to enforce authorization at a trusted service layer and integrate controls into the security architecture directly implements the ASVS requirement that authorization decisions must not rely on untrusted client-side enforcement.
V1.3.6partialaligns with — The principle of distrusting input from external applications and verifying every request maps to the ASVS control that protects against server-side request forgery by validating untrusted data against an allow-list.
V13.2.4partialaligns with — The ISO directive to maintain an allow-list of permitted external resources and systems corresponds to the ASVS requirement that outbound connections be restricted to an explicitly approved set of destinations.
V15.2.3partialaligns with — The ISO principle of least functionality, which removes unnecessary features and hardens systems, aligns with the ASVS requirement that production deployments contain only the minimal functionality needed for operation.
V2.2.2partialaligns with — The ISO guidance to distrust external input and perform validation at a trusted service layer aligns with the ASVS requirement that input validation be enforced server-side rather than solely on the client.
V6.3.3partialaligns with — The ISO requirement for strong authentication and multi-factor verification for every access request aligns with the ASVS mandate that multi-factor or equivalent-strength controls be used for sensitive operations.

Related weaknesses / CWE (737)

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-1007←P →P CWE-1021←P →P CWE-1022←P →P CWE-1023←P →P CWE-1024←P CWE-1037←P CWE-1038←P →P CWE-1039←P →P CWE-1049←P →P CWE-1051→P CWE-1055←P →P CWE-1057→P CWE-1058←P →P CWE-1059←P →M CWE-1066←P →P CWE-1067←P →P CWE-1068→P CWE-1072→P CWE-1076←P →M CWE-1083←P →M CWE-1088←P →P CWE-1091←P →P CWE-1100←P →M CWE-1102←P CWE-1103←P →P CWE-1106→P CWE-1107←P →P CWE-1108←P →P CWE-111←P →P CWE-112→P CWE-1124←P CWE-1125←P →M CWE-113→P CWE-114←P →P CWE-115←P →P CWE-116→P CWE-1173→P CWE-1176←P CWE-118←P →P CWE-1189←P →M CWE-119←P →P CWE-1190←P →M CWE-1191←P →P CWE-120←P →P CWE-121←P →P CWE-122←P →P CWE-1221←P →P CWE-1222←P →P CWE-1223←P →M CWE-1224←P →P CWE-123←P →P CWE-1231←P →P CWE-1233←P →P CWE-1234←P →P CWE-1236→P CWE-124←P →P CWE-1240←P →P CWE-1241→P CWE-1242←P →P CWE-1244←P →P CWE-1245←P →P CWE-1246←P →P CWE-1247←P →P CWE-125←P →P CWE-1250←P →M CWE-1251←P →P CWE-1253←P →P CWE-1254←P →P CWE-1255←P →P CWE-1256←P →P CWE-1257←P →M CWE-1258←P →P CWE-1259→P CWE-126←P →P CWE-1260←P →P CWE-1262→P CWE-1264←P →P CWE-1265←P →P CWE-127←P →P CWE-1274←P →P CWE-1278←P →P CWE-1279←P →P CWE-128←P →P CWE-1280→P CWE-1281←P →P CWE-1282←P →P CWE-1283←P →P CWE-1284→P CWE-1285←P →P CWE-1286→P CWE-1287←P →P CWE-1288→P CWE-1289←P →P CWE-129→P CWE-1298←P →P CWE-1299←P →M CWE-130←P →P CWE-1300→P CWE-1303←P →P CWE-131←P →P CWE-1310→P CWE-1312←P →P CWE-1313←P →P CWE-1314←P →M CWE-1316←P →M CWE-1319→P CWE-1320←P →P CWE-1321→P CWE-1322←P →P CWE-1323←P →P CWE-1325→P CWE-1326←P →P CWE-1327←P →M CWE-1328→P CWE-1332←P →P CWE-1333→P CWE-1334→P CWE-1335←P CWE-1336→P CWE-134←P →P CWE-1341←P CWE-1342→P CWE-135←P →P CWE-138→P CWE-1385←P →P CWE-1386←P →P CWE-141→P CWE-142←P →P CWE-143→P CWE-144→P CWE-145→P CWE-146→P CWE-147→P CWE-148←P →P CWE-149→P CWE-150→P CWE-154→P CWE-155→P CWE-156→P CWE-157→P CWE-158→P CWE-159→P CWE-160→P CWE-162→P CWE-164→P CWE-166→P CWE-167←P →P CWE-168→P CWE-170←P CWE-172←P →P CWE-173←P →P CWE-176←P →P CWE-178←P →P CWE-179→P CWE-180→P CWE-182←P →P CWE-183←P →P CWE-184←P →P CWE-187←P CWE-188←P →P CWE-190←P CWE-191←P →P CWE-192←P →P CWE-193←P →P CWE-194→P CWE-195←P →P CWE-196←P →P CWE-197←P CWE-198←P →P CWE-20→P CWE-200→P CWE-204←P →P CWE-205←P →P CWE-207→P CWE-209→P CWE-210→P CWE-219←P →M CWE-22←P →P CWE-228→P CWE-229→P CWE-23←P →P CWE-231→P CWE-232←P →P CWE-234←P CWE-237←P →P CWE-24→P CWE-240←P →P CWE-241→P CWE-248←P →P CWE-25→P CWE-252←P CWE-253←P →P CWE-26→P CWE-267→P CWE-269→P CWE-27→P CWE-270←P →P CWE-277←P →P CWE-28←P →P CWE-284→P CWE-287→P CWE-288→P CWE-29←P →P CWE-290←P →P CWE-297←P →P CWE-30→P CWE-301→P CWE-306→P CWE-31→P CWE-32→P CWE-322→P CWE-329→P CWE-332→P CWE-333→P CWE-337→P CWE-338→P CWE-34→P CWE-342→P CWE-343→P CWE-344→P CWE-346→P CWE-348→M CWE-349←P →P CWE-35←P →P CWE-350←P →P CWE-351←P →P CWE-353←P →P CWE-356→P CWE-357←P →P CWE-358←P →P CWE-36←P →P CWE-360←P →P CWE-362←P →P CWE-363←P →P CWE-364←P CWE-366←P →P CWE-368←P →P CWE-369←P →P CWE-37←P →P CWE-372←P →P CWE-374←P →P CWE-377→P CWE-378←P →P CWE-379←P →P CWE-38→P CWE-385→P CWE-386←P →P CWE-39←P →P CWE-391←P CWE-40←P →P CWE-401←P →P CWE-407←P →P CWE-409→P CWE-41←P →P CWE-410→P CWE-412→P CWE-413←P →P CWE-415→P CWE-416←P →P CWE-419←P →P CWE-42←P →P CWE-421←P →P CWE-422←P →P CWE-424←P →P CWE-426←P →P CWE-427←P →P CWE-428←P CWE-43←P →P CWE-430←P →P CWE-431←P →P CWE-433→P CWE-435←P →M CWE-436←P →P CWE-437←P →P CWE-44←P →P CWE-441←P →P CWE-444←P →P CWE-446→P CWE-450←P →P CWE-453←P →P CWE-454←P →P CWE-455←P →P CWE-456←P CWE-46←P →P CWE-460←P →P CWE-462←P CWE-466←P CWE-469←P CWE-470←P →P CWE-471→P CWE-474←P CWE-475←P →P CWE-476←P →P CWE-479←P CWE-488←P →P CWE-491←P →P CWE-495←P →P CWE-499←P →P CWE-50←P →P CWE-501←P →M CWE-514←P →P CWE-515←P →P CWE-523→P CWE-526←P →P CWE-535→P CWE-544←P →P CWE-548←P →P CWE-550←P →P CWE-551←P →P CWE-553→P CWE-556→P CWE-562←P CWE-564→P CWE-566→P CWE-567←P →P CWE-57→P CWE-573←P →P CWE-587←P →P CWE-588←P →P CWE-59←P →P CWE-590→P CWE-598→P CWE-600←P →P CWE-602→M CWE-603←P →M CWE-605←P →P CWE-61←P →P CWE-610←P →P CWE-611→P CWE-616→P CWE-617←P →P CWE-618←P →P CWE-62←P →P CWE-621→P CWE-622←P →P CWE-623→P CWE-624←P CWE-626←P →P CWE-627←P →P CWE-637←P →M CWE-641→P CWE-642→M CWE-643→P CWE-644→P CWE-646←P →P CWE-648←P →P CWE-649←P →P CWE-65←P →P CWE-650←P →P CWE-652→P CWE-653←P →M CWE-656←P →M CWE-657←F →F CWE-66←P →P CWE-662←P →P CWE-663←P →P CWE-664→P CWE-665←P →P CWE-667←P →P CWE-669←P →P CWE-67→P CWE-674→P CWE-675←P →P CWE-680←P →P CWE-681←P →P CWE-682←P CWE-686←P CWE-687←P →P CWE-689←P →P CWE-690←P →P CWE-691←P →P CWE-695←P →P CWE-696←P →P CWE-697←P →P CWE-698←P →P CWE-704←P CWE-706←P →P CWE-707←P →P CWE-73→P CWE-732→P CWE-74→P CWE-749←P →P CWE-75→P CWE-754←P →P CWE-755←P →P CWE-757→P CWE-758←P CWE-76←P →P CWE-760→P CWE-762←P CWE-763←P →P CWE-764←P →P CWE-765←P →P CWE-767←P →P CWE-768←P CWE-77→P CWE-771←P →P CWE-774←P →P CWE-776→P CWE-780→P CWE-782→P CWE-786←P →P CWE-787←P →P CWE-788←P →P CWE-789←P →P CWE-790←P →P CWE-791←P →P CWE-792→P CWE-794→P CWE-799→P CWE-805←P →P CWE-807←P →P CWE-81→P CWE-82←P →P CWE-820←P →P CWE-821←P →P CWE-822←P →P CWE-823←P CWE-824←P CWE-825→P CWE-826←P →P CWE-827←P →P CWE-828←P CWE-83→P CWE-830←P →M CWE-832←P →P CWE-833←P →P CWE-834←P →P CWE-839←P →P CWE-841←P →P CWE-843←P →P CWE-862→P CWE-87→P CWE-88←P →P CWE-908←P →P CWE-909→P CWE-91→P CWE-910←P CWE-911←P →P CWE-912←P →P CWE-913←P →P CWE-914←P →P CWE-915←P →P CWE-917→P CWE-923→P CWE-925←P →P CWE-926→P CWE-927←P →P CWE-93→P CWE-941→P CWE-942←P →P CWE-943→P CWE-95→P CWE-96→P CWE-97→P CWE-98→P CWE-99→P

Why these map — AI rationale (under review)

CWE-187nonemitigates — Secure system architecture principles discourage unsafe partial comparisons in critical paths.
CWE-235nonemitigates — Secure architecture principles encourage robust input handling but do not specifically address parameter-count validation.
CWE-336noneprevents — Secure architecture principles include use of strong randomness, but do not specifically prescribe PRNG seeding.
CWE-391noneprevents — Secure architecture principles mandate robust exception and error management.
CWE-474nonemitigates — Secure architecture principles include portable abstractions and avoiding platform-specific calls with divergent behavior.
CWE-90nonemitigates — Secure architecture principles encourage safe query interfaces but do not prescribe the specific coding controls needed for LDAP injection.
CWE-920nonemitigates — Secure architecture principles may include power-aware design, but the control is not focused on power limits.
CWE-1007prevents — Secure architecture principles can include user-interface protections that reduce visual ambiguity.
CWE-1021prevents — Secure architecture principles include isolation of UI layers and proper use of browser security controls.
CWE-1022prevents — Secure architecture principles include isolation of untrusted content and safe navigation patterns that mitigate opener-based attacks.
CWE-1023prevents — Secure architecture principles can require exhaustive entity comparisons, yet the control addresses many other design concerns.
CWE-1038prevents — Secure architecture and engineering principles require explicit validation that automated optimizations preserve security assumptions.
CWE-1039prevents — Secure architecture principles include resilience against input manipulation and adversarial ML attacks.
CWE-1049prevents — Secure architecture principles include database design and indexing standards that mitigate large-table query risks.
CWE-1051prevents — Secure system architecture principles discourage embedding network identifiers in code, but the control is broader.
CWE-1055prevents — Secure system architecture principles discourage complex inheritance that leads to fragile designs.
CWE-1057prevents — Secure architecture principles require all data operations to flow through the designated manager component.
CWE-1058prevents — Secure architecture principles require proper concurrency controls and avoidance of shared mutable static data.
CWE-1059prevents — Secure architecture principles require documented engineering decisions and component descriptions.
CWE-1066prevents — Secure architecture principles mandate explicit serialization controls for serializable objects.
CWE-1067mitigates — Secure architecture principles include data-access efficiency and proper indexing strategies.
CWE-1068prevents — Secure architecture principles guide design but do not verify that code follows the documented design.
CWE-1072prevents — Secure system architecture principles may recommend efficient resource management including pooling, yet do not mandate it.
CWE-1076prevents — Architecture principles may include conventions but are not the primary enforcement mechanism.
CWE-1083prevents — Secure system architecture principles require centralized data access mediation, mitigating the architectural flaw described by CWE-1083.
CWE-1088prevents — Secure architecture principles encourage defensive coding patterns such as timeouts, but do not prescribe them explicitly.
CWE-1091prevents — Secure architecture principles include lifecycle management and resource-release mechanisms.
CWE-1100prevents — Secure system architecture and engineering principles explicitly require modular isolation of system-dependent functions.
CWE-1103mitigates — Secure architecture principles can require abstraction layers or portable component selection.
CWE-1106prevents — Secure architecture principles promote maintainable code that favors named constants.
CWE-1107prevents — Secure system architecture and engineering principles promote modular, centralized constant handling to improve maintainability.
CWE-1108prevents — Secure architecture principles promote limited scope and explicit interfaces over global variables.
CWE-111prevents — Secure architecture principles discourage direct unsafe JNI and favor safer integration patterns.
CWE-112prevents — Secure architecture principles encourage defensive input handling but do not prescribe XML schema validation.
CWE-1125prevents — Secure architecture principles explicitly call for minimizing the attack surface through least functionality.
CWE-113prevents — Secure architecture principles reduce the likelihood of header-splitting vulnerabilities through proper component isolation.
CWE-114prevents — Secure architecture principles discourage reliance on untrusted external processes or libraries.
CWE-115prevents — Secure architecture principles include defensive input processing and error handling that reduce misinterpretation risks.
CWE-116prevents — Secure architecture principles reduce the likelihood of missing encoding but do not prescribe the actual technique.
CWE-1173prevents — Secure architecture principles encourage validated input handling but do not prescribe frameworks.
CWE-118prevents — Secure architecture principles promote defensive coding that limits out-of-bounds access.
CWE-1189prevents — Secure system architecture and engineering principles directly require hardware-level isolation of shared SoC resources.
CWE-119prevents — Secure architecture and engineering principles include memory-safe design patterns that mitigate buffer overflows.
CWE-1190prevents — Secure system architecture principles require DMA devices to be enabled only after security settings are active.
CWE-1191prevents — Secure architecture principles include hardware access-control mechanisms for debug and test interfaces.
CWE-120prevents — Secure system architecture and engineering principles promote defensive coding patterns that reduce the likelihood of unchecked buffer copies.
CWE-121prevents — Secure architecture principles include memory-safety and least-privilege stack usage.
CWE-122prevents — Secure architecture and engineering principles include memory-safety and input-validation controls that address heap overflows.
CWE-1221prevents — Secure system architecture and engineering principles guide the selection of safe register defaults and module parameters.
CWE-1222prevents — Secure architecture principles require appropriate granularity of protection mechanisms, directly addressing the register-lock design flaw.
CWE-1223prevents — Secure system architecture and engineering principles can mandate hardware access ordering and initialization sequencing to prevent race conditions.
CWE-1224prevents — Secure system architecture and engineering principles directly address hardware register design correctness.
CWE-123prevents — Secure architecture and engineering principles discourage unsafe memory handling that leads to write-what-where vulnerabilities.
CWE-1231prevents — Secure system architecture principles can mandate one-time lock-bit setting, but the control does not enforce hardware-level protection.
CWE-1233prevents — Secure system architecture principles require hardware lock-bit protection for critical configuration registers.
CWE-1234prevents — Secure system architecture and engineering principles can mandate hardware lock enforcement during debug, covering most of the weakness.
CWE-1236prevents — Secure architecture principles encourage safe data export design but do not specifically address CSV formula neutralization.
CWE-124prevents — Secure architecture and engineering principles require safe memory-handling patterns.
CWE-1240prevents — Secure architecture principles include selection of proven cryptographic components and avoidance of custom risky implementations.
CWE-1241prevents — Secure engineering principles include selection of cryptographically strong random number generators.
CWE-1242prevents — Secure system architecture and engineering principles mandate documented, minimal, and auditable designs, limiting chicken bits.
CWE-1244prevents — Secure system architecture principles can require proper debug port isolation, yet the control is broader than this specific weakness.
CWE-1245prevents — Secure system architecture and engineering principles directly address proper FSM design and state validation.
CWE-1246prevents — Secure system architecture and engineering principles include selecting and configuring storage technologies to avoid premature wear-out.
CWE-1247prevents — Secure system architecture and engineering principles can mandate glitch-detection circuitry and fault-injection countermeasures.
CWE-125prevents — Secure system architecture and engineering principles require memory-safe design patterns and runtime protections against out-of-bounds access.
CWE-1250prevents — Secure architecture principles can address distributed-state design yet leave the actual consistency mechanisms unspecified.
CWE-1251prevents — Secure architecture principles require consistent state across replicated components, directly addressing mirrored-region integrity.
CWE-1253prevents — Secure system architecture and engineering principles require hardware fuses to be selected and blown so that the secure state is the default.
CWE-1254prevents — Secure system architecture principles can mandate constant-time primitives to eliminate timing side-channels.
CWE-1255mitigates — Secure architecture principles include hardware and software countermeasures against physical side-channel attacks.
CWE-1256prevents — Secure system architecture and engineering principles require hardware abstraction layers and access mediation that directly address improper exposure of hardware features.
CWE-1257prevents — Secure system architecture principles require consistent access-control enforcement across mirrored memory regions.
CWE-1258prevents — Secure system architecture and engineering principles directly address clearing of sensitive data on debug transitions.
CWE-1259prevents — Secure architecture principles can guide token protection mechanisms but do not enforce assignment rules.
CWE-126prevents — Secure architecture principles include memory-safety and bounds-checking design choices.
CWE-1260prevents — Secure system architecture and engineering principles require explicit memory-range separation and protection mechanisms that directly prevent overlapping protected regions.
CWE-1262prevents — Secure architecture principles require proper hardware register access controls by design.
CWE-1264prevents — Secure system architecture and engineering principles require proper sequencing of security checks before data forwarding in hardware logic.
CWE-1265prevents — Secure architecture principles such as thread-safety and state isolation help prevent unintended reentrant invocations.
CWE-127prevents — Secure architecture principles include memory-safety and bounds-checking mechanisms.
CWE-1274prevents — Secure system architecture principles include memory protection mechanisms that can mitigate this weakness.
CWE-1278prevents — Secure engineering principles can include anti-reverse-engineering measures such as obfuscation or tamper resistance.
CWE-1279prevents — Requires secure system architecture and engineering principles that would address readiness of cryptographic inputs.
CWE-128prevents — Secure architecture principles include use of safe data types and overflow detection mechanisms.
CWE-1280prevents — Promotes secure architecture that can embed early checks, but does not mandate them.
CWE-1281prevents — Secure system architecture and engineering principles can mandate hardware-abstraction layers and errata handling to prevent processor lock states.
CWE-1282prevents — Secure system architecture principles require hardware write-protection or one-time-programmable memory for immutable data.
CWE-1283prevents — Secure architecture principles require hardware-protected, immutable attestation registers.
CWE-1284prevents — Secure architecture principles encourage robust input handling but do not specifically address quantity validation.
CWE-1285prevents — Secure architecture principles include defensive input validation and bounds checking for indexable resources.
CWE-1286prevents — Secure architecture principles reduce the likelihood of missing syntactic checks.
CWE-1287prevents — Secure architecture principles promote defensive input handling and type enforcement at system boundaries.
CWE-1288prevents — Secure architecture principles encourage robust input handling but do not specifically mandate consistency validation.
CWE-1289prevents — Secure architecture principles include proper input validation and canonicalization to avoid unsafe equivalence.
CWE-129prevents — Secure architecture principles encourage defensive coding patterns that reduce index-related vulnerabilities.
CWE-1298prevents — Secure system architecture and engineering principles require timing analysis to avoid race conditions in hardware logic.
CWE-1299prevents — Secure system architecture and engineering principles require protection of all interfaces, directly addressing unguarded alternate hardware paths.
CWE-130prevents — Secure architecture principles require robust parsing and bounds checking to prevent length-related flaws.
CWE-1300mitigates — Secure engineering principles can mandate hardware or software side-channel protections.
CWE-1303mitigates — Secure system architecture principles can mandate hardware-level isolation of microarchitectural resources.
CWE-131prevents — Secure architecture principles include safe memory-allocation guidelines.
CWE-1310prevents — Secure architecture principles recommend patchable components, yet the control does not specifically require ROM update mechanisms.
CWE-1312prevents — Secure system architecture principles require complete address-space protection, directly addressing missing mirrored-region coverage.
CWE-1313prevents — Secure system architecture and engineering principles require disabling or locking debug/test logic in production hardware.
CWE-1314prevents — Secure system architecture and engineering principles require hardware-level write-protection for critical sensor parameters.
CWE-1316prevents — Secure system architecture and engineering principles directly require non-overlapping protected address ranges in fabric design.
CWE-1319prevents — Secure system architecture principles can include hardware-level countermeasures against EM-FI, though the control is not specific to this threat.
CWE-1320prevents — Secure architecture principles address integrity of error and alert mechanisms.
CWE-1321prevents — Secure architecture principles reduce the likelihood of prototype pollution through safe design patterns.
CWE-1322prevents — Secure system architecture principles include designing for non-blocking, scalable concurrency models.
CWE-1323prevents — Secure architecture principles require protected storage and transport paths for trace data.
CWE-1325prevents — Secure architecture principles can mandate bounded resource usage, but eliminating this CWE does not address broader architectural controls.
CWE-1326prevents — Secure system architecture and engineering principles require hardware roots of trust to prevent bypass of secure boot.
CWE-1327prevents — Secure architecture principles discourage exposing services on all interfaces, though the control is broader than this single weakness.
CWE-1328prevents — Secure architecture principles can mandate hardware-enforced version counters or fuses.
CWE-1332prevents — Secure system architecture and engineering principles can require hardware-level fault detection and instruction-integrity mechanisms.
CWE-1333prevents — Secure architecture principles encourage avoidance of computationally expensive constructs such as catastrophic backtracking.
CWE-1334prevents — Secure system architecture principles include designing redundancy so that single-point error injection is harder.
CWE-1336prevents — Secure architecture principles reduce the likelihood of unsafe template processing but do not prescribe specific neutralization techniques.
CWE-134prevents — Secure architecture principles discourage dangerous string-handling patterns that lead to format-string issues.
CWE-1342mitigates — Secure architecture principles include selecting processors or designs that reduce microarchitectural leakage.
CWE-135prevents — Secure system architecture and engineering principles can incorporate input validation and encoding-aware string handling to mitigate this weakness.
CWE-138prevents — Secure system architecture principles reduce attack surface but do not prescribe the specific neutralization techniques needed for CWE-138.
CWE-1385prevents — Secure architecture principles can require proper origin validation mechanisms in WebSocket implementations.
CWE-1386prevents — Secure system architecture principles include canonicalization and path-traversal defenses that mitigate junction attacks.
CWE-141prevents — Secure system architecture principles encourage safe interfaces but do not prescribe delimiter neutralization.
CWE-142prevents — Secure system architecture and engineering principles require defensive coding patterns that neutralize special characters.
CWE-143prevents — Secure architecture principles encourage safe data-flow design but do not prescribe delimiter neutralization.
CWE-144prevents — Secure architecture principles encourage safe data handling but do not specifically address line-delimiter neutralization.
CWE-145prevents — Secure system architecture principles reduce delimiter injection risk through proper component isolation.
CWE-146prevents — Secure architecture principles reduce attack surface but do not prescribe delimiter neutralization.
CWE-147prevents — Secure architecture principles encourage robust input handling but do not prescribe the specific neutralization technique.
CWE-148prevents — Secure system architecture principles address robust input parsing and neutralization of malformed leaders.
CWE-149prevents — Secure architecture principles reduce the attack surface but do not prescribe the specific quoting-neutralization technique.
CWE-150prevents — Secure architecture principles reduce attack surface but do not prescribe specific neutralization techniques.
CWE-154prevents — Secure architecture principles reduce the attack surface for delimiter injection but do not prescribe the actual neutralization technique.
CWE-155prevents — Secure architecture principles encourage safe handling of untrusted input but do not prescribe specific wildcard neutralization.
CWE-156prevents — Secure system architecture principles may indirectly support input handling but do not specifically address whitespace neutralization.
CWE-157prevents — Secure system architecture principles can guide design choices that reduce delimiter-related parsing risks.
CWE-158prevents — Secure architecture principles reduce the likelihood of unsafe data flows but do not prescribe character neutralization.
CWE-159prevents — Secure architecture principles reduce attack surface but do not prescribe specific input-filtering techniques.
CWE-160prevents — Secure architecture principles reduce injection vectors but do not prescribe specific neutralization techniques.
CWE-162prevents — Secure architecture principles may indirectly reduce such weaknesses but do not specifically address input neutralization.
CWE-164prevents — Secure system architecture principles reduce attack surface but do not specifically address neutralization of internal special elements.
CWE-166prevents — Secure architecture principles may indirectly reduce malformed-input risks but do not specifically address missing elements.
CWE-167prevents — Secure architecture principles include defensive input handling to prevent injection or parsing anomalies.
CWE-168prevents — Secure architecture principles encourage consistent data handling but do not directly address this weakness.
CWE-172prevents — Secure system architecture and engineering principles address data handling and transformation correctness.
CWE-173prevents — Secure architecture principles include input normalization and canonicalization controls that mitigate encoding-related weaknesses.
CWE-176prevents — Secure architecture principles require robust input processing to avoid encoding-related vulnerabilities.
CWE-178prevents — Architecture principles should enforce canonical, case-aware resource naming.
CWE-179prevents — Secure architecture principles discourage unsafe ordering of validation and sanitization steps.
CWE-180prevents — Secure architecture principles reduce the likelihood of ordering errors in input processing.
CWE-182prevents — Secure architecture principles require defensive design against data-reduction vulnerabilities.
CWE-183prevents — Secure system architecture and engineering principles require explicit, least-privilege input validation designs that directly address permissive allow-lists.
CWE-184prevents — Secure architecture principles include robust input validation design, yet the control is broader than this single weakness.
CWE-188prevents — Secure system architecture and engineering principles directly address assumptions about memory and protocol layout.
CWE-191prevents — Secure architecture principles require defensive coding patterns that mitigate integer wraparound risks.
CWE-192prevents — Secure system architecture and engineering principles promote strong typing and overflow protection.
CWE-193prevents — Secure system architecture and engineering principles promote defensive coding practices that reduce off-by-one mistakes.
CWE-194prevents — Secure architecture principles encourage use of safe data types and explicit casting, reducing sign-extension risk.
CWE-195prevents — Secure system architecture and engineering principles include data-type safety and overflow prevention.
CWE-196prevents — Secure architecture principles include choosing appropriate data types and avoiding implicit conversions.
CWE-198prevents — Secure architecture principles mandate explicit handling of platform differences such as byte ordering.
CWE-20prevents — Security-by-design principles explicitly call for data validation and sanitization at every layer, reducing the chance that malformed or malicious input will be processed without scrutiny.
CWE-200prevents — Designing controls to encrypt sensitive data, apply least privilege and fail securely limits the exposure of confidential information when an attacker gains partial access or an error occurs.
CWE-204prevents — Secure architecture principles discourage designs that leak internal state via differing responses.
CWE-205prevents — Secure architecture principles can mandate uniform error handling and response patterns to avoid leaking internal state.
CWE-207prevents — Secure architecture principles can ensure equivalent products behave identically to external observers.
CWE-209prevents — Secure architecture principles include proper exception handling.
CWE-210prevents — Secure architecture principles reduce exposure but do not directly address error-message content.
CWE-219mitigates — Secure architecture principles discourage storing sensitive data in publicly served directories.
CWE-22prevents — Secure architecture principles require least-privilege file access and directory isolation.
CWE-228prevents — Secure system architecture principles encourage robust input handling but do not prescribe the specific coding practice.
CWE-229prevents — Secure architecture principles encourage robust input handling but do not directly specify value-count checks.
CWE-23prevents — Secure architecture principles include directory isolation and canonicalization, reducing but not eliminating traversal risk.
CWE-231prevents — Secure architecture principles encourage robust input handling but do not specifically address extra-value scenarios.
CWE-232prevents — Secure architecture principles mandate explicit handling of undefined or unsupported states.
CWE-237prevents — Secure system architecture principles include defensive design against malformed or complex structural inputs.
CWE-24prevents — Secure architecture principles reduce attack surface but do not prescribe the specific coding fix.
CWE-240prevents — Secure architecture principles mandate consistent structural definitions across system components.
CWE-241prevents — Secure system architecture principles encourage robust input handling but do not specifically address data-type validation.
CWE-248prevents — Secure architecture principles call for centralized, comprehensive exception management.
CWE-25prevents — Secure architecture principles reduce exposure to path traversal through least-privilege file-system design.
CWE-253prevents — Secure architecture principles require defensive coding practices such as validating function results.
CWE-26prevents — Secure architecture principles reduce the attack surface but do not prescribe the specific coding fix.
CWE-267prevents — Secure system architecture can design safer privilege models but does not eliminate unsafe actions in existing privileges.
CWE-269prevents — Requiring dynamic, context-based privilege assignment and least-privilege enforcement stops the assignment of excessive rights that would let a compromised account perform unintended privileged actions.
CWE-27prevents — Secure architecture principles discourage unsafe path construction but do not prescribe the specific coding fix.
CWE-270prevents — Secure-architecture principles encourage least-privilege context separation but leave implementation details open.
CWE-277prevents — Secure system architecture principles can incorporate least-privilege permission models but do not specifically mandate secure inheritance.
CWE-28prevents — Secure architecture principles require canonicalization and least-privilege directory access to prevent traversal.
CWE-284prevents — Embedding least-privilege, default-deny and zero-trust verification into every architecture layer stops the creation of overly permissive access paths that would otherwise allow unauthorized actors to reach protected resources.
CWE-287prevents — Mandating strong, context-aware authentication for all access attempts prevents systems from accepting unauthenticated or weakly authenticated identities that attackers could impersonate.
CWE-288prevents — Secure architecture principles reduce likelihood of alternate unauthenticated paths but do not eliminate them.
CWE-29prevents — Secure architecture principles include directory sandboxing and safe file-access design that mitigate path traversal.
CWE-290prevents — Secure architecture principles help avoid spoofable designs but do not mandate specific controls.
CWE-297mitigates — Secure system architecture principles require proper certificate validation to protect communications.
CWE-30prevents — Secure architecture principles reduce the attack surface but do not prescribe the specific coding checks needed.
CWE-301prevents — Secure system architecture principles encourage mutual authentication and nonce usage that mitigate reflection attacks.
CWE-306prevents — Security engineering principles insist on authentication and authorization for every critical function, eliminating entry points that lack any access control mechanism.
CWE-31prevents — Secure architecture principles reduce the attack surface but do not prescribe the specific coding fix.
CWE-32prevents — Secure architecture principles reduce exposure to path traversal but do not prescribe the specific coding fix.
CWE-322prevents — Secure system architecture principles include authenticated key exchange as a foundational design requirement.
CWE-329prevents — Secure architecture principles guide selection of strong cryptographic primitives and IV handling.
CWE-332prevents — Secure architecture principles include use of approved cryptographic modules with adequate entropy sources.
CWE-333mitigates — Requires secure system architecture that includes robust random-number services, mitigating TRNG failures.
CWE-337prevents — Secure architecture principles include choosing cryptographically strong random number generation.
CWE-338prevents — Secure engineering principles include selection of appropriate cryptographic primitives.
CWE-34prevents — Secure system architecture principles reduce the attack surface for path traversal but do not prescribe specific coding fixes.
CWE-342prevents — Secure architecture principles include use of strong, unpredictable random sources.
CWE-343prevents — Secure architecture principles call for cryptographically strong randomness sources.
CWE-344prevents — Secure architecture principles discourage hard-coded assumptions, yet the control is broader than this single weakness.
CWE-346prevents — Secure architecture principles encourage origin checks but do not mandate them.
CWE-348prevents — Secure architecture principles include trusted input channels and source verification mechanisms.
CWE-349prevents — Secure architecture principles require explicit trust boundaries and data-origin checks that mitigate mixing of trusted and untrusted inputs.
CWE-35prevents — Secure architecture principles require proper directory restrictions and input sanitization to prevent traversal.
CWE-350prevents — Secure architecture principles discourage reliance on unauthenticated DNS for security decisions.
CWE-351prevents — Secure architecture principles encourage strong typing and clear type boundaries in system design.
CWE-353prevents — Secure architecture principles can mandate integrity protection for communications.
CWE-356prevents — Secure architecture principles can mandate confirmation prompts for risky actions.
CWE-357prevents — Secure system architecture and engineering principles address usable security mechanisms such as prominent warnings.
CWE-358prevents — Secure system architecture and engineering principles require faithful realization of protocol-level security checks.
CWE-36prevents — Secure architecture principles call for canonicalization and sandboxing that limit absolute path traversal.
CWE-360prevents — Secure architecture principles can include event validation mechanisms but do not mandate them.
CWE-362prevents — Secure architecture principles require proper synchronization and resource isolation, addressing the root cause of CWE-362.
CWE-363mitigates — Secure architecture principles encourage atomic checks and safe file APIs, but do not prescribe them explicitly.
CWE-366prevents — Secure architecture principles address concurrent access and resource synchronization.
CWE-368prevents — Secure architecture principles include designing atomic privilege transitions to avoid race conditions.
CWE-369prevents — Secure architecture principles encourage defensive coding patterns that avoid arithmetic exceptions.
CWE-37mitigates — Secure architecture principles include canonicalization and path-handling controls that prevent traversal.
CWE-372prevents — Secure architecture principles encourage explicit state modelling and fail-safe transitions.
CWE-374prevents — Secure architecture principles include isolating mutable state and avoiding shared references across trust boundaries.
CWE-377prevents — Secure system architecture principles discourage insecure temporary-file patterns but do not directly address them.
CWE-378prevents — Secure architecture principles require least-privilege file creation and access controls.
CWE-379prevents — Secure system architecture principles include proper file-system permission models that mitigate insecure temp-file creation.
CWE-38prevents — Secure architecture principles encourage safe file-access design patterns that reduce traversal risk.
CWE-385prevents — Secure architecture principles can include timing-channel countermeasures but are not specific.
CWE-386mitigates — Secure architecture principles discourage use of mutable symbolic references that can resolve to unintended objects.
CWE-39prevents — Secure architecture principles include canonicalization and path sanitization to prevent traversal via drive letters.
CWE-40prevents — Secure architecture principles include canonicalization and path-handling controls that prevent UNC traversal.
CWE-401prevents — Secure system architecture and engineering principles include resource-management guidelines that address memory leaks.
CWE-407prevents — Secure system architecture principles encourage selection of algorithms with acceptable worst-case complexity.
CWE-409prevents — Secure architecture principles encourage defensive design against resource-exhaustion threats.
CWE-41prevents — Secure architecture principles call for safe file-system abstractions that mitigate path traversal risks.
CWE-410prevents — Secure architecture principles include designing adequate resource allocation and limits.
CWE-412prevents — Secure architecture principles discourage exposing lock mechanisms to external actors.
CWE-413prevents — Secure system architecture principles include concurrency and resource-locking design rules.
CWE-415prevents — Secure system architecture and engineering principles can prescribe safe memory-management patterns.
CWE-416prevents — Secure architecture principles include memory-safety design choices that limit use-after-free exposure.
CWE-419prevents — Secure architecture principles include protecting management channels by design.
CWE-42prevents — Secure system architecture can enforce canonicalization and path normalization controls.
CWE-421prevents — Secure architecture principles reduce the likelihood of exposing alternate channels to unintended actors.
CWE-422prevents — Secure system architecture principles require least-privilege design and authenticated inter-process communication, mitigating shatter attacks.
CWE-424prevents — Secure architecture principles require eliminating unauthorized entry points during design.
CWE-426prevents — Secure architecture principles include hard-coded or validated search paths and avoiding reliance on untrusted directories.
CWE-427mitigates — Secure system architecture and engineering principles require explicit control over search paths and resource locations.
CWE-43prevents — Secure architecture principles mandate canonicalization and safe path resolution mechanisms.
CWE-430prevents — Secure architecture principles require correct component wiring and handler assignment.
CWE-431prevents — Secure architecture principles include robust error handling and graceful degradation to avoid unhandled paths.
CWE-433prevents — Secure architecture principles can guide safe web-root design but do not directly address unparsed file extensions.
CWE-435prevents — Secure architecture principles address component interfaces and composition risks.
CWE-436prevents — Secure architecture principles include well-defined component boundaries and shared data models that limit conflicting state perceptions.
CWE-437prevents — Secure architecture principles emphasize complete system modeling, including all endpoint capabilities and states.
CWE-44prevents — Secure architecture principles include canonicalization and input sanitization to prevent path equivalence attacks.
CWE-441prevents — Secure-architecture principles discourage designs where a component blindly forwards requests without source validation.
CWE-444prevents — Secure architecture principles include consistent protocol handling and defense-in-depth for proxies.
CWE-446prevents — Secure architecture principles can guide UI design but do not specifically address misleading security-state indicators.
CWE-450prevents — Secure system architecture principles can enforce consistent, least-privilege handling of ambiguous UI input.
CWE-453prevents — Secure architecture principles include avoiding insecure defaults in design.
CWE-454prevents — Secure architecture principles reduce exposure of trusted variables to external inputs.
CWE-455prevents — Secure system architecture principles include fail-safe initialization and error handling requirements.
CWE-46prevents — Secure system architecture and engineering principles include canonicalization and path-handling controls that mitigate ambiguous file names.
CWE-460prevents — Secure architecture principles include designing for safe failure and guaranteed cleanup on exceptions.
CWE-470prevents — Secure architecture principles discourage dynamic class loading from external data sources.
CWE-471prevents — Secure architecture principles call for explicit immutability guarantees and enforcement mechanisms.
CWE-475prevents — Secure system architecture principles can require defensive coding that eliminates undefined behavior in APIs.
CWE-476prevents — Secure architecture principles encourage defensive design that avoids unsafe pointer use.
CWE-488prevents — Secure system architecture principles require isolation of session state to avoid cross-session data leakage.
CWE-491prevents — Secure architecture principles discourage mutable state exposure via cloneable objects.
CWE-495prevents — Secure architecture principles such as least privilege and encapsulation directly address the exposure of private data structures.
CWE-499prevents — Secure architecture principles include data-protection patterns that prevent unintended serialization of secrets.
CWE-50prevents — Secure system architecture principles mandate proper input sanitization and path normalization.
CWE-501prevents — Secure architecture principles require explicit trust zones and data segregation, mitigating mixing of trusted/untrusted data.
CWE-514mitigates — Secure architecture principles include isolation and resource separation that mitigate covert channels, yet the control is broader than this single weakness.
CWE-515prevents — Secure architecture principles can reduce covert storage opportunities but do not guarantee elimination.
CWE-523prevents — Requires secure system architecture principles that can mandate encrypted transport.
CWE-526prevents — Secure architecture principles discourage placing secrets in environment variables without encryption.
CWE-535mitigates — Secure architecture principles encourage generic error responses but are not specific to shell error messages.
CWE-544prevents — Secure system architecture and engineering principles include consistent exception and error-handling mechanisms.
CWE-548prevents — Secure system architecture principles include configuring web servers to prevent automatic directory listings.
CWE-550prevents — Secure architecture principles include proper exception handling to prevent leakage.
CWE-551prevents — Secure architecture principles include proper request handling order to prevent bypasses.
CWE-553prevents — Secure architecture principles discourage exposing executable directories but do not directly prevent the weakness.
CWE-556mitigates — Secure architecture principles discourage the use of impersonation in favor of proper delegation models.
CWE-564prevents — Secure architecture principles discourage dynamic SQL but do not directly address Hibernate misuse.
CWE-566mitigates — Secure architecture principles require least-privilege data access and input validation, directly mitigating the described authorization bypass.
CWE-567prevents — Secure architecture principles address concurrency and shared-state protection mechanisms.
CWE-57prevents — Promotes secure architecture principles that reduce the likelihood of path-equivalence vulnerabilities.
CWE-573prevents — Secure system architecture and engineering principles include specification adherence as a design constraint.
CWE-587prevents — Secure system architecture and engineering principles discourage unsafe pointer usage.
CWE-588prevents — Secure architecture principles discourage unsafe casting and promote strong typing.
CWE-59prevents — Secure architecture principles include input validation and safe file-access design patterns.
CWE-590prevents — Secure architecture and engineering principles include disciplined memory management that prevents freeing non-heap memory.
CWE-598prevents — Secure architecture principles discourage exposing sensitive data in URLs.
CWE-600prevents — Secure system architecture principles require robust error management and containment of exception information.
CWE-602prevents — Secure architecture principles discourage client-side trust but do not directly address this weakness.
CWE-603prevents — Promotes secure architecture principles that reject client-only authentication designs.
CWE-605prevents — Secure system architecture principles require unique service endpoints and prevent port collisions by design.
CWE-61prevents — Secure-architecture principles require safe file-handling and canonicalization, directly addressing symlink attacks.
CWE-610prevents — Secure architecture principles reduce the attack surface for externally controlled references but do not prescribe specific validation rules.
CWE-611prevents — Secure architecture principles include safe parser configuration that mitigates external entity risks.
CWE-616prevents — Secure architecture principles discourage unsafe global state, indirectly reducing exposure to variable-injection attacks.
CWE-617prevents — Secure architecture principles discourage the use of assertions for runtime error handling that an attacker could exploit.
CWE-618prevents — Secure architecture principles discourage exposing privileged operations outside the browser security model.
CWE-62prevents — Secure architecture principles include proper file-system namespace handling that can prevent hard-link traversal.
CWE-621prevents — Secure architecture principles discourage unsafe dynamic variable extraction patterns.
CWE-622prevents — Secure architecture principles mandate defensive coding and parameter validation at API boundaries.
CWE-623prevents — Secure architecture principles discourage unsafe ActiveX usage, yet the control is broader than this specific weakness.
CWE-626prevents — Secure architecture principles can require canonicalization and safe data-representation boundaries.
CWE-627prevents — Secure architecture principles discourage unsafe dynamic evaluation constructs.
CWE-637prevents — Secure system architecture and engineering principles explicitly require simplicity and minimalism, directly mitigating unnecessary complexity.
CWE-641prevents — Secure system architecture principles discourage unsafe resource naming but do not prescribe specific controls.
CWE-642prevents — Secure architecture principles discourage external control of security-critical state.
CWE-643prevents — Secure architecture principles reduce the likelihood of unsafe dynamic query construction.
CWE-644prevents — Secure architecture principles reduce injection surfaces but do not prescribe header-specific controls.
CWE-646prevents — Secure architecture principles encourage safe file handling, yet the control is broader than this specific weakness.
CWE-648prevents — Secure architecture principles guide proper privilege separation and API usage.
CWE-649prevents — Secure architecture principles require that encrypted or obfuscated data be protected against unauthorized modification.
CWE-65prevents — Secure system architecture principles include least-privilege file access and sandboxing that mitigate link-based redirection attacks.
CWE-650prevents — Secure system architecture principles include proper HTTP method handling and RESTful design to prevent state changes via GET.
CWE-652prevents — Secure architecture principles reduce the likelihood of unsafe dynamic query construction.
CWE-653prevents — Secure system architecture principles explicitly call for isolation and least-privilege boundaries.
CWE-656prevents — Requires secure architecture and engineering principles that reject reliance on obscurity.
CWE-657prevents — Secure system architecture and engineering principles are the explicit embodiment of the secure design principles violated by CWE-657.
CWE-66prevents — Secure system architecture and engineering principles can incorporate design controls that prevent improper resolution of virtual file names.
CWE-662prevents — Secure system architecture principles include thread-safety and resource-locking mechanisms to avoid improper synchronization.
CWE-663prevents — Secure architecture principles include concurrency-safe design and avoidance of shared mutable state in non-reentrant functions.
CWE-664prevents — Secure architecture principles reduce lifetime control issues but are not specific to them.
CWE-665prevents — Secure system architecture and engineering principles require explicit initialization of resources and secure state management.
CWE-667prevents — Secure architecture principles address thread-safety and resource synchronization.
CWE-669mitigates — Secure architecture principles reduce cross-sphere transfer weaknesses.
CWE-67prevents — Secure architecture principles mandate safe pathname construction and canonicalization.
CWE-674prevents — Secure system architecture principles include resource-management and input-validation rules that limit recursion.
CWE-675prevents — Secure architecture principles discourage redundant operations on the same resource.
CWE-680prevents — Secure architecture principles encourage use of safe arithmetic libraries and overflow detection.
CWE-681prevents — Secure architecture principles promote strong typing and safe conversion practices.
CWE-687prevents — Secure architecture principles promote defensive coding that reduces argument misuse.
CWE-689prevents — Promotes secure architecture principles that avoid race conditions in resource operations.
CWE-690prevents — Secure architecture principles require robust error handling and pointer validation.
CWE-691prevents — Secure system architecture and engineering principles require explicit control-flow integrity mechanisms and error-handling paths.
CWE-695prevents — Secure architecture principles restrict use of low-level constructs outside approved patterns.
CWE-696prevents — Secure system architecture and engineering principles require proper ordering of design and implementation steps.
CWE-697prevents — Secure architecture principles can require robust comparison mechanisms for access decisions.
CWE-698prevents — Secure architecture principles discourage continued execution after redirects.
CWE-706prevents — Secure architecture principles discourage reliance on ambient or globally-resolvable names without explicit scoping.
CWE-707prevents — Secure architecture principles include canonicalization and safe parsing, mitigating but not fully covering neutralization issues.
CWE-73prevents — Secure architecture principles discourage unsafe path construction but do not prescribe concrete file-name controls.
CWE-732prevents — System hardening and explicit specification of required permissions during design reduce the likelihood that critical resources will be created or left with overly permissive access rights.
CWE-74prevents — Secure architecture principles reduce injection surfaces but do not prescribe specific neutralization techniques.
CWE-749prevents — Secure architecture principles discourage exposing dangerous functions, but do not guarantee their absence.
CWE-75prevents — Secure architecture principles reduce injection surfaces but do not prescribe the actual sanitization logic.
CWE-754prevents — Secure system architecture and engineering principles require robust error and exception handling mechanisms.
CWE-755prevents — Secure architecture and engineering principles require robust exception and error management.
CWE-757prevents — Secure architecture principles include enforcing strong algorithm selection in protocol design.
CWE-76prevents — Secure system architecture principles require consistent canonicalization and neutralization of equivalent inputs.
CWE-760prevents — Secure system architecture and engineering principles guide the selection of strong cryptographic mechanisms including proper salting.
CWE-763prevents — Secure architecture principles include safe memory handling and resource-lifetime rules.
CWE-764prevents — Secure system architecture and engineering principles can mandate proper resource-locking patterns and deadlock analysis.
CWE-765prevents — Secure system architecture and engineering principles can mandate proper resource-state management and locking invariants.
CWE-767prevents — Secure architecture principles enforce encapsulation and least-privilege data access.
CWE-77prevents — Secure architecture principles reduce the attack surface but do not prescribe the specific neutralization techniques needed.
CWE-771prevents — Secure system architecture principles can mandate explicit resource tracking and release mechanisms.
CWE-774prevents — Secure architecture principles include resource-management controls to prevent exhaustion.
CWE-776prevents — Secure architecture principles discourage unsafe parser configurations that enable entity expansion attacks.
CWE-780prevents — Secure architecture principles include choosing appropriate cryptographic primitives and padding.
CWE-782prevents — Secure system architecture principles mandate least-privilege access to kernel interfaces.
CWE-786prevents — Secure architecture principles promote safe memory handling and pointer arithmetic safeguards.
CWE-787prevents — Secure architecture and engineering principles reduce the likelihood of buffer overflows.
CWE-788prevents — Secure architecture principles discourage unsafe pointer arithmetic and unbounded buffers.
CWE-789prevents — Secure architecture principles require resource-limit enforcement that mitigates uncontrolled memory requests.
CWE-790prevents — Secure system architecture and engineering principles include defensive input handling that reduces the risk of unfiltered special elements.
CWE-791prevents — Secure system architecture and engineering principles require defensive design patterns that prevent unfiltered data from reaching downstream components.
CWE-792prevents — Secure architecture principles encourage defensive input handling but do not prescribe the specific filtering mechanism.
CWE-794prevents — Secure architecture principles encourage defensive input handling but do not prescribe specific filtering controls.
CWE-799prevents — Secure architecture principles recommend rate-limiting and resource-management mechanisms.
CWE-805prevents — Secure architecture principles encourage bounds-checked APIs, yet leave concrete coding decisions to developers.
CWE-807prevents — Secure architecture principles mandate treating all external inputs as untrusted.
CWE-81prevents — Secure system architecture principles reduce the likelihood of unsafe error handling but do not prescribe specific neutralization techniques.
CWE-82prevents — Secure architecture and engineering principles include design rules that eliminate unsafe attribute handling in web pages.
CWE-820prevents — Secure architecture principles include proper synchronization for shared resources.
CWE-821prevents — Secure architecture principles address concurrent access and resource synchronization.
CWE-822prevents — Secure architecture principles discourage direct use of untrusted values as pointers.
CWE-825prevents — Secure architecture and engineering principles can prescribe memory-safety patterns, yet fixing only this weakness does not achieve the control.
CWE-826prevents — Secure architecture principles encourage proper resource scoping and lifetime management.
CWE-827prevents — Secure architecture principles require disabling external DTD resolution and entity expansion limits.
CWE-83prevents — Secure architecture principles reduce attack surface but do not prescribe the specific neutralization techniques needed.
CWE-830prevents — Secure architecture principles discourage embedding untrusted content, yet require additional controls for full mitigation.
CWE-832prevents — Secure system architecture and engineering principles can mandate proper resource-locking patterns.
CWE-833prevents — Secure system architecture principles include concurrency controls and resource-locking discipline that prevent deadlock.
CWE-834prevents — Secure architecture principles mandate defensive coding patterns such as loop termination checks.
CWE-839prevents — Secure system architecture principles require defensive input handling and range validation to prevent out-of-bounds values.
CWE-841prevents — Secure architecture principles address proper ordering of security-critical operations.
CWE-843prevents — Secure architecture principles promote type-safe languages and memory-safety mechanisms that mitigate type confusion.
CWE-862prevents — Requiring explicit authorization checks for every request, even from inside the perimeter, eliminates the absence of authorization logic that would let callers invoke functions or data without proper rights.
CWE-87prevents — Secure architecture principles reduce attack surface but do not prescribe specific encoding rules.
CWE-88prevents — Secure architecture principles discourage unsafe command invocation patterns and favor safer APIs.
CWE-908prevents — Secure system architecture and engineering principles include defensive coding practices that prevent use of uninitialized memory or objects.
CWE-909prevents — Secure architecture principles include proper resource lifecycle management.
CWE-91prevents — Secure architecture principles reduce attack surface but do not prescribe XML-specific controls.
CWE-911prevents — Secure system architecture principles encourage explicit resource-ownership models that mitigate reference-count misuse.
CWE-912prevents — Secure system architecture and engineering principles require transparent, documented designs that preclude hidden functionality.
CWE-913prevents — Secure architecture principles require design controls that prevent improper dynamic code resource manipulation.
CWE-914prevents — Secure architecture principles discourage unsafe dynamic variable access patterns.
CWE-915prevents — Secure architecture principles mandate strict control over dynamic object modification and attribute binding.
CWE-917prevents — Secure architecture principles reduce the attack surface but do not prescribe the specific neutralization techniques needed.
CWE-923prevents — Secure architecture principles recommend endpoint verification but are not a direct mitigation.
CWE-925prevents — Secure architecture principles include proper component authorization and input validation.
CWE-926prevents — Secure architecture principles discourage overly permissive component exports, though the control is broader than this single weakness.
CWE-927prevents — Secure architecture principles discourage implicit intents for sensitive payloads.
CWE-93prevents — Secure architecture principles encourage safe handling of untrusted data but do not prescribe specific CRLF controls.
CWE-941prevents — Secure architecture principles encourage proper endpoint design, providing indirect mitigation.
CWE-942prevents — Secure architecture principles include defining trust boundaries, which can reduce permissive cross-domain allowances.
CWE-943prevents — Secure architecture principles reduce the likelihood of query-logic flaws but do not prescribe the specific coding practice.
CWE-95prevents — Secure architecture principles discourage unsafe dynamic evaluation constructs.
CWE-96prevents — Secure architecture principles reduce injection surfaces but do not prescribe the specific neutralization techniques.
CWE-97prevents — Secure architecture principles reduce the attack surface for SSI but do not prescribe specific neutralization techniques.
CWE-98prevents — Secure architecture principles reduce attack surface but do not specifically address dynamic file inclusion.
CWE-99prevents — Secure architecture principles reduce attack surface for resource injection but do not prescribe identifier validation.

Mitigated MITRE ATT&CK techniques (1557)

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

Why these map — AI rationale (under review)

T1001detects — A.8.27 mandates security-oriented design reviews, threat analysis, and zero-trust monitoring principles that surface anomalous or obfuscated C2 patterns during architecture and engineering reviews, but this is limited to design-time and does not mandate runtime detection mechanisms.
T1001prevents — A.8.27 mandates security-by-design, defense-in-depth, assume-breach, least-privilege, distrust-external-input, hardening, and zero-trust verification that together constrain or block many T1001 implementations (e.g., protocol impersonation, junk-data blending, or stego in C2 channels) when applied to system architecture and engineering; it does not reach every possible obfuscation method or post-deployment adversary innovation, leaving a genuine minority slice unaddressed.
T1001.001detects — A.8.27 mandates security-oriented design reviews, analysis of controls' detection capabilities, hardening, and zero-trust monitoring principles that surface anomalous C2 protocols (including junked traffic) during engineering and review, but this is limited to design-time and does not mandate runtime detection mechanisms.
T1001.002detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of principles to identify vulnerabilities and new threats; this surfaces steganography in C2 design or traffic patterns as part of architecture analysis, but only where the organization chooses to apply those reviews to the specific technique (a slice set by implementation scope, not a bounded remainder).
T1001.002prevents — A.8.27 mandates security-by-design, defence-in-depth, assume-breach, least-privilege, distrust-external-input, hardening, and zero-trust verification that together constrain or block many steganographic C2 channels (e.g. by requiring end-to-end encryption, strong authz on every request, and removal of unnecessary protocols), but leaves a genuine remainder of custom or covert channels that can still be designed around the mandated principles.
T1001.003detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of principles against new threats/attack patterns, which surfaces impersonation attempts in reviewed or monitored architecture but does not instrument or guarantee detection of in-flight C2 blending across all platforms or implementations.
T1001.003prevents — A.8.27 mandates security-by-design, defense-in-depth, least privilege, assume-breach, distrust-external-input, hardening, and zero-trust verification that together stop many impersonation vectors at design time; the remainder is post-design malleable C2 that still blends with legitimate traffic.
T1003detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust monitoring principles, and ongoing review of engineering practices that surface anomalous credential-access patterns in architecture and deployment, but this is scoped by what the organization chooses to instrument and does not guarantee runtime detection of all OS credential dumping methods.
T1003prevents — A.8.27 mandates applying security-by-design, defence-in-depth, least-privilege, zero-trust, hardening, and secure engineering principles (including credential handling and authentication) that can stop many OS credential-dumping vectors before they succeed; it does not reach every possible in-memory or custom-tool extraction path on every platform.
T1003.001detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust principles, and ongoing review of engineering practices that can surface LSASS dumping risks or anomalous credential-access patterns during architecture and deployment reviews, but the clause is a governance and design process that does not itself instrument or monitor runtime behavior.
T1003.001prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, hardening, assume-breach and zero-trust principles that can stop credential material from being harvestable from LSASS (e.g. by removing plaintext storage, enforcing credential guard, or isolating LSA), but the clause only sets engineering practices rather than mandating any specific mechanism, leaving many Windows deployments still vulnerable.
T1003.002detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust principles, and ongoing review of engineering practices that surface credential-extraction risks (e.g., via assume-breach, least privilege, and monitoring for anomalous access), but does not mandate or guarantee runtime detection of the specific in-memory or registry-based SAM extraction technique.
T1003.002prevents — A.8.27 mandates security-by-design principles (least privilege, assume breach, defence-in-depth, hardening, distrust external input, secure architecture layers) that, when applied during engineering, reduce the attack surface and privilege paths needed for SYSTEM-level SAM extraction; this is a genuine but minority slice of the class because the technique can still be introduced via flawed implementation, unhardened defaults, or post-deployment configuration drift.
T1003.003detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of engineering principles against new threats; these surface design or runtime indicators of NTDS-access patterns (e.g. via monitoring implied by assume-breach and never-trust), but only as a minority slice of possible implementations rather than a guaranteed or broad detection mechanism.
T1003.003prevents — A.8.27 mandates security-by-design, defence-in-depth, least privilege, assume-breach, hardening, and zero-trust principles that can stop many paths to NTDS.dit access (e.g. via least-privilege on DCs, hardened configs, and not relying on perimeter alone), but leaves residual vectors such as legitimate admin tools, insider access, or unhardened backups that the control does not itself block.
T1003.004detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust monitoring principles, and regular review of engineering practices that can surface anomalous credential-access patterns (e.g. via assume-breach or never-trust verification), but the clause is about architecture/engineering and does not itself instrument or perform detection of the runtime technique.
T1003.004prevents — A.8.27 mandates security-by-design, least privilege, hardening, defence-in-depth and zero-trust principles that, when applied during engineering, can stop SYSTEM-level access or credential extraction paths from being available; this reaches only a slice of the technique because the control is a process that depends on implementation rigour and does not itself block already-present SYSTEM-level registry or memory access on a compromised host.
T1003.005detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust principles (assume breach, never trust/always verify, least privilege), and ongoing review of engineering principles against new threats; these surface the possibility of cached credential extraction during design and threat analysis but do not instrument or monitor runtime extraction attempts.
T1003.005prevents — A.8.27 mandates applying security-by-design, least-privilege, zero-trust, hardening, and secure credential-handling principles that can stop cached-domain-credential stores from being created or made extractable, but the control is a set of engineering practices rather than an enforced mechanism, leaving substantial residual exposure on deployed systems.
T1003.006detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification of requests, and ongoing review of principles against new threats, which surfaces anomalous replication-like behavior in architecture but does not mandate runtime monitoring or logging that would catch DCSync in flight across all implementations.
T1003.006prevents — A.8.27 mandates applying security-by-design, least privilege, defence-in-depth, assume-breach and zero-trust principles (including strong auth, dynamic access control and distrust of internal requests) during architecture and engineering; these directly constrain the privileged replication rights and API abuse that enable DCSync, but the control is a process that depends on how rigorously those principles are implemented and reviewed, leaving a genuine slice unreached.
T1003.007prevents — A.8.27 mandates security-by-design, defence-in-depth, least privilege, hardening, secure defaults and zero-trust principles that can constrain credential exposure in process memory and limit procfs access, but does not guarantee elimination of all credential-in-memory patterns or all /proc read paths on Linux.
T1003.008detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust monitoring principles, and regular review of engineering practices against new threats, which can surface anomalous access or dumping attempts on credential files as part of integrated controls, but this is only a slice of possible detection rather than broad coverage of the technique.
T1003.008prevents — A.8.27 mandates security-by-design, least privilege, defence-in-depth, hardening, secure defaults and zero-trust principles that, when applied during engineering, stop the /etc/shadow file from being world-readable or easily dumped by non-root processes; this is only a slice of the technique because the control is a process that depends on how rigorously those principles are followed in any given build.
T1005detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust principles, and ongoing review of engineering practices that surface anomalous access patterns or insecure designs enabling local data searches, but does not mandate runtime detection mechanisms.
T1005prevents — A.8.27 mandates security-by-design principles (least privilege, default deny, zero-trust/never-trust, hardening, distrust-external-input, defence-in-depth) that, when applied during engineering, constrain the attack surface and data exposure that T1005 relies on; this is a genuine but minority slice of the technique because the clause only sets process-level requirements whose actual coverage depends on how rigorously the implementer applies them to every component and because many post-compromise local-collection vectors remain reachable even under hardened designs.
T1006detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of principles to identify vulnerabilities and new threats; this surfaces the bypass pattern in design or monitoring gaps but does not instrument runtime detection of the technique itself.
T1006prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, hardening, and zero-trust principles that can constrain direct-volume mechanisms (e.g. by removing unnecessary raw-device privileges or enforcing strict access boundaries), but leaves a large remainder for post-design bypasses, third-party tools, and volume-level primitives that the engineering principles do not themselves block.
T1007detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust monitoring principles, and regular review of engineering procedures to surface new threats; this can surface anomalous service-discovery commands or unexpected service enumeration in monitored environments, but the clause is scoped to architecture/engineering activities rather than mandating runtime detection coverage of all T1007 observables.
T1008detects — A.8.27 mandates security-oriented design reviews, threat analysis, zero-trust verification, assume-breach posture, and hardening that surface anomalous or fallback C2 channels during architecture and engineering reviews; this is genuine but only a slice (design-time detection of patterns), not runtime monitoring of live fallback usage.
T1008prevents — A.8.27 mandates security-by-design, defence-in-depth, assume-breach, least-privilege, zero-trust and hardening principles that, when applied during architecture and engineering, can block many fallback-channel C2 designs before they are implemented; the coverage is only a slice because the control is a process that depends on how rigorously those principles are followed and does not guarantee every possible alternate-channel pattern is eliminated.
T1010detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust monitoring principles, and regular reviews against new threats, which can surface anomalous window-enumeration behavior in monitored systems but does not require or guarantee runtime detection of the technique itself.
T1011detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification of requests, and ongoing review of principles against new threats; these surface anomalous exfiltration paths (e.g. via Bluetooth/RF or unmonitored mediums) during architecture analysis and reviews, but only where the organization elects to apply the principles to that medium and only as design-time or review-time discovery rather than runtime detection.
T1011prevents — A.8.27 mandates security-by-design, defence-in-depth, least functionality, zero-trust, hardening, and secure architecture that can constrain or remove many risky secondary network mediums (e.g. disabling Bluetooth, enforcing encrypted/verified channels, applying least-privilege to interfaces), but does not guarantee prevention of all exfiltration-over-alternate-medium cases (e.g. proximity-based WiFi/cellular/modems that remain operationally required).
T1011.001detects — A.8.27 mandates security-oriented design reviews, threat analysis, hardening, zero-trust verification, and ongoing review of engineering principles that surface anomalous or risky Bluetooth usage patterns (e.g. via assume-breach, distrust-external, or monitoring integration), but this is limited to what the design/engineering process itself can discover and does not mandate runtime detection mechanisms.
T1012detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust monitoring principles, and ongoing review of engineering practices that can surface anomalous registry queries as part of threat-aware architecture, but this is only a slice of possible detection coverage rather than a dedicated or comprehensive detection mechanism.
T1014detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of principles against new threats, which surfaces rootkit-enabling design or implementation choices (e.g., weak hooks or unverified boot components) during engineering but does not instrument runtime detection of deployed rootkits.
T1014prevents — A.8.27 mandates security-by-design, defence-in-depth, least privilege, hardening, assume-breach, and distrust-external-input principles plus design reviews that surface and eliminate classes of hooks/modifications used by rootkits; this stops many (but not all) rootkit insertion paths, especially those relying on poor architecture or unhardened defaults.
T1016.002prevents — A.8.27 mandates security-by-design principles (least privilege, default-deny, hardening, assume-breach, distrust-external-input) that reach credential storage and access-control decisions for Wi-Fi profiles, so the technique is blocked on systems built under it; the remainder is post-compromise enumeration on already-breached hosts where the control's preventive slice ends and detection/response take over.
T1018prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, zero-trust and hardening principles that, when applied during engineering, constrain many of the discovery vectors (e.g. by limiting network reachability, removing enumeration utilities, enforcing strict segmentation and default-deny), but leaves a genuine slice (passive local cache/host-file reads, built-in admin tools on managed devices, and discovery that still succeeds inside an authorised enclave) unreached.
T1020detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of principles to identify vulnerabilities and anomalous patterns, which can surface automated exfiltration designs or behaviors in reviewed systems but does not instrument runtime detection of the technique itself.
T1020prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, zero-trust, hardening, and secure session/data-validation principles that can stop automated exfiltration paths (e.g. by blocking unauthorized outbound channels or enforcing end-to-end encryption and dynamic access), but only for systems built under it; it does not reach already-deployed systems or the many exfiltration techniques that ride legitimate channels.
T1020.001detects — A.8.27 mandates security-oriented design reviews, threat analysis, zero-trust principles, and ongoing review of engineering practices that surface design or configuration choices enabling traffic mirroring for exfiltration, but does not mandate runtime detection mechanisms or monitoring of the technique itself.
T1020.001prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, zero-trust, assume-breach, and hardening principles plus design reviews that, when applied to network and cloud architectures, can stop mirroring features from being enabled or reachable by adversaries; this is only a slice because the clause is a process that depends on implementation rigour and does not itself remove the native mirroring capability present on every supported platform.
T1021detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, assume-breach monitoring integration, and regular reviews against new threats, which can surface anomalous remote-service logons or lateral-movement patterns once the architecture is built and operated, but only as a slice of what the control actually requires rather than a dedicated detection mechanism.
T1021prevents — A.8.27 mandates security-by-design principles (least privilege, zero-trust/never-trust-always-verify, defence-in-depth, secure authentication, hardening, and explicit reviews against attack patterns) that directly constrain the credential-abuse and remote-login vectors named in T1021; this stops many instances at design time, but leaves a bounded remainder (compromised credentials, misconfigured services, legacy protocols, and post-design runtime abuse of legitimate remote tools such as ARD) that the clause does not itself close.
T1021.001detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification of requests, and ongoing review of principles against new threats, which surfaces anomalous RDP usage patterns in architecture and deployment but does not mandate runtime monitoring instrumentation.
T1021.001prevents — A.8.27 mandates applying security-by-design, least privilege, default-deny, zero-trust, hardening, and secure authentication principles during engineering; these can stop RDP from being enabled or reachable with valid accounts, but the control only sets a process that may or may not be applied to every RDP surface, leaving a genuine slice unreached.
T1021.002detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification of requests, and ongoing review of principles against new threats, which can surface anomalous SMB/admin-share usage patterns in architecture and monitoring design but does not itself perform detection.
T1021.002prevents — A.8.27 mandates security-by-design principles (least privilege, zero-trust/never-trust, defence-in-depth, hardening, distrust-external-input, assume-breach) that reach administrator-share exposure and SMB lateral movement when applied; the control is a process that does not itself enforce those principles at runtime or on every system, leaving a genuine minority slice unreached.
T1021.003detects — A.8.27 mandates security-oriented design reviews, threat analysis, and ongoing review of engineering principles to identify vulnerabilities and keep up with new threats; this surfaces DCOM-based lateral movement risks during architecture/design or when new attack patterns emerge, but does not mandate runtime detection or monitoring of the technique in operation.
T1021.003prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, assume-breach and zero-trust principles plus architecture reviews that, when applied during engineering, constrain DCOM remote activation paths and privilege boundaries; this stops many but not all real-world DCOM lateral-movement instantiations (e.g. those riding already-elevated admin sessions or misconfigured COM ACLs).
T1021.004detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of engineering principles that surface anomalous or insecure SSH configurations and usage patterns, but does not itself perform or require runtime detection of the technique once it occurs.
T1021.004prevents — A.8.27 mandates security-by-design principles (least privilege, zero-trust never-trust/always-verify, strong auth, defence-in-depth, hardening, secure session control) that can stop valid-account SSH logons when applied to SSH configuration and architecture; this is only a slice because the control is a requirement-setting process whose coverage depends on what the implementer actually chooses to harden or enforce.
T1021.005detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of engineering principles against new threats; these surface VNC-specific risks (weak auth, brute-force, memory exploits) during architecture and review but do not instrument runtime detection of the technique in flight.
T1021.005prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, zero-trust, hardening, secure authentication/session controls and explicit review against known attack patterns; these directly stop many VNC-abuse vectors (weak/default auth, brute-force, unauthenticated access, unnecessary exposure) but leave residual paths such as legitimate VNC use with valid accounts or implementation flaws not caught at design time.
T1021.006detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust monitoring principles, and regular review of engineering practices to surface new threats, which can include WinRM abuse patterns, but does not itself perform or require runtime detection of the technique.
T1021.006prevents — A.8.27 mandates security-by-design, least privilege, zero-trust/never-trust-always-verify, defence-in-depth, hardening, and secure authentication principles that constrain WinRM remote access when applied; this stops many (but not all) valid-account abuse paths, leaving a slice dependent on implementation rigour and exempted legacy configurations.
T1021.007detects — A.8.27 mandates security-oriented design reviews, threat analysis against known attack patterns, zero-trust verification of every request, and regular review of engineering principles to surface new threats; this surfaces the T1021.007 technique (or its indicators) in design/operation but only where the organization chooses to apply those reviews to cloud federation/CLI paths, leaving the bulk of runtime detection to other controls.
T1021.007prevents — A.8.27 mandates security-by-design principles (least privilege, zero-trust/never-trust-always-verify, strong auth, defence-in-depth, assume-breach) that are applied to architecture and engineering; these directly constrain the successful use of valid/federated accounts or tokens against cloud services, but the clause only sets a requirement on the engineering process rather than mandating any universal mechanism, leaving residual exposure dependent on implementation rigour and on legacy/federation exceptions.
T1021.008detects — A.8.27 mandates security-oriented design reviews, threat analysis, zero-trust verification, and ongoing review of engineering principles that surface anomalous or risky direct VM access patterns (e.g. via assume-breach, never-trust, or logging of privileged console use), but this is only a slice of the technique's post-authentication execution on IaaS platforms.
T1021.008prevents — A.8.27 mandates security-by-design principles (least privilege, zero-trust/never-trust-always-verify, defence-in-depth, hardening, secure authentication/session controls) that can be applied during architecture and engineering to restrict or eliminate default privileged direct VM console access, but the control is a process that depends on implementation rigour and does not guarantee the specific technique is blocked in all cloud IaaS configurations.
T1025detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust monitoring principles, and ongoing review of engineering practices that surface anomalous access or collection from removable media in monitored environments, but the clause sets requirements rather than mandating instrumentation depth so what is caught is an implementer-chosen slice
T1027detects — A.8.27 mandates security-oriented design reviews, threat analysis, and reviews against known attack patterns (including obfuscation techniques) plus ongoing updates to combat new threats, which surfaces some instances of T1027 during engineering but does not broadly detect its runtime use across platforms or in transit.
T1027prevents — A.8.27 mandates security-by-design, defense-in-depth, least functionality/privilege, hardening, and design reviews that catch or block many common obfuscation patterns (e.g. via secure defaults, input distrust, and architecture that limits where/ how obfuscated payloads can execute), but does not stop all adversary obfuscation techniques (especially novel encodings, split payloads, or command obfuscation that still runs after delivery).
T1027.001prevents — A.8.27 mandates security-by-design, defence-in-depth, least functionality, hardening, and design reviews that catch or block many evasion patterns including oversized binaries that break static-analysis tools; it does not reach every implementation or every post-compromise padding choice an adversary can still make.
T1027.002detects — A.8.27 mandates security-oriented design reviews, hardening, and ongoing review of engineering principles to identify vulnerabilities and combat new threats, which surfaces some packing/obfuscation techniques (especially custom or novel ones via review against attack patterns), but does not mandate or perform runtime/artifact detection of packed binaries.
T1027.002prevents — A.8.27 mandates security-by-design, defence-in-depth, least functionality, hardening, and design reviews that explicitly consider known attack patterns; these principles applied during development can stop many (but not all) packing/obfuscation techniques from being introduced or left viable in delivered systems or their components.
T1027.003detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of engineering principles against new threats/attack patterns, which surfaces steganography use in custom-developed or reviewed systems but does not instrument runtime detection of hidden payloads in media across all platforms or third-party code.
T1027.003prevents — A.8.27 mandates security-by-design, defense-in-depth, least functionality, hardening, and reviews against known attack patterns (including steganography as a concealment technique), which stops many instances from being introduced; it does not reach every implementation detail or every outsourced supplier, leaving a genuine minority slice unaddressed.
T1027.004detects — A.8.27 mandates security-oriented design reviews, hardening, and ongoing review of engineering principles against new threats/attack patterns, which can surface compile-after-delivery as a suspicious delivery or evasion pattern in reviewed systems or supplier code, but does not mandate runtime or post-delivery detection mechanisms.
T1027.004prevents — A.8.27 mandates security-by-design, defence-in-depth, least functionality, hardening, and secure-engineering reviews that can eliminate the need for or block delivery/execution of uncompiled source-code payloads before they reach the victim, but this is only a slice of the technique's attack surface (e.g., phishing-delivered encrypted sources or post-delivery compilation via native tools).
T1027.006detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and regular review of principles against new threats/attack patterns; this surfaces HTML smuggling as a known pattern during engineering but does not instrument runtime detection of the delivered technique.
T1027.006prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, distrust-external-input, hardening, and design reviews that explicitly consider known attack patterns; these principles, when applied during development, stop most HTML-smuggling patterns from being introduced into delivered systems or web content, but the control is a process that depends on implementation rigour and does not reach every downstream delivery vector or zero-day smuggling variant.
T1027.007detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and regular review of principles against new threats/attack patterns, which can surface dynamic API resolution in reviewed or monitored engineering outputs, but this is limited to what is caught in design/hardening reviews rather than runtime behavioral detection of the technique.
T1027.007prevents — A.8.27 mandates security-by-design, defence-in-depth, least privilege, hardening, and design reviews that catch or block many common dynamic-API-resolution patterns when applied during development; it does not reach malware authored outside the organisation’s SDLC or supply chain.
T1027.008prevents — A.8.27 mandates security-by-design principles (hardening, least functionality, security-oriented design reviews, and secure engineering that includes data sanitisation and defence-in-depth) applied across the SDLC; these directly constrain the production of stripped payloads by requiring symbols/strings to be retained or analysis aids to be present, but only where the principles are actually followed and only for first-party or contracted development, leaving a large remainder for adversary-controlled or post-build stripping on the listed platforms.
T1027.009detects — A.8.27 mandates security-oriented design reviews, hardening, and analysis of controls (including detection capabilities) plus regular review for new threats; this surfaces embedded-payload techniques during architecture and code review but does not instrument runtime detection of the delivered technique itself.
T1027.009prevents — A.8.27 mandates security-by-design, defence-in-depth, least functionality/privilege, hardening, and design reviews that explicitly consider known attack patterns; these directly lower the chance an implementer will produce or accept the benign-looking containers that enable embedded-payload concealment, but do not stop an adversary from crafting or using such a file post-deployment.
T1027.010detects — A.8.27 mandates security-oriented design reviews, hardening, and ongoing review of engineering principles to identify vulnerabilities and combat new threats, which surfaces command obfuscation patterns during architecture, implementation, and code review stages, but only where the organization elects to apply those reviews to the specific languages, tools, or payloads involved.
T1027.010prevents — A.8.27 mandates security-by-design, defence-in-depth, least functionality/privilege, distrust-external-input, secure coding and design reviews that explicitly consider attack patterns; these directly reduce the opportunity for and success of command-obfuscation techniques when applied to development and engineering of the systems that would otherwise execute them.
T1027.011detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of principles against new threats/attack patterns, which surfaces some fileless storage techniques during architecture and engineering but does not instrument or monitor runtime use of Registry/WMI/shared-memory storage.
T1027.011prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, hardening, zero-trust and secure-engineering reviews that can stop many fileless-storage patterns (e.g. by removing writable shared-memory mounts, enforcing strict registry ACLs, or rejecting designs that rely on unmonitored WMI/event-log stores), but leaves a bounded remainder: adversary-chosen encodings, in-memory-only transients, and post-compromise abuse of legitimate admin-configured storage that the principles do not categorically eliminate.
T1027.012detects — A.8.27 mandates security-oriented design reviews, hardening, and ongoing review of engineering principles against known attack patterns and new threats; this surfaces LNK icon smuggling as a known pattern during design/review of shortcut handling or content-filter bypasses, but the clause is scoped to engineering activities rather than runtime detection or monitoring of deployed systems.
T1027.012prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, hardening, distrust-external-input and security-oriented design reviews that can catch or block LNK metadata abuse in the engineering of filters, email gateways, sandboxing, or endpoint execution policies; this stops the technique in some but not all delivery/post-compromise paths, leaving a genuine minority slice prevented.
T1027.013detects — A.8.27 mandates security-oriented design reviews, threat analysis, and reviews against known attack patterns (including obfuscation techniques like encryption/encoding of files), which surfaces the T1027.013 pattern during engineering but does not instrument runtime detection of deployed artifacts.
T1027.013prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, hardening, and design reviews that explicitly consider known attack patterns; these principles, when applied during development, stop many (but not all) common file-encryption/encoding obfuscation patterns from being introduced into first-party or contracted code and into the delivered system.
T1027.014detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and regular review of principles against new threats; these surface polymorphic/mutating code in development or via updated detection logic, but the clause is silent on runtime behavioral detection of already-deployed polymorphic malware.
T1027.014prevents — A.8.27 mandates security-by-design, defence-in-depth, least functionality, hardening, and design reviews that can stop polymorphic code from being introduced or surviving in developed/outsourced systems, but does not reach adversary-controlled mutation engines or already-deployed polymorphic malware.
T1027.015detects — A.8.27 mandates security-oriented design reviews, hardening, and ongoing review of engineering principles to identify vulnerabilities and combat new threats, which can surface compression-based obfuscation in reviewed systems or architectures, but this is limited to design/engineering-time inspection rather than runtime or broad operational detection of the technique.
T1027.015prevents — A.8.27 mandates security-by-design, defense-in-depth, least functionality, hardening, and design reviews that explicitly consider known attack patterns; these principles, when applied during development, stop many (but not all) compression-based obfuscation techniques from being introduced or made effective in the resulting systems.
T1027.016detects — A.8.27 mandates security-oriented design reviews, hardening, and application of principles (including against known attack patterns) that surface obfuscation techniques such as junk code during engineering and review; this is a genuine but minority slice of the full technique surface (which also includes post-deployment static-analysis evasion on already-built malware).
T1027.016prevents — A.8.27 mandates security-by-design, defence-in-depth, least functionality, security-oriented design reviews, hardening, and reviews against known attack patterns; these directly constrain the insertion of junk/dead code during malware development or outsourced engineering, but only where the principles are actually applied to the adversary's own build pipeline, leaving the bulk of post-compromise or third-party malware untouched.
T1027.017detects — A.8.27 mandates security-oriented design reviews, threat analysis against known attack patterns, and hardening that can surface SVG smuggling vectors during engineering, but does not require or perform runtime/operational detection of the technique once deployed.
T1027.017prevents — A.8.27 mandates security-by-design, defence-in-depth, distrust-external-input, secure coding principles (including data validation/sanitisation), hardening, and design reviews that explicitly target known attack patterns; these directly address the SVG/XML/script smuggling vector in development, but the clause is a process that depends on implementation rigour and does not guarantee every downstream filter or renderer will block it.
T1027.018detects — A.8.27 mandates security-oriented design reviews to identify vulnerabilities and analysis of controls that can detect security events, which surfaces the Unicode concealment technique during secure engineering and reviews but does not mandate runtime or scanning detection mechanisms.
T1027.018prevents — A.8.27 mandates security-by-design, defence-in-depth, least functionality, distrust-external-input, secure coding reviews and hardening that reach input sanitisation, data validation and attack-pattern review, all of which can stop invisible-Unicode concealment from being introduced; the control is silent on runtime reconstruction, dynamic execution and non-code text channels, leaving a genuine minority slice prevented.
T1030detects — A.8.27 mandates security-oriented design reviews, threat analysis, and zero-trust monitoring principles that can surface anomalous chunked exfiltration in reviewed architectures or logs, but the clause is about engineering practices rather than mandating runtime detection coverage of this specific technique.
T1033prevents — A.8.27 mandates security-by-design principles (least privilege, zero-trust/never-trust-always-verify, defense-in-depth, hardening, secure session control, and integrated controls) that constrain many common discovery vectors such as unauthenticated enumeration commands, weak session exposure, and overly permissive process/file ownership queries; this is a genuine but minority slice of the technique's surface because the control is a process that sets requirements rather than a universal mechanism that stops every whoami/w/who/show users invocation or environment-variable read.
T1036detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and regular review of principles against new threats/attack patterns, which surfaces masquerading in architecture and engineering but does not instrument runtime detection of the technique once artifacts are deployed.
T1036prevents — A.8.27 mandates security-by-design, defence-in-depth, least privilege, hardening, security-oriented design reviews against known attack patterns, and zero-trust verification; these directly constrain many masquerading vectors (e.g. by enforcing default-deny, proper naming/paths, strong auth, and removal of abusable utilities) but leave residual cases such as post-compromise in-memory manipulation or metadata forgery that the principles do not universally block.
T1036.001detects — A.8.27 mandates security-oriented design reviews, hardening, and ongoing review of engineering principles against known attack patterns and new threats, which surfaces invalid code signature mimicry during development or architecture review, but does not instrument runtime or post-deployment detection of the technique.
T1036.001prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, hardening, security-oriented design reviews against known attack patterns, and zero-trust verification of signatures/authenticity; these directly constrain the adversary's ability to create and deploy binaries that mimic valid signatures and thereby deceive tools or users, but the clause is a process requirement whose coverage still depends on how rigorously those principles are applied to every binary and every validation point.
T1036.002detects — A.8.27 mandates security-oriented design reviews to identify vulnerabilities, hardening, and reviews against known attack patterns plus zero-trust verification; these surface RTLO-based disguise in reviewed systems or during engineering but do not instrument runtime detection of the technique across all platforms or uses (e.g. phishing, registry).
T1036.002prevents — A.8.27 mandates security-by-design, defence-in-depth, least functionality, distrust-external-input, hardening, and design reviews that explicitly consider known attack patterns; these principles applied during engineering would stop most RTLO filename disguises from reaching production (e.g. by sanitising display names, enforcing canonical forms, or blocking anomalous extensions), but the control is a set of high-level principles rather than an enforced mechanism, leaving residual cases in outsourced code, legacy tools, or post-deployment naming.
T1036.003detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of principles against new threats/attack patterns, which can surface renamed-utility evasion in architecture and engineering but does not itself instrument or monitor runtime execution of the technique (that is the domain of A.8.16 monitoring).
T1036.003prevents — A.8.27 mandates security-by-design, defence-in-depth, least privilege, hardening, security-oriented design reviews, and zero-trust principles that can stop renamed utilities from being introduced or executed in many cases, but does not guarantee detection or blocking of all post-compromise renaming or masquerading on every platform.
T1036.004detects — A.8.27 mandates security-oriented design reviews, hardening, and ongoing review of engineering principles to identify vulnerabilities and ensure controls combat new threats, which can surface masquerading in reviewed/outsourced development or architecture but does not broadly instrument runtime detection of deployed masqueraded tasks/services across platforms.
T1036.004prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, hardening, security-oriented design reviews against known attack patterns, and zero-trust principles that explicitly distrust inputs and verify every request; these directly constrain the ability of an adversary to introduce a masquerading task/service that would pass design review or runtime checks, but the clause is a set of engineering principles rather than an enforcement mechanism on every deployed scheduler or service registry, leaving a genuine slice unreached.
T1036.005detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and reviews against known attack patterns, which can surface naming/location masquerading during architecture and engineering reviews (especially in containers), but this is limited to the design/implementation phase and does not broadly detect post-deployment runtime use of the technique.
T1036.005prevents — A.8.27 mandates security-by-design, defence-in-depth, least privilege, hardening, security-oriented design reviews against known attack patterns, and zero-trust principles that reduce the attack surface and the value of masquerading; these stop many (but not all) instances of the technique from being introduced during engineering.
T1036.006detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification of requests, and ongoing review of principles against new threats/attack patterns, which can surface the filename-space evasion in design or monitoring but does not mandate runtime detection of the technique itself.
T1036.006prevents — A.8.27 mandates security-by-design, defence-in-depth, least functionality, hardening, distrust-external-input, and design reviews that analyse attack patterns; these directly address the OS-level filename-processing weakness exploited by T1036.006 when applied to file-type handling and UI/UX layers, but the control is a set of high-level principles whose concrete application is not guaranteed, leaving a genuine slice unreached.
T1036.007detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification of requests, and ongoing review of principles against new threats; these surface double-extension masquerading in architecture, deployment, or incoming payloads but only where the organization explicitly scopes the review or monitoring to cover it, leaving the bulk of runtime file-type inspection or user-side detection outside the clause.
T1036.007prevents — A.8.27 mandates security-by-design, defence-in-depth, least functionality, distrust-external-input, hardening, and design reviews that explicitly consider known attack patterns; these directly stop double-extension masquerading files from being built, delivered or left executable on Windows systems, but the clause is a process requirement whose coverage still depends on how rigorously the principles are applied in each project.
T1036.008detects — A.8.27 mandates security-oriented design reviews, hardening, and analysis of controls (including detection) plus zero-trust verification that can surface masquerading artifacts during engineering and review, but does not itself perform or require runtime detection of the technique post-deployment.
T1036.008prevents — A.8.27 mandates security-by-design principles (including secure coding, input sanitization, distrust-external-input, defense-in-depth, least functionality, and design reviews against known attack patterns) that reduce the chance an application will accept or execute a masqueraded/polyglot file, but does not guarantee complete coverage of all transfer/storage/execution vectors or all possible formatting tricks.
T1036.009detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust monitoring principles, and regular review of engineering procedures against new threats; these surface anomalous process-tree behaviors (e.g., double-fork or daemon detachment) during design, deployment, or ongoing analysis, but only where the organization elects to instrument or review for them.
T1036.009prevents — A.8.27 mandates applying security-by-design, defence-in-depth, least functionality, hardening, and security-oriented design reviews that can identify and eliminate process-tree evasion patterns (e.g. double-fork, daemon calls) before deployment, but the clause is a process requirement whose effectiveness depends on how rigorously those reviews and principles are actually performed.
T1036.010detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification of requests, and ongoing review of principles against new threats; these surface masquerading account names during architecture/engineering reviews or when anomalous account-creation/renaming patterns are examined, but only as a minority slice of the post-deployment operational detection surface across all listed platforms.
T1036.010prevents — A.8.27 mandates security-by-design, least-privilege, zero-trust, hardening, and design reviews that catch or block creation of masquerading accounts when engineering practices are followed; this is a genuine but minority slice of the technique (most real-world abuse occurs via post-compromise admin actions or supply-chain compromise outside the engineering SDLC).
T1036.011detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust monitoring principles, and regular reviews against new threats, which can surface anomalous process-argument spoofing via design/operational telemetry, but only where those reviews or monitoring scopes explicitly cover runtime process memory anomalies on Linux (a slice, not the bulk).
T1036.011prevents — A.8.27 mandates applying security-by-design, defence-in-depth, least privilege, least functionality, hardening, and security-oriented design reviews that can stop the technique from being introduced in developed or outsourced code, but leaves a large remainder for adversary-controlled binaries, runtime memory corruption in already-deployed processes, and techniques that do not require new code.
T1036.012detects — A.8.27 mandates security-oriented design reviews, threat analysis against known attack patterns, and ongoing review of engineering principles to identify new threats; this surfaces the fingerprinting technique in design/implementation but does not instrument runtime detection of spoofed traffic.
T1036.012prevents — A.8.27 mandates security-by-design, defence-in-depth, least privilege, assume-breach, distrust-external-input and zero-trust principles plus design reviews that surface spoofing risks; these constrain the technique's success vector in systems built under them, but the control is a process that does not itself block fingerprint spoofing in every implementation or legacy component.
T1037detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of engineering principles against new threats, which can surface anomalous or insecure boot/logon initialization scripts during architecture and deployment reviews, but does not mandate runtime detection or monitoring of their execution.
T1037prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, hardening, secure defaults and zero-trust principles that reach boot/logon script execution points in several platforms, but leaves a bounded remainder (e.g. legacy OS boot mechanisms, vendor-supplied network-device scripts, and outsourced development where contracts do not fully enforce the principles).
T1037.001detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification of requests, and ongoing review of principles against new threats; these surface anomalous logon-script persistence (e.g. via assume-breach or least-privilege checks) in design and operation, but only where the review scope and monitoring explicitly reach registry-driven logon behaviors rather than mandating broad detection coverage.
T1037.001prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, hardening, secure defaults and zero-trust principles that can constrain logon-script abuse for persistence when applied to authentication, session control, privilege boundaries and system hardening, but the clause only sets engineering principles rather than mandating any specific mechanism that stops the registry-key modification itself.
T1037.002detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and regular review of principles against new threats; these surface anomalous login-hook persistence (or its design) in reviewed/outsourced systems but do not instrument runtime detection of the technique itself.
T1037.002prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, hardening, secure defaults and zero-trust principles that reach the macOS login-hook vector when applied; the control is silent on the specific plist, the deprecated hook mechanism itself, and on post-deprecation LaunchAgent/LaunchDaemon equivalents, leaving a genuine minority slice prevented.
T1037.003detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of engineering principles against new threats, which can surface anomalous logon-script behaviors or misconfigurations enabling persistence, but only as a slice of what the control inspects rather than broad runtime detection.
T1037.003prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, hardening, secure defaults and zero-trust review of architecture and engineering (including GPO/AD configurations), which can stop malicious logon scripts from being introduced or auto-executing, but does not guarantee prevention of all persistence vectors or misconfigurations in outsourced or legacy environments.
T1037.004detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and regular review of principles against new threats; these surface RC-script persistence risks in architecture or during engineering reviews for applicable systems, but the clause is silent on runtime/operational detection and the technique is a post-deployment persistence mechanism on deprecated paths.
T1037.004prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, hardening, secure boot-time configuration and zero-trust principles that reach the class of boot-time root-execution vectors; this constrains many (but not all) RC-script abuse paths, especially on modern distributions that have deprecated RC scripts.
T1037.005detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of engineering principles against new threats; this surfaces the (deprecated) boot-time persistence vector during architecture/design or post-deployment review, but only where the organization explicitly includes legacy macOS boot artifacts in its threat-model or scanning scope.
T1037.005prevents — A.8.27 mandates applying security-by-design, least privilege, default-deny, hardening, and zero-trust principles during engineering; these can stop the creation or enablement of unauthorized StartupItems at architecture and deployment time, but the clause is a process that depends on implementation rigour and does not reach every legacy macOS boot artifact or outsourced development.
T1039detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust principles, and ongoing review of engineering practices that surface anomalous access patterns or insecure share configurations, but does not itself instrument or perform detection of the live T1039 technique.
T1039prevents — A.8.27 mandates security-by-design principles (least privilege, zero-trust/never-trust, defence-in-depth, hardening, secure architecture) that can constrain network-share exposure and access paths, but does not itself enforce or remove the accessible shares an already-compromised host can still reach.
T1040detects — A.8.27 mandates security-oriented design reviews, threat analysis, zero-trust principles, and hardening that surface sniffing risks (e.g. unencrypted protocols, promiscuous mode, traffic mirroring) during architecture and engineering, but does not itself perform ongoing detection of the technique in operation.
T1040prevents — A.8.27 mandates security-by-design principles (defense-in-depth, least privilege, assume-breach, never-trust/always-verify, end-to-end encryption, hardening) that, when applied during architecture and engineering, stop many sniffing vectors (e.g. plaintext creds, weak perimeter reliance, unencrypted requests) before they exist; it does not reach every platform-specific capture method (promiscuous mode on endpoints, cloud mirroring configs, CLI on network devices) so the coverage is a genuine but incomplete slice.
T1041detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust monitoring principles (never trust/always verify, assume breach), and ongoing review of engineering practices against new threats; these surface anomalous exfiltration patterns in C2 channels during design and operation but do not mandate runtime detection mechanisms across all implementations or platforms.
T1041prevents — A.8.27 mandates security-by-design, defense-in-depth, least privilege, zero-trust, end-to-end encryption of requests, and hardening that can block many C2-based exfil paths at design time, but does not guarantee removal of all exfil-capable C2 implementations (especially in outsourced or legacy components)
T1046detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, assume-breach monitoring principles, and regular reviews against new threats, which can surface anomalous network service discovery activity in designed systems but does not mandate or guarantee runtime detection mechanisms across all platforms, entry points, or outsourced development.
T1046prevents — A.8.27 mandates security-by-design, defense-in-depth, least functionality, assume-breach, and hardening that can remove or lock down unnecessary network services (and their discovery vectors) during architecture and engineering; this stops the technique on covered systems but leaves a large remainder (services required for business, post-deployment discovery, outsourced code not fully constrained, and macOS Bonjour/mDNS behaviors)
T1047detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of principles against new threats, which surfaces anomalous or risky use of WMI (e.g. via design review or assume-breach monitoring) but only as a slice of possible detections rather than a dedicated or comprehensive detection mechanism.
T1047prevents — A.8.27 mandates applying security-by-design, least functionality/privilege, default-deny, hardening, and zero-trust principles during architecture and engineering; these can remove or constrain WMI interfaces (e.g. via least functionality or hardened defaults) on some systems, but the technique remains available on standard Windows builds where WMI is required for management.
T1048detects — A.8.27 mandates security-oriented design reviews, threat analysis, zero-trust verification, and ongoing review of engineering principles that surface anomalous exfiltration channels or protocol misuse during architecture and deployment reviews, but this is limited to what the design process itself can observe rather than runtime detection of the technique.
T1048prevents — A.8.27 mandates security-by-design principles (defense-in-depth, least privilege, zero-trust never-trust/always-verify, end-to-end encryption, distrust-external-input, hardening) that can be applied during architecture and engineering to constrain or block many alternate-protocol exfiltration paths, but the control is a process of establishing/applying/reviewing principles rather than a concrete mechanism that stops all such exfiltration (e.g. residual risk in cloud APIs, outsourced code, or sanctioned protocols remains).
T1048.001detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification of requests, and ongoing review of principles against new threats, which surfaces anomalous exfiltration designs or implementations during engineering but does not instrument runtime detection of the technique once deployed.
T1048.001prevents — A.8.27 mandates security-by-design, defense-in-depth, least-privilege, zero-trust, and hardening principles plus design reviews that can stop many symmetric-exfiltration channels from being introduced; it does not guarantee every possible manual symmetric channel (e.g., custom RC4 over HTTP) will be blocked.
T1048.002detects — A.8.27 mandates security-oriented design reviews, threat analysis, and ongoing review of engineering principles to identify vulnerabilities and ensure controls (including those that detect events) are specified; this surfaces the technique in design but does not instrument runtime detection of exfiltration.
T1048.002prevents — A.8.27 mandates security-by-design, defense-in-depth, least-privilege, zero-trust, and hardening principles plus design reviews that can block many exfiltration paths (e.g., by enforcing encrypted channels only to trusted endpoints or denying unnecessary outbound protocols), but does not guarantee prevention of all asymmetric-encrypted non-C2 exfiltration once an adversary has a foothold inside the perimeter.
T1048.003detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification of requests, and ongoing review of principles against new threats; these surface design or configuration choices that enable unencrypted exfiltration (e.g. missing encryption mandates or weak network controls) but do not instrument or observe the runtime technique itself.
T1048.003prevents — A.8.27 mandates security-by-design, defense-in-depth, least functionality, assume-breach, and explicit review of controls (including encryption and data protection) across architecture layers, which constrains the design space so that unencrypted exfiltration channels are less likely to be present; it does not guarantee their universal absence on every possible protocol or implementation.
T1049detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust monitoring principles, and integration of detection-capable controls (e.g. via defence-in-depth and assume-breach), which surfaces anomalous network discovery in flight as part of operational security; this is a genuine but minority slice of the broad technique that spans many unmonitored platforms and native utilities.
T1049prevents — A.8.27 mandates security-by-design principles (least privilege, least functionality, default-deny, zero-trust, hardening) that can remove or restrict the utilities/commands (netstat, lsof, who, CLI show commands) used by T1049, but does not guarantee their removal from every platform or every build, leaving a genuine slice unaddressed.
T1052detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust principles, and ongoing review of engineering practices that surface physical-medium exfiltration risks (e.g., via assume-breach, distrust-external-input, or device-control analysis), but this is limited to what the design/review process can observe in architecture and does not broadly instrument runtime detection of the technique.
T1052prevents — A.8.27 mandates security-by-design, defence-in-depth, least privilege, hardening, zero-trust verification and secure engineering that can block removable-media exfiltration vectors (e.g. via device control, data-loss-prevention architecture, default-deny USB policies) when applied; it does not guarantee those controls are selected or enforced for every air-gapped or physical-medium scenario, leaving a genuine residual slice.
T1052.001detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust principles, and ongoing review of engineering practices that can surface anomalous USB usage or exfiltration vectors during architecture analysis and monitoring design, but does not itself perform or require runtime detection of the technique.
T1052.001prevents — A.8.27 mandates security-by-design, defense-in-depth, least-privilege, hardening, zero-trust, and explicit analysis of controls that can prevent exfiltration (including physical-device and data-leakage vectors); this stops many but not all USB exfil paths (e.g., insider-introduced devices, incomplete hardening, or air-gap exceptions).
T1053detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of engineering principles to identify vulnerabilities and new threats, which can surface abuse of task scheduling in system design or deployment but does not mandate runtime monitoring or anomaly detection of the technique itself.
T1053prevents — A.8.27 mandates applying security-by-design, least privilege, default-deny, fail-secure, zero-trust and hardening principles during architecture and engineering; these constrain how scheduling services are exposed, configured or used for untrusted code, but do not eliminate the legitimate OS scheduling primitives adversaries abuse on all listed platforms.
T1053.002detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust principles, and ongoing review of engineering practices that can surface anomalous or risky use of at for scheduling/persistence during design, implementation, or operational review, but this is limited to what the organization's chosen architecture and review scope elects to instrument or examine.
T1053.002prevents — A.8.27 mandates applying security-by-design, least privilege, default-deny, fail-secure, hardening, and zero-trust principles during architecture and engineering; these directly constrain or remove the at utility, its allow/deny misconfigurations, and its sudo escalation path in new or reviewed systems, but the clause is a process that only reaches what the organization builds or re-engineers, leaving pre-existing, unmanaged, or legacy deployments untouched.
T1053.003detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of engineering principles against new threats; these surface anomalous or risky scheduled tasks (including cron abuse) during design, review or monitoring of the architecture, but only where the organization elects to instrument or review that layer — a chosen slice rather than a bounded remainder.
T1053.003prevents — A.8.27 mandates applying security-by-design, least privilege, default-deny, hardening, and zero-trust principles during architecture and engineering; these can stop cron-based persistence when the principles are translated into hardened defaults, restricted crontab permissions, or removal of unnecessary scheduling services, but the clause only sets a process and does not itself enforce any concrete mechanism, leaving most real-world deployments reachable.
T1053.005detects — A.8.27 mandates security-oriented design reviews, threat analysis, hardening, zero-trust verification and regular review of engineering principles to surface vulnerabilities and new threats; this can detect abuse patterns of Task Scheduler in architecture or code reviews but does not instrument runtime detection of the technique itself.
T1053.005prevents — A.8.27 mandates security-by-design, least privilege, default-deny, hardening, and zero-trust principles that can constrain scheduled-task abuse for persistence/execution when applied to system architecture and engineering, but leaves many implementation-specific abuse vectors (hidden tasks, WMI/schtasks, SYSTEM context) unaddressed as a minority slice.
T1053.006detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust monitoring principles, and regular review of engineering procedures against new threats, which can surface anomalous timer-based scheduling in reviewed/ monitored Linux architectures but does not mandate runtime detection of the technique itself.
T1053.006prevents — A.8.27 mandates security-by-design, defence-in-depth, least privilege, least functionality, hardening, security-oriented design reviews and zero-trust principles that can constrain systemd-timer abuse when applied to Linux service architecture and scheduled-execution paths; this is a genuine but minority slice of the technique's attack surface (most real-world timer abuse occurs via post-compromise file writes that the engineering principles do not themselves stop).
T1053.007detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification of requests, and ongoing review of principles against new threats; these surface anomalous or malicious container orchestration jobs (e.g. via assume-breach or least-privilege violations) in design and operation, but only where the organization's chosen scope and practices include them — a slice, not a bounded remainder.
T1053.007prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, least-functionality, hardening, and zero-trust principles applied throughout the engineering life cycle (including to outsourced development); these directly constrain the ability to introduce or configure malicious/abusable CronJob-style scheduling in container orchestration, but the clause is a process that depends on rigour of implementation and does not guarantee removal of all such mechanisms from every possible cluster or supplier image.
T1055detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of principles against new threats/attack patterns, which surfaces injection risks during architecture and engineering but does not instrument or monitor runtime process behavior.
T1055prevents — A.8.27 mandates applying security-by-design, defence-in-depth, least privilege, least functionality, hardening, security-oriented design reviews, and zero-trust principles (never trust/always verify, strong auth, dynamic access) during architecture and engineering; these can stop many injection vectors from being introduced (e.g. by removing unnecessary APIs, enforcing strict boundaries, or requiring input distrust), but do not guarantee prevention of all platform-specific or sophisticated IPC-based variants that still arise in production code.
T1055.001detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of principles against new threats/attack patterns, which surfaces some DLL injection vectors during architecture and engineering but does not instrument or monitor runtime process behavior to detect live attacks.
T1055.001prevents — A.8.27 mandates applying security-by-design, least privilege, defence-in-depth, assume-breach, distrust-external-input and hardening principles during architecture and engineering; these can stop many (but not all) common vectors for DLL injection such as unsafe process creation, missing sandboxing or weak session controls, yet cannot eliminate every possible in-process memory-corruption or reflective variant that arises from an already-compromised process or from code that still trusts its own address space.
T1055.002detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust monitoring principles, and ongoing review of engineering practices that can surface anomalous injection behaviors in architecture and runtime, but the clause is primarily about secure design/implementation rather than mandating runtime detection mechanisms.
T1055.002prevents — A.8.27 mandates applying security-by-design, defence-in-depth, least privilege, least functionality, assume-breach and hardening principles during architecture and engineering; these can preclude the insecure process/memory behaviours that enable PE injection, but the clause only sets a process and does not guarantee the resulting systems are free of the specific injection vectors.
T1055.003detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of principles against new threats/attack patterns, which surfaces the technique in architecture and code reviews but does not instrument runtime detection of in-process hijacking.
T1055.003prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, least-functionality, hardening, and secure-engineering reviews that can stop the injection vectors and privilege-escalation preconditions of thread hijacking when applied to the affected components; the control is a process that does not guarantee universal application or completeness against every possible implementation, leaving a genuine minority slice unaddressed.
T1055.004detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of principles against new threats/attack patterns, which surfaces APC injection as a known technique during architecture and engineering but does not instrument or monitor runtime execution of the technique itself.
T1055.004prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, least-functionality, hardening, and secure-engineering reviews that can remove or constrain the OS mechanisms and coding patterns used for APC injection when those principles are applied during development; the coverage is only a slice because the clause is a process/governance requirement whose actual preventive effect depends on how rigorously an implementer chooses to apply the listed principles to any given codebase or platform.
T1055.005detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust monitoring principles, and regular review of engineering practices against new threats, which can surface anomalous TLS callback behavior in reviewed/hardened systems but does not mandate runtime detection mechanisms that would catch the technique across the board.
T1055.005prevents — A.8.27 mandates applying security-by-design, defence-in-depth, least-privilege, hardening, security-oriented design reviews, and zero-trust principles that can stop TLS callback injection from being introduced or succeeding in systems built under it, but the clause is a process/guidance control whose effect depends on how rigorously those principles are followed in any given implementation.
T1055.008detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust principles, and ongoing review of engineering practices to identify vulnerabilities and new threats, which can surface ptrace-based injection risks in Linux process architecture and monitoring design but does not itself instrument or perform runtime detection.
T1055.008prevents — A.8.27 mandates applying security-by-design, defence-in-depth, least-privilege, least-functionality, hardening, security-oriented design reviews and zero-trust principles during engineering; these can stop ptrace-based injection vectors in the built system (e.g. by restricting debug/ptrace capabilities, enforcing strict process boundaries or removing unnecessary debug interfaces), but the clause is a process requirement whose coverage still depends on what the implementer actually selects and hardens, leaving a genuine slice of residual Linux ptrace attack surface.
T1055.009detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust monitoring principles, and regular review of engineering practices against new threats; these surface some proc-memory-injection indicators (e.g., anomalous /proc access or ROP patterns) when the architecture explicitly scopes them in, but the clause sets requirements rather than mandating instrumentation depth, leaving large implementation-dependent gaps.
T1055.009prevents — A.8.27 mandates security-by-design, defence-in-depth, least privilege, least functionality, hardening, secure session control, data validation/sanitisation and zero-trust principles that can stop the /proc-based enumeration and memory overwrite at multiple layers; this is genuine but only a slice because the clause is a process that depends on how rigorously those principles are applied to the specific Linux memory-protection mechanisms involved.
T1055.011detects — A.8.27 mandates security-oriented design reviews, threat analysis against known attack patterns, hardening, and ongoing review of engineering principles to surface vulnerabilities; this can detect the design/implementation conditions that enable EWM injection (a known process-injection pattern) before or during development, but does not instrument or monitor running systems for the technique in flight.
T1055.011prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, least-functionality, hardening, and secure-engineering reviews that can eliminate the EWM-injection vector in new or reviewed Windows software (e.g. by avoiding EWM abuse patterns or enforcing stricter memory/execution controls), but does not reach already-deployed vulnerable processes or legacy code.
T1055.012detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust principles, and ongoing review of engineering practices to identify vulnerabilities and combat new threats, which can surface hollowing-like evasion patterns in architecture or code; this is limited to design-time and review activities rather than runtime detection of the live technique.
T1055.012prevents — A.8.27 mandates security-by-design, defence-in-depth, least privilege, assume-breach, hardening, and secure engineering reviews that can stop hollowing from being designed into or left available in the built system; this is a genuine but minority slice of the technique's full attack surface (implementation-time evasion of process-based defenses).
T1055.013detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of principles against new threats/attack patterns, which surfaces the technique in architecture and code review but does not instrument runtime detection of in-flight doppelgänging
T1055.013prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, assume-breach, hardening, and security-oriented design reviews that analyse attack patterns; these directly address the technique's core evasion (TxF-based file-less memory replacement that bypasses monitored APIs), but the control is a set of engineering principles and reviews rather than an enforceable runtime mechanism, leaving residual gaps in implementation rigour and specific TxF mitigations.
T1055.014detects — A.8.27 mandates security-oriented design reviews, threat analysis, hardening, zero-trust monitoring principles, and regular reviews for new threats, which can surface VDSO hijacking indicators in architecture or runtime anomalies, but only as a slice dependent on chosen scope and tooling rather than a broad, guaranteed detection mechanism.
T1055.014prevents — A.8.27 mandates security-by-design, defence-in-depth, least privilege, hardening, assume-breach, and secure engineering reviews that can preclude the specific memory-layout and library-hijacking conditions required for VDSO hijacking on Linux, but these are high-level principles whose concrete application (and therefore coverage of this niche technique) remains implementation-dependent.
T1055.015detects — A.8.27 mandates security-oriented design reviews, threat analysis, hardening, zero-trust principles, and regular review of engineering practices that can surface ListPlanting-like injection vectors during development or architecture reviews, but does not mandate runtime detection, monitoring instrumentation, or post-deployment discovery of the live technique.
T1055.015prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, least-functionality, assume-breach, distrust-external-input and hardening principles plus design reviews that explicitly consider attack patterns; these constrain the surface for ListPlanting (a shatter-attack form of process injection) when applied to UI-component and memory-management architecture, but remain high-level requirements whose concrete effectiveness still depends on implementation rigour and do not eliminate every Windows list-view or message-passing vector.
T1056detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust monitoring principles, and ongoing review of engineering practices that surface anomalous input-capture behaviors (e.g. via assume-breach or never-trust verification), but this is only a slice of possible detection rather than broad coverage of all T1056 variants.
T1056prevents — A.8.27 mandates security-by-design principles (least privilege, distrust external input, fail securely, defence-in-depth, zero-trust “never trust/always verify”, hardening, secure session control, data validation/sanitisation) that stop many input-capture vectors from being introduced; it does not reach all platform-specific hooking or UI-deception implementations, leaving a genuine minority slice unaddressed.
T1056.001detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust monitoring principles, and ongoing review of engineering practices that surface anomalous input-handling or key-capture behaviors during architecture and deployment reviews, but does not itself instrument or run detection against live keylogging.
T1056.001prevents — A.8.27 mandates security-by-design, defense-in-depth, least-privilege, fail-secure, distrust-external-input, hardening, and zero-trust verification that together stop most keylogging vectors (API hooks, registry mods, custom drivers, raw buffer reads) from being introduced or succeeding; it does not reach every possible implementation detail or all platforms (e.g., network-device Modify System Image).
T1056.002detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification of requests, and ongoing review of principles against new threats/attack patterns, which surfaces GUI input capture attempts in reviewed/analyzed systems but does not instrument runtime detection of the technique across all platforms or un-reviewed outsourced code.
T1056.002prevents — A.8.27 mandates security-by-design principles (least privilege, security by default, distrust external input, fail securely, zero-trust verification of every request) plus design reviews and hardening that reach the credential-prompt spoofing vector in the development life cycle, but the clause is silent on runtime UI anti-spoofing or OS-level prompt integrity so a real residual remains
T1056.003detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of engineering principles against new threats; these surface design or implementation anomalies that could enable web portal credential capture (e.g. via code review or assume-breach analysis) but do not instrument or monitor runtime execution of the technique itself.
T1056.003prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, distrust-external-input, hardening, secure session control and design reviews that explicitly target known attack patterns; these close many but not all vectors for an adversary to install credential-capturing code on an external portal (e.g. zero-days, supply-chain compromise of the portal software itself, or post-compromise admin access remain outside the clause's direct reach).
T1056.004detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust monitoring principles, and regular review of engineering practices against new threats, which can surface hooking-based credential theft in reviewed systems or via anomaly detection in hardened/zero-trust architectures, but does not mandate or guarantee runtime detection mechanisms for this technique.
T1056.004prevents — A.8.27 mandates security-by-design principles (least privilege, defence-in-depth, assume-breach, distrust external input, hardening, secure session control, zero-trust verification) that can stop many common hooking vectors before they are coded or deployed, but does not reach every implementation detail (e.g. LD_PRELOAD abuse on Linux or inline hooks in already-compromised processes) and is a process-level requirement rather than an absolute barrier.
T1057detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust monitoring principles, and ongoing review of engineering practices that can surface anomalous process enumeration (e.g. via assume-breach or never-trust behaviors), but this is only a slice of possible detections rather than a dedicated or comprehensive monitoring control.
T1057prevents — A.8.27 mandates security-by-design principles (least privilege, least functionality, defense-in-depth, hardening, assume-breach, distrust-external-input) that can be applied during architecture and engineering to remove or restrict many of the interfaces (cmd/PowerShell/ps/esxcli/show processes, /proc, Native APIs) used by T1057, but does not guarantee their removal from every required platform or process and leaves administrator-level discovery intact.
T1059detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of principles against new threats, which surfaces abuse potential in interpreters during architecture and engineering but does not instrument or monitor runtime execution of the technique itself.
T1059prevents — A.8.27 mandates applying security-by-design, least functionality/privilege, default-deny, fail-secure and zero-trust principles plus hardening and design reviews that can remove or disable many interpreters and constrain their abuse vectors, but cannot eliminate the platform-required interpreters adversaries most target.
T1059.001detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust monitoring principles, and regular reviews against new threats, which can surface anomalous PowerShell usage in designed systems but does not itself instrument or guarantee detection of the technique.
T1059.001prevents — A.8.27 mandates applying security-by-design, least functionality/privilege, hardening, default-deny, and zero-trust principles during architecture and engineering; these can remove or constrain PowerShell where it is not required for business processes, but cannot eliminate it from Windows platforms where it remains an essential OS component, leaving a bounded remainder that adversaries continue to abuse.
T1059.002detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of engineering principles against new threats; these surface AppleScript abuse vectors (e.g. via design review or assume-breach monitoring) in some but not all deployment contexts, as the clause sets principles rather than mandating runtime detection coverage.
T1059.002prevents — A.8.27 mandates applying security-by-design, least functionality/privilege, default-deny, hardening, and zero-trust principles during engineering; these can stop AppleScript abuse vectors (e.g. by removing interpreters, restricting osascript, enforcing strict execution policies) in systems built under the control, but the clause is a process that does not guarantee removal of all platform-default interpreters or block every post-compromise execution path, leaving a genuine minority slice prevented.
T1059.003detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust monitoring principles, and regular review of engineering practices against new threats, which surfaces anomalous command-shell use in designed systems but does not mandate runtime detection mechanisms across all possible Windows deployments or outsourced code.
T1059.003prevents — A.8.27 mandates applying security-by-design, least functionality/privilege, default-deny, hardening, and secure-engineering reviews that can remove or constrain Windows cmd.exe and batch-file interpreters from builds or deployments, stopping the technique from being available; this is only a slice because many production Windows systems legitimately require cmd for administrative and legacy tasks that cannot be fully excised.
T1059.004detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust monitoring principles, and regular review of engineering practices against new threats; this surfaces anomalous shell usage or unsafe shell-related design decisions in some (but not all) cases, especially where telemetry or review scope is set by the organization.
T1059.004prevents — A.8.27 mandates applying security engineering principles (least functionality, least privilege, security by default, hardening, secure design reviews) that can remove or constrain Unix shells from systems where they are not required, directly stopping the technique from being available to run; this is only a slice because many platforms require a shell for legitimate operation and the control is a process rather than a universal mechanism.
T1059.005detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of principles against new threats, which surfaces some VB abuse vectors (e.g. unsafe macro/VBA defaults or unverified external inputs) during engineering but does not instrument runtime detection of the technique itself.
T1059.005prevents — A.8.27 mandates establishing and applying secure engineering principles (including least privilege, security by default, distrust external input, hardening, and secure coding practices for data validation/sanitization and session control) across the SDLC and to outsourced development, which constrains the introduction or enablement of unsafe VB/VBA/VBScript execution paths in custom or integrated systems.
T1059.006detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust monitoring principles, and regular review of engineering practices that surface anomalous or malicious use of interpreters like Python, but only where those practices fall inside the chosen security architecture and monitoring scope.
T1059.006prevents — A.8.27 mandates applying security-by-design, least functionality/privilege, hardening, secure defaults, and distrust-external-input principles during engineering; these can remove or constrain the interpreter or its dangerous built-ins on systems where it is not required, preventing the technique from being available to run.
T1059.007detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of principles against new threats, which surfaces some JS abuse vectors (e.g. via architecture reviews or anomalous execution patterns) but does not instrument or monitor runtime execution of JS scripts across platforms.
T1059.007prevents — A.8.27 mandates security-by-design, least functionality/privilege, hardening, distrust-external-input, secure coding practices (including data validation/sanitisation) and architecture reviews that directly constrain or remove many JS interpreters, execution paths and abuse surfaces across the SDLC, but cannot reach every platform-required JS engine or post-deployment script execution.
T1059.008detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, assume-breach monitoring principles, and regular reviews for new threats, which can surface anomalous CLI use on network devices but does not mandate or guarantee runtime detection coverage of the technique itself.
T1059.008prevents — A.8.27 mandates applying security-by-design, least privilege, default-deny, fail-secure, zero-trust and hardening principles during architecture and engineering; these constrain CLI exposure, permission models and remote access on network devices and therefore stop many (but not all) abuse paths before the technique can run.
T1059.009detects — A.8.27 mandates security-oriented design reviews, threat analysis, zero-trust verification, and ongoing review of engineering principles that surface anomalous or risky API usage patterns in cloud architectures, but does not mandate runtime detection mechanisms or monitoring of actual technique execution.
T1059.009prevents — A.8.27 mandates security-by-design, least privilege, zero-trust, defence-in-depth and hardening principles that, when applied during engineering, constrain or remove many of the architectural paths that would allow unrestricted cloud-API abuse (e.g. overly broad IAM defaults, unauthenticated shells, missing boundary validation).
T1059.010detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust monitoring principles, and regular reviews against new threats, which can surface anomalous use of AHK/AutoIT scripts or compiled payloads when those are treated as part of the threat model or observable behavior in deployed systems.
T1059.010prevents — A.8.27 mandates applying security-by-design, least functionality/privilege, hardening, and secure engineering principles (including distrusting external input and default-deny) during system and software development, which can stop AHK/AutoIT interpreters or script execution from being present or enabled on production Windows systems; this is only a slice because the control is scoped to engineering activities and does not mandate universal removal of these legitimate automation tools from all endpoints.
T1059.011detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust monitoring principles, and regular reviews against new threats, which can surface anomalous Lua execution or embedded interpreter abuse in reviewed systems but does not mandate runtime detection mechanisms across all platforms or entry points.
T1059.011prevents — A.8.27 mandates applying security-by-design, least functionality, default-deny, hardening and secure-engineering reviews that can remove or prohibit unnecessary Lua interpreters from the build or runtime, directly stopping the technique from being available; this is only a slice because many legitimate applications embed Lua and those cannot be removed without breaking functionality.
T1059.012detects — A.8.27 mandates security-oriented design reviews, threat analysis against known attack patterns, hardening, zero-trust verification, and regular review of engineering principles to surface vulnerabilities; this can detect abuse potential of hypervisor CLIs during design/hardening but does not instrument or monitor runtime execution of the technique itself.
T1059.012prevents — A.8.27 mandates applying security-by-design, least functionality/privilege, default-deny, hardening, and zero-trust principles during architecture and engineering; these can remove or lock down hypervisor CLIs (e.g. ESXi esxcli) from guest/admin contexts in new builds, but the control is a process that depends on implementation rigour and does not reach already-deployed systems or residual management interfaces.
T1059.013detects — A.8.27 mandates security-oriented design reviews, threat analysis, and ongoing review of engineering principles to identify vulnerabilities and keep practices current against new threats, which can surface the abuse of container CLIs/APIs during architecture and implementation reviews, but this is limited to the design/engineering phase rather than runtime detection of the technique.
T1059.013prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, least-functionality, hardening, assume-breach and zero-trust principles plus design reviews that, when applied to container platforms, can remove many CLI/API abuse vectors (e.g. by restricting exposed Docker/K8s APIs, enforcing strict authz, removing unnecessary tools, and hardening images), but the clause is a process that depends on implementation rigour and does not guarantee the specific defects are absent.
T1068prevents — Applying least-privilege, fail-secure defaults, and defence-in-depth principles reduces opportunities for privilege-escalation exploits within compromised processes.
T1068detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of principles against new threats/attack patterns, which can surface some exploitable vulnerabilities (especially in architecture or known patterns) before or after they are present, but does not mandate or perform runtime detection of exploitation attempts.
T1069prevents — A.8.27 mandates security-by-design principles (least privilege, zero-trust/never-trust-always-verify, defense-in-depth, hardening) that, when applied during architecture and engineering, constrain the exposure and discoverability of permission groups; this is a genuine but minority slice of the broad, post-compromise discovery techniques named by T1069 across all listed platforms.
T1069.001prevents — A.8.27 mandates security-by-design principles (least privilege, zero-trust, defense-in-depth, secure defaults) plus architecture reviews and hardening that constrain how local groups/permissions are created and exposed, so the reconnaissance technique is blocked on systems built under it; it is only a slice because the control is a process applied during engineering rather than a runtime mechanism that stops every post-deployment enumeration command on every platform.
T1069.002prevents — A.8.27 mandates security-by-design principles (least privilege, zero-trust/never-trust-always-verify, defence-in-depth, hardening) that, when applied during architecture and engineering, constrain how domain groups and permissions are structured and exposed, thereby preventing many discovery vectors; it does not eliminate all enumeration commands or residual paths on Linux/macOS/Windows.
T1069.003detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust principles (assume breach, never trust/always verify, least privilege), and ongoing review of engineering principles against new threats, which surfaces anomalous permission-enumeration activity as part of integrated monitoring and breach-assumption practices, but only as one slice of a broad governance-and-design control rather than dedicated detection of this specific discovery technique.
T1069.003prevents — A.8.27 mandates security-by-design, least privilege, zero-trust, defense-in-depth and secure engineering reviews that, when applied during architecture and implementation, stop many discovery paths for cloud groups/ACLs; residual paths remain because the control is a process applied at build time, not a runtime enforcement that universally blocks all authenticated enumeration APIs.
T1070.003prevents — A.8.27 mandates security-by-design principles (least privilege, fail securely, security by default, hardening, assume-breach, distrust-external-input) that reach command-history protections on some platforms when applied in the SDLC, but leaves the bulk of post-compromise deletion techniques (rm ~/.bash_history, Clear-History, file edits) untouched because they are not design defects prevented by architecture.
T1070.004detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust monitoring principles, and regular review of engineering procedures to identify vulnerabilities and new threats, which can surface anomalous file-deletion activity when it aligns with known attack patterns or integrated controls, but this is limited to what the design/engineering process chooses to instrument rather than broad runtime detection of the technique.
T1070.006prevents — A.8.27 mandates applying security-by-design, defence-in-depth, least functionality/privilege, hardening, and secure engineering principles that include data validation/sanitisation and reviews against known attack patterns; these can stop many timestomping vectors (especially user-level $SI changes and unhardened default behaviours) but do not block all kernel-level or double-timestomping paths on every platform.
T1070.008prevents — A.8.27 mandates security-by-design, defense-in-depth, least-privilege, assume-breach, hardening, and secure engineering reviews that can stop many T1070.008 vectors (e.g. by removing unnecessary mail APIs, enforcing transport rules that preserve logs, or designing systems that distrust and log mailbox-altering commands), but leaves a bounded remainder where the technique can still be executed by sufficiently privileged insiders or via unhardened legacy mail components.
T1070.009detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and regular review of engineering principles against new threats, which surfaces cleanup/persistence-removal activity as anomalous in reviewed architectures but does not instrument or monitor the post-compromise host actions themselves.
T1070.010detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of engineering principles against new threats/attack patterns, which surfaces relocation-based evasion in architecture but does not instrument runtime detection of the post-delivery technique itself.
T1071detects — A.8.27 mandates security-oriented design reviews, threat analysis against known attack patterns, zero-trust verification, and ongoing review of engineering principles to surface deviations; this can detect misuse of application-layer protocols in design or deployment but does not instrument runtime detection of the technique once in use.
T1071prevents — A.8.27 mandates security-by-design, defense-in-depth, least privilege, zero-trust, hardening, and design reviews that can prevent many application-layer protocol abuse patterns (e.g., by enforcing strong auth, end-to-end encryption, distrust of external input, and secure session controls), but leaves residual cases where the protocol is required for legitimate business use and cannot be removed or fully constrained.
T1071.001detects — A.8.27 mandates security-oriented design reviews, threat analysis against known attack patterns, zero-trust verification, and ongoing review of engineering principles to surface new threats; this surfaces the technique in design and during reviews but does not instrument runtime detection of live web-protocol C2 blending with traffic.
T1071.001prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, zero-trust, and hardening principles plus design reviews that, when applied, constrain or block many common T1071.001 implementations (e.g. by enforcing strong auth, input distrust, default-deny, end-to-end encryption, and removal of unnecessary protocols); the remainder is the open set of legitimate web channels an adversary can still abuse without violating those principles.
T1071.003detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification of requests, and ongoing review of principles against new threats, which surfaces anomalous use of mail protocols for C2 during architecture and engineering but does not mandate runtime monitoring or detection mechanisms.
T1071.003prevents — A.8.27 mandates security-by-design principles (defence-in-depth, least privilege, assume-breach, distrust-external-input, zero-trust verification) plus architecture-layer reviews that, when applied to mail-protocol handling, can stop the embedding of C2 in SMTP/IMAP/POP3 fields or messages; this is genuine but only a slice because the clause is a process that depends on implementation rigour and does not itself remove the protocols or block all abuse vectors.
T1071.004detects — A.8.27 mandates security-oriented design reviews, analysis of controls' detection/response capabilities, hardening, zero-trust verification, and regular reviews for new threats, which surfaces anomalous DNS tunneling/beaconing in architecture and engineering but does not mandate runtime monitoring or detection mechanisms.
T1071.004prevents — A.8.27 mandates security-by-design, defense-in-depth, least functionality, assume-breach, and zero-trust principles plus design reviews that can eliminate or harden channels allowing DNS tunneling (e.g. by restricting outbound DNS, enforcing encrypted/verified flows, or removing unnecessary resolvers), but these are high-level engineering practices whose application is not guaranteed to block all common DNS abuse vectors on every platform.
T1071.005detects — A.8.27 mandates security-oriented design reviews, analysis of controls' detection/response capabilities, hardening, zero-trust verification, and regular reviews for new threats; this surfaces anomalous pub/sub usage or broker abuse in reviewed systems but does not instrument runtime detection of the technique itself.
T1071.005prevents — A.8.27 mandates security-by-design, defence-in-depth, least functionality, assume-breach, distrust-external-input and zero-trust principles plus architecture reviews that can eliminate or harden pub/sub broker configurations, topic ACLs, authentication and encryption so the technique cannot run, but these are optional principles applied where the organisation chooses rather than a universal mechanism that stops all abuse of MQTT/XMPP/AMQP/STOMP.
T1072detects — A.8.27 mandates security-oriented design reviews, threat analysis, and ongoing review of engineering principles to identify vulnerabilities and keep up with new threats; this surfaces design or configuration weaknesses that would enable T1072 abuse (e.g. overly broad admin access to deployment tools), but does not instrument or monitor runtime use of those tools.
T1072prevents — A.8.27 mandates security-by-design, defense-in-depth, least-privilege, zero-trust, hardening, and secure engineering reviews that reduce the attack surface and privilege model of deployment tools, making unauthorized access and RCE harder to achieve; this is a genuine but minority slice of the technique (the remainder is post-compromise abuse of legitimately granted admin access to the tool itself).
T1074detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust monitoring principles, and regular review of engineering practices against new threats, which can surface anomalous staging activity when it deviates from secure architecture baselines, but this is indirect, scope-dependent governance rather than dedicated detection instrumentation.
T1074.001detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust monitoring principles, and ongoing review of engineering practices that surface anomalous staging behaviors (e.g. via assume-breach or never-trust verification), but only where those practices fall inside the chosen security architecture and monitoring scope; it does not itself instrument or guarantee detection of local data staging.
T1074.001prevents — A.8.27 mandates security-by-design principles (least privilege, default-deny, zero-trust verification, hardening, distrust-external-input) that can stop many common staging paths when applied in the SDLC, but leaves open-ended residual cases (e.g., legitimate admin tools, already-breached hosts, or post-compromise use of native shells) that the control does not reach.
T1074.002detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust monitoring principles, and regular review of engineering practices against new threats, which surfaces anomalous staging activity when it falls inside the chosen architecture and telemetry scope, but the clause itself sets requirements rather than mandating specific detection instrumentation.
T1078prevents — A.8.27 mandates security-by-design principles (least privilege, zero-trust/never-trust-always-verify, defence-in-depth, secure authentication, IAM integration, hardening) that directly constrain credential abuse vectors when applied; this is a genuine but minority slice of T1078 because the control is a process that sets and reviews principles rather than a universal mechanism that stops all credential compromise or inactive-account reuse.
T1078.001detects — A.8.27 mandates security-oriented design reviews, threat analysis, and ongoing review of principles to identify vulnerabilities including default accounts and insecure defaults, but this is limited to the engineering and review process rather than runtime detection of the technique in operation.
T1078.001prevents — A.8.27 mandates security-by-design, hardening, least-privilege, default-deny, zero-trust and secure-engineering reviews that catch and eliminate many default accounts/passwords/keys during architecture, implementation and outsourced development; the named remainder is post-deployment defaults (e.g. newly-integrated vpxuser, factory appliances not yet hardened, or legacy components) that the clause does not reach.
T1078.002detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and regular review of principles to surface new threats/vulnerabilities in architecture and engineering; this can detect design or implementation flaws enabling domain account abuse (e.g. weak auth, missing least-privilege), but does not instrument runtime detection of the technique itself.
T1078.002prevents — A.8.27 mandates security-by-design principles (least privilege, zero-trust/never-trust-always-verify, defense-in-depth, secure authentication, hardening, and integrated controls) that directly constrain credential abuse and domain-account compromise vectors when applied during engineering; this is a genuine but minority slice of the technique because the control is a process that only reaches systems built under it and does not block post-deployment credential dumping or reuse on existing domain accounts.
T1078.003detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of principles to surface vulnerabilities and anomalous access patterns (including local-account abuse), but this is limited to what the engineering process and architecture choose to instrument rather than broad runtime detection of the technique.
T1078.003prevents — A.8.27 mandates applying security-by-design, least privilege, default-deny, zero-trust, hardening, and secure authentication principles during engineering, which can stop many local-account abuse paths (weak defaults, over-privileged service accounts, password reuse, perimeter-only trust); it does not reach every local-account creation or credential-harvesting vector on every platform.
T1078.004prevents — A.8.27 mandates security-by-design, zero-trust, least-privilege, defense-in-depth and hardening principles that, when applied during engineering, stop many of the misconfigurations, over-privileged defaults, weak credential handling and missing verification steps that enable T1078.004; it does not itself stop brute-force, phishing or post-compromise credential creation, which sit outside the engineering-time scope.
T1080detects — A.8.27 mandates security-oriented design reviews to identify vulnerabilities, hardening, and ongoing review of principles against new threats/attack patterns, which can surface tainted-content risks in shared-storage designs or code repositories, but does not itself perform or require runtime/operational detection of the technique once it occurs.
T1080prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, hardening, secure defaults, distrust-external-input and zero-trust principles plus design reviews that surface tainted-content risks; these constrain the technique in architected systems but do not stop an adversary from adding malicious content to an already-shared repository or drive.
T1082detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust monitoring principles, and regular review of engineering procedures to identify new threats; this surfaces anomalous discovery behaviors (e.g. via systemsetup, esxcli, or privileged API calls) when they deviate from expected patterns, but only where the organization has chosen to instrument those layers.
T1082prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, least-functionality, hardening, and zero-trust principles that can stop many common discovery vectors (e.g. by removing unnecessary CLI tools, enforcing strict least-privilege on APIs, or hardening defaults), but leaves a bounded remainder (privileged local commands, cloud metadata APIs reachable after initial access, and reconnaissance that occurs before any engineered controls are present).
T1083detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust principles, least privilege, and ongoing review of engineering practices that surface anomalous discovery behaviors or insecure file-system exposure during architecture and deployment reviews, but this is limited to what the design/engineering process itself inspects rather than runtime detection of the technique.
T1083prevents — A.8.27 mandates security-by-design principles (least privilege, least functionality, default-deny, zero-trust “never trust/always verify”, hardening) that can constrain the commands, permissions and default exposures adversaries rely on to enumerate files/directories, but does not eliminate the technique outright on any platform.
T1087prevents — A.8.27 mandates security-by-design principles (least privilege, zero-trust/never-trust, defense-in-depth, hardening, secure defaults) that, when applied during architecture and engineering, constrain many common discovery vectors (e.g., overly permissive IAM listings, misconfigured interfaces, default commands, external-input leaks); this is genuine but only a slice because the technique can still succeed post-compromise via living-off-the-land binaries, local file searches, or already-granted legitimate queries that the principles do not universally eliminate.
T1087.002detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust monitoring principles, and regular review of engineering practices that surface anomalous account enumeration; this detects the technique in some architectural contexts but depends on what the organization chooses to instrument and review.
T1087.002prevents — A.8.27 mandates security-by-design principles (least privilege, zero-trust never-trust/always-verify, defence-in-depth, hardening, security architecture integration) that can constrain discovery techniques when applied to IAM and access-control layers, but the control is a process-oriented requirement on engineering practices rather than a concrete mechanism that stops enumeration commands or LDAP queries on deployed systems.
T1087.003prevents — A.8.27 mandates security-by-design principles (least privilege, zero-trust/never-trust-always-verify, defence-in-depth, hardening, security architecture integration) that reach authentication, authorization and data-access controls capable of blocking unauthenticated or over-privileged enumeration of GALs and directories; this is a genuine but minority slice of the technique because the control is a process that sets requirements rather than a concrete mechanism that closes every implementation path (e.g. legacy protocols, service accounts, or insider abuse after valid auth).
T1087.004prevents — A.8.27 mandates security-by-design, least-privilege, zero-trust, and hardening principles that, when applied during engineering, constrain the IAM surfaces and default permissions adversaries enumerate with these commands; this is a genuine but minority slice of the technique (the dominant remainder is post-compromise use of already-granted credentials against production IAM APIs).
T1090detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust monitoring principles, and regular review of engineering practices to identify vulnerabilities and new threats, which can surface proxy-based C2 patterns during architecture review or deployment but does not mandate runtime detection mechanisms across all platforms or traffic.
T1090prevents — A.8.27 mandates applying security-by-design, defence-in-depth, least privilege, zero-trust/never-trust-always-verify, distrust-external-input and hardening principles during architecture and engineering; these directly constrain or remove many proxy-based C2 paths (e.g. by enforcing strong auth, dynamic access control, end-to-end encryption and default-deny at design time), but leave residual cases (e.g. proxies inside already-trusted boundaries, CDN routing abuse, or post-deployment misconfigurations) unaddressed.
T1090.001detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification of requests, and ongoing review of principles against new threats, which surfaces anomalous internal proxying or C2 redirection patterns during architecture, deployment and monitoring reviews, but only for systems built or reviewed under the control (not legacy or un-reviewed compromised hosts).
T1090.001prevents — A.8.27 mandates applying security-by-design, defence-in-depth, least-privilege, zero-trust, and hardening principles plus security-oriented design reviews that can preclude the architectural conditions (e.g. overly permissive internal routing, unverified lateral paths, missing segmentation) allowing internal proxies for C2, but does not guarantee their absence in every implementation.
T1090.002detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification of requests, and ongoing review of principles against new threats/attack patterns, which surfaces anomalous proxy usage or external redirection in architecture and deployment but does not mandate runtime monitoring or anomaly detection mechanisms.
T1090.002prevents — A.8.27 mandates security-by-design principles (defense-in-depth, least privilege, zero-trust/never-trust-always-verify, assume-breach, hardening, and explicit analysis of controls that prevent events) which, when applied during architecture and engineering, can block many classes of external-proxy C2 by design (e.g. strict egress filtering, mutual TLS, dynamic access controls, distrust of external input); it does not guarantee prevention of every implementation or every compromised external relay, leaving a genuine minority slice prevented.
T1090.003detects — A.8.27 mandates security-oriented design reviews, threat analysis, zero-trust verification, and ongoing review of engineering principles against new threats/attack patterns, which surfaces some multi-hop proxy techniques (especially those relying on known patterns, boundary bridging, or anomalous internal routing) but does not instrument or monitor runtime traffic/behavior to detect live instances.
T1090.003prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, zero-trust and hardening principles that can stop multi-hop proxy chains from being established or traversed inside the defended environment (e.g. by enforcing end-to-end encryption, never-trust verification, dynamic least-privilege access, and secure architecture reviews), but leaves open the external Tor/ORB/P2P networks and pre-compromised devices the adversary may already control before traffic reaches the boundary.
T1090.004prevents — A.8.27 mandates security-by-design, defence-in-depth, assume-breach, least-privilege, distrust-external-input and zero-trust principles (never trust/always verify, end-to-end encryption, contextual authz) that, when applied to network and application layers, can block domain-fronting routes; the control is a high-level engineering process, not a concrete mechanism, so only a slice of implementations actually close the SNI/Host mismatch.
T1091detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of principles against new threats; these surface design or implementation gaps (e.g., unsafe Autorun, unhardened USB handling, missing firmware checks) that enable T1091 but do not instrument runtime detection of the technique itself.
T1091prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, hardening, distrust-external-input and zero-trust principles that reach autorun disabling, removable-media controls and input sanitisation, but leaves a bounded remainder (air-gapped networks, firmware-level media modification, and manual user execution of disguised files) untouched by the engineering principles alone.
T1092prevents — A.8.27 mandates security-by-design, defense-in-depth, least privilege, zero-trust, hardening, and secure engineering that can block many removable-media C2 vectors (e.g. by distrusting external input, enforcing strong auth on mounts, or removing unnecessary media support), but leaves a bounded remainder where air-gapped systems still require physical media transfer and the control cannot stop an already-compromised pair from relaying commands.
T1095detects — A.8.27 mandates security-oriented design reviews, threat analysis, hardening, zero-trust verification, and ongoing review of engineering principles to surface vulnerabilities and anomalous designs; this can detect the insecure choice or implementation of non-application-layer protocols (e.g. ICMP, VMCI) during architecture and review stages, but does not itself instrument runtime detection of their use in C2 traffic.
T1095prevents — A.8.27 mandates security-by-design, defense-in-depth, least functionality, assume-breach, and hardening principles plus explicit analysis of required controls (including network-layer ones) and review against known attack patterns; this constrains many non-application-layer C2 choices (e.g., by removing unnecessary protocols, enforcing default-deny, or requiring end-to-end encryption and verification) but leaves residual cases such as required protocols (ICMP, VMCI) or sophisticated abuse that still evades the architecture.
T1098detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of engineering principles to identify vulnerabilities and new threats, which can surface account manipulation patterns in architecture or code but does not instrument runtime detection of the post-compromise technique itself.
T1098prevents — A.8.27 mandates applying security-by-design, least privilege, default-deny, zero-trust, hardening, and secure credential/session controls throughout the engineering lifecycle, which stops many classes of account manipulation (e.g., weak defaults, over-privileged accounts, missing MFA, insecure credential storage) from being introduced; it does not stop post-compromise manipulation once an adversary already holds sufficient permissions on a deployed system.
T1098.001detects — A.8.27 mandates security-oriented design reviews, threat analysis, and ongoing review of engineering principles to identify vulnerabilities and ensure controls (including those that detect events) are specified; this surfaces design or procedural gaps that would allow T1098.001 but does not operationally detect the technique in flight or after the fact.
T1098.001prevents — A.8.27 mandates applying security-by-design, least privilege, zero-trust, defence-in-depth, fail-secure and hardening principles plus security-oriented design reviews during engineering; these directly constrain the architectural decisions and permission models that allow an adversary with initial access to add persistent credentials, but the clause is a process requirement whose effectiveness still depends on how rigorously those principles are implemented and reviewed.
T1098.002detects — A.8.27 mandates security-oriented design reviews, threat analysis, and ongoing review of engineering principles to identify vulnerabilities and new threats; this surfaces the insecure permission-granting patterns that enable T1098.002 but does not instrument runtime detection of the technique itself.
T1098.002prevents — A.8.27 mandates security-by-design, least privilege, zero-trust, defence-in-depth and explicit review of controls (including IAM) during architecture and engineering; this directly constrains the ability of an adversary (or compromised account) to grant broad additional mailbox/folder delegations that violate those principles, but the clause is a process requirement whose coverage depends on how rigorously those principles are applied to email/collaboration systems and on post-compromise abuse of already-authorized sessions, leaving a genuine minority slice prevented.
T1098.003detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification of requests, and regular review of engineering principles to identify vulnerabilities and new threats, which can surface anomalous role/permission additions during design, review or monitoring of IAM architecture; this is a genuine but minority slice of the post-compromise technique that occurs in runtime IAM modifications across IaaS/SaaS platforms.
T1098.003prevents — A.8.27 mandates security-by-design, least privilege, zero-trust, defence-in-depth and secure engineering reviews that, when applied to IAM and role design, stop many patterns of adding excessive cloud roles; it does not reach every implementation detail or post-deployment abuse of already-granted permissions, leaving a genuine minority slice prevented.
T1098.004prevents — A.8.27 mandates applying security-by-design, least privilege, defence-in-depth, fail-secure, hardening, and zero-trust principles (including strong auth and never-trust/always-verify) during engineering; these directly constrain the attack surface and configuration paths the technique relies on, but only where the principles are actually followed in the SSH/auth implementation, leaving a large slice of deployed systems untouched.
T1098.005detects — A.8.27 mandates security-oriented design reviews, threat analysis, zero-trust verification of requests, and ongoing review of engineering principles to surface vulnerabilities and new threats; this can detect risky device-registration patterns in MFA/Intune/conditional-access designs or supplier practices, but only as a minority slice of the technique's post-compromise execution paths.
T1098.005prevents — A.8.27 mandates security-by-design, zero-trust, least-privilege, never-trust/always-verify, and hardening principles that, when applied during engineering, constrain or block insecure device-registration paths (e.g. weak self-enrollment, perimeter-only trust, missing contextual authz), but the control is a set of principles and reviews rather than an enforceable mechanism that stops every registration technique on every platform or legacy MFA/Intune deployment.
T1098.006detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and regular review of engineering principles to identify vulnerabilities and new threats; this surfaces malicious role/permission additions in container clusters as anomalous or non-compliant during reviews or threat analysis, but only for engineered/observed systems and not real-time runtime detection of the post-compromise technique itself.
T1098.006prevents — A.8.27 mandates security-by-design, least privilege, defence-in-depth, zero-trust and secure engineering principles (including explicit review against known attack patterns) that, when applied during architecture and implementation, stop many paths to unauthorized role-binding or ABAC-policy changes; it does not reach runtime enforcement, all deployment configurations, or post-compromise account modification on every platform.
T1098.007detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification of requests, and ongoing review of engineering principles against new threats, which can surface anomalous group-addition activity (e.g. via design review or assume-breach monitoring) but only as a minority slice of the post-compromise technique on Windows/Linux/macOS platforms.
T1098.007prevents — A.8.27 mandates applying security-by-design, least-privilege, defence-in-depth, fail-securely and zero-trust principles (including dynamic least-privilege access control) during architecture and engineering; these constrain the design space in which an adversary could usefully add groups for persistence, but do not stop the post-compromise administrative command (net localgroup, usermod, etc.) itself.
T1102detects — A.8.27 mandates security-oriented design reviews, threat analysis, and ongoing review of engineering principles to identify vulnerabilities and new threats, which can surface the use of external web services for C2 as a design or operational risk, but this is limited to what is caught in reviews rather than continuous runtime detection of the technique.
T1102prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, zero-trust, distrust-external-input and hardening principles that, when applied during engineering, constrain or block many common T1102 implementations (e.g. by enforcing strong auth, dynamic access control, end-to-end encryption validation and secure session controls on outbound web-service use); residual coverage remains partial because the clause only sets principles and reviews, does not mandate specific blocking mechanisms for every legitimate web-service channel an adversary might abuse, and cannot prevent post-compromise use of already-approved services.
T1102.001detects — A.8.27 mandates security-oriented design reviews, threat analysis, and ongoing review of engineering principles to identify vulnerabilities and new threats, which can surface dead-drop resolver patterns in system design or supplier code but does not instrument runtime detection of the live technique.
T1102.001prevents — A.8.27 mandates security-by-design, defence-in-depth, least privilege, zero-trust verification, distrust-external-input, hardening, and design reviews that explicitly consider known attack patterns; these principles, when applied during development, stop many classes of dead-drop resolver implant by removing the necessary outbound C2 channel or forcing stronger validation/authentication before following redirects.
T1102.002detects — A.8.27 mandates security-oriented design reviews, threat analysis, zero-trust verification, assume-breach posture, and ongoing review of engineering principles that surface anomalous or risky external web-service usage patterns as potential C2, but only where those principles are actually applied in the organization's architecture and reviews.
T1102.002prevents — A.8.27 mandates security-by-design, defence-in-depth, least privilege, zero-trust verification, distrust-external-input, hardening and explicit review against known attack patterns; these directly constrain the design and deployment choices that would otherwise allow bidirectional C2 over legitimate web services, but the clause is a process/principle that depends on how rigorously it is applied and does not eliminate every possible legitimate-service channel an implementer might still permit.
T1102.003detects — A.8.27 mandates security-oriented design reviews, threat analysis, zero-trust verification, assume-breach posture, and ongoing review of engineering principles that surface anomalous or unverified external web-service C2 patterns; this is genuine but only a slice of the technique's post-compromise runtime behavior on already-breached hosts.
T1102.003prevents — A.8.27 mandates security-by-design, defence-in-depth, least privilege, assume-breach, zero-trust, distrust-external-input and hardening principles that, when applied during engineering, constrain or block many common one-way Web-service C2 patterns (e.g. by enforcing strong auth, dynamic access control, end-to-end encryption validation and network-perimeter independence); residual coverage is only partial because the control is a set of high-level principles whose concrete effectiveness still depends on which specific architecture and controls the implementer actually chooses.
T1104detects — A.8.27 mandates security-oriented design reviews, threat analysis, and zero-trust monitoring principles that surface multi-stage C2 designs or anomalous staged callbacks during architecture review and runtime verification, but only where those practices are scoped in and applied to the relevant systems.
T1104prevents — A.8.27 mandates security-by-design, defense-in-depth, least privilege, assume-breach, zero-trust, and hardening principles that can stop multi-stage C2 loaders from being introduced or from functioning across stages, but the clause is a process/guidance control whose effect depends on how rigorously those principles are applied in each development project.
T1105detects — A.8.27 mandates security-oriented design reviews, threat analysis, hardening, zero-trust monitoring principles, and regular review of engineering practices that surface anomalous ingress activity (e.g. unexpected tool downloads or external transfers), but this is limited to what the resulting architecture chooses to instrument rather than a dedicated detection mechanism for the technique.
T1105prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, zero-trust, hardening, and secure-engineering reviews that can block many ingress vectors (e.g. default-deny, distrust-external-input, strong auth on sync services, removal of unnecessary download utilities), but leaves residual paths on required tools/protocols and post-compromise lateral movement inside the perimeter.
T1106prevents — A.8.27 mandates security-by-design, defence-in-depth, least privilege, least functionality, hardening, and secure engineering principles (including secure session control, input sanitisation, and distrust of external input) that are applied across the SDLC; these directly constrain or remove many of the higher-level, library-mediated, and framework-mediated routes to native API abuse (e.g. unsafe CreateProcess/fork usage or unhardened defaults), but leave a bounded remainder of direct syscalls, assembly-level evasion, and kernel/boot-time behaviours that the clause does not reach.
T1110detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, strong authentication, and ongoing review of principles against new threats; these surface brute-force attempts or weak designs enabling them in the engineering process or via monitoring architecture, but do not require or guarantee runtime detection mechanisms for all brute-force activity across all platforms and vectors.
T1110prevents — A.8.27 mandates security-by-design principles (least privilege, default-deny, fail-secure, never-trust/always-verify, MFA, dynamic access control, hardening) that directly stop many brute-force vectors (online guessing, weak/default creds, perimeter-only reliance); it does not reach offline hash cracking, all legacy protocols, or every possible credential store.
T1110.001detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust principles (never trust/always verify, assume breach), and ongoing review of engineering principles against new threats; these surface password-guessing vectors during design and in deployment monitoring but do not mandate runtime detection mechanisms across all targeted services or platforms.
T1110.001prevents — A.8.27 mandates security-by-design principles (least privilege, default-deny, fail-securely, never-trust/always-verify, MFA, secure authentication, session controls) that directly stop password-guessing from succeeding; the remainder is legacy protocols, exempted accounts, and outsourced development where the principles are only required to be flowed down rather than guaranteed.
T1110.002detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of principles against new threats; these surface design or configuration weaknesses that enable offline cracking (e.g., weak hashes, insufficient key derivation) but do not broadly detect the offline cracking technique itself once hashes are obtained.
T1110.002prevents — A.8.27 mandates security-by-design principles (least privilege, fail securely, zero-trust “never trust/always verify”, strong MFA, end-to-end encryption of requests) that directly raise the bar for offline hash cracking to succeed in producing usable plaintext credentials; this is genuine but only a slice because the technique’s core (obtaining hashes via T1003/T1602 then cracking offline on adversary systems) is not itself stopped by architecture or engineering choices.
T1110.003detects — A.8.27 mandates security-oriented design reviews, threat analysis, zero-trust verification, strong authentication, and regular reviews of engineering principles that surface password-spraying risks in auth design and implementation, but does not mandate runtime detection mechanisms or monitoring of the technique in flight.
T1110.003prevents — A.8.27 mandates security-by-design principles (least privilege, default-deny, fail-securely, never-trust/always-verify, strong MFA, end-to-end encryption of requests) that directly stop many password-spraying vectors when applied; the remainder is legacy protocols, exempted accounts, and implementations that do not fully enforce those principles.
T1110.004detects — A.8.27 mandates security-oriented design reviews, threat analysis, zero-trust verification, and ongoing review of engineering principles to identify vulnerabilities and new threats; this surfaces credential-stuffing risks in authentication design (e.g. via weak reuse patterns or insufficient MFA) but does not instrument runtime detection of the technique itself.
T1110.004prevents — A.8.27 mandates establishing and applying security engineering principles (including least privilege, security by default, fail securely, strong/MFA authentication, never-trust/always-verify, and design reviews against attack patterns) that directly constrain credential-stuffing vectors when followed; this is a genuine but minority slice because the control is a process of principle-setting and review rather than an always-on mechanism that stops every reuse-of-breached-creds attempt.
T1111detects — A.8.27 mandates security-oriented design reviews, threat analysis against known attack patterns, zero-trust verification, and ongoing review of principles to combat new threats, which surfaces MFA-interception risks during engineering but does not instrument runtime detection of the technique itself.
T1111prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, zero-trust, strong authentication (incl. MFA per 8.5), distrust-external-input and hardening principles that, when applied during engineering, stop many interception vectors (e.g. by requiring end-to-end encryption, device-bound auth, or non-replayable MFA) but cannot block all post-design runtime techniques such as keyloggers on already-compromised endpoints or upstream SMS-provider compromise.
T1112detects — A.8.27 mandates security-oriented design reviews, threat analysis, and ongoing review of engineering principles to identify vulnerabilities and ensure controls (including monitoring) are specified; this surfaces Registry-modification patterns as part of defense-evasion or persistence design flaws, but only as a slice of the technique's post-deployment runtime use.
T1112prevents — A.8.27 mandates security-by-design, defense-in-depth, least-privilege, fail-securely, hardening, and zero-trust principles that can stop many classes of Registry abuse (e.g., by enforcing proper ACLs, removing unnecessary remote-registry exposure, or blocking common persistence/impairment patterns at design time), but leaves a genuine remainder of post-design, runtime, or configuration-specific Registry modifications that the engineering principles do not themselves block.
T1113detects — A.8.27 mandates security-oriented design reviews, threat analysis, and monitoring for new attack patterns plus zero-trust/least-privilege principles that surface anomalous screen-capture behaviors when they align with the reviewed architecture and threat model, but this is only a slice of possible post-compromise usage rather than broad runtime detection.
T1114detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust monitoring principles, and ongoing review of engineering practices that surface anomalous email collection patterns (e.g. via assume-breach, never-trust, or integrated controls), but this is limited to what the architecture chooses to instrument rather than broad detection of the technique.
T1114.001detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust monitoring principles, and ongoing review of engineering practices that surface anomalous access or collection behaviors (e.g., via assume-breach and never-trust verification), but this is scoped only to what the chosen architecture and reviews explicitly instrument rather than broadly detecting local email file collection post-compromise.
T1114.001prevents — A.8.27 mandates security-by-design, defense-in-depth, least privilege, zero-trust, hardening, and secure engineering that can integrate controls (e.g. encryption, access management, data protection) to stop local email files from being collectible; this reaches only a slice because the control is a process/principle applied during development rather than a universal runtime mechanism that stops every local collection path on every deployed system.
T1114.002detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of principles to surface vulnerabilities and anomalous access patterns (including credentialed Exchange/Office 365 collection), but this is limited to what the engineering process and architecture explicitly cover rather than broad runtime detection of the technique.
T1114.002prevents — A.8.27 mandates security-by-design, zero-trust, least-privilege, never-trust/always-verify, end-to-end encryption and strong authentication principles that, when applied during engineering, stop many credential-based or perimeter-only paths to remote Exchange/Office 365 collection; it does not reach every implementation detail or every already-deployed system, leaving a genuine minority slice.
T1114.003detects — A.8.27 mandates security-oriented design reviews, threat analysis against known attack patterns, and ongoing review of engineering principles to combat new threats, which can surface the insecure design allowing unrestricted forwarding rules; this is a genuine but minority slice of the class (most instances arise at runtime from valid credentials, hidden MAPI rules, or admin transport rules rather than during initial architecture/engineering).
T1114.003prevents — A.8.27 mandates security-by-design, defense-in-depth, least-privilege, assume-breach, and zero-trust principles plus design reviews that explicitly address authentication, access control, and data-handling rules; these constrain the creation or scope of forwarding rules in properly engineered mail systems, but the control is a process applied during development rather than an enforcement mechanism that stops any authenticated user or admin from creating a rule at runtime.
T1115detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust monitoring principles, and ongoing review for new threats, which can surface anomalous clipboard-access patterns in monitored systems but does not require or guarantee runtime detection of the technique itself.
T1119detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust monitoring principles, and ongoing review of engineering practices that surface anomalous collection behaviors (e.g. via assume-breach, never-trust, and integrated controls), but only where those are designed into the architecture and do not cover all post-compromise automated collection methods on every platform.
T1119prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, zero-trust and hardening principles that can stop many automated-collection vectors (e.g. by restricting interpreters, enforcing dynamic least-privilege, distrusting external input, and removing unnecessary collection surfaces), but leaves open-ended residual paths that still allow the technique once the adversary is established.
T1123detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of engineering principles that surface anomalous or insecure audio-capture mechanisms during architecture and implementation reviews, but this is limited to what the design process itself can observe rather than runtime detection of the technique.
T1123prevents — A.8.27 mandates security-by-design, least privilege, default-deny, hardening, and zero-trust principles that can constrain API access and peripheral use at design time, but does not guarantee runtime enforcement against all post-compromise or application-level capture vectors on Linux/macOS/Windows.
T1125detects — A.8.27 mandates security-oriented design reviews, threat analysis, hardening, zero-trust monitoring principles, and regular reviews that surface attack patterns including unauthorized peripheral use, but does not itself instrument or run detection.
T1125prevents — A.8.27 mandates security-by-design, least privilege, zero-trust, hardening, and secure engineering principles (including distrust-external-input and integrated controls) that can be applied to restrict unauthorized API access to cameras/webcams, but does not guarantee prevention of all malware that abuses legitimate OS/application APIs after initial access.
T1127detects — A.8.27 mandates security-oriented design reviews, analysis of controls' detection capabilities, hardening, and ongoing review of principles against new threats/attack patterns, which surfaces the abuse of trusted developer utilities as a design or implementation vulnerability
T1127prevents — A.8.27 mandates security-by-design, defence-in-depth, least functionality/privilege, hardening, and design reviews that analyse attack patterns and integrate controls; these directly constrain the class of signed-trusted-developer-utilities that can proxy arbitrary code, but the control is a process that depends on rigour of application and does not guarantee removal of every such utility (especially those required for legitimate development).
T1127.001detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of engineering principles against new threats/attack patterns, which surfaces anomalous or risky use of build tools like MSBuild for inline code execution in a minority of cases (e.g., during secure SDLC reviews or assume-breach analysis) but does not instrument or monitor runtime execution.
T1127.001prevents — A.8.27 mandates security-by-design, least functionality/privilege, hardening, security-oriented design reviews, and distrust of external input across the engineering lifecycle; this directly constrains unsafe build-tool features such as MSBuild inline tasks when those principles are applied during development or outsourcing, but the control is a process that depends on implementation rigour and does not universally eliminate the technique on already-deployed systems.
T1127.002detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of engineering principles against new threats/attack patterns, which can surface ClickOnce abuse vectors in custom or reviewed systems but does not instrument runtime detection of the technique itself.
T1127.002prevents — A.8.27 mandates applying security-by-design, least privilege, default-deny, fail-securely, distrust-external-input, hardening, and zero-trust principles during architecture and engineering; these directly constrain the trusted-utility proxy, limited-permission ClickOnce abuse, and startup-folder persistence vectors named in the technique, but the clause is a process requirement whose coverage still depends on how rigorously those principles are instantiated in any given build or deployment.
T1127.003detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and regular review of engineering principles against new threats; these surface the abuse of JamPlus as a build tool for malicious .jam execution during design/implementation analysis, but only where the organization has explicitly included such developer tooling in its reviewed architecture and threat models.
T1127.003prevents — A.8.27 mandates security-by-design, least functionality, hardening, and secure engineering principles (including analysis of controls and threat patterns) that can be applied to development tooling and build processes, thereby preventing many instances of JamPlus abuse for malicious script proxying; it does not reach every possible deployment or outsourced build environment.
T1129detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of engineering principles against new threats, which can surface risky module-loading patterns (e.g. arbitrary paths, dlopen/LoadLibrary misuse) during development or architecture review, but does not instrument or monitor runtime execution of the technique on deployed systems.
T1129prevents — A.8.27 mandates applying security-by-design, least privilege, least functionality, hardening, distrust-external-input, and secure engineering principles (including secure session control, data validation/sanitization, and architecture-layer integration) during development and outsourced builds; this stops many unsafe module-loading patterns from being introduced in custom code or supplier deliverables, but leaves a bounded remainder for third-party platform loaders, OS APIs (dlopen/LoadLibrary), and post-deployment runtime abuse that the clause does not reach.
T1132detects — A.8.27 mandates security-oriented design reviews, analysis of controls' detection capabilities, and ongoing review of principles against new threats/attack patterns, which surfaces encoding as a known C2 obfuscation technique in architecture and reviews; this is a genuine but minority slice of the class (design-time detection of the pattern, not runtime detection of encoded C2 traffic).
T1132prevents — A.8.27 mandates security-by-design principles (defence-in-depth, assume-breach, distrust-external-input, least-functionality, hardening, security-oriented design reviews) that reach a slice of T1132 by pushing for input validation/sanitisation, protocol-aware encoding scrutiny and removal of unnecessary encoding/compression functions, but cannot block all standard encodings (ASCII/Unicode/Base64) that remain protocol-compliant and useful for C2.
T1132.001detects — A.8.27 mandates security-oriented design reviews, analysis of controls' detection capabilities, hardening, and ongoing review for new threats, which surfaces encoding-based C2 evasion in architecture and engineering but does not itself instrument or perform runtime detection of the realized technique.
T1132.001prevents — A.8.27 mandates security-by-design principles (defence-in-depth, least functionality, distrust external input, assume-breach, hardening, security-oriented design reviews) that reach a slice of standard-encoding C2 (e.g. by rejecting or sanitising non-standard payloads or by limiting protocol surface), but the clause does not mandate or design any concrete mechanism that stops an adversary from using a protocol-compliant encoding such as Base64 inside an allowed channel.
T1132.002detects — A.8.27 mandates security-oriented design reviews, analysis of controls' detection capabilities, hardening, and regular review of principles against new threats/attack patterns, which surfaces non-standard encoding in C2 during architecture and engineering reviews but does not instrument runtime detection of the realized technique.
T1132.002prevents — A.8.27 mandates security-by-design, defence-in-depth, distrust-external-input, hardening, and secure session/data-validation principles that reach non-standard encoding in C2 traffic when applied to protocol or application layers; this is a genuine but minority slice of the technique's surface (implementation-dependent, not exhaustive across all custom schemes or platforms).
T1133detects — A.8.27 mandates security-oriented design reviews, threat analysis, and ongoing review of engineering principles to identify vulnerabilities and keep up with new threats; this surfaces design or configuration choices that expose remote services (e.g. unauthenticated Docker/K8s APIs, weak VPN gateways, or Tor hidden services) before or after deployment, but only within the engineering and review process rather than continuous runtime detection of the technique in flight.
T1133prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, zero-trust, hardening, and secure engineering principles (including authentication, session control, and input sanitisation) that are applied to system architecture; these directly constrain or block many T1133 vectors (exposed unauthenticated services, weak remote gateways, improper trust boundaries, persistent Tor services), but the control is a process that depends on implementation rigour and does not guarantee removal of all external remote services or all credential-based access paths.
T1134detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification of requests, and ongoing review of principles against new threats, which can surface token-manipulation patterns in architecture or code but does not instrument or monitor runtime behavior to detect the technique once it occurs.
T1134prevents — A.8.27 mandates applying security-by-design, least privilege, defence-in-depth, assume-breach and zero-trust principles (never trust/always verify, strong auth, dynamic access control) during architecture and engineering; these constrain token-manipulation vectors in new systems but do not stop the built-in Windows APIs or post-compromise use against already-deployed components.
T1134.001detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification of requests, and ongoing review of principles against new threats, which surfaces token-impersonation patterns in architecture and code but does not instrument runtime detection of the technique itself.
T1134.001prevents — A.8.27 mandates application of security-by-design, least privilege, defence-in-depth, assume-breach and zero-trust principles plus security-oriented design reviews that surface token-impersonation risks and require stronger session controls and authentication; this constrains the technique on systems built under it, but the clause only sets a process rather than a universal mechanism and cannot stop an already-compromised process from calling DuplicateToken/ImpersonateLoggedOnUser.
T1134.002detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification of requests, and ongoing review of principles against new threats, which surfaces token-related privilege-escalation patterns during engineering but does not instrument runtime detection of the technique once deployed.
T1134.002prevents — A.8.27 mandates applying security-by-design, least privilege, defence-in-depth, assume-breach and zero-trust principles (never trust/always verify, contextual authz, strong MFA) during architecture and engineering; these constrain the conditions under which a stolen/duplicated token can be used to spawn an escalated process, but do not eliminate the underlying Windows token-creation APIs or the prerequisite token-acquisition steps.
T1134.003detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification of every request, and ongoing review for new threats, which surfaces token-creation/impersonation patterns during engineering but does not instrument runtime detection of the technique once deployed.
T1134.003prevents — A.8.27 mandates applying security-by-design, least privilege, default-deny, assume-breach, distrust-external-input, and zero-trust principles (never-trust/always-verify, contextual authz, strong MFA) during architecture and engineering; these directly constrain the creation and use of new tokens to escalate or bypass access controls, but only for systems built under the control and only to the degree the principles are actually enforced in code and configuration.
T1134.004detects — A.8.27 mandates security-oriented design reviews, threat analysis, and monitoring of engineering principles that can surface PPID-spoofing patterns during development or architecture reviews, but does not mandate runtime detection of the technique itself.
T1134.004prevents — A.8.27 mandates security-by-design principles (least privilege, defence-in-depth, assume-breach, security architecture integration, hardening, and design reviews against known attack patterns) that reach PPID-spoofing when it is treated as a privilege-escalation or evasion vector; this constrains the technique in systems built under the control, but the clause is a process/governance requirement whose coverage depends on how rigorously the principles are selected and applied, leaving a genuine slice unreached.
T1134.005detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification of requests, and ongoing review of principles against new threats, which can surface anomalous SID-History usage or weak token handling in architecture but does not instrument or monitor runtime execution of the technique itself.
T1134.005prevents — A.8.27 mandates security-by-design, least-privilege, defence-in-depth, assume-breach and zero-trust principles plus hardening and design reviews that, when applied to identity and access architecture, stop SID-History from being writable or honoured; this is a genuine but minority slice of the technique (the remainder is post-compromise DA-level abuse of a correctly functioning AD attribute).
T1135detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust principles (assume breach, never trust/always verify, least privilege), and ongoing review of engineering principles against new threats; these surface anomalous discovery activity (e.g. unexpected SMB/net view/share enumeration) as part of integrated controls and threat-aware architecture, but only where the resulting telemetry/monitoring falls inside the chosen scope and does not guarantee detection of all instances.
T1135prevents — A.8.27 mandates security-by-design principles (least privilege, least functionality, default-deny, zero-trust “never trust/always verify”, hardening) that can remove or lock down unnecessary network shares and SMB exposure, but the control is a high-level process that does not itself enforce any concrete configuration and leaves many legitimate shares untouched.
T1136prevents — A.8.27 mandates security-by-design principles (least privilege, default-deny, zero-trust verification, hardening, security reviews) that can stop many forms of unauthorized account creation during engineering and deployment, but does not block runtime creation by an already-privileged adversary on live systems.
T1136.001detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification of requests, and ongoing review of principles against new threats, which can surface anomalous local account creation as a vulnerability or deviation in reviewed systems or architecture, but this is limited to design/engineering-time or scoped monitoring rather than reliably detecting post-compromise runtime use of the technique across all platforms.
T1136.001prevents — A.8.27 mandates security-by-design, least privilege, default-deny, zero-trust and hardening principles that, when applied during engineering, stop many classes of local-account creation (e.g. by removing unnecessary account-creation primitives, enforcing just-in-time accounts, or requiring MFA/authorization on administrative interfaces); the remainder is accounts legitimately needed by the OS, services or business processes that the adversary can still abuse once created.
T1136.002detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification of requests, and regular review of principles against new threats, which surfaces anomalous account creation in the engineering and operational process but does not instrument runtime detection of the post-compromise T1136.002 technique itself.
T1136.002prevents — A.8.27 mandates security-by-design, least privilege, default-deny, zero-trust, and hardening principles that are applied during engineering; these constrain where and how domain accounts can legitimately be created and what privileges they receive, so the adversary technique is blocked in systems built under the control, but the clause is silent on runtime enforcement that would stop an already-privileged process from issuing net user /add /domain, leaving a genuine minority slice prevented.
T1136.003detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification of requests, and regular review of engineering principles against new threats; these surface anomalous or risky account creations (especially in design/outsourced phases or via monitoring implied by assume-breach), but the clause is not a monitoring or scanning control and leaves most post-deployment stealthy account creations undetected.
T1136.003prevents — A.8.27 mandates security-by-design, least privilege, zero-trust, defence-in-depth and secure engineering reviews that, when applied during cloud architecture and outsourced development, constrain how easily an adversary-created account can be granted broad undetected access; this stops a meaningful slice of the technique but leaves residual paths (e.g., minimal-permission service principals or post-breach role manipulation) that the clause does not itself block.
T1137detects — A.8.27 mandates security-oriented design reviews, hardening, and ongoing review of engineering principles to identify vulnerabilities and keep up with new threats; this surfaces some Office application startup abuse vectors (e.g. via macro/add-in analysis or assume-breach reviews) but does not instrument or monitor runtime Office behavior, leaving most post-deployment detection of T1137 outside its scope.
T1137prevents — A.8.27 mandates security-by-design principles (least privilege, default deny, distrust external input, hardening, secure session control, data validation/sanitisation) that can stop many Office add-in/macro/template abuse vectors at design or deployment time, but leaves a remainder for post-deployment configuration abuse such as Outlook rules and Home Page modifications that the clause does not directly govern.
T1137.001detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of engineering principles against new threats; these surface template-macro persistence risks during design, deployment or post-incident review but do not instrument runtime detection of the technique itself.
T1137.001prevents — A.8.27 mandates applying security-by-design, least functionality/privilege, distrust-external-input, hardening, and secure-development principles (including macro handling) across the engineering lifecycle and to outsourced code; this constrains the attack surface and reduces the chance the vulnerable template/macro-persistence path is introduced, but does not guarantee its absence in every Office deployment or configuration.
T1137.002detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and regular review of engineering principles to identify vulnerabilities and new threats; this surfaces the anomalous Office Test registry key or untrusted DLL load during design, deployment or ongoing review, but only where the technique is in scope of the chosen architecture review or monitoring rather than universally.
T1137.002prevents — A.8.27 mandates security-by-design, hardening, least-privilege, default-deny and secure-engineering reviews that would stop the insecure Office Test registry key from being present or enabled by default in a hardened build, but the control is a set of principles and review practices whose actual preventive effect still depends on how rigorously they are applied to the specific Office component.
T1137.003detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and regular review of engineering principles to identify vulnerabilities and new threats; this surfaces the Outlook Forms persistence technique in design or post-deployment review but only where the organization explicitly includes client-side email form analysis in its scope, leaving most implementations without that coverage.
T1137.003prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, hardening, distrust-external-input and security-oriented design reviews that reach custom code and forms in the Outlook/Office development lifecycle, so the malicious-form technique is prevented where those principles are applied; it remains a slice because the clause is a process that depends on rigour of implementation and does not itself block every possible Outlook form abuse.
T1137.004detects — A.8.27 mandates security-oriented design reviews, threat analysis against known attack patterns, and ongoing review of engineering principles to identify vulnerabilities including in legacy features and deployment; this surfaces the Outlook Home Page abuse in design or review but is scoped only to engineering activities rather than runtime detection across deployed systems.
T1137.004prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, distrust-external-input, hardening, and secure-engineering reviews that explicitly address custom code execution surfaces such as Outlook Home Page; these stop the malicious HTML from being introduced or executed in the large majority of engineered systems, but the legacy feature can still be left enabled in Outlook configurations that pre-date or fall outside the reviewed architecture.
T1137.005detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of engineering principles against new threats, which surfaces the malicious Outlook rule as a design or configuration vulnerability during secure development or architecture review, but only for in-scope custom/outsource engineering and not for post-compromise runtime abuse on end-user mailboxes.
T1137.005prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, default-deny, distrust-external-input and zero-trust principles plus design reviews that would catch or block malicious Outlook rules as an insecure persistence mechanism; this constrains the technique for systems built under it, but the clause is a process that depends on rigour of application and does not reach every existing Outlook deployment.
T1137.006detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and regular review of engineering principles to identify vulnerabilities and new threats; this surfaces the add-in persistence technique in reviewed systems or during threat updates, but only where the review scope and depth actually inspect Office configurations or add-in loading (a slice set by the implementer).
T1137.006prevents — A.8.27 mandates establishing and applying security engineering principles (including least privilege, security by default, default deny, hardening, and distrusting external input) to the full development life cycle and architecture layers, which reaches the design and implementation choices that would allow malicious add-ins to auto-execute on Office start; this stops the technique at source in systems built under it, but remains partial because the clause is a process/governance requirement whose coverage depends on implementation rigour, does not reach already-deployed systems or third-party Office add-ins outside the engineering scope, and the review clause is only reactive.
T1140detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of principles against new threats/attack patterns, which can surface deobfuscation utilities or patterns in architecture and code reviews; this is limited to what is caught in design/hardening rather than runtime detection of the technique in flight.
T1140prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, hardening, zero-trust and secure-engineering reviews that can stop many common deobfuscation utilities and patterns from being available or effective in the built system; the remainder (adversary-supplied tools, user-triggered actions, or novel methods) is a named slice, not the bulk.
T1176detects — A.8.27 mandates security-oriented design reviews, analysis of controls (including detection capabilities), hardening, and regular review of principles against new threats; this surfaces design or marketplace weaknesses that enable malicious extensions but does not instrument runtime detection of their use or persistence.
T1176prevents — A.8.27 mandates security-by-design, defense-in-depth, least-privilege, hardening, distrust-external-input, and secure engineering reviews that directly shape extension loading, permission inheritance, marketplace vetting, and runtime controls, stopping many installation and abuse paths; it leaves a slice (social-engineering delivery of signed extensions, supply-chain compromise of the marketplace itself, and post-install benign-extension abuse) unaddressed.
T1176.001detects — A.8.27 mandates security-oriented design reviews, threat analysis, hardening, and ongoing review of engineering principles to identify vulnerabilities and keep up with new threats; this surfaces some extension-abuse vectors (e.g. via architecture reviews or zero-trust assumptions) but does not instrument runtime detection of installed malicious extensions or their behaviors.
T1176.001prevents — A.8.27 mandates security-by-design principles (least privilege, default-deny, distrust-external-input, hardening, security reviews against attack patterns) that can stop malicious-browser-extension installation vectors when applied to browser and endpoint engineering; this is only a slice of the technique's full surface (social engineering, post-compromise file manipulation, app-store bypasses, and already-installed extensions).
T1176.002detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and regular review of engineering principles to identify vulnerabilities and new threats; this surfaces malicious or abused IDE extensions during development, procurement, or supplier-alignment reviews, but does not instrument runtime detection of installed extensions on end systems.
T1176.002prevents — A.8.27 mandates security-by-design, hardening, least-privilege, zero-trust, and secure-engineering review of architecture layers and new technology; this directly constrains malicious or abused IDE extensions at design and deployment time, but leaves a large remainder (runtime extension marketplaces, side-loading, and benign-extension abuse after the IDE is already present).
T1185detects — A.8.27 mandates security-oriented design reviews, threat analysis against known attack patterns, and ongoing review of engineering principles to identify vulnerabilities including those enabling session hijacking; this surfaces the class in design and engineering but does not instrument runtime detection of the realized technique.
T1185prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, secure session control, hardening, distrust-external-input and zero-trust review of architecture layers; these directly block the injection, session-inheritance and privilege-escalation vectors named in T1185, but the control is a process that depends on how rigorously those principles are applied in any given browser or extension, leaving a real slice unaddressed.
T1187detects — A.8.27 mandates security-oriented design reviews, threat analysis, zero-trust verification, and ongoing review of engineering principles to identify vulnerabilities and new threats; this surfaces the design/implementation gaps that enable forced authentication but does not instrument runtime detection of the technique itself.
T1187prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, distrust-external-input, fail-securely and zero-trust principles plus design reviews that, when applied during engineering, stop most forced-authentication vectors (e.g. by removing automatic outbound SMB/WebDAV, enforcing endpoint isolation, or requiring explicit verification); residual attack surface remains because the control is a process that depends on how rigorously those principles are implemented and does not reach every legacy protocol or third-party component.
T1189detects — A.8.27 mandates security-oriented design reviews to identify vulnerabilities, analysis of controls' capabilities to detect security events, and ongoing reviews for new threats, which surfaces some drive-by vectors (e.g., XSS, watering holes) during engineering but does not instrument runtime detection of the technique itself.
T1189prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, hardening, secure session control, input sanitisation and zero-trust verification that can stop several delivery vectors (XSS, malicious script execution, unsafe defaults) and limit post-compromise impact, but cannot stop all watering-hole or malvertising paths that rely on unpatched client browsers or user action.
T1190prevents — Security-by-design reviews, threat analysis, and hardening of public-facing applications directly shrink the attack surface that adversaries exploit to gain initial access.
T1195detects — A.8.27 mandates security-oriented design reviews, analysis of threats/controls, and regular review of engineering principles to identify vulnerabilities and keep up with new threats, which surfaces supply-chain risks in development/outsourced engineering but does not broadly detect post-deployment or second-order compromises across all listed stages.
T1195prevents — A.8.27 mandates security engineering principles (security by design, least privilege, assume breach, distrust external input, hardening, secure development practices, supplier contract alignment, design reviews against attack patterns) that directly constrain manipulation of development tools/environments, source code, open-source dependencies, and outsourced development — preventing the technique from succeeding in those stages; it does not reach physical supply-chain stages such as factory-infected media, shipment interdiction, or counterfeit hardware sales.
T1195.001detects — A.8.27 mandates security-oriented design reviews, analysis of threats/controls, and regular review of engineering principles to identify vulnerabilities (including in outsourced development and new technology), which surfaces supply-chain risks in dependencies/CI-CD before or during engineering but does not instrument runtime detection of the post-compromise technique itself.
T1195.001prevents — A.8.27 mandates security-by-design, secure engineering principles (least privilege, distrust external input, defence-in-depth, zero-trust verification), hardening, design reviews against attack patterns, and supplier alignment; these directly constrain supply-chain manipulation of dependencies, dev tools, and CI/CD components before they reach the consumer, but only where the principles are actually applied in the engineering process — the clause sets requirements rather than mandating universal mechanisms or coverage of every third-party/abandoned package.
T1195.002detects — A.8.27 mandates security-oriented design reviews, analysis of threats/controls, and regular review of engineering principles to identify vulnerabilities including in outsourced development, which surfaces supply-chain manipulation risks in design and supplier practices but does not broadly detect post-deployment or runtime instances of the technique.
T1195.002prevents — A.8.27 mandates security engineering principles (security by design, secure coding, hardening, supply-chain contract alignment, design reviews against attack patterns) that reduce the chance of source-code or build manipulation in the development life cycle, but does not stop an upstream or external supplier from inserting a backdoor before the organization receives the component.
T1195.003prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, assume-breach, hardening, supply-chain contract clauses and design reviews that analyse threats and known attack patterns; these directly constrain the insertion or acceptance of compromised hardware/firmware in the engineering and procurement process, but only for systems the organization itself designs, specifies or contracts for (a genuine but bounded slice of the global pre-consumer supply-chain manipulation named by T1195.003).
T1197detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of engineering principles against new threats; this can surface BITS abuse patterns in architecture or code review but does not mandate runtime monitoring or anomaly detection that would catch live BITS jobs.
T1197prevents — A.8.27 mandates establishing and applying security engineering principles (least privilege, least functionality, security by default, default deny, fail securely, distrust external input, assume breach, zero-trust verification) plus security-oriented design reviews and hardening; these can prevent abuse of BITS by removing or restricting the unnecessary background job mechanism or its COM/PowerShell interfaces in hardened builds, but only for systems built under the control and only where the principles are actually enforced against this specific low-priority transfer service.
T1199detects — A.8.27 mandates security-oriented design reviews, threat analysis, zero-trust verification, and ongoing review of engineering principles that surface supply-chain/third-party access risks and anomalous trusted relationships, but this is limited to what the design/engineering process itself can discover rather than runtime detection of the technique.
T1199prevents — A.8.27 mandates security-by-design, zero-trust, least-privilege, and supply-chain contract requirements that directly constrain how trusted third-party relationships and their accounts are architected, limited, verified and monitored, stopping many (but not all) T1199 abuse paths at design time.
T1200detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of engineering principles that surface anomalous hardware additions (e.g. via assume-breach, distrust-external-input, or network boundary monitoring), but this is limited to what the design/operational review process can observe and does not broadly instrument for post-introduction detection of physical additions.
T1201prevents — A.8.27 mandates security-by-design, least privilege, zero-trust, defence-in-depth and hardening principles plus security-oriented design reviews that, when applied to authentication/identity components, constrain how password policies are engineered (e.g. strong defaults, MFA, dynamic access) and thereby stop many discovery paths that would otherwise succeed; it does not reach every platform or every discovery vector (CLI, cloud APIs, network devices) so the coverage is a genuine but minority slice of the technique.
T1202detects — A.8.27 mandates security-oriented design reviews, threat analysis, and ongoing review of principles to identify vulnerabilities and keep up with new threats/attack patterns, which can surface indirect command execution techniques during architecture and engineering phases, but this is limited to pre-deployment design-time discovery rather than runtime detection of the live technique.
T1202prevents — A.8.27 mandates security-by-design, defence-in-depth, least privilege, least functionality, hardening, and security-oriented design reviews that can eliminate many indirect-execution utilities or block their abuse vectors before deployment; this is genuine but only a slice because the control is a process that depends on implementation rigour and does not guarantee removal of every living-off-the-land binary an adversary might leverage post-compromise.
T1203detects — A.8.27 mandates security-oriented design reviews to identify vulnerabilities plus ongoing review of principles against new threats, which can surface exploitable client-application flaws before or after deployment, but the clause is scoped to engineering activities and does not require runtime detection of exploitation attempts.
T1203prevents — A.8.27 mandates establishing and applying security engineering principles (secure-by-design, least privilege, security-oriented design reviews, hardening, distrust external input, secure coding practices for validation/sanitization/authentication) to the development life cycle, which directly reduces the likelihood of the unsecure coding practices that create the client-application vulnerabilities T1203 exploits; it does not reach third-party or already-shipped client software that adversaries target.
T1204detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust principles, and ongoing review of engineering practices to identify vulnerabilities and new threats, which can surface risky user-execution vectors (e.g. unsafe defaults, missing session controls, or unhardened clients) during design and review but does not instrument or monitor runtime user actions or the technique itself.
T1204prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, fail-secure, distrust-external-input, hardening, and zero-trust principles that can stop many user-execution vectors (e.g. safe defaults, input sanitisation, strong auth on tools, reduced attack surface) but cannot stop all social-engineering lures or every user action on already-delivered malicious content.
T1204.001detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of principles to surface vulnerabilities and anomalous access patterns that could enable malicious-link execution, but this is limited to what is caught in design/engineering reviews rather than runtime detection of the user-click technique itself.
T1204.001prevents — A.8.27 mandates security-by-design, defence-in-depth, least privilege, zero-trust, distrust-external-input, hardening and secure session/auth principles that can stop many malicious-link execution paths (e.g. by blocking unsafe links, requiring strong auth, or sandboxing), but leaves open social-engineering clicks that still reach browser/app vulnerabilities or downloads, so only a slice of the technique is prevented.
T1204.002detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification of requests, and ongoing review of principles against new threats, which can surface indicators of malicious-file techniques in architecture and deployment but does not itself instrument or monitor for the user-action event.
T1204.002prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, hardening, distrust-external-input and secure-engineering reviews that can stop malicious-file execution paths (e.g. by blocking unsafe file types, sandboxing, strict allow-lists, or removing execution vectors), but these are only principles applied where the implementer chooses and do not guarantee removal of every social-engineering or masquerading vector that leads to user execution.
T1204.003detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and regular review of principles against new threats, which surfaces malicious/backdoored images in the engineering and deployment pipeline, but only for images built or reviewed under the org's process (a slice; public-repo consumption and naming tricks lie outside that scope).
T1204.003prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, hardening, zero-trust verification, secure defaults and design reviews that catch or block many classes of backdoored/malicious images before deployment; it does not reach every supply-chain upload or every naming trick that tricks a user into running one.
T1204.004detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of principles to identify vulnerabilities and new threats; this surfaces social-engineering patterns like ClickFix in architecture and reviews but does not instrument runtime detection of the user copy-paste execution itself.
T1204.004prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, distrust-external-input, fail-securely and zero-trust principles plus design reviews that surface social-engineering vectors; these constrain the attack surface and raise the bar for successful ClickFix-style paste-execution, but do not stop users from being socially engineered into pasting when the principles are only partially realised in UI/UX or training layers.
T1204.005detects — A.8.27 mandates security-oriented design reviews, analysis of controls for detection capability, hardening, and regular review of principles against new threats; this surfaces malicious-library risks in architecture/dependencies but does not mandate runtime or supply-chain detection mechanisms.
T1204.005prevents — A.8.27 mandates security-by-design, secure engineering principles (least privilege, distrust external input, hardening, zero-trust verification), and design reviews that surface malicious-library risks in the SDLC and supply chain; this stops many instances at design or procurement time, but the control is a process that depends on implementation rigour and does not block every user-side install of a typosquatted or compromised dependency.
T1205detects — A.8.27 mandates security-oriented design reviews, threat analysis, and zero-trust verification that can surface traffic-signaling mechanisms (e.g. magic values, port-knocking sequences, or custom packet handlers) during architecture and code review, but only where the organization controls the development and the review actually inspects for them; it does not instrument runtime detection of the technique in deployed systems.
T1205prevents — A.8.27 mandates security-by-design, defense-in-depth, least privilege, fail-secure, distrust-external-input, assume-breach, and zero-trust principles plus design reviews that explicitly consider attack patterns; these directly constrain the design and implementation choices that would allow hidden ports, magic-value triggers, or custom signaling handlers, but the clause is a process that depends on how rigorously those principles are applied and does not reach every possible implementation (especially on embedded/network devices or outsourced code).
T1205.001detects — A.8.27 mandates security-oriented design reviews, threat analysis, and monitoring for anomalous behaviour via principles like assume-breach and zero-trust verification, which can surface port-knocking signals in reviewed architectures or logged traffic, but this is limited to what the organisation chooses to instrument in design and does not guarantee detection of the technique post-deployment.
T1205.001prevents — A.8.27 mandates security-by-design, defense-in-depth, least functionality, assume-breach, and hardening that can exclude or lock down unnecessary listening ports and firewall rules, stopping the port-knocking sequence from ever succeeding; this is only a slice of the technique because custom software, raw-socket implementations, and already-open ports remain reachable under the clause's own guidance on residual risk and outsourced development.
T1205.002detects — A.8.27 requires security-oriented design reviews, threat analysis, and regular review of engineering principles to identify vulnerabilities and keep up with new threats; this surfaces the socket filter technique in design and during principle updates, but the control is silent on runtime/operational detection of the low-activity, raw-socket behavior described.
T1205.002prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, assume-breach, hardening, and security-oriented design reviews that can stop socket-filter backdoors from being introduced or left enabled; this reaches only a slice because the control is a process/guidance clause whose effect depends on how rigorously those principles are applied to every relevant component and platform.
T1207detects — A.8.27 mandates security-oriented design reviews, threat analysis, zero-trust verification, and ongoing review of engineering principles that can surface design or implementation flaws enabling rogue DC registration (e.g. via architecture gaps or weak auth), but does not instrument runtime detection of the technique itself or its AD manipulation.
T1207prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, assume-breach, zero-trust and hardening principles plus design reviews that, when applied to AD architecture and engineering, stop rogue-DC registration from succeeding; the coverage is only a slice because the clause is a process that depends on how rigorously those principles are implemented and reviewed.
T1210prevents — Secure architecture reviews and hardening of remote services decrease the number of remotely exploitable pathways available for lateral movement.
T1210detects — A.8.27 mandates security-oriented design reviews, analysis of controls' detection/response capabilities, hardening, and ongoing review of principles against new threats, which surfaces some exploitable remote-service flaws during engineering but does not instrument or monitor runtime exploitation attempts on deployed systems.
T1211detects — A.8.27 mandates security-oriented design reviews, threat analysis, and zero-trust principles that surface stealth/exploitation opportunities during engineering, but this is limited to the development/review phase and does not broadly detect in-operation exploitation of stealth vulnerabilities.
T1211prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, assume-breach, security-oriented design reviews, hardening, and analysis of controls that can prevent events; these directly reduce the likelihood that exploitable flaws enabling stealth/evasion are introduced, but do not guarantee their absence.
T1212detects — A.8.27 mandates security-oriented design reviews, analysis of controls' detection capabilities, hardening, zero-trust verification, and ongoing review of principles against new threats; this surfaces some credential-exploitation vulnerabilities (especially in auth mechanisms) during engineering but does not instrument runtime detection of the technique itself.
T1212prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, secure session control, input validation/sanitisation, distrust-external-input, fail-securely and zero-trust verification principles that directly address the programming errors, improper validation and weak authentication mechanisms exploited by T1212; this stops many (but not all) such vulnerabilities from being introduced or left exploitable.
T1213prevents — A.8.27 mandates security-by-design, defense-in-depth, least privilege, zero-trust, hardening, and secure architecture reviews that directly reduce the likelihood of the overly-broad or public repository access patterns named in the T1213 source prose; this is genuine but only a slice because the control is a process that depends on implementation rigor and does not itself enforce or remove every possible misconfiguration of every repository type.
T1213.001prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, zero-trust and hardening principles plus design reviews that, when applied to development environments and outsourced systems, reduce the likelihood sensitive items (credentials, diagrams, source, internal links) are stored unprotected in Confluence; this is a genuine but minority slice of the technique because the control does not govern access decisions at the repository itself nor remove already-stored data.
T1213.002prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, zero-trust and hardening principles plus design reviews that, when applied to SharePoint repositories, can stop many classes of information exposure (e.g. by enforcing proper access controls, data classification, and default-deny on sensitive diagrams/credentials), but the control is a set of engineering practices rather than a concrete mechanism that guarantees the listed items will never be stored in or exfiltrated from SharePoint, leaving a genuine residual slice.
T1213.003prevents — A.8.27 mandates security-by-design, least privilege, zero-trust, hardening, and secure engineering principles (including authentication, session control, data validation/sanitization) that can stop an adversary from reaching or extracting data from a code repository once inside the network; this is only a slice of the technique because the control is a set of high-level principles rather than an enforced mechanism that guarantees protection of every repository or credential.
T1213.004prevents — A.8.27 mandates security-by-design, zero-trust, least-privilege, and hardening principles that, when applied during engineering of the CRM system (on-prem or SaaS), constrain the ways an adversary who has initial access can reach and query the stored customer data, but do not stop the technique once the adversary already possesses valid high-privilege access inside the victim organization.
T1213.005prevents — A.8.27 mandates security-by-design, zero-trust, least-privilege, default-deny and distrust-external-input principles plus design reviews that, when applied to messaging platforms, can stop sensitive data (credentials, source, proprietary info) from ever reaching chat channels; this is a genuine but minority slice of the technique because the control is a process that depends on implementation rigour and does not reach every deployment or every data type an adversary might mine.
T1213.006detects — A.8.27 mandates security-oriented design reviews, threat analysis against known attack patterns, zero-trust verification, and ongoing review of engineering principles that surface database access anomalies or insecure designs, but this is limited to the development/engineering phase and does not broadly instrument runtime detection of database mining across IaaS/SaaS platforms.
T1213.006prevents — A.8.27 mandates security-by-design, zero-trust, least-privilege, and hardening principles that, when applied during engineering, stop many database access paths and misconfigurations the technique relies on; it does not reach every deployment or every post-deployment database instance, leaving a genuine minority slice.
T1216detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of principles against new threats, which surfaces proxy/abuse risks in architecture and engineering but does not instrument runtime detection of the technique once deployed.
T1216prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, least-functionality, hardening, and design reviews that explicitly consider known attack patterns; these principles applied during engineering would remove or lock down many of the signed Microsoft proxy scripts (e.g. via AppLocker-style restrictions, removal of unnecessary interpreters, or default-deny execution), but the control is a process that depends on implementation rigour and does not guarantee every LOLBAS proxy is eliminated on every Windows build.
T1216.001detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification of requests, and regular review of principles against new threats; these surface anomalous or risky use of living-off-the-land binaries such as PubPrn abuse during design, testing or ongoing engineering reviews, but the clause is silent on runtime monitoring or detection mechanisms so only a minority slice of the technique is reached.
T1216.001prevents — A.8.27 mandates applying security-by-design, defence-in-depth, least-privilege, default-deny, fail-securely, distrust-external-input and hardening principles plus design reviews that explicitly consider known attack patterns; these reach the PubPrn abuse vector (a signed living-off-the-land binary that trusts remote script: monikers) and would cause the flawed design to be rejected or hardened, but the clause is a process that depends on rigour of application and does not itself remove the technique from every Windows build.
T1216.002detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of engineering principles to identify vulnerabilities and new threats; this surfaces the abuse of a signed LOLBin for proxy execution as an attack pattern or insecure design, but only where the review process actually examines the specific technique (a slice set by implementation scope, not a bounded remainder).
T1216.002prevents — A.8.27 mandates security-by-design, defence-in-depth, least functionality/privilege, hardening, and secure-engineering reviews that can remove or constrain signed LOLBin proxies such as SyncAppvPublishingServer.vbs; this prevents the technique on systems built under those principles, but the control is a process that depends on rigour of application and does not reach every legacy or third-party Windows deployment, leaving a genuine minority slice prevented.
T1218detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of engineering principles against new threats/attack patterns, which can surface proxy-abuse vectors (e.g. via architecture review or monitoring design) but does not itself perform or require runtime detection of the technique.
T1218prevents — A.8.27 mandates security-by-design, defence-in-depth, least privilege, least functionality, hardening, and security-oriented design reviews that can remove or constrain many proxy binaries and their abuse paths during architecture and implementation; this is a genuine but minority slice of the technique because many signed LOLBINs remain required for legitimate OS functions and the control does not guarantee their complete elimination or runtime blocking.
T1218.001detects — A.8.27 mandates security-oriented design reviews, threat analysis against known attack patterns, hardening, and ongoing review of engineering principles to surface vulnerabilities; this can detect the insecure design/implementation that permits T1218.001 abuse (e.g. unpatched hh.exe handling or missing application control), but only as part of broader SDLC review rather than runtime or specific technique detection.
T1218.001prevents — A.8.27 mandates security-by-design, defence-in-depth, least functionality/privilege, hardening, distrust-external-input and assume-breach principles plus design reviews that would catch or block unsafe CHM/hh.exe handling in new or reviewed systems; it does not reach legacy/unpatched systems already deployed or third-party CHM content that bypasses existing controls.
T1218.002detects — A.8.27 mandates security-oriented design reviews, threat analysis, and ongoing review of engineering principles to identify vulnerabilities and keep up with new threats; this surfaces the abuse technique in design or when new attack patterns (e.g. proxying via control.exe/CPL) become known, but the clause is scoped to engineering activities rather than runtime/operational detection of in-flight abuse.
T1218.002prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, least-functionality, hardening, and secure-engineering reviews that can remove or block the attack surface (e.g. by restricting CPL/DLL loading, proxy execution paths, or untrusted registration), but these are high-level principles whose concrete application is not guaranteed and leaves residual bypass vectors such as renamed DLLs or phishing delivery.
T1218.003detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust principles, and regular review of engineering practices to identify vulnerabilities and new threats; this surfaces the abuse potential of signed binaries like CMSTP during architecture and review activities, but only as a slice of possible detection rather than ongoing runtime or monitoring instrumentation.
T1218.003prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, least-functionality, hardening, security-oriented design reviews and zero-trust principles that, when applied during engineering, can stop the inclusion or enablement of CMSTP.exe abuse paths (e.g. by removing unnecessary binaries, enforcing strict allow-lists, or designing out auto-elevated COM interfaces), but these are process-level requirements whose actual coverage depends on implementation rigour and leaves many residual Windows-native execution vectors untouched.
T1218.004detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust monitoring principles, and regular review of engineering practices against new threats, which can surface anomalous or suspicious use of InstallUtil as a living-off-the-land binary, but does not itself perform or require runtime detection instrumentation.
T1218.004prevents — A.8.27 mandates applying security-by-design, least functionality/privilege, hardening, security-oriented design reviews, and distrust-external-input principles to the engineering life cycle (including outsourced development); these directly constrain the class of signed-trusted-utility proxy techniques when followed, but remain a process that depends on implementation rigour and does not guarantee removal of all such living-off-the-land opportunities.
T1218.005detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of engineering principles to identify vulnerabilities and new threats; this surfaces mshta abuse patterns in architecture and deployment but does not instrument runtime detection of the technique itself.
T1218.005prevents — A.8.27 mandates security-by-design, defence-in-depth, least functionality/privilege, hardening, distrust-external-input and security-oriented design reviews that can exclude or constrain unneeded trusted utilities like mshta.exe (and its bypass of application control/browser policy), but the control is a set of engineering principles and reviews rather than a universal mechanism that guarantees removal of every living-off-the-land binary on every Windows build.
T1218.007detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of principles against new threats/attack patterns, which surfaces the abuse potential of signed binaries like msiexec in architecture and deployment but does not instrument runtime detection of its use as a proxy.
T1218.007prevents — A.8.27 mandates security-by-design, defence-in-depth, least privilege, least functionality, hardening, security-oriented design reviews and zero-trust principles that can be applied to remove or constrain msiexec.exe abuse vectors (e.g. via default-deny execution policy, removal of AlwaysInstallElevated, signed-binary allow-listing and contextual authz), but these are only principles and reviews that depend on downstream implementation rigour and do not guarantee the specific technique is blocked on every Windows system.
T1218.008detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and regular review of principles against new threats/attack patterns, which surfaces living-off-the-land abuse of signed binaries like odbcconf.exe in architecture and deployment reviews, but only where those reviews explicitly consider proxy-execution techniques (a slice, not the bulk).
T1218.008prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, hardening, security-oriented design reviews and zero-trust principles that, when applied during engineering, reduce the likelihood an allowed-by-default signed binary such as odbcconf.exe can be left available for REGSVR abuse; this is a genuine but minority slice of the technique (most instances arise from unhardened defaults or post-deployment misconfigurations outside the engineering process).
T1218.009detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of engineering principles against new threats, which can surface anomalous or suspicious use of signed binaries like Regsvcs/Regasm in development/operation but does not mandate runtime monitoring or detection mechanisms.
T1218.009prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, least-functionality, hardening, and secure-engineering reviews that can remove or block the signed-trusted-binary proxy path in new systems or outsourced development, but leaves residual exposure on existing Windows deployments, legacy .NET assemblies, and attacker-introduced binaries that already satisfy the technique.
T1218.010detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of principles against new threats/attack patterns, which surfaces proxy-execution and living-off-the-land abuse like Regsvr32 in architecture and engineering but does not instrument runtime detection of the technique itself.
T1218.010prevents — A.8.27 mandates security-by-design, defence-in-depth, least privilege, least functionality, hardening, and secure engineering reviews that can remove or constrain the living-off-the-land binary and COM/scriptlet abuse paths before systems are built or deployed.
T1218.011detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of principles against new threats/attack patterns, which surfaces some proxying/obfuscation vectors (e.g. via signed DLLs or masquerading) during architecture and engineering but does not instrument or monitor runtime execution of rundll32.exe itself.
T1218.011prevents — A.8.27 mandates security-by-design, defence-in-depth, least privilege, least functionality, hardening, security-oriented design reviews, and analysis of controls that can explicitly block proxy-execution techniques such as rundll32 abuse; these principles applied during engineering reduce the attack surface and stop many (but not all) variants, especially those relying on unnecessary functionality or weak defaults.
T1218.012detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and regular review of principles against new threats/attack patterns, which surfaces proxy/abuse techniques like verclsid.exe during architecture and engineering but does not instrument runtime detection of its use.
T1218.012prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, hardening, and secure-engineering reviews that can eliminate many proxy-execution vectors (including unsafe COM/CLSID handling) before deployment; the named remainder is post-compromise or legacy Windows binaries whose abuse surface is not removed by architecture principles alone.
T1218.013detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of principles against new threats/attack patterns, which surfaces proxy-injection techniques like mavinject during architecture and engineering reviews, but only for systems built under the control and not for arbitrary post-deployment abuse of living-off-the-land binaries.
T1218.013prevents — A.8.27 mandates security-by-design, defence-in-depth, least privilege, least functionality, hardening, and secure engineering reviews that can remove or constrain living-off-the-land binaries such as mavinject.exe and the injection vectors it enables, but these are only applied where the organisation chooses to restrict them and do not stop all signed LOLBins or all forms of DLL/import injection.
T1218.014detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and regular review of principles against new threats/attack patterns, which surfaces some proxy-execution or anomalous MMC/.msc usage in reviewed systems but does not instrument or monitor runtime behavior across the enterprise.
T1218.014prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, least-functionality, hardening, and security-oriented design reviews that can stop unsafe snap-in/CLSID registration and MMC abuse paths from being introduced; this is a genuine but minority slice of the full technique surface (most real-world abuse uses already-shipped legitimate .msc files and signed binaries).
T1218.015detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of principles against new threats/attack patterns, which can surface Electron-specific abuse risks (e.g. arbitrary command execution or planted JS) during architecture and engineering but does not instrument or monitor for runtime technique execution.
T1218.015prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, hardening, distrust-external-input, secure session control, data validation/sanitisation and zero-trust principles that reach the Electron abuse surface (JS sandboxing, command-line flags, child-process execution, planted scripts); these stop many but not all real-world Electron technique variants, especially those exploiting app-specific misconfigurations or unhardened third-party Electron apps.
T1219detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust principles (assume breach, never trust/always verify, strong auth), and ongoing review of engineering principles against new threats; these surface anomalous or risky remote-access tooling/behavior in design and operation but only for what falls inside the chosen architecture and review scope, leaving many post-compromise or living-off-the-land RAT uses undetected.
T1219prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, zero-trust, hardening, and secure-session principles that can stop many legitimate remote-access tools from being installed or from granting unauthenticated interactive C2, but cannot prevent all post-compromise abuse of already-permitted EDR response features, built-in modules (e.g. Chrome Remote Desktop), or admin-approved tools.
T1219.001detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and regular review of engineering principles against new threats; these surface anomalous IDE tunneling (e.g. unexpected remote sessions or extensions) during design, deployment or updates, but the clause is scoped to engineering processes and does not mandate runtime monitoring of production sessions.
T1219.001prevents — A.8.27 mandates establishing and applying secure engineering principles (security by design, least functionality/privilege, defense in depth, hardening, distrust external input, assume breach, zero-trust verification) plus security-oriented design reviews during the SDLC; these directly constrain or eliminate the IDE features, extensions, auto-reconnect, and tunneling that enable T1219.001 when applied to development tooling, but remain a slice because the control is a process that depends on implementation rigor and does not itself remove already-deployed IDEs or extensions on production systems.
T1219.002detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification of requests, and ongoing review of engineering principles to identify vulnerabilities and anomalous access patterns, which can surface misuse of legitimate remote desktop tools as C2; this is limited to what the organization's chosen architecture and monitoring scope elect to instrument rather than a universal detection mechanism.
T1219.002prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, zero-trust, hardening, and design reviews that can block many legitimate-desktop-support C2 vectors (e.g. by default-deny, strong auth, network segmentation, or removal of unnecessary RMM tools), but leaves a genuine slice unaddressed: sanctioned support tools that remain after risk analysis, outsourced development that still ships them, or legitimate business needs that survive the review.
T1219.003detects — A.8.27 mandates security-oriented design reviews, threat analysis, hardening, zero-trust principles, and ongoing review of engineering practices that surface hardware-based remote access risks (e.g., via assume-breach, distrust-external-input, or architecture reviews), but this is limited to what is caught in design/engineering phases rather than runtime detection of post-compromise hardware use.
T1219.003prevents — A.8.27 mandates security-by-design, defence-in-depth, least privilege, assume-breach, hardening, and zero-trust principles (never trust/always verify, contextual authz, end-to-end encryption) that can be applied to system architecture to reduce the attack surface and bypass potential of post-compromise hardware KVM implants, but does not stop physical installation or use of allowed peripheral remote-access hardware.
T1220detects — A.8.27 mandates security-oriented design reviews, threat analysis, hardening, and ongoing review of engineering principles against new threats/attack patterns, which surfaces XSL script processing risks in custom or reviewed systems but does not instrument runtime detection of the msxsl.exe/wmic abuse technique itself.
T1220prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, hardening, distrust-external-input and secure-engineering reviews that, when applied during development, stop XSL script processing from being enabled or reachable; this is a genuine but minority slice of the technique's attack surface (custom apps and bespoke deployment) while the dominant built-in Windows msxsl.exe / WMIC vectors remain untouched.
T1221detects — A.8.27 mandates security-oriented design reviews to identify vulnerabilities plus ongoing review of engineering principles against new threats; this surfaces template-injection patterns during design or when known in the wild, but the clause is silent on runtime/execution monitoring or detection of delivered documents.
T1221prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, distrust-external-input, hardening, and design reviews that explicitly consider known attack patterns; these directly constrain the class of template-reference abuses that embed external URLs or malicious payloads in documents, but the clause is a process requirement whose coverage still depends on how rigorously those principles are applied to every document format and parser, leaving a genuine minority slice unreached.
T1222detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of engineering principles against new threats; these surface permission-modification patterns (e.g. via assume-breach or design review) in the engineering process but do not instrument runtime detection of the post-deployment T1222 technique across all platforms.
T1222prevents — A.8.27 mandates applying security-by-design, least privilege, defence-in-depth, fail-secure and hardening principles during engineering, which directly constrains the design and deployment choices that would otherwise allow easy ACL/permission modification for evasion.
T1222.001detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of engineering principles to identify vulnerabilities and new threats, which can surface permission-modification patterns in Windows architecture or code but does not instrument runtime detection of the technique itself.
T1222.001prevents — A.8.27 mandates applying security-by-design, least privilege, defence-in-depth, fail-secure and hardening principles plus security-oriented design reviews that explicitly consider required controls, their capabilities to prevent events, and integration; this reaches the design-time slice that would stop ACL-modification techniques from being viable, but leaves a large remainder (runtime abuse of legitimate tools like icacls/takeown by already-authorized processes, post-design misconfigurations, and exceptions for safety requirements) unaddressed.
T1222.002detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of engineering principles that can surface permission-related weaknesses or anomalous permission changes during architecture, implementation, and operational reviews, but this is limited to what is caught in the engineering process rather than runtime detection of the live technique.
T1222.002prevents — A.8.27 mandates security-by-design principles (least privilege, default deny, fail securely, defence-in-depth, zero-trust verification) plus design reviews and hardening that, when applied during engineering, stop many permission-modification vectors from being introduced; it does not reach runtime enforcement or all post-deployment adversarial uses of chown/chmod.
T1480.002detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and regular review of principles against new threats/attack patterns, which can surface mutex-based single-instance or already-compromised checks during architecture and code review, but this is only a slice of possible implementations rather than broad runtime or post-deployment detection.
T1482detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust principles (assume breach, never trust/always verify, strong auth), and ongoing review of engineering principles against new threats; these surface anomalous trust-enumeration activity (e.g. via Nltest, LDAP queries) as part of monitoring for attack patterns, but only where the review/monitoring scope chosen by the implementer includes it.
T1484detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and regular review of engineering principles to identify vulnerabilities and new threats, which can surface risky policy configurations or modifications during design/implementation but does not mandate ongoing runtime detection of post-deployment adversarial changes to domain/tenant policy.
T1484prevents — A.8.27 mandates applying security-by-design, least privilege, default-deny, assume-breach, zero-trust and defence-in-depth principles plus security-oriented design reviews that explicitly consider required controls, their integration and known attack patterns; this constrains many of the policy-modification vectors (e.g. overly permissive trusts, GPO abuse, rogue federation) at design time, but the technique can still be executed post-deployment by an already-privileged actor, leaving a genuine minority slice prevented.
T1484.001detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification of requests, and ongoing review of principles against new threats; these surface anomalous GPO modifications or violations of least-privilege/dynamic-access expectations in an AD domain, but only where the review/monitoring scope chosen by the implementer includes them.
T1484.001prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, zero-trust and secure-engineering reviews that reach GPO ACLs, hardening and privilege-delegation decisions, thereby stopping many (but not all) modification paths before they can be introduced.
T1484.002detects — A.8.27 mandates security-oriented design reviews, threat analysis, and ongoing review of engineering principles to identify vulnerabilities and keep up with new threats; this surfaces some trust-modification vectors (especially during design or when new federation/IdP tech is introduced) but does not monitor or detect post-deployment runtime or configuration changes to live trusts.
T1484.002prevents — A.8.27 mandates security-by-design, zero-trust, least-privilege, distrust-external-input, and secure architecture principles that, when applied during engineering, stop many trust-modification vectors (e.g., by enforcing never-trust/always-verify, end-to-end encryption of requests, and proper federation/claim rules); residual attack surface remains because the control is a process that depends on implementation rigor and does not reach every possible trust-configuration mistake an adversary could exploit post-deployment.
T1485prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, hardening, zero-trust and secure engineering reviews that can stop many T1485 vectors (e.g. by removing destructive commands, enforcing strong auth, limiting lateral movement) but leaves residual paths (e.g. insider or already-breached admin rights that still allow deletion).
T1485recovers — A.8.27 mandates security-by-design principles (defence-in-depth, fail-securely, least functionality, zero-trust, hardening, integrated controls) that can produce recoverable architectures (e.g. off-line backups, immutable snapshots, redundant storage) when applied to availability threats, but the clause itself only requires the principles be established/reviewed/applied and does not own or execute the recovery action.
T1485.001detects — A.8.27 mandates security-oriented design reviews, threat analysis, zero-trust verification, and ongoing review of engineering principles to surface vulnerabilities and new threats; this can detect risky lifecycle policy designs or anomalous modifications in IaaS storage before or during use, but only for a slice (e.g., reviewed systems or monitored engineering), not broadly across deployed buckets or runtime policy changes.
T1485.001prevents — A.8.27 mandates security-by-design, least-privilege, zero-trust, defence-in-depth and hardening principles plus design reviews that, when applied to cloud storage engineering, constrain the ability to set destructive lifecycle policies; the coverage is only a slice because the clause is a process/governance requirement whose effectiveness depends on how rigorously those principles are implemented in the specific IaaS configuration and contracts.
T1489detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust monitoring principles, and regular review of engineering practices against new threats, which surfaces anomalous service-stop activity as part of integrated controls and assume-breach posture, but only where those practices explicitly include runtime/operational monitoring rather than purely design-time activities.
T1489prevents — A.8.27 mandates security-by-design, defence-in-depth, least privilege, least functionality, hardening, assume-breach and zero-trust principles that, when applied during engineering, can remove many service-stop vectors (e.g. by restricting admin rights, removing unnecessary services, enforcing strong auth on management APIs); this is genuine but only a slice of the class, as runtime process/service control, cloud IAM misconfigurations and post-deployment admin actions remain outside the engineering-principles clause.
T1491detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust monitoring principles, and regular review of engineering practices that surface anomalous modifications (including defacement) when those are in scope of the chosen architecture and threat models, but the clause itself sets requirements rather than mandating any specific detection mechanism or coverage depth.
T1491prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, hardening, secure session control, input sanitisation and assume-breach principles that, when applied during engineering, stop many common vectors (e.g. weak auth, unvalidated uploads, missing integrity checks) that adversaries use to reach and alter visual content, but leaves residual paths such as post-compromise credential abuse or supply-chain insertion that the clause does not itself block.
T1491.001detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust monitoring principles, and regular review of engineering practices against new threats, which surfaces anomalous internal modifications (e.g. via integrity checking or assume-breach detection) in a slice of cases but does not mandate runtime detection mechanisms for post-intrusion defacement.
T1491.001prevents — A.8.27 mandates security-by-design, defense-in-depth, least privilege, hardening, secure defaults, assume-breach, and explicit reviews against known attack patterns; these stop many classes of internal defacement (e.g., by blocking the write paths or privilege escalation that enable wallpaper/login/website changes) but leave residual paths (e.g., post-breach admin sessions or supply-chain compromises that bypass the engineered controls).
T1491.002detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust monitoring principles, and regular review of engineering practices against new threats, which surfaces anomalous defacement of external systems as part of operational security but only within the scoped architecture and review processes rather than universal detection.
T1491.002prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, hardening, security-oriented design reviews, and zero-trust principles that reduce the attack surface and block common external-defacement vectors (e.g. injection, weak auth, misconfiguration) when applied to externally-facing systems; it does not stop every possible vector (e.g. supply-chain compromise of a third-party CMS or zero-day in the web stack itself).
T1495detects — A.8.27 mandates security-oriented design reviews, threat analysis, hardening, and ongoing review of principles to identify vulnerabilities including those enabling firmware attacks, but does not mandate runtime or operational detection mechanisms for the technique itself.
T1495prevents — A.8.27 mandates security-by-design, defense-in-depth, least-privilege, hardening, assume-breach, and zero-trust principles plus design reviews that explicitly consider attack patterns; these reduce the likelihood an adversary can reach and corrupt firmware, but the control is a set of engineering practices rather than a concrete mechanism that stops every possible firmware write path (especially on already-deployed devices or supply-chain vectors).
T1496detects — A.8.27 mandates security-oriented design reviews, threat analysis, hardening, zero-trust monitoring principles, and regular review of engineering practices that surface anomalous resource consumption or hijacking indicators during design, deployment and operation, but only where those practices are scoped into the organization's chosen architecture and monitoring (a slice, not the bulk).
T1496prevents — A.8.27 mandates security-by-design, least functionality/privilege, hardening, assume-breach, and zero-trust principles that can stop many hijacking vectors (e.g. by removing unnecessary compute, restricting outbound bandwidth, enforcing strong auth on cloud services) but leaves open vectors that still satisfy those principles or arise from configuration/implementation gaps.
T1496.001detects — A.8.27 mandates security-oriented design reviews, threat analysis, hardening, zero-trust monitoring principles, and regular reviews that surface anomalous compute usage or resource hijacking in architecture and deployment, but this is limited to what the organization chooses to instrument and review rather than broad runtime detection of the technique.
T1496.001prevents — A.8.27 mandates security-by-design, least functionality/privilege, hardening, zero-trust verification and threat-aware reviews that can stop many hijacking vectors (e.g. exposed APIs, weak defaults, unnecessary compute services) but leaves residual paths such as post-compromise execution after initial access or insider-enabled mining.
T1496.002detects — A.8.27 mandates security-oriented design reviews, threat analysis, zero-trust monitoring principles, and ongoing review of engineering practices that surface anomalous bandwidth consumption or proxying behaviors as part of assume-breach and never-trust verification, but only where those tie into the chosen architecture and monitoring scope rather than guaranteeing detection of all hijacking vectors.
T1496.002prevents — A.8.27 mandates security-by-design, defense-in-depth, least functionality/privilege, assume-breach, hardening, and zero-trust network controls that can stop many bandwidth-hijacking vectors (e.g., by limiting outbound connections, removing unnecessary services, enforcing authenticated/encrypted channels, and reducing attack surface), but leaves open vectors that still succeed under those principles such as supply-chain malware, insider compromise, or zero-days that bypass the engineered controls.
T1496.003detects — A.8.27 mandates security-oriented design reviews, threat analysis, zero-trust verification, and ongoing review of engineering principles to identify vulnerabilities and new threats; this surfaces SMS-pumping abuse of public forms/OTP fields as an availability/cost risk during design or review, but only for in-scope systems and does not mandate runtime detection of the technique itself.
T1496.003prevents — A.8.27 mandates security-by-design, defence-in-depth, least functionality, distrust-external-input, security reviews against attack patterns, and hardening that can block the abused OTP/verification forms or rate-limit the messaging calls, but these are only principles applied where the implementer chooses and do not guarantee coverage of every SaaS messaging integration or outsourced development path.
T1496.004detects — A.8.27 requires security-oriented design reviews, threat analysis, zero-trust verification, and ongoing review of engineering principles that surface anomalous SaaS enablement, resource spikes, or hijacking patterns during architecture and deployment reviews, but this is limited to what the organization chooses to include in its reviews rather than continuous runtime detection of the technique.
T1496.004prevents — A.8.27 mandates security-by-design, zero-trust, least-privilege, default-deny and hardening principles plus design reviews that, when applied to SaaS enablement/authorization layers, stop many hijacking paths before the adversary can first enable or abuse the service; residual paths remain because the clause is a process that depends on implementation rigour and does not itself block every compromised credential or insider-enabled service.
T1497prevents — A.8.27 mandates security-by-design, defense-in-depth, assume-breach, least-privilege, hardening, and zero-trust principles that shape architecture and engineering so many common VME/sandbox artifacts and detection vectors are simply absent or harder to fingerprint; this stops the technique from succeeding in those engineered environments, but does not eliminate all possible checks or custom analysis environments.
T1497.001prevents — A.8.27 mandates security-by-design, defence-in-depth, assume-breach, least-privilege, hardening, and explicit analysis of controls against known attack patterns; these principles applied during engineering can preclude many classes of VME/Sandbox-Evasion checks (e.g. by removing detectable artifacts, enforcing consistent hardware profiles, or designing out reliance on perimeter-only trust), but do not stop an adversary from still performing the discovery techniques on a correctly engineered system.
T1497.002prevents — A.8.27 mandates security-by-design, defense-in-depth, least privilege, assume-breach, distrust-external-input, hardening, and zero-trust verification that together constrain sandbox/VME evasion checks and user-activity triggers in the engineered product.
T1497.003prevents — A.8.27 mandates security-by-design, defence-in-depth, assume-breach, least functionality and hardening principles plus design reviews that can surface and eliminate time-based anti-analysis checks before deployment, but does not mandate or guarantee their removal from every possible implementation or third-party component.
T1498detects — A.8.27 mandates security-oriented design reviews, threat analysis, and ongoing review of principles to identify vulnerabilities and new threats, which can surface Network DoS risks (e.g., via attack pattern review or zero-trust assumptions), but does not itself perform detection of the technique in operation.
T1498prevents — A.8.27 mandates security-by-design, defence-in-depth, least functionality, assume-breach, hardening, and explicit analysis of controls that can prevent events; these principles applied during architecture and engineering reduce the attack surface and bandwidth-exhaustion vectors for Network DoS (e.g. via rate limiting, anti-spoofing, or capacity planning), but cannot stop all volumetric or reflection attacks launched from outside the engineered boundary.
T1498.001detects — A.8.27 mandates security-oriented design reviews, threat analysis, zero-trust monitoring principles, and ongoing review of engineering practices that surface anomalous traffic patterns or DDoS risks in architecture, but does not itself instrument or perform detection of live network floods.
T1498.001prevents — A.8.27 mandates security-by-design, defence-in-depth, least functionality, assume-breach, hardening, and explicit analysis of controls that can prevent events; these principles applied during architecture and engineering can remove or constrain the exposed attack surface (e.g. rate-limiting, traffic scrubbing architecture, or protocol restrictions) that a direct network flood exploits, but do not stop an external botnet flood once the service is reachable on the Internet.
T1498.002detects — A.8.27 mandates security-oriented design reviews, threat analysis, and ongoing review of engineering principles to identify vulnerabilities and new threats, which can surface reflection/amplification risks in protocol or architecture choices, but does not itself instrument or monitor for the live network event.
T1498.002prevents — A.8.27 mandates security-by-design, defense-in-depth, least functionality, assume-breach, and hardening plus explicit analysis of controls that can prevent events; these principles applied during engineering can remove many amplification vectors (e.g., by disabling open reflectors, enforcing BCP38-style anti-spoofing, or requiring protocol hardening), but the control is a process that depends on implementation rigor and does not guarantee every possible reflector or protocol is secured, leaving a genuine minority slice unaddressed.
T1499detects — A.8.27 mandates security-oriented design reviews, threat analysis, and ongoing review of engineering principles to identify vulnerabilities and keep practices current against new threats, which surfaces some Endpoint DoS risks (e.g., via resource exhaustion patterns or weak defaults) in the design/implementation phase but does not instrument or monitor for the live technique.
T1499prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, fail-securely, hardening, and zero-trust principles that can stop many endpoint resource-exhaustion or crash-condition DoS vectors at design time; it does not reach every implementation detail, runtime configuration, or all botnet/spoofing vectors an adversary may still exploit.
T1499.001detects — A.8.27 mandates security-oriented design reviews, threat analysis, and ongoing review of principles to identify vulnerabilities and new threats, which can surface OS-exhaustion DoS risks in architecture (e.g. via known attack patterns like SYN/ACK floods), but does not mandate runtime detection mechanisms.
T1499.001prevents — A.8.27 mandates applying security-by-design, defense-in-depth, least functionality, fail-securely, assume-breach and hardening principles plus explicit analysis of required controls (including boundary protection) during architecture and engineering; these directly constrain or eliminate many OS-exhaustion vectors (e.g., SYN-flood limits, connection-table tuning, protocol hardening) before the system is built or deployed, but the clause is a process that depends on implementation rigor and does not guarantee every possible TCP-state or resource-limit attack is designed out.
T1499.002detects — A.8.27 mandates security-oriented design reviews, threat analysis, zero-trust verification, and ongoing review of principles against new threats, which surfaces some service-exhaustion risks (e.g., via assume-breach or request-validation gaps) in architecture but does not instrument or monitor for the runtime technique itself.
T1499.002prevents — A.8.27 mandates security-by-design, defence-in-depth, least functionality, fail-secure, hardening, and zero-trust principles that can eliminate or constrain many service-exhaustion vectors (e.g., by removing unnecessary services, enforcing rate limits, or designing protocols without renegotiation abuse), but leaves residual exposure to volumetric floods or implementation-specific flaws that require runtime controls outside the engineering principles themselves.
T1499.003detects — A.8.27 mandates security-oriented design reviews, threat analysis against known attack patterns, and ongoing review of principles to combat new threats, which surfaces resource-exhaustion DoS risks during engineering but does not instrument runtime detection of the live technique.
T1499.003prevents — A.8.27 mandates security-by-design, defence-in-depth, least functionality, fail-securely, hardening, and design reviews that explicitly consider attack patterns and resource-exhaustion threats, which stops many application-exhaustion vectors from being introduced; it does not guarantee every resource-intensive feature is removed or rate-limited, leaving a genuine minority slice unaddressed.
T1499.004detects — A.8.27 mandates security-oriented design reviews, analysis of controls' detection capabilities, hardening, and ongoing review of principles against new threats/attack patterns, which surfaces exploitable vulnerabilities (including those leading to crashes) during engineering but does not instrument runtime detection of the exploitation technique itself.
T1499.004prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, fail-securely, hardening, and explicit analysis of controls against known attack patterns and vulnerabilities, which stops many exploitable crash conditions from being introduced; it does not reach zero-days, all implementation bugs, or every runtime configuration that could still allow re-exploitation.
T1505detects — A.8.27 mandates security-oriented design reviews, analysis of controls' detection capabilities, hardening, and ongoing review of principles against new threats, which surfaces some abuse of extensible server components during design, implementation, or post-deployment review, but does not mandate runtime detection mechanisms or monitoring that would catch the technique in operation across all platforms.
T1505prevents — A.8.27 mandates security-by-design, defence-in-depth, least functionality/privilege, hardening, and design reviews that explicitly consider attack patterns; these directly constrain the insertion of malicious extensible server components when applied during development, but the clause is a process requirement whose coverage depends on rigour of implementation and does not reach already-deployed systems or outsourced development that fails to align.
T1505.001detects — A.8.27 mandates security-oriented design reviews, threat analysis against known attack patterns, and ongoing review of engineering principles to identify vulnerabilities including those enabling persistence mechanisms like malicious stored procedures; this surfaces the technique in design/implementation but is scoped only to engineering activities and does not broadly instrument runtime detection.
T1505.001prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, secure coding, hardening, and review against known attack patterns across the SDLC (including outsourced development); this reaches the design and implementation of stored-procedure logic, CLR assemblies, and startup hooks that adversaries abuse for persistence, but leaves residual gaps (e.g., misconfigurations or post-deployment changes) so the coverage is a genuine but incomplete slice.
T1505.002detects — A.8.27 mandates security-oriented design reviews, threat analysis, and ongoing review of engineering principles to identify vulnerabilities and new threats, which can surface the abuse of transport agents during development or registration but does not mandate runtime detection mechanisms for the deployed persistence technique.
T1505.002prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, hardening, security-oriented design reviews and zero-trust principles applied across the engineering lifecycle (including outsourced development); these directly constrain the introduction and registration of malicious transport agents, but the control is a set of principles and reviews rather than an enforcement mechanism that guarantees the specific weakness cannot arise, leaving a genuine implementation-dependent slice.
T1505.003detects — A.8.27 mandates security-oriented design reviews to identify vulnerabilities plus ongoing review of principles against new threats; this surfaces some web shell insertion vectors (e.g. via insecure architecture or unhardened servers) but does not instrument or monitor for the deployed web shell itself at runtime.
T1505.003prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, hardening, secure coding (including input sanitisation and output encoding), and zero-trust principles that stop many classes of web-server flaws an adversary would exploit to plant a web shell; it does not guarantee the absence of every possible injection or misconfiguration vector that could still allow one.
T1505.004detects — A.8.27 mandates security-oriented design reviews, threat analysis, and ongoing review of engineering principles to identify vulnerabilities and ensure controls combat new threats, which can surface IIS component installation risks in architecture and code review but does not mandate runtime or operational detection mechanisms.
T1505.004prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, hardening, security-oriented design reviews and zero-trust principles that, when applied during IIS component engineering, stop many malicious ISAPI/filter/module installation paths; the remainder is post-compromise or misconfigured deployment vectors outside the engineering process.
T1505.005detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and regular review of engineering principles against new threats/attack patterns, which can surface anomalous Terminal Services DLL modifications or RDP abuse during design, testing or monitoring of the architecture, but only reaches a slice (e.g. via reviews or threat analysis) rather than broadly instrumenting runtime detection of the post-deployment technique.
T1505.005prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, hardening, security-oriented design reviews, and zero-trust principles that reach the Terminal Services/RDP surface; these stop most (but not all) ways an adversary can introduce or swap a malicious termsrv.dll or ServiceDll pointer before the technique can run.
T1505.006detects — A.8.27 mandates security-oriented design reviews, threat analysis, hardening, and regular review of engineering principles to identify vulnerabilities and new threats; this surfaces malicious VIB abuse in design/maintenance but only for systems built or reviewed under the control, leaving runtime detection of deployed malicious VIBs on ESXi outside its scope.
T1505.006prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, hardening, zero-trust verification, secure deployment and design reviews that explicitly consider attack patterns; these principles, when applied to hypervisor engineering and supplier contracts, stop malicious VIBs from being installable or boot-persistent in the bulk of cases, but the technique can still succeed via privileged esxcli --force or acceptance-level tampering on systems whose engineering process did not fully enforce the listed principles.
T1518detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust monitoring principles, and regular review of engineering practices against new threats, which surfaces anomalous software enumeration as part of assume-breach or defense-in-depth but does not mandate runtime detection mechanisms for the technique itself.
T1518prevents — A.8.27 mandates security-by-design, defense-in-depth, least functionality/privilege, hardening, assume-breach, and zero-trust principles that reduce the attack surface and limit what an adversary can enumerate or act upon after initial access, but does not stop the discovery technique itself from running on a compromised host.
T1518.001detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust architecture, and ongoing review of engineering principles to identify vulnerabilities and integrate detection-capable controls (e.g., monitoring agents, IAM), which surfaces discovery attempts in designed systems but does not itself instrument or perform detection.
T1518.001prevents — A.8.27 mandates security-by-design, defense-in-depth, least privilege, assume-breach, hardening, and zero-trust principles that reduce the attack surface and make discovery of defensive tools harder or less useful, but does not stop the technique itself from executing via standard commands or APIs.
T1518.002detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust monitoring principles, and regular review of engineering procedures to surface new threats; this can detect anomalous backup-software discovery commands or patterns during operation or review, but the clause is primarily about architecture/engineering rather than runtime detection tooling and leaves most post-deployment execution unobserved.
T1525detects — A.8.27 mandates security-oriented design reviews, analysis of controls (including detection capabilities), hardening, and regular review of principles against new threats; this surfaces risks in image handling and backdooring during architecture/engineering but does not mandate or perform runtime/operational detection of an already-implanted image in a registry.
T1525prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, hardening, security-oriented design reviews, and analysis of controls against threats/attack patterns; these directly constrain the ability to implant a malicious image in a registry or to provision from a backdoored image, but only where the engineering process is followed and does not reach post-compromise registry writes by an already-privileged adversary.
T1526detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, assume-breach monitoring integration, and regular review of engineering principles against new threats; this surfaces anomalous discovery/enumeration attempts in designed systems but only where those principles are applied to the runtime architecture and monitoring scope, leaving a large slice of post-compromise API calls and tools (e.g. Pacu, Stormspotter) outside the engineering process.
T1526prevents — A.8.27 mandates security-by-design, defence-in-depth, least privilege, assume-breach, zero-trust and hardening principles that, when applied during architecture and engineering, constrain many discovery vectors (e.g. by removing unnecessary services, enforcing least functionality, and limiting what an identity can enumerate), but leaves a genuine remainder of legitimate services that must still be discoverable by authorized identities and cannot be designed away.
T1528detects — A.8.27 mandates security-oriented design reviews, threat analysis, and ongoing review of engineering principles to identify vulnerabilities and keep practices current against new threats; this surfaces token-theft risks in architecture, CI/CD, OAuth flows, and zero-trust gaps during design and review, but does not instrument runtime detection of the technique itself.
T1528prevents — A.8.27 mandates security-by-design principles (least privilege, zero-trust/never-trust-always-verify, defence-in-depth, secure session control, hardening, distrust-external-input) that are applied across the SDLC and to outsourced development, directly constraining many token-theft vectors (e.g. weak OAuth flows, overly permissive service accounts, unhardened containers, missing context-aware authz); it does not reach social-engineering phishing for consent or post-compromise token extraction from already-breached runtimes, leaving a genuine minority slice prevented.
T1529detects — A.8.27 mandates security-oriented design reviews, threat analysis, zero-trust monitoring principles, and ongoing review of engineering practices that surface anomalous shutdown/reboot behaviors or related privilege abuse in architecture, but does not itself instrument or perform detection.
T1529prevents — A.8.27 mandates security-by-design, least privilege, fail-securely, hardening, and zero-trust principles that can block many privilege-acquisition and command-execution paths used to trigger shutdown/reboot, but leaves residual vectors (e.g., physical access, hypervisor-level, or already-privileged insiders) unaddressed.
T1530detects — A.8.27 mandates security-oriented design reviews, threat analysis, and ongoing review of principles to identify vulnerabilities and new threats, which can surface misconfigurations or weak access controls enabling T1530, but does not mandate runtime detection or monitoring of the technique itself.
T1530prevents — A.8.27 mandates security-by-design, zero-trust, least-privilege, default-deny, hardening, and explicit review of controls (including IAM, encryption, and access architecture) that directly stop the misconfigurations and weak IAM that enable unauthenticated or overly-broad cloud-storage access; it is only partial because the clause is a process that depends on how rigorously those principles are applied to every cloud deployment.
T1531detects — A.8.27 mandates security-oriented design reviews, threat analysis, zero-trust verification, and ongoing review of engineering principles that surface anomalous account manipulations or violations of least-privilege/dynamic-access rules, but this is limited to what the architecture and reviews are scoped to catch rather than broad runtime detection of the post-compromise technique.
T1531prevents — A.8.27 mandates security-by-design principles (least privilege, defence-in-depth, assume-breach, zero-trust verification, hardening, secure IAM integration) that, when applied during engineering, constrain many of the account-manipulation vectors (e.g. overly permissive defaults, weak credential handling, missing MFA, unsafe admin interfaces) but do not block post-compromise execution of the listed tools/utilities once an adversary already has the necessary privileges.
T1534detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust principles (assume breach, never trust/always verify, strong auth), and ongoing review of engineering principles against new threats; these surface indicators of internal spearphishing campaigns (e.g. anomalous internal messages, impersonation patterns, or unverified requests) during design and operation but do not mandate runtime detection mechanisms across all vectors like chat apps or attachments.
T1534prevents — A.8.27 mandates security-by-design, defense-in-depth, least privilege, zero-trust/never-trust-always-verify, hardening, and secure engineering that explicitly covers authentication techniques, session control, data validation/sanitization, and distrust of external input; these directly stop many internal spearphishing vectors (e.g. phishing links, fake login sites, malicious chat payloads) when applied, but the control is a process that does not guarantee uniform enforcement across all users, chat apps, or legacy internal trust paths, leaving a genuine minority slice unaddressed.
T1535detects — A.8.27 mandates security-oriented design reviews, threat analysis, zero-trust verification of all requests, and ongoing review of principles against new threats, which surfaces the use of unmonitored/unsupported regions as a detectable design or configuration risk during engineering and review.
T1535prevents — A.8.27 mandates security-by-design, defence-in-depth, least functionality, assume-breach, zero-trust and architecture reviews that can constrain unused-region creation (e.g. by enforcing approved-region lists, dynamic access controls and integrated monitoring), but the clause is a set of high-level engineering principles rather than an enforceable mechanism, leaving most of the technique reachable via compromised accounts or regional variances.
T1537detects — A.8.27 mandates security-oriented design reviews, threat analysis, zero-trust principles, and ongoing review of engineering practices that surface anomalous internal transfers and misconfigurations enabling T1537, but only where those practices are applied to the specific systems and monitoring scope chosen by the implementer.
T1537prevents — A.8.27 mandates security-by-design, zero-trust, least-privilege, default-deny and distrust-external-input principles plus design reviews that, when applied to cloud architectures, stop many intra-provider transfer paths (e.g. by requiring strong per-request authz and removing broad IAM that would let an adversary-controlled account pull data); residual paths remain because the clause sets engineering requirements rather than mandating a universal mechanism that closes every cloud-native sharing or backup API.
T1538detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust principles, and ongoing review of engineering practices that surface anomalous access or configuration risks (e.g. via assume-breach, least privilege, and dashboard-related design scrutiny), but this is indirect governance of the development process rather than runtime detection of the post-compromise GUI usage itself.
T1538prevents — A.8.27 mandates security-by-design, least privilege, zero-trust/never-trust-always-verify, defence-in-depth and hardening principles that, when applied during engineering, constrain the attack surface and credential utility for dashboard enumeration; this is genuine but only a slice because the technique still succeeds against any already-breached or misconfigured cloud tenant that the principles did not govern.
T1539detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of principles to identify vulnerabilities and new threats; this surfaces some session-cookie theft vectors (e.g., via malicious JS, proxy/AiTM, or weak auth design) in the engineering phase or through architecture analysis, but does not instrument runtime detection of the technique itself.
T1539prevents — A.8.27 mandates security-by-design principles (secure session control, defence-in-depth, least privilege, zero-trust “never trust/always verify”, end-to-end encryption of requests, hardening) that directly address session-cookie theft vectors such as insecure transmission, weak session management, and perimeter-only reliance; these stop many but not all T1539 paths (e.g. post-auth local malware theft from browser memory or malicious JS injection after user execution remain outside the clause’s engineering focus).
T1542detects — A.8.27 mandates security-oriented design reviews, analysis of controls' detection capabilities, hardening, and zero-trust monitoring principles that surface some pre-OS anomalies (e.g. via firmware integrity checks or assume-breach verification), but does not itself perform or require runtime detection of the T1542 technique once it has run at the firmware layer.
T1542prevents — A.8.27 mandates security-by-design, defence-in-depth, least privilege, hardening, assume-breach, and secure boot/firmware review within the engineering life cycle, which stops many classes of pre-OS boot abuse from being introduced; it does not reach every platform or every supply-chain firmware modification, leaving a bounded remainder.
T1542.001detects — A.8.27 mandates security-oriented design reviews, threat analysis, and ongoing review of engineering principles to identify vulnerabilities including those in firmware, but does not itself perform or require runtime/operational detection of the T1542.001 technique once deployed.
T1542.001prevents — A.8.27 mandates security-by-design, defence-in-depth, least privilege, hardening, assume-breach, and zero-trust principles plus design reviews that explicitly consider firmware-level threats and controls, which can stop modification/persistence at the architecture stage; it reaches only a slice because firmware flashing is ultimately a physical or privileged-runtime act whose concrete prevention lives in lower-layer mechanisms (e.g. 8.2, 8.5, 8.18) not required by this clause.
T1542.002detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of principles against new threats, which surfaces component-firmware risks during engineering but does not instrument runtime detection of deployed malicious firmware implants.
T1542.002prevents — A.8.27 mandates security-by-design, defence-in-depth, least privilege, hardening, assume-breach, and security-oriented design reviews that analyse threats and known attack patterns; these directly constrain the ability to introduce or leave the modifiable firmware surfaces that T1542.002 exploits, but only for systems built under the control and only to the degree the principles are actually applied (implementation slice, not bulk).
T1542.003detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust principles, and regular review of engineering practices to identify vulnerabilities and new threats, which can surface bootkit risks in architecture (e.g., via assume-breach or EFI/MBR analysis), but does not mandate or perform runtime/operational detection of an active bootkit technique.
T1542.003prevents — A.8.27 mandates security-by-design, defense-in-depth, least privilege, assume-breach, hardening, and secure boot principles that can stop boot-sector or EFI modifications at design and deployment time; this is a genuine but minority slice of the technique's full attack surface (raw boot-drive access after compromise, firmware-level persistence that survives OS reinstalls).
T1542.004detects — A.8.27 mandates security-oriented design reviews, analysis of controls' detection capabilities, hardening, zero-trust verification, and regular reviews for new threats, which surfaces ROMMON firmware tampering risks during engineering but does not instrument runtime detection of the post-deployment technique itself.
T1542.004prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, hardening, assume-breach, and explicit review of designs against known attack patterns plus full control analysis; this reaches the firmware/boot-loader layer for many devices and would stop most ROMMON replacement vectors, but the control is a process that depends on implementation rigour and does not guarantee detection or blocking of every supply-chain or physical-access vector on every legacy network device.
T1542.005detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification of requests, and ongoing review of principles against new threats; these surface anomalous boot behavior or unauthorized TFTP usage in reviewed architectures but do not instrument runtime detection of the technique itself across all network devices.
T1542.005prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, hardening, assume-breach, and secure boot/engineering review practices that can block unauthorized TFTP netboot configuration changes or malicious images on managed devices; this is only a slice of the technique because the clause is a process that depends on implementation rigour and does not itself enforce network-level TFTP restrictions or immutable bootloaders on every legacy platform.
T1543detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of engineering principles to identify vulnerabilities and new threats, which can surface T1543 indicators during architecture reviews or anomaly detection in system processes, but this is limited to what the design/engineering process explicitly inspects rather than broad runtime detection.
T1543prevents — A.8.27 mandates security-by-design, least privilege, default-deny, hardening, and zero-trust principles that constrain how system processes/services are created or modified, but does not stop an adversary who has already obtained the privileges needed to install or alter them.
T1543.001detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and regular review of engineering principles to identify vulnerabilities and new threats, which can surface anomalous launch-agent behavior or persistence patterns during design/operation but does not mandate runtime monitoring or scanning that would catch post-deployment technique use.
T1543.001prevents — A.8.27 mandates security-by-design, least privilege, default-deny, hardening, and secure engineering reviews that can stop malicious launch-agent .plist files from being introduced or surviving review in systems built under it; this is a genuine but minority slice of the technique (most real-world instances are post-compromise modifications of already-running systems, not defects introduced at engineering time).
T1543.002detects — A.8.27 mandates security-oriented design reviews, threat analysis, and ongoing review of engineering principles to identify vulnerabilities and ensure controls combat new threats, which can surface systemd service abuse during design, implementation or review — but this is limited to the development/engineering process and does not broadly instrument or monitor deployed runtime systemd activity.
T1543.002prevents — A.8.27 mandates applying security-by-design, least privilege, default-deny, fail-secure, hardening, and zero-trust principles during engineering; these constrain how systemd services can be created or modified (e.g. by enforcing hardened defaults, least-privilege User= directives, and secure generator behavior), but the control is a process that depends on implementation rigor and does not eliminate all possible service-file or generator-based persistence paths.
T1543.003prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, least-functionality, hardening, secure defaults and zero-trust principles that constrain service creation/modification paths and privilege escalation, but leaves open many implementation-specific service-registry and driver-loading vectors that can still be abused for persistence.
T1543.004detects — A.8.27 mandates security-oriented design reviews, threat analysis, hardening, and ongoing review of engineering principles to identify vulnerabilities and ensure controls combat new threats, which can surface Launch Daemon abuse during architecture reviews or hardening checks, but this is limited to the development/engineering phase and does not broadly instrument runtime detection of the technique post-deployment.
T1543.004prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, least-functionality, hardening, secure defaults and zero-trust review of architecture layers and new technology against known attack patterns; these principles applied during engineering would stop many (but not all) unsafe LaunchDaemon creation/modification patterns on macOS.
T1543.005detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of engineering principles to surface vulnerabilities and misconfigurations in system architecture, which can detect some adversarial modifications to container services (e.g., via reviews of DaemonSets or restart policies), but does not mandate runtime monitoring or anomaly detection for the technique itself.
T1543.005prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, least-functionality, hardening, secure reviews and zero-trust principles that can stop many of the container-service modifications and DaemonSet abuses named in the technique, but the control is a set of engineering principles rather than an enforceable runtime mechanism and leaves slices (e.g. misconfigured restart policies or privileged docker access) reachable when those principles are not fully applied.
T1546detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification of requests, and ongoing review of principles against new threats, which surfaces some event-trigger abuse patterns during architecture and engineering but does not instrument runtime detection of the technique itself.
T1546prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, fail-secure, hardening, and zero-trust principles that can stop many classes of event-trigger abuse (e.g. by removing unnecessary triggers, enforcing strict ACLs on trigger registration, or requiring strong auth on invocation), but leaves a genuine remainder (e.g. legitimate business-required triggers that can still be repurposed post-compromise) so the coverage is only a slice rather than mostly.
T1546.001detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification of requests, and regular review of principles against new threats; these surface anomalous file associations or registry tampering during design, deployment or ongoing review, but only where the review scope and threat-model depth include this Windows-specific persistence vector (a chosen slice rather than mandated bulk coverage).
T1546.001prevents — A.8.27 mandates security-by-design, least privilege, default-deny, hardening, and secure-engineering reviews that can stop unsafe default-file-association changes from being introduced or left in production systems; this is a genuine but minority slice of the technique's attack surface (registry writes remain possible post-deployment, via admin rights or supply-chain compromise).
T1546.002detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and regular review of principles against new threats, which can surface anomalous screensaver-based persistence in architecture or during reviews, but only as a slice of possible detection rather than a dedicated or comprehensive mechanism.
T1546.002prevents — A.8.27 mandates security-by-design principles (least privilege, default-deny, fail-secure, hardening, security-oriented design reviews) that reach the registry-based configuration and PE-execution path used by T1546.002, but the clause is a process requirement whose coverage depends on how rigorously those principles are applied to every screensaver-related setting and component, leaving a genuine slice unreached.
T1546.003detects — A.8.27 mandates security-oriented design reviews, threat analysis, and ongoing review of engineering principles to identify vulnerabilities and new threats, which can surface WMI-based persistence techniques during development or architecture review, but does not mandate runtime detection or monitoring of deployed subscriptions.
T1546.003prevents — A.8.27 mandates security-by-design principles (least privilege, default deny, assume breach, distrust external input, hardening, security-oriented design reviews) that reach the WMI subscription technique when applied during engineering, but the control is a process that depends on implementation rigour and does not itself block the technique on already-deployed systems or in outsourced development that deviates from the principles.
T1546.004prevents — A.8.27 mandates security-by-design, hardening, least-privilege, default-deny, distrust-external-input and security-oriented design reviews that, when applied to shell configuration handling, stop malicious insertion into /etc/profile, ~/.bash* and ~/.z* files; this is a genuine but minority slice of the technique (most real-world abuse occurs via post-compromise file writes that the engineering principles do not themselves block).
T1546.006detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and regular review of principles against new threats; these surface tainted binaries or anomalous dylib loads in reviewed/outsourced engineering but do not instrument runtime detection of the post-build technique on deployed macOS systems.
T1546.006prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, hardening, and secure-engineering reviews that can stop tainted Mach-O binaries or unsafe LC_LOAD_DYLIB additions from reaching production, but the clause is a process that depends on implementation rigour and does not guarantee prevention of every such binary modification.
T1546.007detects — A.8.27 mandates security-oriented design reviews, threat analysis against known attack patterns, hardening, and ongoing review of engineering principles to surface vulnerabilities; this can detect the insecure Netsh Helper DLL registration pattern during architecture/implementation review or hardening, but only where the organization explicitly includes persistence mechanisms and registry-based auto-execution in its review scope.
T1546.007prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, hardening, and secure-engineering reviews that can stop unsafe Netsh helper-DLL registration at design or hardening time; the control does not reach every implementation or every post-deployment change, leaving a genuine minority slice unaddressed.
T1546.008detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of principles against new threats/attack patterns, which can surface accessibility-feature abuse in architecture and engineering but does not mandate runtime detection mechanisms or monitoring that would catch the technique post-deployment.
T1546.008prevents — A.8.27 mandates establishing and applying security engineering principles (security by design, least privilege, default deny, fail securely, hardening, security-oriented design reviews, and zero-trust verification) to the full development life cycle; these directly constrain the design and implementation choices that allow binary replacement, registry pointer abuse, or unauthenticated trigger paths for accessibility features, but the clause is a process requirement whose coverage depends on how rigorously the principles are applied and reviewed, leaving a genuine slice of residual implementations.
T1546.009detects — A.8.27 mandates security-oriented design reviews, threat analysis against known attack patterns, hardening, and ongoing review of engineering principles to surface vulnerabilities; this can detect the AppCert DLLs technique when it appears in reviewed designs, code, or configurations, but the clause is scoped to development/engineering activities and does not require runtime monitoring of loaded DLLs or registry changes.
T1546.009prevents — A.8.27 mandates applying security-by-design, least-privilege, default-deny, hardening, and zero-trust principles during architecture and engineering; these can stop the AppCertDLLs registry value from being set to a malicious DLL or block the resulting load in many (but not all) development and deployment contexts, yet the control is a process that does not reach every possible implementation or legacy system.
T1546.010detects — A.8.27 mandates security-oriented design reviews, threat analysis against known attack patterns, hardening, zero-trust verification, and regular review of engineering principles, which can surface the AppInit_DLLs persistence vector during architecture, implementation or post-deployment review, but only where those reviews explicitly reach this Windows-specific registry mechanism (most of the clause is higher-level and does not guarantee instrumentation or runtime detection).
T1546.010prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, hardening, secure-boot consideration and zero-trust principles that can stop the registry value from being set or the resulting DLL load from succeeding, but the clause is a process requirement whose coverage depends on how rigorously those principles are applied to this specific legacy mechanism, leaving a slice of implementations where the weakness is not reached.
T1546.011detects — A.8.27 mandates security-oriented design reviews, threat analysis against known attack patterns, hardening, and ongoing review of engineering principles to surface vulnerabilities; this can detect the abuse of application shimming as a known attack pattern during design, review or hardening, but only for systems built under the control and not for already-deployed shims or third-party software.
T1546.011prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, hardening, security-oriented design reviews, and analysis of controls against threats/attack patterns; these directly constrain the insecure design and deployment of shim mechanisms that adversaries abuse for privilege escalation and persistence, but only for systems built under the control and do not reach legacy Windows shimming that ships by default.
T1546.012detects — A.8.27 mandates security-oriented design reviews, threat analysis, and ongoing review of engineering principles to identify vulnerabilities and new attack patterns; this surfaces the IFEO abuse technique in design/implementation but does not broadly instrument runtime detection of deployed instances.
T1546.012prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, fail-securely, hardening, and security-oriented design reviews that can stop IFEO registry abuse from being introduced in developed or configured systems; this reaches only a slice because the technique is also available to already-deployed malware or admins and the clause does not mandate runtime enforcement that would block all instances.
T1546.013detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification of requests, and regular review of engineering principles against new threats; these surface anomalous or malicious profile content (e.g. via review or runtime verification) in some but not all cases, as the clause sets a process rather than mandating specific profile-monitoring instrumentation.
T1546.013prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, hardening, secure defaults and zero-trust principles that reach the engineering of PowerShell execution environments and profile loading, so the technique is harder to introduce or succeed; it does not stop every possible profile modification on every Windows host.
T1546.014detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and regular review of engineering principles against new threats; these surface emond rule abuse during design/implementation or via ongoing threat analysis, but only as a slice of the full technique (no runtime detection mechanism is required).
T1546.014prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, least-functionality, hardening, secure defaults and explicit review of architecture against known attack patterns; these directly constrain the surface for emond rule abuse (e.g. by removing unnecessary event handlers, enforcing tight ACLs on /etc/emond.d/rules/, and requiring explicit authorisation for persistence mechanisms), but the control is a set of engineering principles rather than an enforced mechanism, leaving residual risk when principles are incompletely applied or when the OS ships emond enabled by default.
T1546.015detects — A.8.27 mandates security-oriented design reviews, threat analysis, and regular review of engineering principles to identify vulnerabilities and keep up with new threats; this surfaces some hijacking opportunities (especially those tied to insecure architecture or known attack patterns) but does not instrument runtime detection of the technique itself.
T1546.015prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, hardening, security-oriented design reviews and zero-trust principles that reach registry-integrity, input distrust and COM-component isolation, so the technique is blocked in systems built under it; the remainder is legacy Windows components, outsourced development that evades the contract flow, and post-deployment configuration drift that the clause does not itself police.
T1546.016detects — A.8.27 mandates security-oriented design reviews to identify vulnerabilities plus ongoing review of engineering principles against new threats; this surfaces installer-script abuse patterns in development or updates, but does not instrument runtime detection of the technique once deployed.
T1546.016prevents — A.8.27 mandates security-by-design, defense-in-depth, least-privilege, fail-secure, distrust-external-input, hardening, and secure engineering reviews that explicitly address installer scripts, post-install actions, privilege inheritance, and zero-trust verification; this stops many (but not all) malicious installer variants at design or review time.
T1546.017detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and regular review of engineering principles against new threats; these surface udev rule abuse as a design or configuration vulnerability during reviews or threat updates, but only where the organization elects to apply those reviews to Linux device management (a minority slice of the technique's attack surface).
T1546.017prevents — A.8.27 mandates security-by-design, defence-in-depth, least privilege, hardening, secure architecture reviews and zero-trust principles that reach Linux system configuration and device management; these constrain where and how udev rules can be placed or executed, but do not stop a root-privileged actor from adding a malicious rule file.
T1546.018detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of engineering principles against new threats, which surfaces anomalous or risky startup-hook mechanisms during design, implementation, or review — but only where those reviews actually inspect the Python interpreter startup path, leaving most runtime or post-deployment instances outside its scope.
T1546.018prevents — A.8.27 mandates security-by-design, hardening, least-privilege, default-deny, assume-breach and secure-engineering reviews that can stop malicious .pth / sitecustomize.py hooks from being introduced or surviving into production; this is genuine but only a slice because the control is a process that depends on implementation rigour and does not itself block every placement vector or every post-deployment abuse on Python-heavy systems.
T1547detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification of requests, and ongoing review of principles against new threats, which surfaces some boot/logon autostart mechanisms (e.g. via architecture analysis or assume-breach reviews) but does not instrument or monitor runtime execution across the broad set of OS mechanisms named in T1547.
T1547prevents — A.8.27 mandates applying security-by-design, least privilege, default-deny, fail-secure, hardening, and zero-trust principles during architecture and engineering; these directly constrain unsafe autostart mechanisms (e.g., registry Run keys, kernel extensions, privileged boot programs) before they are built or deployed, but the control is a process that depends on how rigorously the implementer applies it and does not reach every possible platform or legacy mechanism.
T1547.001detects — A.8.27 mandates security-oriented design reviews, threat analysis, and ongoing review of engineering principles to identify vulnerabilities and new threats, which can surface Registry Run Keys/Startup Folder persistence in reviewed systems or designs, but this is limited to the development/review process and does not broadly instrument or monitor deployed systems for the technique.
T1547.001prevents — A.8.27 mandates applying security-by-design, least privilege, default-deny, hardening, and secure-engineering reviews that can stop insecure auto-start mechanisms from being introduced; this reaches only a slice of the technique because the control is a process that depends on implementation rigour and does not itself block already-present registry/run-key entries.
T1547.002detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and regular review of engineering principles against new threats; these surface anomalous or risky authentication package registrations during design, review or monitoring of the boot-time LSA load path, but only where the organization has chosen to instrument or review that specific autostart vector.
T1547.002prevents — A.8.27 mandates security-by-design, least-privilege, default-deny, hardening, and zero-trust principles that reach the LSA authentication-package autostart vector when applied during system engineering, but the control is a process that depends on how rigorously those principles are implemented and does not itself block the registry modification.
T1547.003detects — A.8.27 mandates security-oriented design reviews, threat analysis against known attack patterns, hardening, zero-trust verification of requests, and regular review of principles to stay current with new threats; these surface the anomalous time-provider registration or boot-time DLL load in reviewed/ monitored systems, but the clause sets a process rather than mandating specific detection instrumentation or coverage depth, leaving a large slice of implementations that do not instrument this vector.
T1547.003prevents — A.8.27 mandates security-by-design, defence-in-depth, least privilege, hardening, secure architecture reviews and zero-trust principles that reach the boot-time loading of registered DLLs and can stop malicious time-provider registration or execution; this is a genuine but minority slice of the full technique surface (which also includes post-boot registry abuse, privilege escalation paths and non-architectural implementation flaws).
T1547.004detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of engineering principles to identify vulnerabilities and new threats, which can surface abuse of Winlogon registry keys during architecture review or threat analysis, but does not mandate runtime monitoring or scanning that would catch post-deployment modifications.
T1547.004prevents — A.8.27 mandates security-by-design, least-privilege, default-deny, hardening, and secure-engineering reviews that would stop most unsafe Winlogon helper registrations at design or implementation time; the remainder is post-deployment abuse of a shipped, approved configuration that the clause does not reach.
T1547.005detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and regular review of engineering principles against new threats, which can surface SSP registry abuse or anomalous LSA DLL loading in reviewed architectures, but does not mandate runtime detection mechanisms or monitoring and leaves many post-design deployment cases unreached.
T1547.005prevents — A.8.27 mandates security-by-design, least-privilege, default-deny, hardening, and secure architecture principles that reach the LSA/SSP loading path and registry protections in new or reviewed systems, but does not stop an already-deployed or misconfigured Windows SSP abuse path.
T1547.006detects — A.8.27 mandates security-oriented design reviews, threat analysis, hardening, zero-trust verification and ongoing review of engineering principles that can surface kernel-module risks during development or architecture review, but the clause is silent on runtime detection of already-loaded malicious LKMs/kexts and its scope is limited to systems built under the principles rather than all deployed systems.
T1547.006prevents — A.8.27 mandates applying security-by-design, defence-in-depth, least-privilege, least-functionality, hardening, secure boot-time architecture reviews and zero-trust principles to the full engineering life cycle (including outsourced development), which directly constrains the attack surface for malicious LKMs/kexts; it does not reach every implementation detail or legacy kext paths, leaving a genuine minority slice unaddressed.
T1547.007detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and regular review of principles against new threats; these surface the plist-modification persistence vector in design or during reviews of macOS login flows, but only where the organization explicitly includes it in scope rather than mandating broad runtime detection.
T1547.007prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, hardening, security-oriented design reviews and zero-trust principles that can be applied to stop plist-based auto-reopen persistence at design or hardening time; this reaches only a slice of the technique because the control is a process of establishing and applying principles rather than a concrete mechanism that universally blocks plist modification.
T1547.008detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of engineering principles against new threats, which can surface anomalous LSASS driver modifications during architecture analysis or reviews but does not mandate runtime detection mechanisms.
T1547.008prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, hardening, zero-trust verification and secure-engineering reviews that can stop illegitimate LSASS driver addition/replacement at design or deployment time; this reaches only a slice of the technique because the control is a process that depends on rigour of application and does not itself block all post-compromise driver loading paths.
T1547.009detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and regular review of engineering principles against new threats; these surface shortcut-modification TTPs during design, code review or threat modeling but do not instrument runtime detection of the technique once deployed.
T1547.009prevents — A.8.27 mandates applying security-by-design, least privilege, default-deny, hardening, and secure-engineering reviews that can stop shortcut-based persistence from being introduced during development or configuration; this reaches only a slice of the technique because the control is scoped to engineering activities and does not block post-deployment abuse of existing shortcuts by an already-present adversary.
T1547.010detects — A.8.27 mandates security-oriented design reviews, threat analysis, and ongoing review of engineering principles to identify vulnerabilities and new threats, which can surface the port monitor persistence vector in architecture or code review, but does not mandate runtime monitoring or detection mechanisms.
T1547.010prevents — A.8.27 mandates security-by-design principles (least privilege, defense-in-depth, fail securely, hardening, assume-breach, distrust-external-input) plus design reviews that would catch or block the insecure boot-time DLL loading mechanism in most cases, but the control is a process that depends on implementation rigor and does not itself enforce the specific registry or spooler protections.
T1547.012detects — A.8.27 mandates security-oriented design reviews, threat analysis, hardening, zero-trust verification and regular review of engineering principles to identify vulnerabilities and new threats; this surfaces the abuse technique in design, configuration or post-deployment review but only where the print-processor addition is examined as part of those activities, leaving most runtime or un-reviewed instances outside its scope.
T1547.012prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, least-functionality, hardening, and secure-engineering reviews that can stop unsafe print-processor registration or boot-time DLL loading when applied to the spooler architecture; the coverage is only a slice because the clause sets process-level requirements whose actual enforcement depends on how rigorously the implementer applies them to this specific component.
T1547.013detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification of requests, and ongoing review of engineering principles against new threats; these surface anomalous autostart entries or persistence patterns during design/implementation or via monitoring aligned to the architecture, but only where the review scope and threat models explicitly include them (a chosen slice, not a bounded remainder).
T1547.013prevents — A.8.27 mandates security-by-design, least privilege, default-deny, hardening, and secure engineering principles that reach autostart abuse when applied to Linux desktop/session configuration; this stops many but not all instances because the control is a requirement-setting process whose coverage depends on the rigour and completeness of the resulting implementation.
T1547.014detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of engineering principles against new threats, which surfaces anomalous persistence mechanisms like Active Setup abuse during design, testing or architecture review, but only for systems built under the control and not for already-deployed instances or un-reviewed legacy code.
T1547.014prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, hardening, and secure-engineering reviews that would catch or block unsafe Active-Setup registry usage in developed or configured systems; it does not reach every possible post-deployment abuse vector or every outsourced component, leaving a genuine minority slice unaddressed.
T1547.015prevents — A.8.27 mandates applying security-by-design, least privilege, default-deny, fail-securely, zero-trust and hardening principles plus design reviews during engineering; these constrain the attack surface and mechanisms adversaries abuse to add malicious login items, but do not eliminate all possible vectors (e.g., legitimate-but-abused APIs or insider-supplied code).
T1548detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of principles against new threats, which surfaces elevation-control bypasses during architecture and engineering but does not instrument runtime detection of the technique in operation.
T1548prevents — A.8.27 mandates applying security-by-design, least privilege, default-deny, fail-secure, defence-in-depth and zero-trust principles plus hardening and design reviews that directly constrain elevation-control bypasses when followed; it is only a slice because the clause sets required practices rather than a universal mechanism and the technique can still succeed against incomplete or bypassed implementations.
T1548.001prevents — A.8.27 mandates applying security engineering principles (least privilege, security by design, default deny, hardening, secure architecture review) that directly address avoiding or removing unnecessary setuid/setgid bits and configurations, but this is a process applied during design/development rather than a universal mechanism that stops all instances or post-deployment abuse.
T1548.002detects — A.8.27 mandates security-oriented design reviews, threat analysis against known attack patterns, and ongoing review of engineering principles to identify vulnerabilities including bypass techniques like UACME methods, but this is limited to the development/engineering phase and does not require runtime detection of the technique in operation.
T1548.002prevents — A.8.27 mandates establishing and applying security engineering principles (least privilege, security by design, default deny, fail securely, hardening, security-oriented design reviews) that reach UAC configuration, auto-elevation paths, and privilege boundaries, but does not guarantee their correct implementation against the many discovered bypasses or residual configuration drift.
T1548.003prevents — A.8.27 mandates applying security engineering principles (least privilege, security by default, default deny, fail securely, hardening, security-oriented design reviews) to system architecture and engineering; these directly shape sudo/sudoers configurations to block the poor setups the technique abuses, but the control is a process applied during development rather than a universal runtime mechanism, leaving residual risk in legacy, outsourced, or post-deployment sudoers.
T1548.004prevents — A.8.27 mandates security-by-design, least privilege, default-deny, fail-secure, distrust-external-input, hardening, and zero-trust verification principles that would stop most legitimate uses of the deprecated AuthorizationExecuteWithPrivileges API from being introduced or left exploitable; the remainder is that the control is a process/guidance clause whose effectiveness still depends on whether developers and reviewers actually apply it to every macOS component that still ships or calls the API.
T1548.005detects — A.8.27 mandates security-oriented design reviews, threat analysis, and regular review of engineering principles to identify vulnerabilities and keep up with new threats; this surfaces misconfigurations enabling temporary elevation paths in cloud designs (especially via assume-breach/zero-trust reviews), but does not mandate runtime detection or monitoring of the technique in operation.
T1548.005prevents — A.8.27 mandates establishing and applying security engineering principles (least privilege, security by default, zero-trust never-trust/always-verify, defense-in-depth, secure design reviews, hardening) to cloud architecture and IAM; this directly constrains the misconfigurations that enable temporary elevation paths, but remains a process requirement whose completeness depends on implementation rigor and does not eliminate all JIT/impersonation/PassRole abuse vectors.
T1548.006detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and regular review of engineering principles to identify vulnerabilities and new threats; this surfaces some TCC manipulation vectors (e.g. via design review or assume-breach analysis) but does not instrument runtime detection of the technique itself.
T1548.006prevents — A.8.27 mandates security-by-design, least privilege, default-deny, fail-secure, distrust-external-input, hardening, and zero-trust principles (never-trust/always-verify, contextual authz) applied across the engineering life cycle; these directly constrain the TCC-abuse vectors (insecure defaults, privilege inheritance, database manipulation, SIP bypass) when followed, but remain a process requirement whose completeness depends on implementation rigor and does not eliminate every macOS-specific bypass.
T1550detects — A.8.27 mandates security-oriented design reviews, threat analysis against known attack patterns, zero-trust verification, and ongoing review of engineering principles to surface vulnerabilities; this can detect design or implementation choices that would allow theft/use of alternate auth material (e.g. weak caching or insufficient verification), but only as part of broader secure-engineering inspection rather than runtime detection of the technique itself.
T1550prevents — A.8.27 mandates security-by-design principles (least privilege, zero-trust/never-trust-always-verify, defence-in-depth, secure authentication techniques, hardening) that can be applied during architecture and engineering to reduce the attack surface for stealing and abusing alternate auth material (e.g. via stronger session controls, dynamic access, end-to-end encryption of requests, and reduced caching exposure), but does not guarantee prevention of all such techniques across all platforms or implementations.
T1550.001detects — A.8.27 mandates security-oriented design reviews, threat analysis, zero-trust verification, and ongoing review of engineering principles that surface token-related weaknesses (e.g. misconfigurations, insufficient verification, or missing contextual auth), but this is limited to the design/engineering phase and does not instrument runtime detection of token use or theft.
T1550.001prevents — A.8.27 mandates security-by-design principles (least privilege, zero-trust/never-trust-always-verify, defence-in-depth, secure session control, strong authentication, dynamic access control, distrust external input) that reach token issuance, validation, scoping and usage; this stops many acquisition paths and misuse patterns for T1550.001 but leaves residual cases (e.g. stolen refresh tokens, misconfigured cloud IAM that still issues valid tokens, or supply-chain compromise of the token issuer itself).
T1550.002detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification of requests, and ongoing review for new threats, which can surface PtH patterns in architecture or logs but does not mandate runtime detection mechanisms.
T1550.002prevents — A.8.27 mandates security-by-design principles (least privilege, defence-in-depth, assume-breach, never-trust/always-verify, strong auth, hardening) that can stop PtH by removing NTLM reliance, enforcing MFA, and limiting hash usability, but these are high-level practices whose actual coverage depends on implementation rigour and leaves residual cases (e.g. legacy systems, certain Kerberos paths).
T1550.003detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification of requests, and ongoing review of principles against new threats; these surface PtT indicators (e.g., anomalous Kerberos ticket use or weak auth design) in architecture and engineering but do not instrument runtime detection of the technique itself.
T1550.003prevents — A.8.27 mandates security-by-design principles (least privilege, defence-in-depth, assume-breach, distrust-external-input, zero-trust “never trust/always verify”, strong auth, IAM integration, hardening) that directly constrain Kerberos-ticket misuse for lateral movement; this stops many real-world PtT vectors but leaves a bounded remainder (e.g. already-compromised valid tickets obtained via T1003, golden/silver tickets, or overpass-the-hash) that the clause’s own guidance does not eliminate.
T1550.004detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification of requests, and ongoing review of principles against new threats; these surface session-cookie weaknesses or anomalous use in design/operation but only as a slice (e.g., via architecture reviews or monitoring tied to principles), not broadly across runtime cookie theft or import.
T1550.004prevents — A.8.27 mandates applying security-by-design principles (least privilege, secure session control, defence-in-depth, zero-trust “never trust/always verify”, end-to-end encryption of requests, and hardening) that can stop session-cookie replay from succeeding; this is only a slice of the technique because the control is a requirement-setting process whose coverage depends on how rigorously those principles are implemented in any given architecture.
T1552detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of principles to surface design/implementation gaps that could leave credentials unsecured; this surfaces a slice of the technique (e.g., via reviews or monitoring implied by architecture) but does not broadly instrument or detect runtime searches for credentials across all listed platforms and storage forms.
T1552prevents — A.8.27 mandates security-by-design, hardening, least-privilege, zero-trust, secure credential handling (authentication, secrets management, distrust-external-input) and design reviews that surface insecure storage; this stops many (but not all) classes of unsecured credential artifacts from being introduced at build time.
T1552.001detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and regular review of principles to identify vulnerabilities including insecure credential storage in files/configs, but this is limited to the engineering/SDLC phase and does not broadly detect post-deployment adversary searches across live systems.
T1552.001prevents — A.8.27 mandates security-by-design principles (least privilege, security by default, hardening, distrust external input, secure credential handling via auth/IAM/PKI) that, when applied in the SDLC, stop many classes of insecure credential storage from being introduced into files/configs/code; it does not reach all deployment paths, legacy code, or runtime credential discovery in backups/logs.
T1552.002prevents — A.8.27 mandates security-by-design, least privilege, zero-trust, hardening, and secure engineering that includes credential handling and data protection across architecture layers, which stops many insecure-storage patterns before the Registry ever receives plaintext credentials; it does not reach every possible legacy or third-party storage decision, leaving a genuine minority slice unaddressed.
T1552.003prevents — A.8.27 mandates security-by-design principles (least privilege, security by default, hardening, distrust external input, zero-trust verification) that reach command-line credential practices and history-file exposure in the engineering/SDLC process, but only for systems built under it and without mandating specific mechanisms like HISTCONTROL or history-file permissions, leaving a genuine minority slice of residual cases.
T1552.004prevents — A.8.27 mandates security-by-design principles (least privilege, defence-in-depth, secure defaults, hardening, zero-trust verification, proper key management via PKI/IAM) that reduce the chance insecure storage locations or exportable keys are introduced during engineering; this stops the technique at source for systems built under it, but only a slice because the control is a process applied where chosen, does not reach already-deployed systems or outsourced code that deviates, and the technique can still run post-compromise on any residual insecure key file.
T1552.005detects — A.8.27 mandates security-oriented design reviews, threat analysis, zero-trust principles, and ongoing review of engineering practices that surface metadata API risks (e.g. via assume-breach or SSRF patterns), but this is only a slice of possible detections rather than broad runtime or post-deployment monitoring.
T1552.005prevents — A.8.27 mandates security-by-design, defence-in-depth, least privilege, assume-breach, zero-trust, hardening, and explicit distrust of external input; these directly stop the technique when applied to instance configuration, network segmentation, metadata-service firewalling, IMDSv2 enforcement, or SSRF protections, but remain a minority slice because the clause only requires the principles be established and applied where the organisation deems them applicable rather than mandating universal technical blocks on every cloud instance.
T1552.006detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and regular review of principles against new threats, which can surface the GPP credential exposure during architecture reviews or threat analysis, but does not mandate runtime/operational detection mechanisms for the technique itself.
T1552.006prevents — A.8.27 mandates security-by-design, defence-in-depth, least privilege, zero-trust, hardening, and secure engineering that explicitly includes credential protection and avoiding embedded secrets, which would stop GPP from ever containing decryptable passwords; this is only a slice of the technique because the control is a process that depends on implementation rigour and does not reach legacy GPP files already deployed in SYSVOL.
T1552.007detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust principles, and ongoing review of engineering practices that surface insecure API exposures or credential-gathering vectors in container architecture, but does not itself instrument or monitor runtime behavior to detect the technique once it occurs.
T1552.007prevents — A.8.27 mandates security-by-design principles (least privilege, zero-trust/never-trust, defense-in-depth, secure defaults, distrust external input, hardening, and explicit review against attack patterns) that reach authentication, authorization, and API exposure in container environments, but these are high-level process and architecture requirements whose concrete effectiveness against credential-gathering via Docker/K8s APIs depends on how rigorously they are implemented in a given design.
T1552.008detects — A.8.27 mandates security-oriented design reviews, analysis of controls' detection/response capabilities, hardening, zero-trust monitoring principles, and regular reviews for new threats, which surfaces chat-based credential exposure as a design or runtime anomaly in a subset of engineered systems.
T1552.008prevents — A.8.27 mandates security-by-design, defense-in-depth, least privilege, zero-trust, secure session control, data validation/sanitization and hardening that can stop credentials from being sent/stored unsecured in chat services when those principles are applied to the affected systems and integrations; this is only a slice because the control is a set of engineering practices whose coverage depends on what the implementer actually builds or requires of suppliers, leaving many real-world chat deployments untouched.
T1553prevents — A.8.27 mandates security-by-design, defense-in-depth, least privilege, hardening, secure defaults, distrust-external-input, assume-breach, and explicit design reviews against known attack patterns; these directly constrain the engineering choices that would allow trust-subversion mechanisms (e.g., weak signing validation, missing attribute checks, or permissive execution paths) to be present in the built system.
T1553.001prevents — A.8.27 mandates applying security-by-design, defence-in-depth, least-privilege, fail-securely, security-by-default and zero-trust principles plus security-oriented design reviews and hardening during engineering; these directly shape Gatekeeper-like controls and reduce bypass surface, but the clause is a process that cannot guarantee the resulting implementation will be free of the logic errors, unchecked file-type paths or first-launch timing gaps the technique exploits.
T1553.002prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, hardening, security-oriented design reviews against known attack patterns, and zero-trust verification of signatures and requests, which directly constrains the successful use of stolen or adversary-created signing material to bypass policies on Windows/macOS.
T1553.003detects — A.8.27 mandates security-oriented design reviews to identify vulnerabilities plus ongoing review of engineering principles against new threats; this surfaces the possibility of SIP/trust-provider hijacking during architecture and review activities, but the clause is silent on runtime or post-deployment detection mechanisms and the technique can still be introduced via outsourced or legacy components.
T1553.003prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, fail-secure, distrust-external-input, hardening, and security-oriented design reviews that explicitly consider known attack patterns; these principles, when applied during engineering, stop the architectural conditions (weak registry protections, missing integrity on SIP/trust-provider components, absent least-functionality) that let T1553.003 succeed, but the clause is a process requirement whose effect still depends on how rigorously the implementer applies the listed principles, leaving a genuine slice unreached.
T1553.004detects — A.8.27 mandates security-oriented design reviews, threat analysis, hardening, and ongoing review of engineering principles to identify vulnerabilities and ensure controls combat new threats; this surfaces root-certificate installation risks in design/supply-chain but does not instrument runtime detection of the post-compromise technique itself.
T1553.004prevents — A.8.27 mandates establishing and applying security engineering principles (including defense-in-depth, least privilege, assume breach, distrust external input, hardening, and zero-trust verification of certificates/endpoints) plus security-oriented design reviews that surface and mitigate risks from root-certificate installation during system engineering; this constrains the technique in systems built under it but does not stop post-compromise execution of the cited commands on already-deployed Linux/macOS/Windows platforms.
T1553.005detects — A.8.27 mandates security-oriented design reviews, threat analysis against known attack patterns, and regular review of principles to combat new threats; this surfaces MOTW-bypass patterns during architecture/engineering but does not instrument runtime detection of the technique.
T1553.005prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, hardening, security-oriented design reviews against known attack patterns, and zero-trust principles that explicitly include never-trust/always-verify and distrusting external input; these directly address the design and implementation choices that allow MOTW-stripping container formats to reach execution, but the clause is a set of engineering principles and reviews rather than an enforced runtime mechanism, leaving residual gaps in legacy formats, outsourced implementations, and incomplete hardening.
T1553.006detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and regular review of engineering principles against new threats; these surface policy-modification vectors and artifacts (e.g., test-signing watermarks, kernel changes) during design and review but do not instrument runtime detection of the technique itself.
T1553.006prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, fail-secure, default-deny and zero-trust principles plus design reviews that explicitly consider attack patterns and required controls; these directly shape policies and enforcement mechanisms so that code-signing policy modification is harder to achieve, but the clause stops at requiring principles and reviews rather than mandating unbreakable enforcement, leaving a genuine residual slice reachable via kernel exploits or debug-mode bypasses.
T1554detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and regular review of principles against new threats/attack patterns, which can surface some binary modification attempts during engineering or reviews, but does not mandate runtime monitoring or detection mechanisms for post-deployment compromise of binaries.
T1554prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, hardening, secure reviews against attack patterns, and zero-trust principles that reduce the attack surface and make binary modification/patching materially harder to achieve or persist, but does not stop an already-privileged adversary from replacing or hooking a binary.
T1555detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of principles to surface vulnerabilities and new threats; this can detect insecure password-store designs or anomalous access patterns in reviewed systems, but the clause is about engineering processes rather than runtime detection of the post-deployment search technique itself.
T1555prevents — A.8.27 mandates security-by-design, defence-in-depth, least privilege, zero-trust, hardening, and secure credential-handling principles that can stop many common password-store exposures at design or deployment time, but leaves residual paths (e.g., already-compromised hosts, unhardened third-party password managers, or post-breach extraction from memory) unaddressed.
T1555.001prevents — A.8.27 mandates security-by-design principles (least privilege, assume breach, distrust external input, hardening, secure credential handling) that reach a slice of the macOS Keychain acquisition path when applied during engineering, but do not block post-compromise credential dumping by an already-authenticated adversary.
T1555.002prevents — A.8.27 mandates security-by-design, defence-in-depth, least privilege, assume-breach, hardening, and zero-trust principles (never trust/always verify, end-to-end encryption, contextual authz) that, when applied during engineering, stop the insecure in-memory caching and weak protection of the master key that the technique relies on; the remainder is that the control is a process that depends on how rigorously those principles are followed in any given implementation.
T1555.003detects — A.8.27 mandates security-oriented design reviews, threat analysis against known attack patterns, zero-trust verification, hardening, and regular review of principles to surface new threats; this can surface browser-credential extraction patterns in design or post-deployment reviews, but the clause is scoped to engineering activities and does not mandate runtime detection mechanisms.
T1555.003prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, zero-trust, hardening, and secure credential-handling principles that can stop browser credential files from being stored in plaintext or made extractable, but these are high-level practices whose concrete application (and therefore coverage of the specific file/memory theft vectors) is left to the implementer.
T1555.004detects — A.8.27 mandates security-oriented design reviews, threat analysis, zero-trust verification, hardening, and ongoing review of engineering principles that surface credential-management weaknesses (e.g., via assume-breach, distrust-external-input, and least-privilege reviews), but does not itself instrument or monitor runtime credential extraction.
T1555.004prevents — A.8.27 mandates security-by-design, least privilege, zero-trust, hardening, and secure credential handling (authentication, session control, data protection) that can stop many common acquisition paths when applied, but leaves residual techniques (e.g., post-breach API abuse, direct file reads after obtaining the VPOL key, or password-recovery tools) unaddressed.
T1555.005detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust principles, and ongoing review of engineering practices that surface design or implementation weaknesses (including insecure password-manager handling of master passwords, memory exposure, or brute-force vectors) before or during deployment, but does not itself instrument runtime detection of the post-compromise T1555.005 technique.
T1555.005prevents — A.8.27 mandates security-by-design principles (least privilege, assume breach, distrust external input, defence-in-depth, hardening, secure session control, data validation/sanitisation, zero-trust verification) that can stop extraction-from-memory or brute-force paths to the master password in password-manager implementations; this is genuine but only a slice because the control is a process that applies where the implementer chooses to follow it, not a universal mechanism that stops every possible password-manager credential-theft technique on every platform.
T1555.006detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification of requests, and regular review of engineering principles to identify vulnerabilities and new threats; this surfaces some cloud secrets-manager access anomalies or misconfigurations during design/operation but does not instrument or monitor runtime API calls to the stores themselves.
T1555.006prevents — A.8.27 mandates security-by-design, zero-trust, least-privilege, never-trust/always-verify, end-to-end encryption of requests, and hardening that, when applied to cloud architecture and IAM, stops many privilege paths that would let an adversary reach the secrets-manager API; the remainder is post-compromise abuse of already-authorized high-privilege cloud accounts or services that legitimately hold retrieve permissions, which the clause does not block.
T1556prevents — Requiring strong, context-aware authentication and authorization at every layer makes it harder for an attacker to weaken or bypass authentication processes without detection.
T1556detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and regular review of principles to identify vulnerabilities and new threats, which can surface modifications to auth processes (e.g., via reviews or anomaly detection in deployment), but this is limited to what the engineering process and reviews explicitly cover rather than ongoing runtime detection of the technique.
T1556.001detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and regular review of principles against new threats/attack patterns, which can surface anomalous authentication behavior or patching of LSASS on domain controllers when those activities fall inside the reviewed scope, but does not mandate runtime monitoring or specific detection mechanisms.
T1556.001prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, assume-breach, hardening, and secure authentication principles that reach domain-controller/LSASS design and review, so the technique is harder to introduce; it does not guarantee the absence of a patchable flaw in every implementation, leaving a genuine minority slice unaddressed.
T1556.002detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of engineering principles to identify vulnerabilities and new threats, which can surface malicious password filter registration as an anomalous or insecure authentication design; this is only a slice because the control is primarily about secure-by-design practices in development rather than runtime detection of deployed malicious DLLs.
T1556.002prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, hardening, security-oriented design reviews, and zero-trust principles that can be applied to keep malicious DLLs out of the LSA authentication path; this stops the technique at registration or loading for systems built under it, but the clause is a process that depends on rigour of application and does not reach every legacy or unmanaged Windows instance.
T1556.003detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and regular review of engineering principles against new threats, which can surface malicious PAM modifications or anomalous authentication during design, deployment or ongoing review, but this is limited to what the reviews and monitoring explicitly target rather than broad runtime detection of the technique.
T1556.003prevents — A.8.27 mandates establishing and applying secure engineering principles (including least privilege, security by design, defense in depth, fail securely, distrust external input, hardening, and zero-trust verification) plus security-oriented design reviews during the SDLC; these directly target the design and implementation flaws that allow PAM modification/backdooring, but only reach a slice of the weakness because the control is a process that depends on implementation rigor and does not itself stop post-deployment PAM tampering.
T1556.004detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of engineering principles against new threats/attack patterns, which can surface the backdoor pattern during design, review or monitoring of deployed images, but only where those reviews explicitly target implanted auth bypasses rather than generic flaws.
T1556.004prevents — A.8.27 mandates security-by-design, hardening, least-privilege, assume-breach, and secure engineering reviews that would stop the backdoor password from being introduced in the image; this is genuine but only a slice because the control is a process applied during development and does not reach every possible supply-chain or post-deployment modification of a network-device image.
T1556.005detects — A.8.27 mandates security-oriented design reviews, threat analysis against known attack patterns, and regular review of engineering principles to combat new threats; this surfaces the reversible-encryption misconfiguration during architecture or outsourced-development review, but only where the reviewer recognizes the AD property as a credential-exposure vector, leaving most runtime or post-deployment instances outside the clause's scope.
T1556.005prevents — A.8.27 mandates establishing and applying security engineering principles (including least privilege, security by default, fail securely, defence in depth, and zero-trust “never trust and always verify”) plus security-oriented design reviews and hardening; these directly address not enabling reversible encryption (a clear violation of those principles) and would stop the configuration change that enables the technique, but the clause is a process that depends on implementation rigour and does not itself block every possible setting path or legacy exception.
T1556.006detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and regular review of engineering principles to identify vulnerabilities and new threats; this surfaces some MFA modification vectors (e.g. via architecture review or assume-breach analysis) but does not instrument or monitor runtime MFA changes across the listed platforms.
T1556.006prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, fail-securely, zero-trust and explicit MFA/strong-auth requirements that, when applied during engineering, stop many classes of MFA-disable or bypass mechanisms from being introduced; it does not reach post-deployment admin abuse, configuration exclusions or patching of already-deployed MFA components, leaving a genuine minority slice prevented.
T1556.007detects — A.8.27 mandates security-oriented design reviews, threat analysis against known attack patterns, zero-trust verification, and ongoing review of engineering principles to surface vulnerabilities in authentication/hybrid identity designs; this can detect some classes of backdoorable processes (e.g. via review of PTA/AD FS configs or new agent registrations) but does not instrument or surface the runtime modification techniques themselves.
T1556.007prevents — A.8.27 mandates security-by-design, defense-in-depth, least-privilege, assume-breach, zero-trust, and secure-engineering reviews that explicitly address authentication architecture (including hybrid identity flows), which would stop most on-prem/cloud backdooring of PTA/AD FS before implementation; residual slice remains because the control is a process that depends on how rigorously those principles are applied to every hybrid component.
T1556.008detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification of requests, and ongoing review of principles against new threats; these surface anomalous or malicious network-provider registration and credential-capture behavior during engineering and operation, but only where the review scope and monitoring explicitly cover credential-manager extensibility and logon-notification hooks.
T1556.008prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, hardening, zero-trust verification and secure engineering reviews that can stop malicious network-provider DLL registration at the architecture and deployment layers; this is genuine but only a slice of the class because the technique lives inside the Windows credential-provider surface that the clause does not itself implement or enforce.
T1556.009prevents — A.8.27 mandates establishing and applying security engineering principles (including least privilege, security by default, assume breach, zero-trust verification, and hardening) to the design of IAM and conditional-access mechanisms so that such policies cannot be trivially altered by a compromised account; this stops the technique at the architecture layer for systems built under it, but remains partial because the control is a process that depends on implementation rigour, does not reach already-deployed flawed policies, and does not itself enforce the policies at runtime.
T1557detects — A.8.27 mandates security-oriented design reviews, threat analysis, and ongoing review of engineering principles to identify vulnerabilities and new threats, which can surface AiTM-enabling design flaws (e.g. weak protocol selection or missing defense-in-depth) before or after deployment, but does not mandate runtime monitoring or detection of the technique in flight.
T1557prevents — A.8.27 mandates security-by-design, defense-in-depth, least privilege, fail-secure, distrust-external-input, zero-trust verification, end-to-end encryption and secure session controls that stop many classic AiTM vectors (ARP/DNS poisoning, downgrade attacks, unauthenticated interception); these are genuine but not exhaustive because the clause is a set of engineering principles rather than a universal network-layer mechanism, leaving residual surface on unmanaged segments, legacy protocols or implementation gaps.
T1557.001detects — A.8.27 mandates security-oriented design reviews, threat analysis, and ongoing review of engineering principles to identify vulnerabilities and new threats, which can surface name-resolution poisoning risks in architecture but does not mandate runtime detection mechanisms for the technique itself.
T1557.001prevents — A.8.27 mandates security-by-design, defence-in-depth, least privilege, assume-breach, distrust-external-input, hardening, and zero-trust network principles that directly constrain or eliminate the unauthenticated multicast name-resolution path the technique relies on; the remainder is legacy Windows configurations and non-network vectors that the clause does not universally eradicate.
T1557.002detects — A.8.27 mandates security-oriented design reviews, threat analysis, zero-trust principles, and ongoing review of engineering principles to identify vulnerabilities and new threats; this surfaces ARP cache poisoning risks in network-layer design (e.g. via assume-breach or distrust-external-input) but does not mandate runtime detection mechanisms or monitoring, leaving most in-flight instances of the technique unreached.
T1557.002prevents — A.8.27 mandates security-by-design, defense-in-depth, least privilege, assume-breach, distrust-external-input, hardening, and zero-trust network principles that can eliminate many classic ARP-poisoning vectors (e.g., by removing reliance on unauthenticated ARP, enforcing encrypted channels, or segmenting so gratuitous replies cannot reach victims); these are genuine but not the bulk of the class because the control is a set of engineering principles rather than a concrete mechanism that stops every ARP cache update on every platform.
T1557.003detects — A.8.27 mandates security-oriented design reviews, threat analysis, zero-trust principles, and hardening that can surface DHCP spoofing risks in architecture (e.g. via assume-breach or distrust-external-input reviews), but this is limited to design-time discovery in engineering and does not require runtime detection of the technique in operation.
T1557.003prevents — A.8.27 mandates security-by-design, defence-in-depth, least privilege, zero-trust, secure defaults and explicit review of architecture against known attack patterns; these directly constrain rogue-DHCP insertion and malicious configuration delivery in properly engineered networks, but the clause is a process requirement whose coverage depends on how rigorously the principles are applied to DHCP services, so only a slice of the technique is stopped.
T1557.004detects — A.8.27 mandates security-oriented design reviews, threat analysis, hardening, zero-trust verification, and ongoing review of engineering principles to surface vulnerabilities and new threats; this can detect evil-twin patterns during architecture reviews or when evaluating new wireless tech, but the clause is scoped to development/engineering activities and does not mandate runtime network monitoring or anomaly detection that would catch deployed evil twins in the field.
T1557.004prevents — A.8.27 mandates security-by-design, defense-in-depth, least privilege, zero-trust verification, distrust-external-input, hardening, and secure architecture that together can stop evil-twin Wi-Fi from being trusted or from succeeding in credential theft / MITM, but the control is a high-level engineering principle set whose application to wireless networks, certificates, and client-side PNL behavior is not required or exhaustive.
T1558detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of principles against new threats, which surfaces Kerberos ticket theft/forgery risks in architecture but does not instrument runtime detection of the technique itself.
T1558prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, assume-breach, never-trust/always-verify, hardening, and explicit review against known attack patterns (including authentication techniques and session controls), which stops many Kerberos ticket theft/forgery vectors at design time; it does not reach every implementation detail or every post-compromise forgery path, leaving a genuine minority slice.
T1558.001detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and regular review of principles to identify vulnerabilities and new threats, which can surface golden ticket indicators in architecture or logs, but does not mandate or perform ongoing detection mechanisms.
T1558.001prevents — A.8.27 mandates establishing and applying security engineering principles (least privilege, assume breach, zero-trust verification, defence-in-depth, hardening, security-by-design reviews) that reach authentication architecture and credential protection; these can stop the KRBTGT hash from being obtainable or the forged ticket from being usable, but the control is a process of analysis and principle application rather than a concrete mechanism that guarantees prevention of this specific AD attack path.
T1558.002detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification of requests, and regular review of principles against new threats; these surface silver-ticket patterns or anomalous Kerberos use in architecture and deployment but do not instrument runtime detection of forged TGS tickets.
T1558.002prevents — A.8.27 mandates applying security-by-design, least privilege, defence-in-depth, assume-breach, distrust-external-input, hardening, and zero-trust principles (never trust/always verify, strong auth, dynamic access control) during architecture and engineering; these directly constrain the ability to obtain a usable service-account hash or to forge/accept a silver ticket for resource access, but only for systems built under the control and only to the degree the principles are rigorously implemented.
T1558.003detects — A.8.27 mandates security-oriented design reviews, threat analysis, and zero-trust monitoring principles that can surface anomalous Kerberos ticket requests or weak RC4 usage in architecture, but does not mandate runtime detection mechanisms for the technique itself.
T1558.003prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, assume-breach, hardening, secure authentication guidance and zero-trust principles that can stop weak SPN accounts, RC4 etype-23 issuance and unconstrained TGS requests from ever being available to an adversary, but these are only principles and reviews whose actual enforcement depends on downstream implementation choices, so only a slice of the technique is reached.
T1558.004detects — A.8.27 mandates security-oriented design reviews, threat analysis, zero-trust verification, and ongoing review of engineering principles to identify vulnerabilities and new threats; this surfaces the insecure pre-authentication configuration and weak crypto (RC4) that enable AS-REP roasting, but only as part of broader architecture reviews rather than runtime detection of the technique itself.
T1558.004prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, assume-breach, and explicit review of authentication techniques plus hardening; these directly drive enabling Kerberos pre-authentication (the control that stops AS-REP roasting at source) and preferring strong algorithms, but the clause only sets principles and reviews rather than mandating the concrete mechanism on every account, leaving a slice of residual accounts or legacy configurations.
T1558.005detects — A.8.27 requires security-oriented design reviews, threat analysis, and ongoing review of engineering principles to identify vulnerabilities and new threats, which can surface risks around insecure credential caching or ccache handling in system design, but does not mandate runtime detection of the post-authentication theft technique itself.
T1558.005prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, assume-breach, hardening, and secure authentication/session principles that, when applied during engineering, can stop ccache files from being created on disk or left readable, but the control is a process that does not guarantee these principles are uniformly enforced on every Kerberos deployment.
T1559detects — A.8.27 mandates security-oriented design reviews, threat analysis against known attack patterns, zero-trust verification, and ongoing review of engineering principles to surface vulnerabilities; this can detect IPC-abuse risks during design or review but does not instrument runtime detection of the technique itself.
T1559prevents — A.8.27 mandates applying security-by-design, least privilege, default-deny, fail-secure, distrust-external-input, defence-in-depth and zero-trust principles plus explicit design reviews that surface IPC-abuse vectors (COM/DDE/sockets/pipes) before they ship, so the technique is stopped for code built under it; the remainder is pre-existing or third-party components and legacy IPC surfaces that escape the engineering process.
T1559.001detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of engineering principles to identify vulnerabilities and new threats; this surfaces some COM abuse patterns during design or review but does not instrument runtime detection of the technique itself.
T1559.001prevents — A.8.27 mandates applying security-by-design, least privilege, default-deny, fail-secure, distrust-external-input and zero-trust principles plus architecture reviews that surface COM-abuse risks; this constrains many (but not all) ways COM objects can be exposed or invoked for arbitrary execution.
T1559.002detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of principles against new threats/attack patterns, which can surface DDE-based execution risks in system design or deployment but does not mandate runtime detection mechanisms or monitoring of DDE transactions themselves.
T1559.002prevents — A.8.27 mandates establishing and applying security engineering principles (including least privilege, security by default, default deny, distrust external input, hardening, and secure design reviews) across the SDLC and to outsourced development; these directly constrain DDE enablement, document poisoning, and untrusted IPC use in Office/CSV flows, but the clause is a process that depends on implementation rigour and does not itself disable DDE registry keys or remove the protocol.
T1559.003detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, input distrust/sanitization, and regular reviews against new threats, which can surface XPC client-validation or input-sanitization flaws before or after deployment, but only where those activities are scoped to cover this macOS-specific IPC vector.
T1559.003prevents — A.8.27 mandates security-by-design principles (least privilege, default deny, distrust external input, secure session control, data validation/sanitization, design reviews against attack patterns) that directly target the improper validation and poor sanitization root causes of XPC abuse for local code execution; this stops the technique from succeeding in systems built under it, but remains partial because the clause is a process/guidance control whose coverage depends on implementation rigour and does not reach every macOS XPC service already deployed.
T1560.001prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, least-functionality, hardening, and secure-engineering reviews that can remove or disable unnecessary archiving utilities (e.g. 7-Zip, WinRAR, makecab) or restrict their use, stopping the technique from being available; this is only a slice because many native utilities (tar, zip, certutil, xcopy) remain required by the OS and cannot be removed.
T1560.002detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust monitoring principles, and ongoing review of engineering practices that can surface anomalous use of libraries for compression/encryption in development or runtime, but this is limited to what the organization's chosen architecture, reviews, and monitoring scope actually instrument rather than broadly detecting the post-collection archival technique itself.
T1560.002prevents — A.8.27 mandates applying security-by-design, least functionality, hardening, and secure engineering principles (including distrusting external input and reviewing designs against attack patterns) that can stop an adversary from safely linking or using archival libraries for collection; this reaches only a slice because the technique can still be introduced via custom code, third-party components, or outsourced development that evades the principles.
T1560.003detects — A.8.27 mandates security-oriented design reviews, hardening, and ongoing review of engineering principles against known attack patterns and new threats, which can surface custom archival implementations (e.g. via code inspection or anomaly review in development), but this is limited to what is caught in the SDLC rather than runtime or post-deployment detection of the technique.
T1560.003prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, hardening, and secure engineering principles (including data validation/sanitisation and distrust of external input) that can stop custom archival code from being introduced during development; this is only a slice of the technique because it does not block runtime use of already-present custom methods on deployed systems or in third-party/out-of-scope code.
T1561recovers — A.8.27 mandates hardening, security-by-design, defence-in-depth, fail-securely, least functionality and regular review of engineering principles that explicitly include backup/recovery capabilities and zero-trust resilience; these directly enable post-wipe restoration of wiped systems or configurations, with the bounded remainder being data written after the last backup or on devices where complete sector overwrite leaves nothing recoverable.
T1561.001detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust monitoring principles, and regular review of engineering practices to identify vulnerabilities and new threats, which can surface indicators of disk-wiping techniques in reviewed systems or architectures, but does not mandate runtime detection mechanisms and leaves most in-flight or post-compromise realizations outside its scope.
T1561.001prevents — A.8.27 mandates security-by-design, defense-in-depth, least privilege, assume-breach, hardening, and zero-trust principles that can stop the adversary from gaining the direct/raw-disk access or privileges needed to execute a disk-content wipe; this is a genuine but minority slice of the technique (most of the class lives in post-compromise execution after initial access, which the engineering principles do not block).
T1561.001recovers — A.8.27 mandates hardening, security-by-design, defence-in-depth, fail-securely, least functionality and explicit consideration of backup/recovery architecture (via integration with security controls and zero-trust principles), which directly enables restoration of wiped systems from protected offline or immutable backups after the destructive event.
T1561.002detects — A.8.27 requires security-oriented design reviews, threat analysis, hardening, zero-trust monitoring principles, and regular review of engineering practices against new threats; these surface indicators of disk-wipe capability or anomalous destructive behavior during design, testing, or operation, but only for a slice of the technique (e.g., in scoped systems or via integrated controls) rather than broadly across all platforms and propagation vectors.
T1561.002prevents — A.8.27 mandates security-by-design, defense-in-depth, least privilege, assume-breach, hardening, and secure engineering that can stop the adversary from gaining the privileges or write access needed to reach and overwrite MBR/partition structures, but does not guarantee those principles are applied everywhere or block every propagation path (e.g. valid accounts, admin shares) or every platform variant.
T1561.002recovers — A.8.27 mandates hardening, security-by-design principles (including least functionality, fail securely, defence in depth), secure architecture that integrates backup/recovery considerations, and regular review against new threats; this directly enables post-wipe restoration of boot structures via documented, tested recovery processes, with the bounded remainder being the window of data loss since the last backup.
T1563detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification of requests, and ongoing review of principles against new threats, which surfaces session-hijacking risks or anomalous hijack behavior in reviewed architectures but does not instrument runtime detection of the technique itself.
T1563prevents — A.8.27 mandates security-by-design principles (least privilege, secure session control, defence-in-depth, assume-breach, distrust-external-input, fail-securely) plus design reviews that directly address session hijacking vectors in remote services; this stops many instances at design time, but the clause is a process that depends on implementation rigour and does not reach every possible hijack (e.g. certain protocol flaws or post-deployment misconfigurations).
T1563.001detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification of requests, and ongoing review of principles against new threats, which surfaces SSH agent hijacking risks in architecture but does not instrument runtime detection of an in-progress session hijack.
T1563.001prevents — A.8.27 mandates security-by-design principles (least privilege, defence-in-depth, assume-breach, distrust external input, hardening, secure session control) that can stop SSH-agent compromise vectors and session hijacking before it runs, but the clause is a process that only applies where the implementer chooses to instantiate those principles against this specific trust/SSH design pattern.
T1563.002detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification of requests, and ongoing review of principles against new threats, which surfaces RDP hijacking vectors during architecture and engineering but does not instrument runtime detection of the tscon.exe technique itself.
T1563.002prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, assume-breach, distrust-external-input, hardening, and zero-trust session verification that together stop most RDP session-stealing vectors at design or deployment time; residual paths remain when those principles are applied only partially or when the implementation still trusts an already-authenticated session token.
T1564detects — A.8.27 mandates security-oriented design reviews, threat analysis, zero-trust verification, and hardening that surface hidden artifacts or isolated regions during engineering, but only as part of architecture/development reviews rather than runtime detection of adversary T1564 behaviors.
T1564prevents — A.8.27 mandates security-by-design, defense-in-depth, least privilege, assume-breach, distrust-external-input, hardening, and zero-trust verification that together stop many common hiding techniques (e.g., by removing default-hide features, enforcing strong auth on isolated regions, and requiring visible controls across layers), but leaves a genuine remainder for adversary-chosen obscure OS features or virtualization that the principles do not universally eliminate.
T1564.001detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of principles against new threats/attack patterns, which surfaces the use of hidden files/directories as an evasion TTP during architecture and engineering activities (and in supplier contracts), but does not itself perform runtime or post-deployment detection of the technique.
T1564.001prevents — A.8.27 mandates security-by-design, defence-in-depth, least functionality/privilege, hardening, assume-breach and security-oriented design reviews that can incorporate hiding-resistance (e.g. explicit enumeration of dot-files, UF_HIDDEN, attrib, or space-named objects) into architecture and engineering, but the clause is a process requirement rather than an enforced mechanism and leaves many implementation slices (including legitimate hidden files required by apps) untouched.
T1564.002prevents — A.8.27 mandates establishing and applying security engineering principles (including least privilege, security by design, defence in depth, assume breach, and hardening) plus security-oriented design reviews that would surface and block designs allowing hidden-user accounts; this reaches the macOS/Windows/Linux mechanisms described but remains a slice because the clause is a process/governance requirement whose actual preventive effect depends on how rigorously those principles are implemented in each system.
T1564.003prevents — A.8.27 mandates establishing and applying security engineering principles (security by design, least functionality, defense in depth, hardening, assume breach, distrust external input) plus security-oriented design reviews that explicitly target known attack patterns; these reach the design and implementation choices that produce hidden-window techniques, but only as one slice of a broad set of principles applied during development rather than a dedicated barrier to this specific post-compromise hiding method.
T1564.004detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of engineering principles to identify vulnerabilities and new threats; this surfaces NTFS attribute abuse (e.g. ADS/EA hiding) in reviewed systems or during threat analysis, but only where the review scope and tooling explicitly cover it rather than as a guaranteed or broad detection mechanism.
T1564.004prevents — A.8.27 mandates security-by-design, defence-in-depth, least functionality, hardening, and design reviews that explicitly consider known attack patterns; these principles, when applied during engineering, stop NTFS attribute/ADS abuse from being introduced as a hiding technique on Windows systems built under the control, but the clause is a process requirement whose coverage depends on rigour of application and does not reach every possible deployment or legacy system.
T1564.005detects — A.8.27 mandates security-oriented design reviews, threat analysis, and ongoing review of engineering principles against new threats/attack patterns, which can surface hidden file system designs or anomalies in system architecture before or during deployment, but does not itself perform runtime detection of the technique once present.
T1564.005prevents — A.8.27 mandates security-by-design, defence-in-depth, least functionality, assume-breach, hardening, and explicit analysis of controls that can prevent hidden structures, so it stops the technique from being introduced in systems built under it; the remainder is adversary-controlled post-compromise use on already-deployed systems where the engineering process no longer applies.
T1564.006detects — A.8.27 mandates security-oriented design reviews, analysis of controls' detection capabilities, hardening, zero-trust monitoring principles, and regular reviews for new threats, which surfaces some virtualization-based hiding techniques (especially in reviewed/outsourced systems or via anomaly detection in hardened architectures) but does not mandate runtime detection tooling that would catch most in-guest or rogue-VM instances.
T1564.006prevents — A.8.27 mandates security-by-design, defence-in-depth, least functionality/privilege, assume-breach, distrust-external-input, hardening, and explicit analysis of controls that can prevent events; these principles applied during engineering directly constrain or remove many of the native virtualization, shared-folder, sandbox, and rogue-VM vectors named in T1564.006, but the control is a process that depends on implementation rigour and does not guarantee every possible virtualization technique is blocked.
T1564.007detects — A.8.27 mandates security-oriented design reviews, hardening, and analysis of controls (including detection) plus regular review of principles against new threats; this surfaces the technique in design/implementation reviews or via updated hardening guidance, but the clause is not a runtime monitoring or scanning control and reaches only the engineering slice of the technique.
T1564.007prevents — A.8.27 mandates security-by-design, defence-in-depth, least functionality, hardening, and design reviews that analyse for known attack patterns; these principles applied during Office-document or macro-handling development can stop VBA-stomping patterns from being introduced, but the control is a process that depends on rigour of application and does not reach every development pipeline or third-party document.
T1564.008prevents — A.8.27 mandates security-by-design, defense-in-depth, least-privilege, assume-breach, and zero-trust principles plus design reviews that explicitly consider the full set of controls needed to protect against identified threats; these directly constrain the creation or organization-wide abuse of email-hiding rules that impair detection, but the clause is a process/principle rather than an enforced mechanism and leaves residual risk in legacy clients, misconfigured transport rules, or post-compromise credentialed abuse.
T1564.009detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and regular review of principles against new threats/attack patterns, which can surface resource-fork hiding techniques during architecture and engineering reviews, but does not mandate runtime or scanning detection mechanisms.
T1564.009prevents — A.8.27 mandates security-by-design, defence-in-depth, least functionality/privilege, hardening, and design reviews that analyse threats and known attack patterns; these directly constrain the macOS resource-fork hiding technique when applied to development and deployment, but the clause is a set of principles rather than an enforced mechanism, leaving substantial residual depending on rigour and completeness of application.
T1564.010detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification of requests, and ongoing review of principles against new threats/attack patterns, which surfaces argument-spoofing techniques during architecture and engineering reviews but does not instrument runtime detection of in-memory PEB overwrites.
T1564.010prevents — A.8.27 mandates applying security-by-design, defence-in-depth, least-privilege, assume-breach, distrust-external-input and hardening principles during architecture and engineering; these directly shape process-creation paths, memory protections and argument-handling so that PEB-overwrite tricks become harder to reach in the first place, but the clause stops at principle-setting and review and does not mandate any concrete runtime mechanism that stops every possible in-memory patch.
T1564.011detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of engineering principles against new threats/attack patterns, which can surface the use of nohup/-ErrorAction/etc. in reviewed code or architecture but does not mandate runtime detection of the technique in operation.
T1564.011prevents — A.8.27 mandates security-by-design, defence-in-depth, least privilege, fail-securely, hardening, and zero-trust principles that can be applied during engineering to reduce or eliminate the use of nohup/-ErrorAction-SilentlyContinue patterns and the resulting interrupt-ignoring processes, but the clause is a process requirement whose effect depends on how rigorously those principles are actually followed in any given build.
T1564.012detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and regular review of principles against new threats; these surface the insecure practice of broad/hardcoded AV exclusions during architecture and engineering but do not instrument runtime detection of the technique itself.
T1564.012prevents — A.8.27 mandates security-by-design, defense-in-depth, least functionality/privilege, hardening, and reviews against known attack patterns (including zero-trust verification), which can prevent many default or insecure exclusions from being present; it does not reach all hardcoded vendor exclusions, discovery of existing ones, or post-deployment abuse vectors.
T1564.013detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of engineering principles against new threats; these surface anomalous bind-mount usage or hidden /proc artifacts during architecture reviews, deployment hardening, or threat-pattern analysis, but only as a minority slice of possible post-deployment runtime detections.
T1564.013prevents — A.8.27 mandates security-by-design, defence-in-depth, least functionality/privilege, hardening, and security-oriented design reviews that can exclude or constrain bind-mount abuse vectors in architecture and deployment, but does not reach the post-deployment sudo-enabled runtime abuse on Linux that realises the technique.
T1564.014detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and analysis of controls that can detect events, which surfaces xattr abuse in reviewed/hardened systems or monitored integrity contexts, but leaves substantial remainder for un-reviewed or non-hardened deployments where the hidden payload evades standard tools.
T1564.014prevents — A.8.27 mandates security-by-design, defence-in-depth, least functionality, hardening, distrust-external-input, assume-breach and security-oriented design reviews that surface and eliminate hidden storage mechanisms such as xattrs before deployment; this stops the technique on systems built under it, but the clause is a process that depends on rigour of application and does not reach every existing or third-party binary, leaving a genuine minority slice prevented.
T1565detects — A.8.27 mandates security-oriented design reviews, analysis of controls' detection capabilities, hardening, zero-trust verification, and ongoing review of principles against new threats, which surfaces data manipulation in design, architecture, and some runtime verification but does not mandate or perform detection mechanisms across deployed systems or all manipulation vectors.
T1565prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, fail-secure, distrust-external-input, hardening, and zero-trust verification that together stop many classes of data-manipulation technique from succeeding; the control is silent on the post-deployment operational detection/response slice of the technique and on bespoke complex-system expertise that lives outside the engineering principles themselves.
T1565.001detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of principles against new threats, which surfaces some stored-data manipulation risks during architecture and engineering but does not instrument or monitor runtime data-at-rest changes across file formats or complex systems.
T1565.001prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, fail-securely, hardening, integrity controls and zero-trust verification that, when applied during engineering, stop many classes of stored-data manipulation from being possible; it does not reach every stored-data target or every post-deployment manipulation vector, leaving a genuine minority slice.
T1565.002detects — A.8.27 mandates security-oriented design reviews, threat analysis, zero-trust verification, and ongoing review of engineering principles that surface transmitted-data manipulation risks during design and engineering, but does not mandate runtime detection mechanisms or monitoring of in-transit alterations.
T1565.002prevents — A.8.27 mandates security-by-design principles (defence-in-depth, least privilege, fail securely, distrust external input, zero-trust verification, end-to-end encryption, hardening) that directly constrain opportunities for in-transit alteration when applied to architecture and engineering, but remains a process-level requirement whose effect depends on how rigorously those principles are implemented in any given system.
T1565.003detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of principles to surface vulnerabilities and new threats, which can detect some runtime manipulation vectors (especially in reviewed binaries or anomalous access), but does not mandate runtime monitoring or anomaly detection for data manipulation in operation.
T1565.003prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, fail-secure, distrust-external-input, hardening, and design reviews that explicitly consider attack patterns and required integrity controls; these directly block the binary alterations, masquerading, and runtime-data changes named in T1565.003, but only for systems built under the principles — the clause does not reach already-deployed legacy binaries or outsourced development that fails to apply them, leaving a genuine minority slice unaddressed.
T1566detects — A.8.27 mandates security-oriented design reviews, threat analysis, and zero-trust monitoring principles that surface phishing indicators (e.g., anomalous requests, unverified external origins, or input distrust) in engineered systems, but only as a slice of the social-engineering delivery vector rather than broadly detecting all phishing campaigns.
T1566prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, assume-breach, distrust-external-input, secure defaults and zero-trust principles that, when applied during engineering, harden clients, email handling, authentication flows and user interfaces so that many common phishing payloads and social-engineering vectors cannot succeed; the remainder is the human-targeted delivery and persuasion step that no architecture principle can block.
T1566.001prevents — A.8.27 mandates security-by-design, defense-in-depth, least privilege, distrust-external-input, hardening, and secure engineering that explicitly covers data validation/sanitization, user authentication, and secure session control; these directly stop many attachment-based execution paths (e.g., by blocking unsafe defaults or malformed inputs), but the technique is primarily a social-engineering delivery vector whose success ultimately hinges on user action (T1204) outside the engineering principles' reach.
T1566.002prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, distrust-external-input, secure session control, data validation/sanitisation, hardening, and zero-trust verification principles that can stop many link-based delivery vectors (e.g. unsafe downloads, consent phishing, IDN homographs, browser exploits) when applied to email clients, browsers, OAuth flows and user execution paths; it does not stop the social-engineering delivery of the email itself or all possible obfuscated links.
T1566.003detects — A.8.27 mandates security-oriented design reviews, threat analysis, zero-trust principles, hardening, and ongoing review of engineering practices that surface spearphishing risks (e.g., via distrust-external-input, assume-breach, or anomalous external-service patterns), but this is limited to what the organization's own architecture and reviews can observe rather than broad, real-time detection of the technique in flight.
T1566.003prevents — A.8.27 mandates security-by-design, defense-in-depth, least privilege, assume-breach, distrust-external-input, hardening, and zero-trust verification that together constrain the social-engineering vector and the malicious payload delivered via third-party service, but cannot stop the initial human-targeted rapport-building or the use of personal channels that lie outside the organization's engineered perimeter.
T1566.004detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and regular review of principles to identify vulnerabilities and new threats, which surfaces social-engineering gaps like vishing in architecture but does not instrument runtime detection of voice calls or the downstream user actions.
T1566.004prevents — A.8.27 mandates security-by-design principles (least privilege, zero-trust/never-trust-always-verify, defense-in-depth, distrust-external-input, secure authentication techniques, hardening) that are applied to system architecture and engineering; these directly constrain the social-engineering vectors, MFA-bypass combinations, and user-execution paths described in T1566.004 when built into identity, access, and endpoint layers, but remain a minority slice because the technique is primarily a human-targeted vishing attack that can still succeed against trained or non-technical users outside the engineered controls.
T1567detects — A.8.27 mandates security-oriented design reviews, threat analysis, zero-trust verification of requests, and ongoing review of principles to surface new threats; this surfaces some exfiltration-over-web-service designs or anomalous outbound patterns in architecture but does not instrument runtime detection of the technique itself.
T1567prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, zero-trust, and hardening principles that can constrain or block many common exfiltration-over-web-service patterns when applied to architecture and deployment; it does not reach every implementation detail or every already-permitted legitimate web service an adversary may abuse.
T1567.001detects — A.8.27 mandates security-oriented design reviews, threat analysis, zero-trust verification, and ongoing review of engineering principles that can surface anomalous exfiltration patterns (e.g. via API calls or unusual repository use) during design and operations, but this is a minority slice of the class as the control does not mandate runtime detection mechanisms.
T1567.001prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, zero-trust, hardening, and secure architecture principles that can stop data from reaching an unauthorized external code repo (e.g. via enforced egress controls, dynamic access decisions, or default-deny), but leaves many implementation gaps (e.g. approved internal dev tools, misconfigured IAM, or outsourced code that still permits the API call).
T1567.002detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust principles (never trust/always verify, assume breach, dynamic access control, strong auth), and ongoing review of engineering principles against new threats; these surface anomalous exfiltration patterns to cloud storage in reviewed architectures but do not instrument or monitor runtime behavior themselves.
T1567.002prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, zero-trust, and hardening principles that can constrain exfiltration paths (e.g. by enforcing dynamic access controls, end-to-end encryption requirements, or default-deny on outbound cloud storage), but these are high-level engineering practices whose concrete effect on any given exfil technique depends on how rigorously they are implemented in the architecture, leaving a large slice of residual risk.
T1567.003detects — A.8.27 mandates security-oriented design reviews, threat analysis, hardening, zero-trust principles, and ongoing review of engineering practices that surface anomalous exfiltration patterns (e.g. via assume-breach, distrust-external-input, or monitoring of data flows to unexpected paste sites), but this is limited to what the secure-design and review process can observe in the engineered systems rather than broad runtime detection of the technique.
T1567.003prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, zero-trust, hardening, and secure engineering that can block or constrain outbound exfiltration channels (including to pastebin-like sites) when those principles are applied to network, data-loss, and egress controls; this is a genuine but minority slice of the technique because the control is a high-level process that does not itself implement any specific blocking mechanism.
T1567.004detects — A.8.27 mandates security-oriented design reviews, threat analysis, zero-trust verification, and ongoing review of engineering principles to surface vulnerabilities and anomalous designs, which can detect webhook-based exfiltration patterns in architecture or SaaS integrations, but this is limited to design-time and review activities rather than runtime detection across all platforms and blending scenarios.
T1567.004prevents — A.8.27 mandates security-by-design, defense-in-depth, least-privilege, zero-trust, and secure architecture principles that can stop webhook exfiltration paths (e.g. by blocking unauthorized SaaS linkages, enforcing dynamic access controls, or distrusting external inputs), but leaves many residual cases (manual posts, insider misuse, misconfigured SaaS, or non-architectural exfil) untouched.
T1568detects — A.8.27 mandates security-oriented design reviews, threat analysis, and zero-trust monitoring principles that surface dynamic resolution patterns (e.g. via assume-breach, never-trust, and end-to-end verification) during engineering, but does not itself instrument or perform runtime detection of the technique.
T1568prevents — A.8.27 mandates security-by-design principles (defence-in-depth, least privilege, assume-breach, zero-trust, distrust-external-input, hardening, security-oriented design reviews) that can be applied to make dynamic-resolution C2 harder to implement or more detectable, but does not stop the algorithmic technique itself from being coded or used.
T1568.001detects — A.8.27 mandates security-oriented design reviews, threat analysis, zero-trust verification, and ongoing review of engineering principles against new threats; these surface anomalous DNS behaviors or fast-flux patterns during architecture and deployment reviews, but only as a slice dependent on what the organization chooses to analyze rather than a broad instrumentation mandate.
T1568.002detects — A.8.27 mandates security-oriented design reviews, threat analysis, and zero-trust monitoring principles that can surface anomalous DGA-driven C2 (e.g. via assume-breach or never-trust verification), but this is limited to what the organization chooses to instrument in its architecture rather than a dedicated detection mechanism for the technique.
T1568.003detects — A.8.27 mandates security-oriented design reviews, threat analysis, and ongoing review of engineering principles to identify vulnerabilities and keep up with new threats; this surfaces the DNS calculation technique in custom malware during development or when new C2 patterns are analysed, but does not require runtime monitoring or detection of the live technique post-deployment.
T1568.003prevents — A.8.27 mandates security-by-design, defence-in-depth, least functionality, assume-breach, distrust-external-input and hardening principles plus explicit design reviews against known attack patterns; these reach the DNS-calculation C2 evasion when applied to network, resolver and egress layers but do not eliminate the class because the technique can still be introduced in custom malware or in outsourced components whose engineering the clause only requires to be contractually aligned.
T1569detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of principles against new threats, which surfaces abuse of services/daemons during architecture and engineering phases but does not instrument runtime detection of the technique once deployed.
T1569prevents — A.8.27 mandates security-by-design, least privilege, default-deny, hardening, and zero-trust principles that constrain how services are created/configured/started, thereby stopping many (but not all) abuse paths for T1569.
T1569.001detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust monitoring principles, and regular review of engineering procedures to surface new threats; this can surface anomalous launchctl abuse in reviewed/hardened macOS architectures but does not mandate runtime detection mechanisms and leaves most post-deployment execution unobserved.
T1569.001prevents — A.8.27 mandates applying security-by-design, least privilege, least functionality, default-deny, hardening, and zero-trust principles during architecture and engineering; these can stop launchctl abuse vectors (e.g. by removing unnecessary launchd agents/daemons or enforcing strict execution controls) but only for systems built under the control, leaving a large remainder of existing macOS deployments and post-deployment abuse.
T1569.002detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification of requests, and ongoing review of engineering principles against new threats; these surface anomalous or malicious service execution patterns during design, review or monitoring of the architecture, but only for systems built under the principles and only where the review scope reaches service-control-manager abuse (a minority slice of the technique's post-deployment use).
T1569.002prevents — A.8.27 mandates applying security-by-design, least privilege, default-deny, fail-secure, hardening, and zero-trust principles during architecture and engineering; these constrain service-creation/execution paths and reduce the attack surface for T1569.002, but the control is a process that depends on implementation rigour and does not universally block all service-abuse vectors on Windows.
T1569.003detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and regular review of principles against new threats, which surfaces anomalous or risky use of systemctl in architecture and deployment but does not instrument runtime detection of the technique itself.
T1569.003prevents — A.8.27 mandates applying security-by-design, least privilege, least functionality, default-deny, hardening, and zero-trust principles during architecture and engineering; these can remove or constrain the unnecessary exposure of systemctl (or systemd services) from the build or runtime, preventing the technique from being available to run, but the control is a process that depends on how rigorously those principles are applied and does not guarantee removal of every legitimate service-management interface an adversary could abuse.
T1570detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, monitoring-enabling principles (assume breach, never trust/always verify, end-to-end encryption of requests) and regular reviews for new threats, which can surface anomalous internal file transfers in a designed architecture but does not itself instrument or guarantee detection of the technique.
T1570prevents — A.8.27 mandates security-by-design principles (least privilege, least functionality, defense-in-depth, zero-trust, hardening, distrust-external-input) that can constrain file-transfer vectors and unnecessary tools/protocols when applied during engineering, but does not guarantee their removal from all platforms or block post-compromise use of remaining native ones.
T1571detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification of requests, and ongoing review of engineering principles against new threats; these surface non-standard port usage in architecture or deployment but only as a slice (e.g., during reviews or when tied to monitored IAM/PKI flows), not as broad runtime detection of the technique.
T1571prevents — A.8.27 mandates security-by-design, defence-in-depth, least functionality, hardening, and explicit reviews against known attack patterns (including non-standard port usage to bypass filters), which stops many instances at design time; it does not reach runtime configuration changes on victim systems or all outsourced implementations.
T1572detects — A.8.27 mandates security-oriented design reviews, threat analysis, and ongoing review of engineering principles to identify vulnerabilities and keep up with new threats/attack patterns; this surfaces tunneling as a known pattern in design or post-deployment review but does not mandate runtime detection mechanisms.
T1572prevents — A.8.27 mandates establishing and applying security engineering principles (defense-in-depth, least functionality, assume breach, distrust external input, security by design, hardening, zero-trust verification) plus security-oriented design reviews that directly target tunneling risks in architecture layers, protocol choices, and network controls, but stops short of guaranteeing their complete enforcement or coverage of all possible encapsulation vectors.
T1573detects — A.8.27 mandates security-oriented design reviews, analysis of controls' detection capabilities, hardening, and ongoing review of principles against new threats/attack patterns, which surfaces design or implementation flaws (e.g., hard-coded keys) that enable encrypted C2 channels, but does not itself perform runtime detection of the technique in operation.
T1573prevents — A.8.27 mandates security-by-design principles (defense-in-depth, least privilege, assume-breach, distrust-external-input, secure session control, hardening, zero-trust verification) plus design reviews against known attack patterns; these constrain how C2 channels are built so that hard-coded keys or weak implementations are less likely to be introduced, but do not stop an adversary from choosing a strong external algorithm whose keys are protected outside the malware.
T1573.001detects — A.8.27 mandates security-oriented design reviews, analysis of controls' detection capabilities, hardening, and ongoing review for new threats, which surfaces symmetric crypto use in C2 during architecture/engineering but does not instrument runtime detection of the technique itself.
T1573.001prevents — A.8.27 mandates security-by-design principles (defense-in-depth, least privilege, assume-breach, zero-trust, end-to-end encryption, distrust-external-input) that, when applied during architecture and engineering, lead to designs in which known symmetric C2 encryption is unnecessary or is replaced by stronger mechanisms, but the clause only sets a process and does not guarantee any specific technical outcome.
T1573.002prevents — A.8.27 mandates applying security-by-design, defence-in-depth, least privilege, assume-breach, distrust-external-input, and zero-trust principles plus security-oriented design reviews that analyse required controls (including cryptography) and review against known attack patterns; this constrains many design paths that would allow unencrypted or weakly-protected C2, but does not stop an adversary from choosing to layer known asymmetric crypto (RSA/ElGamal) atop an otherwise permitted protocol.
T1574detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of principles against new threats, which surfaces some hijack vectors (e.g., via architecture review or anomalous access) but does not instrument or monitor runtime execution flow itself.
T1574prevents — A.8.27 mandates applying security-by-design, least privilege, default-deny, fail-secure, hardening, and zero-trust principles during architecture and engineering; these directly constrain many hijack vectors (e.g., library search paths, DLL planting, untrusted inputs) when followed, but the control only sets principles and reviews rather than enforcing any specific runtime mechanism, leaving residual paths on all three platforms.
T1574.001detects — A.8.27 mandates security-oriented design reviews, threat analysis against known attack patterns, hardening, and zero-trust monitoring principles that can surface some DLL abuse vectors (e.g., anomalous loading or sideloading in reviewed architecture), but this is limited to what the design review or hardening catches and does not broadly instrument runtime detection of the technique.
T1574.001prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, hardening, secure session control, data validation/sanitisation and zero-trust verification that, when applied during engineering, stop many DLL side-loading, search-order and phantom-hijacking patterns at the source; it does not reach every implementation detail or every already-deployed binary, leaving a genuine minority slice unaddressed.
T1574.004detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and regular review of principles against new threats; these surface dylib hijacking risks in architecture and code (e.g. via @rpath/weak linking analysis) but do not instrument runtime detection of the technique once deployed.
T1574.004prevents — A.8.27 mandates security-by-design, defence-in-depth, least privilege, hardening, secure session control, data validation/sanitisation and zero-trust verification applied across the engineering life cycle; these directly constrain the search-path, weak-linking and library-loading decisions that enable dylib hijacking on macOS, but the clause is a set of principles and reviews rather than an enforced runtime mechanism, leaving residual gaps in implementation and legacy code.
T1574.005detects — A.8.27 mandates security-oriented design reviews, hardening, and analysis of controls (including detection capabilities) plus regular review for new threats, which can surface installer permission weaknesses during development or architecture review, but does not itself perform or require runtime/operational detection of the technique.
T1574.005prevents — A.8.27 mandates applying security-by-design, least privilege, default-deny, hardening, secure defaults and zero-trust principles during architecture and engineering; these directly address improper permissions and insecure temp-directory creation in installers, but the control is a process that depends on how rigorously those principles are followed in any given development project, leaving a slice of residual risk.
T1574.006detects — A.8.27 mandates security-oriented design reviews, threat analysis, and ongoing review of engineering principles to identify vulnerabilities and keep up with new threats; this surfaces the class of dynamic-linker hijacking risks during design and when new attack patterns emerge, but does not itself instrument or monitor running systems for occurrences of the technique.
T1574.006prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, hardening, secure defaults and zero-trust principles plus design reviews that explicitly consider attack patterns; these directly constrain the class of environment-variable and library-precedence flaws that enable dynamic-linker hijacking, but the control is a set of engineering practices rather than an enforceable runtime mechanism, leaving a large slice (implementation gaps, legacy code, outsourced components) unaddressed.
T1574.007detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of engineering principles against new threats, which can surface PATH interception risks in architecture or code but does not mandate runtime detection mechanisms.
T1574.007prevents — A.8.27 mandates applying security engineering principles (least privilege, security by default, default deny, hardening, secure design reviews, distrust external input) that can stop PATH hijacking at design and hardening time, but the clause is a process that depends on how rigorously those principles are chosen and applied, leaving a real slice of implementations where the weakness remains.
T1574.008detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of engineering principles to identify vulnerabilities and new threats, which can surface search-order weaknesses in custom or reviewed software but does not broadly instrument or monitor for the runtime technique across deployed Windows environments.
T1574.008prevents — A.8.27 mandates security-by-design, defence-in-depth, least privilege, least functionality, hardening, distrust-external-input and secure-engineering reviews that can eliminate vulnerable search-order patterns during architecture and implementation; this stops the technique from being present in the built system, but only where the principles are actually applied to the relevant code paths and supplier deliverables.
T1574.009detects — A.8.27 mandates security-oriented design reviews, hardening, and ongoing review of engineering principles against known attack patterns and new threats, which surfaces unquoted-path vulnerabilities during architecture and implementation reviews, but does not mandate runtime detection or monitoring of the technique in operation.
T1574.009prevents — A.8.27 mandates security-by-design, defence-in-depth, least privilege, hardening, secure coding principles (including input sanitisation and architecture reviews against known attack patterns) that reach the class of unquoted-path hijack when applied to Windows service/shortcut configuration and deployment; the remainder is that the control is a process that does not itself guarantee the specific hardening step on every path, and the clause's own text limits application to 'where applicable'.
T1574.010detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of engineering principles to identify vulnerabilities and ensure controls like least privilege and proper permissions; this surfaces the permission weakness during design, review or monitoring of architecture but does not broadly instrument runtime detection of the hijacking technique itself.
T1574.010prevents — A.8.27 mandates applying security-by-design, least privilege, default-deny, hardening, and secure engineering principles (including analysis of required controls and their integration) during architecture and implementation; this directly blocks improper service-file permissions from being introduced, but only for systems built under the control and only to the degree the principles are rigorously followed.
T1574.011detects — A.8.27 mandates security-oriented design reviews to identify vulnerabilities plus ongoing review of principles against new threats, which can surface insecure registry permission designs or patterns before or after deployment, but does not mandate runtime detection mechanisms for the technique itself.
T1574.011prevents — A.8.27 mandates establishing and applying security engineering principles (including least privilege, security by design, defense in depth, secure defaults, hardening, and design reviews against known attack patterns) to the full SDLC; this reaches the class of permission/ACL weaknesses on service Registry keys as a preventable design or configuration flaw, but only as one slice among many engineering activities and without mandating the specific mechanisms that close every such instance.
T1574.012detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of engineering principles against new threats/attack patterns, which can surface COR_PROFILER abuse in .NET CLR loading during architecture and code review; this is a genuine but minority slice because the control is scoped to development/engineering activities and does not mandate runtime monitoring of environment-variable or in-memory profiler registration across deployed systems.
T1574.012prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, hardening, distrust-external-input, assume-breach and zero-trust principles plus design reviews that would surface and block unsafe use of COR_PROFILER environment variables or untrusted profiler DLLs in .NET CLR loading; this stops the technique at development time for systems built under it, but the clause is a process requirement whose coverage depends on rigour of application and does not reach every existing .NET process or legacy component.
T1574.013detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust principles, and regular review of engineering practices to identify vulnerabilities and combat new threats; this surfaces the technique in design or post-incident review but does not instrument runtime detection of in-process KernelCallbackTable tampering.
T1574.013prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, hardening, assume-breach and distrust-external-input principles plus design reviews that explicitly target known attack patterns; these reach the class of callback-table hijacking when applied to GUI-process and PEB-handling code, but remain a slice because the clause only requires the principles be established/documented/applied where applicable and does not guarantee their consistent enforcement on every legacy component or outsourced development effort.
T1574.014detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of engineering principles against new threats; these surface AppDomainManager hijacking risks during design or when reviewing for known attack patterns, but only as part of broader architecture analysis rather than runtime detection of the technique.
T1574.014prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, hardening, distrust-external-input and secure-engineering reviews that reach .NET runtime/assembly loading behaviours, so the technique is prevented where those principles are applied; it remains a slice because the clause is a process that depends on implementation rigour and does not guarantee every .NET application or unmanaged configuration is covered.
T1578detects — A.8.27 mandates security-oriented design reviews, threat analysis, and ongoing review of engineering principles to identify vulnerabilities and new threats, which can surface risks or anomalous modifications in cloud compute infrastructure during design/operation but does not mandate runtime detection mechanisms.
T1578prevents — A.8.27 mandates security-by-design, defense-in-depth, least-privilege, zero-trust, hardening, and design reviews that directly constrain how compute infrastructure (instances, VMs, snapshots) is created/modified, making many evasion-enabling modifications impossible when applied; it is only a slice because the clause is a process/governance requirement whose coverage depends on how rigorously the organization implements and enforces it in cloud engineering.
T1578.001prevents — A.8.27 mandates security-by-design, defense-in-depth, least-privilege, assume-breach and zero-trust principles plus architecture reviews that can constrain snapshot-creation permissions and bypass patterns in IaaS designs, but the control is a set of engineering practices rather than an enforceable runtime mechanism, leaving substantial residual where those principles are not fully applied or where permissions still allow the action.
T1578.002detects — A.8.27 mandates security-oriented design reviews, threat analysis, zero-trust verification, and ongoing review of engineering principles that can surface anomalous or risky instance-creation patterns (e.g. new VMs with lax policies), but this is only a slice of possible detections and does not mandate runtime monitoring of the technique itself.
T1578.002prevents — A.8.27 mandates security-by-design, defense-in-depth, least-privilege, zero-trust, and hardening principles that are applied to cloud architecture and engineering; these constrain the creation of instances with overly permissive policies or bypass configurations, but the control is a set of principles and reviews rather than an enforcement mechanism that stops every possible instance-creation action on IaaS platforms.
T1578.003detects — A.8.27 mandates security-oriented design reviews, threat analysis, zero-trust monitoring principles, and regular review of engineering practices that surface anomalous deletion activity or missing forensic artifacts in cloud designs, but this is only a slice of possible detection rather than broad runtime coverage of the technique.
T1578.004detects — A.8.27 mandates security-oriented design reviews, threat analysis, hardening, zero-trust monitoring principles, and regular review of engineering practices that surface anomalous reversion/snapshot activity or ephemeral reset artifacts in IaaS designs, but only where those are scoped into the organization's chosen architecture and review process.
T1578.004prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, assume-breach, hardening, and zero-trust principles that can constrain snapshot/revert abuse and ephemeral-storage patterns when applied to cloud architecture, but the control is a set of engineering principles rather than an enforcement mechanism that stops the post-compromise API or dashboard action itself.
T1578.005detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and regular review of engineering principles to identify vulnerabilities and new threats, which can surface misconfigurations or anomalous quota/region/policy changes in cloud architecture but does not mandate runtime monitoring or anomaly detection of the post-compromise modifications themselves.
T1578.005prevents — A.8.27 mandates security-by-design, defense-in-depth, least-privilege, zero-trust, and explicit review of architecture/controls against threats/attack patterns; this directly constrains insecure quota/region/policy defaults that enable T1578.005, but remains a process applied during engineering rather than an always-on enforcement mechanism that stops post-compromise modification.
T1580prevents — A.8.27 mandates security-by-design, zero-trust, least-privilege, default-deny and hardening principles that, when applied during IaaS engineering, constrain the attack surface and IAM surface an adversary can enumerate via discovery APIs; this is a genuine but minority slice of the technique (most discovery paths remain available once credentials are obtained).
T1584.001prevents — A.8.27 mandates security-by-design, defence-in-depth, least privilege, assume-breach, hardening, and secure engineering reviews that can stop some hijacking vectors (e.g. proper deprovisioning, DNS hygiene, strong domain-management auth) but leaves social-engineering, renewal gaps, and outsourced supplier practices largely untouched.
T1584.002prevents — A.8.27 mandates security-by-design, defense-in-depth, least privilege, assume-breach, and hardening principles plus security-oriented design reviews that, when applied to outsourced development and infrastructure, reduce the likelihood an organization deploys or relies on a third-party DNS server whose compromise would be easy or undetected; this is a genuine but minority slice of the PRE technique whose dominant vector is external compromise of unmanaged DNS providers.
T1584.005prevents — A.8.27 mandates security-by-design, defense-in-depth, least privilege, hardening, zero-trust verification and secure engineering reviews that reduce the attack surface and make large-scale third-party compromise materially harder, but cannot stop every possible initial-access vector an adversary might chain to build or hijack a botnet.
T1584.007detects — A.8.27 mandates security-oriented design reviews, threat analysis, and ongoing review of engineering principles to identify vulnerabilities and new threats; this surfaces risks in serverless designs or compromised functions (e.g. via assume-breach or zero-trust reviews) but does not mandate runtime detection of the post-compromise use for proxying or hiding.
T1584.007prevents — A.8.27 mandates security-by-design, zero-trust, least-privilege, and hardening principles applied throughout the engineering life cycle (including to outsourced development), which directly constrains the insecure serverless configurations that enable T1584.007; it does not guarantee every possible serverless deployment is built that way, leaving a slice of implementations outside its enforced scope.
T1584.008prevents — A.8.27 mandates security-by-design, defense-in-depth, least-privilege, zero-trust, hardening, and secure engineering principles (including for outsourced development) that reduce the likelihood an adversary can compromise and repurpose third-party network devices; this is a genuine but minority slice of the technique because the control addresses only systems built or contracted under the organization's own engineering process, while the bulk of T1584.008 targets unmanaged, already-deployed Internet-edge appliances outside that boundary.
T1586.003prevents — A.8.27 mandates security-by-design, zero-trust, least-privilege, defence-in-depth and secure-engineering principles that, when applied during outsourced or internal development of cloud systems, reduce the attack surface and make credential compromise harder, but do not stop the upstream reconnaissance, phishing-for-information or password-spraying vectors that precede the account takeover.
T1587.003prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, zero-trust, PKI/IAM integration, hardening, and design reviews that explicitly consider attack patterns and certificate trust; this stops many (but not all) adversary self-signed-certificate creation and trust-abuse paths at the architecture/engineering stage.
T1587.004prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, fail-secure, security reviews against known attack patterns, and hardening; these directly constrain the creation and quality of custom exploits an adversary (or its contractors) can produce during targeting, but do not stop all exploit development (e.g., zero-days or outsourced work that evades the principles).
T1588.004prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, zero-trust and hardening principles plus design reviews that can stop many downstream uses of stolen/purchased certificates (e.g. untrusted C2, unverified MitM, weak PKI integration), but the technique itself is an acquisition step performed by the adversary before any defender-controlled system is built or operated, so only a slice of the technique is reached.
T1588.005prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, hardening, and design reviews that reduce the number of exploitable bugs/vulnerabilities created in the first place, so the adversary has fewer ready-made exploits available to buy/steal/download; this is a genuine but minority slice of the technique whose dominant part (acquiring already-public exploits for known third-party or legacy flaws) is untouched.
T1589.001prevents — A.8.27 mandates security-by-design principles (least privilege, MFA/strong auth, zero-trust never-trust/always-verify, secure session control, defense-in-depth) that stop many credential-gathering vectors from succeeding; it does not stop the gathering itself (phishing elicitation, dark-web purchase, breach-dump scraping) so the slice prevented is genuine but bounded.
T1590.004prevents — A.8.27 mandates security-by-design, defence-in-depth, least functionality, assume-breach, zero-trust and hardening principles that shape network architecture to reduce exposed topology details and limit what active scanning or public data sets can reveal; this constrains the technique on systems built under it but does not stop all pre-compromise reconnaissance methods such as phishing for information or searching already-public datasets.
T1593.003prevents — A.8.27 mandates security-by-design, hardening, least-privilege, secure coding, and reviews that reduce accidental credential/API-key leaks into public repos, but cannot stop deliberate public posting of non-sensitive information (languages, libraries, employee names) that still enables the technique.
T1595detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust principles (assume breach, never trust/always verify), and ongoing review of engineering principles against new threats; these surface reconnaissance activity like active scanning in design or monitoring layers but only as a slice dependent on chosen architecture and scope, not a broad detection mechanism.
T1595prevents — A.8.27 mandates security-by-design, defence-in-depth, least functionality, assume-breach, hardening, and explicit analysis of controls that can prevent reconnaissance; these principles applied during architecture and engineering can block many classes of active scanning (e.g. by removing unnecessary services/ports or enforcing default-deny), but the control is a process that depends on implementation rigour and does not guarantee every probe vector is closed.
T1595.001detects — A.8.27 mandates security-oriented design reviews, threat analysis, zero-trust monitoring principles, and regular reviews of engineering procedures that can surface anomalous scanning as a security event or vulnerability during architecture hardening and ongoing reviews, but this is limited to what the organization's chosen security architecture and monitoring scope elects to instrument rather than a dedicated detection mechanism.
T1595.002prevents — A.8.27 mandates security-by-design, defence-in-depth, least functionality, hardening, and regular review of engineering principles that reduce the attack surface and insecure configurations an external vulnerability scan can discover; this stops many (but not all) such scans from succeeding in finding exploitable weaknesses.
T1595.003prevents — A.8.27 mandates security-by-design, defence-in-depth, least functionality, default-deny, fail-securely and zero-trust principles plus design reviews that reduce attack surface and hidden/vulnerable endpoints; this stops many wordlist-discoverable resources from existing or being reachable, but cannot eliminate all (e.g. required public pages or legacy content).
T1598prevents — A.8.27 mandates security-by-design principles (least privilege, assume breach, distrust external input, defence-in-depth, secure session control, data validation/sanitisation, zero-trust verification) that are applied to system architecture and engineering; these directly constrain or block many technical vectors that enable phishing-for-information (spoofing, evasive email manipulation, weak credential handling, missing end-to-end encryption), but the technique is primarily human-targeted social engineering whose success ultimately depends on user behaviour outside the engineered system, leaving a large residual slice.
T1598.001prevents — A.8.27 mandates security-by-design, zero-trust, least-privilege, distrust-external-input, and secure-engineering principles that reduce the success rate of social-engineering lures (e.g., by requiring strong auth, end-to-end encryption of requests, and verification even for internal-origin messages), but cannot stop the adversary from sending the initial spearphishing message via third-party services that lie outside the organization's engineering scope.
T1598.002prevents — A.8.27 mandates security-by-design, defence-in-depth, least privilege, assume-breach, distrust-external-input, hardening, and secure engineering that explicitly covers user authentication, session control, data validation/sanitisation and zero-trust verification; these directly stop many attachment-based credential-harvesting lures (e.g. by blocking execution paths or rendering the attachment inert), but the social-engineering core of crafting and delivering the email itself is untouched by system architecture principles.
T1598.003prevents — A.8.27 mandates security-by-design, defence-in-depth, least privilege, assume-breach, distrust-external-input, security-oriented design reviews and hardening that, when applied to email clients, web browsers and authentication flows, can stop many link-based credential-harvesting lures from succeeding; it does not stop the social-engineering delivery of the message itself or every possible obfuscated/QR/BitB variant, leaving a genuine minority slice prevented.
T1598.004prevents — A.8.27 mandates security-by-design, zero-trust, least-privilege, distrust-external-input, and secure engineering principles that reduce the success rate of vishing pretexts (e.g., by requiring strong MFA, contextual verification, and not relying on caller identity), but does not stop the social-engineering phone call itself or the human disclosure decision.
T1599detects — A.8.27 mandates security-oriented design reviews, threat analysis, and ongoing review of engineering principles to identify vulnerabilities and keep practices current; this surfaces design or configuration weaknesses that could enable boundary bridging on perimeter devices, but does not instrument runtime detection of the technique itself.
T1599prevents — A.8.27 mandates security-by-design, defense-in-depth, least-privilege, zero-trust, and hardening principles plus design reviews that, when applied to boundary devices, reduce the likelihood an adversary can compromise them or reconfigure them to bridge networks; this is a genuine but minority slice of the technique (most of which lives in post-deployment configuration, credential, and patching weaknesses outside the engineering principles themselves).
T1599.001detects — A.8.27 mandates security-oriented design reviews, threat analysis, and ongoing review of engineering principles to identify vulnerabilities and keep practices current, which can surface risky NAT configurations or modifications as part of architecture review or threat modeling, but does not mandate runtime/operational detection mechanisms for the technique once underway.
T1599.001prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, assume-breach, and zero-trust principles plus architecture reviews that would normally preclude insecure NAT configurations allowing boundary bridging; this is genuine but only a slice because the control is a process/guidance clause whose effect depends on how rigorously the principles are applied to the specific network device.
T1600detects — A.8.27 mandates security-oriented design reviews, analysis of controls' detection/response capabilities, hardening, zero-trust verification, and ongoing review of principles against new threats; this surfaces some weakening behaviors (e.g. via reviews or monitoring of crypto/integrity) but does not instrument or guarantee detection of post-deployment device compromise on network devices.
T1600prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, hardening, zero-trust verification and explicit analysis of controls (including crypto) against threats and attack patterns; this directly constrains the device-level weakening behaviours named in T1600, but only for systems built or reviewed under the principles — it does not stop an already-deployed or supplier-delivered device from being compromised post-shipment.
T1600.001detects — A.8.27 mandates security-oriented design reviews, hardening, and ongoing review of engineering principles against new threats/attack patterns, which can surface weakened crypto configurations (including reduced key space) during design, implementation or post-deployment review, but only where those activities explicitly include crypto analysis rather than general architecture.
T1600.001prevents — A.8.27 mandates security-by-design, defence-in-depth, least functionality, hardening, and explicit review of designs/controls against known attack patterns (including crypto strength and key-management choices), which stops the weakened-cipher configuration from being introduced during engineering; it does not reach post-deployment modification of already-deployed images.
T1600.002detects — A.8.27 requires security-oriented design reviews, analysis of controls' detection capabilities, hardening, zero-trust verification, and ongoing review of principles against new threats; these surface design or configuration choices that disable crypto hardware (or the tampering that enables it) during engineering or review, but only within the development/outsourced lifecycle and not against post-deployment adversarial use of T1600.002 on live network devices.
T1600.002prevents — A.8.27 mandates security-by-design, defense-in-depth, least functionality, hardening, and explicit review of architecture against known attack patterns and threats to crypto; this directly constrains the class of design/implementation choices that would allow an adversary to disable hardware crypto (or to deploy devices lacking tamper-resistant hardware crypto), but leaves a bounded remainder for legacy devices, outsourced implementations that do not fully adopt the principles, and post-deployment configuration changes.
T1601detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of engineering principles to surface vulnerabilities and deviations, which can detect modifications to a monolithic system image in embedded devices during design, review, or runtime anomaly checks, but this is limited to scoped implementation choices rather than comprehensive detection of all live or storage-based changes.
T1601prevents — A.8.27 mandates security-by-design, hardening, least-privilege, assume-breach, and secure-engineering reviews that can stop many classes of OS-image modification (e.g., by enforcing integrity checks, secure boot, and distrust of external input), but leaves a bounded remainder for live-memory or storage attacks on already-deployed monolithic firmware that the principles do not mechanically block.
T1601.001detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and regular review of principles against new threats, which surfaces some classes of patchable weaknesses or anomalous modifications during engineering and review but does not instrument or discover live in-memory/storage patching once deployed on network devices.
T1601.001prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, hardening, secure reviews against attack patterns, and zero-trust principles that reach network-device OS images and boot processes, but leaves a bounded remainder (e.g., supply-chain images, post-deployment runtime patching, and legacy monolithic firmware) unaddressed.
T1601.002detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and regular review of principles against new threats; these surface downgrade attempts or the resulting weakened state in reviewed/operated systems, but only where the engineering process or monitoring scope reaches the network device (a bounded slice, not the bulk of post-deployment or un-reviewed embedded cases).
T1601.002prevents — A.8.27 mandates security-by-design, hardening, least functionality/privilege, assume-breach, and regular review of engineering principles that would normally stop an older/weaker image from being introduced or made bootable; this reaches the embedded/network-device slice only where those principles are actually applied to firmware/OS selection and supplier contracts, leaving a large remainder on unmanaged or legacy devices.
T1602detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust principles, and ongoing review of engineering practices that surface anomalous access or misconfigurations in repositories during design and operation, but this is limited to what the architecture review and monitoring scope explicitly cover rather than broad runtime detection of the T1602 collection technique.
T1602prevents — A.8.27 mandates security-by-design, zero-trust, least-privilege, defense-in-depth and hardening principles that, when applied during engineering, can block many common exposure paths (e.g. default-deny, distrust-external-input, strong auth on repository access), but the control is a process that depends on implementation rigor and does not guarantee every configuration repository will be built without an exploitable flaw or misconfiguration.
T1602.001detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of engineering principles to identify vulnerabilities and new threats; this surfaces SNMP/MIB exposure risks during architecture and review stages but does not mandate runtime detection of the T1602.001 technique itself.
T1602.001prevents — A.8.27 mandates security-by-design, defense-in-depth, least privilege, least functionality, assume-breach, and hardening that can remove SNMP/MIB exposure (e.g. disable unnecessary SNMP, restrict OIDs, enforce strong auth on queries) before the technique can run, but the control is a set of engineering principles rather than a concrete mechanism, so coverage depends on what the implementer actually selects and remains a slice rather than the bulk of the class.
T1602.002detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of engineering principles to surface vulnerabilities and new threats; this can detect insecure config exposure patterns (e.g. via SNMP/SMI) during architecture reviews or threat analysis, but does not mandate runtime detection of the technique itself.
T1602.002prevents — A.8.27 mandates security-by-design, defense-in-depth, least privilege, zero-trust, hardening, and secure architecture principles that, when applied during engineering, can block many of the access vectors (e.g. weak SNMP defaults, unauthenticated SMI, overly permissive management interfaces) that enable T1602.002; it does not reach every possible dump method on every legacy or misconfigured device.
T1606detects — A.8.27 mandates security-oriented design reviews, threat analysis against known attack patterns, and ongoing review of engineering principles for new threats; this surfaces the possibility of credential-forging techniques during architecture and implementation but does not instrument runtime detection of the forged material in use.
T1606prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, assume-breach, distrust-external-input, secure session control, proper authentication techniques and zero-trust verification that together stop most forgery paths at design time; residual attack surface remains when implementation flaws, misconfigured IAM/PKI, or unhardened token-generation APIs are still present.
T1606.001detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification of requests, and ongoing review of principles against new threats; these surface cookie-forging vectors or anomalous use in architecture but do not instrument runtime detection of the technique itself.
T1606.001prevents — A.8.27 mandates applying security-by-design, defence-in-depth, least-privilege, secure session control, distrust-external-input, fail-securely and zero-trust principles (never trust/always verify, end-to-end encryption, contextual MFA) during architecture and engineering; these directly constrain the cookie-forging path that bypasses authentication, but only where the principles are actually translated into the concrete mechanisms (e.g. proper HMAC secrets, short-lived signed cookies, device-binding) chosen by the implementer.
T1606.002detects — A.8.27 mandates security-oriented design reviews, threat analysis against known attack patterns, zero-trust verification principles, and regular review of engineering practices to surface new threats; these can surface SAML token forgery risks in architecture or implementation but do not instrument runtime detection of the technique itself.
T1606.002prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, assume-breach, distrust-external-input, secure authentication/session principles, hardening, and zero-trust verification that together constrain SAML token forgery vectors (e.g. by requiring strong PKI/IAM controls, end-to-end encryption, contextual authz, and design reviews against known attack patterns), but leaves residual gaps such as stolen signing keys or misconfigured federation trusts that the clause does not itself close.
T1608.003prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, hardening, and explicit review of designs/controls against known attack patterns and zero-trust principles; these constrain the adversary's ability to install untrusted/self-signed certs for C2 or phishing by requiring proper PKI/IAM integration and validation, but the control is a process applied during engineering and does not block post-compromise or PRE-stage installation on acquired infrastructure.
T1608.004prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, distrust-external-input, fail-securely and hardening principles plus design reviews that directly reduce the likelihood an adversary can stage malicious web content or exploitable browser flaws for drive-by delivery; the coverage is only a slice because the control is a process that depends on how rigorously those principles are applied and does not itself block every possible staging vector (e.g. typosquatting or malvertising on third-party ad networks).
T1608.005prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, assume-breach, distrust-external-input, secure architecture reviews and hardening that, when applied to web-facing systems and phishing vectors, stops many link-target setups (cloned phishing sites, malicious redirects, unsafe URL handling) from being introduced; it does not stop all (e.g. adversary-controlled external domains, IPFS hosting, or post-deployment changes).
T1609detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of engineering principles to surface vulnerabilities and misconfigurations in system architecture (including container platforms), which can detect abuse patterns of container admin services, but this is limited to design-time and review activities rather than runtime detection of the technique.
T1609prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, zero-trust, hardening, and secure engineering that explicitly includes authentication, authorization, and input distrust; these directly stop many abuse paths (e.g. unauthenticated docker exec, weak kubelet perms, unsafe entrypoints) but leave residual cases (e.g. legitimate admin with stolen strong creds, misconfigured but compliant deployments, or overrides for safety).
T1610detects — A.8.27 mandates security-oriented design reviews, threat analysis, zero-trust verification, hardening, and ongoing review of engineering principles that surface insecure container deployments (e.g. privileged/vulnerable images, missing network rules or least-privilege), but this is limited to the design/engineering phase and does not broadly instrument runtime detection of an adversary's T1610 action.
T1610prevents — A.8.27 mandates security-by-design, least-privilege, default-deny, hardening, zero-trust and secure-engineering reviews that stop many insecure/privileged container deployments before they can be used for execution or evasion; it does not reach every deployment vector (e.g. compromised build pipelines or runtime API abuse) so the coverage is a genuine but incomplete slice.
T1611detects — A.8.27 mandates security-oriented design reviews, threat analysis, hardening, zero-trust verification, and regular review of principles to surface vulnerabilities and misconfigurations that enable container/host escapes; this detects classes of the technique during engineering but does not instrument runtime detection of the escape itself.
T1611prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, least-functionality, hardening, secure reviews against attack patterns, and zero-trust principles that directly shape container/virtualization isolation boundaries; this stops many documented escape vectors (privileged containers, bind mounts, default-allow sockets, missing hardening) before they are instantiated, but leaves residual paths that still require runtime detection, patching or specific configuration not guaranteed by the engineering principles alone.
T1612detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and regular review of engineering principles against new threats; these surface the suspicious local build of a malware-laden image (or its Dockerfile) as a vulnerability or anomalous engineering practice, but only where the review/monitoring scope chosen by the implementer actually reaches container build activity on hosts.
T1612prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, hardening, assume-breach, and security-oriented design reviews that explicitly consider attack patterns; these principles applied during container build pipelines and image construction would stop many (but not all) malicious Dockerfile or build-API patterns on the host.
T1613detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust monitoring principles, and regular review of engineering practices to surface new threats; this can surface anomalous container-discovery behavior in a designed/monitored environment but does not mandate runtime detection mechanisms and leaves most of the technique's post-breach execution slice untouched.
T1613prevents — A.8.27 mandates security-by-design, defence-in-depth, least privilege, zero-trust, hardening, and design reviews that reduce the attack surface and limit discovery surfaces (e.g. via default-deny, distrust-external-input, integrated controls, and secure architecture), but does not stop an already-authenticated adversary from querying the Docker/K8s APIs or dashboards that remain exposed inside the container environment.
T1615detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust principles, and regular review of engineering practices to identify vulnerabilities and new threats; this surfaces reconnaissance patterns like Group Policy discovery in design/operational reviews but only as a slice (not routine runtime detection of gpresult/PowerShell use).
T1619detects — A.8.27 mandates security-oriented design reviews, threat analysis, zero-trust verification, and ongoing review of engineering principles that can surface anomalous discovery/enumeration patterns in cloud storage designs or implementations, but this is indirect governance of the development process rather than runtime detection of the technique.
T1619prevents — A.8.27 mandates security-by-design, zero-trust, least-privilege, and hardening principles that can constrain discovery APIs and default-open storage buckets when applied to cloud architectures, but the control is a process for establishing/reviewing principles rather than a concrete mechanism that stops enumeration, leaving most IaaS discovery paths reachable.
T1620detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and regular review of principles against new threats/attack patterns, which can surface reflective loading as a design or runtime risk in reviewed systems, but this is limited to what the organization chooses to review or instrument rather than broad detection of the technique in operation.
T1620prevents — A.8.27 mandates applying security-by-design, defence-in-depth, least privilege, least functionality, hardening, security-oriented design reviews, and zero-trust principles (never trust/always verify, assume breach) during architecture and engineering; these can stop many reflective loading techniques from being introduced or viable at build time, but the control is a process that depends on implementation rigour and does not reach every possible in-memory loading vector or post-deployment abuse.
T1621detects — A.8.27 mandates security-oriented design reviews, threat analysis against known attack patterns, zero-trust verification of every request, and regular review of principles to combat new threats; this surfaces MFA-fatigue or request-generation abuse during design/engineering but does not instrument runtime detection of the live technique.
T1621prevents — A.8.27 mandates security-by-design principles (least privilege, zero-trust never-trust/always-verify, strong MFA per 8.5, fail-secure, defence-in-depth) that directly shape authentication flows to block automated MFA-request generation and fatigue attacks at design time; this is genuine but only a slice because the clause is a process/guidance control whose effect depends on how rigorously those principles are applied in a given implementation.
T1622prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, assume-breach, hardening, and security-oriented design reviews that explicitly consider known attack patterns; these principles applied during engineering directly stop many debugger-evasion checks (e.g. by removing debug artifacts, enforcing fail-secure behaviours, or integrating anti-analysis controls), but the control is a set of high-level principles rather than a concrete mechanism that guarantees removal of every possible evasion vector an adversary can code.
T1647prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, hardening, secure defaults and zero-trust principles that, when applied during engineering, constrain plist-modification vectors for persistence or evasion; this is a genuine but minority slice of the technique because the control is a process that depends on implementation rigour and does not reach every plist surface or post-deployment change.
T1648detects — A.8.27 mandates security-oriented design reviews, threat analysis against known attack patterns, and ongoing review of principles to combat new threats; this surfaces serverless abuse risks during architecture/engineering but does not instrument runtime detection of the technique itself.
T1648prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, assume-breach, zero-trust and hardening principles plus design reviews that, when applied to serverless engineering, stop many abuse patterns (e.g. overly permissive IAM roles, unauthenticated triggers, missing input sanitisation); residual paths remain because the clause only sets principles and reviews, not universal enforcement of correct implementation across every possible serverless resource or event trigger.
T1649detects — A.8.27 mandates security-oriented design reviews, threat analysis against known attack patterns, hardening, and ongoing review of principles to combat new threats, which surfaces certificate-related misconfigurations, weak PKI/IAM designs, and insecure certificate handling during engineering — but does not instrument runtime detection of theft or forgery once deployed.
T1649prevents — A.8.27 mandates security-by-design, defense-in-depth, least-privilege, zero-trust, hardening, and secure engineering of authentication/PKI/IAM layers (including review against attack patterns), which stops many certificate theft/forgery vectors at design time; it does not reach all implementation flaws, misconfigurations, or runtime enrollment abuses named in the technique.
T1651detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust principles, assume-breach, and ongoing review of engineering principles to identify vulnerabilities and new threats; this surfaces the abuse of cloud admin command services as a design or runtime risk in IaaS but does not mandate or perform detection instrumentation itself.
T1651prevents — A.8.27 mandates security-by-design, zero-trust, least-privilege, assume-breach, and hardening principles that, when applied during architecture and engineering, constrain the administrative pathways and agent trust assumptions abused by T1651; this is a genuine but minority slice of the technique (most real-world abuse occurs post-compromise of already-deployed admin accounts rather than at design time).
T1653prevents — A.8.27 mandates security-by-design, defence-in-depth, least functionality, hardening, and secure configuration principles that reach power/hibernation/lock settings when applied during engineering; this stops the abuse vector at build time for systems built under it, but the clause is a process (not a mechanism) whose coverage depends on implementer rigour and does not reach already-deployed systems or all platforms.
T1654detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust monitoring principles, and regular review of engineering procedures to surface new threats; this surfaces log-enumeration activity as anomalous behavior in a designed architecture but only where the resulting controls (e.g. monitoring scope) happen to cover it, leaving the bulk of the technique (real-time SIEM targeting, bulk export, host-binary use on unmonitored platforms) outside the clause's direct effect.
T1657prevents — A.8.27 mandates security-by-design, zero-trust, least-privilege, defense-in-depth, secure session control, data validation/sanitization, hardening, and reviews that stop many technical vectors (account compromise, unauthorized transfers, weak auth) and some social-engineering precursors, but cannot block pure social engineering, extortion demands after ransomware, or post-breach monetary demands that do not rely on preventable design flaws.
T1659detects — A.8.27 mandates security-oriented design reviews, threat analysis, zero-trust verification, and ongoing review of engineering principles to identify vulnerabilities and new threats, which can surface content injection risks in architecture or upstream channels, but this is limited to design-time and does not mandate runtime detection mechanisms.
T1659prevents — A.8.27 mandates security-by-design, defense-in-depth, assume-breach, least-privilege, distrust-external-input, hardening, and zero-trust verification/encryption that constrain or block many upstream-channel content-injection vectors (e.g., by requiring end-to-end encryption and never-trust verification even for internal traffic), but leaves a bounded remainder where upstream ISP-level or lawful-interception compromises occur before the organization's design layer.
T1665detects — A.8.27 mandates security-oriented design reviews, threat analysis, zero-trust verification, and ongoing review of engineering principles against new threats; this surfaces some hiding techniques (e.g., domain masking, traffic filtering that deviates from expected patterns) during architecture and deployment but does not instrument runtime detection of live C2 evasion on deployed systems.
T1665prevents — A.8.27 mandates security-by-design, defense-in-depth, least privilege, assume-breach, zero-trust, hardening, and design reviews that reduce the feasible attack surface and force adversaries to expend more effort on traffic filtering, domain masking, and proxy/VPN blending, but does not stop the technique from being executed against systems built under it.
T1666detects — A.8.27 mandates security-oriented design reviews, threat analysis, and ongoing review of engineering principles to identify vulnerabilities and ensure controls (including those that detect events) are specified; this surfaces gaps in hierarchy/modification defenses during design and review but does not itself monitor or detect the runtime technique.
T1666prevents — A.8.27 mandates security-by-design, defense-in-depth, least-privilege, zero-trust and architecture reviews that, when applied during IaaS engineering, can stop many hierarchy-modification paths (e.g. by enforcing SCPs, IAM boundaries and default-deny at organizational layers); residual attack surface remains because the control is a process that depends on implementation rigor and cannot block every post-compromise API call (LeaveOrganization, CreateAccount, subscription hijacking) once credentials are obtained.
T1667detects — A.8.27 mandates security-oriented design reviews, threat analysis, and monitoring-capable principles (e.g. assume breach, defense in depth, zero-trust verification) that surface anomalous inbound email floods or signup patterns as security events, but the clause is about engineering practices rather than mandating runtime detection tooling or coverage of all bombing vectors.
T1669detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust principles, and ongoing review of engineering practices that surface anomalous wireless behaviors or insecure Wi-Fi configurations as vulnerabilities during design/operation, but this is limited to what the architecture review and monitoring scope choose to cover rather than broadly detecting the technique in flight.
T1669prevents — A.8.27 mandates security-by-design, defense-in-depth, least privilege, zero-trust, hardening, and secure architecture principles that reach wireless network configuration, authentication, and segmentation; this stops many (but not all) paths to unauthorized Wi-Fi connection, especially those relying on weak defaults, missing MFA, or perimeter-only trust.
T1671detects — A.8.27 mandates security-oriented design reviews, threat analysis against known attack patterns, and ongoing review of engineering principles for new threats; this surfaces the malicious OAuth integration risk during design or review of SaaS/cloud architecture, but does not instrument runtime detection of the technique once deployed.
T1671prevents — A.8.27 mandates security-by-design, zero-trust, least-privilege, and secure engineering principles (including authentication, session control, and integration reviews) that can stop malicious OAuth app creation/consent when applied to SaaS/Cloud architecture, but the control is a high-level process that does not guarantee enforcement or block all integration vectors (e.g., co-opting existing apps or post-consent persistence).
T1673detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust monitoring principles, and regular review of engineering procedures to surface new threats; this can surface anomalous VM-enumeration activity (especially via hypervisor CLI or vCenter) when those are inside the chosen security architecture and monitoring scope, but the clause itself sets requirements rather than mandating instrumentation depth or coverage of all discovery vectors.
T1673prevents — A.8.27 mandates security-by-design, defense-in-depth, least privilege, least functionality, hardening, and assume-breach principles that can be applied to hypervisor/VM configurations to block many discovery vectors (e.g. disabling unnecessary CLI/GUI interfaces or restricting their use), but does not guarantee removal of all enumeration paths on every platform or after initial access.
T1674detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of engineering principles against new threats; these surface input-injection risks (e.g. via attack-pattern review or assume-breach analysis) in the engineering phase or when new technology is introduced, but do not instrument runtime detection of the live technique.
T1674prevents — A.8.27 mandates security-by-design principles (least privilege, default-deny, distrust external input, fail-secure, hardening, zero-trust verification) plus design reviews that explicitly address input handling and sanitization, which can stop many classes of simulated-keystroke injection before the vulnerable component is built or deployed; it reaches only a slice because the control is a process/guidance clause whose effect depends on how rigorously those principles are applied to every possible input vector (HID, message-loop hooks, GUI automation) and does not itself enforce a concrete mechanism.
T1675detects — A.8.27 mandates security-oriented design reviews, threat analysis against known attack patterns, zero-trust verification, and ongoing review of engineering principles to surface vulnerabilities; this can detect the abuse pattern in architecture or during reviews, but only for systems built under it and not for already-deployed ESXi environments or runtime technique execution.
T1675prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, assume-breach, zero-trust and hardening principles plus design reviews that, when applied to the virtualisation layer and guest-management services, can stop the abuse path (e.g. by removing unauthenticated guest APIs or enforcing strong per-VM auth); this is genuine but only a slice because the clause is a process that depends on implementer rigour and does not itself block the technique on every ESXi deployment.
T1677detects — A.8.27 mandates security-oriented design reviews to identify vulnerabilities plus regular review of engineering principles against new threats; this surfaces some poisoned-pipeline risks (especially public/PR-triggered scenarios) during architecture and code-review stages, but does not instrument runtime detection of the technique once the pipeline is executing.
T1677prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, distrust-external-input, secure-review of architecture against known attack patterns, hardening, and secure engineering principles applied throughout the SDLC (including to outsourced development); these directly address the design and configuration flaws that enable Direct, Indirect and Public pipeline poisoning, but stop short of guaranteeing enforcement on every pipeline, every pull-request trigger, or every self-hosted runner, leaving a genuine residual slice.
T1678detects — A.8.27 mandates security-oriented design reviews, threat analysis, and ongoing review of engineering principles to identify vulnerabilities and keep up with new threats; this surfaces time-based evasion patterns like sleep, scheduling, loops, or API hammering during design or post-deployment review, but only where those patterns are known and the review scope includes them.
T1679detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of principles against new threats/attack patterns, which can surface selective-exclusion behaviors in ransomware engineering or testing but does not instrument runtime detection of the technique itself.
T1680prevents — A.8.27 mandates security-by-design principles (least privilege, least functionality, default-deny, zero-trust verification) and hardening that can remove or restrict many of the CLI/API commands and unneeded storage interfaces adversaries use for discovery; this is a genuine but minority slice of the broad, cross-platform technique that also includes built-in utilities required for normal operation.
T1683.002detects — A.8.27 mandates security-oriented design reviews, analysis of controls that can detect security events, hardening, and regular review of principles against new threats including AI-assisted synthetic media, which surfaces the technique or its artifacts in the engineering process, but only for in-scope systems and not the adversary's external/pre-attack generation.
T1684detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust principles, and regular review of engineering practices to identify vulnerabilities and new threats; this surfaces some social-engineering vectors (e.g., via assume-breach or distrust-external-input reviews of workflows and consent mechanisms) but does not instrument or discover actual adversary social-engineering attempts in operation.
T1684prevents — A.8.27 mandates security-by-design, defense-in-depth, least privilege, assume-breach, distrust-external-input, secure session control, data validation/sanitization, and zero-trust verification that together stop many social-engineering outcomes (e.g., unauthorized access, MFA changes, malicious payload execution) at the system layer; it does not stop the human-influence step itself or every possible persuasion channel, leaving a genuine minority slice unaddressed.
T1684.001detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and regular review of principles to identify vulnerabilities and new threats, which surfaces impersonation risks in architecture and engineering (e.g. via email spoofing or weak auth) but does not instrument runtime detection of the social-engineering technique itself.
T1684.001prevents — A.8.27 mandates security-by-design principles (least privilege, assume breach, never trust/always verify, distrust external input, defence-in-depth, secure session control, authentication techniques) that directly constrain the social-engineering trust-abuse path of impersonation when applied to identity, email, and access layers; this is a genuine but minority slice of the technique (most impersonation campaigns still succeed via human factors outside engineered controls).
T1684.002detects — A.8.27 mandates security-oriented design reviews to identify vulnerabilities plus ongoing review of principles against new threats; this surfaces weak/absent DMARC/SPF/DKIM configurations that enable header spoofing, but the clause is about engineering practices rather than runtime detection mechanisms and does not reach all delivery-path or post-delivery cases.
T1684.002prevents — A.8.27 mandates establishing and applying security engineering principles (including security by design, least privilege, distrust external input, defence in depth, secure defaults, and explicit analysis of required controls for authentication/integrity) to the full SDLC; this directly shapes email-system architecture, DMARC/SPF/DKIM policy strength, header-validation logic, and hardening that stop spoofed headers from reaching inboxes, but remains a process-level requirement whose completeness depends on how rigorously the principles are implemented and reviewed.
T1685detects — A.8.27 mandates security-oriented design reviews, hardening, defence-in-depth, assume-breach, and zero-trust monitoring architecture that can surface tampering with tools or sensors when the design itself is reviewed or when residual telemetry survives the tampering attempt; this is a genuine but minority slice of the broad technique that also covers direct process kills, registry edits, and driver-based bypasses outside any design review.
T1685prevents — A.8.27 mandates security-by-design, defense-in-depth, least privilege, assume-breach, hardening, and zero-trust principles that reduce the attack surface and make tampering with or disabling security tools materially harder; this is a genuine but minority slice of the broad technique that also covers post-compromise process-killing, ETW redirection, and driver-based bypasses on already-deployed systems.
T1685.001detects — A.8.27 mandates security-oriented design reviews, threat analysis, zero-trust monitoring principles, and integration of detective controls (including logging) into architecture layers, which surfaces tampering attempts against Event Log configuration or service state during design, review, or operation.
T1685.001prevents — A.8.27 mandates security-by-design, defence-in-depth, least functionality, assume-breach, hardening, and explicit review against known attack patterns; these principles applied during engineering can remove or lock-down the service-start, registry, and auditpol vectors that T1685.001 relies on, but the clause is a process that depends on how rigorously the implementer applies it and does not guarantee every Windows build will be immune.
T1685.002detects — A.8.27 mandates security-oriented design reviews, threat analysis, and ongoing review of engineering principles to identify vulnerabilities and ensure controls (including logging) are specified and effective, which surfaces gaps or modifications in logging as part of architecture review but does not monitor runtime tampering or provide detection instrumentation.
T1685.002prevents — A.8.27 mandates security-by-design, defense-in-depth, least functionality, assume-breach, and explicit logging-related principles (e.g. integrity checking, fail securely, zero-trust verification) that, when applied during architecture and engineering, stop many classes of disable/modify-logging mechanisms from being introduced; it does not reach every permission, configuration, or post-deployment change an adversary with sufficient rights can still make.
T1685.003detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, assume-breach, and integrated controls that surface spoofed/misleading UIs as design or runtime anomalies, but this is limited to what the engineering process or architecture can instrument and does not guarantee detection of all post-compromise UI manipulations.
T1685.003prevents — A.8.27 mandates security-by-design, defense-in-depth, least privilege, assume-breach, hardening, and security-oriented design reviews that surface spoofable UIs or missing integrity checks before deployment; this stops many (but not all) instances of the technique from being introduced.
T1685.004detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust monitoring principles, and regular review of engineering procedures to surface new threats; this surfaces tampering with auditd via design review or anomaly detection in hardened/zero-trust setups but does not mandate runtime detection of the technique itself.
T1685.004prevents — A.8.27 mandates security-by-design, defence-in-depth, least functionality, hardening, assume-breach, and secure engineering reviews that include logging/analysis of threats; these reduce the likelihood an adversary with root can silently disable auditd, but do not stop a determined root-level attacker who already has privileges from killing the daemon or editing its rules.
T1685.005detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust monitoring principles, and regular review of engineering practices to surface new threats; this can surface anomalous log-clearing activity as part of assume-breach or defense-in-depth but does not mandate or guarantee runtime detection of the technique itself.
T1686detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, assume-breach monitoring principles, and regular review of engineering procedures against new threats, which surfaces some firewall-tampering behaviors (especially in reviewed/outsourced systems or via anomalous access patterns) but does not mandate runtime detection mechanisms or cover all post-compromise modification vectors on every platform.
T1686prevents — A.8.27 mandates applying security-by-design, defense-in-depth, least-privilege, least-functionality, default-deny, fail-securely and zero-trust principles plus hardening and design reviews that reduce the attack surface and make unauthorized firewall changes far harder; this stops many (but not all) instances of the technique, especially those relying on weak defaults, missing segmentation or overly permissive rules.
T1686.001detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of engineering principles to surface vulnerabilities and misconfigurations like permissive firewall rules, but this is limited to the design/engineering phase and does not broadly instrument runtime detection of post-deployment adversarial modifications.
T1686.001prevents — A.8.27 mandates applying security-by-design, defense-in-depth, least-privilege, default-deny, zero-trust and hardening principles plus security-oriented design reviews that would normally stop insecure firewall rules from being introduced; this reaches the design/implementation slice of the technique but not runtime modification by an already-privileged adversary inside a deployed cloud environment.
T1686.002detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of principles to identify vulnerabilities and new threats, which can surface some firewall misconfigurations or bypass patterns in reviewed systems but does not mandate runtime detection mechanisms or cover all post-deployment adversarial modifications on network devices.
T1686.002prevents — A.8.27 mandates security-by-design, defense-in-depth, least-privilege, zero-trust and hardening principles plus design reviews that, when applied to network devices, stop many classes of firewall-rule tampering from being possible; the remainder (post-compromise admin access via valid accounts or exploited public-facing apps) is a bounded, nameable slice left to other controls.
T1686.003detects — A.8.27 mandates security-oriented design reviews, hardening, zero-trust verification, and ongoing review of engineering principles against new threats; these surface anomalous firewall changes or weak configurations during design, deployment, or review, but only for systems built under the process (not post-compromise runtime detection of adversary modifications on arbitrary Windows hosts).
T1686.003prevents — A.8.27 mandates applying security-by-design, defense-in-depth, least functionality, default-deny, hardening, and zero-trust principles (including never-trust/always-verify and dynamic access control) during architecture and engineering; these directly shape host firewall configuration and rule sets so the adversary technique cannot succeed, but the clause is a process that depends on implementation rigor and does not guarantee every possible Windows firewall modification vector is closed.
T1687prevents — A.8.27 mandates security-by-design, defense-in-depth, least-privilege, assume-breach, hardening, and explicit analysis of controls' ability to prevent/detect/respond plus reviews against known attack patterns; this reaches a genuine slice of T1687 (vulnerabilities in defensive components) but leaves a large remainder (0-days, implementation bugs after design, and post-deployment exploits of EDR/AV that secure architecture principles do not stop).
T1688detects — A.8.27 mandates security-oriented design reviews, threat analysis against known attack patterns, hardening, zero-trust/least-privilege principles, and ongoing review of engineering procedures to surface new threats; this can surface safe-mode abuse patterns in architecture or during reviews, but the clause is scoped to development/engineering activities rather than runtime detection of the technique on deployed hosts.
T1688prevents — A.8.27 mandates security-by-design, defense-in-depth, least functionality/privilege, hardening, assume-breach, and secure engineering reviews that explicitly consider boot-time and minimal-service configurations; this constrains the attack surface and forces safe-mode bypasses to be harder, but does not stop an already-privileged adversary from forcing BCD/registry changes that disable EDR loaders.
T1689detects — A.8.27 mandates security-oriented design reviews, analysis of controls' detection/response capabilities, hardening, zero-trust verification, and regular review of principles against new threats, which surfaces downgrade risks in architecture and engineering but does not mandate runtime detection mechanisms for the technique once deployed.
T1689prevents — A.8.27 mandates security-by-design, defense-in-depth, least functionality, hardening, zero-trust verification, and explicit review against known attack patterns (including backward-compatibility risks), which stops many downgrade vectors at design or deployment time, but leaves residual cases (e.g., unpatched legacy components, supplier non-compliance, or post-deployment protocol negotiation) unaddressed.

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

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

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

A01←P →P A02→P A04→P A05→P A06→M A07→P A08→P A09→P A10→P

Why these map — AI rationale (under review)

A01mitigates — A.8.27's zero-trust, least-privilege, default-deny, assume-breach and defence-in-depth principles plus design reviews and hardening limit the blast radius or success rate of some broken-access-control realisations (e.g. certain IDOR or path-traversal patterns), but do not bound or reduce the consequence of the dominant members (missing authz checks, CSRF, function-level bypasses) once the authorization decision itself has failed.
A01prevents — A.8.27 mandates security-by-design, least privilege, default-deny, zero-trust verification and secure architecture principles that directly stop many authorization failures (missing checks, IDOR, function-level bypasses), but does not reach path traversal or CSRF which sit outside the authorization-decision core of the category.
A02mitigates — A.8.27 mandates hardening, secure-by-default, least-privilege, zero-trust and design reviews that reduce (but do not eliminate) the realized impact or attack surface of weak defaults and incomplete hardening once a misconfiguration is present.
A04mitigates — A.8.27 mandates security-by-design principles (including zero-trust, least privilege, defence-in-depth, and explicit end-to-end encryption of requests) that bound the blast radius or consequence of weak/missing crypto for some sensitive data flows, but the clause does not itself supply, enforce or correct the cryptography and leaves the core weakness (absent/weak/misused crypto) intact.
A04prevents — A.8.27 mandates establishing and applying security engineering principles (including security by design, defence in depth, least privilege, zero-trust verification, end-to-end encryption of requests, and hardening) that directly address the design and implementation gaps causing absent/weak/misused cryptography for sensitive data.
A05mitigates — A.8.27 mandates security-by-design principles (defense-in-depth, least privilege, assume-breach, distrust external input, fail-securely, hardening, zero-trust verification) that can bound the blast radius or consequence of a realized injection without stopping the unneutralized crossing itself.
A05prevents — A.8.27 mandates security-by-design, defence-in-depth, least-privilege, distrust-input, fail-securely and explicit data validation/sanitisation principles that, when applied during architecture and engineering, stop untrusted data from reaching an interpreter unneutralised; the coverage is only a slice because the clause is a process that depends on how rigorously those principles are followed in each project, and it does not itself insert the neutralisation code.
A06mitigates — A.8.27 mandates security-by-design, defence-in-depth, least privilege, assume-breach, zero-trust, secure design reviews and hardening that directly reduce the realised impact or blast radius of design-level weaknesses (e.g. missing controls, flawed architecture patterns) even when the weakness is present in the delivered system.
A06prevents — A.8.27 mandates establishing and applying security-by-design, defence-in-depth, least-privilege, fail-securely, zero-trust and other principles plus explicit design reviews against threats and attack patterns, which directly stops most classes of insecure design from being baked into the architecture.
A07mitigates — A.8.27 mandates security-by-design principles (least privilege, zero-trust never-trust/always-verify, defence-in-depth, secure session control, strong MFA) that bound blast radius and make successful authentication-bypass or session-hijack harder to exploit, but the control does not itself correct weak credential storage, flawed reset logic, or missing rate-limiting that allow the failures to occur.
A07prevents — A.8.27 mandates security-by-design principles (least privilege, default deny, distrust external input, secure session control, authentication techniques, zero-trust verification) that directly block many authentication-failure defects when applied in the SDLC; it does not guarantee complete or correct implementation of those principles across all entry points, flows or supplier code, leaving a genuine residual slice.
A08mitigates — A.8.27's security-by-design, defence-in-depth, assume-breach, least-privilege, hardening, and zero-trust principles limit the blast radius or consequence of an integrity failure (e.g. by distrusting input, requiring verification, or isolating compromised components), but do not address the core weakness of trusting code/data without performing integrity checks.
A08prevents — A.8.27 mandates security-by-design, defence-in-depth, least privilege, fail-securely, distrust-external-input, hardening, and explicit design reviews that surface integrity gaps; these directly block many root causes of unsigned updates, insecure deserialization and CI/CD tampering, but the clause is a process that still depends on implementation rigour and does not reach every member (e.g. supply-chain signing of third-party binaries).
A09mitigates — A.8.27's security-by-design, defence-in-depth, assume-breach, zero-trust and hardening principles can bound the blast radius or improve detection layering of missing logging, but do not address the core weakness of events not being logged or alerts not firing.
A10mitigates — A.8.27's security-by-design, fail-securely, defence-in-depth, least-privilege and zero-trust principles (plus design reviews and hardening) bound the blast radius or consequence of many fail-open or inconsistent-state errors, but do not address information-leakage paths or the core logic-flaw error handling that defines the class.
A10prevents — A.8.27 mandates security-by-design, fail-securely, defence-in-depth, least-privilege, security-oriented design reviews and hardening that directly target fail-open behaviour, inconsistent states and information leakage in error paths; this prevents a genuine slice of the class but leaves real remainder (e.g. application-specific logic flaws, runtime exception paths not caught in design review, outsourced code whose error handling deviates from the mandated principles).

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.