A.8.7 Technological
Protection against malware
Structured attributes from ISO/IEC 27002:2022 — control type · CIA properties · cybersecurity concept · operational capability · security domain. What do these mean?
Mapped NIST 800-53 r5 controls (17)
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).
Why these map — AI rationale (under review)
- SI-3mostlyaligns with — Both controls establish layered malware protection combining automated detection tools, configuration management, user awareness, and incident recovery procedures.
- SI-3mostlycovers — A.8.7's requirement to protect assets against malware is largely accounted for by SI-3's specific mechanisms, detection/eradication, updates, and scanning at entry/exit points, but a residual of A.8.7 (e.g., user awareness, non-technical controls, or protection of assets outside system boundaries) remains uncovered.
- AT-2partialaligns with — User awareness and training on recognizing and responding to malware directly fulfills the literacy training requirement.
- CM-7partialaligns with — Application allowlisting and restrictions on unauthorized software implement the least-functionality principle to limit malware attack surface.
- CP-10partialaligns with — Business continuity planning and data backup/recovery measures for malware incidents align with system recovery and reconstitution requirements.
- SC-7partialaligns with — Placement of malware detection at network gateways and boundary points implements boundary protection to prevent malware ingress.
- SI-2partialaligns with — The ISO control reduces exploitable vulnerabilities through technical vulnerability management, which directly supports the NIST flaw remediation objective.
- CM-7covers — A.8.7's malware-specific protections (e.g. detection, prevention, updates) address only the malware-related slice of CM-7's broader least-functionality and prohibited-software requirements; the bulk of CM-7 (non-malware ports, protocols, services, and general configuration) sits outside A.8.7
- CP-10covers — 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.
- SI-2covers — Assessed as NOT holding by the authoring instrument at v1.22-2026-08-29. This row records a tested non-relation; it is not a graded claim and carries no rationale, because the instrument produced none when the verb did not hold.
Aligned NIST CSF 2.0 outcomes (18)
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).
Why these map — AI rationale (under review)
- PR.PS-05fullcovers — The ISO control's emphasis on application allowlisting, blocklisting, and preventing unauthorized software execution directly fulfills the CSF outcome of stopping installation and execution of unauthorized software.
- DE.CM-09mostlyaligns with — Continuous scanning of systems, email, web traffic, and storage media for malware implements the CSF outcome of monitoring computing hardware, software, and data to detect potentially adverse events.
- PR.AT-01mostlyaligns with — Requiring user awareness and training on recognizing and mitigating malware-infected content satisfies the CSF outcome of equipping personnel with the knowledge to perform tasks securely.
- PR.PS-01mostlyaligns with — Mandating regular updates, configuration of malware tools, and controlled exception processes for disabling protections aligns with establishing and applying configuration management practices.
- ID.RA-01partialaligns with — Reducing exploitable vulnerabilities through technical vulnerability management contributes to identifying and recording vulnerabilities in assets.
- PR.IR-01partialaligns with — Placing malware controls at network gateways and endpoints to block malicious traffic supports protecting networks and environments from unauthorized logical access.
- DE.CM-09implements — 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-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.AT-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.IR-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-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.
Related OWASP ASVS 5.0 requirements (12)
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).
Why these map — AI rationale (under review)
- V13.2.4mostlyaligns with — The ISO control's requirement to maintain allowlists and blocklists for external resources and software directly implements the ASVS mandate that applications communicate only with explicitly permitted external systems.
- V13.2.5mostlyaligns with — ISO guidance to configure servers with allowlists of permitted destinations mirrors the ASVS requirement that web or application servers only send requests or load resources from an approved list.
- V13.4.2partialaligns with — The ISO control's call to reduce exploitable vulnerabilities through technical vulnerability management aligns with the ASVS requirement to disable debug modes in production to limit attack surface.
- V15.2.3partialaligns with — ISO's requirement to isolate environments where catastrophic malware consequences could occur aligns with the ASVS rule that production environments must contain only the functionality required for operation.
- V5.2.2partialaligns with — The ISO directive to scan files and attachments for malware before use aligns with the ASVS requirement to validate file extensions and types upon upload to block malicious content.
- V5.2.3partialaligns with — ISO's emphasis on scanning compressed files and archives for malware before processing corresponds to the ASVS check that compressed uploads are inspected for size and content anomalies.
Related weaknesses / CWE (9)
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).
Why these map — AI rationale (under review)
- CWE-434mitigates — Application allow-listing and pre-use scanning of received files directly blocks the introduction of executable content that has not been vetted, eliminating the primary vector for unrestricted dangerous file uploads.
- CWE-507finds — Malware protection directly detects and blocks Trojan Horse code before execution.
- CWE-508prevents — Malware-protection controls directly block or detect non-replicating malicious code on endpoints.
- CWE-509prevents — Directly addresses protection against malware including viruses and worms.
- CWE-69finds — Malware-protection mechanisms may scan or block known ADS-based threats, yet coverage is limited to signature or behavior heuristics rather than all ADS handling flaws.
Mitigated MITRE ATT&CK techniques (1931)
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).
Why these map — AI rationale (under review)
- T1001detects — A.8.7 requires malware detection software, regular scans of traffic (including network, email, web), anomaly validation, and awareness of new malware techniques, which can surface some obfuscated C2 that uses known malware delivery or signatures, but does not broadly detect non-malware C2 obfuscation methods like steganography or protocol impersonation.
- T1001.001detects — A.8.7 requires scanning, monitoring for anomalous behaviour and awareness that can surface junk-data C2 as suspicious traffic or malware artifacts at network boundaries, email, or endpoints, but does not mandate the specific protocol-analysis depth needed to reliably catch obfuscated junked payloads.
- T1001.002detects — A.8.7 explicitly requires malware detection software, regular scans of received data/email/web content, anomaly validation of files, and awareness of new malware sources, all of which can surface steganographic C2 hiding in transferred files or messages; this is limited to a slice because the control is scoped to malware (not generic traffic analysis or protocol stego without a malicious payload) and depends on configuration/risk placement that may miss novel or encrypted stego.
- T1001.002prevents — A.8.7's malware detection, scanning of received files/email/web content, vulnerability reduction, allowlisting, and awareness directly stop many steganography delivery vectors before C2 data is extracted and acted on, but cannot block all custom or novel embedding techniques that evade signature-based detection or occur in unmonitored channels.
- T1001.003detects — A.8.7 requires scanning, monitoring for anomalous/malicious content (including at network gateways, email, web, and endpoints), regular collection of new malware intel, and awareness of evasive techniques, which can surface disguised C2 traffic that matches known malware patterns or anomalies, but does not broadly detect protocol impersonation that blends with legitimate traffic without a malware signature or observable malice.
- T1003detects — A.8.7 requires malware detection software, regular scans of files/data/emails/webpages, anomaly validation of system content, and awareness of new malware sources, which can surface known malware-based credential dumpers (e.g. Mimikatz) or their artifacts when they match signatures or trigger scans, but does not broadly detect custom/non-malware variants or memory-only dumping techniques that evade file-based detection.
- T1003.001detects — A.8.7 requires regular automated validation of system content, malware scans (including on received data, email, webpages), collection of new malware intel, and monitoring for anomalous behaviour that can surface LSASS dumping tools or activity, but this is only a slice of the technique's stealthy in-memory/registry methods with many evasion paths left unaddressed.
- T1003.001prevents — A.8.7's malware detection, vulnerability reduction, unauthorized software prevention (allowlisting), and awareness directly stop many common LSASS dumping tools and in-memory malware vectors on Windows, but leave a bounded remainder of admin-privileged memory-access techniques, SSP registry changes, and non-malware credential dumping that the clause does not address.
- T1003.001recovers — A.8.7 point j) explicitly requires business continuity plans including backups and recovery measures for recovering from malware attacks; while LSASS dumping is not itself malware, the harvested credentials are often used to deliver malware (e.g. ransomware), so the control's recovery provisions address a named slice of post-T1003.001 impact restoration.
- T1003.001responds — A.8.7 explicitly requires business continuity plans, isolating environments, procedures for recovering from malware attacks, and awareness/training on responding to malware-infected files/programs, which can contain and eradicate an in-progress LSASS credential-harvesting incident once detected as malware activity.
- T1003.002detects — A.8.7 explicitly requires regular automated validation/scans of systems (including for unapproved files/amendments), malware detection software placement based on risk, scanning of received data/email/web content, and procedures for reporting malware — all of which can surface in-memory/registry SAM extraction tools or anomalous credential-dumping behavior on Windows, but only where those behaviors or tools are recognized as malware or trigger the scans; many in-memory techniques (e.g. Mimikatz) routinely evade signature-based detection and the control does not mandate behavioral monitoring.
- T1003.002prevents — A.8.7's malware detection, vulnerability reduction, unauthorized software prevention (allowlisting), and awareness directly block many in-memory SAM extraction tools (Mimikatz, pwdumpx, gsecdump) and some registry-based methods that rely on malware delivery or unpatched exploits, but not all SYSTEM-level credential dumping techniques or non-malware vectors.
- T1003.002recovers — A.8.7 point j) explicitly requires business continuity plans that include data and software backup plus recovery measures for recovering from malware attacks; credential dumping via SAM tools is commonly delivered by malware, so the control's recovery provisions address post-event restoration of affected state (e.g. reimaging, credential rotation) for that slice of the technique's impact.
- T1003.003detects — A.8.7 requires regular automated validation of system content, malware scans (including on received data, email, webpages, and media), collection of new malware intel, and procedures for reporting malware incidents, which can surface the anomalous file access/copy tools and techniques listed for T1003.003 (e.g. ntdsutil.exe, Invoke-NinjaCopy, or VSS usage) when they match known malware patterns or trigger integrity anomalies; this is only a slice because the technique is not inherently malware and many stealthy or custom executions evade signature-based detection.
- T1003.003prevents — A.8.7's malware detection, vulnerability reduction, unauthorized software prevention (allowlisting), website blocklisting, and scanning directly stop several listed techniques (Volume Shadow Copy via VSS malware vectors, ntdsutil.exe/Invoke-NinjaCopy as unauthorized tools, secretsdump.py from malicious sites), but not all NTDS access paths (e.g., legitimate admin tools or direct file reads without malware).
- T1003.003recovers — A.8.7 explicitly requires business continuity plans including backups and recovery measures for malware attacks (j), which can restore state after an NTDS theft realised via malware-delivered tools like Volume Shadow Copy or Invoke-NinjaCopy.
- T1003.004detects — A.8.7 requires regular automated validation of system content, malware scanning of files/downloads/webpages, collection of new malware intel, and procedures to detect/report malware attacks, which can surface known malware tools (e.g. Mimikatz) or anomalous registry/memory access patterns used in the technique, but does not broadly detect the credential-dumping behavior itself or unknown variants.
- T1003.004prevents — A.8.7's malware detection, vulnerability reduction, unauthorized software prevention (allowlisting), and awareness directly block common vectors like Mimikatz (a malware tool) from being introduced or executed to dump LSA secrets, but do not stop all SYSTEM-level registry/memory access methods once an adversary is present.
- T1003.004recovers — A.8.7 point j) explicitly requires business continuity plans that include data/software backup and recovery measures for recovering from malware attacks; T1003.004 is commonly performed by malware (e.g. Mimikatz droppers) so post-attack credential restoration via those backups qualifies as recovers, with the named remainder being non-malware uses of the same technique.
- T1003.005detects — A.8.7 requires regular automated validation/scans of systems (d,f), malware detection software placement based on risk (g), procedures to collect/verify new malware info (n,o), and awareness/reporting (l,m) that can surface anomalous access to credential caches or related malware, but this is scoped to malware-focused mechanisms and does not broadly instrument credential extraction or file access across all T1003.005 vectors.
- T1003.005prevents — A.8.7's malware detection, vulnerability reduction, unauthorized software prevention (allowlisting), and awareness/training directly stop many malware vectors (e.g. Mimikatz, Linikatz) that extract cached credentials, but do not address legitimate admin access, non-malware extraction methods, or all credential-caching mechanisms.
- T1003.005recovers — A.8.7 explicitly requires preparing business continuity plans that include data/software backup and recovery measures for recovering from malware attacks, and cached credential extraction is a post-compromise action that can be part of malware-enabled credential access, so recovery plans address restoring the affected state afterward.
- T1003.006detects — A.8.7 requires regular automated validation of system software/data content, scanning of received data/email/webpages, collection of new malware intel, and monitoring for anomalous behaviour that can surface DCSync-like replication abuse when it matches known malware patterns or triggers scans, but this is only a slice since the technique is a living-off-the-land privileged API call rather than delivered malware.
- T1003.006recovers — A.8.7 explicitly requires business continuity plans including backups and recovery measures (item j) to recover from malware attacks; DCSync is a credential-access technique commonly delivered by malware (e.g. Mimikatz), so the control's recovery provisions address post-event restoration after such an attack, but only for the malware-delivery slice rather than all DCSync vectors.
- T1003.006responds — A.8.7(j) and (l) explicitly require business continuity plans and defined procedures for recovering from malware attacks (including backups and training), which bounds impact once a DCSync-based credential theft (often delivered via malware like Mimikatz) is underway, but this is only a slice of the technique's execution and does not address containment or eradication.
- T1003.007detects — A.8.7 requires regular automated validation of system content, malware scans (including on received data, email, webpages), collection of new malware intel, and procedures to detect/report malware events; these can surface proc-fs credential scraping when it involves known malware patterns or anomalous file reads, but miss the dominant technique of direct, non-malware memory-pattern searches by legitimate tools or custom scripts.
- T1003.008detects — A.8.7 requires regular automated validation of system content, malware scans at multiple layers (including on received data, email, webpages, and endpoints), anomaly investigation, and awareness-driven reporting of suspicious activity, which can surface malware-driven dumping of /etc/passwd and /etc/shadow but only where the technique involves or resembles known malware delivery or execution patterns, leaving most direct credential-dumping via legitimate tools or root-level reads undetected.
- T1003.008recovers — A.8.7 explicitly requires business continuity plans including backups and recovery measures (item j) for recovering from malware attacks; while T1003.008 is credential access rather than malware, the control's recovery provisions can restore system state (and thus any exfiltrated credential material's impact) after a realized attack that used malware delivery or persistence.
- T1005detects — A.8.7 requires malware detection software, regular automated system validation for unapproved files/amendments, scanning of received data/email/webpages, and awareness of malware indicators, which can surface anomalous collection activity if it involves malware or unauthorized changes, but does not broadly detect non-malware T1005 file searches.
- T1005recovers — A.8.7 point j) explicitly requires business continuity plans including backups and recovery measures for recovering from malware attacks, which directly restores state after a realized T1005 collection (e.g., if malware-enabled) per the event-lane recovers definition.
- T1006detects — A.8.7 requires regular automated validation of system software/data content, scanning of received files/media/email/webpages, collection of new malware intel, and monitoring for unauthorized changes or malware indicators, which can surface some T1006 artifacts (e.g. unexpected shadow copies via vssadmin/esentutl or anomalous volume-access utilities) but does not broadly instrument or detect direct volume I/O, file-system-bypass reads, or the core technique itself.
- T1006recovers — A.8.7 clause j) explicitly requires business continuity plans including backups and recovery measures for malware attacks, which can restore state after a T1006-based exfiltration or ransomware impact (paralleling the cp-9 and A.8.13 anchors for T1486)
- T1007detects — A.8.7 requires malware detection software, regular scans of systems/data/email/web content, anomaly validation for unapproved files/amendments, and awareness of new malware, which can surface T1007 when performed by malware but does not broadly instrument command-line discovery behaviors like sc query or schtasks outside a malware context
- T1008detects — A.8.7 requires malware detection software, regular scans of networks/email/web/downloads/media, anomaly validation of system content, and awareness of new malware sources, which can surface fallback channel activity when it delivers or exhibits malware-like behavior, but this is only a slice since the technique itself is not inherently malware and many non-malware fallback channels (e.g. encrypted C2) fall outside its scope.
- T1011detects — A.8.7 requires malware detection software, regular scans of data received over networks or media, email/IM attachments, webpages, and anomaly detection for unapproved files/amendments, which can surface exfiltration activity when it uses removable media, Bluetooth, or other channels as a malware vector or carrier, but does not broadly instrument or detect the exfiltration technique itself across all alternative media (e.g. WiFi/cellular outbound without malware involvement).
- T1011.001detects — A.8.7 requires malware detection software, regular scans, awareness, and monitoring for anomalous file/software changes that can surface Bluetooth-based exfiltration if it involves malware delivery or unauthorized transfers, but the control is scoped to malware and does not broadly detect non-malware Bluetooth exfiltration over proximity channels.
- T1014detects — A.8.7 explicitly requires malware detection/repair software, regular automated validation/scans of systems/data (including for unapproved files/amendments), awareness of new malware, and risk-based placement of detection tools, all of which surface rootkits (a form of malware) in many but not all cases (e.g., kernel/bootkit evasion, firmware, or disabled measures remain outside guaranteed detection).
- T1014prevents — A.8.7's malware detection, vulnerability reduction, allowlisting, website blocklisting, scanning, and awareness directly stop many rootkit installation vectors and lower the chance the hiding technique can be introduced, but kernel/boot/firmware rootkits and post-install evasion (e.g. API hooking) remain outside its reach.
- T1014recovers — A.8.7 explicitly requires business continuity plans including data/software backup and recovery measures (point j) to recover from malware attacks, and rootkits are a form of malware whose effects (hidden components) can be addressed by restoring clean system state from backup.
- T1016detects — A.8.7 requires regular automated validation of system software/content, scanning of received data/email/webpages, collection of new malware intel, and monitoring for anomalous behaviour that can surface reconnaissance commands (e.g. ipconfig, esxcli, route) when they match known malicious patterns or deviate from baselines, but this is scoped only to malware vectors and does not broadly instrument all discovery utilities or post-compromise CLI use.
- T1016.001detects — A.8.7 requires scanning, monitoring for anomalous behaviour (via awareness, validation, and detection tools) and collecting malware intelligence that can surface Internet-connection checks performed by known malware during discovery, but this is scoped to malware-specific observables rather than all discovery techniques and leaves many non-malware or evasive cases undetected.
- T1020detects — A.8.7 requires malware detection software, regular scans of data/email/web content, anomaly validation of files, and awareness of malware indicators; these can surface automated exfiltration when it uses malware delivery or known malicious channels, but the technique itself is not inherently malware and can use legitimate/encrypted C2 channels outside the malware-focused scope.
- T1020.001detects — A.8.7 requires regular automated validation of system content, scanning of received data/email/webpages, collection of new malware info, and monitoring placement based on risk, which can surface anomalous traffic mirroring or related malware artifacts on scanned systems and networks, but does not broadly detect the configuration abuse or exfiltration technique itself across all platforms.
- T1021detects — A.8.7 requires regular automated validation of system content, malware scans (including on received data, email, webpages), collection of new malware intel, and awareness training that surfaces anomalous/malicious activity, which can detect some T1021 abuse vectors (e.g. malware-delivered remote tools or anomalous remote sessions) but leaves the bulk of credentialed remote service logins (especially legitimate-account RDP/SSH without malware) undetected.
- T1021.001detects — A.8.7 requires regular scans, monitoring for malware (including on networks, email, web access, and endpoints), anomaly detection via validation of software/data, and awareness of new threats, which can surface RDP-based malware delivery or post-access activity in some configurations but does not broadly instrument or guarantee detection of credentialed RDP logins or the technique itself.
- T1021.002detects — A.8.7 requires regular automated validation of system content, scanning of received data/email/webpages, collection of new malware intel, and monitoring placement based on risk, which can surface anomalous SMB share access or transferred malware binaries post-facto but does not broadly instrument for the lateral movement technique itself.
- T1021.003detects — A.8.7 requires regular automated validation of system content, malware scanning of received data/email/webpages, collection of new malware intel, and monitoring for anomalous behaviour that can surface DCOM-based lateral movement when it matches known malware patterns or indicators, but this is only a slice of possible DCOM abuse vectors (many rely on valid accounts and legitimate COM/RPC calls without deliverable malware).
- T1021.004detects — A.8.7 requires regular automated validation/scans of systems (d,f), malware detection software placement based on risk (g), procedures for reporting malware (l), and collection of new malware info (n-o), which can surface SSH-based malware delivery or post-login anomalies on scanned Linux/macOS/ESXi systems, but this is limited to malware-specific indicators rather than the SSH login technique itself.
- T1021.005detects — A.8.7 requires regular scans, monitoring for malware indicators, awareness of anomalous behavior from malware, and collection of new malware intelligence, which can surface VNC-based malware or post-compromise activity on Linux/Windows/macOS but does not broadly instrument for legitimate VNC abuse by valid accounts.
- T1021.006detects — A.8.7 requires malware detection software, regular scans, anomaly validation, awareness of malware delivery, and monitoring for new threats, which can surface WinRM-based malware execution or lateral movement artifacts (e.g. via scans of received data, email, or endpoints) but does not broadly detect credentialed WinRM abuse itself.
- T1021.007detects — A.8.7 requires regular scans, anomaly detection via validation of systems/data, awareness of malware indicators, and collection of new malware intel, which can surface some cloud-service logins that carry or exhibit malware artifacts (e.g. malicious CLI tools, infected clients, or anomalous file changes), but the core technique is credentialed access via valid accounts and does not require malware delivery or execution.
- T1021.008detects — A.8.7 requires regular automated validation of system content, malware scanning of received data/email/webpages, collection of new malware intel, and monitoring for anomalous activity that can surface indicators of malware delivered or executed via cloud VM console access, but does not broadly detect the technique of obtaining direct console access itself.
- T1025detects — A.8.7 requires regular automated validation of system content (d), scanning of removable media before use (f.1), and malware-detection placement based on risk (g) that can surface anomalous files or activity on connected removable media, but this is scoped only to malware indicators rather than general sensitive-data collection and leaves many non-malware T1025 executions (e.g. simple file enumeration via cmd) undetected.
- T1025recovers — A.8.7 point j) explicitly requires business continuity plans that include data backup and recovery measures for recovering from malware attacks, which directly restores state after the technique has run and data has been collected from removable media.
- T1027detects — Regular automated validation of system files and data content helps surface obfuscated or packed malware that would otherwise remain hidden on disk.
- T1027prevents — A.8.7 explicitly requires reducing exploitable vulnerabilities, application allowlisting, blocking malicious sites, scanning for malware (including encrypted/obfuscated payloads where detectable), awareness training, and configuration based on risk to stop malware delivery and execution; this stops many T1027 instances that rely on evasion of signature-based or basic controls, but leaves a genuine remainder for advanced evasion (e.g. custom encoding, command obfuscation, or non-malware uses) that the clause does not address.
- T1027recovers — A.8.7 point j) explicitly requires business continuity plans including backups and recovery measures for recovering from malware attacks, which can restore state after an obfuscated payload has executed (e.g. via T1204) and caused impact.
- T1027.001detects — A.8.7 explicitly requires regular automated validation/scans of software content plus malware detection software that can surface anomalies (including unapproved files/amendments), which can discover padded binaries that evade static signatures or size-limited scanners, but this is only a slice because the control's own text acknowledges that detection/repair software alone is usually inadequate and many padding variants (e.g. encrypted, non-signature-matching) remain undetected.
- T1027.001prevents — A.8.7 explicitly requires reducing exploitable vulnerabilities, scanning all received data/media before use, updating detection tools, and using allowlisting/blocklisting that can stop padded binaries from executing or being introduced, but these do not stop an adversary from generating or using a padded binary in the first place.
- T1027.002detects — A.8.7 explicitly requires regular automated validation/scans of software content (including for unapproved files/amendments), malware detection software with risk-based placement and configuration, and awareness of new/evasive techniques such as encrypted files, which surfaces many (but not all) packed binaries depending on the packer, scan depth, and custom evasion.
- T1027.002prevents — A.8.7 explicitly requires reducing exploitable vulnerabilities (c), application allowlisting (a), scanning for malware before use (f), and awareness/training (m) that together stop many (but not all) packing techniques from successfully concealing and executing adversary code.
- T1027.003detects — A.8.7 explicitly requires scanning data received over networks, email/IM attachments, downloads, webpages, and storage media for malware before use, plus regular automated validation of system content for unapproved files/amendments, which surfaces steganography-hidden payloads in those vectors (as in the Duqu and Invoke-PSImage examples) but does not address all possible hiding locations or non-malware uses of steganography.
- T1027.003prevents — A.8.7 explicitly requires reducing exploitable vulnerabilities (c), scanning data/files received over networks or on media before use (f.1, f.2), scanning webpages (f.3), blocking known/suspected malicious sites (b), and awareness/training on identifying malware-infected files (m), all of which stop many (but not all) steganography delivery vectors before the hidden payload can be used.
- T1027.003recovers — A.8.7 point j explicitly requires business continuity plans that include data/software backup and recovery measures for recovering from malware attacks, which directly restores state after a realized steganography-based malware event (as in the Duqu/Invoke-PSImage examples)
- T1027.003responds — A.8.7 explicitly requires business continuity plans, isolating high-risk environments, procedures for reporting/recovering from malware attacks, and awareness/training on mitigating malware-infected files, which directly addresses containment/eradication once steganography-based malware (e.g. Duqu, Invoke-PSImage) is underway.
- T1027.004detects — A.8.7 requires scanning for malware (including on received files, email attachments, downloads, and webpages) plus awareness and vulnerability management that can surface some compiled-after-delivery artifacts, but source code, encrypted/embedded payloads, and post-delivery compilation via native tools largely evade signature-based detection focused on known malware binaries.
- T1027.004prevents — A.8.7's rules to prevent unauthorized software (allowlisting), reduce exploitable vulnerabilities, scan for malware before use, and block malicious sites constrain delivery/execution paths for many compiled-after-delivery payloads, but source code, benign-format, or encrypted variants often bypass these when they do not match known malware signatures or prohibited patterns.
- T1027.004recovers — A.8.7 point j) explicitly requires business continuity plans that include data/software backup and recovery measures for recovering from malware attacks, and the technique's compiled payload is malware that can be removed and restored from clean backups after execution.
- T1027.005detects — A.8.7 explicitly requires malware detection/repair software, regular automated scans of files/emails/webpages/media, collection of new malware intel, and validation of system content to surface unapproved changes or malware indicators before or upon use.
- T1027.005prevents — A.8.7's malware detection/repair, signature scanning, vulnerability reduction, allowlisting, and awareness directly block many indicator-based detections that would otherwise trigger quarantine, forcing the adversary to remove or alter indicators to succeed, but this is only a slice because the technique can still succeed via non-signature indicators, encrypted/obfuscated payloads, or when detection is evaded before scanning occurs.
- T1027.005recovers — A.8.7 explicitly requires business continuity plans including backups and recovery measures (j) to recover from malware attacks, which directly restores state after an adversary re-uses a modified tool that evaded detection/quarantine.
- T1027.005responds — A.8.7 explicitly requires procedures, responsibilities, awareness/training, and business continuity plans (including backups/recovery) to deal with and recover from malware attacks once detected, which directly matches the technique's core scenario of a tool being quarantined by AV and then modified to evade further detection.
- T1027.006detects — A.8.7 explicitly requires scanning of webpages when accessed, email/IM attachments/downloads, data received over networks, and regular automated validation of system content (with investigation of unapproved files), which surfaces HTML smuggling artifacts or the resulting dropped/obfuscated payloads in multiple places; this is a genuine but minority slice because the technique's core evasion (benign MIME in HTML/JS before deobfuscation) is designed to bypass exactly those content filters and scanners, with the bulk of the technique (pre-delivery hiding and client-side generation) outside the control's malware-focused detection mechanisms.
- T1027.006prevents — A.8.7 explicitly requires controls that prevent or detect use of known/suspected malicious websites (blocklisting), reduce exploitable vulnerabilities, scan data received over networks and email/web downloads before use, and place malware detection at network gateways and endpoints per risk assessment; these directly stop many HTML smuggling delivery vectors that rely on web-sourced or email-delivered obfuscated payloads, but leave open vectors such as local generation, encrypted evasion, or non-web delivery that the clause does not universally close.
- T1027.006recovers — A.8.7 point j) explicitly requires business continuity plans that include data/software backup and recovery measures for recovering from malware attacks, which directly restores state after HTML smuggling delivers a malicious payload (T1027.006)
- T1027.006responds — A.8.7 explicitly requires business continuity plans, isolating high-risk environments, procedures for recovering from malware attacks, and awareness/training on mitigating receipt/installation of malware-infected files, which directly addresses containment/eradication once an HTML-smuggled payload has executed as malware.
- T1027.007detects — A.8.7 requires regular automated validation of software/content, malware detection software with scans (including of received data, email, webpages), collection of new malware intel, and awareness to identify suspicious files/behavior; this surfaces some dynamic API resolution artifacts (e.g. via runtime scanning, anomaly detection or updated signatures) but leaves the bulk of the technique's static-obfuscation and in-memory resolution methods outside its defined mechanisms.
- T1027.007prevents — A.8.7's malware detection/repair software, vulnerability reduction (8.8), unauthorized software rules (8.19), and awareness/training can block some delivery vectors or execution of malware relying on dynamic API resolution, but the technique is an obfuscation method that can still succeed against detection and does not map to a bounded remainder of the class.
- T1027.008detects — A.8.7 requires regular automated validation of system software/data content, scanning of received files/emails/webpages, collection of new malware intel from reputable sources, and risk-based placement of detection tools, which can surface stripped payloads when they match known malware signatures or exhibit anomalous file characteristics, but does not guarantee detection of novel or evasive stripped payloads that avoid signatures and behavioral triggers.
- T1027.009detects — A.8.7 explicitly requires regular automated validation of software/data content, scanning of received files/email/webpages/media, collection of new malware intel from reputable sources, and placement of detection tools based on risk (including at gateways/endpoints/servers), which surfaces many embedded-payload cases; it stops short of universal coverage because scanning is limited to known signatures/behaviors, evasive/encrypted embeddings are called out as a challenge, and detection ultimately depends on the specific tools configured.
- T1027.009prevents — A.8.7 explicitly requires rules/controls to prevent unauthorized software (e.g. application allowlisting), reducing exploitable vulnerabilities, scanning for malware before use, and protective measures against obtaining files from external sources, all of which stop many (but not all) embedding and concealment methods before the payload can be delivered or executed.
- T1027.009recovers — A.8.7 point j) explicitly requires business continuity plans including backups and recovery measures for recovering from malware attacks, which directly restores state after the embedded-payload technique has realised its impact.
- T1027.009responds — A.8.7 explicitly requires procedures to deal with malware attacks including reporting and recovering, plus business continuity plans for recovering from malware attacks (j, l); this matches the `responds` verb once the embedded-payload malware is underway, but only partially because the clause is scoped to malware generally rather than the specific embedding/obfuscation technique and many of its controls (scanning, awareness, vulnerability reduction) act earlier in the event chain.
- T1027.010detects — A.8.7 explicitly requires regular automated validation of software/content, scanning of received data/email/webpages for malware before use, collection of new malware intel, and placement of detection tools based on risk (including at gateways/endpoints), which surfaces many obfuscated commands delivered via payloads or executed by malware; partial because it is scoped to malware artifacts rather than all command-line obfuscation (e.g. interactive interpreter use or non-malware scripts).
- T1027.010prevents — A.8.7's rules to prevent unauthorized software (allowlisting), reduce exploitable vulnerabilities, block malicious sites, scan for malware before execution, and use defense-in-depth placement stop many obfuscated commands from running or succeeding, but do not block all forms of command obfuscation (especially interactive or in permitted interpreters).
- T1027.011detects — A.8.7 explicitly requires malware detection/repair software, regular automated validation/scans of systems (including for unapproved files/amendments), scanning of received data/email/webpages, collection of new malware intel, and risk-based placement of tools; these surface many fileless storage artifacts (esp. in Registry/WMI/event logs) but leave real gaps for in-RAM-only cases, heavily obfuscated payloads, and non-malware uses such as data staging.
- T1027.011prevents — A.8.7's malware detection/repair, vulnerability reduction, unauthorized-software rules, awareness, and scanning requirements (including of non-file locations where possible) stop some fileless storage of malicious payloads but leave large residual coverage gaps for in-memory/shared-memory evasion, encrypted/obfuscated data, and non-malware uses such as data staging.
- T1027.011recovers — A.8.7 point j) explicitly requires business continuity plans that include data and software backup plus recovery measures for malware attacks; fileless storage of payloads or collected data is an artifact of such an attack whose state can be restored from backup, but this is bounded by the fact that many fileless locations (registry, WMI, shared memory) are not ordinary files and the control's malware-specific recovery does not guarantee restoration of every possible non-file artifact.
- T1027.012detects — A.8.7 explicitly requires regular automated validation/scans of systems and data (including email/IM attachments, downloads, webpages, and external files) plus malware detection software placement based on risk, which surfaces LNK-based smuggling when the referenced payload or LNK itself is scanned as malicious; this is limited to a slice because the technique can be used post-compromise via local scripts without triggering network/file-receipt scans, and evasive LNK metadata may bypass signature-based detection until updated intel (n/o) is applied.
- T1027.012prevents — A.8.7 explicitly requires malware detection/repair software, scanning of received files/email/web content, rules preventing unauthorized software (e.g. allowlisting), vulnerability reduction, and awareness training, all of which can stop LNK Icon Smuggling payloads from executing or downloading on Windows; it is only a slice because the technique can still succeed via novel/undetected variants, evasive encryption (explicitly called out in the control), or pre-installed LNKs that bypass initial scans.
- T1027.012recovers — A.8.7 explicitly requires business continuity plans including data/software backup and recovery measures for recovering from malware attacks, which directly restores state after the LNK-smuggled payload executes and delivers malware.
- T1027.012responds — A.8.7 explicitly requires procedures, training, awareness, scanning, and business continuity plans to respond to and recover from malware attacks once underway, which directly addresses the malware delivery realized by T1027.012; partial because the control is scoped to malware consequences rather than every smuggling vector or post-compromise script execution.
- T1027.013detects — A.8.7 explicitly requires malware detection software to scan data, email attachments, downloads, and webpages (including for evasive/encrypted techniques per g.2), which surfaces many encoded/encrypted malicious files before use, but this is only a slice: it depends on up-to-date signatures, does not address custom/non-malware encodings, BOM abuse, or files already resident without being scanned.
- T1027.013prevents — A.8.7 explicitly requires reducing exploitable vulnerabilities (c), blocking known/suspected malicious sites (b), scanning for malware before use including on received files/webpages (f), and configuring detection tools against evasive techniques such as encrypted files (g.2), all of which stop many (but not all) instances of this obfuscation technique from succeeding in delivery or static evasion.
- T1027.013recovers — A.8.7 point j) explicitly requires business continuity plans that include data/software backup and recovery measures for recovering from malware attacks, which restores state after the technique has been used to deliver/execute malware.
- T1027.013responds — A.8.7 explicitly requires preparing business continuity plans, isolating environments, defining procedures for recovering from malware attacks, and handling protection bypass during maintenance/emergency procedures, which directly addresses containment/eradication once an encrypted/obfuscated malware file has executed or evaded initial detection.
- T1027.014detects — A.8.7 explicitly requires malware detection software, regular scans of files/emails/webpages, automated validation for unapproved changes, awareness of new malware from reputable sources, and risk-based placement (including against evasive techniques), which surfaces polymorphic variants that change footprint; however this is only a slice because traditional signature-based detection (explicitly called out in the T1027.014 description) is known to fail against mutation, with the clause relying on complementary non-signature methods whose coverage is not mandated.
- T1027.014prevents — A.8.7 explicitly requires reducing exploitable vulnerabilities (c), application allowlisting (a), scanning at multiple layers (f/g), awareness/training (m), and defence-in-depth placement that can catch polymorphic variants before execution, which stops many instances of the technique from succeeding even though it cannot stop every mutation engine or combined obfuscation.
- T1027.014recovers — A.8.7 explicitly requires business continuity plans including backups and recovery measures (item j) to recover from malware attacks, which directly addresses restoring state after polymorphic malware (a form of malware) has executed and impacted systems.
- T1027.014responds — A.8.7 explicitly requires incident-response procedures, training, reporting and business-continuity/recovery measures once a malware attack (including polymorphic variants that have evaded detection) is underway; this matches the `responds` verb, but only a minority slice of the full technique because the clause's dominant focus is on prevention/detection and the response language is high-level without specific containment steps for in-memory mutation.
- T1027.015detects — A.8.7 explicitly requires malware detection software to scan data received over networks, email/IM attachments, downloads, and webpages before use, which surfaces many compressed malicious payloads delivered via those vectors; it does not address compressed shellcode in registry keys, concatenated archives that evade readers, or self-extracting archives that launch without user extraction.
- T1027.015prevents — A.8.7 explicitly requires rules/controls that prevent or detect unauthorized software (e.g. application allowlisting), reducing exploitable vulnerabilities, scanning data received over networks/email/attachments/webpages before use, and protective measures for files from external networks, all of which stop many (but not all) uses of compression to deliver or obfuscate malware payloads.
- T1027.015recovers — A.8.7 explicitly requires business continuity plans including backups and recovery measures for malware attacks (j), which can restore state after a compressed/obfuscated payload has executed as malware; this is a minority slice of the technique because most of T1027.015 is about pre-execution obfuscation and delivery rather than post-execution impact that recovery undoes.
- T1027.015responds — A.8.7 explicitly requires business continuity plans, isolating high-risk environments, defined procedures for reporting/recovering from malware attacks, and awareness/training on mitigating malware-infected files (including those delivered via email/archives), which responds to and contains/eradicates a realized T1027.015 compression-based delivery once underway; partial because it does not address non-malware uses (e.g., pure shellcode compression for registry storage) or all concatenated/self-extracting variants that evade detection tools.
- T1027.016detects — A.8.7 requires regular automated validation of software content, malware detection software with scanning (including of received files, email, webpages), collection of new malware intel, and awareness of evasion techniques; this surfaces some junk-code-obfuscated malware post-insertion via behavioral or signature-based detection but leaves a large remainder (static-analysis evasion, novel junk patterns, encrypted delivery, or non-malware uses of the technique) undetected by design.
- T1027.017detects — A.8.7 explicitly requires scanning of email/IM attachments, downloads, received data, webpages, and regular automated validation of software/content to detect malware or unauthorized changes; SVG smuggling (malicious JS inside image-like XML) can be surfaced by those scans when the SVG is delivered via covered vectors, but the clause does not mandate parsing/inspection of embedded scripts inside legitimate SVG structures nor cover all delivery forms (e.g. inside PDFs or non-scanned local files), leaving an open remainder.
- T1027.017prevents — A.8.7 explicitly requires malware detection/repair software, scanning of received files/email/web content, blocklisting of malicious sites, vulnerability reduction, and awareness training — all of which catch or stop many SVG-smuggling vectors before execution; the named remainder is that SVG files are often treated as legitimate images, evading signature-based scanners and allow-lists that do not deeply inspect XML/script inside image formats.
- T1027.017recovers — A.8.7 explicitly requires business continuity plans including backups and recovery measures (item j) to recover from malware attacks, which directly applies to restoring state after SVG-smuggled payloads execute as malware.
- T1027.017responds — A.8.7 explicitly requires malware detection/repair software, regular scans of received files/email/web content, awareness training on identifying malware-infected files, incident response procedures for recovering from malware attacks, and business continuity plans — all of which activate once an SVG-smuggled payload has been delivered and is executing or being processed.
- T1027.018detects — A.8.7 explicitly requires regular automated validation of software/data content, scanning of received files/emails/webpages/attachments, and collection of new malware information from reputable sources, which can surface invisible Unicode hiding payloads in scanned content; however, it is scoped to malware signatures and known patterns rather than general evasion of static analysis via invisible characters, leaving most realizations undetected.
- T1027.018prevents — A.8.7 explicitly requires reducing exploitable vulnerabilities (c), preventing/detecting unauthorized software via allowlisting (a), scanning received data/email/web content before use (f), and awareness training on identifying malicious files (m), all of which stop many Unicode-obfuscated payloads from executing; it does not address custom encoding reconstruction at runtime or all evasion vectors such as PUA in non-scanned contexts.
- T1027.018recovers — A.8.7 point j) explicitly requires business continuity plans that include backup and recovery measures for recovering from malware attacks, which restores state after a realised T1027.018-based malware event; partial because the control is scoped to malware recovery and does not address non-malware uses of the technique (e.g. phishing, prompt injection).
- T1036detects — A.8.7 explicitly requires regular automated validation/scans of software and data content (including for unapproved files/amendments), malware detection software placement based on risk, and awareness of new malware indicators, which can surface masquerading artifacts when they deviate from expected legitimate patterns or appear in scans; this is a genuine but minority slice because the control's dominant focus is on preventing/detecting installation and execution of actual malware rather than post-compromise naming tricks that evade tools.
- T1036prevents — A.8.7's rules to prevent unauthorized software (allowlisting), reduce exploitable vulnerabilities, scan for malware before use, and defend in depth against evasive delivery directly stop many masquerading artifacts from executing or being treated as benign, but do not address all forms such as metadata manipulation, renamed legitimate utilities, or non-malware masquerading that evades detection entirely.
- T1036.001detects — A.8.7 requires regular automated validation of software/content, scanning of received files/downloads/webpages, collection of new malware intel, and risk-based placement of detection tools, which can surface invalid-signature binaries that deviate from known-good patterns or appear in scans, but this is not the clause's primary malware-signature focus and leaves many mimicry cases (especially non-executable or post-scan) undetected.
- T1036.001prevents — A.8.7's malware detection, allowlisting, vulnerability reduction, scanning of received files/software, and awareness directly stop many invalid-signature binaries from executing or being trusted as legitimate malware vectors, but do not address all mimicry vectors (e.g., non-malware delivery, evasive encryption, or post-scan execution).
- T1036.002detects — A.8.7 explicitly requires regular automated validation of software/content (d), scanning of received files/email/webpages (f), awareness training on identifying malware-infected files (m), and collection of new malware information (n-o); these surface RTLO-disguised malicious files when they reach the organization, but only where scanning/awareness tools are RTLO-aware and the file is not introduced via bypassed paths (h) or in non-scanned locations.
- T1036.002prevents — A.8.7's malware detection/repair, awareness training, unauthorized-software rules (allowlisting), vulnerability reduction, scanning of received files/emails/webpages, and protective measures against external files directly stop many RTLO-based malicious-file tricks before execution, but the Unicode spoof itself is not a malware binary and can still reach users via non-scanned vectors or social engineering.
- T1036.002recovers — A.8.7 point j) explicitly requires business continuity plans including backups and recovery measures for malware attacks, which recovers from the realized impact of an executed disguised malicious file (the technique's end state).
- T1036.003detects — A.8.7 requires regular automated validation of software/content (d), scanning of received data/email/webpages (f), collection of new malware intel (n-o), and risk-based placement of detection tools that can surface renamed/masqueraded utilities when they match known patterns, signatures, or anomalous behavior, but this is only a slice because the technique is fundamentally about evading name/path-based controls and many renamed utilities trigger no malware signature.
- T1036.003prevents — A.8.7's allowlisting (a), vulnerability reduction (c), scanning/validation (d/f), and awareness (m) can stop many renamed-utility executions before they run, but the technique's core (masquerading a legitimate binary) evades name/path-based detection and is not blocked by malware-specific tools or rules.
- T1036.004detects — A.8.7 requires regular automated validation of system software/content (d), scans of received data/email/webpages (f), collection of new malware info (n), and awareness of indicators (m), which can surface masquerading tasks/services when they match known malicious patterns or produce anomalous files/behavior; this is limited to a slice because the technique is a naming deception that often evades signature-based detection without additional behavioral or integrity checks.
- T1036.004recovers — A.8.7 point j) explicitly requires business continuity plans that include backup and recovery measures for recovering from malware attacks, which restores state after a masquerading service/task (a common malware delivery/persistence vector) has already run and caused impact.
- T1036.005detects — A.8.7 requires regular automated validation of system content, scanning for unapproved files/amendments, malware detection software with risk-based placement (including endpoints/servers/gateways), and awareness of new malware — all of which can surface masquerading resources when they trigger scans, validation or anomaly checks, but leaves large gaps (e.g. non-executable resources, Registry keys, containers, or placements that evade signature/behavior rules).
- T1036.005prevents — A.8.7 guidance (a,c,f,g,h) explicitly calls for application allowlisting, vulnerability reduction, scanning before use, defence-in-depth placement, and protecting maintenance paths — all of which stop many (but not all) masquerading placements from executing or being introduced
- T1036.006detects — A.8.7 requires regular automated validation of system content, scanning of received files/media/email/webpages for malware before use, and awareness training on identifying suspicious files; these surface the disguised executable (via content-based detection or user reporting) in some but not all delivery paths, leaving a large remainder for un-scanned local files or evasive variants.
- T1036.006prevents — A.8.7 guidance on malware detection/repair software, reducing exploitable vulnerabilities, preventing unauthorized software via allowlisting, scanning received files before use, awareness training, and isolating risky environments directly stops many delivery vectors for disguised malicious binaries (including space-after-filename tricks that rely on user double-click or un-scanned execution), but leaves open slices such as zero-day variants, insider-introduced files during maintenance bypasses, or files already resident before controls activate.
- T1036.007detects — A.8.7 explicitly requires scanning of email attachments, downloads, received data, and webpages for malware before use (including at multiple points such as servers and endpoints), which surfaces double-extension masquerading when the true executable payload is recognized as malware; this is limited to partial because detection depends on the malware signature/behavior being known and on user awareness/training rather than reliably catching the filename trick itself in all cases.
- T1036.007prevents — A.8.7 explicitly requires rules/controls that prevent or detect unauthorized software (incl. application allowlisting), scanning of email/attachments/downloads before use, protective measures on files from external networks, and awareness training — all of which stop the double-extension masquerading file from being delivered, opened, or executed on Windows; this is a genuine but minority slice of the control's malware-protection scope rather than the bulk with a bounded remainder.
- T1036.007recovers — A.8.7 explicitly requires preparing business continuity plans including data/software backup and recovery measures specifically for recovering from malware attacks, which directly restores state after a double-extension payload has executed as malware.
- T1036.007responds — A.8.7 explicitly requires scanning email attachments and downloads for malware before use (at multiple points including servers and endpoints), investigating unapproved files, and preparing business continuity/recovery plans for malware attacks; this acts on the technique once the double-extension payload has reached the user or network as an attachment or file, containing and recovering from the realized execution rather than stopping the masquerading itself.
- T1036.008detects — A.8.7 explicitly requires malware detection/repair software, regular automated validation of system content for unapproved files/amendments, scanning of received data/email/webpages, and collection of new malware intel, all of which surface masqueraded payloads that deviate from expected signatures, extensions or content.
- T1036.008prevents — A.8.7 explicitly requires rules/controls that prevent or detect unauthorized software (incl. application allowlisting), scanning of received/transferred files before use, reducing exploitable vulnerabilities, and awareness — all of which stop many (but not all) masquerading tricks that rely on bypassing validation, benign-looking extensions, or unvetted ingress.
- T1036.008recovers — A.8.7 point j) explicitly requires business continuity plans that include data/software backup and recovery measures for recovering from malware attacks, which restores state after a masqueraded payload has executed as malware.
- T1036.009detects — A.8.7 requires malware detection software, regular scans of files/emails/webpages, anomaly validation of system content, and awareness of new malware sources, which can surface double-fork/daemonized malware post-execution on scanned Linux endpoints or gateways; this is only a slice because the technique is a PPID-evasion step that can complete before any scan runs and is not guaranteed to produce a detectable artifact the controls require checking for.
- T1036.009recovers — A.8.7 point j) explicitly requires business continuity plans including backups and recovery measures for recovering from malware attacks; while the technique is an evasion method used by malware, the control's recovery provisions address post-malware state restoration in a limited way (not all instances or platforms).
- T1036.010recovers — A.8.7 point j) explicitly requires business continuity plans including backups and recovery measures for recovering from malware attacks; while the masquerading technique itself is not malware, it is a common post-compromise persistence step in real malware/ransomware campaigns (per the cited examples), so the control's recovery planning addresses restoring from the broader incident that employed this technique.
- T1036.011detects — A.8.7 requires regular automated validation of system software/content, scanning of received data/email/webpages, collection of new malware intel, and monitoring for anomalous behaviour that can surface in-memory process spoofing when the overwritten argv produces observable discrepancies or known malicious patterns
- T1036.012detects — A.8.7 requires regular automated validation of system content, scanning of received data/webpages/emails, collection of new malware intel, and placement of detection tools based on risk (including at network gateways and endpoints), which can surface anomalous/spoofed browser fingerprints when they match known malicious patterns or deviate from baselines, but does not broadly detect all fingerprint spoofing used to blend with legitimate traffic.
- T1037detects — A.8.7 requires regular automated validation of system software/content (d), scanning of received data/email/webpages (f), collection of new malware info (n), and monitoring for anomalous behaviour via awareness and procedures (l/m), which can surface malicious boot/logon scripts or their effects post-execution on covered platforms, but this is limited to specific scan points and does not broadly instrument script execution or persistence mechanisms across all platforms/vectors.
- T1037prevents — A.8.7's rules to prevent unauthorized software (allowlisting), reduce exploitable vulnerabilities, scan for malware before use/execution, and block malicious content directly stop many T1037 script-based persistence implants at initialization time; it leaves a remainder for scripts that are authorized, signed, or use non-malware vectors such as legitimate admin tools or configuration changes.
- T1037.001detects — A.8.7 requires regular automated validation of system software/content (d), scanning of received data/email/web content (f), collection of new malware info (n), and awareness of anomalous behaviors, which can surface logon script anomalies or known malicious payloads but does not broadly instrument for the persistence technique itself.
- T1037.001prevents — A.8.7 guidance (a,c,f,h) directly prevents unauthorized logon-script insertion via allowlisting, vulnerability reduction, change controls, and maintenance protections; this stops the technique at source for many cases but leaves a remainder where admin-privileged or already-approved scripts can still be planted.
- T1037.002detects — A.8.7 requires regular automated validation of system software/content (d), scanning of received files/media/email/webpages (f), collection of new malware info (n), and awareness of indicators (m), which can surface a malicious login hook script or plist change as anomalous/malicious when it matches known patterns or triggers scans; this is limited to a slice because the technique is a configuration change (not delivered malware) on a deprecated macOS mechanism, many instances evade generic detection, and placement is risk-based rather than universal.
- T1037.002prevents — A.8.7's rules to prevent unauthorized software (allowlisting), reduce exploitable vulnerabilities, block malicious sites, scan for malware before execution, and protect against external file introduction all constrain the adversary's ability to place and execute a malicious login-hook script, but the control is silent on plist modification, admin-privileged configuration changes, and the deprecated-but-still-possible technique itself.
- T1037.003detects — A.8.7 requires regular automated validation of system software/content (d), scanning of received data/email/web content (f), collection of new malware info (n), and monitoring placement based on risk (g), which can surface anomalous logon-script changes or known malicious payloads but does not broadly instrument or guarantee detection of the persistence mechanism itself.
- T1037.003prevents — A.8.7's rules to prevent unauthorized software (via allowlisting), reduce exploitable vulnerabilities, scan for malware before execution, and block malicious content can stop malicious logon scripts from being deployed or run at logon, but this is only a slice: the technique can still succeed via legitimate admin-assigned scripts, insider changes, or non-malware persistence that bypasses detection-focused controls.
- T1037.004detects — A.8.7 requires regular automated validation of system software/content (d), scanning of received data/email/webpages (f), collection of new malware info (n), and monitoring for anomalous behaviour via awareness and procedures (l,m), which can surface RC script modifications as unauthorized changes or malware indicators on covered Unix-like systems, but this is limited to a slice (e.g., post-facto file scans or endpoint tools) rather than broad detection of the persistence mechanism itself.
- T1037.004prevents — A.8.7's rules to prevent unauthorized software (allowlisting), reduce exploitable vulnerabilities, scan for malware before use/execution, and block malicious content directly stop many (but not all) ways an RC script can be maliciously modified and executed at startup, especially on systems still using this deprecated mechanism.
- T1037.005detects — A.8.7 requires regular automated validation of system content, scanning of received data/email/webpages, collection of new malware intel, and placement of detection tools based on risk (including at endpoints/servers where boot-time items could be surfaced), but does not mandate scanning for persistence mechanisms or deprecated startup items specifically, leaving most of the technique's post-boot execution and configuration outside routine malware detection.
- T1037.005prevents — A.8.7's malware-detection/repair software, allowlisting, vulnerability reduction, scanning of received files/executables, and awareness directly stop many malware delivery vectors that would plant a StartupItem, but do not stop an already-privileged adversary (or insider) from manually creating the folders/files, nor do they address the deprecated mechanism's persistence once present.
- T1039detects — A.8.7 requires regular automated validation of system content (d), scanning of received data/files (f1/f2), webpage scanning (f3), and malware-information collection (n/o) that can surface anomalous or unauthorized files pulled from network shares, but does not mandate monitoring or detection of the adversary search technique itself on already-compromised hosts.
- T1040detects — A.8.7 requires malware detection software, regular automated validation of systems for unapproved files/amendments, scanning of received data/email/webpages, and awareness procedures that surface malware indicators; these can detect sniffing tools or captured credential files when they match known malware patterns or introduce anomalous files, but do not address passive sniffing behaviors, configuration changes, or non-malware network captures.
- T1040recovers — A.8.7 point j) explicitly requires business continuity plans including backups and recovery measures for recovering from malware attacks, which directly restores state after a realized sniffing incident that delivered malware (e.g. credential theft leading to further compromise).
- T1041detects — A.8.7 requires malware detection software, regular scans of networks/email/web traffic, anomaly-oriented validation of systems, and awareness of new malware sources, all of which can surface encoded exfiltration that resembles or carries malware payloads over C2; this is a genuine but minority slice of T1041 instances (most are non-malware protocol abuse without detectable malicious code).
- T1046detects — A.8.7 requires regular automated validation of system content, scans of received data/email/webpages, collection of new malware intel, and monitoring for anomalous activity that can surface network scanning tools or behaviors, but does not mandate detection of the discovery technique itself or of all its variants (e.g. native mDNS queries).
- T1046prevents — A.8.7's rules to prevent unauthorized software (allowlisting), block malicious sites, reduce exploitable vulnerabilities, and scan for malware before use stop some discovery tools and scans from running or succeeding, but native platform mechanisms (e.g. mDNS/Bonjour), authorized admin tools, and many legitimate network scans remain possible.
- T1047detects — A.8.7 explicitly requires regular automated validation/scans of systems and data (including for unapproved files/amendments), malware detection software with scans at multiple layers (email, web, endpoints, network), awareness of new malware, and procedures to deal with/report malware attacks, all of which surface WMI abuse when it manifests as anomalous/malicious activity or files; this is limited to a slice because the control is scoped to malware-focused detection rather than general anomalous WMI usage or non-malware behaviors like pure discovery.
- T1047prevents — A.8.7 guidance on application allowlisting, reducing exploitable vulnerabilities, blocking malicious sites, scanning before use, and defence-in-depth placement can stop many (but not all) abuse paths for WMI execution of malicious payloads, especially those relying on unauthorized software, unpatched flaws, or external delivery.
- T1047responds — A.8.7 explicitly requires procedures to deal with malware attacks including reporting and recovering, plus business continuity plans for recovering from malware attacks (j, l); this matches the `responds` verb once the technique is underway, but only a minority slice of T1047 abuse (malware/payload execution) is covered while non-malware WMI behaviors (e.g. discovery) are untouched.
- T1048detects — A.8.7 requires scanning, monitoring for anomalous files/behavior, awareness of malware indicators, and collection of new threat intel, which can surface some exfiltration-over-alternate-protocol activity when it involves malware delivery or anomalous network/file use, but the technique itself is not inherently malware and much of it (e.g. legitimate curl, cloud console downloads, encrypted channels) falls outside malware-focused detection.
- T1048.001detects — A.8.7 requires scanning of data received over networks, email/IM attachments, downloads, and webpages for malware before use, which can surface exfiltration tools or payloads using symmetric encryption (especially if they involve known malware or anomalous files), but does not broadly detect the exfiltration technique itself when it uses custom or non-malware implementations of symmetric crypto over non-C2 protocols.
- T1048.002detects — A.8.7 requires scanning of data received over networks, email attachments, downloads, and webpages for malware (including at multiple points like gateways and endpoints), which can surface exfiltration of malware payloads or related artifacts over asymmetric encrypted protocols such as HTTPS, but does not broadly detect the exfiltration technique itself when no malware is involved.
- T1048.003detects — A.8.7 requires malware detection software, regular scans of data received over networks/email/web, anomaly detection via validation of system content, and awareness of suspicious files, which can surface some obfuscated exfiltration over unencrypted protocols (e.g. anomalous HTTP/FTP/DNS payloads resembling malware), but this is limited to malware-signature or content-validation slices rather than general exfiltration detection.
- T1049detects — A.8.7 requires regular automated validation of system software/data content, scanning of received data/email/webpages, collection of new malware info, and monitoring for anomalous behavior that can surface discovery commands or unexpected network activity, but this is scoped to malware-focused detection rather than broadly catching all network-connection discovery techniques or their artifacts.
- T1052detects — A.8.7 requires scanning of data on removable/electronic storage media (f, e, d) and awareness of malware risks on introduced media (m, l), which can surface anomalous or malicious content during exfiltration attempts via physical medium, but does not broadly instrument or guarantee detection of the exfiltration act itself across all scenarios (e.g. air-gapped hops or non-malware data).
- T1052prevents — A.8.7 guidance (a,e,f,h) explicitly requires rules, protective measures, scanning of removable media before use, and controls against malware introduction during maintenance that can block or detect unauthorized physical-medium use for data movement in air-gapped scenarios, but leaves open user-introduced devices that bypass allowlisting or scanning and does not address the exfiltration act itself once data reaches the medium.
- T1052.001detects — A.8.7 requires regular automated validation of system content, scanning of removable media before use, malware detection tool placement based on risk (including at endpoints), and procedures to deal with malware on systems, which can surface unauthorized USB exfiltration activity when it involves malware or unapproved files, but does not broadly require detection of non-malware USB data exfiltration.
- T1052.001prevents — A.8.7 guidance (a,e,f,h) explicitly requires rules/controls to prevent unauthorized software/media use, protective measures on external files/software via any medium (including USB), scans before use of removable media, and safeguards during maintenance that could introduce malware vectors, which stops the adversary-introduced USB device from being a viable exfiltration path in air-gapped scenarios; partial because it does not universally block all physical USB exfil (e.g. authorized/approved devices or non-malware vectors).
- T1053detects — A.8.7 requires regular automated validation of system software/content, malware scans (including on received data, email, webpages), anomaly detection via updated tools placed per risk assessment, and awareness of new malware indicators; these surface scheduled malicious tasks or their artifacts in many but not all cases (e.g. evasive/encrypted payloads, non-malware persistence, or unmonitored platforms), so only a slice of T1053 is detected.
- T1053prevents — A.8.7's malware detection, allowlisting, vulnerability reduction, scanning of received files/executables, and awareness directly stop many (but not all) malicious scheduled tasks from executing or persisting, especially those relying on dropped malware or unpatched vectors; it does not address legitimate-task abuse, remote scheduling by privileged users, or non-malware persistence mechanisms.
- T1053.002detects — A.8.7 explicitly requires regular automated validation/scans of systems and media (including for unapproved files/amendments), malware detection software placement based on risk, and procedures to collect/verify malware information, which can surface at-scheduled malicious code or anomalous scheduled jobs as malware indicators; this is a genuine but minority slice of the technique (most at-abuse is not delivered as recognizable malware binaries or known signatures).
- T1053.002prevents — A.8.7 guidance explicitly requires rules/controls that prevent unauthorized software (e.g. application allowlisting per 8.19), reducing exploitable vulnerabilities, scanning before use, and protective measures against external files/software; these block many (but not all) AT-abuse vectors such as unscheduled binaries or untrusted payloads, leaving a remainder for admin/sudo-permitted or already-authorized scheduled jobs.
- T1053.003detects — A.8.7 requires regular automated validation of system content, malware scans (including on received data, email, webpages), collection of new malware intel, and anomaly-oriented awareness/training that can surface cron-based malicious scheduling when it matches known patterns or produces observable artifacts, but this is only a slice of the technique's possible implementations (e.g., custom benign-looking jobs, non-malware payloads, or placements outside scanned scopes).
- T1053.003prevents — A.8.7 guidance on application allowlisting, reducing exploitable vulnerabilities, scanning for malware before execution/use, and defence-in-depth placement can stop malicious cron jobs from being scheduled or running, but leaves open many legitimate ways to create and use cron for persistence (e.g. approved binaries, non-malware payloads, or bypassed maintenance paths).
- T1053.005detects — A.8.7 requires regular automated validation of system software/content, malware scans (including on received data, email, webpages), collection of new malware intel, and procedures for reporting malware attacks, which can surface hidden or anomalous scheduled tasks that deliver/execute malware, but does not specifically target or guarantee detection of task-scheduler abuse itself.
- T1053.005prevents — A.8.7 guidance on application allowlisting, reducing exploitable vulnerabilities, scanning for malware before execution/use, and defence-in-depth placement can stop many (but not all) malicious scheduled tasks from running or persisting, especially those relying on unauthorized binaries or known malware signatures.
- T1053.005responds — A.8.7 explicitly requires procedures, training, awareness, and business continuity plans to deal with and recover from malware attacks once underway, which matches the `responds` verb for containing/eradicated malware delivered via scheduled tasks.
- T1053.006detects — A.8.7 requires regular automated validation of system software/content (d), scanning of received data/email/webpages (f), collection of new malware info (n), and placement of detection tools based on risk (g), which can surface systemd timer/service files as anomalous or malicious when they match known patterns or violate baselines, but this is limited to scanned vectors and known signatures rather than reliably catching novel or disguised timer-based persistence.
- T1053.006prevents — A.8.7's rules to prevent unauthorized software (via allowlisting), reduce exploitable vulnerabilities, scan for malware before execution, and protect against malicious files from external sources block many vectors for introducing or activating a malicious systemd timer/service, but do not stop an already-privileged adversary from writing a timer that evades detection or uses approved mechanisms.
- T1053.007detects — A.8.7 explicitly requires regular automated validation of system software/data content, scanning of received data/email/web content, collection of new malware intel, and risk-based placement of detection tools (including at network gateways and endpoints), which can surface malicious container orchestration jobs or their artifacts when they involve known malware signatures, anomalous files, or unapproved changes, but this is limited to a slice because the technique can use legitimate-looking images, benign schedulers, or evasive/zero-day payloads outside scanned scopes or update cycles.
- T1055detects — A.8.7 explicitly requires malware detection software, regular scans of files/data/email/webpages, anomaly validation of system content, and awareness of new malware sources, which can surface many process-injection techniques that deliver or exhibit as malware; however, purely in-memory or evasive injections (especially those using encryption or legitimate APIs without dropping detectable artifacts) frequently fall outside what endpoint malware scanners observe, matching the partial scope set by risk-based placement in the clause.
- T1055prevents — A.8.7's rules to prevent unauthorized software (allowlisting), reduce exploitable vulnerabilities, block malicious sites, scan for malware before execution, and use defense-in-depth placement (including endpoints) stop many common process-injection vectors that rely on dropping/running malicious code or exploiting unpatched flaws; however, many legitimate-functionality abuses (e.g., reflective DLL injection into already-approved processes) remain outside its reach.
- T1055responds — A.8.7 clause l) and j) explicitly require defined procedures, responsibilities, training, and business continuity plans to deal with and recover from malware attacks; process injection is a common malware delivery/execution technique, so once underway the control responds to contain/eradicate it, but only for the malware subset of T1055 (not all injections are malware-borne) and without addressing the technique's evasion or privilege aspects directly.
- T1055.001detects — A.8.7 explicitly requires malware detection/repair software with regular scans of files, emails, downloads, webpages and media (plus awareness and vulnerability management), which surfaces many in-memory or file-based DLL injection artifacts when they match known malware signatures or anomalous patterns, but leaves a large remainder for fileless/reflective/module-stomping variants that evade signature-based tools or never touch scanned storage.
- T1055.001prevents — A.8.7's malware detection/repair, allowlisting, vulnerability reduction, scanning of received files/media/webpages, and awareness directly stop many common vectors for delivering and executing the malicious DLL that T1055.001 relies on, but in-memory reflective/module-stomping variants that never touch disk or use authorized processes evade the bulk of its controls.
- T1055.001responds — A.8.7 explicitly requires procedures, training, and business continuity plans to deal with and recover from malware attacks once underway, which responds to realized DLL injection when it delivers or manifests as malware.
- T1055.002detects — A.8.7 requires malware detection software, regular scans of files/emails/webpages, anomaly validation of system content, and awareness of new malware, which can surface some in-memory PE injection artifacts (e.g. via endpoint scans or behavioral anomalies) but is scoped to malware rather than the full technique and leaves many memory-only, non-file-based cases undetected.
- T1055.002prevents — A.8.7 guidance on reducing exploitable vulnerabilities (via 8.8/8.19), application allowlisting, blocking malicious sites, scanning before execution, defence-in-depth placement, and awareness/training constrains several vectors that enable or deliver PE injection, but leaves a genuine remainder (in-process memory writes via documented APIs inside already-trusted processes).
- T1055.002responds — A.8.7 requires procedures, training, detection/repair tools, scanning, and business continuity plans that respond to malware attacks once underway (including recovery), but PE injection is an in-memory technique that does not rely on detectable malware files and can evade the clause's scanning and detection mechanisms.
- T1055.003detects — A.8.7 explicitly requires malware detection/repair software, regular automated validation/scans of systems/data (including for unapproved files/amendments), awareness training on identifying malware, and procedures to collect/verify malware intelligence, all of which can surface Thread Execution Hijacking when it manifests as recognizable malware artifacts or anomalous behavior, but this is only a slice because the technique can use custom/non-signatured code that evades standard detection tools and the control does not mandate host telemetry or behavioral monitoring depth.
- T1055.003prevents — A.8.7's malware detection/repair, vulnerability reduction, unauthorized software prevention (allowlisting), website blocklisting, scanning of received data/executables, and awareness directly stop many delivery vectors and some in-memory execution paths for Thread Execution Hijacking malware, but leave open advanced in-process techniques (e.g. via already-trusted processes or evasive encrypted delivery) that the clause itself flags as residual.
- T1055.003recovers — A.8.7 point j) explicitly requires business continuity plans that include backup and recovery measures for recovering from malware attacks, which directly restores state after a realized T1055.003 execution (as with the cp-9 and A.8.13 anchors against T1486).
- T1055.003responds — A.8.7 explicitly requires procedures, training, and business continuity plans to deal with and recover from malware attacks once underway, which responds to the realized technique when it delivers malware.
- T1055.004detects — A.8.7 explicitly requires malware detection/repair software with regular scans of files, email, downloads, webpages and media (plus awareness and vulnerability management), which surfaces APC injection artifacts (malicious DLLs, altered processes, suspicious APC queue activity) in most common delivery paths, though Early Bird and evasive variants before hooks can leave a bounded remainder.
- T1055.004prevents — A.8.7 guidance on reducing exploitable vulnerabilities (via 8.8/8.19), application allowlisting, blocking malicious sites, scanning before use, defence-in-depth placement, and awareness/training lowers the chance of the initial malicious code or APC-queue delivery vector being present or executed, but does not stop all APC-injection variants (e.g. Early Bird before hooks, AtomBombing via global atom table, or in-process techniques that bypass endpoint scanning).
- T1055.004responds — A.8.7 explicitly requires procedures, responsibilities, training and business continuity plans to deal with and recover from malware attacks once they occur, which responds to the realized APC-injection technique (malware running in a legitimate process) even though the clause's dominant focus is on prevention and detection.
- T1055.005detects — A.8.7 mandates regular automated scans, malware detection software placement based on risk, and awareness-driven reporting that can surface anomalous TLS callback behavior when it matches known malware patterns or triggers endpoint scans, but this is only a slice because the technique is an in-memory PE manipulation often using evasion (encrypted delivery, living-off-the-land) that bypasses signature-based detection and is not guaranteed to be caught by the control's scanning or awareness layers.
- T1055.005prevents — A.8.7 guidance on reducing exploitable vulnerabilities (via 8.8/8.19), application allowlisting, blocking malicious sites, scanning before execution, defence-in-depth placement, and awareness/training constrains several vectors for introducing and executing the TLS callback PE manipulation, but leaves a remainder where the injection uses in-memory techniques on already-running processes that bypass file-based scanning and allowlisting.
- T1055.005responds — A.8.7 explicitly requires procedures, training, and business continuity plans to deal with and recover from malware attacks once underway, which matches the `responds` verb for an in-flight technique that has already executed code via TLS callback injection.
- T1055.008detects — A.8.7 requires regular automated validation of system software/data content, scanning of received files/emails/webpages, collection of new malware intel, and placement of detection tools based on risk (including at endpoints/servers where ptrace injection would manifest), which surfaces the technique when it matches known malware patterns or leaves detectable artifacts, but does not broadly instrument for novel/unknown ptrace-based injection in arbitrary processes.
- T1055.008prevents — A.8.7's malware detection/repair, vulnerability reduction, unauthorized software rules, awareness, and scanning can block some ptrace-based injection vectors that rely on malicious code delivery or exploitable flaws, but the technique is a live-process memory manipulation that can be performed without conventional malware files and is outside the primary scope of endpoint malware tools.
- T1055.009detects — A.8.7 requires regular automated validation of system content, malware detection software with scans (including at network entry points, email, web), anomaly investigation, and awareness of new malware, which can surface proc-memory injection artifacts when they match known patterns or produce observable anomalies, but leaves a large remainder for novel/ROP-based variants that evade signature-based detection and do not trigger the clause's scanning or validation controls.
- T1055.009prevents — A.8.7 requires reducing exploitable vulnerabilities (via 8.8/8.19), application allowlisting, blocking malicious sites, scanning for malware before use, defence-in-depth placement of detection tools, and awareness — all of which can stop the delivery or successful execution of the malicious payload used in proc memory injection on Linux; this is a genuine but minority slice of the technique's full attack surface (e.g. does not block all gadget enumeration or in-memory ROP once a process is already compromised).
- T1055.011detects — A.8.7 explicitly requires regular scans of files, email, downloads, webpages and media plus collection of new malware indicators, which surfaces many malware samples using EWM injection once they touch disk or network but does not instrument live process memory or EWM itself, leaving the in-memory technique largely unseen.
- T1055.011prevents — A.8.7 requires reducing exploitable vulnerabilities (via 8.8/8.19), application allowlisting, blocking malicious sites, scanning for malware before use/execution, defence-in-depth placement of detection tools, and awareness — all of which close many (but not all) vectors and prerequisites for EWM injection as a malware delivery technique.
- T1055.011responds — A.8.7 explicitly requires procedures, training, and business continuity plans to deal with and recover from malware attacks once underway (l, j, m), which matches the `responds` verb for an in-flight technique; extent is partial because the clause is scoped to malware detection/repair and awareness rather than full incident containment/eradication of process-injection tactics.
- T1055.012detects — A.8.7 explicitly requires malware detection/repair software with regular scans of files, email, downloads, webpages and systems (including at multiple points such as gateways, endpoints and servers), which surfaces many process-hollowing artifacts once the malicious payload is written or executed, but the technique's in-memory, evasive nature (suspended hollowed process masked under a legitimate parent) and explicit callout in the control to attacker evasive techniques leave a substantial slice undetected.
- T1055.012prevents — A.8.7's malware detection/repair software, vulnerability reduction (8.8), unauthorized software rules (allowlisting), website blocklisting, scanning of received data/email/webpages, and awareness directly stop many delivery vectors and execution paths that would otherwise lead to process hollowing; the remainder is in-memory techniques that can still succeed when the hollowed process is spawned from an already-compromised context or evades the placed scanners.
- T1055.012recovers — A.8.7 point j) explicitly requires business continuity plans including backups and recovery measures for recovering from malware attacks, which restores state after a successful process-hollowing malware execution
- T1055.012responds — A.8.7 explicitly requires procedures, training, and business continuity plans to deal with and recover from malware attacks once underway, which responds to the realized T1055.012 execution (malware running inside the hollowed process) even though most of the clause is oriented toward prevention and detection.
- T1055.013detects — A.8.7 explicitly requires malware detection/repair software, regular automated validation of system content, scanning of files/downloads/webpages/email, awareness of new malware, and placement based on risk assessment, all of which can surface process doppelgänging artifacts or anomalous behavior on Windows endpoints; this is limited to a slice because the technique is fileless, uses deprecated TxF APIs to evade common monitoring hooks, and may only be caught post-execution or via specific behavioral indicators rather than reliably at every step.
- T1055.013prevents — A.8.7 explicitly requires reducing exploitable vulnerabilities (via 8.8/8.19), application allowlisting, blocking malicious sites, scanning before execution, defence-in-depth placement, and awareness — all of which close the majority of infection vectors that deliver or enable Process Doppelgänging; the named remainder is its in-memory TxF abuse that evades many on-disk and API-monitored controls.
- T1055.013recovers — A.8.7 explicitly requires business continuity plans including backups and recovery measures (j) to recover from malware attacks, which directly restores state after process-doppelgänging execution (a fileless malware injection technique).
- T1055.013responds — A.8.7 explicitly requires procedures, training, awareness, detection/repair software, scanning, and business continuity plans to respond to and recover from malware attacks once underway; process doppelgänging is a malware delivery technique that can be contained/eradicated by those measures, but the control's malware-specific focus leaves a remainder for non-malware injection variants and the technique's evasion of common detection points.
- T1055.014detects — A.8.7 explicitly requires regular automated validation of system software/content, scanning of received data/email/webpages, malware detection software placement based on risk, and procedures for reporting malware, which can surface VDSO hijacking as anomalous code injection or unauthorized library mapping on Linux endpoints/servers; however this is only a slice because the technique's stealth (masquerading under legitimate process, evading process-based defenses) and reliance on memory patching leave much of it outside typical malware signature or scan detection.
- T1055.014prevents — A.8.7's malware detection/repair, vulnerability reduction (8.8), unauthorized software rules (8.19), awareness, and scanning can stop some VDSO-hijacking malware payloads from executing or being mapped, but the technique's in-memory syscall/GOT patching in a live legitimate process is not directly addressed by any listed control and can still succeed.
- T1055.014recovers — A.8.7 point j) explicitly requires business continuity plans including backups and recovery measures for malware attacks, which recovers state after a realized VDSO hijacking injection (an in-memory malware technique).
- T1055.014responds — A.8.7 explicitly requires procedures, training, awareness, scanning, and business continuity plans to respond to and recover from malware attacks once underway, which matches the in-memory malicious code execution of VDSO hijacking (a form of malware injection), but only partially as the clause is malware-centric while the technique is a stealthy Linux-specific process injection that can evade detection tools.
- T1055.015detects — A.8.7 requires regular automated validation of system software/data content, malware detection software with scans (including of received data, email, webpages), awareness training, and procedures to collect/verify malware information, which can surface ListPlanting artifacts or anomalous behavior in some cases but is not scoped to reliably catch in-memory process injection via list-view controls or window messages.
- T1055.015prevents — A.8.7's malware detection, vulnerability reduction, unauthorized software rules, awareness, and scanning can block some ListPlanting vectors that rely on malware delivery or exploitable flaws, but the technique is a form of in-memory process injection via legitimate Windows APIs and UI controls that does not require malware files, so most of the class remains unreached.
- T1055.015responds — A.8.7 requires procedures, training, detection/repair tools, scanning, awareness and business continuity plans to respond to and recover from malware attacks once underway; ListPlanting executes malware code inside a legitimate process, so the clause's incident-response slice applies but is limited by the technique's evasion of process-based defenses and detection products.
- T1056detects — A.8.7 requires malware detection software, regular scans of data/email/web content, anomaly validation of system files, and awareness of malware indicators; these can surface some input-capture malware (e.g. via endpoint scans or known malicious sites) but miss transparent hooking, non-malware mechanisms, and many evasive variants by design.
- T1056prevents — A.8.7's malware detection, allowlisting, vulnerability reduction, website blocklisting, awareness training, and scanning directly stop many input-capture malware vectors (e.g. keyloggers, hooks, malicious downloads) before they run, but leave non-malware techniques (e.g. pure phishing deception, legitimate API abuse, or non-executable capture) untouched.
- T1056.001detects — A.8.7 explicitly requires malware detection/repair software, regular automated scans of systems/data/email/webpages, collection of new malware intel, and validation for unapproved changes, all of which surface many (but not all) keylogging implementations that rely on malware-like artifacts such as custom drivers, registry mods, or hooks.
- T1056.001prevents — A.8.7's malware detection/repair, allowlisting, vulnerability reduction, scanning, awareness, and protective measures against malicious files/websites can stop many keylogging malware vectors before they execute, but not all (e.g. custom drivers, hardware buffer reads, or non-malware-based hooking/registry mods).
- T1056.001recovers — A.8.7 explicitly requires preparing business continuity plans including backups and recovery measures (item j) to recover from malware attacks, and keylogging is commonly delivered by malware whose effects (including captured credentials) can be addressed through such recovery processes.
- T1056.002detects — A.8.7 requires malware detection software, regular scans of received data/email/webpages, awareness training on identifying malware-infected files, and procedures to collect/verify malware threat intel, which can surface GUI input capture when it is delivered or behaves as malware (e.g. fake removal suite or malicious script), but this is only a slice since the technique is not inherently malware and can be implemented in legitimate-looking non-malware processes.
- T1056.003detects — A.8.7 requires regular automated validation of system software/content, malware scans at multiple layers (including web), collection of new malware intel, and awareness/reporting procedures that can surface anomalous portal modifications or credential-capture artifacts when they match known malware patterns, but this is only a slice of the technique's post-compromise admin-install or initial-exploit vectors that do not involve detectable malware binaries.
- T1056.003prevents — A.8.7's malware detection, vulnerability reduction, unauthorized software prevention (allowlisting), website blocklisting, and awareness directly stop many post-compromise or exploit-based installations of credential-capturing web code, but not all vectors (e.g., admin-authorized changes or non-malware delivery)
- T1056.003recovers — A.8.7 point j) explicitly requires business continuity plans including backups and recovery measures for recovering from malware attacks, which directly restores state after the technique (malware-based web portal capture) has run.
- T1056.004detects — A.8.7 explicitly requires malware detection/repair software, regular scans of files/downloads/webpages/email, collection of new malware intel, and awareness of evasive techniques, which surfaces many (but not all) hooking-based credential stealers once they land and exhibit detectable malware-like behavior; it does not instrument or surface the in-process API redirection itself when performed by non-malware tools or custom code.
- T1056.004prevents — A.8.7's malware detection/repair, allowlisting, vulnerability reduction, scanning of received files/emails/webpages, and awareness directly stop many common hooking-based credential stealers (especially those delivered as malware or exploiting unpatched code), but cannot stop all in-memory hooking variants (e.g. custom inline/IAT hooks or LD_PRELOAD without a detectable payload) that an adversary can introduce without triggering the listed controls.
- T1057detects — A.8.7 requires malware detection software, regular scans of files/data/emails/webpages, anomaly-oriented validation of system content, and awareness of new malware — all of which can surface process-discovery activity when it is performed by actual malware, but the control is silent on non-malware process enumeration, on non-file-based discovery methods, and on placement that would guarantee coverage of every platform or every process-listing command.
- T1059detects — Preventing or detecting unauthorized scripts and interpreters through allow-listing and regular integrity validation limits adversaries’ ability to abuse command and scripting interpreters.
- T1059prevents — A.8.7's rules to prevent unauthorized software (allowlisting), reduce exploitable vulnerabilities, block malicious sites, scan before use, and isolate high-risk environments stop many abuse paths for interpreters (especially downloaded/embedded payloads or unapproved ones), but built-in interpreters required for normal operations cannot be removed and remain fully usable by adversaries.
- T1059.001detects — A.8.7 requires regular scans, awareness, and monitoring for malware (including downloads, attachments, webpages, and anomalous files), which can surface PowerShell-based execution or malware delivery but does not broadly instrument or guarantee detection of all script abuse, in-memory execution, or non-malware uses of the interpreter.
- T1059.001prevents — A.8.7 guidance explicitly includes application allowlisting (8.19), reducing exploitable vulnerabilities (8.8), blocking malicious sites, scanning downloads/webpages, and awareness that together stop many (but not all) PowerShell abuse paths such as unsigned scripts, downloads, or exploitation vectors; in-memory .NET reflection and built-in legitimate use remain unaddressed.
- T1059.001responds — A.8.7 explicitly requires procedures, training, awareness, and business continuity plans to deal with and recover from malware attacks (points l, m, j); when PowerShell abuse delivers or is itself a malware payload the clause responds to the realized event, but this is only a slice of the technique (e.g. non-malware script execution, in-memory .NET abuse) and the control is not centered on containment/eradication of the actor's foothold.
- T1059.002detects — A.8.7 requires regular automated validation of system content, malware scanning of received data/email/webpages, collection of new malware intel, and awareness of anomalous behaviors, which can surface AppleScript abuse when it triggers known signatures, anomalous file changes, or suspicious scripts at entry points, but leaves large gaps for novel/embedded/scripted execution that evades signature-based or non-code-focused scanning.
- T1059.002prevents — A.8.7's malware detection, allowlisting, vulnerability reduction, website blocklisting, scanning of received files/emails/webpages, and awareness directly stop many delivery vectors and execution paths for AppleScript-based malware on macOS, but cannot block all legitimate-script-abuse, native-API, or already-present interpreter uses.
- T1059.002responds — A.8.7 explicitly requires procedures to deal with malware attacks including reporting and recovering, plus business continuity plans for recovering from malware attacks (j, l); AppleScript abuse is a malware delivery/execution vector on macOS so incident response to the realized attack qualifies as responds, but the clause is scoped to malware rather than all script abuse and recovery does not address all post-execution effects.
- T1059.003detects — A.8.7 requires regular automated validation of system content, scanning of received data/email/webpages for malware before use, collection of new malware intel, and placement of detection tools based on risk (including at endpoints, gateways, and email servers), which can surface cmd.exe or batch-file abuse when it delivers or exhibits known malware behavior, but this is only a slice of T1059.003 executions that do not involve malware.
- T1059.003prevents — A.8.7's rules to prevent unauthorized software (allowlisting), reduce exploitable vulnerabilities, block malicious sites, scan before execution, and isolate high-risk environments stop many (but not all) ways cmd.exe or .bat/.cmd files can be introduced and abused for adversary execution.
- T1059.004detects — A.8.7 requires regular automated validation of system content, scanning of received data/email/webpages, collection of new malware intel, and placement of detection tools based on risk (including at network gateways, endpoints, and servers), which can surface Unix shell abuse when it involves known malicious scripts, files, or anomalous behavior, but this is limited to malware-linked cases and does not broadly detect all legitimate-looking shell command or script execution.
- T1059.004prevents — A.8.7 prevents the technique by blocking unauthorized software (allowlisting), reducing exploitable vulnerabilities, scanning for malware before execution, and isolating high-risk environments, but cannot stop legitimate shell use or all post-compromise abuse vectors.
- T1059.005detects — A.8.7 explicitly requires regular automated validation/scans of systems, data, email/IM attachments, downloads, and webpages for malware (including before use), which surfaces VB/VBA/VBScript payloads when they match known malware signatures or anomalous patterns, but this is limited to post-delivery scanning rather than detecting the broader abuse technique itself (e.g. in-memory execution or macro automation without detectable malware).
- T1059.005prevents — A.8.7 guidance explicitly lists application allowlisting, reducing exploitable vulnerabilities, blocking malicious sites, scanning received files/emails/web content before use, and awareness training — all of which stop many (but not all) VB/VBA/VBScript abuse paths such as malicious Office macros or VBScript payloads.
- T1059.005responds — A.8.7 explicitly requires procedures, training, awareness, business continuity plans and recovery measures to deal with and recover from malware attacks once underway, which matches the `responds` verb for a realized T1059.005 execution delivered via malware (e.g. VBA macro in spearphish attachment); partial because the clause is scoped to malware vectors and does not address all non-malware VB abuse paths named in the technique.
- T1059.006detects — A.8.7 requires regular automated validation of system content, malware detection software with scanning (including of received data, downloads, webpages), anomaly investigation, and awareness-driven reporting of suspicious files/behaviors, which can surface Python-based execution when it matches known malware patterns or triggers scans, but leaves large gaps for custom benign-looking Python scripts that do not match signatures or trip file-integrity checks.
- T1059.006prevents — A.8.7 guidance (a,c,f,g,h) directly prevents unauthorized/malicious Python execution via allowlisting, vulnerability reduction, scanning before use, and defense-in-depth placement, but leaves legitimate Python interpreters required by the platform (the dominant attack vector) untouched.
- T1059.007detects — A.8.7 explicitly requires regular automated validation/scans of systems, data, email/IM attachments, webpages and storage media plus collection of new malware intel, which surfaces many JS-based payloads (especially file-based or web-delivered ones) but leaves gaps for in-memory JXA/osascript, heavily obfuscated scripts, and non-file interpreter abuse that fall outside typical malware-signature or scan coverage.
- T1059.007prevents — A.8.7's malware detection/repair, website blocklisting, vulnerability reduction, unauthorized software rules, awareness training, and scanning of downloads/webpages/email directly stop many common JS-based execution vectors (web delivery, drive-by, secondary payloads); it does not stop all JS abuse (e.g. in-memory JXA, built-in interpreters, or non-malware scripts).
- T1059.007responds — A.8.7 explicitly requires procedures, training, awareness, business continuity plans and recovery measures to deal with and recover from malware attacks once underway; JS-based execution is a common malware delivery/execution vector (web scripts, downloads, drive-by) that these response elements address, but the clause is scoped to malware events and does not reach all non-malware JS abuse (e.g. benign but maliciously-used interpreters or in-memory JXA).
- T1059.008detects — A.8.7 requires regular automated validation/scans of systems (d,f), malware detection software placement based on risk (g), collection of new malware intel (n,o), and awareness-driven reporting (l,m), which can surface CLI abuse on network devices when it matches known malware patterns or anomalous files/config changes, but this is limited to malware signatures rather than general CLI command abuse and does not cover all network device platforms or non-malware indicators.
- T1059.008prevents — A.8.7's rules to prevent unauthorized software (allowlisting), reduce exploitable vulnerabilities, block malicious sites, scan before use, and harden configs via awareness/change controls stop many avenues for delivering and executing malicious CLI payloads on network devices, but do not block legitimate CLI use or all post-compromise abuse vectors.
- T1059.009detects — A.8.7 requires regular automated validation/scans of systems (d,f), collection of new malware info (n,o), and awareness of indicators (m,l) that can surface anomalous API abuse when it matches known malware patterns or unapproved changes, but this is limited to malware-specific signatures rather than general cloud API command abuse and does not cover the full technique surface across IaaS/SaaS platforms.
- T1059.010detects — A.8.7 explicitly requires regular automated validation/scans of systems, data, email/IM attachments, webpages, and media for malware (including before use and at multiple network points), which surfaces AHK/AutoIT scripts or compiled executables when they match known malware signatures or anomalous patterns, but this is limited to malware-specific detection rather than all instances of the technique (e.g., benign or novel automation use).
- T1059.010prevents — A.8.7 explicitly requires rules/controls that prevent unauthorized software (e.g. application allowlisting per 8.19), reducing exploitable vulnerabilities, scanning before use of received files/media/downloads, and protective measures against external files/software; these block many (but not all) delivery/execution paths for AHK/AutoIT scripts or compiled payloads on Windows.
- T1059.010responds — A.8.7 explicitly requires procedures and responsibilities to deal with protection against malware including reporting and recovering from malware attacks, plus business continuity plans for recovering from malware attacks (j, l); once the AHK/AutoIT technique has executed and delivered its malicious payload this directly matches the `responds` verb (containment/eradication once underway).
- T1059.011detects — A.8.7 requires regular automated validation of system content, malware detection software with scans (including on received data, email, webpages), anomaly investigation, and awareness of new malware, which can surface Lua-based execution when it matches known patterns or leaves detectable artifacts, but this is limited to a slice because Lua abuse often blends with legitimate embedded use, evades signature-based tools via custom interpreters or encryption (explicitly noted in guidance), and is not comprehensively instrumented across all platforms or runtime embeddings.
- T1059.011prevents — A.8.7 guidance on application allowlisting, reducing exploitable vulnerabilities, scanning for malware before use/execution, and defence-in-depth placement can stop many (but not all) Lua-based execution paths, especially those relying on unauthorized interpreters, unpatched vectors, or unvetted files.
- T1059.012detects — A.8.7 requires regular automated validation of system content, malware scanning of received data/email/webpages, collection of new malware intel, and risk-based placement of detection tools (including at hypervisor-relevant points like network gateways and endpoints), which can surface hypervisor CLI abuse when it matches known malware patterns or anomalous changes, but leaves most legitimate-admin-use and novel/encrypted cases undetected.
- T1059.012prevents — A.8.7's allowlisting (8.19), unauthorized-software rules, vulnerability reduction, and hypervisor-specific placement/config can block many abuse vectors for hypervisor CLIs, but the control's malware-centric focus leaves a remainder for non-malware administrative abuse or insider use of legitimate hypervisor tools.
- T1059.013detects — A.8.7 requires regular automated validation of system content, malware scanning of received data/files/emails/webpages, collection of new malware intel, and awareness of anomalous indicators, which can surface malicious container CLI/API use when it involves known malware, suspicious downloads, or unapproved files, but this is limited to malware-tied cases and does not broadly detect legitimate CLI/API abuse for command execution or discovery in containers.
- T1068detects — A.8.7 requires regular automated validation of system software/content, malware scanning of received files/downloads/webpages, collection of new malware intel, and awareness of evasive techniques, which can surface some exploitation attempts (especially those involving known malicious files, drivers, or anomalous changes), but does not broadly detect the core technique of exploiting a software vulnerability to escalate privileges.
- T1068prevents — A.8.7c explicitly reduces exploitable vulnerabilities via technical vulnerability management (8.8), which directly stops many software flaws that T1068 would otherwise exploit; other clauses (allowlisting, malware scanning, awareness) address delivery vectors but not the core exploitation mechanic, leaving a bounded remainder of unpatched or zero-day cases.
- T1070detects — A.8.7 requires malware detection software, regular automated validation of systems for unapproved files/amendments, scanning of received data/email/webpages, and procedures to collect/verify new malware info, which can surface some indicator-removal artifacts (e.g. anomalous file changes or modified logs) when they resemble malware delivery or persistence, but this is scoped only to malware-related indicators rather than the broad class of selective artifact tampering.
- T1070recovers — A.8.7 point j) explicitly requires business continuity plans that include data/software backup and recovery measures for recovering from malware attacks; while T1070's selective artifact removal (logs, histories, metadata) is not itself malware, the control's recovery posture addresses post-attack state restoration after such tampering has occurred, though this is only one slice of the broad technique across platforms and non-malware scenarios.
- T1070.003detects — A.8.7 requires regular automated validation of system software/data content, scanning for unapproved files/amendments, malware detection software with scans at multiple layers, anomaly-aware placement via risk assessment, and procedures for reporting malware events, which can surface command-history clearing as suspicious file deletion or anomalous activity in some (but not all) cases.
- T1070.003recovers — A.8.7 point j) explicitly requires business continuity plans including backups and recovery measures for malware attacks; while command history deletion is not malware, the control's recovery-from-attack language and backup provisions can restore a pre-deletion state from offline backups, but this is only a slice of the technique's platforms and methods (e.g. in-memory Clear-History or direct file edits).
- T1070.004detects — A.8.7 requires regular automated validation of system software/data content, scanning for unapproved files/amendments, malware detection software with scans at multiple points, and procedures to collect/verify malware intelligence, all of which can surface file-deletion artifacts or the dropped files themselves before/after cleanup.
- T1070.004recovers — A.8.7 point j explicitly requires business continuity plans that include data/software backup and recovery measures for recovering from malware attacks, which can restore files deleted by post-intrusion cleanup (T1070.004) in malware-driven intrusions, but this is scoped only to malware events rather than all file-deletion activity and does not address non-malware uses of the technique.
- T1070.006detects — A.8.7 requires regular automated validation of software/data content, scanning for malware/unapproved files/amendments, anomaly-aware placement of detection tools, and procedures for reporting malware incidents, which can surface timestomping artifacts when they accompany or deliver malware but does not broadly instrument for timestamp discrepancies themselves.
- T1070.008detects — A.8.7 requires regular automated validation of system content, malware scans on email/attachments/downloads/webpages at multiple points, and procedures to collect/verify malware information, which can surface mailbox-clearing activity when it involves known malware, suspicious attachments, or anomalous file changes, but this is only a minority slice of the technique (most instances use admin APIs, transport rules, or direct deletion without malware involvement).
- T1070.008recovers — A.8.7 point j) explicitly requires business continuity plans that include data and software backup plus recovery measures for recovering from malware attacks; the T1070.008 technique can be (and often is) performed by malware that then deletes mailbox artifacts, so the control's recovery capability restores a slice of the destroyed mailbox state.
- T1070.009detects — A.8.7 requires regular automated validation/scans of systems (d,f), collection of new malware info (n,o), and procedures for reporting malware (l), which can surface cleanup activity that matches known malware patterns or anomalies, but does not broadly instrument for the many non-malware-specific cleanup actions (registry mods, service deletion, account removal) described in T1070.009.
- T1070.010detects — A.8.7 requires regular automated validation/scans of systems (including for unapproved files/amendments), malware detection software with broad placement (gateways, endpoints, servers), and procedures to collect/verify new malware intel, all of which surface relocated copies or anomalous artifacts post-delivery on the listed platforms.
- T1070.010prevents — A.8.7's allowlisting, vulnerability reduction, scanning before use, web/email blocking, and defense-in-depth placement stop many relocation tactics that rely on unauthorized software, known malicious locations, or un-scanned files, but cannot block all post-delivery evasion moves (e.g. renaming to legitimate paths or targeting exclusions/persistence locations inside already-approved processes).
- T1070.010recovers — A.8.7 point j) explicitly requires business continuity plans that include data/software backup and recovery measures for recovering from malware attacks, which directly restores state after the relocation (and associated evasion/deletion) has occurred.
- T1070.010responds — A.8.7 requires incident response procedures, training, and business continuity plans specifically for recovering from malware attacks (points j, k, l), which matches the `responds` verb once the relocation technique is underway as part of a malware event.
- T1071detects — A.8.7 requires regular automated validation, scans of received data/email/webpages, collection of new malware info, and placement of detection tools based on risk (including at network gateways and endpoints), which can surface anomalous application-layer protocol use when it carries known malware or deviates from baselines, but does not broadly detect protocol blending or C2 that avoids malware signatures.
- T1071.001detects — A.8.7 requires scanning of webpages, email, downloads, and network data plus placement of detection tools at network gateways/endpoints based on risk, which surfaces web-protocol C2 blending when it matches known malware patterns or anomalies, but leaves substantial undetected remainder for novel/encrypted/obfuscated C2 that evades signature-based or non-monitored scanning.
- T1071.001prevents — A.8.7 guidance (b, e, f, g) explicitly requires controls to prevent/detect/block known or suspected malicious websites, scan webpages for malware on access, and place detection at network gateways using risk-based defence-in-depth, which stops some (but not all) web-protocol C2 that relies on malicious infrastructure or deliverable payloads.
- T1071.002detects — A.8.7 requires scanning of data received over networks, email/IM attachments, webpages, and storage media for malware (including via network gateways), which can surface file-transfer-protocol C2 when it carries or conceals malware payloads, but does not broadly detect protocol-abuse C2 traffic that blends with normal file-transfer flows or uses non-malware concealment.
- T1071.002prevents — A.8.7 guidance (b,e,f,g,h) explicitly requires controls that prevent or detect use of known/suspected malicious websites, protective measures for files/software from external networks, scanning of data received over networks before use, and placement of detection at network gateways for protocols including file transfer, which stops many (but not all) instances of adversaries abusing common file-transfer protocols like SMB/FTP to blend C2 traffic.
- T1071.003detects — A.8.7 explicitly requires scanning email and instant messaging attachments/downloads for malware before use (at servers, desktops, network entry), plus awareness of malicious emails and collection of new malware intel, which surfaces abuse of mail protocols for C2 when it involves known malware payloads or anomalous attachments; this is a genuine but minority slice of the technique (most T1071.003 use is non-malware C2 blending in normal traffic, outside malware scanners).
- T1071.003prevents — A.8.7 explicitly requires controls that prevent or detect use of known/suspected malicious websites (blocklisting), scanning of email/IM attachments/downloads before use at multiple points (servers, desktops, network entry), reducing exploitable vulnerabilities, and awareness/training on identifying/mitigating malware-infected emails/files, all of which stop T1071.003's abuse of mail protocols for C2 from succeeding in many common cases; it is only partial because the control is silent on protocol-level concealment in legitimate mail flows and on non-malware C2 that blends without delivering a malicious payload.
- T1071.003responds — A.8.7(l) explicitly requires procedures for reporting and recovering from malware attacks, and A.8.7(j) requires business continuity plans for recovering from malware attacks; when the T1071.003 C2 channel delivers or triggers malware the control responds to the realized malware event.
- T1071.004detects — A.8.7 explicitly requires regular scans of webpages, email, downloads, and network-received data plus placement of detection tools based on risk (including at network gateways for protocols like web), which surfaces anomalous/malicious DNS traffic in some vectors; it does not address infrequent beaconing, encrypted tunnels, or all protocol fields where the technique hides.
- T1071.004prevents — A.8.7 guidance on blocking known/suspected malicious websites, reducing exploitable vulnerabilities, scanning for malware in received data/webpages, and defence-in-depth placement (e.g. network gateways) can stop some DNS-tunneling malware delivery or C2 setup before it runs, but leaves most legitimate-DNS-abuse cases (blending, infrequent beacons, non-malware vectors) untouched.
- T1071.005detects — A.8.7 requires regular scans, monitoring for anomalous files/behavior, awareness of new malware, and placement of detection tools based on risk (including at network gateways for protocols), which can surface pub/sub C2 traffic when it carries known malware signatures or triggers anomaly rules, but does not broadly instrument or guarantee detection of protocol-abuse blending with normal traffic.
- T1072detects — A.8.7 requires regular automated validation/scans of systems (d,f), collection of new malware info (n,o), and awareness of anomalous indicators (m,l), which can surface abuse of deployment tools when it involves known malware, unauthorized files/amendments, or suspicious downloads — but this is only a slice, as the technique often uses legitimate admin tools without delivering detectable malware payloads.
- T1074detects — A.8.7 requires malware detection software, regular automated validation/scans of systems/data (including received files, email attachments, downloads, and webpages), anomaly investigation for unapproved files/amendments, and awareness of new malware — which can surface staging activity when it involves malware delivery, suspicious files, or unauthorized changes, but does not broadly detect non-malware staging of collected data.
- T1074recovers — A.8.7 point j explicitly requires business continuity plans that include data and software backup plus recovery measures for recovering from malware attacks; staging is a common preparatory step inside many malware-driven data theft campaigns, so the control restores the post-exfiltration state the technique helped enable.
- T1074.001detects — A.8.7 requires regular automated validation of system software/data content, scanning of received files/emails/webpages, malware detection tools placed per risk assessment, and procedures for reporting malware incidents, which can surface anomalous staging activity (e.g. unexpected files, archives, or registry changes) but only as a minority slice of the broad technique rather than its dominant mechanisms.
- T1074.001recovers — A.8.7 point j explicitly requires business continuity plans that include data and software backup plus recovery measures for recovering from malware attacks; staging is an early post-collection step inside many malware-driven exfiltration chains, so the control restores the affected assets after the technique has run.
- T1074.002detects — A.8.7 requires regular automated validation of system content, malware scans (including on received data, email, downloads, and webpages), anomaly investigation for unapproved files/amendments, and monitoring for new malware indicators, which can surface staging activity as anomalous file creation or transfers but only where it intersects with malware vectors or monitored entry points, leaving most pure staging (e.g., benign copies or cloud VM staging) unreached.
- T1074.002recovers — A.8.7 point j explicitly requires business continuity plans including backups and recovery measures for recovering from malware attacks; while T1074.002 itself is not a malware attack, the staged data (often prepared for exfiltration) can be recovered post-incident via those same offline/online backups once the broader attack is contained.
- T1078detects — A.8.7 requires regular scans, anomaly detection via validation of software/data, awareness of malware indicators, and collection of new malware intel, which can surface credential-abuse signs when malware or anomalous files are involved, but the technique explicitly avoids malware/tools and many account abuses (inactive accounts, pivoting, legitimate use) produce no malware artifacts.
- T1078.001detects — A.8.7 requires regular automated validation of software/content, malware scans at multiple points, collection of new malware intel, and verification of sources, which can surface default-account abuse when it involves known malware, anomalous files, or suspicious access patterns, but this is only a minority slice of the technique (most default-account use is legitimate credential abuse without malware).
- T1078.001recovers — A.8.7 point j) explicitly requires business continuity plans including backups and recovery measures for malware attacks, which can restore state after default-account abuse that delivered malware (e.g. ransomware or persistence payloads), but the control is scoped only to malware vectors and does not address credential abuse alone.
- T1078.002detects — A.8.7 requires regular scans, malware detection software placement based on risk, collection of new malware info, and procedures for reporting malware attacks, which can surface domain account abuse when it involves known malware delivery or execution artifacts (e.g. via scans of downloads, email, or anomalous files), but this is a minority slice as the technique is primarily credential-based (dumping/reuse) rather than malware-driven.
- T1078.003detects — A.8.7 requires regular automated validation of system software/data content, scanning for unapproved files/amendments, malware detection software with scans at multiple layers, anomaly-aware placement via risk assessment, and procedures for reporting malware incidents, all of which can surface local account abuse indicators (e.g. anomalous credential use, unauthorized changes, or malware facilitating dumping/reuse) but only as a minority slice of the broad technique.
- T1078.004detects — A.8.7 requires regular automated validation of systems, malware scans (including on received data, email, webpages), collection of new malware info, and verification of sources, which can surface malware delivered via or exploiting cloud accounts but does not broadly detect the account-compromise techniques (phishing, brute force, misconfigs, credential abuse) themselves.
- T1078.004recovers — A.8.7 point j) explicitly requires business continuity plans including backups and recovery measures for recovering from malware attacks, which can restore state after a T1078.004-compromised cloud account is used to deliver or spread malware.
- T1080detects — A.8.7 explicitly requires regular automated validation of software/data content on systems (especially critical ones), scanning of received files/storage media/email/web content for malware before use, and procedures to collect/verify malware intelligence, all of which surface tainted shared content or the resulting infections after the adversary has acted.
- T1080prevents — A.8.7 guidance directly prevents tainting via malware detection/repair software (scanning shared storage, email, downloads, webpages), rules against unauthorized software (allowlisting), vulnerability reduction, and protective measures for external files, but leaves gaps for novel/zero-day infections, binary append/prepend that evades scanners, insider or maintenance-time tainting, and non-malware variants like directory-share pivots relying on LNK masquerading.
- T1080responds — A.8.7 explicitly requires business continuity plans, isolating high-risk environments, procedures for recovering from malware attacks, and awareness/training on mitigating receipt/installation of malware, which together act on an in-progress T1080 infection (tainted shared content already present and propagating) to contain spread and recover.
- T1082detects — A.8.7 requires regular automated validation of system software/content, malware scanning of received data/email/webpages, collection of new malware intel, and monitoring for anomalous activity that can surface system-info-gathering tools or behaviors, but this is scoped to malware vectors and does not broadly instrument the diverse native discovery commands, CLI queries, or API calls described.
- T1083detects — A.8.7 requires regular automated validation/scans of systems (d,f), malware detection software placement based on risk (g), and procedures to collect/verify malware info (n,o), which can surface anomalous file/directory activity or known malicious artifacts during discovery; this is only a slice because the control is scoped to malware indicators rather than general file-enumeration behavior, and many T1083 utilities leave no malware footprint.
- T1087detects — A.8.7 requires regular automated validation of system software/data content, scanning of received files/emails/webpages, collection of new malware intel, and monitoring/reporting procedures that can surface anomalous account-enumeration commands or file searches as suspicious activity, but this is scoped only to malware-related observables rather than general account discovery techniques.
- T1087.002detects — A.8.7 requires monitoring, scanning, awareness, and procedures that can surface anomalous enumeration commands or malware facilitating discovery, but this is scoped by risk and does not guarantee detection of all legitimate-looking domain queries across platforms.
- T1087.003detects — A.8.7 requires regular scans, monitoring for anomalous files/behavior, awareness of suspicious activity, and procedures to detect/report malware; these can surface the reconnaissance technique when it involves suspicious PowerShell, email-related access, or anomalous queries, but the control is scoped to malware vectors and does not broadly instrument or guarantee detection of authenticated GAL enumeration.
- T1087.004detects — A.8.7 requires regular automated validation of system content, scanning of received data/email/webpages, collection of new malware intel, and monitoring placement based on risk, which can surface anomalous account-enumeration commands or malware artifacts that enable T1087.004, but this is limited to malware-tied discovery rather than general detection of the technique itself.
- T1090detects — A.8.7 requires malware detection software, regular scans of networks/email/web traffic, anomaly validation of systems, and awareness of new malware sources, which can surface proxy-based C2 when it carries or exhibits known malware indicators, but does not broadly detect proxy usage itself (especially non-malware proxies, CDN routing, or encrypted/evasive chains).
- T1090.001detects — A.8.7 requires malware detection software, regular scans of files/downloads/webpages, anomaly detection via integrity checks, and awareness of new malware, which can surface proxy tools or anomalous internal redirection if they involve known malware, suspicious files, or detectable behavioral indicators, but this is only a minority slice since most internal proxies (e.g. benign tools, custom scripts, or living-off-the-land P2P) are not malware and fall outside the clause's malware-focused scope.
- T1090.002detects — A.8.7 requires scanning, monitoring for anomalous behavior via malware tools, awareness, and validation that can surface proxy-based C2 as suspicious network activity or malware artifacts, but only where it intersects malware delivery rather than all proxy use for traffic redirection.
- T1090.003detects — A.8.7 requires scanning, monitoring for anomalous behavior from malware (including at network gateways, email, web, endpoints), and awareness of new threats, which can surface indicators of multi-hop proxy chains (e.g., Tor, ORB, anomalous routing) when they deliver or mask malware C2, but does not broadly detect the proxy technique itself independent of malware involvement and leaves many implementations scoped only to known malware signatures.
- T1090.004detects — A.8.7 requires scanning for malware (including at network gateways, email, web access, and endpoints) plus awareness and anomaly procedures that can surface domain-fronted C2 traffic when it carries or triggers malware, but the control is scoped to malware artifacts rather than the HTTPS routing obfuscation itself and does not guarantee detection of clean domain-fronted sessions.
- T1091detects — A.8.7 explicitly requires regular automated scans of removable media, email, downloads, and data from external sources (including before use), plus awareness of new malware and verification of sources, which surfaces T1091's use of infected media or mobile devices as the vector.
- T1091prevents — A.8.7 explicitly requires rules/controls to prevent unauthorized software and media-borne malware (allowlisting, scanning all removable/external media before use, protective measures on files from external networks/media, reducing exploitable vulns, and blocking malicious sites), which directly stops the copying/execution path of T1091 on Windows including Autorun and USB vectors; the remainder is firmware-level or air-gap manual manipulation that bypasses software controls.
- T1091responds — A.8.7 explicitly requires business continuity plans, isolating high-risk environments, procedures for recovering from malware attacks, and handling malware on systems once present, which responds to (contains/eradicates impact of) T1091 once the removable-media replication has executed and infected a target.
- T1092detects — A.8.7 requires regular automated validation of system content (d), scanning of removable media before use (f.1), and malware detection tools placed per risk assessment (g) that can surface anomalous files/commands on media, but this is scoped to malware signatures rather than arbitrary C2 payloads and does not guarantee detection of all T1092 uses.
- T1092prevents — A.8.7 explicitly requires rules/controls that prevent unauthorized software and media-borne files (a,e,f,h), plus vulnerability reduction and awareness that stop malware from being introduced via removable media, blocking the T1092 C2 vector at the transfer stage; partial because the control is scoped to malware and does not address non-malware command files or all air-gap scenarios.
- T1095detects — A.8.7 requires regular scans, monitoring for anomalous files/behavior, awareness of new malware indicators, and placement of detection tools based on risk (including at network gateways and endpoints), which can surface non-application-layer C2 that carries or exhibits malware traits, but the technique itself is protocol-level evasion often invisible to standard malware tools and the clause's scope is set by risk rather than mandating coverage of all such traffic.
- T1098detects — A.8.7 requires regular automated validation of systems, scanning for unapproved files/amendments, malware detection software with scans at multiple points, collection of new malware info, and procedures for reporting malware attacks, which can surface account manipulation artifacts (e.g. unauthorized credential changes or permission mods) when they resemble or deliver malware, but this is limited to specific vectors and does not broadly detect stealthy post-compromise account changes.
- T1098.001detects — A.8.7 requires regular automated validation of system content, malware scans on received data/email/webpages, collection of new malware intel, and monitoring for anomalous activity that can surface credential-addition actions when they match known malicious patterns or indicators, but this is limited to malware-linked cases and does not broadly detect non-malware persistence via legitimate credential APIs.
- T1098.002detects — A.8.7 requires regular automated validation of system content, scanning of emails/attachments/downloads/webpages for malware before use, collection of new malware info, and procedures for reporting malware attacks, which can surface anomalous permission grants performed via malware or malicious email but does not broadly detect the permission-addition technique itself across all vectors.
- T1098.003detects — A.8.7 requires regular automated validation of system content, malware scans at multiple layers (email, web, downloads, endpoints), collection of new malware intel, and anomaly-oriented awareness training, all of which can surface indicators of the API calls or permission changes when they match known malicious patterns or produce observable artifacts, but most instances of T1098.003 (especially policy updates or external-role additions that do not drop malware) fall outside malware-specific detection.
- T1098.004detects — A.8.7 requires regular automated validation of system software/content (d), scans of received data/email/webpages (f), collection of new malware info (n), and awareness of indicators (m), which can surface anomalous authorized_keys changes if treated as unauthorized amendments or malware-like artifacts, but this is indirect, scope-dependent, and does not systematically detect the technique's core (key addition via shell/API/config edits).
- T1098.004prevents — A.8.7's rules/controls to prevent unauthorized software (allowlisting), reduce exploitable vulnerabilities, block malicious sites, scan for malware before use, and protect against external file introduction stop many delivery vectors that would let an adversary run the commands/scripts/API calls that modify authorized_keys, but do not stop post-compromise file edits or config changes once an authorized process or session is already present.
- T1098.005detects — A.8.7 requires regular automated validation of system software/data content, scanning of received files/emails/webpages, collection of new malware intel, and procedures to detect unauthorized amendments or malware presence; this surfaces some device-registration artifacts (e.g. unexpected enrolled devices or anomalous files) when they match known malware patterns or trigger scans, but the bulk of the technique (credential abuse of legitimate MFA/Intune enrollment flows with no malware binary) sits outside malware-focused detection.
- T1098.006detects — A.8.7 requires regular automated validation of system software/content (d), malware scanning of received data/email/webpages (f), collection of new malware intel (n-o), and awareness of anomalous activity, which can surface suspicious role-binding changes or unauthorized permission modifications if they trigger malware-like indicators or integrity violations, but this is indirect, post-compromise, and limited to monitored vectors rather than reliably catching the RBAC/ABAC manipulation itself.
- T1098.007detects — A.8.7 requires regular automated validation of system software/content (d), scans of received data/email/webpages (f), collection of new malware intel (n-o), and anomaly-oriented awareness (m,l), which can surface unauthorized group changes if they involve known malware artifacts, suspicious files, or detectable post-exploitation patterns, but most of the technique (benign-looking admin commands like net localgroup/usermod with no malware) sits outside malware-focused detection.
- T1102detects — A.8.7 requires scanning for malware (including at network gateways, email, web access, and endpoints) plus awareness and procedures that can surface anomalous use of web services as C2, but this is scoped by risk assessment and does not guarantee detection of all legitimate-looking web service traffic used for relaying.
- T1102.001detects — A.8.7 requires scanning of received data, email/IM attachments, downloads, and webpages (plus awareness and anomaly procedures) which can surface dead-drop resolver activity when it traverses those vectors, but leaves a large remainder of legitimate-looking web service interactions, encrypted C2, and non-malware delivery that the clause does not instrument.
- T1102.001prevents — A.8.7 guidance (b,e,f,g) on blocking known/suspected malicious websites, protective measures for external files/software, scanning downloads/webpages, and risk-based placement of detection tools can stop some dead-drop resolver uses on common services, but leaves substantial remainder for legitimate popular sites (Google/Twitter), obfuscated content, and encrypted channels that are not blocked or detected as malicious.
- T1102.002detects — A.8.7 requires scanning for malware (including at network gateways, email, web access, and endpoints) plus awareness and procedures that can surface anomalous use of web services for C2 as malware indicators, but this is limited to malware-specific detection rather than general bidirectional web-service C2 traffic that blends with expected legitimate use.
- T1102.002prevents — A.8.7 guidance (b) on blocking known/suspected malicious websites, (c) on reducing exploitable vulnerabilities, (f/g) on multi-layer malware detection/scanning of web traffic, and (e) on protective measures for external files can stop some malware that would otherwise enable this C2 technique, but leaves the bulk of legitimate-web-service C2 (e.g. Twitter/GitHub posts, SSL/TLS cover, non-malware delivery) untouched.
- T1102.003detects — A.8.7 requires scanning of webpages, email/IM attachments, downloads, received data, and regular automated validation plus awareness of new malware sources, which can surface known malicious websites or anomalous one-way C2 patterns when they match malware signatures or indicators; this is limited to a slice because the technique uses legitimate popular services (Google/Twitter) with SSL/TLS that routinely evade detection until a specific indicator appears, and the control's scope is malware-focused rather than general anomalous C2.
- T1102.003prevents — A.8.7 guidance (b,e,f,g) on blocking known/suspected malicious websites, protective measures for external files/software, scanning downloads/webpages, and risk-based placement of detection tools can stop some (but not all) one-way Web-service C2 channels that rely on malicious or anomalous sites, leaving common legitimate services (Google/Twitter) and encrypted traffic as a large unaddressed remainder.
- T1104detects — A.8.7 requires regular automated validation of system content, scanning of received data/email/webpages for malware before use, collection of new malware intel, and placement of detection tools based on risk (including at network gateways, endpoints, and servers), which can surface multi-stage C2 loaders or downloaded second-stage RATs as malware; this is limited to malware-based staging and does not broadly detect non-malware obfuscated channels or fallback logic.
- T1105detects — A.8.7 explicitly requires regular automated scans, malware detection software placement based on risk, scanning of incoming data/email/webpages/files from external networks, and procedures to collect/verify malware intelligence, all of which surface the presence of transferred malicious tools or files (including during ingress).
- T1105prevents — A.8.7 explicitly requires controls that prevent or detect use of unauthorized software (allowlisting), malicious websites (blocklisting), and external file/software acquisition risks, which directly stop many T1105 ingress vectors such as untrusted downloads, web-based transfers, and abuse of utilities like curl/wget; it is only partial because the clause is a collection of layered practices (not a single universal mechanism), some vectors (e.g., C2 channel abuse, already-compromised lateral transfer, or insider-approved tools) remain reachable, and it depends on implementation rigor.
- T1105responds — A.8.7 explicitly requires preparing business continuity plans, isolating high-risk environments, defining procedures for recovering from malware attacks, and handling malware incidents (including training on response), which directly enacts the `responds` verb once a tool-transfer event has introduced malware; this covers only a minority slice of the broad technique (ingress of any tool/file, not necessarily malware).
- T1106detects — A.8.7 requires regular automated validation of system content, malware detection software with scanning at multiple layers (email, web, downloads, endpoints), collection of new malware intel, and awareness procedures that can surface anomalous API-driven behaviors when they match known malware patterns or produce detectable artifacts, but this is only a slice of T1106's broad legitimate and stealthy syscall usage (especially direct/assembly syscalls that evade hooks).
- T1110detects — A.8.7 requires scanning, monitoring for anomalous behavior from malware (including during auth attempts or via awareness of suspicious login patterns), and procedures to detect/report malware-related incidents, but brute-force attempts are not inherently malware and the clause's malware-specific mechanisms (scans, blocklisting, vulnerability management) only surface a minority slice of T1110 activity such as credential-dumping malware or post-compromise password spraying that triggers endpoint anomalies.
- T1110recovers — A.8.7 point j) explicitly requires business continuity plans including backups and recovery measures for recovering from malware attacks, and the T1110 prose notes that brute-force often leverages post-compromise behaviors such as credential dumping (T1003) which malware commonly performs, so recovery from that malware-enabled state restores the impacted accounts/credentials.
- T1110.001detects — A.8.7 requires malware detection tools, scans, awareness, and procedures that surface malware-related artifacts (including some that could be delivered via credential-guessing attempts on services), but does not require or perform detection of the password-guessing technique itself.
- T1110.001prevents — A.8.7 explicitly requires rules/controls that prevent unauthorized software (e.g. application allowlisting), blocking of malicious websites, vulnerability reduction, protective measures on external files/software, and malware scanning at network/email/web entry points; these directly stop the delivery vectors and common credential-guessing tools used in T1110.001 (e.g. via compromised endpoints, malicious downloads, or unauthorized management services), with a bounded remainder for exempted/legacy protocols or non-malware vectors like pure network brute-force.
- T1110.001recovers — A.8.7 point j) explicitly requires business continuity plans that include data/software backup and recovery measures for recovering from malware attacks; while the technique itself is credential guessing (not malware), successful guessing often leads to malware deployment whose impact is then recovered from via these plans, matching the recovers verb and the cp-9 vs T1486 anchor.
- T1110.002detects — A.8.7 requires regular collection and verification of new malware information plus scanning for malware (including in files received or accessed), which can surface known cracking tools or malware delivering them on the defended network, but the core technique occurs offline on adversary systems outside the target environment and is not instrumented by endpoint or network malware detection.
- T1110.003detects — A.8.7 requires regular scans, malware detection tools placed per risk assessment, awareness of malware delivery vectors, and procedures to collect/verify new malware intel, which can surface password spraying when it uses malware-infected delivery (e.g. via email attachments, malicious websites, or compromised files), but the technique itself is credential guessing over protocols with no malware payload in the base case.
- T1110.003prevents — A.8.7's malware-detection, vulnerability-reduction, unauthorized-software rules, website blocklisting, awareness training and scanning directly close some spraying vectors (e.g. malware-delivered credential dumpers, exploited vulns, malicious sites used for spraying) but do not address the dominant technique of direct low-and-slow guessing against exposed auth services.
- T1110.003recovers — A.8.7 explicitly requires preparing business continuity plans including backups and recovery measures for recovering from malware attacks (item j), which can restore state after a realized password-spraying incident that delivered malware, but this is only one narrow recovery slice of the technique itself.
- T1110.004detects — A.8.7 requires malware detection software, regular scans, awareness training, and procedures to collect/verify new malware information, which can surface credential-stuffing attempts that deliver or use malware (e.g. via email attachments, downloads, or malicious sites), but the technique itself is a pure authentication abuse with no malware component in its core definition or typical execution.
- T1110.004prevents — A.8.7's malware-focused rules (allowlisting, vulnerability reduction, web blocklisting, scanning) can stop delivery vectors that install credential-harvesting malware, but do not address the core technique of replaying already-breached username/password pairs against login services.
- T1110.004recovers — A.8.7(j) explicitly requires business continuity plans including backups and recovery measures for recovering from malware attacks; while credential stuffing is not itself malware, the control's recovery provisions (and cross-reference to 8.13) can restore access or state after a successful stuffing compromise, but this is only a slice of the technique's possible impacts.
- T1111detects — A.8.7 requires malware detection/repair software, regular scans of received data/email/webpages, awareness of new malware, and validation for unapproved files/amendments, which would surface keyloggers or malware used in most T1111 variants (especially on Windows); it does not address non-malware interception methods such as SMS provider compromise or direct service targeting.
- T1111recovers — A.8.7 point j) explicitly requires business continuity plans including backups and recovery measures for recovering from malware attacks, which would restore state after a realized T1111 malware-based interception (e.g. keylogger or SMS compromise); this is a minority slice of the technique's scope (most variants are credential theft without broad system impact needing recovery).
- T1112detects — A.8.7 requires regular automated validation of system software/data content, malware scans (including on received files, email, webpages), collection of new malware intel, and awareness of anomalous behaviors that could surface Registry modifications used for evasion/persistence when they match known malware patterns or indicators, but this is limited to malware-specific detection rather than general Registry change monitoring.
- T1112recovers — A.8.7 point j) explicitly requires business continuity plans that include data/software backup and recovery measures for recovering from malware attacks, and T1112's most common impacts (persistence, defense evasion via registry changes) are typical malware effects that such recovery can restore to a clean state.
- T1113detects — A.8.7 requires malware detection software, regular scans of systems/data/email/web content, anomaly detection for unapproved files/amendments, and awareness of malware indicators; these can surface screen-capture malware (or its artifacts) when it matches known signatures or triggers scans, but native utilities, post-compromise in-memory use, or non-malware tools fall outside malware-specific detection.
- T1114detects — A.8.7 requires scanning of email attachments and downloads for malware before use (at servers, desktops, network entry), which surfaces malicious payloads that could enable or accompany T1114 email collection but does not broadly detect the collection technique itself (e.g. credential dumping from clients/servers or forwarding rules).
- T1114prevents — A.8.7's malware detection, email scanning, website blocklisting, awareness training, and vulnerability reduction directly stop many malware-based email collection vectors (e.g., attachments, malicious links, or implants), but leave non-malware methods (e.g., credential theft, legitimate client access, or server-side forwarding) untouched.
- T1114recovers — A.8.7 explicitly requires business continuity plans including backups and recovery measures (item j) to recover from malware attacks, and T1114 can be realized via malware (e.g. on clients or servers) whose effects on collected/forwarded email data are restored by those measures.
- T1114.001detects — A.8.7 requires regular scans of files, email attachments, downloads, and systems (including local storage media) plus awareness and procedures to identify malware; this surfaces local email files if they contain or arrived with malware, but the T1114.001 technique itself is benign local file access with no malware required, so only a minority slice is caught.
- T1114.001prevents — A.8.7's malware detection, scanning of email/attachments/downloads, blocklisting of malicious sites, vulnerability reduction, and awareness directly stop many malware vectors that deliver collection tools or perform local email theft, but do not address non-malware methods such as legitimate credentialed access or direct file copy of .ost/.pst files.
- T1114.001recovers — A.8.7 point j) explicitly requires business continuity plans that include data backup and recovery measures for recovering from malware attacks; the T1114.001 technique (local collection of email files) is commonly realized via malware, so post-attack recovery of the collected or altered email data is directly addressed.
- T1114.002detects — A.8.7 requires malware detection software, regular scans of email/attachments/downloads/webpages, awareness training on identifying malware-infected emails, and procedures to collect/verify malware threat intel, which can surface some T1114.002 activity if it involves malware delivery or anomalous email access patterns, but the technique itself is credentialed collection (not malware) so most instances go undetected by these controls.
- T1114.002recovers — A.8.7 point j) explicitly requires business continuity plans that include data and software backup plus recovery measures for recovering from malware attacks; while T1114.002 is credentialed collection (not malware), the control's recovery posture would restore any exfiltrated or corrupted email data after the fact, but only covers a minority slice of the technique's impact.
- T1114.003detects — A.8.7 requires regular scans of email/attachments, webpages, received data, and systems for malware plus awareness and procedures to report malware events; this can surface anomalous forwarding rules or hidden inbox rules when they deliver or are delivered with malware, but the technique itself is rule creation (not malware) and most of the class (legitimate-looking rules, transport rules, MAPI-hidden rules without malware) sits outside malware scanning.
- T1114.003recovers — A.8.7 point j) explicitly requires business continuity plans including backups and recovery measures for recovering from malware attacks, which can restore email data or mailboxes altered by the forwarding rule when the rule was delivered via malware.
- T1115detects — A.8.7 requires regular automated validation of system content, malware scanning of received data/email/webpages, monitoring for new malware info, and anomaly-oriented placement of detection tools; these can surface clipboard-monitoring or clipboard-replacement malware as anomalous files/behavior, but the control is scoped to malware artifacts and does not broadly detect the T1115 technique itself when performed by legitimate processes or non-malware tools.
- T1119detects — A.8.7 requires regular automated validation/scans of systems and data (including received files, email attachments, and webpages) plus procedures to collect/verify malware information, which can surface automated collection activity that matches known malware patterns or anomalous file access/amendments, but this is limited to malware-tied instances rather than the broad legitimate-command/script/cloud-API collection described in T1119.
- T1119recovers — A.8.7 point j explicitly requires business continuity plans that include data and software backup plus recovery measures for recovering from malware attacks; T1119's automated collection (especially via interpreters, discovery, and lateral transfer) is a common post-malware step whose realized impact on exfiltrated or staged data is bounded by those backups and restores.
- T1123detects — A.8.7 mandates regular automated validation, malware detection/repair software with multi-layer scanning (including endpoints, email, web, and media), anomaly investigation, and awareness-driven reporting, all of which surface malware/scripts performing audio capture via APIs or peripherals.
- T1123prevents — A.8.7's malware detection, vulnerability reduction, unauthorized software prevention (allowlisting), and awareness directly stop many malware/scripts that would otherwise invoke audio APIs, but cannot prevent all (e.g. living-off-the-land binaries, already-installed authorized apps, or non-malware vectors).
- T1123recovers — A.8.7 point j explicitly requires business continuity plans that include data and software backup plus recovery measures for recovering from malware attacks, which directly restores state after audio-capture malware has run (the event-lane recovers verb).
- T1125detects — A.8.7 explicitly requires malware detection/repair software, regular automated system validation for unapproved files/amendments, scanning of received data/email/webpages, and procedures to collect/verify new malware info, all of which surface video-capture malware (explicitly named in the T1125 description and examples) before or during its operation.
- T1125prevents — A.8.7's malware detection, vulnerability reduction, unauthorized software prevention (allowlisting), awareness training, and scanning directly stop many malware samples that implement T1125 via API abuse, but cannot prevent all (e.g., living-off-the-land scripts, signed apps, or non-malware vectors) and its maintenance/BC clauses are irrelevant to prevention.
- T1125recovers — A.8.7 point j explicitly requires business continuity plans that include data and software backup plus recovery measures for malware attacks, which recovers from the realized impact of video-capture malware (e.g. restoring from clean backups after removal) even though it does not address the captured video already exfiltrated.
- T1125responds — A.8.7 explicitly requires procedures, responsibilities, training, and business continuity plans for reporting and recovering from malware attacks (l, j, m), which matches the malware-driven realization of T1125; this is a genuine but minority slice of the control whose dominant focus is on prevention and detection rather than post-compromise response.
- T1127detects — A.8.7 requires regular automated validation of software/content, scanning of received data/email/webpages, collection of new malware intel, and placement of detection tools based on risk (including at gateways/endpoints), which can surface use/abuse of trusted developer utilities when they deliver known malware patterns or anomalous files, but does not guarantee detection of novel/proxy-signed abuse that evades signatures or scanning scope.
- T1127prevents — A.8.7 explicitly requires rules/controls that prevent unauthorized software (e.g. application allowlisting per 8.19) and reducing exploitable vulnerabilities, which directly stops many signed-trusted-developer-utility proxy cases that rely on bypassing allowlisting; partial because the technique can still succeed against signed utilities that are authorized or via reputation hijacking of already-trusted processes.
- T1127.001detects — A.8.7 requires regular automated validation of system software/content (d), scans of received data/email/webpages (f), collection of new malware info (n), and risk-based placement of detection tools (g), which can surface MSBuild abuse when it matches known malware patterns, anomalous files, or known malicious indicators, but this is limited to a slice because the technique uses a legitimate signed binary with no inherent malware payload and many variants evade signature-based or non-code-aware detection.
- T1127.001prevents — A.8.7(a) and (c) explicitly require application allowlisting and vulnerability reduction that can stop unauthorized inline-task abuse of a trusted binary like MSBuild; the remainder (signed-binary bypass of allowlists, evasive delivery, and non-vulnerable configurations) is a bounded slice left by the clause's own risk-based and layered guidance.
- T1127.001recovers — A.8.7 explicitly requires business continuity plans including backups and recovery measures for malware attacks (item j), which can restore state after an MSBuild-based execution has already occurred.
- T1127.002detects — A.8.7 explicitly requires malware detection/repair software, regular automated validation/scans of systems/data/email/web content, collection of new malware intel, and risk-based placement of detection tools, which can surface ClickOnce-based proxy execution when it matches known malware patterns or anomalous files, but this is limited to post-delivery scanning rather than reliably catching all disguised or novel abuse variants.
- T1127.002prevents — A.8.7 explicitly requires malware detection/repair software, rules preventing unauthorized software (e.g. allowlisting), blocking malicious websites, vulnerability reduction, scanning of downloads/webpages/email, and awareness training — all of which close multiple abuse paths for T1127.002 (web-based delivery, disguised executables, unauthorized .NET apps); it leaves open the remainder of living-off-the-land abuse via already-permitted ClickOnce mechanisms or startup-folder persistence that does not involve malware files.
- T1127.002recovers — A.8.7 explicitly requires preparing business continuity plans including backups and recovery measures (item j) to recover from malware attacks, and T1127.002 is a malware proxy technique whose delivered payload can be cleaned up via those recovery processes.
- T1127.002responds — A.8.7 explicitly requires business continuity plans, isolating high-risk environments, procedures for recovering from malware attacks, and awareness/training on mitigating receipt/installation of malware-infected files, which together act on a malware-delivery technique once underway to contain impact and support eradication/recovery.
- T1127.003detects — A.8.7 requires regular automated validation of system software/content, malware scanning of received data/email/webpages, collection of new malware intel, and risk-based placement of detection tools, which can surface JamPlus abuse when it triggers known signatures, anomalous .jam files, or suspicious build-tool behavior in scanned contexts, but leaves substantial gaps for novel/unsigned variants, non-scanned developer workflows, and evasion via reputable-tool proxying.
- T1127.003prevents — A.8.7 explicitly requires rules/controls that prevent unauthorized software (e.g. application allowlisting per 8.19), reducing exploitable vulnerabilities, and protective measures against obtaining files/software from external networks, which directly stops JamPlus abuse as a non-approved build tool for malicious .jam scripts on Windows; this is only a slice because the clause is not specific to build utilities or subverting reputable-developer-tool whitelists and leaves other delivery vectors untouched.
- T1129detects — A.8.7 requires malware detection/repair software, regular automated validation of system content, scanning of received files/emails/webpages, and awareness of new malware, which can surface shared-module loading when it matches known malicious patterns or anomalous files, but this is limited to detectable malware instances rather than the technique itself (especially novel or non-malware uses).
- T1129prevents — A.8.7 guidance on malware detection/repair software, reducing exploitable vulnerabilities, preventing unauthorized software via allowlisting, scanning received files/media, and awareness directly stops many (but not all) malicious shared-module loads that rely on malware delivery or untrusted code execution.
- T1132detects — A.8.7 explicitly requires malware detection software, regular automated scans of data received over networks/email/web/downloads, and awareness of malware indicators, which can surface encoded C2 traffic when it carries or exhibits known malware signatures or anomalous patterns, but this is limited to malware-tainted instances rather than the encoding technique itself.
- T1132.001detects — A.8.7 explicitly requires malware detection software, regular scans of data/email/web content, anomaly validation of files/amendments, and awareness of new malware sources, which can surface encoded C2 payloads delivered via those vectors; however, it does not address detection of encoding in general C2 traffic or non-malware uses of the technique.
- T1132.002detects — A.8.7 explicitly requires malware detection software, regular scans of network data/email/webpages, anomaly validation of system content, and awareness of new malware sources, which can surface non-standard encoding in C2 traffic that is often malware-delivered; this is limited to a slice because the control is scoped to malware artifacts rather than all non-standard encodings in arbitrary C2.
- T1133detects — A.8.7 requires regular automated validation of systems, scanning of received data/email/web content, collection of new malware info, and monitoring for malware presence, which can surface indicators of T1133 when the remote service or persistence mechanism (e.g. ShadowLink binary, exposed container API, or anomalous files) exhibits detectable malware traits, but this is only a slice since many T1133 vectors rely on legitimate remote services, valid accounts, or non-malware configuration changes that malware scanners miss.
- T1134detects — A.8.7 requires regular automated validation of system software/data content, scanning of received files/emails/webpages, collection of new malware intel, and anomaly-oriented awareness training; these surface some token-manipulation artifacts (e.g. unexpected binaries or processes) but miss the dominant in-memory Windows API and AD-field mechanisms that leave no new malware on disk.
- T1134recovers — A.8.7 point j) explicitly requires business continuity plans that include backup and recovery measures for recovering from malware attacks; while token manipulation is not itself malware, the control's malware-response recovery slice (and its cross-reference to 8.13) reaches the post-attack state restoration asserted by recovers, but leaves the bulk of non-malware token-manipulation scenarios untouched.
- T1134.001detects — A.8.7 requires regular automated validation of system software/data content, scanning of received files/emails/webpages, collection of new malware intel, and monitoring for anomalous behavior that can surface token manipulation artifacts (e.g. unexpected process token changes or malware delivering the technique), but this is scoped by risk and does not guarantee detection of all in-memory token theft without malware involvement.
- T1134.001recovers — A.8.7 point j) explicitly requires business continuity plans including backups and recovery measures for recovering from malware attacks, which can restore state after a realized token-impersonation incident that leveraged malware delivery.
- T1134.002detects — A.8.7 requires monitoring, scanning, anomaly detection and awareness procedures that can surface malware-delivery or post-exploitation artifacts of token manipulation on scanned endpoints and networks, but the clause's malware-centric focus leaves most Windows token-creation events (especially those without associated malware) outside its scope
- T1134.002recovers — A.8.7 point j) explicitly requires business continuity plans that include backup and recovery measures for recovering from malware attacks, which directly matches the recovers verb even though the technique itself is not malware.
- T1134.003detects — A.8.7 requires regular automated validation of system software/data content, scanning of received files/emails/webpages, collection of new malware intel, and monitoring for anomalous behavior that could surface token-creation anomalies or related artifacts when they match known malware patterns, but this is limited to malware-linked cases and does not broadly detect non-malware token impersonation techniques.
- T1134.004detects — A.8.7 requires regular automated validation of system software/data content, scanning of received files/emails/webpages, collection of new malware info, and anomaly-oriented monitoring via malware detection tools, which can surface PPID-spoofing artifacts when they involve known malicious code, anomalous process trees, or unapproved files, but this is scoped only to malware-focused detection rather than general process-monitoring or behavioral PPID analysis.
- T1134.005detects — A.8.7 requires regular automated validation of system software/content, scanning of received data/email/webpages, collection of new malware intel, and anomaly-oriented awareness training, all of which can surface SID-History anomalies when they match known malicious patterns or produce observable effects, but the technique is an AD attribute manipulation performed with admin rights rather than classic malware delivery or execution so most instances go unseen.
- T1135detects — A.8.7 requires monitoring, scanning, anomaly detection via malware tools and awareness procedures that can surface suspicious network-share enumeration (especially if it triggers file-access or SMB anomalies), but this is only a minority slice of the technique's execution surface and does not systematically detect all discovery commands or queries.
- T1136detects — A.8.7 requires regular automated validation of system software/data content (d), scanning for malware before use (f), anomaly-oriented awareness/training (m), and collection of new malware intel (n-o); these can surface the anomalous account-creation activity or its artifacts when tied to known malware, but do not systematically detect the technique itself across all platforms and stealthy creation methods.
- T1136.001detects — A.8.7 requires regular automated validation of system software/content (d), scans of received data/email/webpages (f), collection of new malware info (n), and procedures to deal with/report malware (l), which can surface anomalous local account creation when it is performed by malware but does not broadly instrument or detect the technique itself across all its vectors (e.g. direct admin use of net user/useradd).
- T1136.002detects — A.8.7 requires regular automated validation of system software/data content, scanning for unapproved files/amendments, malware detection software with scans at multiple points, anomaly-aware placement via risk assessment, and procedures for reporting malware incidents, which can surface unauthorized domain account creation as an anomalous change or malware vector, but this is not the control's primary focus and leaves many stealthy creations undetected.
- T1136.003detects — A.8.7 requires regular automated validation of system software/content, collection of new-malware intelligence, and awareness procedures that can surface anomalous account creations when they resemble known malicious patterns or produce detectable artifacts (e.g. via scans or reported suspicious activity), but the bulk of stealthy, low-privilege cloud account creation leaves no malware artifact and is outside the clause's malware-centric scope.
- T1137detects — A.8.7 requires regular automated validation of software/content, scanning of received files/emails/webpages, collection of new malware intel, and awareness training that surfaces anomalous Office behaviors; this catches some realized T1137 artifacts (e.g. malicious add-ins or macros on scan) but leaves the bulk of Office persistence mechanisms (rules, forms, Home Page, template abuse) outside routine malware-signature or content-validation coverage.
- T1137prevents — A.8.7's malware detection, vulnerability reduction, unauthorized software rules, awareness training, and scanning of files/emails/webpages can stop some Office macro/add-in/in-rule persistence vectors before they execute or persist, but leaves many Office-native mechanisms (e.g. forms, Home Page, O365 rules) untouched as they are not inherently malware.
- T1137.001detects — A.8.7 requires regular automated validation of software/content (d), scanning of files/emails/webpages before use (f), collection of new malware info (n), and awareness of indicators (m), which can surface malicious Office template macro files or anomalous templates; this is only a slice because the technique can use registry hijacks, trusted-location bypasses, or non-file persistence that routine file-based malware scans miss.
- T1137.001prevents — A.8.7 guidance explicitly requires rules/controls preventing unauthorized software (e.g. application allowlisting per 8.19), reducing exploitable vulnerabilities, scanning for malware in files/downloads before use, and awareness training on avoiding malicious files/programs, all of which stop the macro insertion and template abuse in T1137.001 at multiple points; it is only partial because the technique can still succeed via registry hijacking, trusted locations, or policy-enabled macros that bypass these without full enforcement.
- T1137.001responds — A.8.7 point l) and m) explicitly require procedures, responsibilities, training, and awareness for reporting and recovering from malware attacks once underway, which matches the `responds` verb for containing/eradication of an in-flight persistence technique; other clauses (scanning, prevention) address different verbs, leaving this as a genuine but minority slice.
- T1137.002detects — A.8.7 requires regular automated validation of system software/content (d), scanning of received data/email/webpages (f), collection of new malware info (n), and awareness of infection indicators (m), which can surface the anomalous Registry key or DLL but only where those mechanisms are scoped to cover it; the control sets no universal requirement to monitor Registry changes or Office startup specifically.
- T1137.002prevents — A.8.7 guidance on application allowlisting, reducing exploitable vulnerabilities, scanning for malware before use, and defence-in-depth placement can stop the malicious DLL from executing on Office launch in covered environments, but leaves gaps such as unpatched Office installs, disabled scanners, maintenance bypasses, and non-malware persistence via a legitimate Office mechanism.
- T1137.003detects — A.8.7 requires scanning of email/attachments, webpages, received data, and regular validation plus awareness of new malware, which can surface the presence of malicious Outlook forms or the crafted emails that trigger them, but does not guarantee detection of the form-installation step itself or all evasive delivery variants.
- T1137.003prevents — A.8.7's malware detection, email scanning, unauthorized software rules, vulnerability reduction, and awareness directly close the vector for malicious Outlook form delivery/execution via crafted email or attachment, but leave open post-compromise form installation and non-malware persistence mechanisms.
- T1137.004detects — A.8.7 requires scanning for malware (including in email, attachments, downloads, and webpages) plus awareness/training on identifying infected content and collecting threat intel, which can surface this technique when it uses malicious HTML/URLs but only in limited observable cases (e.g. email gateway or endpoint scans) and not the persistence setup itself.
- T1137.004prevents — A.8.7's malware detection, website blocklisting, vulnerability reduction, unauthorized software rules, awareness training, and scanning of received files/emails/webpages can stop some delivery vectors or block malicious HTML/URLs used in this persistence technique, but many vectors (registry changes, direct mailbox manipulation, internal URLs, or post-compromise execution) remain outside its malware-specific scope.
- T1137.005detects — A.8.7 explicitly requires regular automated validation of system content (d), scanning of email/attachments before use at multiple points (f.2), collection of new malware information (n), and awareness of malware-infected emails (m), which surfaces malicious Outlook rules when they trigger on crafted emails or deviate from baselines; this is a genuine but minority slice of the technique (rules can be added stealthily without triggering scans or known-malware signatures, and the control is silent on mailbox/rule inspection).
- T1137.005prevents — A.8.7 guidance on malware detection/repair, email scanning, awareness training, access/change controls, and reducing exploitable vulnerabilities (including via 8.8/8.19) constrains the delivery and execution vector for malicious Outlook rules triggered by crafted email, but does not stop rule creation or persistence once the mailbox is already compromised.
- T1137.005responds — A.8.7 explicitly requires preparing business continuity plans, isolating environments, defining procedures for reporting/recovering from malware attacks, and awareness training on mitigating receipt/installation of malware-infected emails/files, which directly addresses containment, eradication and recovery once a malicious Outlook rule (triggered by crafted email) is active.
- T1137.006detects — A.8.7 requires regular automated validation of software/content, scanning of received files/emails/webpages, collection of new malware intel, and procedures to deal with/report malware; these surface add-in based persistence when the add-in is delivered as or triggers known/suspicious malware or unauthorized change, but miss many stealthy add-in registration techniques that are not file-based or flagged by typical malware signatures.
- T1137.006prevents — A.8.7 guidance explicitly requires rules/controls preventing unauthorized software (e.g. application allowlisting per 8.19), reducing exploitable vulnerabilities, scanning for malware before use, and awareness/training, all of which stop malicious add-ins from being installed/registered for persistence on a meaningful slice of cases, but not all (e.g. authorized-but-malicious add-ins or bypasses during maintenance).
- T1137.006responds — A.8.7 explicitly requires procedures, responsibilities, awareness/training, and business continuity plans to deal with and recover from malware attacks once underway, which responds to the realized persistence technique when the add-in executes malicious code on Office start.
- T1140detects — A.8.7 requires regular automated validation/scans of systems, data, email, webpages and media plus awareness and malware-info collection that can surface deobfuscation activity when it produces detectable artifacts or known malicious payloads, but the technique itself is a local utility action often invisible to signature-based detection and the clause's scope is malware-focused rather than general adversary TTPs.
- T1140prevents — A.8.7's malware detection, vulnerability reduction, unauthorized software rules, website blocklisting, scanning of received files/emails/webpages, and awareness directly stop many deobfuscation steps that rely on malware delivery or execution, but miss purely legitimate-utility or user-triggered cases (e.g. copy/type, certutil on non-malware, password entry) that do not involve detectable malware.
- T1176detects — A.8.7 requires regular automated validation of software/content, scanning of received data/emails/webpages, collection of new malware intel, and placement of detection tools based on risk (including at endpoints, gateways, and for evasive techniques), which surfaces malicious extensions in some vectors and workflows but leaves gaps for trusted marketplaces, benign-abused extensions, manual loads, and post-install blending into normal activity.
- T1176prevents — A.8.7's allowlisting (a), vulnerability reduction (c), awareness (m), and malware scanning (f) can stop malicious extension installation or execution in some vectors, but the class also covers abuse of already-installed benign extensions, marketplace trust, and post-install persistence that the control does not reach.
- T1176.001detects — A.8.7 explicitly requires regular automated validation of software/content, scanning of received data/email/webpages for malware before use, collection of new malware information, and verification of sources, which surfaces malicious browser extensions when they match known signatures or exhibit detectable behaviors during scans or validation, but this is only a slice because many installation vectors (file modification, social engineering, app-store evasion, silent background loading) are not reliably caught by signature-based or pre-use scanning alone.
- T1176.001prevents — A.8.7 guidance explicitly requires rules/controls to prevent unauthorized software (including via application allowlisting per 8.19), blocklisting of malicious sites, vulnerability reduction, protective measures on external files/software, and malware scanning of downloads/webpages — all of which stop many (but not all) installation vectors for malicious browser extensions described in the T1176.001 prose.
- T1176.002detects — A.8.7 requires regular automated validation of software/content, malware scanning of received files/media/email/webpages, collection of new malware intel, and risk-based placement of detection tools, which can surface malicious IDE extensions (or anomalous ones) when they arrive via marketplace/sideload or exhibit runtime behavior, but this is limited to scanning entry points and does not broadly instrument IDE extension loading/execution itself.
- T1176.002prevents — A.8.7's allowlisting of authorized software, vulnerability reduction, scanning of received files/downloads, and awareness/training directly stop many malicious IDE extensions from being installed or executed, but benign-extension abuse (e.g. legitimate VSCode Remote SSH for tunneling) and side-loaded extensions bypass these measures.
- T1185detects — A.8.7 explicitly requires regular automated validation/scans of systems and data (including webpages, email, downloads, and storage media), malware detection software with risk-based placement (e.g. gateways, endpoints), collection of new malware info, and procedures to deal with/report malware attacks, all of which surface browser session hijacking when it involves injected malware, extensions, or anomalous behavior.
- T1185prevents — A.8.7's malware detection/repair, vulnerability reduction (8.8), unauthorized software prevention (allowlisting), malicious website blocking, and awareness directly close the injection-of-malicious-browser-software vector named in the T1185 description and examples; they do not address the separate inherent-functionality or permission-abuse slices of the technique.
- T1185recovers — A.8.7 explicitly requires preparing business continuity plans including backups and recovery measures (item j) for recovering from malware attacks, and T1185 is realized through injected malware that can be cleaned up with such recovery procedures.
- T1185responds — A.8.7 explicitly requires preparing business continuity plans, isolating high-risk environments, defining procedures for reporting/recovering from malware attacks, and handling malware incidents (including training), which directly matches the `responds` verb once a browser-injection hijacking (a form of malware) is underway; the coverage is partial because the clause is scoped to malware vectors and does not address non-malware session hijacking or all browser-pivoting variants.
- T1187detects — A.8.7 requires regular automated validation of system content, scanning of received data/email/webpages for malware, collection of new malware intel, and monitoring for anomalous activity that can surface forced-authentication attempts when they involve malicious files, attachments, or external resource loads.
- T1187prevents — A.8.7's malware-focused rules (allowlisting, blocklisting malicious sites, vulnerability reduction, scanning of received files/emails/webpages) can block some delivery vectors like malicious attachments or .LNK/.SCF files that trigger forced auth, but do not address protocol-level SMB/WebDAV/EFSRPC behaviors, internal shares, or non-malware credential interception.
- T1187recovers — A.8.7 point j) explicitly requires business continuity plans that include data/software backup and recovery measures for recovering from malware attacks; while the core of T1187 is credential theft via forced auth (not malware delivery), the technique is frequently realized through malware vectors such as spearphishing attachments or malicious files, so the recovery clause applies to a genuine but minority slice of realizations.
- T1189detects — A.8.7 explicitly requires malware detection/repair software, regular automated scans of received data/email/webpages, collection of new malware intel, and risk-based placement (including at network gateways, endpoints, and servers) that surfaces drive-by-delivered malware before or upon execution.
- T1189prevents — A.8.7 explicitly requires controls that prevent or detect use of known/suspected malicious websites (blocklisting), reduce exploitable vulnerabilities, scan webpages for malware on access, and use defense-in-depth placement (e.g. network gateways), directly stopping the drive-by delivery and exploitation steps in most but not all cases (e.g. zero-days, evasive/encrypted delivery, or unblocked legitimate-but-compromised sites remain possible).
- T1189responds — A.8.7 explicitly requires preparing business continuity plans, isolating environments, defining procedures for reporting/recovering from malware attacks, and handling malware incidents (including training), which responds to a realized drive-by delivering malware; however, the control's dominant focus is on prevention/detection rather than active containment/eradication once the technique is underway.
- T1190detects — A.8.7 requires regular automated validation of software/data content, scanning of received data/email/webpages for malware, collection of new malware information, and placement of detection tools based on risk assessment, which can surface some exploitation attempts that deliver or trigger malware but does not broadly detect the initial exploit of a public-facing application weakness itself.
- T1190prevents — A.8.7 reduces exploitable vulnerabilities via technical vulnerability management (c), deploys detection/repair that can block some delivery vectors (f, g), and uses allowlisting/blocklisting to stop certain unauthorized code paths (a, b), but does not address the root software bug, misconfiguration, or logic flaw the technique actually exploits in a public-facing app.
- T1195detects — A.8.7 requires regular automated validation of software/content (d), scanning of received files/media/updates (f), collection of new malware info (n), and verification of reputable sources (o), which can surface supply-chain malware in delivered products or updates after receipt, but does not address pre-receipt manipulation stages like development tools, source repos, or shipment interdiction.
- T1195prevents — A.8.7 explicitly requires reducing exploitable vulnerabilities (via 8.8/8.19), scanning received files/media before use, blocking malicious sites, preventing unauthorized software, and protective measures for external files/software — all of which stop many supply-chain delivery vectors (e.g. infected updates, factory media, malicious dependencies) from executing as malware, though upstream manipulation stages (e.g. source-repo or dev-tool tampering before distribution) remain outside its reach.
- T1195.001detects — A.8.7 requires regular automated validation of software/content, scanning of received files/media/emails/webpages, collection of new-malware intel from reputable sources, and investigation of unapproved files/amendments, which surfaces some manipulated dependencies or dev tools (especially post-receipt or via known signatures), but misses pre-receipt upstream supply-chain compromise of open-source packages, typosquatting, or CI/CD pipeline components that never reach the scanned environment.
- T1195.001prevents — A.8.7 guidance on reducing exploitable vulnerabilities (via 8.8/8.19), preventing unauthorized software (allowlisting per 8.19/8.32), scanning received files/software from external networks, and awareness/training on malicious packages directly stops some dependency-supply-chain malware from executing or being introduced, but leaves the upstream compromise itself (e.g. typosquatting, abandoned-package hijacking, or malicious GitHub Actions) untouched.
- T1195.002detects — A.8.7 requires regular automated validation of software/content, scanning of received files/media/downloads/webpages, collection of new malware info from reputable sources, and investigation of unapproved files/amendments, which can surface supply-chain trojans after they reach the organization but before or during execution; this is limited to post-receipt detection slices and does not address pre-receipt manipulation of source/updates/releases.
- T1195.002prevents — A.8.7 guidance (a,c,e,f,h,n,o) directly addresses reducing exploitable vulnerabilities, scanning received files/software from external networks/media, protective measures on supply sources, and awareness of new malware, which stops many pre-delivery manipulations from reaching the consumer; it does not cover all upstream supply-chain vectors such as source-code or build-system compromise before distribution.
- T1195.003detects — A.8.7 requires regular automated validation of system software/data content, scanning of received files/media, collection of new malware intel, and verification of reputable sources, which can surface supply-chain hardware/firmware implants if they match known indicators or produce detectable anomalies post-delivery.
- T1197detects — A.8.7 explicitly requires regular automated validation of system software/data content, scanning of received files/email/webpages, collection of new malware intel, and placement of detection tools based on risk (including at network gateways, endpoints, and servers), which surfaces BITS-abused downloads, persistence jobs, or anomalous transfers as malware indicators; this is only a slice because BITS jobs are often legitimate, stealthy (no new files/registry), and evasive (e.g. encrypted), with detection depending on specific tool configuration rather than guaranteed coverage of the full technique.
- T1197prevents — A.8.7 guidance explicitly requires rules/controls that prevent unauthorized software (e.g. application allowlisting per 8.19), reducing exploitable vulnerabilities, blocking malicious sites, scanning before use of downloads/files, and defence-in-depth placement; these stop many BITS-abuse paths that rely on executing unauthorized/malicious code or ingress, but not all (e.g. abuse of legitimate updaters, built-in BITSAdmin/PowerShell, or already-permitted jobs).
- T1197recovers — A.8.7 explicitly requires business continuity plans including backups and recovery measures (item j) for recovering from malware attacks, and BITS abuse is a malware/persistence technique that can deliver or execute malicious code whose effects (e.g. modified state, exfiltrated data) can be recovered from via those plans.
- T1199detects — A.8.7 requires regular automated validation of system content, scans of received data/email/webpages, collection of new malware intel, and monitoring for anomalous behaviour that can surface indicators of compromise from a trusted third-party vector (e.g. malware delivered via the relationship), but does not broadly detect the abuse of the trusted relationship or valid accounts themselves.
- T1200detects — A.8.7 requires regular automated validation of system software/data content, scanning of received files/media/email/webpages, collection of new malware intel, and awareness of anomalies, which can surface some hardware additions (e.g. unauthorized devices or changes) but misses many stealthy or non-malware vectors like passive taps, DMA readers, or new WAPs that introduce no detectable malicious code.
- T1202detects — A.8.7 requires regular automated validation of system software/data content, scanning of received files/emails/webpages, collection of new malware intel, and awareness of anomalous indicators, which can surface some indirect execution artifacts (e.g. unexpected files or known malicious payloads) but does not target or reliably identify the stealthy abuse of living-off-the-land utilities themselves.
- T1202prevents — A.8.7's rules/controls to prevent unauthorized software (allowlisting), reduce exploitable vulnerabilities, block malicious sites, scan for malware before use, and configure detection tools per risk can stop some abuse of living-off-the-land binaries/utilities for indirect execution, but do not address the core technique of subverting interpreter restrictions via legitimate Windows/SSH utilities that are not themselves malware.
- T1202recovers — A.8.7 point j) explicitly requires business continuity plans that include backup and recovery measures for recovering from malware attacks; T1202 is a stealth technique that can deliver or invoke malware payloads, so the control's recovery provisions address post-attack state restoration for that scenario, but only as one slice of a broader malware-response set rather than a dedicated or comprehensive recovery for indirect command execution itself.
- T1203detects — A.8.7 explicitly requires regular automated validation/scans of systems and data (including email/IM attachments, downloads, webpages, and external media) plus collection of new malware information from reputable sources, which surfaces exploitation artifacts or malicious payloads delivered via client-application vulnerabilities before or after execution.
- T1203prevents — A.8.7's guidance on reducing exploitable vulnerabilities (c), preventing/detecting unauthorized/malicious software and websites (a,b,e,f), awareness (m), and scanning (d,f) stops many client-application exploit vectors before code execution, but leaves residual paths such as zero-days, user-opened malicious office docs, and unpatched third-party apps that the clause does not guarantee to block.
- T1204prevents — Application allow-listing and pre-use malware scanning of attachments, downloads, and web content directly block or detect the user-execution vectors that adversaries rely on to launch malicious payloads.
- T1204detects — A.8.7 explicitly requires regular automated validation/scans of systems and data (including email/IM attachments, downloads, webpages, and external files), malware detection software placement based on risk, collection of new malware intel, and user awareness/reporting procedures that surface execution attempts or indicators.
- T1204responds — A.8.7 explicitly requires business continuity plans, isolating environments, procedures for recovering from malware attacks, and handling protection measures that can be disabled, which directly addresses containment/eradication once user execution of malware is underway, but only for the malware-delivery slice of T1204 and not the broader social-engineering or non-malware variants.
- T1204.001detects — A.8.7 explicitly requires regular automated scans, webpage scanning for malware when accessed, scanning of received data/links/attachments before use, collection of new malware intel, and risk-based placement of detection tools (including at gateways, endpoints, and email servers), which surfaces the malicious link before or at the moment of user interaction on the dominant vectors.
- T1204.001prevents — A.8.7 guidance (b,e,f,g,m) directly blocks or warns against known/suspected malicious links and webpages before click/use, but cannot stop novel social-engineering lures or zero-day links that evade detection and require user judgment.
- T1204.001responds — A.8.7 explicitly requires procedures, responsibilities, awareness/training, and business continuity plans to deal with and recover from malware attacks once underway, which responds to the realized T1204.001 execution but only covers the malware-delivery slice of the technique (not pure social-engineering clicks that trigger non-malware follow-ons like browser exploits).
- T1204.002detects — A.8.7 explicitly requires regular automated scans, malware detection software placement based on risk, scanning of files/emails/webpages received or accessed, and procedures to collect/verify malware intelligence, all of which surface malicious files before or at the point a user would open them.
- T1204.002prevents — A.8.7 directly prevents the technique by mandating malware detection/repair software, scanning of files/emails/downloads/webpages before use, blocklisting of malicious sites, application allowlisting, vulnerability reduction, and awareness training that stops users from opening malicious files.
- T1204.002responds — A.8.7 explicitly requires procedures, responsibilities, training, and business continuity plans (including backups/recovery per 8.13) to deal with and recover from malware attacks once underway, which directly matches the `responds` verb for a technique whose payload is a malicious file.
- T1204.003detects — A.8.7 explicitly requires regular automated validation of software/content (d), scanning of received files/data/media before use (f.1), scanning of downloads (f.2), scanning of webpages (f.3), and collection/verification of new malware info (n/o), which surfaces malicious images in several common delivery vectors but leaves gaps for novel/undetected backdoors, non-scanned internal repos, and post-deployment images.
- T1204.003prevents — A.8.7 explicitly requires rules/controls to prevent unauthorized software (incl. via allowlisting), reduce exploitable vulnerabilities, scan/validate before use of external files/images, block malicious sites, and use defense-in-depth placement, which stops many (but not all) malicious-image executions in IaaS/containers.
- T1204.004detects — A.8.7 requires regular automated validation of system content, scanning of received data/email/webpages for malware before use, collection of new malware intel, and user awareness training on identifying malicious content, all of which can surface the social-engineering lures or resulting malicious payloads in T1204.004; it is not comprehensive for every delivery vector or obfuscated paste command.
- T1204.004prevents — A.8.7 explicitly prevents or detects use of known/suspected malicious websites (via blocklisting), reduces exploitable vulnerabilities, scans email/IM attachments/downloads and webpages before use, and provides user awareness training on identifying/mitigating malicious emails/files — all of which stop the social-engineering delivery vectors (phishing, drive-by sites, fake error prompts) that trigger T1204.004; it does not address user training on safe copy-paste behavior or block all possible obfuscated commands once the user is tricked.
- T1204.004responds — A.8.7 explicitly requires business continuity plans, isolating high-risk environments, procedures for recovering from malware attacks, and awareness/training on mitigating receipt/installation of malware, which together respond to (contain/eradicate impact of) a realized T1204.004 execution; this is only a slice of the full technique surface (e.g. does not address all social engineering vectors or post-execution cleanup comprehensively).
- T1204.005detects — A.8.7 requires regular automated validation of software/content, scanning of received files/downloads/webpages, collection of new malware intel, and verification of sources, which can surface malicious libraries after they reach the environment but does not guarantee detection of novel/typosquatted packages before install or use.
- T1204.005prevents — A.8.7 explicitly requires rules/controls to prevent unauthorized software (e.g. application allowlisting), reducing exploitable vulnerabilities, protective measures for files/software from external networks, and awareness training, all of which can stop users from installing malicious libraries from package managers or repos; however, it does not address supply-chain compromise of popular libraries or typosquatting at the source, leaving a genuine slice unaddressed.
- T1205detects — A.8.7 explicitly requires regular automated validation of system content, scanning of received data/email/webpages for malware before use, collection of new malware information, and placement of detection tools based on risk (including at network gateways and endpoints), which can surface the anomalous packets, magic values, or crafted sequences used in traffic signaling when they match known malware patterns or signatures, but this is limited to malware-borne cases and does not broadly detect custom/non-malware signaling implementations.
- T1205recovers — A.8.7 explicitly requires business continuity plans including backups and recovery measures for malware attacks (item j), which can restore state after a realized T1205-triggered implant or persistence but does not address all variants (e.g. WoL or network-device signaling) and is not the clause's primary purpose.
- T1205.001detects — A.8.7 requires scanning, monitoring for anomalous behaviour (via awareness, validation, and malware tools placed per risk assessment), and procedures to detect malware-related activity, which can surface port-knocking signals when they involve malware delivery, evasive packet sequences, or anomalous connections at network/email/web boundaries, but this is only a slice of the technique's custom-software, raw-socket, or non-malware implementations.
- T1205.002detects — A.8.7 requires regular scans, automated validation, anomaly investigation, awareness of malware indicators, and monitoring placement based on risk, which can surface socket filter installation or triggered backdoor activity as malware-like behavior on some platforms, but the technique's passive/low-activity/raw-socket nature is explicitly hard to detect and largely outside malware-focused scanning.
- T1205.002prevents — A.8.7's rules to prevent unauthorized software (allowlisting), reduce exploitable vulnerabilities, block malicious sites, scan incoming data/email/web content for malware before use, and use defense-in-depth placement directly stop the installation/activation of socket-filter backdoors on several vectors, but leave a remainder for in-memory/privileged raw-socket use that evades detection-based scanning and allowlisting.
- T1205.002recovers — A.8.7 point j) explicitly requires business continuity plans including backups and recovery measures for recovering from malware attacks, which would restore state after a triggered backdoor implant or shell (the technique's payload) even though the socket filter itself is not malware.
- T1207detects — A.8.7 requires regular automated validation of system software/content, malware scans at multiple layers (including network/email/web), collection of new malware intel, and awareness of evasive techniques, which can surface rogue DC registration artifacts or anomalous AD replication as malware-like behavior; this is a genuine but minority slice given the technique's focus on privileged AD schema manipulation that often evades standard malware tools.
- T1207recovers — A.8.7 point j) explicitly requires business continuity plans including backups and recovery measures for malware attacks, which can restore AD state after rogue-DC-induced changes (e.g. via offline backup/restore of directory data).
- T1210detects — A.8.7 requires regular automated validation of systems, malware scanning of received data/email/webpages, collection of new malware intel, and risk-based placement of detection tools, which can surface some exploitation attempts or post-exploit malware artifacts but does not broadly detect the vulnerability-discovery or exploitation steps of T1210 itself.
- T1210prevents — A.8.7(c) explicitly requires reducing exploitable vulnerabilities via technical vulnerability management (cross-referenced to 8.8), which directly stops many of the programming errors and unpatched services named in T1210 from being present; the remainder (zero-days, unpatched exceptions, and post-compromise discovery steps) is a bounded slice, making this a genuine but incomplete prevention.
- T1211detects — A.8.7 mandates regular automated validation of system content, malware scans at multiple layers (email, web, endpoints, gateways), collection of new malware intel, and awareness that can surface stealthy exploitation artifacts when they match known patterns or produce detectable anomalies, but does not guarantee discovery of novel or zero-day stealth techniques that leave no malware signature or obvious file change.
- T1211prevents — A.8.7 reduces exploitable vulnerabilities via technical vulnerability management (c) and deploys layered malware detection that can block some stealthy delivery vectors, but does not address exploitation of logging, monitoring, or cloud components for evasion, which is the core of T1211.
- T1212detects — A.8.7 requires regular automated validation of system software/data content, malware scanning of received files/emails/webpages, collection of new malware intel, and procedures to detect/report malware incidents, which can surface exploitation artifacts (e.g. anomalous files or post-exploit malware) but does not target the vulnerability exploitation or credential-harvesting act itself.
- T1212prevents — A.8.7(c) explicitly calls for reducing exploitable vulnerabilities via technical vulnerability management (cross-referenced to 8.8), which directly stops the programming-error exploitation step at the heart of T1212; the remainder (awareness, scanning, allowlisting, etc.) does not address credential-specific exploitation vectors such as replay attacks or Kerberos ticket forging.
- T1213recovers — A.8.7 point j) explicitly requires business continuity plans including backups and recovery measures for recovering from malware attacks, and T1213 can be realised via malware (e.g. exfiltration tools or ransomware delivered by malware that mines or encrypts repository data); this restores state after the event but only for the malware-delivery slice of the technique, leaving non-malware vectors (misconfiguration, abuse of sharing features) untouched.
- T1213.002detects — A.8.7 requires regular automated validation/scans of systems and data (including file shares and received content), malware detection software with configured placement, and procedures to collect/verify malware intelligence; these can surface anomalous files or malware delivery targeting SharePoint-stored data but do not broadly detect the post-compromise mining technique itself.
- T1213.003recovers — A.8.7 point j) explicitly requires business continuity plans that include data and software backup plus recovery measures for recovering from malware attacks; while the technique is information collection (not malware), the control's recovery slice addresses restoration of exfiltrated or corrupted repository assets after a realised event.
- T1213.004recovers — A.8.7 point j) explicitly requires business continuity plans including data/software backup and recovery measures for recovering from malware attacks; while the technique is data exfiltration (not malware), the control's recovery-from-attack language and backup provisions can restore state after such an event on a partial slice (e.g., on-premises CRM data loss).
- T1213.005detects — A.8.7 requires scanning, monitoring for malware indicators, awareness of suspicious content, and procedures to detect/report malware events; this surfaces malicious use of messaging apps when they deliver or exhibit malware (e.g. via attachments, links, or anomalous behavior), but the core technique of mining stored chat data for credentials or intel has no malware component and is invisible to these controls.
- T1213.005recovers — A.8.7 point j) explicitly requires business continuity plans including backups and recovery measures for recovering from malware attacks, which can restore data or state after a malware-enabled data mining incident on messaging apps (e.g. ransomware or exfiltration via malware)
- T1213.006detects — A.8.7 requires regular automated validation of system content, malware scans on received data/email/webpages, collection of new malware intel, and monitoring for unauthorized files/amendments, which can surface database access anomalies or malware facilitating T1213.006 but does not broadly detect database queries or mining itself.
- T1213.006recovers — A.8.7 point j) explicitly requires business continuity plans that include data and software backup plus recovery measures for malware attacks; while the technique itself is data mining rather than malware, the control's recovery provisions (and cross-reference to 8.13) address restoring state after data loss or corruption that can accompany realized database access by adversaries.
- T1216detects — A.8.7 requires regular automated validation of system software/content, malware detection software with scans (including on received data, email, webpages), anomaly investigation, and awareness of new malware indicators, which can surface proxy script abuse when it triggers observable malware-like behavior or unauthorized changes, but this is limited to cases where the proxied payload is known malware rather than the LOLBAS proxy technique itself, and depends on placement/config per risk assessment.
- T1216prevents — A.8.7 explicitly requires rules/controls that prevent unauthorized software (e.g. application allowlisting per 8.19), reducing exploitable vulnerabilities, and protective measures against obtaining malicious files, which directly stops the proxy-execution bypass of application control for many (but not all) signed-script LOLBIN cases on Windows.
- T1216.001detects — A.8.7 explicitly requires regular automated validation/scans of systems and data (including from external networks, email, webpages), malware detection software placement based on risk, collection of new malware intel, and awareness of indicators, which surfaces this signed-script abuse when it matches known patterns or anomalous remote scriptlet use, but leaves a large remainder for novel/undetected variants or non-scanned execution paths.
- T1216.001prevents — A.8.7 explicitly requires rules/controls to prevent unauthorized software (e.g. application allowlisting per 8.19), reduce exploitable vulnerabilities, block known/suspected malicious sites, scan/validate before use of remote files or downloads, and configure defense-in-depth (including at network gateways and endpoints), all of which stop the PubPrn abuse from succeeding in many but not all configurations or Windows versions.
- T1216.001recovers — A.8.7 point j) explicitly requires business continuity plans including backups and recovery measures for recovering from malware attacks, which restores state after the PubPrn technique (and its payload) has run.
- T1216.001responds — A.8.7 explicitly requires procedures, training, awareness, and business continuity plans to deal with and recover from malware attacks once underway, which matches the `responds` verb for containing/eradication actions against this signed-script proxy execution technique.
- T1216.002detects — A.8.7 requires regular automated validation of system content, scanning of received data/email/webpages, collection of new malware intel, and monitoring for anomalous behaviour that can surface abuse of a signed LOLBin such as SyncAppvPublishingServer.vbs when it deviates from baseline or exhibits known indicators; this is genuine but only a slice because the clause is scoped to malware rather than all script/proxy behaviours and many living-off-the-land executions of this exact technique leave no malware artifact.
- T1216.002prevents — A.8.7 guidance on application allowlisting (8.19), reducing exploitable vulnerabilities (8.8), blocking malicious sites, scanning for malware before use, and defence-in-depth placement can stop many abuse vectors for this signed LOLBin proxy technique, but leaves real residual paths (e.g. already-installed App-V components, non-malware delivery of the script, or evasive/encrypted payloads that bypass detection).
- T1216.002recovers — A.8.7 point j) explicitly requires business continuity plans including backups and recovery measures for recovering from malware attacks, which restores state after the T1216.002 technique (a malware delivery/execution vector) has run and caused impact.
- T1218detects — A.8.7 requires regular automated validation of system software/data content, scanning of received files/emails/webpages, collection of new malware intel, and placement of detection tools based on risk (including at gateways/endpoints), which can surface proxy execution of malicious content via trusted binaries when it matches known malware patterns or produces anomalous files/amendments; this is only a slice because the technique often uses signed/trusted LOLBINs that are not themselves malware and may evade signature-based detection.
- T1218prevents — A.8.7's allowlisting (a), vulnerability reduction (c), scanning/validation (d,f), website blocking (b), and awareness/training directly stop many signed-binary proxies (especially unapproved LOLBINs or those exploiting unpatched flaws), but native/trusted OS binaries remain usable per the technique's core description, leaving a bounded remainder.
- T1218recovers — A.8.7 point j) explicitly requires business continuity plans including backups and recovery measures for recovering from malware attacks, which restores state after T1218 has already executed malicious content via proxy binaries.
- T1218.001detects — A.8.7 explicitly requires malware detection/repair software, regular automated scans of received data/email/web content, and collection of new malware intelligence, all of which surface .chm-based payloads (a known malware delivery vector) before or during execution on Windows.
- T1218.001prevents — A.8.7 explicitly prevents malware delivery/execution vectors via allowlisting (8.19), reducing exploitable vulnerabilities (8.8), scanning before use of files/downloads/web content, blocking malicious sites, and isolating high-risk environments, which directly stops many .chm abuse paths; it is only partial because it does not eliminate all unpatched hh.exe bypasses or every possible delivery channel.
- T1218.001recovers — A.8.7 explicitly requires business continuity plans including backups and recovery measures for malware attacks (item j), which would restore state after a realized T1218.001 execution that delivered/ran malware via CHM; this is a minority slice of the control whose dominant focus is prevention/detection rather than post-impact recovery.
- T1218.002detects — A.8.7 requires regular automated validation of system content, malware detection software with scans (including on received data, email attachments, downloads, and webpages), collection of new malware info, and awareness training that surfaces suspicious files or emails; this can surface some CPL-based proxying (especially if delivered via phishing or as anomalous files), but leaves large gaps for renamed/registered DLLs, registry-based loading, and non-file behaviors that evade typical malware signatures and scans.
- T1218.002prevents — A.8.7 explicitly requires application allowlisting (8.19), reducing exploitable vulnerabilities (8.8), blocking malicious sites, scanning before use, and defence-in-depth placement that together stop many delivery vectors and execution paths for malicious CPL files, but the technique can still succeed via renamed DLLs, registry abuse, or phishing that evades the listed controls.
- T1218.002recovers — A.8.7 point j) explicitly requires business continuity plans including backups and recovery measures for malware attacks, which restores state after a realized T1218.002 execution (as with the event-lane cp-9 vs T1486 anchor); partial because the clause is scoped to malware consequences rather than every possible proxy-execution artifact.
- T1218.003detects — A.8.7 explicitly requires regular automated validation/scans of systems and data (including received files, email attachments, downloads, and webpages), malware detection software placement based on risk, collection of new malware intel, and procedures for reporting malware attacks, which can surface CMSTP abuse when it involves malicious INF/SCT/DLL files or anomalous execution, but this is only a slice because the technique can be fileless, use signed binaries, or evade scanning via encryption/obfuscation.
- T1218.003prevents — A.8.7 explicitly requires application allowlisting (8.19), reducing exploitable vulnerabilities (8.8), blocking malicious sites, scanning before use, and defence-in-depth placement that together stop many CMSTP abuse paths (malicious INF/SCT/DLL delivery and execution), but leaves a bounded remainder where signed CMSTP.exe is a permitted binary and UAC-bypass variants can still succeed.
- T1218.003recovers — A.8.7 point j) explicitly requires business continuity plans including backups and recovery measures for recovering from malware attacks, which restores state after CMSTP-abused malicious code has executed.
- T1218.003responds — A.8.7 explicitly requires procedures, responsibilities, training and business continuity plans to deal with and recover from malware attacks once underway, which matches the `responds` verb for containment/eradication of a realised technique.
- T1218.004detects — A.8.7 explicitly requires regular automated validation/scans of systems plus malware detection software that can surface anomalous files or unauthorized changes, which would catch InstallUtil abuse in many (but not all) cases such as post-execution artifacts or known malicious payloads.
- T1218.004prevents — A.8.7 explicitly requires rules/controls that prevent unauthorized software (e.g. application allowlisting per 8.19), reducing exploitable vulnerabilities, and protective measures against obtaining malicious files, all of which stop InstallUtil proxy execution and its app-control bypass in many but not all cases (e.g. signed Microsoft binaries, maintenance bypasses, or non-software vectors remain).
- T1218.005detects — A.8.7 explicitly requires regular automated scans, malware detection software placement based on risk (including at network gateways, endpoints, email servers), scanning of received data/attachments/downloads/webpages, and procedures to collect/verify new malware intel, all of which surface mshta.exe abuse of .hta/.sct payloads or anomalous script execution.
- T1218.005prevents — A.8.7 explicitly requires rules/controls that prevent unauthorized software (e.g. application allowlisting per 8.19), reducing exploitable vulnerabilities, blocking known malicious sites, scanning before use of downloads/attachments/web content, and defence-in-depth placement; these stop most mshta.exe abuse vectors that rely on untrusted HTA/JS/VBS from external sources or bypasses, but not all (e.g. already-authorized mshta use, internal malicious files, or evasive/encrypted delivery that evades detection).
- T1218.005recovers — A.8.7 point j) explicitly requires business continuity plans including backups and recovery measures for recovering from malware attacks, which directly restores state after T1218.005 has executed malicious HTA/JS/VBS code.
- T1218.005responds — A.8.7 explicitly requires procedures, training, and business continuity plans to deal with and recover from malware attacks once underway, which matches the `responds` verb for containment/eradication of a realized T1218.005 execution; partial because the clause is malware-centric while this technique is a living-off-the-land binary abuse that may or may not be classified as malware.
- T1218.007detects — A.8.7 requires regular automated validation of system content, malware detection software with scans (including of received files, downloads, webpages), collection of new malware intel, and awareness of anomalous behaviors, which can surface msiexec.exe abuse when it matches known patterns or triggers scans, but leaves many signed-native proxy executions undetected as the clause is scoped to malware rather than all living-off-the-land binaries.
- T1218.007prevents — A.8.7 explicitly requires rules/controls that prevent unauthorized software (e.g. application allowlisting per 8.19), reducing exploitable vulnerabilities, scanning before use of files/downloads, and defence-in-depth placement; these stop many (but not all) msiexec abuse paths such as unsigned/suspicious MSI or DLL payloads, while signed-native bypass and policy misconfigs remain outside its direct reach.
- T1218.007recovers — A.8.7 point j) explicitly requires business continuity plans including backups and recovery measures for recovering from malware attacks, which applies after a T1218.007 abuse has executed a malicious payload.
- T1218.008detects — A.8.7 requires regular automated validation of system software/content, malware scanning of received data/email/webpages, collection of new malware intel, and monitoring for anomalous behavior that can surface odbcconf.exe abuse as a suspicious signed-binary proxy execution, but this is scoped by risk assessment and does not guarantee detection of all variants or evasive techniques.
- T1218.008prevents — A.8.7 explicitly requires application allowlisting (a) and reducing exploitable vulnerabilities (c) plus malware detection at multiple layers, which stops many signed-binary proxy abuses like odbcconf REGSVR; the remainder is living-off-the-land abuse of a built-in signed utility that allowlisting cannot block without breaking legitimate ODBC use.
- T1218.008recovers — A.8.7 point j) explicitly requires business continuity plans including backups and recovery measures for recovering from malware attacks, which restores state after the T1218.008 technique has executed its payload.
- T1218.009detects — A.8.7 requires regular automated validation of system software/content, malware detection software with scanning (including of received data, email attachments, webpages), collection of new malware intel, and awareness of malware indicators, which can surface anomalous or malicious use of signed binaries like Regsvcs/Regasm when they trigger known patterns or behaviors, but this is limited to observable malware-like activity rather than reliably catching all proxy-execution abuse of these LOLBins.
- T1218.009prevents — A.8.7 explicitly requires application allowlisting (8.19) and reducing exploitable vulnerabilities (8.8), both of which can stop the signed LOLBin from being used to run unauthorized code, but leaves open the remainder of signed binaries that are legitimately needed on Windows endpoints.
- T1218.010detects — A.8.7 explicitly requires regular automated validation/scans of systems and data (including from networks/external sources), malware detection software with risk-based placement (e.g. gateways, endpoints), awareness of new malware, and procedures for reporting malware attacks, which can surface Regsvr32 abuse as anomalous or malicious activity; this is limited to a slice because the control is scoped to malware-focused detection rather than all proxy-execution or LOLBin behaviors, and detection depends on configuration and known signatures.
- T1218.010prevents — A.8.7 explicitly requires application allowlisting (8.19), blocking known/suspected malicious sites, reducing exploitable vulnerabilities, scanning downloads/webpages/attachments before use, and defence-in-depth placement of detection tools, all of which stop Squiblydoo-style regsvr32 proxying of remote malicious code; the remainder is signed regsvr32 abuse that evades allowlists or uses non-malicious-site vectors.
- T1218.010recovers — A.8.7 point j) explicitly requires business continuity plans including backups and recovery measures for recovering from malware attacks, which restores state after a successful Regsvr32 technique has executed malicious code.
- T1218.010responds — A.8.7 explicitly requires procedures, training, and business continuity plans to respond to and recover from malware attacks once underway, which covers the malicious code execution delivered via Regsvr32 but only as one malware vector among many, leaving non-malware uses or undetected instances as residue.
- T1218.011detects — A.8.7 explicitly requires regular automated validation/scans of systems and data (including email/IM attachments, downloads, webpages, and media), malware detection software placement based on risk, collection of new malware intel, and awareness of indicators, which surfaces many rundll32 proxying, masquerading, and script/DLL abuse behaviors when they involve files, downloads, or observable anomalies, but leaves gaps for in-memory/ordinal/obscured variants that evade file-based scanning.
- T1218.011prevents — A.8.7 explicitly requires application allowlisting (a), reducing exploitable vulnerabilities (c), scanning before use (f), and defence-in-depth placement of detection tools (g), all of which stop many (but not all) rundll32 abuse vectors such as unsigned/malicious DLLs, scripts, and external payloads; signed-system-DLL, masquerading, and ordinal-name variants remain outside the named remainder.
- T1218.011recovers — A.8.7 point j) explicitly requires business continuity plans that include data/software backup and recovery measures for recovering from malware attacks, which restores state after a T1218.011-delivered malware event; this is only partial because the control's dominant focus is on prevention/detection of malware itself rather than post-impact recovery.
- T1218.011responds — A.8.7 explicitly requires procedures, training, awareness, and business continuity plans to respond to and recover from malware attacks (points l, j, m), which would be invoked once rundll32.exe has already executed malicious code as malware; this is only a slice of the technique's full scope (e.g., non-malware uses, pre-execution evasion via masquerading or allowlist abuse).
- T1218.012detects — A.8.7 explicitly requires regular automated validation/scans of systems (including for unapproved files/amendments), malware detection software with scans at multiple layers (email, web, endpoints, network), collection of new malware intel, and awareness of evasive techniques, which can surface verclsid.exe abuse as anomalous or malicious activity; however, this is limited to what the configured scanners and intel sources actually cover rather than all instances of the technique.
- T1218.012prevents — A.8.7 explicitly requires application allowlisting (8.19), reducing exploitable vulnerabilities (8.8), blocking malicious sites, scanning before use, and defence-in-depth placement of detection tools, all of which stop many but not all signed-native LOLBIN proxy executions that abuse verclsid.exe.
- T1218.012recovers — A.8.7 point j) explicitly requires business continuity plans including backups and recovery measures for malware attacks, which restores state after the technique has run and delivered its payload.
- T1218.013detects — A.8.7 explicitly requires malware detection/repair software, regular automated validation/scans of systems/data/email/web content, collection of new malware intel, and risk-based placement of tools (including at network gateways/endpoints), which surfaces many instances of mavinject.exe abuse when it delivers or exhibits known malware behavior, but leaves gaps for novel/undetected variants, evasive encrypted delivery, or non-malware injection that evades signature/heuristic scanning.
- T1218.013prevents — A.8.7 explicitly requires application allowlisting (8.19), reducing exploitable vulnerabilities (8.8), blocking malicious sites, scanning before use, and defence-in-depth placement of detection tools; these stop many (but not all) abuse paths for a signed LOLBin like mavinject.exe that can be launched from authorized locations or via evasive/encrypted delivery.
- T1218.013recovers — A.8.7 point j) explicitly requires business continuity plans including backups and recovery measures for recovering from malware attacks, which directly restores state after a realized T1218.013 injection (a malware delivery vector).
- T1218.013responds — A.8.7 explicitly requires procedures, training, and business continuity plans to deal with and recover from malware attacks once underway, which matches the `responds` verb for containing/eradication of a realized technique.
- T1218.014detects — A.8.7 explicitly requires regular automated validation/scans of systems (including for unapproved files/amendments), malware detection software placed per risk assessment (network gateways, endpoints, servers), scanning of received data/email/web content, and procedures for reporting malware — all of which surface MMC abuse when it introduces or exhibits detectable malicious .msc/CLSID behavior, but this is only a slice because the technique can be crafted to evade signature-based detection or run without triggering file-based scans.
- T1218.014prevents — A.8.7's allowlisting (8.19), vulnerability reduction (8.8), unauthorized software rules, and malware scanning/detection before execution close some vectors for malicious .msc files or snap-ins but leave open signed binaries, custom CLSID registry abuse, and evasive delivery that bypass detection.
- T1218.014recovers — A.8.7 explicitly requires business continuity plans including backups and recovery measures (j) to recover from malware attacks, and the technique's primary example (wbadmin.msc deleting backup catalog) directly produces a recoverable state via those measures; partial because the technique can also deliver arbitrary CLSID payloads whose effects (e.g. non-backup-related persistence or exfil) are not addressed by recovery.
- T1218.014responds — A.8.7 explicitly requires procedures to deal with malware attacks including reporting and recovering, plus business continuity plans for recovery from malware attacks; this bounds an in-progress MMC-abuse event that has already delivered/activated malware, but only for the malware-delivery slice of the technique and not the pure proxy-execution or .msc-abuse paths that do not involve malware files.
- T1218.015detects — A.8.7 mandates regular automated validation of system content, malware detection software with scans (including on received data, email, webpages), awareness of new malware, and procedures to deal with/report malware attacks, which can surface Electron-based abuse when it manifests as anomalous files, processes, or known malware signatures; however, the control's scope is malware-focused and does not broadly instrument for Electron-specific mechanics like JS injection or disguised child-process abuse of legitimate apps.
- T1218.015prevents — A.8.7's malware detection, vulnerability reduction, unauthorized software rules, awareness, and scanning can stop some Electron abuse vectors (e.g. malicious JS or downloads), but the technique's core abuse of legitimate Electron app mechanics and child-process execution is not reached by these measures.
- T1218.015recovers — A.8.7 explicitly requires preparing business continuity plans including backups and recovery measures (item j) to recover from malware attacks, and this technique is a malware-delivery vector that can produce malicious code execution or persistence whose effects are restored-from via those plans.
- T1219detects — A.8.7 requires regular automated validation of system content, malware detection software with scans (including of received data, email, webpages), collection of new malware intel, and procedures to deal with/report malware attacks, which can surface post-compromise RAT installation or anomalous remote sessions as malware or unapproved software, but this is scoped only to malware-focused mechanisms and does not broadly instrument for legitimate RAT abuse or EDR feature misuse.
- T1219prevents — A.8.7's malware detection, unauthorized software rules (allowlisting), vulnerability reduction, and scanning can block some RAT installation vectors that qualify as malware or unauthorized software, but most legitimate RAT usage (post-compromise abuse of built-in or approved tools for C2) is untouched.
- T1219responds — A.8.7 explicitly requires business continuity plans, isolating high-risk environments, procedures for recovering from malware attacks, and handling malware incidents (including when RATs are delivered or function as malware components), which constitutes a response once the technique is underway; however, its core focus is malware-specific detection/repair rather than general RAT C2 sessions, leaving a substantial remainder unaddressed.
- T1219.001detects — A.8.7 requires regular automated validation of software/content, malware scanning of downloads/received files/webpages, collection of new malware intel, and anomaly-oriented awareness training, all of which can surface IDE tunneling when it involves known malicious extensions, suspicious downloads, or observable behavioral anomalies, but most legitimate IDE tunneling blends with approved dev tools/workflows and evades signature/behavioral detection focused on classic malware.
- T1219.001prevents — A.8.7's allowlisting (8.19), unauthorized-software prevention, vulnerability reduction, and malware-detection rules can block installation/execution of IDE tunneling tools or extensions when treated as unauthorized or malicious, but legitimate IDE remote features and developer workflows create a large unblocked slice
- T1219.002detects — A.8.7 requires regular automated validation of system content, malware detection software with scans (including of received data, email, webpages), collection of new malware intel, and awareness of anomalous behaviors, which can surface use of unauthorized or suspicious remote desktop tools when they match known malware patterns or violate allowlists, but does not broadly detect legitimate RMM software used post-compromise as C2 since it is not inherently malicious.
- T1219.002prevents — A.8.7 explicitly requires rules/controls that prevent or detect unauthorized software via application allowlisting (8.19), which directly stops installation/execution of many non-approved RMM tools used for this technique; however, it is only partial because the technique routinely abuses already-approved legitimate desktop support software (e.g. TeamViewer, AnyDesk, built-in remote features of Zoom/Chrome) that application control would permit.
- T1219.003detects — A.8.7 requires regular automated validation of system software/data content, scanning of received files/media/email/webpages, collection of new malware intel, and risk-based placement of detection tools (including at network gateways and endpoints), which can surface anomalous hardware-installed remote access tools or their traffic as suspected malware or unauthorized changes; this is limited to a slice because the technique uses legitimate hardware that peripheral policies may explicitly allow, evades software scanners via physical installation/encryption, and is not the primary malware focus of the control.
- T1220detects — A.8.7 explicitly requires malware detection software, regular automated validation/scans of files (including received data, email attachments, downloads, and webpages), collection of new malware info from reputable sources, and risk-based placement of detection tools, which would surface many XSL-embedded script abuses (especially file-based or network-delivered ones) but leaves gaps for novel/encrypted variants, non-malware-classified living-off-the-land abuse of built-in tools like wmic/msxsl, and detection scope set by risk assessment rather than universal coverage.
- T1220prevents — A.8.7 explicitly requires rules/controls that prevent unauthorized software (e.g. application allowlisting), reducing exploitable vulnerabilities, blocking malicious websites, scanning before use of received files/downloads/web content, and defence-in-depth placement of detection tools; these directly stop the msxsl.exe/wmic abuse vectors and embedded-script execution on Windows in most but not all cases (e.g. local already-present trusted binaries, arbitrary extensions, or evasive/encrypted delivery remain possible).
- T1220recovers — A.8.7 explicitly requires preparing business continuity plans including backups and recovery measures specifically for recovering from malware attacks, and T1220's core effect is malware-driven code execution that can be restored from after the fact.
- T1220responds — A.8.7 explicitly requires business continuity plans, isolating high-risk environments, defined procedures for reporting/recovering from malware attacks, and awareness training on handling infected files — all of which constitute containment/eradication actions once a malware-driven technique like T1220 is underway.
- T1221detects — A.8.7 explicitly requires regular automated validation/scans of software and data content (including received files, email attachments, downloads, and webpages) plus procedures to collect/verify malware information, which surfaces template-injection documents that fetch malicious payloads; this is limited to a slice because the technique can evade static detection until fetch time, operates via legitimate template mechanisms, and is not guaranteed by awareness or configuration guidance alone.
- T1221prevents — A.8.7 guidance on preventing unauthorized software (allowlisting), blocking malicious websites, reducing exploitable vulnerabilities, scanning received files/emails/web content before use, and awareness directly stops many delivery vectors and the initial execution of fetched template payloads on Windows endpoints.
- T1221recovers — A.8.7 point j) explicitly requires business continuity plans including data/software backup and recovery measures for recovering from malware attacks, which directly restores state after T1221 delivers and executes its concealed payload.
- T1221responds — A.8.7 explicitly requires business continuity plans, isolating high-risk environments, procedures for recovering from malware attacks, and awareness/training on mitigating receipt/installation of malware-infected files — all of which constitute containment/eradication/response once a realized malware-delivery technique is underway, but only for the malware-payload slice and not the forced-authentication or static-document-modification aspects.
- T1222detects — A.8.7 requires regular automated validation of software/data content, scanning of received files/emails/webpages, collection of new malware info, and procedures for reporting malware attacks, which can surface permission modifications performed by malware (especially ransomware) but does not broadly detect the standalone T1222 technique across non-malware scenarios or all platforms.
- T1222.001detects — A.8.7 requires regular automated validation/scans of systems (d,f), malware detection software placement based on risk (g), collection of new malware intel (n,o), and awareness of anomalous files, which can surface permission-modifying tools or unauthorized changes after the fact on scanned endpoints; this is a genuine but minority slice of the technique's execution surface (e.g. not all icacls/PowerShell use is malware-flagged, and many modifications occur outside scanned critical systems or before detection tooling acts).
- T1222.002detects — A.8.7 requires regular automated validation of system software/data content, scanning for unapproved files/amendments, malware detection software with scans at multiple layers, collection of new malware intel, and procedures for reporting malware incidents, which can surface anomalous permission changes (e.g. via unauthorized file mods or post-malware cleanup) but only as a minority slice of the broad technique.
- T1480.001detects — A.8.7 requires regular automated validation of system software/data content, scanning for unapproved files/amendments, malware detection software with scans at multiple layers (email, web, endpoints, network), and procedures to collect/verify new malware info, which can surface environmental keying artifacts (e.g. anomalous encrypted payloads or environment-specific checks) in some but not all cases.
- T1480.002detects — A.8.7 requires malware detection software, regular scans of files/emails/webpages/media, anomaly validation of system content, and awareness of new malware indicators; these can surface mutex-based single-instance checks when the mutex file or creation is observable during scans or monitoring, but do not guarantee detection of the technique itself (especially in-memory or evasive cases).
- T1484detects — A.8.7 requires regular automated validation of system software/content (d), scans of received data/email/webpages (f), collection of new malware info (n), and verification of reputable sources (o), which can surface indicators of malicious GPO/trust/federation changes if they introduce detectable malware artifacts, but most T1484 abuse vectors (e.g. policy tweaks enabling rogue DCs or forged tokens without dropping malware) fall outside malware-focused detection.
- T1484recovers — A.8.7 point j) explicitly requires business continuity plans that include backup and recovery measures for recovering from malware attacks; while T1484 is not itself a malware technique, several of its abuse examples (malicious GPO/scheduled task, rogue DC) can be realized via malware delivery and the control's recovery provisions therefore address the post-impact state for that slice
- T1484.001detects — A.8.7 requires regular automated validation of system software/data content, scanning of received files/emails/webpages, collection of new malware info, and procedures for reporting malware attacks; these can surface anomalous GPO file changes or malicious payloads delivered via GPO abuse as malware indicators, but miss native AD permission changes or non-malware GPO modifications.
- T1484.001prevents — A.8.7's change management, access controls, vulnerability reduction, unauthorized software prevention (allowlisting), and malware scanning can block some delivery vectors or malicious payloads used to modify GPOs, but do not stop an already-privileged adversary from directly editing SYSVOL files or GPO settings.
- T1484.001recovers — A.8.7 point j) explicitly requires business continuity plans including backups and recovery measures for recovering from malware attacks; while GPO modification is not itself malware, the technique is commonly used to deliver/persist malware (T1484.001 prose links to Disable or Modify Tools, Ingress Tool Transfer, etc.) so the recovery slice applies but leaves the bulk of non-malware GPO abuse and non-restore impacts (e.g. privilege escalation, backdoors) unreached.
- T1484.002detects — A.8.7 requires regular automated validation of system software/content (d), scanning of received data/email/webpages (f), collection of new malware info (n), and awareness of anomalous indicators (m), which can surface trust modifications that introduce or resemble malicious code or unauthorized changes; this is limited to a slice because most trust manipulations (e.g., adding a federated IdP or altering claim rules) are configuration changes rather than malware and fall outside scanning or malware-specific detection.
- T1485detects — A.8.7 explicitly requires malware detection software, regular automated scans for unapproved files/amendments, scanning of incoming data/email/web content, collection of new malware intel, and verification of sources, which surfaces many (but not all) data-destruction malware instances before or during execution.
- T1485prevents — A.8.7's malware detection/repair, allowlisting, vulnerability reduction, website blocklisting, scanning, and awareness directly stop many malware-borne data-destruction payloads from executing or reaching targets, but the technique can also be performed manually or via legitimate admin tools without malware, which the control does not address.
- T1485recovers — A.8.7 explicitly requires business continuity plans including data/software backup and recovery measures (item j) to recover from malware attacks that can perform data destruction.
- T1485responds — A.8.7 point j explicitly requires business continuity plans (with backups and recovery measures) to recover from malware attacks, and T1485 is commonly realized by malware; this bounds impact once underway but does not address non-malware data destruction vectors or full eradication of the actor.
- T1485.001detects — A.8.7 requires regular automated validation of system content (d), scans of data received over networks or storage media (f), collection of new malware information (n), and procedures for reporting malware incidents (l), which can surface anomalous lifecycle policy changes or mass-deletion artifacts when they align with known malware behaviors or trigger integrity scans, but this is limited to a minority slice as the technique is a permissioned admin API call with no inherent malware payload or file-based indicator.
- T1485.001recovers — A.8.7 explicitly requires business continuity plans including online/offline backups and recovery measures (j) to restore from malware attacks that destroy data, which directly recovers state after lifecycle-triggered deletion performed for extortion or indicator removal.
- T1486detects — A.8.7 explicitly requires malware detection/repair software, regular automated scans of files/data/email/webpages, collection of new malware intel, and validation for unapproved changes — all of which surface ransomware (the dominant form of T1486) before or during execution on the named platforms.
- T1486prevents — A.8.7's malware detection, allowlisting, vulnerability reduction, website blocklisting, scanning before use, and awareness directly stop many ransomware delivery vectors and the malware's own execution, but the technique can still succeed via legitimate encryption tools, already-present malware, or post-compromise native OS mechanisms that bypass the malware-specific controls.
- T1486recovers — A.8.7 explicitly requires business continuity plans including backups and recovery measures (point j) to restore from malware attacks that encrypt data, matching the T1486 impact; mostly because the control's recovery is scoped to malware vectors while T1486 can also use non-malware means such as legitimate cloud encryption APIs.
- T1486responds — A.8.7 explicitly requires preparing business continuity plans (j), isolating environments (k), defining procedures for reporting/recovering from malware attacks (l), and awareness/training on mitigating malware (m), which together constitute incident response once a ransomware encryption event is underway.
- T1489detects — A.8.7 requires regular automated validation/scans of systems (especially critical ones), malware detection software with scans at multiple layers, anomaly investigation, and awareness-driven reporting of suspicious activity, which can surface service-stopping malware or its precursors but does not broadly instrument or detect the native service-stop technique itself (especially in cloud, via admin APIs, or non-malware vectors).
- T1489recovers — A.8.7 explicitly requires preparing business continuity plans including backups and recovery measures for malware attacks (item j), which can restore service availability after a malware-induced stop/disable (as in WannaCry examples) but does not address non-malware service stops or cloud API disables.
- T1490detects — A.8.7 explicitly requires regular automated validation/scans of systems (esp. critical ones), malware detection software with scans at multiple layers (email, web, storage, network entry), collection of new malware intel, and awareness of indicators, which surfaces many T1490 precursors or artifacts (e.g. unauthorized changes to recovery files, known ransomware tools, anomalous file deletions) but leaves real gaps for stealthy or non-malware delivery methods named in the T1490 prose.
- T1490recovers — A.8.7 explicitly requires preparing business continuity plans that include all necessary data/software backup (online and offline) plus recovery measures to recover from malware attacks, directly addressing restoration after T1490 has deleted/disabled recovery features (see event-lane anchor A.8.13 vs T1490 and A.8.13 vs T1486).
- T1490responds — A.8.7 explicitly requires preparing business continuity plans, isolating environments, defining procedures for reporting/recovering from malware attacks, and protecting against malware introduction during maintenance that can bypass controls, all of which constitute containment/eradication response once a malware-driven T1490 is underway.
- T1491recovers — A.8.7 point j) explicitly requires business continuity plans including backups and recovery measures for malware attacks; while T1491 is not malware-driven, the control's recovery-from-integrity-loss provisions (data/software restore) address post-defacement state restoration in a minority of scenarios where malware was the delivery vector.
- T1491.001detects — A.8.7 requires regular automated validation of system software/data content, scanning for unapproved files/amendments, malware detection software with scans at multiple layers, and procedures to deal with/report malware attacks, which can surface defacement changes (especially file-based ones like wallpaper or web content) as anomalies or malware artifacts, but this is limited to specific vectors and does not broadly cover all internal defacement forms like login message edits.
- T1491.001recovers — A.8.7 clause j) explicitly requires business continuity plans including backups and recovery measures for recovering from malware attacks, and T1491.001 is commonly realized via destructive malware that replaces or alters files (e.g. desktop wallpaper, web content); this restores state post-impact but only for the malware-delivery slice of the technique, not non-malware vectors or non-restorable changes like login messages.
- T1491.001responds — A.8.7 point j explicitly requires business continuity plans for recovering from malware attacks (with backups and recovery measures), and internal defacement is commonly delivered by destructive malware; this is a response action once the technique has run, but the clause is scoped only to malware vectors and does not address non-malware defacement methods.
- T1491.002detects — A.8.7 requires regular automated validation of system software/content, scanning of received data/webpages/emails, collection of new malware intel, and verification of sources, which can surface defacement (as unauthorized change or anomalous content) on scanned external-facing systems but only where those exact mechanisms are placed and configured to inspect the defaced asset or its delivery vector.
- T1491.002recovers — A.8.7 point j) explicitly requires business continuity plans including backups and recovery measures for malware attacks; while T1491.002 is not itself a malware technique, the control's recovery provisions can restore defaced external assets (e.g. website content) after a realized defacement event.
- T1495detects — A.8.7 explicitly requires regular automated validation of system software/content (d), scanning of received data/media/email/webpages (f), collection of new malware info (n), and placement of detection tools based on risk (g), which can surface known firmware-targeting malware before or during delivery but does not broadly detect post-compromise firmware corruption itself.
- T1495prevents — A.8.7's malware detection/repair, vulnerability reduction, unauthorized software prevention, awareness, and scanning directly stop many malware-based firmware corruption vectors (e.g. via email, downloads, or exploited vulns), but firmware flashing often uses signed/authorized tools or physical/maintenance paths outside standard malware delivery, leaving a bounded remainder.
- T1495recovers — A.8.7 explicitly requires business continuity plans including backups and recovery measures (item j) to restore from malware attacks, which can encompass firmware corruption delivered via malware; however, this is only one slice of the control whose dominant focus is prevention/detection rather than post-corruption recovery, and firmware-specific restoration (e.g. from hardware-protected sources) is not addressed.
- T1496detects — A.8.7 requires regular automated validation of system content, malware scanning of received data/email/webpages, collection of new malware intel, and anomaly-oriented awareness training, all of which can surface cryptomining or proxying artifacts after they are present; this is a genuine but minority slice of the broad technique (especially non-malware forms such as legitimate SaaS abuse or bandwidth selling).
- T1496recovers — A.8.7 clause j) explicitly requires business continuity plans including backups and recovery measures for malware attacks, which can restore availability after resource-hijacking malware (e.g. cryptominers) has run its course.
- T1496.001detects — A.8.7 explicitly requires regular automated scans, malware detection software placement based on risk, scanning of received data/email/webpages, collection of new malware intel, and procedures to detect unauthorized software/amendments — all of which surface compute-hijacking malware (including cryptominers) on the listed platforms before or during execution.
- T1496.001prevents — A.8.7's malware detection/repair, vulnerability reduction, unauthorized software prevention (allowlisting), website blocklisting, scanning of downloads/emails/webpages, and awareness directly stop many common crypto-mining malware delivery and execution vectors before resource hijacking occurs, but not all (e.g. non-malware-based compute abuse, post-compromise legitimate binaries, or evasion of the listed controls).
- T1496.001recovers — A.8.7 explicitly requires business continuity plans including backups and recovery measures (j) to restore from malware attacks that consume resources, directly addressing post-impact restoration for compute hijacking malware.
- T1496.001responds — A.8.7 explicitly requires preparing business continuity plans, isolating high-impact environments, defining procedures for reporting/recovering from malware attacks, and handling malware incidents (including training), which responds to an in-progress compute-hijacking malware event once underway; this is bounded by the clause's malware-specific focus and does not address non-malware hijacking vectors or full eradication in all cases.
- T1496.002detects — A.8.7 mandates regular automated validation/scans of systems (including for unapproved files/amendments), malware detection software with network/email/web scanning, collection of new malware intel, and awareness of anomalous behaviors, all of which surface bandwidth-hijacking malware or botnet activity on covered platforms.
- T1496.002prevents — A.8.7's malware detection, vulnerability reduction, unauthorized software prevention (allowlisting), malicious site blocking, and awareness directly stop the malware-driven bandwidth hijacking/botnet/proxyjacking vectors in the technique, but not the non-malware scanning or proxyjacking behaviors that do not rely on malware installation.
- T1496.002recovers — A.8.7 explicitly requires business continuity plans including backups and recovery measures for malware attacks (item j), which can restore availability and bandwidth after a hijacking incident that used malware, but this is only one vector among several non-malware paths in the technique (proxyjacking, scanning) and does not address all impacts such as reputational damage.
- T1496.002responds — A.8.7 explicitly requires procedures, responsibilities, training, and business continuity plans (including backups/recovery per 8.13) to deal with and recover from malware attacks; because the technique is realized via malware on co-opted systems, these directly address the realized malware event once underway, though only a slice of the broader bandwidth-hijacking scenarios (non-malware proxyjacking or scanning) and not full containment/eradication.
- T1496.003detects — A.8.7 requires regular automated validation of system content, scanning of received data/email/webpages for malware, collection of new malware information, and anomaly-aware placement of detection tools; this surfaces anomalous SMS-pumping traffic that manifests as unexpected volume or patterns in messaging infrastructure (especially when it involves web forms or external services), but the control is scoped to malware rather than general abuse/fraud, leaving most of the technique outside its detection envelope.
- T1496.003recovers — A.8.7 point j) explicitly requires business continuity plans including backups and recovery measures for malware attacks; while SMS pumping is a fraud/availability technique rather than classic malware, the control's recovery-from-attack language reaches the realized impact (overwhelmed channels, inflated costs) in a limited way via the named continuity provisions.
- T1496.004detects — A.8.7 requires regular automated validation of systems, scanning of data/emails/webpages for malware, collection of new malware intel, and anomaly-oriented placement of detection tools; this surfaces some hijacking (e.g. anomalous email/SMS volume or unexpected LLM proxy use that triggers malware-like signatures or behavioral alerts) but leaves the bulk of SaaS credential abuse, service enablement, and non-malware resource exhaustion undetected.
- T1496.004recovers — A.8.7 point j) explicitly requires business continuity plans including backups and recovery measures for malware attacks; while the technique is SaaS abuse rather than classic malware, the control's recovery provisions (and cross-reference to 8.13) address post-impact restoration of availability and service state in a bounded slice of the technique's effects.
- T1497detects — A.8.7 explicitly requires regular automated validation of software/data content, scanning for malware (including new variants via collected intel), and placement of detection tools based on risk, which surfaces evasion artifacts or altered behaviors in analysis/sandbox environments as part of malware checks, but only as a minority slice of the broad technique (most evasion checks target non-malware artifacts or occur pre-execution).
- T1497prevents — A.8.7 guidance on reducing exploitable vulnerabilities, application allowlisting, blocking malicious sites, scanning for malware before use/execution, defence-in-depth placement, and awareness/training can stop many common VME/sandbox detection artifacts and behaviors from succeeding, but leaves real residual (e.g. timing loops, legitimate-user-activity checks, novel/encrypted evasion not caught by signatures or baselines).
- T1497.001detects — A.8.7 requires regular automated validation of system software/data content, scanning for unapproved files/amendments, malware detection software with scans at multiple points, and procedures to collect/verify new malware info, which can surface sandbox/VME artifacts or anomalous checks as part of malware discovery, but this is not its core purpose and leaves most specific system-check behaviors (e.g., registry, hardware, WMI queries) outside its defined scope.
- T1498detects — A.8.7 requires regular automated validation of system content, scanning of received data/email/webpages for malware, collection of new malware intel, and placement of detection tools based on risk (including at network gateways), which can surface some malware-driven botnets or anomalous traffic patterns used in DDoS but does not broadly detect bandwidth-exhausting Network DoS itself.
- T1498recovers — A.8.7 point j) explicitly requires business continuity plans including backups and recovery measures for recovering from malware attacks; while T1498 is a bandwidth-exhaustion availability attack (not a malware infection), the control's recovery-from-attack language and cross-reference to 8.13 still reach the post-impact restoration slice of degraded availability, leaving most non-malware DoS cases outside its scope.
- T1498.001detects — A.8.7 requires regular automated validation of system content, scanning of received data/email/webpages, collection of new malware intel, and placement of detection tools based on risk (including at network gateways), which can surface anomalous flood traffic or malware used to recruit botnets, but does not guarantee detection of high-volume direct floods especially when encrypted, distributed, or using non-malware vectors.
- T1498.001recovers — A.8.7 explicitly requires preparing business continuity plans including backups and recovery measures for recovering from malware attacks, which directly restores availability after a flood launched via malware-compromised botnets.
- T1498.002detects — A.8.7 requires scanning, monitoring for anomalous behavior via malware tools and awareness procedures that can surface some reflection/amplification traffic patterns (especially when malware/botnet delivery is involved), but the control is scoped to malware protection and does not broadly detect pure network protocol reflection DoS.
- T1498.002recovers — A.8.7 clause j) explicitly requires business continuity plans including backups and recovery measures for recovering from malware attacks, and reflection amplification is a network DoS technique that can be launched via malware (e.g. botnet); this restores state post-impact but does not address non-malware vectors or full availability restoration in all cases.
- T1499detects — A.8.7 requires regular automated validation/scans of systems plus malware detection software that surfaces anomalies (including unapproved files/amendments), which can detect some endpoint resource exhaustion or crash conditions caused by malware but does not broadly detect non-malware DoS techniques such as botnets, spoofing or application-layer flooding.
- T1499recovers — A.8.7 explicitly requires preparing business continuity plans including backups and recovery measures for malware attacks (item j), which can restore availability after a malware-induced endpoint DoS (e.g. resource exhaustion or crash from malicious code), but this is only one limited slice of the broad technique that also covers non-malware vectors such as botnets, spoofing, and application-layer exhaustion.
- T1499responds — A.8.7 point j) explicitly requires business continuity plans for recovering from malware attacks (with backups and recovery measures), which bounds impact once a malware-delivered Endpoint DoS is underway; the remainder of T1499 vectors (non-malware resource exhaustion, botnets, spoofing) are outside its malware-specific scope.
- T1499.001detects — A.8.7 requires regular automated validation of system software/data content, scanning of received data/email/webpages, collection of new malware info, and monitoring for anomalous behavior that can surface resource-exhaustion symptoms or known malware patterns, but this is scoped to malware rather than generic OS-exhaustion floods like SYN/ACK floods which are not malware.
- T1499.001recovers — A.8.7 explicitly requires business continuity plans including backups and recovery measures for malware attacks (item j), but the technique is a network flood exhausting OS state/tables rather than malware infection, so recovery credit is limited to generic continuity overlap without addressing the flood itself.
- T1499.002detects — A.8.7 requires malware detection software, regular scans, anomaly validation of systems/data, awareness of malware indicators, and collection of new malware intel, which can surface some volumetric/renegotiation floods that exhibit known malware-like patterns or anomalous resource use, but the bulk of pure service-exhaustion DoS (especially non-malware variants) falls outside malware-specific detection.
- T1499.002recovers — A.8.7 clause j) explicitly requires business continuity plans including backups and recovery measures for recovering from malware attacks, but T1499.002 is a resource-exhaustion DoS (not malware), so only the generic continuity/recovery slice applies.
- T1499.003detects — A.8.7 requires regular automated validation of system software/data content, scanning of received data/email/webpages, collection of new malware info, and monitoring for anomalous behavior that can surface resource-exhaustion effects from application-targeted floods, but this is scoped to malware vectors and does not broadly instrument or guarantee detection of non-malware DoS floods exploiting resource-intensive app features.
- T1499.003recovers — A.8.7 point j) explicitly requires business continuity plans including backups and recovery measures for recovering from malware attacks; while T1499.003 is a resource-exhaustion DoS (not malware), the control's recovery planning and isolation provisions (k) can restore availability after such an availability event, but this is only a slice of the technique's surface rather than its dominant form.
- T1499.004detects — A.8.7 requires regular automated validation of software/data content, scanning for malware before use, and procedures to collect/verify malware information, which can surface exploitation artifacts that match known malware but does not broadly detect zero-day or non-malware exploitation crashes.
- T1499.004prevents — A.8.7 reduces exploitable vulnerabilities via technical vulnerability management (c), deploys detection/repair that can block some exploitation paths before crash, and uses allowlisting to stop unauthorized exploit-delivery vectors, but does not stop all known or zero-day exploits that trigger crashes.
- T1499.004recovers — A.8.7 clause j) explicitly requires business continuity plans including backups and recovery measures for recovering from malware attacks, which can encompass DoS conditions triggered by exploitation that also leads to malware effects or secondary impacts like data destruction/service stop.
- T1499.004responds — A.8.7(j) explicitly requires business continuity plans including backups and recovery measures for recovering from malware attacks; while the technique is exploitation (not malware delivery), the control's response posture for resulting DoS/crashes via recovery planning and isolation (k) addresses the realized impact in a limited way, but most of the technique (vulnerability exploitation itself) sits outside malware-specific response.
- T1505detects — A.8.7 explicitly requires regular automated validation/scans of systems (d,f), malware detection software placement based on risk (g), collection of new malware intel (n,o), and awareness-driven reporting (l,m) that can surface installed malicious server components after the fact; this is genuine but only a slice because the control is scoped to malware signatures/behaviors rather than all extensible server abuse (e.g. custom benign-looking extensions or zero-days without known indicators).
- T1505prevents — A.8.7 explicitly requires rules/controls preventing unauthorized software (e.g. application allowlisting), reducing exploitable vulnerabilities, scanning for malware before use, and protective measures against obtaining malicious files/software, which stops many (but not all) ways of installing malicious server components.
- T1505.001detects — A.8.7 requires regular automated validation of system software/content (d), malware detection software with scans of received data/email/webpages (f), collection of new malware intel (n), and awareness of malware indicators (m), which can surface malicious stored procedures or CLR assemblies when they are introduced or invoked in scanned contexts, but this is limited to specific entry points and does not broadly inspect database-internal stored procedure logic or modifications.
- T1505.002detects — A.8.7 explicitly requires scanning email attachments/downloads for malware before use (at servers, desktops, network entry) plus awareness/training on identifying malicious emails/files, which surfaces a malicious transport agent when it processes or arrives via email; this is genuine but only a slice because the technique registers as a .NET assembly for persistence (not always via email) and can be configured for non-malware behaviors like selective exfiltration.
- T1505.002prevents — A.8.7's rules against unauthorized software (allowlisting), change management, vulnerability reduction, and malware scanning of email/attachments before use directly block registration and execution of a malicious transport agent in the Exchange pipeline, but this is only a slice of the technique's attack surface (e.g., does not reach all deployment vectors, insider bypasses during maintenance, or non-email triggers).
- T1505.003detects — A.8.7 explicitly requires regular automated validation/scans of systems (esp. critical ones), scanning of received data/email/web content, malware detection software placement based on risk, collection of new malware intel, and procedures for reporting malware — all of which surface web shells once present on a web server or during delivery.
- T1505.003prevents — A.8.7's rules to prevent unauthorized software (allowlisting), reduce exploitable vulnerabilities, block malicious sites, scan for malware before use, and protect external file/software intake directly stop many web shell installation vectors, but leave open slices such as zero-days, insider/maintenance bypasses, and encrypted/evasive delivery that the clause itself flags as residual.
- T1505.003responds — A.8.7 explicitly requires procedures, responsibilities, awareness/training, and business continuity plans to deal with, report on, and recover from malware attacks once underway, which responds to a realized web shell (a form of malware) but only covers the malware-specific slice rather than general incident response.
- T1505.004detects — A.8.7 explicitly requires regular automated validation of system software/content, malware detection software with scanning of received data/webpages/emails, collection of new malware intel, and procedures to deal with/reporting malware, all of which can surface malicious IIS components or related artifacts post-installation.
- T1505.004prevents — A.8.7's rules to prevent unauthorized software (via allowlisting), reduce exploitable vulnerabilities, block malicious sites, scan for malware before use, and protect against external file/software introduction all constrain the installation of malicious IIS components (DLLs/modules), but do not stop an already-privileged adversary from installing them via legitimate mechanisms or during bypassed maintenance/emergency procedures.
- T1505.004responds — A.8.7 explicitly requires procedures to deal with protection against malware including reporting and recovering from malware attacks, plus business continuity plans for recovering from malware attacks; this matches the `responds` verb once the technique (malware installation) is underway, but only partially because the clause is scoped to malware generally and does not address all IIS-component specifics or containment/eradication steps.
- T1505.005detects — A.8.7 requires regular automated validation of system software/content (d), scanning of files/downloads/webpages (f), collection of new malware info (n), and verification of sources (o), which can surface anomalous or malicious replacement of termsrv.dll or related registry changes as malware indicators; this is limited to a slice because the technique is a targeted, low-profile persistence modification that may not match known malware signatures or trigger scans unless the replacement is overtly malicious.
- T1505.005prevents — A.8.7's change management, unauthorized software prevention (allowlisting), vulnerability reduction, and malware scanning before use on files/media can stop the initial modification/replacement of termsrv.dll or loading of a malicious ServiceDll, but the technique's post-compromise patching of a running system DLL and registry changes sit mostly outside the malware-focused controls.
- T1505.006detects — A.8.7 explicitly requires regular automated validation of software/content, malware detection software with scanning of received data/media/email/webpages, collection of new malware intel from reputable sources, and procedures to report malware — all of which can surface malicious VIBs (as known/suspected malware or unauthorized changes) after they reach the ESXi host, but this is only a slice given the technique's focus on privileged/esxcli installation, signature masquerading, and hypervisor-specific persistence that standard endpoint malware tools often miss.
- T1505.006prevents — A.8.7 explicitly requires rules/controls to prevent unauthorized software (via allowlisting per 8.19), reduce exploitable vulnerabilities (via 8.8), scan/validate before use of files from external networks/media, and configure malware tools with defense-in-depth; these block many (but not all) vectors for installing malicious VIBs on ESXi, leaving gaps such as privileged/esxcli --force installs, insider changes to acceptance levels, or supply-chain VIBs that pass signature checks.
- T1518detects — A.8.7 requires regular automated validation of software/content, scanning for unapproved files/amendments, malware detection tools placed per risk assessment, and procedures to collect/verify malware intelligence; this surfaces discovery activity when it matches known malicious patterns or produces anomalous files, but does not broadly instrument or alert on benign enumeration of installed software versions.
- T1518.001detects — A.8.7 requires regular automated validation/scans of systems (d,f), collection of new malware info (n,o), and awareness of defensive tooling placement (g,m), which can surface discovery attempts against installed security software; this is limited to scanning/monitoring slices rather than broadly detecting the technique across all platforms and methods (e.g. Cloud API, reg query).
- T1518.002detects — A.8.7 requires regular automated validation of system software/content, scanning for unapproved files/amendments, malware detection software with risk-based placement, and procedures to collect/verify malware info, which can surface backup software discovery activity as anomalous or malware-related behavior on monitored endpoints/servers, but this is limited to specific scanning contexts rather than broadly detecting the technique across all platforms and commands.
- T1525detects — A.8.7 requires regular automated validation of system software/content (d), scanning of received data/media before use (f1), scanning of downloads/attachments (f2), and collection/verification of new malware info (n/o), which can surface implanted malicious images in some cases (e.g. during provisioning or scans of storage), but does not broadly detect post-implant images already resident in cloud/container registries.
- T1525prevents — A.8.7 explicitly requires reducing exploitable vulnerabilities (via 8.8/8.19), preventing unauthorized software via allowlisting (8.19/8.32), scanning for malware in received files/software (including from external networks), and protecting against malware introduction during maintenance/emergency procedures that could bypass controls; these directly stop the post-access implant of a malicious image or backdoor into a registry in many cases, but leave a bounded remainder for privileged insiders or supply-chain images where detection/allowlisting is evaded or bypassed.
- T1526detects — A.8.7 requires regular automated validation of system content, malware scans at multiple layers (including network gateways, endpoints, email, web), anomaly-oriented awareness training, and collection of new malware intel; these surface some discovery behaviors that involve known malicious tools, anomalous enumeration patterns, or malware delivery, but miss the bulk of legitimate-API-based cloud service enumeration performed by an already-authenticated identity.
- T1528detects — A.8.7 requires regular automated validation of systems, malware scans (including on received data, email, webpages), collection of new malware intel, and awareness training that surfaces anomalous/malicious behavior, which can detect some token-theft vectors (e.g., malware on endpoints, phishing emails, or compromised containers) but misses many others (e.g., direct IMDS queries, OAuth phishing without malware, or CI/CD pipeline compromises).
- T1528prevents — A.8.7's malware detection/repair, awareness training, unauthorized-software rules, website blocklisting, vulnerability reduction, and scanning directly stop malware-based vectors for stealing tokens (e.g. compromised containers, CI/CD pipelines, or phishing-delivered malware), but the technique's social-engineering OAuth flows, post-compromise IMDS requests, and refresh-token theft sit outside malware entirely.
- T1528recovers — A.8.7 point j) explicitly requires business continuity plans including backups and recovery measures for recovering from malware attacks, which directly restores state after token-theft malware has run (per event-lane recovers definition and cp-9/T1486 anchor).
- T1529detects — A.8.7 requires regular automated validation of system software/data content, malware scans at multiple layers (including email/web/network), collection of new malware intel, and procedures for reporting malware attacks, which can surface anomalous shutdown/reboot behaviors when they are malware-driven but does not broadly instrument or guarantee detection of all T1529 vectors (e.g., direct privileged API use or non-malware physical/hypervisor reboots).
- T1529recovers — A.8.7(j) explicitly requires business continuity plans including backups and recovery measures to recover from malware attacks; while T1529 is not itself a malware technique, the control's recovery provisions (and cross-reference to 8.13) address post-shutdown/reboot restoration of availability in the malware context that the technique often accompanies.
- T1530detects — A.8.7 requires regular automated validation of system content, malware scans on received data/email/webpages, collection of new malware intel, and verification of sources, which can surface malware used to deliver or exploit cloud storage access but does not broadly detect the access technique itself or misconfigurations enabling it.
- T1530recovers — A.8.7 point j) explicitly requires business continuity plans that include data and software backup plus recovery measures for recovering from malware attacks; while T1530 is about data access (often via misconfig or credential abuse), a realized malware-driven exfiltration or ransomware variant that encrypts or deletes cloud-stored data can have its effects undone by those backups, but this is only a slice of the technique's non-malware vectors.
- T1531detects — A.8.7 requires regular automated validation of system content, malware scans at multiple layers (email, web, endpoints, network), collection of new malware intel, and awareness/reporting procedures that can surface anomalous account changes when they resemble or accompany malware activity, but the control is scoped to malware vectors and does not broadly instrument or detect pure account manipulation techniques such as direct use of passwd, esxcli, or Group Policy edits.
- T1531recovers — A.8.7 explicitly requires preparing business continuity plans including backups and recovery measures for recovering from malware attacks, and T1531 is commonly performed as a precursor step in ransomware/malware attacks to impede recovery, so the control's recovery provisions address the post-impact state asserted by recovers (though only for the malware/ransomware slice of the technique).
- T1534detects — A.8.7 mandates scanning for malware in email/IM attachments, downloads, webpages, received data, and regular system validation plus awareness of malware-infected content, which surfaces malicious payloads or links used in internal spearphishing but does not broadly detect the social-engineering, impersonation, or credential-capture stages of the multi-staged technique.
- T1534prevents — A.8.7's malware detection, scanning of attachments/downloads/emails/webpages, blocklisting of malicious sites, awareness training on malware-infected content, and vulnerability reduction directly stop many delivery vectors (e.g. malicious attachments/links in internal email/chat that carry payloads), but internal spearphishing can also rely on credential theft via impersonation or non-malware social engineering that the control does not address.
- T1534responds — A.8.7 requires procedures, training, awareness, and business continuity plans specifically for recovering from and dealing with malware attacks (points j, k, l), which responds to the malware-delivery stage of internal spearphishing once underway, but does not address the broader social-engineering, credential-harvesting, or impersonation aspects of the multi-staged technique.
- T1537detects — A.8.7 requires regular automated validation of system content, malware scans on data received over networks or via storage media, and procedures for collecting/using malware information, which can surface anomalous internal cloud transfers or shared backups if they carry or trigger known malware indicators, but this is a minority slice against T1537's primary API-based, non-malware exfiltration paths that blend as normal internal traffic.
- T1539detects — A.8.7 explicitly requires malware detection/repair software, regular automated system validation for unapproved files/amendments, scanning of received data/email/webpages, collection of new malware intel, and awareness of malware indicators — all of which surface the malware that targets or steals session cookies on local systems, in browsers, or via malicious JS/downloads.
- T1539prevents — A.8.7's malware detection/repair, awareness, allowlisting, vulnerability reduction, website blocklisting, and scanning directly stop the malware vectors that target local browser cookies or deliver via JS/phishing, but do not address non-malware vectors such as malicious proxies (Evilginx2), network traffic interception, or post-acquisition use of a stolen cookie.
- T1539recovers — A.8.7 explicitly requires business continuity plans including backups and recovery measures (item j) to recover from malware attacks; while T1539 can be realized by malware that steals cookies, the control's recovery provisions address only the malware-driven slice of the technique and do not restore sessions or credentials compromised by non-malware vectors such as JS injection, phishing proxies, or MITM.
- T1539responds — A.8.7 explicitly requires business continuity plans, isolating high-risk environments, defined procedures for reporting/recovering from malware attacks, and awareness/training on mitigating malware-infected files — all of which constitute containment/eradication actions once a malware-driven cookie-theft technique is underway, but only for the malware vector slice of T1539 (not JS injection, phishing proxies, or non-malware vectors).
- T1542detects — A.8.7 explicitly requires regular automated validation of system software/content (d), scanning of received data/media/email/webpages (f), placement of detection tools based on risk (g) including at network gateways/endpoints/servers, collection of new malware intel (n-o), and awareness of evasive techniques; this surfaces some pre-OS/boot anomalies (especially on supported platforms) but the T1542 description notes such malware is particularly difficult to detect by host software-based defenses, leaving a large remainder
- T1542prevents — A.8.7 explicitly requires reducing exploitable vulnerabilities (via 8.8/8.19), preventing unauthorized software (allowlisting), scanning for malware before execution/use, defence-in-depth placement (including firmware-relevant layers where feasible), and protecting maintenance/emergency paths that could introduce pre-OS malware; this stops many delivery vectors and some persistence attempts, but cannot fully block sophisticated firmware/BIOS/UEFI overwrites that occur below the OS and evade host-based detection tools the control relies on.
- T1542recovers — A.8.7 explicitly requires business continuity plans including backups and recovery measures (j) to recover from malware attacks, and T1542 is a malware-based persistence technique; this restores state after the attack but does not address all pre-OS impacts or non-malware boot abuses, leaving a bounded remainder
- T1542.001detects — A.8.7 explicitly requires regular automated validation of system software/content (d), scanning of received data/media/email/webpages (f), collection of new malware intel (n-o), and risk-based placement of detection tools including at network gateways and endpoints (g); this surfaces some firmware modification attempts (especially those involving delivered/known malware or anomalous changes), but firmware flashing is often out-of-band, pre-OS, or uses evasion that leaves only a minority slice detectable by the listed mechanisms.
- T1542.001prevents — A.8.7's malware detection, vulnerability reduction, unauthorized software prevention, and awareness measures can stop some vectors that deliver or activate malicious firmware (e.g. via untrusted media or known exploits), but firmware modification is a low-level persistence technique outside typical malware scanners and the control's dominant focus on OS-level malware.
- T1542.001recovers — A.8.7 explicitly requires business continuity plans including backups and recovery measures (item j) to recover from malware attacks, and firmware modification is presented as a malware/persistence technique; this restores state after impact but only for the malware-delivery slice of the technique, not the full class of firmware modification (e.g. non-malware supply-chain or physical attacks).
- T1542.002detects — A.8.7 requires regular automated validation of system software/content (d), scanning of received data/media/email/webpages (f), collection of new malware info (n), and risk-based placement of detection tools (g), which can surface malicious component firmware if it is known, scannable at a checked boundary, or triggers integrity anomalies; this is limited to a minority slice because firmware modifications often occur outside the OS, evade host-based scans, and target obscure components with no routine detection coverage.
- T1542.002prevents — A.8.7's rules to prevent unauthorized software (allowlisting), reduce exploitable vulnerabilities, scan/validate for unapproved files/amendments, and protect against external media/network files block many vectors for introducing malicious component firmware, but firmware flashing often uses authorized tools/drivers and can bypass host malware scanners entirely.
- T1542.002recovers — A.8.7 explicitly requires business continuity plans including data/software backup and recovery measures (item j) to recover from malware attacks; while component firmware modification is a sophisticated malware persistence technique outside the OS, the control's recovery provisions address post-attack restoration for affected systems and assets in a bounded but not comprehensive way (e.g., may not fully restore firmware without additional measures).
- T1542.003detects — A.8.7 explicitly requires regular automated validation of system software/content (d), scanning of storage media and boot-related data before use (f1), placement of detection tools based on risk (g) including at network gateways and endpoints, plus procedures to collect/verify malware intelligence (n/o) and awareness of boot-time threats; this surfaces some bootkits (especially known ones on scanned media or via anomalous files) but misses many low-level UEFI/BIOS modifications that evade standard malware scanners, leaving a genuine implementation-dependent slice rather than a bounded remainder.
- T1542.003prevents — A.8.7 explicitly requires reducing vulnerabilities that malware can exploit (via 8.8/8.19), preventing unauthorized software and changes (allowlisting, change management), scanning for malware before execution (including on storage media and during boot-related flows), and isolating critical environments, all of which stop many bootkit installation paths; however, once raw boot-sector or EFI-partition access is obtained the low-level modification evades most endpoint malware tools and full remediation is acknowledged as difficult, leaving a genuine residual slice.
- T1542.003recovers — A.8.7 explicitly requires business continuity plans including backups and recovery measures (j) to recover from malware attacks, and a bootkit is defined as a malware variant; however the control's malware-specific scanning, detection and repair tools do not reach the below-OS boot sector/ESP modifications that the technique names, leaving most remediation outside its scope.
- T1542.003responds — A.8.7 explicitly requires business continuity plans, isolating environments, procedures for recovering from malware attacks, and handling protection during maintenance/emergency bypasses, all of which constitute containment/eradication actions once a bootkit (as malware) is underway or suspected.
- T1542.004detects — A.8.7 explicitly requires regular automated validation of software content, scanning of received data/firmware before use, collection of new malware information from reputable sources, and risk-based placement of detection tools (including on network gateways for protocols like TFTP used in ROMMON updates), which surfaces unauthorized ROMMON firmware changes; this is only a slice because ROMMONkit is a low-level, hard-to-detect boot firmware attack on network devices that can bypass endpoint scans and standard malware signatures.
- T1542.004prevents — A.8.7 guidance on preventing unauthorized software (allowlisting), reducing exploitable vulnerabilities, protecting against malicious files from external networks, and scanning before use on network devices directly constrains the loading of unauthorized ROMMON firmware, but leaves a remainder for physical/local maintenance bypasses, emergency procedures, and supply-chain firmware that the clause does not fully close.
- T1542.004recovers — A.8.7 explicitly requires business continuity plans including backups and recovery measures (item j) to recover from malware attacks, which directly addresses restoring state after a realized ROMMONkit firmware overwrite.
- T1542.005detects — A.8.7 requires regular automated validation of system software/content (d), scans of data received over networks or electronic media before use (f.1), scans of webpages (f.3), collection of new malware info (n), and risk-based placement of detection tools including at network gateways for protocols like file transfer; this surfaces anomalous or malicious boot images/files delivered via TFTP in some network contexts but does not broadly detect configuration manipulation or unauthorized netbooting itself on the device.
- T1542.005prevents — A.8.7 explicitly requires rules/controls to prevent unauthorized software (via allowlisting), protective measures against obtaining files/software from external networks, reducing exploitable vulnerabilities, and scanning data received over networks before use — all of which constrain the TFTP-based loading of an unauthorized/malicious network device image at boot, though the boot-sequence manipulation itself and non-malware-modified images remain outside its malware-specific focus.
- T1542.005recovers — A.8.7 explicitly requires business continuity plans including backups and recovery measures (item j) to recover from malware attacks, and the technique results in a modified device image that can be treated as malware-induced corruption.
- T1543detects — A.8.7 mandates regular automated validation of system software/content, malware scanning of received data/email/webpages, collection of new malware intel, and awareness of malware indicators, which can surface anomalous or malicious system processes/daemons after creation but does not systematically detect all T1543 variants (e.g. those using legitimate mechanisms or evading scans).
- T1543prevents — A.8.7's malware detection, allowlisting, vulnerability reduction, scanning before use, and awareness directly stop many (but not all) malicious service/daemon creations that rely on malware delivery or known-vulnerable components
- T1543.001detects — A.8.7 explicitly requires regular automated validation of system software/content, scanning of received data/email/webpages, collection of new malware intel from reputable sources, and placement of detection tools based on risk (including at endpoints, gateways, and for evasive techniques), which surfaces many but not all Launch Agent .plist creations or modifications on macOS.
- T1543.001prevents — A.8.7's malware detection, vulnerability reduction, unauthorized software rules, awareness, and scanning can stop many malicious launch agents from executing or persisting, but the control is silent on plist-specific creation/modification and leaves gaps for disguised or non-malware-classified agents.
- T1543.001responds — A.8.7 explicitly requires procedures to deal with protection against malware including reporting and recovering from malware attacks, plus business continuity plans for recovering from malware attacks; this matches the `responds` verb once the persistence technique (a malware payload) is already running, but only partially because the clause is scoped to malware events and does not address non-malware launch-agent abuse.
- T1543.002detects — A.8.7 requires regular automated validation of system software/content (d), scanning of received data/email/webpages (f), collection of new malware info (n), and placement of detection tools based on risk (g), which can surface systemd service anomalies or known malicious payloads but does not broadly instrument for creation/modification of .service files, generators, or symbolic links across all vectors.
- T1543.002prevents — A.8.7's rules/controls to prevent unauthorized software (allowlisting), reduce exploitable vulnerabilities, block malicious sites, scan/validate before execution, and protect external file intake all constrain the creation or modification of malicious systemd .service files and generators on Linux, but leave open slices such as authorized-but-malicious admin actions, symbolic-link tricks inside permitted paths, and generator-based persistence that bypasses static allowlists or scans.
- T1543.002responds — A.8.7 explicitly requires preparing business continuity plans, isolating high-risk environments, defining procedures for reporting/recovering from malware attacks, and handling malware via detection/repair software and awareness, which directly addresses containment, eradication, and recovery once a systemd-based malicious service (as malware/persistence) is underway.
- T1543.003detects — A.8.7 mandates regular automated validation of system software/data content, scanning of received files/emails/webpages, malware detection software placement based on risk, and procedures for reporting malware, which can surface malicious services or drivers after they are created/installed but does not broadly instrument service creation, registry changes, or hidden/masqueraded services in real time.
- T1543.003prevents — A.8.7's rules to prevent unauthorized software (allowlisting), reduce exploitable vulnerabilities, block malicious sites, scan before execution, and harden configs via change management stop many service-creation paths that rely on dropping/running unauthorized binaries or drivers, but leave open registry/API abuse, signed BYOVD, masquerading, and hidden-service techniques that do not require new unauthorized code.
- T1543.003responds — A.8.7 explicitly requires procedures, training, and business continuity plans to respond to and recover from malware attacks (items l, j, m), which would be invoked once a malicious Windows service (a common malware persistence vector) is detected and underway.
- T1543.004detects — A.8.7 mandates regular automated validation of system software/content, malware detection software with scans (including on received data, email, webpages), collection of new malware intel, and awareness of malware indicators; these surface some Launch Daemon anomalies (e.g. unexpected plist/executable changes or known malicious signatures) but miss many others (e.g. novel unsigned daemons, masquerading, or config-induced writeable paths without signatures).
- T1543.004prevents — A.8.7's malware detection/repair, allowlisting, vulnerability reduction, scanning of received files/executables, and awareness directly stop many Launch Daemon malware payloads from installing or executing, but macOS-specific plist/launchd mechanisms, privilege requirements, and configuration-based hijacking (e.g., writable directories) are only partially covered by the listed controls.
- T1543.004responds — A.8.7 explicitly requires procedures, training, and business continuity plans to deal with and recover from malware attacks once underway (l, j, m), which responds to a realized Launch Daemon persistence technique that delivers malware.
- T1543.005detects — A.8.7 requires regular automated validation of system software/content, malware scanning of received data/email/webpages, collection of new malware intel, and anomaly-oriented awareness training, all of which can surface container-service modifications or unauthorized daemon-like containers when they match known malware patterns or produce detectable anomalies; this is only a slice because most T1543.005 realizations (e.g. benign-looking DaemonSet, policy-driven restart=always, or privilege-escalating docker run) introduce no malware signature and fall outside the clause's malware-centric scanning focus.
- T1543.005prevents — A.8.7's rules to prevent unauthorized software (allowlisting), reduce exploitable vulnerabilities, block malicious sites, scan for malware before use, and isolate high-risk environments stop many vectors for introducing or modifying container services/daemons, but do not address legitimate admin use of docker/podman/kubelet commands or configuration changes that achieve the technique.
- T1546detects — A.8.7 requires regular automated validation of system content, malware scans (including on received data, email, webpages), collection of new malware intel, and anomaly-oriented awareness/training that can surface event-triggered malicious payloads or their effects after they are present.
- T1546prevents — A.8.7's malware detection, vulnerability reduction, unauthorized software prevention (allowlisting), awareness, and scanning can stop some event-triggered malware from executing or being installed, but do not address creation/modification of legitimate event triggers (e.g. WMI, cron, services) or privilege escalation via them once present.
- T1546.001detects — A.8.7 requires regular automated validation of system software/data content, scanning of received files/emails/webpages, collection of new malware intel, and monitoring for anomalous behavior that would surface registry changes or unexpected handlers, but this is scoped by risk and does not guarantee detection of all custom or novel file-association modifications.
- T1546.001prevents — A.8.7 guidance explicitly requires rules/controls that prevent unauthorized software (e.g. application allowlisting per 8.19), reducing exploitable vulnerabilities, scanning before use of files/downloads, and awareness that together stop the adversary from successfully modifying file associations or having the malicious handler execute on open.
- T1546.002detects — A.8.7 requires regular automated validation of system software/content, malware detection software with scans (including on received data, email, webpages), collection of new malware intel, and awareness of malware indicators; these surface screensaver-based persistence when it triggers execution or matches known malware signatures, but miss purely registry-based configuration changes that do not yet execute or match known samples.
- T1546.002prevents — A.8.7's malware detection/repair, allowlisting, vulnerability reduction, website blocklisting, scanning of received files/emails/webpages, and awareness directly stop many malware delivery vectors that would plant the malicious .scr or registry change, but do not stop an already-privileged adversary from directly writing the registry keys or replacing a legitimate screensaver binary.
- T1546.002responds — A.8.7 explicitly requires business continuity plans, isolating high-risk environments, procedures for recovering from malware attacks, and handling malware incidents (including training and response), which directly addresses containment/eradication once a screensaver-triggered malware persistence technique is underway; partial because the clause is scoped to malware events and does not broadly respond to all persistence techniques or non-malware variants of T1546.002.
- T1546.003detects — A.8.7 requires regular automated validation of system software/content, malware scanning of received data/email/webpages, collection of new malware intel, and monitoring for anomalous behaviour that can surface WMI event subscriptions or their artifacts when they match known patterns or trigger scans, but this is limited to observable malware-like activity rather than reliably catching all stealthy or custom WMI persistence.
- T1546.003prevents — A.8.7 guidance on malware detection/repair software, reducing exploitable vulnerabilities, preventing unauthorized software via allowlisting, scanning received data/email/web content, and awareness/training directly blocks many delivery and execution vectors for the malicious WMI subscription code, but leaves open attacker-controlled legitimate WMI usage or insider/admin abuse that does not rely on malware introduction.
- T1546.003responds — A.8.7 explicitly requires procedures to deal with protection against malware including reporting and recovering from malware attacks, plus business continuity plans for recovering from malware attacks; this bounds an in-progress WMI-triggered malicious execution once underway but does not address the full technique (e.g. the initial subscription creation).
- T1546.004detects — A.8.7 requires regular automated validation of system software/content (d), scanning of received data/email/webpages (f), collection of new malware info (n), and placement of detection tools based on risk (g), which can surface malicious shell config modifications if they introduce detectable malware signatures or anomalies, but this is limited to post-insertion scanning rather than reliably catching all config changes or non-malware persistence.
- T1546.004prevents — A.8.7's rules to prevent unauthorized software (allowlisting), reduce exploitable vulnerabilities, block malicious sites, scan for malware before execution, and protect against external file introduction all stop malicious commands from being inserted into or executed from shell config files on many vectors, but leave a nameable remainder (e.g. authorized-but-malicious insider changes to permitted files, or evasion of detection in un-scanned maintenance/emergency paths).
- T1546.005detects — A.8.7 requires regular automated validation of system software/content, malware scanning of received data/email/webpages, collection of new malware intel, and monitoring for anomalous behavior that can surface trap-based persistence when it matches known malware patterns or triggers scans, but this is only a slice of possible trap implementations (many are custom benign-looking shell code with no detectable malware signature).
- T1546.006detects — A.8.7 explicitly requires regular automated validation of software content, scanning of received files/executables, malware detection software placement on endpoints/servers/gateways, and procedures to deal with/reporting malware, which surfaces tainted Mach-O binaries or anomalous dylib loads on macOS but only where those behaviors or files are in scope of the scans and risk-based placement (remainder includes fileless header edits, encrypted/evasive delivery, or un-scanned maintenance paths).
- T1546.006prevents — A.8.7's malware detection/repair, allowlisting, vulnerability reduction, scanning of received files/executables, and awareness directly stop many vectors for introducing or triggering tainted Mach-O binaries with added LC_LOAD_DYLIB, but leave gaps for supply-chain or already-trusted binaries modified via maintenance bypasses or evasive techniques.
- T1546.007detects — A.8.7 requires regular automated validation of system software/content, malware scanning of received data/email/webpages, collection of new malware intel, and anomaly-oriented awareness training, all of which can surface a malicious Netsh helper DLL once present and triggered; this is a genuine but minority slice of the class (most instances are introduced via registry changes or during maintenance that the clause does not instrument).
- T1546.007prevents — A.8.7's malware detection/repair, unauthorized-software allowlisting, vulnerability reduction, scanning of received files/executables, and awareness directly stop many malicious Netsh Helper DLL registrations and executions, but leave open registry-write paths, signed or evasive loaders, and non-malware persistence vectors that the control does not address.
- T1546.008detects — A.8.7 explicitly requires regular automated validation/scans of system software and data content (including for unapproved files/amendments), malware detection software on endpoints/servers/gateways, and awareness of new malware, which surfaces binary replacements or registry changes to accessibility features as anomalous or malicious after they occur.
- T1546.008prevents — A.8.7 requires malware detection/repair software, vulnerability reduction (8.8), unauthorized software prevention via allowlisting (8.19), website blocklisting, integrity validation scans, and awareness — all of which can stop the binary replacement or registry pointer modification steps that deliver the malicious accessibility trigger, but leaves residual paths such as IFEO debugger injection, signed binaries, or non-malware delivery vectors that the clause does not address.
- T1546.008responds — A.8.7 explicitly requires preparing business continuity plans, isolating high-risk environments, defining procedures for reporting/recovering from malware attacks, and protecting maintenance/emergency paths that could introduce malware, which directly addresses containment/eradication once a malware-triggered accessibility backdoor is active.
- T1546.009detects — A.8.7 requires regular automated validation of system software/content, malware detection software with scanning of files/downloads/webpages, collection of new malware intel, and anomaly-oriented awareness training, all of which can surface AppCert DLL abuse when it matches known patterns or produces observable artifacts, but leaves substantial coverage gaps for novel/encrypted/evasive variants that do not trigger those exact mechanisms.
- T1546.009prevents — A.8.7 guidance on application allowlisting, reducing exploitable vulnerabilities, scanning for malware before use/execution, and defence-in-depth placement directly stops many (but not all) malicious AppCert DLLs from being introduced or loaded into processes
- T1546.009responds — A.8.7 explicitly requires procedures to deal with protection against malware on systems including reporting and recovering from malware attacks, plus business continuity plans for recovering from malware attacks; this matches the `responds` verb (containment/eradication once the technique is underway) for a malware-based persistence/elevation technique.
- T1546.010detects — A.8.7 explicitly requires regular automated validation of system software/content, malware detection software with scans (including on received data, email, webpages), collection of new malware intel, and awareness of indicators, which can surface AppInit_DLLs registry abuse or loaded malicious DLLs as malware; this is limited to a slice because detection depends on signatures/behavioral rules for the specific technique, placement choices per risk assessment, and does not guarantee finding all variants or pre-execution registry changes.
- T1546.010prevents — A.8.7 guidance on application allowlisting, reducing vulnerabilities via technical vulnerability management, scanning for malware before use, and defence-in-depth placement directly stops many (but not all) malicious DLLs from being registered or loaded as AppInit_DLLs on Windows.
- T1546.011detects — A.8.7 explicitly requires malware detection/repair software, regular automated validation/scans of systems (including for unapproved files/amendments), scanning of received data/email/web content, and collection of new malware information, which surfaces shim-based malicious content or changes on Windows systems; partial because it is scoped to malware signatures/behaviors rather than all shim abuse (e.g. non-malware persistence without detectable payload).
- T1546.011prevents — A.8.7 explicitly requires rules/controls preventing unauthorized software (e.g. application allowlisting), reducing exploitable vulnerabilities, scanning for malware before use, and defence-in-depth placement, all of which stop malicious shim installation/execution in many but not all cases (e.g. admin-privileged or signed shims, or non-malware persistence vectors).
- T1546.012detects — A.8.7 explicitly requires regular automated validation of system software/data content, scanning of received files/emails/webpages, collection of new malware intel, and placement of detection tools based on risk (including at endpoints, servers, gateways), which surfaces IFEO registry abuse and malicious debugger/persistence payloads when they match known patterns or trigger scans; it does not guarantee detection of novel or evasive variants that bypass signature-based or scoped scanning.
- T1546.012prevents — A.8.7's rules to prevent unauthorized software (allowlisting), reduce exploitable vulnerabilities, block malicious sites, scan for malware before execution, and use defense-in-depth placement stop many IFEO registry abuses that rely on malware delivery or known-vulnerable binaries, but do not stop an already-authorized process or admin from directly writing the Debugger value.
- T1546.012responds — A.8.7 explicitly requires procedures, responsibilities, training, and business continuity plans for reporting and recovering from malware attacks once underway, which matches the `responds` verb for containment/eradication of a realized T1546.012 abuse (e.g. malware registering malicious IFEO debuggers).
- T1546.013detects — A.8.7 requires regular automated validation of system software/content (d), scanning of received data/email/webpages (f), collection of new malware info (n), and awareness of indicators (m), which can surface malicious profile modifications when they match known malware patterns or trigger scans, but this is limited to observable file-based indicators rather than the full technique (including in-memory or privilege-escalation aspects).
- T1546.013prevents — A.8.7's rules against unauthorized software (allowlisting), vulnerability reduction, change management, malware scanning of files/scripts, awareness training on malicious files, and protective measures on external/obtained content all constrain the introduction or execution of a malicious profile.ps1, but do not stop an admin-level adversary from modifying a legitimate profile under their control.
- T1546.014detects — A.8.7 requires regular automated validation of system software/content (d), scanning of received data/email/webpages (f), collection of new malware info (n), and awareness of anomalous indicators (m), which can surface emond rule additions or anomalous emond behavior on macOS; this is only a slice because the clause centers on malware binaries/signatures rather than plist rule abuse for persistence and does not mandate host telemetry or behavioral detection of the technique itself.
- T1546.014prevents — A.8.7's rules/controls to prevent unauthorized software (allowlisting), reduce exploitable vulnerabilities, scan for malware before use, and protect against introduction during maintenance directly stop adversaries from writing/using malicious emond rules on macOS, but only a slice — the technique can still succeed via legitimate admin-authorized changes, unpatched 0-days, or bypassed scanning.
- T1546.015detects — A.8.7 requires regular automated validation of system software/content (d), scanning of received data/email/web content before use (f), collection of new malware info (n), and awareness of indicators (m), which can surface COM registry anomalies or known malicious payloads post-hijack; this is limited to a slice because the technique is a stealthy registry change for persistence (not always involving detectable malware files or known signatures) and the control's scanning focus leaves many in-memory or TypeLib variations unreached.
- T1546.015prevents — A.8.7's rules to prevent unauthorized software (allowlisting), reduce exploitable vulnerabilities, block malicious sites, scan for malware before use, and protect against external file introduction all constrain the registry changes, malicious code insertion, and remote payload delivery that enable COM hijacking, but do not stop all variants (e.g., those using legitimate-looking local changes or evasive encryption).
- T1546.016detects — A.8.7 explicitly requires malware detection/repair software, regular automated validation of software/content (including unapproved files/amendments), scanning of received data/email/webpages, and collection of new malware info, all of which surface malicious installer scripts or packages before or during execution on Linux/macOS/Windows.
- T1546.016prevents — A.8.7 explicitly requires rules/controls to prevent unauthorized software (e.g. application allowlisting), reduce exploitable vulnerabilities, block malicious sites, scan before use, and use defense-in-depth placement; these stop many but not all installer-script abuse vectors (e.g. signed legitimate packages, insider-modified trusted installers, or maintenance-bypass cases).
- T1546.016responds — A.8.7 explicitly requires business continuity plans, isolating high-risk environments, defined procedures for reporting/recovering from malware attacks, and awareness/training on mitigating malware-infected files/programs, which directly addresses containment/eradication once an installer-based malware execution is underway.
- T1546.017detects — A.8.7 requires regular automated validation of system software/content, malware detection software with scans (including on received data/media/email/webpages), collection of new malware info, and anomaly investigation, which can surface udev rule modifications as unauthorized changes or known malware patterns, but this is limited to scanned/known cases and does not broadly instrument rule file integrity or udev events across all Linux systems.
- T1546.017prevents — A.8.7's rules/controls to prevent unauthorized software (a), reduce exploitable vulnerabilities (c), scan/validate for unapproved files/amendments (d), protect against external files/software (e), and awareness/training (m) constrain udev rule abuse for persistence, but only as a minority slice — the technique is a privileged, file-based config change rather than typical malware delivery or execution.
- T1546.018detects — A.8.7 requires regular automated validation of system software/content (d), scanning of received data/email/webpages (f), collection of new malware info (n), and monitoring placement based on risk (g), which can surface Python startup-hook abuse when it introduces detectable malware signatures or anomalous files, but leaves large gaps for fileless/script-only hooks, evasive/encrypted delivery (g2), and non-malware persistence that never matches known signatures.
- T1546.018prevents — A.8.7's rules to prevent unauthorized software (allowlisting), reduce exploitable vulnerabilities, scan for malware before use, and block malicious sites can stop malicious .pth or sitecustomize.py files from being introduced or executed on Python startup, but this is only a slice — the technique can still be planted via authorized/developer workflows, legitimate package installs, or in environments where Python execution itself is permitted and scanning misses the hook.
- T1547detects — A.8.7 requires regular automated validation of system software/content, malware scans (including on received data, email, webpages), collection of new malware intel, and awareness of anomalous indicators, which can surface some T1547 artifacts (e.g. unexpected autostart entries or files) but does not systematically detect kernel modifications, registry changes, or most persistence mechanisms.
- T1547prevents — A.8.7's malware detection, vulnerability reduction, unauthorized software rules, website blocklisting, scanning, and awareness directly stop many common malware vectors that deliver or install autostart/persistence mechanisms (e.g. via email, downloads, unpatched vulns, or unauthorized binaries), but leave kernel modifications, legitimate-but-abused OS autostart config changes, and non-malware delivery paths untouched.
- T1547.001detects — A.8.7 requires regular automated validation of system software/content, malware scans (including on received data, email, webpages), collection of new malware intel, and awareness of evasive techniques, which can surface anomalous registry/startup entries or known malware using them, but does not mandate specific detection of persistence modifications themselves.
- T1547.001prevents — A.8.7 guidance (a,c,f,g,h) directly prevents malware from being written to or surviving on the registry/startup locations that T1547.001 abuses, but does not stop an adversary who already has code execution from creating the persistence entry itself.
- T1547.002detects — A.8.7 requires regular automated validation of system software/content (d), scanning of received data/email/webpages (f), collection of new malware intel (n-o), and risk-based placement of detection tools (g) which can surface anomalous registry changes or unknown DLLs used in this LSA autostart technique, but only where the binary or its behavior is already known or matches a detectable pattern.
- T1547.002prevents — A.8.7's malware detection, vulnerability reduction, unauthorized software prevention (allowlisting), and awareness directly block many common malware delivery vectors that would install or reference a malicious authentication package binary, but do not address the specific registry edit or LSA loading of a trusted-but-malicious DLL.
- T1547.003detects — A.8.7 requires regular automated validation of system software/content (d), scanning of received data/email/webpages (f), collection of new malware info (n), and placement of detection tools based on risk (g), which can surface the anomalous time-provider DLL registration or load at boot on monitored paths; this is a genuine but minority slice of the technique's full surface (registry abuse under admin, Local Service execution, evasive encrypted delivery).
- T1547.003prevents — A.8.7 guidance on application allowlisting, reducing exploitable vulnerabilities, scanning for malware before use/execution, and defence-in-depth placement can stop malicious time-provider DLL registration and loading at boot on covered vectors, but does not reach all persistence paths or require blocking of admin-privileged registry changes that enable the technique.
- T1547.004detects — A.8.7 requires regular automated validation of system software/content (d), scanning of received data/email/webpages (f), collection of new malware info (n), and awareness of indicators (m), which can surface Winlogon registry modifications or anomalous DLL loads when they match known malware patterns, but this is limited to detectable/known cases rather than all possible abuse.
- T1547.004prevents — A.8.7 guidance on malware detection/repair software, reducing exploitable vulnerabilities, preventing unauthorized software via allowlisting, scanning received files/executables, and awareness directly blocks many common delivery vectors and initial execution of malicious DLLs that would abuse Winlogon registry keys for persistence, but leaves open registry modification paths, insider changes, or novel evasion not caught by scanning or allowlisting.
- T1547.005detects — A.8.7 requires regular automated validation of system software/content, malware detection software with scanning (including at multiple layers), collection of new malware intel, and procedures for reporting malware attacks, which can surface anomalous SSP Registry modifications or unknown DLL loads as potential malware, but this is not targeted at persistence techniques and leaves many evasive or non-signature SSP abuses undetected.
- T1547.005prevents — A.8.7 guidance on application allowlisting, reducing vulnerabilities via technical vulnerability management, preventing use of malicious sites, scanning for malware before use, and defence-in-depth placement can stop malicious SSP DLL registration or loading at boot on a slice of vectors, but leaves many legitimate SSP changes and non-malware persistence paths untouched.
- T1547.006detects — A.8.7 explicitly requires regular automated validation of system software/content, malware detection/repair software with scans (including of received data, attachments, webpages), collection of new malware intel, and awareness of malware indicators, which can surface malicious LKMs/kexts post-installation but does not guarantee detection of all kernel-level rootkit behaviors such as hiding or evasion techniques.
- T1547.006prevents — A.8.7 guidance on application allowlisting, reducing exploitable vulnerabilities, blocking malicious sites, scanning before use, and defence-in-depth placement directly stops many malicious LKMs/kexts from loading at boot, but leaves a bounded remainder (signed/approved-but-malicious modules, kernel exploits bypassing allowlists, and disabled measures during maintenance/emergency)
- T1547.007detects — A.8.7 explicitly requires regular automated validation/scans of system content (d,f), malware detection software placement based on risk (g), collection of new malware intel (n,o), and procedures for reporting malware (l), which can surface plist modifications or malicious reopened apps on macOS endpoints as anomalous or known-bad; this is a genuine but minority slice because the control is scoped to malware signatures/behaviors rather than the full spectrum of plist tampering for persistence.
- T1547.007prevents — A.8.7 guidance on application allowlisting (a), reducing vulnerabilities (c), scanning for malware before use (f), and awareness/training (m) can stop malicious plist modifications or the resulting payload from executing on macOS, but leaves gaps such as signed malware, insider-approved changes, and non-malware persistence vectors.
- T1547.008detects — A.8.7 requires regular automated validation of system software/content, malware detection software with scanning (including of received data, email, webpages), collection of new malware intel, and anomaly investigation, which can surface LSASS driver modifications as unauthorized changes or known malware but only where the driver is scanned, matches known signatures, or triggers configured validation — leaving many fileless/persistence-only cases undetected.
- T1547.008prevents — A.8.7's rules to prevent unauthorized software (allowlisting), reduce exploitable vulnerabilities, scan for malware before use, and configure detection tools based on risk assessment can stop addition/replacement of illegitimate LSASS drivers on Windows endpoints, but this is only a slice — the clause is silent on credential dumping that often precedes the persistence step, on drivers loaded via signed-but-malicious means, and on the LSA itself being the attack surface.
- T1547.009detects — A.8.7 requires regular automated validation of system software/content (d), scanning of received files/emails/webpages (f), collection of new malware info (n), and awareness of indicators (m), which can surface malicious shortcuts or anomalous changes in startup contexts, but this is limited to specific scan points and does not broadly instrument shortcut creation/modification itself.
- T1547.009prevents — A.8.7's malware detection, allowlisting, vulnerability reduction, scanning of received files/emails/webpages, and awareness directly stop many delivery vectors (e.g. malicious LNKs arriving via email, web, or unapproved software) that lead to shortcut modification for persistence, but do not block all local post-compromise abuse of existing shortcuts or startup-folder edits once inside.
- T1547.010detects — A.8.7 requires regular automated validation of system software/content, malware detection software with scans (including on received data, email, webpages), collection of new malware intel, and anomaly investigation, which can surface port monitor DLL anomalies or known malicious payloads but does not broadly instrument the specific registry/API technique itself.
- T1547.010prevents — A.8.7 guidance on malware detection/repair software, reducing exploitable vulnerabilities, preventing unauthorized software via allowlisting, scanning received data/files, and awareness/training directly stops many (but not all) vectors for introducing/running the malicious DLL at boot
- T1547.012detects — A.8.7 requires regular automated validation of system software/content (d), malware detection software with scans of files/downloads/webpages (f), collection of new malware intel (n-o), and awareness of anomalous behaviors, all of which can surface a malicious print processor DLL or registry change after it is present but before or during execution.
- T1547.012prevents — A.8.7's malware detection/repair, allowlisting, vulnerability reduction, unauthorized software rules, and awareness directly stop many vectors for installing/running malicious print-processor DLLs at boot, but leave gaps such as signed or evasive payloads, privileged insider abuse of AddPrintProcessor, and maintenance bypasses.
- T1547.013detects — A.8.7 requires regular automated validation of system content, scanning of received data/email/webpages, collection of new malware intel, and placement of detection tools based on risk (including at endpoints and servers), which can surface malicious autostart .desktop entries or the binaries they launch; partial because detection is not required for every possible modification vector or pre-execution change to config files in user directories.
- T1547.013prevents — A.8.7 guidance on application allowlisting (8.19), reducing vulnerabilities (8.8), preventing unauthorized software use, scanning for malware before execution, and awareness directly stops many (but not all) malicious autostart .desktop entries from running at login on Linux
- T1547.014detects — A.8.7 requires regular automated validation of system software/content, malware detection software with scans (including on received data, email, webpages), collection of new malware intel, and awareness to identify suspicious files/programs; this surfaces some Active Setup registry abuses when they involve known malware signatures or anomalous files, but leaves most registry-only persistence (no dropped file, no known signature, post-login execution) undetected.
- T1547.014prevents — A.8.7 guidance on malware detection/repair software, reducing exploitable vulnerabilities, preventing unauthorized software via allowlisting, scanning received files/emails/web content, and awareness/training directly stops many (but not all) malware delivery vectors that would plant the Active Setup StubPath key for persistence.
- T1547.014responds — A.8.7 explicitly requires business continuity plans, isolating high-risk environments, defined procedures for reporting/recovering from malware attacks, and training on mitigation, all of which constitute responding once a malware-based persistence technique like Active Setup execution is underway.
- T1547.015detects — A.8.7 requires regular automated validation of system software/content (d), scanning of received data/email/webpages (f), collection of new malware info (n), and placement of detection tools based on risk (g), which can surface login-item malware on macOS when it matches known signatures or triggers scans; this is only a slice because the technique is a legitimate persistence mechanism often added via AppleScript/Native API without delivering a detectable malicious binary or file signature.
- T1547.015prevents — A.8.7's rules to prevent unauthorized software (allowlisting), reduce exploitable vulnerabilities, block malicious sites, scan for malware before execution, and use awareness/training close off many vectors for adding and persisting via malicious login items, but do not stop all legitimate-app abuse of the SMLoginItemSetEnabled API or all post-compromise scripting that can still create them.
- T1548detects — A.8.7 requires regular automated validation of system content, malware scans at multiple layers (including email, web, downloads, and endpoints), collection of new malware intel, and awareness-driven reporting, which can surface some abuse of elevation mechanisms when delivered via or exhibiting malware-like behavior, but leaves the bulk of native, non-malware elevation abuse (UAC bypass, sudo abuse, etc.) outside its malware-specific scope.
- T1548.001detects — A.8.7 requires regular automated validation of system software/content, scanning of received data/email/webpages, collection of new malware info, and placement of detection tools based on risk (including defense-in-depth at endpoints/servers/gateways), which can surface setuid/setgid abuse when it involves known malware binaries or anomalous files, but does not broadly detect the configuration change or discovery step itself.
- T1548.002detects — A.8.7 requires regular automated validation of system software/data content, scanning of received files/emails/webpages, collection of new malware intel, and awareness of evasive techniques, which can surface some UAC-bypass malware or anomalous files but does not broadly instrument for the technique's many living-off-the-land or configuration-based methods.
- T1548.002prevents — A.8.7's malware detection, vulnerability reduction, unauthorized software rules, awareness, and scanning directly stop many malware-based UAC bypasses (e.g. injected DLLs or malicious executables), but not all listed methods (e.g. auto-elevating binaries like eventvwr.exe, COM object abuse, or credentialed lateral movement)
- T1548.003detects — A.8.7 explicitly requires regular automated validation of system software/data content, scanning of received files/emails/webpages, collection of new malware information, and verification of sources, which can surface malicious changes to sudoers or related files as anomalous/unapproved amendments, but this is only a slice of the technique's possible vectors (e.g., in-memory abuse of timestamp without file changes)
- T1548.004detects — A.8.7 requires regular automated validation of software/content, malware detection software with scans (including of received files, downloads, webpages), collection of new malware intel, and procedures to deal with/report malware; these surface some instances of this macOS-specific privilege-escalation technique (especially when it results in detectable malicious software or anomalous files) but do not broadly instrument or surface the API call, world-writable file abuse, or masquerading aspects themselves.
- T1548.004prevents — A.8.7's rules to prevent unauthorized software (allowlisting), reduce exploitable vulnerabilities, block malicious sites, scan before use, and protect external file/software intake stop many vectors for delivering or running the malicious program that would call AuthorizationExecuteWithPrivileges, but do not stop all (e.g. world-writable file modification of a legitimate signed binary already present, or user-approved masquerading).
- T1548.005detects — A.8.7 requires regular automated validation of system content, malware scans at multiple layers (email, web, downloads, endpoints), collection of new malware intel, and procedures for reporting malware incidents, which can surface some misconfigurations or anomalous permission-use artifacts that deliver malware but does not broadly detect the permission-abuse technique itself.
- T1548.006detects — A.8.7 requires regular automated validation of system software/data content, scanning of received files/emails/webpages, malware detection software placement based on risk, and procedures for reporting malware, which can surface TCC database tampering or anomalous permission grants on macOS as suspicious activity, but only as a minority slice given its primary focus on traditional malware rather than permission-abuse techniques.
- T1548.006prevents — A.8.7's malware detection, vulnerability reduction, unauthorized software rules, awareness, and scanning can block some delivery vectors or exploited flaws that lead to TCC manipulation (e.g. via injected processes or unapproved binaries), but do not address the core TCC database abuse, SIP bypass, or privilege inheritance techniques on macOS.
- T1550detects — A.8.7 requires regular automated validation of system software/data content, scanning of received files/emails/webpages, collection of new malware intel, and anomaly-oriented awareness training, all of which can surface malware that has already stolen or is using alternate auth material; this is genuine but only a minority slice of the technique (most T1550 abuse is not delivered by or accompanied by detectable malware).
- T1550.001detects — A.8.7 requires regular scans, automated validation of systems/data, collection of new malware info, and awareness training that can surface indicators of token-theft malware (e.g. via endpoint scans or anomalous files), but does not address token abuse over legitimate API channels that requires no malware delivery.
- T1550.002detects — A.8.7 requires regular automated validation of system software/data content, scanning of received files/emails/webpages, collection of new malware intel, and anomaly-oriented awareness training, all of which can surface PtH artifacts or anomalous use of hashes on Windows endpoints; this is a genuine but minority slice of the technique (credential use after initial capture, not the malware delivery vector itself).
- T1550.003detects — A.8.7 requires regular automated validation of system software/data content, scanning of received files/emails/webpages, collection of new malware intel, and monitoring for anomalous behavior that can surface PtT artifacts (e.g. unexpected Kerberos ticket use or dumped credentials), but this is scoped by risk assessment and does not guarantee detection of all PtT variants especially those using golden/silver tickets or overpass-the-hash.
- T1550.004detects — A.8.7 requires malware detection/repair software, regular scans of received data/email/webpages, awareness of malware-infected files, and collection of new malware intel; these surface malware that targets or steals session cookies (explicitly noted in the T1550.004 prose), but do not detect the post-theft use/import of an already-stolen cookie itself.
- T1552detects — A.8.7 requires regular automated validation/scans of systems (d,f), malware detection software placement based on risk (g), and procedures to collect/verify malware information (n,o), which can surface unsecured credential files as suspicious or anomalous when they match known malware patterns or indicators, but this is indirect, not guaranteed for all credential forms/locations, and leaves most non-malware-linked instances undetected.
- T1552prevents — A.8.7's rules to prevent unauthorized software, reduce exploitable vulnerabilities, scan for malware, and block malicious sites can stop some malware that would otherwise place or expose unsecured credentials, but the control does not address insecure storage of credentials already present on the system.
- T1552recovers — A.8.7 point j) explicitly requires business continuity plans that include data and software backup plus recovery measures for recovering from malware attacks; when malware delivers or enables credential theft (T1552), those backups let the organization restore the pre-compromise state.
- T1552.001detects — A.8.7 requires regular automated validation/scans of systems (d,f), malware detection software placement based on risk (g), and procedures to collect/verify malware info (n,o), which can surface known malware or anomalies tied to credential-harvesting files; this is a genuine but minority slice of the technique (e.g. post-compromise scanning for known droppers or anomalous credential files), not the dominant search behavior itself.
- T1552.001prevents — A.8.7's rules to prevent unauthorized software, reduce exploitable vulnerabilities, scan for malware before use, and block malicious sites constrain some vectors for credential-harvesting malware or unauthorized credential-dumping tools, but do not stop an adversary (or insider) from simply reading already-present insecure credential files that were placed legitimately or via non-malware means.
- T1552.001recovers — A.8.7 point j) explicitly requires business continuity plans including backups and recovery measures for recovering from malware attacks, which can restore systems and data after malware has already searched for and exfiltrated credentials from files.
- T1552.002detects — A.8.7 requires regular automated validation of system content, malware scans at multiple layers (including endpoints and servers where the Registry lives), anomaly investigation for unauthorized changes, and awareness-driven reporting of suspicious activity, all of which can surface Registry queries or unexpected credential-storing keys as potential malware indicators; this is only a slice because the control is scoped to malware artifacts and does not mandate general credential or Registry monitoring.
- T1552.003detects — A.8.7 requires regular automated validation of system content (d), scans of received data/email/webpages (f), collection of new malware info (n), and monitoring/reporting procedures (l,m) that can surface anomalous history-file access or unexpected credential patterns as malware indicators, but this is indirect, scope-limited by risk assessment (g), and does not target credential-in-history artifacts themselves.
- T1552.004detects — A.8.7 requires regular automated validation of system content, malware scans (including on received data, email, webpages), collection of new malware intel, and procedures to deal with/report malware, which can surface private-key files if they match known malware signatures, anomalous patterns, or unapproved content, but this is limited to cases where the keys are delivered via or resemble malware rather than general credential-search behavior.
- T1552.004prevents — A.8.7's rules to prevent unauthorized software, reduce exploitable vulnerabilities, block malicious sites, scan for malware before use, and use allowlisting directly stop many vectors that would place or allow discovery of insecure private keys on systems, but do not address already-present keys, export via CLI, or passphrase attacks.
- T1552.005detects — A.8.7 requires regular automated validation of system content, malware scans at multiple layers (including network gateways, email, web, endpoints), anomaly-oriented awareness training, and collection of new malware intelligence, all of which can surface the anomalous queries or SSRF patterns that realize T1552.005; this is genuine but only a slice because the control is scoped to malware artifacts and does not mandate general behavioral detection of credential-access or metadata API abuse.
- T1552.005recovers — A.8.7 point j) explicitly requires business continuity plans including backups and recovery measures for recovering from malware attacks, which can restore state after credentials are exfiltrated via the metadata API (a malware-enabled technique).
- T1552.006detects — A.8.7 requires regular automated validation of system content, scanning of received data/email/webpages, collection of new malware info, and monitoring for malware indicators, which can surface GPP XML files containing embedded credentials when they are treated as suspicious or scanned as part of malware detection workflows, but this is not a primary or reliable method for the credential-harvesting technique itself.
- T1552.006prevents — A.8.7's rules to prevent unauthorized software (allowlisting), reduce exploitable vulnerabilities, block malicious sites, scan for malware before use, and protect against external file introduction all constrain the delivery/execution path that lets an adversary reach and run the GPP enumeration tools or scripts on SYSVOL, but do not stop an already-authenticated domain user from simply viewing the share and decrypting the public-key-protected credentials that are the core of the technique.
- T1552.007detects — A.8.7 requires regular automated validation of system content, malware scans (including on received data, emails, webpages), collection of new malware intel, and monitoring/reporting procedures that can surface anomalous container API access or credential-gathering artifacts when they match known malware patterns or signatures, but this is only a slice of the technique's stealthy, permission-based credential access that does not rely on malware delivery.
- T1552.007recovers — A.8.7 point j) explicitly requires business continuity plans including backups and recovery measures for recovering from malware attacks, which can restore state after credential-gathering via container APIs if malware was the delivery vector.
- T1552.008detects — A.8.7 requires regular automated validation/scans of systems and data (including email/IM attachments, webpages, and received files), malware detection software placement based on risk, and procedures for reporting malware incidents, which can surface credential-sharing in chat as anomalous/malicious behavior on endpoints, email servers, or networks, but does not broadly instrument or guarantee detection of credential extraction from chat services, SaaS portals, admin interfaces, or compromised integration tools.
- T1552.008recovers — A.8.7 point j) explicitly requires business continuity plans that include data/software backup and recovery measures for recovering from malware attacks; while the technique is credential theft via chat services (not malware), the control's recovery posture addresses post-compromise restoration after credential abuse leads to malware delivery or impact.
- T1553detects — A.8.7 explicitly requires malware detection/repair software, regular automated validation/scans of systems/data/files/emails/webpages, and collection of new malware information, which surfaces many (but not all) subversions of trust controls that involve malware delivery or execution
- T1553prevents — A.8.7 guidance (a,b,c,f,g) directly prevents execution of untrusted/malicious programs via allowlisting, blocklisting, vulnerability reduction, and multi-layer malware detection/repair, covering a genuine slice of T1553's trust-subversion methods (e.g. unsigned or web-sourced binaries) while leaving certificate theft, registry/permission mods, and signed-malware evasion as named residuals.
- T1553.001detects — A.8.7 explicitly requires regular automated validation of software/content (d), scanning of received files/media/email/webpages (f), collection of new malware intel (n-o), and placement of detection tools based on risk (g), which surfaces Gatekeeper-bypassing malware on macOS once present; this is limited to a slice because the control is platform-agnostic, relies on malware signatures rather than Gatekeeper-specific logic errors or unsigned attribute manipulation, and does not guarantee detection of novel/undiscovered bypasses.
- T1553.001prevents — A.8.7 explicitly requires rules/controls that prevent unauthorized software (e.g. application allowlisting), reducing exploitable vulnerabilities, protective measures for files from external sources, and malware detection/repair that scans before use — all of which close the primary vectors (quarantine flag evasion, unsigned/unnotarized binaries from USB/network/curl, and first-launch bypasses) for T1553.001; it is only partial because the control is a set of practices whose coverage depends on implementation rigor and does not guarantee every Gatekeeper subversion (e.g. logic errors or post-Ventura edge cases) is stopped.
- T1553.002detects — A.8.7 requires regular automated validation of software content, scanning of received data/email/webpages, collection of new malware info from reputable sources, and awareness training that can surface signed malicious binaries when they deviate from expected signatures or trigger behavioral alerts, but this is limited to post-introduction detection and does not systematically catch adversary-created/ stolen code-signing materials used to bypass policies.
- T1553.003detects — A.8.7 explicitly requires regular automated validation of software/content (d), scanning of received data/email/webpages (f), collection of new malware info (n), and verification of reputable sources (o), which can surface hijacked SIP/trust-provider components when they cause detectable anomalies or are flagged by updated detection tools; this is only a slice because the technique can be implemented stealthily (e.g. in-memory registry redirection or already-present DLLs) without introducing recognizable malware artifacts.
- T1553.003prevents — A.8.7's malware detection/repair, vulnerability reduction, unauthorized software rules, awareness, and change management directly address some delivery vectors and post-hijack scanning but do not stop the core registry/DLL tampering or SIP hijack that subverts trust validation itself.
- T1553.003recovers — A.8.7 point j) explicitly requires business continuity plans that include backup and recovery measures for recovering from malware attacks, which restores state after a realized hijacking that delivered/persisted malware.
- T1553.004detects — A.8.7 requires regular automated validation of system software/content, scanning of received data/email/webpages, collection of new malware intel from reputable sources, and risk-based placement of detection tools, all of which can surface atypical or malicious root-certificate installation (especially when tied to malware delivery or supply-chain compromise) but do not guarantee coverage of every vector, platform, or cloning method described in the technique.
- T1553.004prevents — A.8.7 explicitly requires reducing exploitable vulnerabilities (via 8.8/8.19), blocking known/suspected malicious sites, scanning for malware before use (including downloads and webpages), awareness training on malware-infected files, and defence-in-depth placement of detection tools; these directly stop the delivery vectors, supply-chain pre-installs, and malware-driven root-certificate installation named in T1553.004, but leave a remainder for supply-chain manufacturer pre-installs, cloned certs used only for code-signing bypass, and non-malware administrative installation after initial compromise.
- T1553.004recovers — A.8.7 point j explicitly requires business continuity plans that include data/software backup and recovery measures for recovering from malware attacks, and the technique is realized by malware (Ay MaMi, Superfish, etc.) that installs the root cert.
- T1553.005detects — A.8.7 explicitly requires regular automated validation/scans of systems plus malware detection software that scans received data, email attachments, downloads, and webpages before use, which surfaces many container-based MOTW-bypass payloads once they reach the network or endpoint; it does not guarantee detection of every evasion (e.g. encrypted delivery or offline extraction) so the coverage is a genuine but incomplete slice.
- T1553.005prevents — A.8.7 explicitly requires rules/controls that prevent unauthorized software (e.g. application allowlisting), reducing exploitable vulnerabilities, scanning data received over networks or on media before use, protective measures for files from external networks, and defence-in-depth placement of detection tools; these directly stop many (but not all) container-based MOTW-bypass delivery paths before malicious code executes.
- T1553.005recovers — A.8.7 explicitly requires business continuity plans that include backup and recovery measures for recovering from malware attacks (item j), which restores assets after a successful MOTW-bypass delivery and execution of malware
- T1553.006detects — A.8.7 requires regular automated validation of system software/content, malware scans (including on received data, email, webpages), collection of new malware intel, and awareness procedures that can surface policy-modification artifacts or anomalous unsigned/self-signed execution attempts, but this is scoped only to malware-focused detection rather than the full technique (e.g., registry/kernel changes or test-signing mode without delivered malware).
- T1553.006prevents — A.8.7 requires rules/controls that prevent unauthorized software (explicitly naming application allowlisting), reducing exploitable vulnerabilities, and protective measures against obtaining malicious files, all of which stop the adversary from successfully modifying and bypassing code signing policy enforcement in many cases; it is only partial because the clause is silent on kernel-memory attacks, debug/recovery mode, and the specific policy-modification vectors themselves.
- T1554detects — A.8.7 explicitly requires regular automated validation/scans of software content (including binaries on critical systems), malware detection/repair tools placed per risk assessment, scanning of received files/media/emails/webpages, and procedures to collect/verify new malware info, all of which surface modifications or malicious replacements of host binaries.
- T1554prevents — A.8.7's malware detection/repair, vulnerability reduction, unauthorized software rules, integrity validation scans, and awareness directly stop many binary replacement/infection vectors before they succeed, but patching, entry-point hooking, and post-modification update-blocking are not malware and sit outside the clause's primary mechanisms.
- T1554responds — A.8.7 explicitly requires preparing business continuity plans, isolating environments, defining procedures for reporting/recovering from malware attacks, and handling malware via detection/repair software and awareness, which responds to (contains, eradicates) a realized T1554 infection once underway, but only for the malware-delivery slice of the technique and not the full class (e.g. non-malware binary patching or version-locking).
- T1555detects — A.8.7 requires malware detection software, regular scans of files/data/emails/webpages, anomaly validation of system content, and awareness of new malware, which can surface credential-harvesting malware (or its artifacts) but does not broadly detect the T1555 search technique itself when performed without malware.
- T1555.001detects — A.8.7 requires regular automated validation/scans of systems and media (including for unapproved files/amendments), malware detection software placement based on risk, collection of new malware info, and procedures for reporting malware attacks, which can surface Keychain access/abuse as anomalous or malicious behavior on macOS endpoints; this is only a slice because the clause centers on generic malware rather than credential-access TTPs, with detection depending on whether the specific Keychain read is flagged by the configured tools or training.
- T1555.001recovers — A.8.7 point j) explicitly requires business continuity plans that include data/software backup and recovery measures for recovering from malware attacks; while the technique is credential theft rather than malware, the control's recovery provisions (and cross-reference to 8.13) can restore the affected Keychain state or credentials after the technique has run.
- T1555.002detects — A.8.7 explicitly requires regular automated validation/scans of systems plus malware detection software that surfaces malware (including via memory-resident techniques on endpoints), but this is scoped to malware artifacts rather than the specific in-memory credential-gathering behavior of T1555.002, leaving most of the technique undetected.
- T1555.003detects — A.8.7 requires regular automated validation of system content, malware scans (including on received data, email, webpages), collection of new malware intel, and procedures to detect/report malware, which can surface browser credential theft when it involves known malware or unauthorized file changes, but this is only a slice of the technique's methods (e.g., direct file reads or memory searches without malware).
- T1555.003prevents — A.8.7 guidance (a,b,c,f,g) directly prevents the malware-delivery vector that implants browser credential stealers or memory scrapers, and (c) reduces exploitable vulns in the browser itself; it does not stop post-compromise file/memory reads that do not involve malware.
- T1555.003recovers — A.8.7 point j) explicitly requires business continuity plans that include data and software backup plus recovery measures for malware attacks; while the technique is credential theft (often malware-delivered), the control's recovery provisions restore state after such an event, but only address a slice of the technique's post-acquisition use and do not cover non-malware vectors or credential recycling.
- T1555.004detects — A.8.7 explicitly requires regular automated validation/scans of systems and data (including for unapproved files/amendments), malware detection software with scans at multiple points (email, downloads, webpages, storage media), awareness of new malware via reputable sources, and procedures for reporting malware incidents, all of which can surface T1555.004 activity when it involves known malware tools, anomalous file reads, or credential-dumping behaviors; this is only a slice because the technique can be performed with native Windows tools/APIs without introducing detectable malware.
- T1555.004recovers — A.8.7 explicitly requires business continuity plans including backups and recovery measures for malware attacks (item j), which can restore credentials or systems after a malware-enabled T1555.004 theft, but this is indirect, malware-specific, and does not address non-malware acquisition vectors or the technique itself.
- T1555.005detects — A.8.7 requires malware detection/repair software, regular scans of files/emails/webpages/media, anomaly validation of system content, and awareness of new malware sources, which can surface known malware or suspicious activity tied to credential extraction from password manager processes/memory/files on supported platforms, but does not broadly instrument for the technique's exploitation, memory dumping, or brute-force vectors.
- T1555.005prevents — A.8.7's malware detection, vulnerability reduction, unauthorized software rules, website blocklisting, scanning of files/emails/webpages, and awareness directly stop many delivery vectors (e.g. malicious email attachments or downloads containing credential-stealing malware) that realize T1555.005, but leave memory scraping, exploitation for credential access, and brute-force of an already-unlocked manager untouched.
- T1555.005recovers — A.8.7 point j) explicitly requires business continuity plans that include data/software backup and recovery measures for recovering from malware attacks, which directly restores state after credential theft via password-manager malware (T1555.005)
- T1555.006detects — A.8.7 requires regular automated validation of systems, malware scanning of data/email/web content, collection of new malware intel, and monitoring for anomalous use of unauthorized software or websites, which can surface some T1555.006 activity (e.g. anomalous API calls or downloads) but does not broadly instrument or detect credential requests from cloud secrets managers.
- T1555.006recovers — A.8.7 point j) explicitly requires business continuity plans that include backup and recovery measures for recovering from malware attacks; the technique's impact (acquired credentials) can be recovered from by rotating/revoking the compromised secrets and restoring from clean backups where the technique ran via malware.
- T1556detects — A.8.7 mandates regular automated validation of system software/data content, scanning of received files/emails/webpages, collection of new malware intel, and awareness of malware indicators, which can surface some authentication-process modifications that introduce or exhibit malware-like artifacts, but most T1556 variants (e.g., in-memory PAM/LSASS hooks without files) fall outside malware-focused detection.
- T1556prevents — A.8.7's malware detection, vulnerability reduction, unauthorized software prevention (allowlisting), and awareness/training reduce some vectors for delivering or executing the modification (e.g. via malicious files or unpatched exploits), but do not stop an already-present adversary from directly altering auth mechanisms like LSASS, PAM, or plugins.
- T1556recovers — A.8.7 point j) explicitly requires business continuity plans including backups and recovery measures for recovering from malware attacks, which can restore state after a T1556 modification that used malware delivery.
- T1556.001detects — A.8.7 explicitly requires malware detection/repair software, regular automated validation/scans of systems (including critical ones), scanning of received data/email/web content, collection of new malware intel from reputable sources, and awareness of evasive techniques, all of which surface Skeleton Key-style malware that patches LSASS on a domain controller.
- T1556.001prevents — A.8.7 explicitly prevents malware delivery/execution via allowlisting, vulnerability reduction, scanning, web/email blocking, and awareness, which stops the malware that performs the LSASS patch; it does not address non-malware vectors or post-execution persistence that survives reboot.
- T1556.001recovers — A.8.7 explicitly requires business continuity plans including backups and recovery measures (item j) to recover from malware attacks, and the technique is realized by malware (Skeleton Key) that patches LSASS in memory; recovery is therefore possible via reboot (which erases the patch) plus restoration from clean backups, but this is only a slice of the overall malware-protection control and does not address non-rebootable persistence or domain-wide credential exposure.
- T1556.001responds — A.8.7 explicitly requires procedures, responsibilities, awareness/training, and business continuity plans to deal with and recover from malware attacks once underway, which matches the malware-driven patching of LSASS in T1556.001; extent is partial because the control is scoped to malware events and does not address non-malware variants of the technique.
- T1556.002detects — A.8.7 requires regular automated validation of system software/content, malware detection software with scans (including on received data, email, webpages), collection of new malware info, and awareness/training that can surface anomalous DLL registration or malicious behavior post-install, but does not specifically target or guarantee discovery of stealthy password filter DLLs in the LSA authentication path.
- T1556.002prevents — A.8.7's rules against unauthorized software (allowlisting), vulnerability reduction, change management, and malware detection on systems/media can stop malicious DLL registration and loading in many cases, but the technique's integration into the LSA authentication path on domain controllers leaves a real remainder that the clause does not universally block.
- T1556.003detects — A.8.7 requires regular automated validation of system software/content, malware detection software with scanning (including of received data, email, webpages), collection of new malware info, and procedures to deal with/report malware attacks, which can surface malicious PAM modifications as anomalous files or malware on Linux/macOS systems, but this is only a slice since many PAM patches are not recognized malware signatures and fall outside routine scan coverage.
- T1556.003prevents — A.8.7's malware detection/repair, vulnerability reduction, unauthorized software rules, awareness, and scanning directly prevent many infection vectors that deliver the PAM-modifying malware, but do not stop all supply-chain, insider, or already-resident modification techniques that realize the technique.
- T1556.003recovers — A.8.7 point j) explicitly requires business continuity plans including backups and recovery measures for recovering from malware attacks, which directly restores state after a PAM-modifying malware incident (as in the T1556.003 description)
- T1556.004detects — A.8.7 requires regular automated validation of system software/content (d), scanning of received data/media/email/webpages (f), collection of new malware info (n), and verification of sources (o), which can surface implanted backdoor code or anomalous files in network device images as malware-like artifacts; this is a genuine but minority slice given the technique's focus on targeted OS patching rather than conventional malware distribution.
- T1556.004recovers — A.8.7 point j) explicitly requires business continuity plans that include data/software backup and recovery measures for recovering from malware attacks, which directly restores state after the technique (a form of malware/patch implant) has run.
- T1556.005detects — A.8.7 requires regular automated validation of system software/data content, scanning for unapproved files/amendments, malware detection software with regular scans, and procedures to collect/verify malware information, which can surface the anomalous enabling of reversible encryption or related unauthorized changes.
- T1556.006detects — A.8.7 requires regular automated validation of system software/content, malware scanning of received data/email/webpages, collection of new malware intel, and awareness of malware indicators; these can surface some MFA-modification artifacts (e.g. unauthorized hosts-file changes, patched binaries, or suspicious MFA-method registrations) when treated as malware-like anomalies, but miss the bulk of the technique's legitimate-feature-abuse vectors and post-compromise administrative changes.
- T1556.007detects — A.8.7 requires regular automated validation/scans of systems (including critical ones), malware detection software with scans at multiple points (email, web, downloads, endpoints, servers, gateways), collection of new malware intel, and awareness of evasive techniques, which can surface DLL injections, config modifications, or anomalous PTA/AD FS behavior as malware; this is limited to a slice because the technique can be performed from the cloud side, via privileged accounts without introducing detectable malware binaries, or through stealth that evades even updated scanners.
- T1556.007recovers — A.8.7 point j) explicitly requires business continuity plans including backups and recovery measures for recovering from malware attacks, which directly restores state after a realized backdoor (e.g. via injected DLL or modified config) that qualifies as malware.
- T1556.008detects — A.8.7 requires regular automated validation of system software/content, malware scanning of received data/email/webpages, collection of new malware intel, and procedures to deal with/report malware; these can surface a malicious network provider DLL (as unauthorized software or anomalous file) but only where it is in scanned locations or matches known signatures, leaving many installation vectors and evasive techniques outside detection scope.
- T1556.008prevents — A.8.7's malware detection/repair, allowlisting, vulnerability reduction, scanning of received files/executables, and awareness directly stop many malicious DLL registration vectors (including those delivered via untrusted media, email, web, or unpatched flaws), but the technique can still be planted via authorized admin/maintenance processes, registry edits, or insider action that bypass normal malware controls.
- T1556.008recovers — A.8.7 point j) explicitly requires business continuity plans including backups and recovery measures for malware attacks, which can restore state after credential-theft malware has run.
- T1556.009detects — A.8.7 requires regular automated validation of system software/data content, scans of received files/emails/webpages, collection of new malware intel, and verification of sources, which can surface anomalous policy modifications as unauthorized changes or malware artifacts on identity systems.
- T1557detects — A.8.7 requires regular automated validation of system content, scanning of received data/email/webpages for malware before use, collection of new malware information, and verification of sources, which can surface AiTM-delivered malware or anomalous files but does not broadly detect protocol abuse like ARP/DNS poisoning or traffic interception itself.
- T1557prevents — A.8.7's malware detection, website blocklisting, vulnerability reduction, and awareness/training directly stop malware-delivery vectors that use AiTM (e.g. DNS manipulation to push malware or downgrade attacks), but do not address non-malware AiTM behaviors such as ARP poisoning, credential interception, or traffic modification.
- T1557recovers — A.8.7 point j) explicitly requires business continuity plans including backups and recovery measures for recovering from malware attacks, and AiTM is described as sometimes pushing additional malware whose realized effects (e.g. data loss or corruption) can be recovered via those backups.
- T1557.001detects — A.8.7 requires regular automated validation of system content, malware scans (including on network-received data, email, webpages), collection of new malware intel, and monitoring for anomalous activity that can surface name-resolution spoofing or malicious tools like Responder when they trigger detectable signatures or behaviors, but this is only a slice because the technique is often local-link, uses legitimate protocols without files, and evades many signature-based malware tools.
- T1557.001prevents — A.8.7 guidance on preventing unauthorized software, reducing exploitable vulnerabilities, blocking malicious sites, scanning for malware before use, and defence-in-depth placement (e.g. network gateways) can stop some poisoning/relay tools and delivery vectors on Windows, but leaves residual exposure from legitimate mDNS/LLMNR/NBT-NS traffic, relay without malware, and non-malware vectors like spoofed responses.
- T1557.001recovers — A.8.7 explicitly requires business continuity plans including backups and recovery measures (item j) for recovering from malware attacks; while T1557.001 is not itself malware, the poisoning/relay often delivers or enables malware execution whose realized impact (e.g. compromised systems, data exfiltration) can be recovered from via those plans, but this is only a slice of the technique's effects (credential theft, relay without malware) and does not address the poisoning itself.
- T1557.001responds — A.8.7 requires procedures, responsibilities, training, and business continuity plans specifically for recovering from malware attacks (points j, l); name resolution poisoning/SMB relay is a network attack that can deliver or enable malware (e.g. via Responder or BlackCat), so the control's recovery slice applies once the malware payload has executed, but most of the technique (spoofing, hash collection, relay) is outside malware recovery.
- T1557.002detects — A.8.7 requires regular automated validation of system content, scanning of received data/email/webpages, collection of new malware intel, and monitoring placement based on risk, which can surface anomalous ARP replies or unexpected MAC-IP mappings as indicators of compromise on scanned endpoints and networks, but this is limited to malware-focused detection rather than general network protocol anomalies or non-malware MITM.
- T1557.002recovers — A.8.7 point j) explicitly requires business continuity plans including backups and recovery measures for recovering from malware attacks, which can restore state after an ARP-poisoning-enabled malware incident (e.g. data exfiltration or ransomware) even though the technique itself is not malware.
- T1557.003detects — A.8.7 requires regular automated validation of system software/data content, scanning of received data/email/webpages for malware, collection of new malware intel, and procedures to detect/report malware attacks; this surfaces rogue-DHCP malware that acts as a malicious server but does not broadly detect protocol-level spoofing or exhaustion without a malware payload.
- T1557.003prevents — A.8.7's rules to prevent unauthorized software, reduce exploitable vulnerabilities, block malicious sites, scan for malware before use, and use allowlisting directly stop the malware that commonly acts as rogue DHCP server (as named in the technique prose), but do not stop a non-malware adversary from spoofing DHCP messages or exhausting the pool.
- T1557.003recovers — A.8.7 point j) explicitly requires business continuity plans including backups and recovery measures for recovering from malware attacks; the technique can be (and often is) delivered by malware acting as rogue DHCP server, so the control recovers from that vector's realized impact, but the technique also has non-malware paths (e.g. direct rogue server without malware) that sit outside the clause.
- T1557.004detects — A.8.7 explicitly requires regular automated validation of system content, scanning of received data/email/webpages for malware, collection of new malware intel, and placement of detection tools based on risk (including at network gateways), which can surface evil-twin artifacts such as rogue APs, unexpected certificates, or anomalous traffic patterns; this is genuine but only a minority slice because the control is scoped to malware rather than the broader rogue-AP or Wi-Fi impersonation technique itself.
- T1557.004recovers — A.8.7 point j) explicitly requires business continuity plans including backups and recovery measures for recovering from malware attacks, which can restore assets after an evil twin has enabled follow-on malware delivery or data manipulation.
- T1558detects — A.8.7 requires malware detection software, regular scans of systems/data/email/web content, anomaly validation of files/amendments, and awareness of new malware sources, which can surface some T1558 artifacts (e.g. malware droppers, anomalous ticket-related files, or known malicious tools) but does not target or reliably identify the technique's core behaviors like ticket dumping via klist, forgery, or memory extraction of Kerberos material.
- T1558recovers — A.8.7 point j) explicitly requires business continuity plans including backups and recovery measures for malware attacks, which can restore state after a Kerberos-ticket theft incident that delivered malware.
- T1558.001detects — A.8.7 requires regular automated validation of system software/data content, scanning for unapproved files/amendments, malware detection software with scans at multiple layers (including servers and network gateways), collection of new malware intel, and procedures for reporting malware incidents, which can surface indicators of KRBTGT compromise or golden ticket artifacts on Windows domain controllers as anomalous activity.
- T1558.001recovers — A.8.7 point j) explicitly requires business continuity plans including backups and recovery measures for recovering from malware attacks; a golden ticket (forged via KRBTGT hash obtained through credential dumping) is a realized post-compromise artifact that such recovery can restore from (e.g. by resetting KRBTGT, rebuilding affected DCs, or restoring from clean backups), with the named remainder being the window of already-issued valid tickets or unrecoverable lateral movement.
- T1558.002detects — A.8.7 requires regular automated validation of system content, malware scanning of received data/email/webpages, collection of new malware intel, and procedures to detect/report malware attacks, which can surface silver-ticket artifacts or anomalous Kerberos behavior on scanned endpoints and networks, but this is only a minority slice given the technique's offline forgery nature and lack of malware payload.
- T1558.002recovers — A.8.7 point j) explicitly requires business continuity plans including backups and recovery measures for recovering from malware attacks, which can restore state after a silver ticket (often delivered via malware) has been used.
- T1558.003detects — A.8.7 requires regular automated validation of system software/data content, scanning of received data/email/webpages, collection of new malware information, and monitoring for anomalous behavior that can surface Kerberoasting artifacts (e.g. anomalous TGS requests or RC4-encrypted ticket patterns), but this is scoped by risk assessment and does not guarantee detection of the technique itself.
- T1558.003recovers — A.8.7 point j) explicitly requires business continuity plans that include data/software backup and recovery measures for recovering from malware attacks; while Kerberoasting is not itself malware, the technique's outcome (cracked credentials enabling persistence/lateral movement) can be addressed post-incident by restoring from clean backups and resetting compromised accounts, but this is only one slice of the technique's full attack chain and impact.
- T1558.004detects — A.8.7 requires regular automated validation of system software/data content, scanning of received files/emails/webpages, collection of new malware info from reputable sources, and procedures to detect unauthorized changes or malware presence; these surface AS-REP roasting artifacts (e.g. anomalous AS-REQ traffic, unexpected encrypted blobs, or post-crack malware using the credentials) in monitored environments but do not broadly instrument the Kerberos protocol, LDAP enumeration, or offline cracking itself.
- T1558.004recovers — A.8.7 point j) explicitly requires business continuity plans that include data/software backup and recovery measures for recovering from malware attacks; while the technique is credential theft via Kerberos (not malware), the control's recovery provisions can restore affected accounts, systems or data post-compromise in a malware-like incident, but this is only a slice of the technique's impact (e.g. does not undo cracked credentials themselves).
- T1558.005detects — A.8.7 requires regular automated validation of system content, malware detection software with scans (including of files received over networks or on media), monitoring for new malware info, and awareness procedures that can surface anomalous credential-cache files or unauthorized changes when they match known malware patterns or indicators, but ccache theft is typically a quiet file read with no malware involved and many placements fall outside the malware-focused scope.
- T1558.005prevents — A.8.7's malware rules, allowlisting, vulnerability reduction, scanning of received files/emails/webpages, and awareness directly stop many delivery vectors that would plant tools (e.g. Kekeo) used to steal ccache files, but do not stop an already-authenticated user or process from simply reading the /tmp krb5cc_* file that the OS legitimately creates.
- T1558.005recovers — A.8.7 explicitly requires preparing business continuity plans that include data/software backup and recovery measures for recovering from malware attacks; while the technique is credential theft rather than malware, the control's recovery provisions (including offline backups and isolation) can restore affected systems or credentials post-incident in some cases, but this is not the control's primary focus or a direct match for ccache theft artifacts.
- T1559detects — A.8.7 requires malware detection software, regular scans of data/email/web content, anomaly validation of system files, awareness of malware indicators, and collection of new malware intel, which can surface some IPC-abusing malware (e.g. via endpoint scans or known malicious payloads) but does not broadly instrument or detect native IPC abuse techniques themselves.
- T1559.001detects — A.8.7 requires regular automated validation of system software/data content, scanning of received files/emails/webpages, collection of new malware intel, and monitoring for anomalous behavior that can surface COM-based code execution or related artifacts when they match known malware patterns or violate allowlists, but this is limited to detectable instances rather than all COM abuse (e.g., novel or fileless variants).
- T1559.001prevents — A.8.7's malware detection, vulnerability reduction, unauthorized software rules, website blocklisting, and awareness/training directly stop many COM-abusing malware vectors (e.g. via email, downloads, unpatched flaws, or malicious code), but do not address legitimate COM usage by native Windows processes or non-malware adversary tools.
- T1559.002detects — A.8.7 requires regular automated validation of software/data content, scanning of received files/emails/webpages, collection of new malware intel, and placement of detection tools based on risk (including at email servers, endpoints, gateways), which surfaces DDE-based Office/CSV payloads as anomalous or malicious when they match known patterns or trigger scans, but leaves gaps for novel/encrypted/evasive DDE uses or post-compromise local invocation without matching malware signatures.
- T1559.002prevents — A.8.7 explicitly requires rules/controls that prevent unauthorized software (e.g. application allowlisting), reducing exploitable vulnerabilities, blocking malicious sites, scanning data/files before use, and awareness training, all of which stop many DDE-based execution vectors (especially Office/CSV document abuse and external delivery); it does not address DDE protocol enablement via registry, in-memory IPC on already-compromised hosts, or all evasion techniques.
- T1559.003detects — A.8.7 requires malware detection/repair software, regular automated validation of system content, scanning of received data/email/webpages, and awareness of new malware, which can surface XPC-borne malicious content or anomalous files on macOS but only where the malware is known or produces detectable artifacts, not the technique's core abuse of improper validation/sanitization in the XPC handler itself.
- T1559.003prevents — A.8.7's malware detection, input scanning (email/web/files), vulnerability reduction, allowlisting, website blocklisting, and awareness directly close several vectors for delivering malicious content to XPC services (especially via untrusted files, networks, or unsanitized inputs), but leave a bounded remainder: macOS-specific XPC protocol flaws, client validation errors, and privilege-escalation paths that are not malware-borne.
- T1560detects — A.8.7 requires malware detection software, regular scans of data/files/emails/webpages, anomaly validation of system content, and awareness of new malware indicators, which can surface compressed/encrypted exfil staging artifacts when they match known malware patterns, suspicious files, or evasive delivery; this is only a slice because the technique is legitimate compression/encryption that is not inherently malicious and is frequently performed by benign software or custom methods that evade signature-based detection.
- T1560recovers — A.8.7 point j explicitly requires business continuity plans that include backup and recovery measures for recovering from malware attacks, which directly restores state after an attack that may have used T1560 to prepare exfiltrated data.
- T1560.001detects — A.8.7 requires regular automated validation/scans of systems plus malware detection software that can surface anomalous files, unauthorized amendments, or known malicious content (including in archives or downloads), but this is scoped to malware-focused detection rather than reliably catching all legitimate archiving utilities or their use for exfiltration packaging.
- T1560.001recovers — A.8.7 point j) explicitly requires business continuity plans including backups and recovery measures for recovering from malware attacks; the technique's packaging (often via malware or post-compromise tooling) is an early step in the malware-driven exfiltration chain whose realized impact (lost or encrypted data) is restored by those measures.
- T1560.002detects — A.8.7 requires regular automated validation/scans of systems plus malware detection software that can surface anomalous compressed/encrypted archives or library usage when configured to do so (e.g. via risk-based placement at gateways/endpoints), but this is not its primary purpose and many library-based archival behaviors (especially benign or custom-linked) remain undetected.
- T1560.002recovers — A.8.7 point j explicitly requires business continuity plans that include data and software backup plus recovery measures for recovering from malware attacks; while T1560.002 itself is not a malware attack, the same recovery apparatus (restoring from backup) would restore the pre-archived state after any realized impact, but this is only a slice of the technique's scope (pre-exfil compression/encryption that may not involve malware).
- T1560.003detects — A.8.7 requires malware detection software, regular scans of data/email/web content, anomaly validation of files/amendments, and awareness of new malware sources, which can surface custom archival (e.g. XOR/stream cipher) artifacts when they match known patterns or produce observable anomalies, but this is limited to a slice because purely custom implementations often evade signature-based detection and the clause does not mandate behavioral or memory-based detection of the technique itself.
- T1560.003prevents — A.8.7's rules to prevent unauthorized software (allowlisting), reduce exploitable vulnerabilities, block malicious sites, scan for malware before use, and isolate high-risk environments stop many (but not all) custom-method implementations that rely on unapproved tools, unpatched vectors, or external delivery
- T1560.003recovers — A.8.7 point j explicitly requires business continuity plans that include data and software backup plus recovery measures for recovering from malware attacks; the custom-archival technique is a common post-collection step in malware-driven exfiltration, so the control's recovery apparatus addresses the realized impact (restoring the exfiltrated or encrypted data) with the usual named remainder of data written after the last backup.
- T1561detects — A.8.7 requires regular automated validation of system content, malware detection software with scans (including of received data, email, webpages), collection of new malware intel, and procedures for reporting malware attacks, which can surface disk-wiping malware (especially when it uses propagation or known malicious payloads) but does not address non-malware CLI-based wipes on network devices or post-execution disk corruption that evades signature-based detection.
- T1561prevents — A.8.7's malware detection/repair, vulnerability reduction, unauthorized software prevention (allowlisting), website blocklisting, scanning of incoming files/emails/webpages, and awareness directly stop many malware-based disk-wipe vectors before execution; however, non-malware CLI erase on network devices, insider direct writes, and post-breach propagation via valid accounts remain outside its scope.
- T1561recovers — A.8.7 explicitly requires preparing business continuity plans including data/software backups and recovery measures (item j) to recover from malware attacks, and T1561 is commonly realized by malware (with worm-like propagation) that wipes disks to destroy availability.
- T1561responds — A.8.7 explicitly requires business continuity plans, isolating high-impact environments, procedures for recovering from malware attacks, and awareness/training on responding to malware incidents, which directly addresses containment/eradication once disk-wiping malware is underway; partial because the clause is scoped to malware vectors and does not address non-malware disk wipes (e.g. direct CLI erase on network devices) or post-impact recovery of already-wiped data.
- T1561.001detects — A.8.7 explicitly requires regular automated validation/scans of systems (especially critical ones), malware detection software with scans of storage media/data received, and procedures for reporting malware attacks, which would surface disk-wiping malware or anomalous disk changes in many cases, but not all (e.g. fully offline, pre-execution, or evasive/encrypted delivery per its own guidance).
- T1561.001prevents — A.8.7's malware detection, vulnerability reduction, unauthorized software prevention, scanning, and awareness directly stop many malware-based disk-wipe vectors before execution, but leave open non-malware vectors, direct hardware access, and post-infection execution that the control does not address.
- T1561.001recovers — A.8.7 explicitly requires preparing business continuity plans including data/software backup and recovery measures (item j) to recover from malware attacks, and T1561.001 is a malware technique that wipes disk content to destroy availability.
- T1561.001responds — A.8.7 explicitly requires business continuity plans, isolating high-impact environments, procedures for recovering from malware attacks, and awareness/training on mitigating malware (including destructive variants), which directly addresses containment/eradication once a disk-wiping malware event is underway; partial because it is scoped to malware vectors and does not broadly respond to non-malware disk-wipe methods or all propagation techniques listed.
- T1561.002detects — A.8.7 explicitly requires regular automated validation of system software/data content (d), scanning of received data/email/webpages (f), collection of new malware intel (n-o), and placement of detection tools based on risk (g), which can surface disk-wipe malware before or during execution on monitored vectors; this is limited to a slice because the technique can be deployed via already-resident privileged malware, direct CLI reformatting, or maintenance bypasses (h) outside the scanning scope.
- T1561.002prevents — A.8.7's malware detection, vulnerability reduction, unauthorized software rules, awareness, and continuity planning (including isolating critical environments) stop many malware-borne disk-wipe vectors before execution, but the technique can still be delivered via non-malware means (CLI format, legitimate admin tools, or unknown malware) that the clause does not block.
- T1561.002recovers — A.8.7 explicitly requires preparing business continuity plans including data/software backup and recovery measures (item j) to recover from malware attacks, and T1561.002 is commonly realized by malware (e.g. Shamoon) whose disk-structure destruction is restored by those backups.
- T1561.002responds — A.8.7 explicitly requires business continuity plans, isolating critical environments, procedures for recovering from malware attacks, and handling malware incidents (including training and response), which directly addresses containment/eradication once a disk-wiping malware event is underway, but only covers the malware vector and leaves non-malware wipe methods (e.g. direct CLI format) as a named remainder.
- T1563detects — A.8.7 requires malware detection software, regular scans of files/downloads/webpages, anomaly validation of systems, and awareness of malware indicators; these can surface some hijacking techniques that rely on malware delivery or post-hijack artifacts (e.g. anomalous files or processes), but the core session-hijacking behavior itself is not a malware artifact and is mostly outside the clause's malware-focused scope.
- T1563.001detects — A.8.7 requires regular automated validation of system content, scanning of received data/email/webpages, collection of new malware intel, and monitoring for anomalous behaviour that can surface SSH agent compromise or hijack attempts, but this is scoped by risk assessment and does not guarantee detection of all in-memory agent/socket hijacks especially post-root or via evasive techniques.
- T1563.002detects — A.8.7 requires regular automated validation/scans of systems (d,f), collection of new malware info (n,o), awareness training on identifying malware (m,l), and anomaly-oriented placement of detection tools (g), all of which can surface RDP hijacking artifacts (e.g. tscon.exe abuse, unauthorized session changes, or associated malware) when they match known patterns or trigger integrity checks, but this is only a slice because the technique is primarily a living-off-the-land privilege-escalation/lateral-movement action that does not require or introduce detectable malware in most executions.
- T1563.002responds — A.8.7 explicitly requires business continuity plans, isolating high-risk environments, procedures for reporting/recovering from malware attacks, and awareness training on handling infected sessions/files, which together respond to (contain, eradicate, recover from) an active RDP-hijacking incident once underway, but only for the malware-delivery slice of the technique rather than native tscon.exe session theft.
- T1564detects — A.8.7 requires regular automated validation/scans of systems (d,f), malware detection software placement based on risk (g), procedures to collect/verify new malware intel (n,o), and awareness of evasion; these surface hidden artifacts or malware that uses hiding, but only where scanners or monitoring reach the isolated/hidden regions, leaving a large slice (e.g. virtualization, rootkits, un-scanned media) unreached.
- T1564prevents — A.8.7's malware detection, vulnerability reduction, unauthorized software/web blocking, scanning, and awareness directly stop many common hiding techniques (e.g. alternate data streams, rootkits, malicious files) before they can be deployed or persist, but virtualization/container isolation and certain native OS hiding features fall outside its malware-centric scope.
- T1564.001detects — A.8.7 requires regular automated validation of system content, malware scans at multiple layers (including email/web/network), collection of new malware intel, and awareness of evasive techniques, which can surface hidden malware artifacts when scans or validation explicitly include hidden files; this is only a slice because the clause centers on malware rather than generic hidden-file discovery and does not mandate scanning for every hidden non-malware object.
- T1564.001prevents — A.8.7 guidance explicitly requires rules/controls that prevent or detect unauthorized software (e.g. application allowlisting), reducing exploitable vulnerabilities, scanning for malware in files received over networks or on media before use, and protective measures against risks from external files/software, all of which stop adversaries from successfully introducing and using hidden malware files on the system; this is only a slice of the technique because legitimate hidden files (e.g. .ssh, UF_HIDDEN app data) and purely naming-based evasion remain untouched.
- T1564.002detects — A.8.7 requires regular automated validation of system software/data content, scanning for unapproved files/amendments, malware detection software with configured placement (including endpoints/servers), awareness training, and procedures to collect/verify malware info, which can surface hidden-user artifacts (e.g. anomalous plist/registry changes or files) in some cases but not reliably or comprehensively across all platforms/methods.
- T1564.003detects — A.8.7 requires regular automated validation of system software/data content, scanning of received files/emails/webpages, collection of new malware intel, and awareness training that can surface hidden-window malware artifacts when they match known signatures or produce observable anomalies, but most of the technique (plist edits, registry changes, off-screen positioning, hidden desktops, or LOLBin parenting) is not inherently malware and evades signature-based detection tools.
- T1564.004detects — A.8.7 explicitly requires regular automated validation/scans of systems plus malware detection software that can surface hidden malicious data in NTFS attributes (e.g. ADS), but this is scoped by risk assessment and does not guarantee coverage of all evasion variants or non-scanned locations.
- T1564.004prevents — A.8.7 explicitly requires reducing exploitable vulnerabilities, scanning all received data/media/email/web content for malware before use, defence-in-depth placement of detection tools, and awareness of evasive techniques; this catches many (but not all) NTFS ADS/EA hiding attempts that deliver or activate malware, leaving a remainder for post-compromise or non-malware uses of the technique.
- T1564.004responds — A.8.7 explicitly requires procedures, responsibilities, training and business continuity plans to deal with and recover from malware attacks once they have occurred, which matches the `responds` verb; however the control is scoped to malware and this technique is a generic hiding method that is not inherently malware, leaving a large remainder of non-malware uses untouched.
- T1564.005detects — A.8.7 explicitly requires regular automated validation/scans of system content (d,f), malware detection software placement based on risk (g), and procedures for reporting malware (l), which can surface hidden file system artifacts when they are scanned or when anomalous files/partitions trigger detection; this is limited to a slice because hidden/VFS implementations (reserved space, non-standard fragmentation, encrypted evasion) routinely bypass standard scanners as the clause itself notes in (g2).
- T1564.005prevents — A.8.7's rules to prevent unauthorized software (allowlisting), reduce exploitable vulnerabilities, scan for malware before use, and use defense-in-depth placement directly stop many hidden file system implementations that rely on dropped malware, unauthorized partitions, or exploited code; the remainder is adversary techniques that never introduce detectable malware (e.g. pure in-memory VFS or non-standard fragmentation of legitimate files).
- T1564.005recovers — A.8.7 explicitly requires business continuity plans including data/software backup and recovery measures (item j) to recover from malware attacks, which can encompass restoring state after a hidden file system used by malware is removed.
- T1564.006detects — A.8.7 explicitly requires regular automated validation of system content, malware detection software with scans at multiple layers (including endpoints, email, web, and network gateways), awareness of new malware, and risk-based placement of detection tools, all of which can surface hidden virtual instances or their artifacts when they interact with monitored host resources or deviate from baselines, but many evasion techniques (e.g., fully isolated VMs, encrypted payloads, or rogue ESXi VMs hidden from admin tools) remain outside typical malware-focused detection scopes.
- T1564.006prevents — A.8.7 requires malware detection/repair software, allowlisting, vulnerability reduction, scanning of downloads/executables, awareness, and configuration based on risk assessment, which can block many common vectors for dropping and running virtualization tools or emulators used in T1564.006; however, it does not address native hypervisor use, VM creation via admin tools or RC scripts, or hidden VMs on ESXi that evade typical endpoint scanning.
- T1564.006recovers — A.8.7 point j) explicitly requires business continuity plans including backups and recovery measures for recovering from malware attacks, which directly restores state after a T1564.006 virtual-instance malware event (per the event-lane recovers definition and A.8.13 anchor).
- T1564.007detects — A.8.7 explicitly requires regular automated validation of software/content, scanning of received files/email/web content for malware before use, and collection of new malware information from reputable sources; these surface VBA-stomped documents when the p-code is recognized by up-to-date detection tools, but many scanners only inspect source (which is deliberately benign) and the technique's version-match evasion leaves a genuine unaddressed slice.
- T1564.007prevents — A.8.7 explicitly requires reducing exploitable vulnerabilities (c), preventing unauthorized software via allowlisting (a), scanning for malware before use (f), and awareness/training on malicious files (m), all of which stop VBA-stomped documents from being introduced or executed in many cases; it does not reach the p-code hiding technique itself when version match occurs and source scanners are bypassed.
- T1564.007recovers — A.8.7 point j) explicitly requires business continuity plans that include data and software backup plus recovery measures for malware attacks, which restores state after a realized T1564.007 infection; partial because the technique can also be purely evasive (no destructive payload) and recovery is scoped to post-malware-impact restoration rather than all instances.
- T1564.008detects — A.8.7 explicitly requires scanning email and instant-messaging attachments/downloads for malware before use (at multiple points including servers and endpoints), regular collection of new-malware intelligence, and awareness training on identifying malicious emails; this surfaces many rule-filtered inbound messages that contain malware keywords or payloads, but does not address non-malware hiding of alerts/C2 or purely administrative rule creation.
- T1564.008recovers — A.8.7 point j) explicitly requires business continuity plans that include data and software backup plus recovery measures for recovering from malware attacks; this restores state after the technique has hidden/deleted security-alert or C2 emails, but only for the malware-attack slice of the technique and only after impact is realised.
- T1564.009detects — A.8.7 explicitly requires malware detection software, regular automated validation of system content for unapproved files/amendments, scanning of received data/email/webpages, and awareness of new malware techniques, which can surface resource-fork hiding on macOS as anomalous or malicious; this is only a slice because the control is scoped to malware-specific tools and risk-based placement rather than universal extended-attribute or resource-fork inspection.
- T1564.009prevents — A.8.7 guidance on malware detection/repair software, reducing exploitable vulnerabilities, scanning received files/media/webpages, blocking malicious sites, and awareness/training directly stops many resource-fork hiding and execution paths on macOS before the technique succeeds.
- T1564.009recovers — A.8.7 point j) explicitly requires business continuity plans including backups and recovery measures for recovering from malware attacks, which directly restores state after a realized T1564.009-based malware event (as in the cp-9 vs T1486 and A.8.13 vs T1486 anchors).
- T1564.010detects — A.8.7 requires regular automated validation of system software/data content, scanning for unapproved files/amendments, malware detection software with scans at multiple layers (including memory-resident effects on endpoints/servers), anomaly-aware placement via risk assessment, and awareness of evasive techniques; this surfaces many in-memory PEB overwrites as anomalous but leaves gaps for sophisticated in-process memory patches that evade signature-based or non-memory-focused scans.
- T1564.011detects — A.8.7 requires regular automated validation of system content, scanning of received data/email/webpages, collection of new malware intel, and monitoring placement based on risk, which can surface anomalous processes or known malware using nohup/silentlyContinue-style evasion on scanned vectors; this is only a slice because the technique is a runtime flag on legitimate interpreters rather than delivered malware and many executions (local, non-networked, non-scanned) fall outside the clause's scanning focus.
- T1564.011recovers — A.8.7 point j) explicitly requires business continuity plans that include backup and recovery measures for recovering from malware attacks, which directly matches the event-lane definition of recovers once the technique has run.
- T1564.012detects — A.8.7 requires regular automated validation of system software/data content, scanning for unapproved files/amendments, malware detection software with risk-based placement/config (including defense-in-depth at endpoints/servers/gateways), and procedures for reporting malware — all of which can surface abuse of AV exclusions as anomalous files or via discovery of the exclusions themselves, but this is only a slice (not bulk) of the technique's surface given hardcoded/contextual exclusions, evasive delivery, and reliance on awareness/training rather than guaranteed detection.
- T1564.012prevents — A.8.7 requires rules/controls that prevent unauthorized software (e.g. application allowlisting), reducing exploitable vulnerabilities, protective measures for external files/software, and proper configuration/placement of malware detection tools; these constrain the adversary's ability to rely on default/hardcoded exclusions for hiding file artifacts on many (but not all) platforms and configurations.
- T1564.013detects — A.8.7 explicitly requires regular automated validation of system software/data content, scanning for unapproved files/amendments, malware detection software placement based on risk assessment, and procedures for reporting malware attacks, which can surface bind-mount hiding of malicious processes/artifacts on Linux systems; this is only a slice because the control is malware-centric, not a general anomaly detector for filesystem or process-hiding techniques.
- T1564.014detects — A.8.7 explicitly requires regular automated validation of software/data content, scanning of received files/media/email/webpages, collection of new malware intel, and placement of detection tools based on risk (including defense-in-depth at endpoints/servers/gateways), which surfaces xattr-hidden payloads when those mechanisms inspect extended attributes; this is only a slice because many standard integrity/hash tools and scans ignore xattrs by default, and the control's malware-detection focus does not mandate universal xattr inspection.
- T1564.014prevents — A.8.7 requires malware detection/repair software, integrity validation of files/data, vulnerability reduction, unauthorized-software rules, awareness, and scanning of received content — all of which can stop xattr-hidden payloads from being written, persisting, or executing as malware on Linux/macOS, but leaves real gaps (e.g., non-malware xattr abuse, tools that ignore xattrs, or pre-installed legitimate loaders).
- T1564.014recovers — A.8.7 point j) explicitly requires business continuity plans including backups and recovery measures for recovering from malware attacks, which restores state after the xattr-hidden payload has executed.
- T1565detects — A.8.7 requires regular automated validation/scans of software and data content (d,f), malware detection software placement based on risk (g), and procedures to collect/verify malware information (n,o), which can surface data manipulation if performed by malware but does not broadly detect all adversary data manipulation techniques.
- T1565recovers — A.8.7 explicitly requires business continuity plans including backups and recovery measures (item j) to recover from malware attacks that can realize data manipulation, but this is scoped only to malware vectors and does not address the full class of T1565 manipulations (e.g. direct authorized-user or non-malware exploits).
- T1565.001detects — A.8.7 requires regular automated validation of software/data content, malware scans on received files/emails/webpages, and procedures to collect/verify malware intelligence, which can surface stored-data manipulation if it introduces detectable malware signatures or anomalies, but this is only a slice since the technique often uses legitimate tools or non-malware changes that evade signature-based detection.
- T1565.001prevents — A.8.7's rules to prevent unauthorized software, reduce exploitable vulnerabilities, scan for malware before use, and block malicious sites constrain some vectors that could deliver or enable stored-data manipulation (e.g. via malware), but do not stop an adversary who already has legitimate or privileged access from directly editing at-rest data.
- T1565.001recovers — A.8.7 explicitly requires business continuity plans including backups and recovery measures (item j) to restore from malware attacks that can include data manipulation at rest, but this is only one recovery vector among many for the broad T1565.001 class and does not address non-malware vectors or all stored-data formats.
- T1565.002detects — A.8.7 requires regular automated validation of software/data content, scanning of received data/email/webpages for malware, collection of new malware intel, and procedures to deal with/report malware attacks, which can surface some in-transit manipulation if it involves known malware or leaves detectable artifacts, but does not broadly detect arbitrary data manipulation techniques.
- T1565.002recovers — A.8.7 clause j) explicitly requires business continuity plans including backups and recovery measures for recovering from malware attacks; while T1565.002 is not itself a malware technique, the control's recovery provisions address post-manipulation restoration of affected data/integrity in malware scenarios that could enable or parallel such transmission manipulation.
- T1565.003detects — A.8.7 mandates regular automated validation of software/data content, malware scans (including on received files, email, webpages), collection of new malware intel, and procedures to detect/report malware, which can surface runtime binary alterations or anomalous files as malware indicators, but this is limited to malware-focused detection rather than general runtime data manipulation techniques that may not involve known malware.
- T1565.003recovers — A.8.7 point j) explicitly requires business continuity plans including backups and recovery measures for recovering from malware attacks, which can restore data integrity after runtime manipulation caused by malware-altered binaries or files.
- T1566detects — A.8.7 explicitly requires scanning email/IM attachments, downloads, webpages, received data, and regular automated validation of systems/content to detect malware presence or unauthorized changes before use, which surfaces the malicious payload or link delivered by T1566 phishing (the dominant malware-delivery vector in the technique description); it does not address non-malware social-engineering-only phishing variants or pre-delivery spoofing/evasion.
- T1566prevents — A.8.7 explicitly requires malware detection/repair software, scanning of email/attachments/downloads/webpages before use, blocklisting of malicious sites, awareness training on identifying/mitigating malicious emails/files, and vulnerability reduction — all of which stop many (but not all) phishing payloads from executing; it does not address social engineering, spoofing, or thread hijacking that succeed without malware.
- T1566responds — A.8.7 explicitly requires business continuity plans, isolating environments, procedures for recovering from malware attacks, and training on recovering from malware (points j, k, l, m), which constitute a response once a phishing-delivered malware event is underway; this is bounded to the malware payload/execution slice of T1566 rather than the social-engineering delivery or credential-harvesting variants.
- T1566.001detects — A.8.7 explicitly requires scanning email attachments and downloads for malware before use (at servers, desktops, network entry), plus regular collection/verification of new malware intel and user awareness of malicious emails, which surfaces the spearphishing attachment technique in flight.
- T1566.001prevents — A.8.7 directly prevents the technique by mandating email/attachment scanning before use (f.1-2), blocklisting of malicious sites, allowlisting, vulnerability reduction, and awareness that stops the attachment from being opened and executed.
- T1566.001responds — A.8.7 explicitly requires procedures, training, awareness, and business continuity plans to deal with and recover from malware attacks (l, j, m), which directly addresses containment/eradication once a spearphishing attachment has delivered and executed malware.
- T1566.002detects — A.8.7 explicitly requires malware detection software, regular automated scans of received data/email attachments/webpages, collection of new malware intel, and verification of warning sources, all of which surface spearphishing-link-delivered malware (or its payload) before or after delivery; the social-engineering/token-theft slices without a malware artifact remain outside this coverage.
- T1566.002prevents — A.8.7 explicitly requires controls that prevent or detect use of known/suspected malicious websites (e.g. blocklisting), scanning of webpages and email links/downloads for malware before use, reducing exploitable vulnerabilities, awareness training on identifying malicious links/emails, and protective measures for files from external networks, which stops many (but not all) T1566.002 delivery paths such as direct malware downloads or browser exploits.
- T1566.002responds — A.8.7 explicitly requires preparing business continuity plans, isolating environments, defining procedures for reporting/recovering from malware attacks, and protective measures against malware introduction, which constitute a response once a spearphishing-link-delivered malware event is underway.
- T1566.003detects — A.8.7 requires scanning of email/IM attachments, downloads, webpages, received data and media for malware (f, g), plus awareness/training on identifying malicious emails/files (m) and procedures for reporting malware incidents (l), which surfaces spearphishing-via-service payloads when they reach scanned channels or are recognized; this is only a slice because the technique relies on social engineering rapport-building on non-enterprise services that can wholly bypass enterprise scanning and training if the user never forwards the content into monitored paths.
- T1566.003prevents — A.8.7 explicitly requires controls that prevent or detect use of known/suspected malicious websites (blocklisting), scanning of email/IM attachments/downloads and webpages for malware before use, reducing exploitable vulnerabilities, awareness training on identifying/mitigating malicious emails/files, and protective measures for files from external networks, all of which stop the malicious link/attachment delivery step of T1566.003 before execution; partial because the technique's social engineering rapport-building via non-enterprise services can still succeed without triggering technical blocks.
- T1566.004detects — A.8.7 requires awareness training, procedures to collect/verify malware information, regular scans, anomaly validation, and monitoring placement based on risk, which can surface indicators of vishing leading to malware execution or suspicious downloads/URLs, but the control is scoped to malware protection and does not broadly detect the social-engineering voice call itself.
- T1566.004prevents — A.8.7 explicitly requires user awareness/training on identifying and mitigating receipt/installation of malware-infected content plus protective measures against external files/software and malicious websites, which directly lowers success odds of the social-engineering voice call that tricks users into visiting malicious URLs or downloading/executing malware; this is a genuine but minority slice of the technique (the call itself and non-malware vectors such as credential theft or RAT installation remain untouched).
- T1567detects — A.8.7 requires scanning of data received over networks, email/IM attachments, downloads, and webpages (plus anomaly detection via regular validation of system content), which can surface exfiltration of data to web services when it matches known malware patterns or produces detectable anomalies, but this is only a minority slice of T1567 (most exfil uses legitimate non-malware channels, encrypted flows, or non-file-based methods that bypass malware-focused detection).
- T1567.001detects — A.8.7 requires malware detection software, regular scans of data/email/web content, anomaly validation of files, and awareness of suspicious activity, which can surface exfiltration of data/files to a code repo when it involves malware, suspicious attachments, or unauthorized changes, but does not broadly detect clean exfiltration over HTTPS APIs to popular services.
- T1567.002detects — A.8.7 requires malware detection software, regular scans of data received over networks/email/web, anomaly detection via validation of system content, and awareness of suspicious files, which can surface exfiltration of data to cloud storage when it involves malware delivery, suspicious downloads, or unauthorized file changes, but does not broadly detect clean exfiltration using legitimate cloud services.
- T1567.003detects — A.8.7 requires scanning of data received over networks, email/IM attachments, downloads, and webpages (plus regular automated validation of system content), which can surface exfiltration of data to a text storage site when performed at network gateways, email servers, or endpoints; this is a genuine but minority slice of the technique because the control is scoped to malware-focused scanning rather than general outbound data flow or destination monitoring.
- T1567.003prevents — A.8.7.b explicitly requires controls that prevent or detect use of known/suspected malicious websites (e.g. blocklisting), which directly stops exfiltration to pastebin-like text storage sites when they are categorized as malicious; this is a genuine but minority slice of the technique because many text storage sites are not pre-categorized as malicious, paid/encrypted variants evade detection, and the control's other clauses (awareness, scanning, vulnerability reduction) do not stop deliberate outbound exfil to benign-looking paste sites.
- T1567.004detects — A.8.7 requires malware detection software, regular scans of data/email/web content, anomaly validation of systems, and awareness of suspicious files, which can surface webhook exfiltration when it involves malware delivery, staged malicious payloads, or anomalous file transfers, but the technique itself is not inherently malware and blends with normal HTTPS/SaaS traffic outside those vectors.
- T1568detects — A.8.7 requires scanning for malware (including on networks, email, web pages, and endpoints) plus awareness and procedures that can surface dynamic-resolution malware when it is delivered or executes, but does not guarantee detection of the algorithm-driven C2 channel itself once established.
- T1568prevents — A.8.7's malware detection, website blocklisting, vulnerability reduction, and awareness measures can stop some malware that relies on dynamic resolution from ever executing or phoning home, but do not block the technique itself when the malware is already present or uses non-malware vectors.
- T1568.001detects — A.8.7 requires regular automated validation, scans of received data/email/webpages, collection of new malware intel, and risk-based placement of detection tools (including at network gateways and endpoints), which can surface fast-flux C2 domains or anomalous resolutions when they match known indicators or behavioral patterns, but does not mandate or guarantee coverage of the DNS-layer flux mechanics themselves.
- T1568.002detects — A.8.7 explicitly requires scanning for malware (including at network gateways, email, web access, and endpoints) plus collecting/validating malware intelligence, which surfaces many DGA-driven C2 behaviors as malware but leaves a large remainder of novel or evasive DGAs undetected until signatures or behavioral rules are updated.
- T1568.002prevents — A.8.7 guidance on blocking known/suspected malicious websites, reducing exploitable vulnerabilities, scanning for malware before use, defence-in-depth placement, and awareness/training can stop some DGA-based C2 (especially post-compromise or detectable patterns), but does not stop malware from generating or attempting algorithmically-produced domains.
- T1568.002responds — A.8.7 explicitly requires business continuity plans, isolating high-risk environments, procedures for recovering from malware attacks, and awareness/training on mitigating malware-infected files — all of which constitute containment/eradication/response actions once a DGA-driven malware C2 event is underway.
- T1568.003detects — A.8.7 requires regular automated validation, scans of received data/email/webpages, collection of new malware intel from reputable sources, and risk-based placement of detection tools (including at network gateways and endpoints), which can surface anomalous DNS responses or calculated C2 traffic as suspicious; this is a genuine but minority slice because the technique is not itself malware and most of the clause's mechanisms target executable malware rather than this calculation behavior.
- T1569detects — A.8.7 requires regular automated validation/scans of systems (including for unapproved files/amendments), malware detection software with scans at multiple layers (email, web, endpoints, network), and procedures to collect/verify malware info, which can surface abuse of system services when it involves known malicious content or anomalies, but does not broadly instrument or detect all service creation/interaction behaviors especially for custom or living-off-the-land abuse.
- T1569prevents — A.8.7's rules to prevent unauthorized software (allowlisting), reduce exploitable vulnerabilities, block malicious sites, scan before execution, and isolate high-risk environments stop many (but not all) ways of introducing/creating/abusing a malicious service or daemon.
- T1569.001detects — A.8.7 requires regular automated validation of system content, malware detection software with scans (including on received data, email, webpages), anomaly investigation, and awareness-driven reporting, which can surface launchctl abuse as anomalous or malware-like behavior on macOS endpoints; this is only a slice because the clause scopes detection to malware signatures and known patterns rather than arbitrary command-line abuse of a legitimate macOS binary.
- T1569.001prevents — A.8.7's malware detection, allowlisting, vulnerability reduction, scanning of received files/executables, and awareness directly stop many launchctl-based malware execution vectors on macOS (e.g. via untrusted downloads, agents/daemons, or exploited vulns), but not all (e.g. legitimate admin use of launchctl or already-installed malicious agents).
- T1569.002detects — A.8.7 requires regular automated validation of system software/content, malware scanning of received data/email/webpages, collection of new malware intel, and monitoring/reporting procedures that can surface anomalous service creation or execution as potential malware indicators, but this is scoped to malware-focused detection rather than broadly detecting all service execution abuse.
- T1569.002prevents — A.8.7's rules to prevent unauthorized software (allowlisting), reduce exploitable vulnerabilities, block malicious sites, scan for malware before execution, and isolate high-risk environments stop many (but not all) service-control-manager abuse paths that rely on dropped binaries, unpatched services, or external delivery.
- T1569.003detects — A.8.7 requires regular automated validation of system software/content, malware scanning of received data/email/webpages, collection of new malware intel, and anomaly-oriented awareness training, all of which can surface systemctl abuse when it introduces or exhibits known malicious artifacts or patterns, but this is only a slice of possible abuse (e.g. benign-looking service starts) and the clause is scoped to malware rather than general technique execution.
- T1569.003prevents — A.8.7's rules/controls to prevent unauthorized software (via allowlisting), reduce exploitable vulnerabilities, block malicious sites, scan/validate before execution, and isolate high-risk environments all constrain the ability to introduce or run a malicious systemctl-based systemd service on Linux, but leave open legitimate admin use of systemctl plus any malware that evades detection or is already authorized.
- T1570detects — A.8.7 requires regular scans, automated validation of systems, and monitoring for unapproved files/amendments plus malware detection at multiple points (email, web, downloads, endpoints), which can surface lateral tool/file transfers when they match known malware patterns or introduce unauthorized binaries, but this is only a slice since many legitimate-looking or custom tools evade signature-based detection and the control does not mandate behavioral anomaly detection for all file movement.
- T1570prevents — A.8.7's rules to prevent unauthorized software (allowlisting), block malicious sites, reduce exploitable vulns, scan/validate files before use, and protect against external file acquisition directly stop many common lateral tool-transfer vectors (e.g. dropping/copying malware tools via shares, native utilities, or web services), but cannot block all legitimate-file or already-authorized-tool lateral movement inside a compromised environment.
- T1571detects — A.8.7 requires regular automated validation of system content, scans of received data/email/webpages, collection of new malware intel, and risk-based placement of detection tools (including at network gateways), which can surface non-standard port usage when it delivers or exhibits observable malware artifacts, but does not broadly instrument or detect the port-abuse behavior itself when malware is not involved.
- T1572detects — A.8.7 requires scanning, monitoring for anomalous behavior via malware tools, awareness, and validation that can surface tunneling when it delivers or exhibits known/suspected malware (e.g. at network gateways, email, web, or endpoints), but the control is scoped to malware and does not broadly detect protocol tunneling that blends with or encrypts traffic absent a malware payload.
- T1572prevents — A.8.7's malware-detection/repair, website blocklisting, vulnerability reduction, unauthorized-software rules, and network-gateway scanning can stop some tunneling vectors that rely on malware delivery or known-malicious sites, but most tunneling (SSH, DoH, custom encapsulation) is not malware and evades the clause's malware-centric focus.
- T1573detects — A.8.7 explicitly requires scanning for malware (including at network gateways, endpoints, email, web access, and during maintenance), which surfaces the presence of malware samples containing the weak/embedded-key encrypted C2 channel, but does not broadly detect the in-transit encrypted traffic itself or non-malware uses of the technique.
- T1573prevents — A.8.7.g.2 explicitly calls out considering attacker evasive techniques that use encryption protocols to transmit malware, and its layered detection/allowlisting/vulnerability-reduction measures (a,c,f,g) can stop some malware-borne C2 implementations before they run, but the control does not block all custom or correctly keyed encryption of C2 traffic.
- T1573.001detects — A.8.7 explicitly requires scanning for malware (including in network traffic, email, downloads, and webpages) plus awareness of new malware and evasive techniques such as encrypted delivery, which surfaces some symmetric-C2 malware artifacts but leaves the bulk of protocol-level symmetric encryption undetected when it is not delivered as a recognizable malicious payload.
- T1573.002detects — A.8.7 explicitly requires scanning for malware (including at network gateways, email servers, endpoints, and webpages) plus awareness and procedures that surface anomalous/malicious activity, which can detect C2 traffic using asymmetric crypto when it carries or exhibits malware indicators, but the technique itself is not inherently malware and much of it evades detection via encryption as the control itself notes.
- T1574detects — A.8.7 requires regular automated validation/scans of systems plus malware detection software that surfaces known/suspected malicious files or websites, which can discover some hijack artifacts (e.g. poisoned files or libraries) but does not broadly detect the technique's many variants such as registry poisoning, DLL search-order hijacks, or evasion of scanners.
- T1574prevents — A.8.7's allowlisting (8.19), vulnerability reduction (8.8), unauthorized-software rules, and malware scanning directly stop many hijack vectors (e.g. poisoned libraries, malicious payloads, unapproved files) before execution; residual techniques such as registry poisoning, DLL search-order attacks that evade detection, or those bypassing allowlisting remain unaddressed by this control alone.
- T1574recovers — A.8.7 explicitly requires business continuity plans including backups and recovery measures (j) to recover from malware attacks, and T1574's hijacking often delivers a malicious payload that can be treated as malware whose effects (e.g. persistence or altered binaries) are restored from clean backups.
- T1574.001detects — A.8.7 explicitly requires malware detection/repair software, regular automated scans of files/data/email/webpages (including at multiple layers), collection of new malware intel, and validation for unapproved changes — all of which surface known or suspected malicious DLLs planted via sideloading, search-order hijacking, phantom/substitution, or remote loading.
- T1574.001prevents — A.8.7 explicitly lists controls that prevent unauthorized software execution (allowlisting), reduce exploitable vulnerabilities, block malicious sites, scan for malware before use, and apply defense-in-depth placement, all of which stop many (but not all) DLL sideloading, search-order hijacking, phantom, and substitution vectors before they execute.
- T1574.001recovers — A.8.7 explicitly requires business continuity plans including backups and recovery measures for malware attacks (item j), which can restore state after a realized DLL-abuse technique such as sideloading or substitution, but this is only one slice of the control whose dominant focus is prevention and detection.
- T1574.001responds — A.8.7 explicitly requires business continuity plans, isolating high-risk environments, defined procedures for reporting/recovering from malware attacks, and training on mitigation, which directly addresses containment/eradication once a DLL-based malware technique is underway.
- T1574.004detects — A.8.7 explicitly requires regular automated validation of software/content, scanning of received data/email/webpages, collection of new malware intel from reputable sources, and risk-based placement of detection tools, all of which can surface a planted malicious dylib (especially via scans or anomaly checks), but this is limited to a slice because the technique can be masked under legitimate processes, use evasion like encryption, or occur in unmonitored paths/environments.
- T1574.004prevents — A.8.7 guidance on malware detection/repair software, reducing exploitable vulnerabilities, preventing unauthorized software via allowlisting, scanning received files/media, awareness training, and isolating high-risk environments directly stops many dylib hijacking vectors on macOS before execution, but leaves gaps such as weak linking, @rpath abuse in signed apps, and evasion of scanners.
- T1574.004recovers — A.8.7 point j) explicitly requires business continuity plans including backups and recovery measures for recovering from malware attacks, which restores state after dylib hijacking execution (a malware technique) but does not address all impacts such as privilege escalation or persistence.
- T1574.004responds — A.8.7 explicitly requires malware detection/repair software, regular scans of received data/email/web content, awareness training on identifying malware-infected files, procedures for reporting/recovering from attacks, and business continuity plans including backups for recovering from malware attacks — all of which directly address a realized dylib-based malware execution once underway.
- T1574.005detects — A.8.7 requires regular automated validation of software/content, malware scans (including on received files, email, downloads, webpages), collection of new malware intel, and awareness of infection indicators, which can surface some installer hijacking artifacts (e.g. unexpected files/amendments in %TEMP% or anomalous binaries) but does not systematically detect the core permission weakness or the hijack in progress.
- T1574.005prevents — A.8.7 guidance explicitly requires rules/controls that prevent unauthorized software (a), reducing exploitable vulnerabilities (c), protective measures for files from external networks (e), and malware detection/repair that can block malicious payloads before execution (f), which directly counters the permission-weakness and temp-directory hijacking vectors in T1574.005; it is only partial because the control is a collection of practices whose effectiveness still depends on implementation rigor and does not guarantee every installer binary or directory will be hardened.
- T1574.005recovers — A.8.7 point j) explicitly requires business continuity plans including backups and recovery measures for malware attacks, which can restore state after the hijacked installer has executed its payload.
- T1574.006detects — A.8.7 explicitly requires regular automated validation of system software/content, malware detection/repair software with scans (including on received data, email, webpages), collection of new malware intel, and awareness of malware indicators, which can surface dynamic linker hijacking artifacts or anomalous libraries after the fact; this is only a slice because the clause centers on conventional malware scanning rather than specialized detection of environment-variable or linker anomalies.
- T1574.006prevents — A.8.7 explicitly requires rules/controls that prevent unauthorized software (e.g. application allowlisting), reducing exploitable vulnerabilities, protective measures against obtaining malicious files, and malware detection that can block LD_PRELOAD-style library loads before execution; this stops many instances but leaves developer/debug use-cases, legitimate environment variable needs, and bypasses via maintenance/emergency paths as residual.
- T1574.006recovers — A.8.7 point j) explicitly requires business continuity plans including backups and recovery measures for recovering from malware attacks, which restores state after a realized T1574.006 payload executes as malware; partial because the clause is scoped to malware recovery and does not address non-malware hijacking vectors or all post-hijack artifacts.
- T1574.007detects — A.8.7 requires regular automated validation of system software/content, malware detection software with scanning of received data/email/webpages, collection of new malware intel, and awareness training that surfaces anomalous behavior, all of which can surface PATH hijacking artifacts (e.g. unexpected binaries or modified env vars) but only where they match known malware patterns or monitored scopes, leaving many stealthy or novel variants undetected.
- T1574.007prevents — A.8.7's rules to prevent unauthorized software (allowlisting), reduce exploitable vulnerabilities, block malicious sites, scan for malware before execution, and harden against external file introduction all stop the adversary from successfully placing and executing a malicious binary via PATH hijacking in many common cases, but leave real gaps (e.g., insider or already-privileged modification of PATH, un-scanned local changes, or non-malware delivery of the hijack binary)
- T1574.007recovers — A.8.7 point j) explicitly requires business continuity plans including data/software backup and recovery measures for recovering from malware attacks, which directly restores state after T1574.007's malicious payload has executed (the malware is the realized impact).
- T1574.008detects — A.8.7 requires regular automated validation/scans of systems (including for unapproved files/amendments), malware detection software with scans at multiple layers (email, web, endpoints, gateways), and awareness of new malware, which can surface search-order hijacking artifacts after placement but does not guarantee detection of the technique itself or all instances.
- T1574.008prevents — A.8.7 guidance on application allowlisting, reducing exploitable vulnerabilities, scanning for malware before use/execution, and defence-in-depth placement directly stops many (but not all) search-order hijack payloads from running as malware.
- T1574.008recovers — A.8.7 explicitly requires business continuity plans including data/software backup and recovery measures (point j) to recover from malware attacks, which this technique delivers as its payload.
- T1574.008responds — A.8.7 requires procedures, training, detection/repair tools, and business continuity plans explicitly for recovering from malware attacks, which responds to the realized malicious payload from search order hijacking once underway.
- T1574.009detects — A.8.7 requires regular automated validation of system software/content (d), scanning of received data/email/webpages (f), collection of new malware info (n), and awareness of malware indicators (m), which can surface unquoted-path hijack artifacts (e.g. unexpected executables in higher directories) after they are placed but before or during use; this is a genuine but minority slice of the technique's full surface (placement, persistence, or escalation).
- T1574.009prevents — A.8.7 guidance explicitly requires rules/controls that prevent unauthorized software (e.g. application allowlisting per 8.19), reducing exploitable vulnerabilities, scanning for malware before use, and protective measures on external files/software, which stops the adversary-placed executable from being introduced or executed in many (but not all) unquoted-path scenarios.
- T1574.009recovers — A.8.7 point j) explicitly requires business continuity plans including backups and recovery measures for recovering from malware attacks, which directly restores state after the T1574.009 payload executes as malware.
- T1574.010detects — A.8.7 requires regular automated validation of system software/content (d), scanning of received data/email/webpages (f), collection of new malware info (n), and awareness of indicators (m), which can surface anomalous binaries or known malware signatures post-replacement; this is a genuine but minority slice of the technique (e.g., does not broadly detect permission flaws or pre-execution hijack attempts).
- T1574.010prevents — A.8.7 guidance on reducing exploitable vulnerabilities (via 8.8/8.19), preventing unauthorized software (allowlisting per 8.19/8.32), scanning for malware before execution, and awareness directly blocks many hijack vectors that rely on weak perms enabling malicious binary placement or execution, but leaves a remainder for unpatched permission flaws on unmanaged services or novel binaries that evade detection.
- T1574.010recovers — A.8.7 point j) explicitly requires business continuity plans including backups and recovery measures for malware attacks, which can restore state after a services binary has been hijacked and replaced (the realized impact of T1574.010).
- T1574.011detects — A.8.7 requires regular automated validation of system software/content (d), scanning of received data/email/webpages (f), collection of new malware info (n), and verification of reputable sources (o); these surface some hijacked registry entries or anomalous files/DLLs post-compromise but miss many permission flaws and registry manipulations that do not involve known malware signatures or observable execution artifacts.
- T1574.011recovers — A.8.7 point j) explicitly requires business continuity plans including backups and recovery measures for malware attacks, which restores state after the hijacked service has executed its payload.
- T1574.012detects — A.8.7 explicitly requires regular automated validation of system software/content, malware detection software with scanning of received data/email/webpages, collection of new malware intel, and risk-based placement of detection tools, which can surface COR_PROFILER-based DLL loading or anomalous .NET profiler behavior as malware or unauthorized change, but this is not guaranteed for in-memory/process-scope abuse or evasive encrypted delivery and depends on configuration/scope.
- T1574.012prevents — A.8.7 guidance on application allowlisting, reducing exploitable vulnerabilities, scanning for malware before execution/use, defence-in-depth placement, and awareness/training directly stops many (but not all) forms of malicious COR_PROFILER DLL registration and loading on Windows .NET processes.
- T1574.012recovers — A.8.7 point j) explicitly requires business continuity plans that include backup and recovery measures for recovering from malware attacks, which would restore state after a COR_PROFILER-based hijack that qualifies as malware execution.
- T1574.013detects — A.8.7 requires malware detection software, regular scans of received data/email/webpages, awareness of new malware, and anomaly-oriented validation of system content; these surface some in-memory hijacks that manifest as malware-like artifacts or known IOCs, but the technique's stealth (restoring the table, running under legitimate process, no file-based malware) leaves most instances undetected.
- T1574.013prevents — A.8.7's malware detection/repair, vulnerability reduction, unauthorized software prevention (allowlisting), awareness, and scanning directly stop many delivery vectors and some in-memory malware behaviors that rely on loading malicious payloads, but the specific PEB/KernelCallbackTable hijack (often via process injection or reflective loading) can still succeed in memory without triggering file-based detection or allowlisting, leaving a genuine minority slice prevented.
- T1574.013recovers — A.8.7 explicitly requires preparing business continuity plans including backups and recovery measures (item j) for recovering from malware attacks, and this technique's payload is malware that runs under a legitimate process; recovery therefore applies after execution but only to a minority slice of impacts (e.g. corrupted state or data) while the hijack itself and most stealth aspects fall outside recovery.
- T1574.013responds — A.8.7 explicitly requires procedures, training, awareness, and business continuity plans to deal with and recover from malware attacks once underway, which matches the `responds` verb for containing/eradicating a realized technique; partial because the clause is scoped to malware delivery vectors and does not address in-memory hijacking via KernelCallbackTable that evades detection and does not rely on a distinct malware artifact.
- T1574.014detects — A.8.7 requires malware detection software, regular scans of files/downloads/webpages, anomaly validation of system content, and awareness of new malware sources, which can surface known AppDomainManager injection artifacts (e.g. tampered .config files or unexpected assemblies) but does not guarantee detection of novel or evasive variants that bypass signature-based or scan-based methods.
- T1574.014prevents — A.8.7 explicitly requires rules/controls that prevent unauthorized software (e.g. application allowlisting per 8.19), reducing exploitable vulnerabilities, scanning before use, and protective measures against external files/software; these block many vectors for loading a malicious assembly via AppDomainManager hijacking, but leave a remainder for in-process tampering of .config files or environment variables in already-trusted .NET processes.
- T1574.014recovers — A.8.7 explicitly requires business continuity plans including backups and recovery measures for recovering from malware attacks, which restores state after AppDomainManager injection (a malware technique) has executed.
- T1574.014responds — A.8.7 explicitly requires procedures, training, and business continuity plans to deal with and recover from malware attacks once underway, which matches the `responds` verb for containing/eradication of this malware technique; coverage is partial because the clause is malware-generic and does not address .NET-specific hijacking mechanics.
- T1578detects — A.8.7 requires regular automated validation of system content, malware scans at multiple layers (including network gateways and endpoints), anomaly-oriented awareness/training, and collection of new malware intel, all of which can surface suspicious compute modifications or their artifacts in IaaS environments; this is a genuine but minority slice of the broad technique (most evasion via infrastructure changes leaves no malware footprint and is outside the malware-specific scope).
- T1578.001detects — A.8.7 requires regular automated validation of system software/data content, scanning of received files/media/email/webpages, collection of new malware info, and procedures to deal with/report malware; these can surface anomalous snapshot creation when it delivers or resembles malware, but the technique itself is a permissioned cloud management action with no malware payload and lives outside the malware-focused scanning/validation scope.
- T1578.002detects — A.8.7 requires regular automated validation of system software/data content, scanning of received files/media/webpages, collection of new malware intel, and monitoring for anomalous activity that can surface creation of unauthorized cloud instances as potential malware vectors or policy violations, but this is scoped to malware-focused detection rather than broadly covering all evasion-driven instance creation in IaaS.
- T1578.003detects — A.8.7 requires regular automated validation of system content, scanning for unapproved files/amendments, malware detection tools placed per risk assessment, collection of new malware intel, and procedures for reporting malware incidents, which can surface anomalous instance deletions or related artifacts in monitored environments but does not broadly cover cloud IaaS deletion events or non-malware evidence removal.
- T1578.003recovers — A.8.7 clause j) explicitly requires business continuity plans including backups and recovery measures for recovering from malware attacks, which can restore state after instance deletion if backups exist outside the deleted instance.
- T1578.004detects — A.8.7 requires regular automated validation of system software/data content, scanning for unapproved files/amendments, malware detection software with scans at multiple layers, anomaly-oriented awareness/training, and collection of new malware intel, all of which can surface evidence of a reverted cloud instance (e.g. unexpected snapshot restore, ephemeral reset, or post-revert anomalies) but only as one slice of a broad malware-focused control that does not target reversion or cloud-specific evasion.
- T1578.004recovers — A.8.7.j explicitly requires business continuity plans that include backup and recovery measures for recovering from malware attacks, which can restore state after a revert technique that uses snapshots or ephemeral storage to erase evidence.
- T1578.005detects — A.8.7 requires regular automated validation of system software/data content, scanning for unapproved files/amendments, malware detection software with scans at multiple layers, collection of new malware info, and awareness procedures that can surface anomalous configuration changes as potential malware indicators, but this is limited to general system/endpoint/network scanning rather than specifically targeting cloud quota, tenant policy, or compute configuration modifications.
- T1583.001detects — A.8.7 requires scanning for malware in received data, email attachments, downloads, and webpages (including those reached via acquired malicious domains used for drive-by or phishing), which surfaces malware delivered through the domain but does not detect the domain acquisition or registration itself.
- T1583.001prevents — A.8.7 guidance explicitly requires controls that prevent or detect use of known/suspected malicious websites (e.g. blocklisting) and protective measures against obtaining files/software from external networks, which stops adversaries from leveraging acquired domains for delivery, phishing, or drive-by in the victim environment; this is only a slice of the pre-attack acquisition technique itself.
- T1583.007detects — A.8.7 requires regular collection and verification of new malware information plus scanning for malware in received data, emails, webpages and media; this surfaces known malicious serverless indicators (e.g. known-bad Cloudflare/AWS patterns or IOCs) when they appear in traffic or files, but the pre-compromise purchase-and-configure act itself is outside scanning scope and the technique's blending with legitimate provider traffic limits coverage to a chosen slice rather than a bounded remainder.
- T1583.008detects — A.8.7 explicitly requires scanning webpages for malware when accessed, regular collection and verification of new malware information from reputable sources, and placement of detection tools based on risk (including at network gateways and for evasive techniques), which surfaces malvertising artifacts or their downstream effects in some but not all cases (e.g., pre-purchase adversary evasion of ad networks or non-web vectors remain outside the clause's scanning and awareness scope).
- T1583.008prevents — A.8.7 guidance explicitly requires controls that prevent or detect use of known/suspected malicious websites (e.g. blocklisting) plus reducing exploitable vulnerabilities, scanning webpages for malware, and awareness training, which directly stops many malvertising vectors before compromise; partial because the technique is PRE, adversary-side ad purchase and evasion (spoofing, dynamic routing, typos) can still succeed against imperfect blocklists or unpatched browsers.
- T1584detects — A.8.7 requires regular automated validation of systems, scanning for malware (including on received data, emails, webpages, and media), collection of new malware info, and verification of sources, which can surface malware indicators on already-compromised third-party infrastructure but only for a minority slice of T1584's scope (e.g., botnets or post-compromise malware delivery) while leaving most pre-compromise or non-malware infrastructure compromises (domains, DNS, cloud servers) untouched.
- T1584.002detects — A.8.7 requires regular scans, validation of systems/data, collection of new malware intel, and monitoring for anomalous behavior that can surface DNS compromise indicators (e.g. unauthorized changes, malicious redirects, or malware artifacts on servers), but this is limited to post-compromise detection on organizational assets and does not broadly detect pre-compromise third-party DNS server compromises.
- T1584.004detects — A.8.7 requires scanning, monitoring for malware indicators, and collecting/validating malware intelligence, which can surface compromise of third-party servers used for C2, watering holes, or phishing when malware artifacts or anomalous behavior are present, but this is limited to malware-tainted cases and does not broadly detect all server compromises (e.g., credential theft or misconfiguration without malware).
- T1584.005detects — A.8.7 requires scanning, monitoring for anomalous files/behavior, awareness of new malware indicators, and validation procedures that can surface botnet-related compromise artifacts (e.g. malware on third-party systems or C2 patterns) after the fact, but this is limited to organizational assets and does not broadly detect adversary botnet-building or takeover activity on external/pre-compromised third-party systems.
- T1584.006detects — A.8.7 requires scanning, monitoring for anomalous files/behavior, awareness of suspicious emails/files, and collection of new malware intel, which can surface indicators of compromised web-service accounts (e.g. anomalous logins, unexpected file changes, or malware used in the compromise) but does not systematically detect the account takeover itself or its use as infrastructure.
- T1584.007detects — A.8.7 requires scanning, monitoring for anomalous files/behavior, awareness of new malware, and validation of systems (including during maintenance), which can surface compromised serverless functions or their malware artifacts when they match known signatures or trigger scans, but this is limited to a slice because serverless runtimes are ephemeral, often outside endpoint scanning scope, and the technique's stealth (cloud subdomains, encrypted delivery) leaves most attribution and pre-compromise detection untouched.
- T1584.008detects — A.8.7 requires regular automated validation/scans of systems (including network devices where in scope), collection of new malware info, and monitoring for malware indicators, which can surface compromise of edge network devices lacking host defenses; this is only a slice because the control is oriented toward malware on endpoints/servers rather than adversary-controlled network appliances used for infrastructure.
- T1586detects — A.8.7 requires scanning, awareness, and procedures that surface malware indicators (including in email/attachments used for credential phishing) and new malware intel, which can detect some T1586 methods such as phishing or credential-dumping malware, but most account-compromise vectors (purchasing creds, brute force, paying insiders, reconnaissance) sit outside malware detection.
- T1586.002detects — A.8.7 requires scanning of email attachments/downloads, webpages, data from external networks, and regular collection/verification of new malware information, which can surface indicators of compromised accounts used for phishing/spam campaigns; this is a genuine but minority slice of the pre-compromise reconnaissance, credential theft, and account takeover methods described.
- T1588detects — A.8.7 requires regular collection and verification of new malware information plus scanning for malware (including on downloads, websites, and external media), which can surface some obtained capabilities like known malware or exploits after acquisition but before or during use; it does not address purchasing, stealing, or acquisition of non-malware capabilities like certificates or vulnerability data.
- T1588.001detects — A.8.7 requires regular collection and verification of new malware information plus scanning/detection tooling that can surface acquired malware (or its signatures) once present in the environment or during delivery, but the control has no view into the pre-compromise acquisition activity itself on PRE platforms.
- T1588.002detects — A.8.7 requires scanning, validation, awareness, and monitoring for malware (and related suspicious activity) at multiple layers, which can surface acquisition or use of many attacker tools (especially when they exhibit malware-like behaviors or are tested against AV/EDR), but the technique is explicitly distinguished from malware, occurs pre-compromise on adversary-controlled systems, and is not the control's named focus.
- T1588.003detects — A.8.7 requires regular automated validation of software/content, scanning of received files/downloads/webpages, collection of new malware intel from reputable sources, and awareness procedures that can surface indicators of stolen or misused code-signing certs (e.g. via anomalous signed binaries or known-bad certs in threat feeds), but this is limited to post-acquisition detection on systems rather than the pre-targeting acquisition itself on PRE platform.
- T1588.005detects — A.8.7 requires regular collection and verification of new malware information (n,o), automated system validation for unapproved files/amendments (d), and scanning for malware (f) which can surface acquired exploit code or kits when they match known malware signatures or appear as unauthorized content, but this is limited to post-acquisition detection on systems and does not address pre-acquisition monitoring of forums or marketplaces.
- T1589.001detects — A.8.7 requires malware detection/repair software, regular scans of incoming data/email/webpages, collection of new malware intel from reputable sources, and awareness training that can surface credential-harvesting malware (e.g. infostealers) or malicious sites/content, but this only covers the malware vector of T1589.001 while leaving non-malware methods (phishing elicitation, breach dumps, dark-web purchase, compromised sites) untouched.
- T1589.001prevents — A.8.7's malware detection, awareness training, website blocklisting, vulnerability reduction, and scanning of downloads/emails/webpages directly stop infostealer malware and malicious content that harvest credentials, but do not address phishing elicitation, credential leaks, dark-web purchases, or service-provider compromises for MFA codes.
- T1592.002detects — A.8.7 requires malware detection/repair software, regular automated validation of systems for unapproved files/amendments, scanning of received data/email/webpages, collection of new malware intel, and awareness training that can surface indicators of reconnaissance activity aimed at host software details (including defensive tools like AV), but this is only a slice of the broad PRE reconnaissance methods (scanning, phishing, metadata analysis, public data exposure) described.
- T1595detects — A.8.7 requires monitoring for anomalous network behaviour including scans at network gateways and endpoints (g, f), which surfaces active scanning in flight; this is only a slice because the clause is scoped to malware vectors rather than all reconnaissance and PRE-platform activity falls outside deployed detection.
- T1595.001detects — A.8.7 requires monitoring, scanning, and anomaly detection (including at network gateways and for network activity) that can surface scanning behavior as anomalous or malware-related, but this is scoped by risk assessment and does not mandate coverage of all pre-attack IP block scanning (especially non-malware, stealthy, or external reconnaissance).
- T1595.002detects — A.8.7 requires regular automated validation of software/content, scanning for malware (including on received data, email, webpages), collection of new malware info, and risk-based placement of detection tools, which can surface vulnerability scans as anomalous or malware-delivery activity, but this is not its defined purpose and leaves broad residual (e.g., stealthy/pre-network scans, non-malware-linked recon).
- T1595.003detects — A.8.7 requires regular automated validation of system content, scanning of received data/webpages/emails, collection of new malware intel, and monitoring for anomalous activity that can surface wordlist-driven probing when it triggers malware signatures, unusual scanning patterns, or unapproved files, but this is limited to post-reconnaissance execution on defended systems rather than preemptively detecting external PRE reconnaissance.
- T1598detects — A.8.7 requires scanning of email/IM attachments, downloads, webpages and data received over networks (plus awareness and procedures to report malware), which surfaces phishing messages carrying malicious payloads or links but does not address the social-engineering, spoofing or information-elicitation core of T1598 that carries no malware.
- T1598prevents — A.8.7's email/IM attachment scanning, malicious website blocklisting, user awareness training on identifying phishing, and rules preventing unauthorized software or external files can stop some phishing-for-info messages from reaching users or being acted on, but the technique is primarily social engineering (not malware delivery) and many vectors (spoofed non-attachment emails, phone callbacks, urgent messaging) remain untouched.
- T1598.001detects — A.8.7 requires scanning of email/IM attachments, downloads, webpages, and data from external networks plus awareness training on identifying malicious emails/files, which surfaces spearphishing lures delivered via third-party services when they reach monitored vectors; this is only a slice because the technique occurs on non-enterprise platforms outside organizational scanning scope and relies on social engineering that may succeed without delivering detectable malware.
- T1598.001prevents — A.8.7's awareness/training (m), rules against unauthorized software/websites (a-b), and protective measures for external files (e) reduce user susceptibility to social-engineering lures delivered via third-party services, but do not stop the adversary from sending the messages or block all rapport-building variants on PRE platforms.
- T1598.002detects — A.8.7 requires scanning of email attachments, downloads, and data received over networks (including at email servers) plus awareness training on identifying malware-infected emails/files, which surfaces malicious attachments in some delivery paths but leaves social-engineering lures, non-malware credential-harvesting attachments, and pre-delivery reconnaissance untouched.
- T1598.002prevents — A.8.7's malware detection/repair, attachment scanning (f.2), website blocklisting (b), vulnerability reduction (c), and awareness/training (m) stop many malicious attachments from executing or reaching users, but the social-engineering elicitation of information (including non-executable filled forms or HTML smuggling) is only partially covered.
- T1598.003detects — A.8.7 explicitly requires scanning email/IM attachments, downloads, webpages, and data received over networks for malware before use, which surfaces malicious links or phishing payloads in email and web vectors; this is a genuine but minority slice of T1598.003 because the technique is primarily social-engineering driven (user clicking a link to a credential-harvesting site) rather than malware delivery, many variants (QR codes, tracking pixels, BitB, obfuscated URLs, proxy kits) evade or occur outside the scan points, and detection stops at knowledge with no protective effect asserted.
- T1598.003prevents — A.8.7's rules to block known/suspected malicious websites (blocklisting), scan email/attachments/webpages for malware before use, reduce exploitable vulnerabilities, and train users on identifying malicious links/emails directly stop many (but not all) spearphishing-link deliveries and clicks that rely on malicious payloads or unpatched vectors.
- T1599detects — A.8.7 requires regular automated validation of system software/content, malware scans (including on received data, email, webpages), collection of new malware intel, and procedures to detect/report malware, which can surface compromise of perimeter devices (e.g. anomalous files, unauthorized changes, or known malware used in bridging); this is a genuine but minority slice of the technique focused on malware artifacts rather than the boundary breach itself.
- T1599.001recovers — A.8.7 point j) explicitly requires business continuity plans including backups and recovery measures for recovering from malware attacks, which can restore state after a malware-enabled boundary breach such as this NAT modification technique.
- T1600detects — A.8.7 requires regular automated validation of system software/content, malware scanning at multiple layers (including network gateways and endpoints), collection of new malware intel, and anomaly-oriented awareness — all of which can surface indicators of compromised network-device images, disabled crypto hardware, or anomalous encryption behavior, but only as a minority slice given the technique's focus on subtle device-level manipulation of encryption (not classic malware payloads) and the control's primary emphasis on endpoint/file malware rather than network-device integrity.
- T1600.001detects — A.8.7 requires regular automated validation of system software/content, malware scans at multiple layers, collection of new malware intel, and verification of sources, which can surface anomalous crypto-parameter changes or known weak-cipher malware but does not broadly instrument for this network-device-specific configuration weakening.
- T1601detects — A.8.7 requires regular automated validation of software content, malware scans (including on received data, media, and during maintenance), collection of new malware intel, and anomaly investigation that can surface unauthorized modifications to a monolithic system image file, but this is limited to known-malware signatures, approved-file checks, and endpoint/network placement rather than reliably catching novel or in-memory firmware changes on embedded network devices.
- T1601prevents — A.8.7's rules to prevent unauthorized software (allowlisting), reduce exploitable vulnerabilities, scan for malware before use, and protect against malicious files from external sources stop many ways an adversary could introduce or replace a modified system image on network devices, but leave real gaps for in-memory runtime modification, supply-chain or maintenance-bypass changes, and firmware images that are not caught by standard malware signatures.
- T1601recovers — A.8.7 point j) explicitly requires business continuity plans including backups and recovery measures for malware attacks, which can restore a modified system image after the technique has run.
- T1601.001detects — A.8.7 requires regular automated validation of software/content (d), scanning of received files/media/email/webpages (f), collection of new malware info (n), and verification of reputable sources (o), which can surface anomalous files or known malware signatures in a patched image or during download; this is limited to a slice because in-memory runtime patching (via debug commands or boot loader) leaves no persistent file for scanning, many network-device images lack endpoint-style malware tools, and the clause focuses on conventional malware rather than adversary-introduced OS patches.
- T1601.001prevents — A.8.7's rules to prevent unauthorized software (allowlisting), block malicious sites, reduce exploitable vulnerabilities, scan before use, and protect external file acquisition directly stop many delivery vectors and modifications of the monolithic OS image via standard protocols or untrusted media, but leave open admin-level debug commands, boot-loader implants (ROMMONkit), and in-memory runtime patching that bypass these controls.
- T1601.001recovers — A.8.7 point j explicitly requires business continuity plans that include backup and recovery measures for recovering from malware attacks, which directly restores state after a T1601.001-style OS image modification that qualifies as malware; partial because the control is scoped to malware events and does not address non-malware patching vectors or in-memory-only changes that evade persistence.
- T1601.002detects — A.8.7 requires regular automated validation of system software/content (d), scans of received data/media/email/webpages (f), collection of new malware info (n), and verification of reputable sources (o), which can surface anomalous older OS images or known downgrade-related malware on some platforms, but this is limited for embedded/network device firmware changes that may not match typical malware signatures or scan scopes.
- T1601.002recovers — A.8.7 point j) explicitly requires business continuity plans including backups and recovery measures for restoring from malware attacks, which can restore a downgraded network-device image to a known-good current version after the technique has run.
- T1602detects — A.8.7 requires regular automated validation of system software/data content, scanning for unapproved files/amendments, malware detection software with scans at multiple points, anomaly-oriented awareness/training, and collection of new malware intel, all of which can surface unauthorized access or changes to a configuration repository when it manifests as malware-like behavior or known malicious indicators, but this is only a minority slice of the technique (which is primarily stealthy collection via legitimate protocols with no malware involved).
- T1602.001detects — A.8.7 requires malware detection software, regular scans, anomaly validation of system content, and awareness of new malware, which can surface SNMP-based reconnaissance if it delivers or exhibits malware-like indicators, but the technique itself is legitimate SNMP querying with no inherent malware component.
- T1602.002detects — A.8.7 requires regular automated validation of system software/data content, scanning of received data/email/webpages, collection of new malware info, and monitoring for malware indicators, which can surface anomalous configuration dumps or related malware artifacts on network devices but only covers a minority slice of this purely credential/data-collection technique that does not rely on malware.
- T1606detects — A.8.7 requires scanning, monitoring for anomalous files/behavior, awareness of suspicious activity, and collection of new malware indicators, which can surface some forgeries that involve malware delivery, anomalous API use, or suspicious files, but most of T1606 (pure credential forging via APIs, private keys, or legitimate features without malware) falls outside malware-focused detection.
- T1606recovers — A.8.7 point j) explicitly requires business continuity plans that include data/software backup and recovery measures for recovering from malware attacks; while T1606 is credential forgery (not malware), the forged material is often used to deliver or enable malware execution, so the recovery slice applies but is not the technique's core.
- T1606.001detects — A.8.7 requires regular automated validation of system content, scanning of received data/email/webpages, collection of new malware intel, and monitoring for anomalous behavior that can surface forged-cookie artifacts or the malware that delivers the needed secrets, but this is only a slice of the technique's possible vectors (e.g. purely offline forgery using stolen keys with no malware or network activity).
- T1606.001recovers — A.8.7 point j) explicitly requires business continuity plans including backups and recovery measures for recovering from malware attacks; while T1606.001 is not itself a malware attack, the forged-cookie access it enables can deliver or be part of malware-driven impact that the recovery provisions address.
- T1606.002detects — A.8.7 requires regular automated validation of system software/data content, scanning of received files/emails/webpages, collection of new malware intel from reputable sources, and awareness of malware indicators; these can surface some indicators of forged SAML tokens delivered via malicious files, email, or web vectors (or anomalous files introduced during maintenance), but do not address the core certificate compromise, token forging, or identity-provider behaviors that define the technique.
- T1606.002recovers — A.8.7 point j) explicitly requires business continuity plans including backups and recovery measures for recovering from malware attacks, which can restore state after a forged-SAML incident that leveraged malware to obtain the signing certificate.
- T1608detects — A.8.7 requires regular automated validation/scans of systems plus collection of new-malware intelligence and awareness, which can surface staged capabilities (esp. malware/tools on victim-reachable locations or known-malicious sites) but does not address adversary-controlled staging infrastructure, certificates, or most pre-compromise/pre-access activity on PRE platform.
- T1608.001detects — A.8.7 requires regular collection and verification of new malware information plus scanning of received data, emails, webpages, and systems (including at network entry points and for critical processes), which can surface malware that has been uploaded to accessible infrastructure or repositories before it is fetched or executed, but this is limited to what the organization's scanning reaches and does not cover adversary-controlled staging on decentralized/blockchain platforms or pre-attack uploads outside monitored paths.
- T1608.003detects — A.8.7 requires regular automated validation of system software/data content, scanning of received files/emails/webpages, collection of new-malware intel, and verification of sources, which can surface anomalous or malicious certificates (especially self-signed or from suspect origins) but does not broadly detect certificate installation on adversary-controlled external infrastructure.
- T1608.004detects — A.8.7 explicitly requires regular automated validation of system content, scanning of webpages when accessed, scanning of received data/email/IM/web content for malware before use, and collection/verification of new malware information, all of which surface drive-by staging artifacts (malicious scripts, injected content, malvertising) after they exist but before or during delivery.
- T1608.004prevents — A.8.7 guidance directly prevents staging of malicious web content via blocklisting known/suspected malicious sites, scanning webpages for malware on access, reducing exploitable vulnerabilities, and awareness/training that lowers successful drive-by delivery, but leaves adversary-controlled or newly compromised infrastructure (pre-staging, domain typosquatting, etc.) largely unreached.
- T1608.005detects — A.8.7 explicitly requires regular automated scans, malware detection software, webpage scanning, collection of new malware intel, and verification of sources, which surfaces many (but not all) link targets such as malicious downloads, cloned phishing pages, or known-bad domains/IPFS content once they are reachable; it does not detect purely preparatory adversary setup of shortened/redirected/homoglyph domains or one-time URIs before they are used or scanned.
- T1608.005prevents — A.8.7's detection/repair software, blocklisting of malicious sites, vulnerability reduction, awareness training, and scanning of received files/links directly stop many link-target resources (e.g. malware downloads, known phishing sites) from being usable, but leaves untouched adversary-controlled infrastructure setup, domain typosquatting, URL masking, IPFS hosting, and novel client-side scripts.
- T1608.006detects — A.8.7 requires scanning webpages for malware when accessed, regular collection/verification of new malware intel from reputable sources, and awareness training on identifying malicious content; this surfaces some SEO-poisoned lures that deliver known malware but misses novel/undetected payloads, cloaking, or purely reputational manipulation that does not yet involve executable malware.
- T1609detects — A.8.7 requires regular automated validation of system content, malware scanning of received data/email/webpages, collection of new malware intel, and monitoring for anomalous behavior that can surface container admin command abuse when it matches known malware patterns or triggers scans at network/endpoint layers, but this is only a slice as the technique is often legitimate admin activity without malware involvement and many executions evade signature-based detection.
- T1610detects — A.8.7 requires regular automated validation of system software/content, malware scanning of received data/media/email/webpages, collection of new malware intel, and risk-based placement of detection tools, which can surface malicious or anomalous container deployments (especially those pulling/downloading malware or using known-bad images), but does not broadly instrument or guarantee detection of all container deployment methods or evasion configurations on the Containers platform.
- T1610prevents — A.8.7's malware-focused rules (allowlisting, vulnerability reduction, scanning of images/files, blocking malicious sources) stop some malicious-container deployments that rely on known malware or exploitable vulns, but do not stop benign-image deployments, privileged-container escapes, or non-malware evasion uses of the technique.
- T1611detects — A.8.7 requires regular automated validation/scans of systems (including for unapproved files/amendments), malware detection software with scans at multiple layers (email, web, storage, network), awareness of new malware, and anomaly-oriented placement based on risk; these surface many container escapes that involve malware, dropped payloads, kernel modules, or anomalous files/behavior, but miss purely configuration-driven or vulnerability-exploitation paths that introduce no detectable malware artifact.
- T1611prevents — A.8.7(c) explicitly calls for reducing exploitable vulnerabilities via technical vulnerability management (8.8), which directly blocks the subset of T1611 that relies on exploiting container/VM/hypervisor flaws (e.g. symbolic-link or ESXi bugs); the remainder of the technique (misconfigurations such as privileged containers, bind mounts, docker.sock exposure, or unshare/keyctl abuse) is untouched by malware-focused controls.
- T1612detects — A.8.7 requires regular automated validation of system software/content (d), scanning of received data/files (f1/f2), webpage scanning (f3), collection of new malware intel (n), and placement of detection tools based on risk (g) — all of which can surface anomalous container builds or embedded malware on hosts, but only as a slice (no mandate for build-specific or Docker API monitoring, and local vanilla-base builds are designed to evade standard detection).
- T1612prevents — A.8.7 guidance (a,c,f,g,h) directly addresses preventing malware introduction via unauthorized software, vulnerability reduction, scanning of received data/downloads, and protecting maintenance procedures that could deliver malware during image builds, but leaves open vectors such as local registry pulls, encrypted delivery, or approved build processes that still embed C2 malware.
- T1612recovers — A.8.7 explicitly requires business continuity plans including backups and recovery measures (item j) to recover from malware attacks, which would restore state after a realized T1612-built malicious image is deployed and executes its payload.
- T1620detects — A.8.7 requires regular automated validation of system software/data content, scanning of received data/email/webpages, collection of new malware intel, and placement of detection tools based on risk (including defence-in-depth at endpoints/servers/gateways), which can surface some in-memory reflective loading when it matches known patterns or triggers anomalies, but the purely fileless/memory-resident nature (no disk artifacts, encrypted/obfuscated until execution, evasion of process-based detection) leaves most instances outside what the clause's malware scanners and validation routines reliably catch.
- T1620prevents — A.8.7 explicitly requires reducing exploitable vulnerabilities, application allowlisting, blocking malicious sites, scanning for malware (including in memory-resident contexts via defence-in-depth placement), awareness training, and configuration against evasive fileless techniques; these stop many (but not all) reflective loading paths before execution.
- T1620recovers — A.8.7 point j) explicitly requires business continuity plans including backups and recovery measures for recovering from malware attacks, which directly restores state after reflective code loading (a fileless malware technique) has executed.
- T1620responds — A.8.7 explicitly requires malware detection/repair tools, regular scans (including of memory-resident payloads via endpoint placement), awareness/training on malware receipt/installation, incident response procedures for recovering from malware attacks, and defence-in-depth placement that surfaces in-process anomalies once the technique is underway.
- T1621detects — A.8.7 requires monitoring for anomalous behaviour via malware detection tools, awareness training, regular scans and collection of new malware information; this surfaces some T1621 indicators (e.g. anomalous repeated login attempts that could be flagged as suspicious activity or malware-like abuse) but the control's malware-centric focus and placement leaves most MFA-fatigue or push-bombardment instances outside its detection scope.
- T1621recovers — A.8.7 point j) explicitly requires business continuity plans including backups and recovery measures for recovering from malware attacks, which can be leveraged after an MFA fatigue attack that succeeds via social engineering or credential abuse.
- T1622detects — A.8.7 explicitly requires regular automated validation of software/content, scanning for malware (including before use on received data, email, webpages), collecting malware intelligence, and awareness of new threats, which surfaces debugger-evasion artifacts when they appear in delivered malware but does not broadly detect the evasion technique itself across all its forms.
- T1647detects — A.8.7 requires regular automated validation of system software/data content (d), scanning of received files/media/email/webpages (f), collection of new malware info (n), and placement of detection tools based on risk (g), which can surface plist modifications that match known malicious patterns or anomalies but does not broadly instrument or detect all adversarial plist edits (especially novel or non-malware ones).
- T1647recovers — A.8.7 point j) explicitly requires business continuity plans including backups and recovery measures for recovering from malware attacks, which restores state after plist modification used in malware persistence or evasion.
- T1648detects — A.8.7 requires regular automated validation of system software/data content, malware scanning of received files/downloads/webpages, collection of new malware intel, and awareness of anomalous indicators, which can surface some serverless abuse (e.g. unexpected functions, crypto-mining payloads, or event-triggered anomalies) but leaves the bulk of cloud-native creation/invocation techniques (IAM abuse, workflow persistence, Apps Script exfil) outside its malware-focused, endpoint/network scanning model.
- T1649detects — A.8.7 requires regular automated validation of system software/data content, scanning of received files/emails/webpages/storage media, collection of new malware info from reputable sources, and awareness of malware indicators; this surfaces some certificate-stealing malware (or related anomalous files) but does not address forged/golden certificates, non-malware theft via APIs/enrollment rights/misconfigurations, or non-malware vectors on non-Windows platforms.
- T1649recovers — A.8.7 point j) explicitly requires business continuity plans that include data/software backup and recovery measures for recovering from malware attacks; while certificate theft/forge is not itself malware, the technique's described vectors (stealing from storage, registry, files, or via crypto APIs) and downstream persistence/lateral effects can be triggered or enabled by malware, so the recovery provisions address a genuine but minority slice of the technique's realized impact.
- T1651detects — A.8.7 requires regular automated validation of system content, malware scanning of received data/email/webpages, collection of new malware intel, and anomaly-oriented awareness training, all of which can surface abuse of cloud admin command services when it introduces or exhibits known/suspicious malware-like behavior; this is a genuine but minority slice of the technique (most executions are not malware delivery and many evade signature/behavioral detection).
- T1653detects — A.8.7 requires regular automated validation of system software/data content, scanning for unapproved files/amendments, malware detection software with regular scans, collection of new malware info, and awareness procedures that can surface anomalous power-setting changes or related malware artifacts, but this is only a slice of possible T1653 abuse vectors (e.g., not all config tweaks or file deletions are caught by malware-focused scans).
- T1657detects — A.8.7 mandates malware detection/repair software, regular scans of email/attachments/downloads/webpages/files, anomaly validation of critical systems, and collection of new malware intel, which surfaces many ransomware and BEC delivery vectors (malware, malicious sites, unauthorized changes) but does not detect the social-engineering, account-compromise, or post-impact extortion phases of financial theft.
- T1657prevents — A.8.7's malware-focused controls (detection/repair, allowlisting, website blocklisting, vulnerability reduction, email/web scanning) prevent the malware-delivery vectors used in ransomware extortion and some technical theft paths to financial gain, but do not stop social engineering, BEC, impersonation, or non-malware financial theft methods that dominate the technique.
- T1657recovers — A.8.7 explicitly requires preparing business continuity plans including data/software backup and recovery measures for recovering from malware attacks, which directly addresses the ransomware-extortion slice of T1657 (restore availability of encrypted resources after the monetary demand); this does not address non-malware vectors such as BEC, social engineering, or bank hacking, so the coverage is a genuine but minority slice of the technique.
- T1657responds — A.8.7 explicitly requires preparing business continuity plans, isolating environments, defining procedures for reporting/recovering from malware attacks, and protective measures during maintenance that can bypass controls, which directly addresses containment, eradication, and response once a ransomware-based financial theft (T1486 + extortion) is underway.
- T1659detects — A.8.7 requires scanning of received data, email/IM attachments, downloads, and webpages for malware (plus awareness and vulnerability management), which can surface injected malicious content arriving via network traffic; this is limited to malware signatures rather than arbitrary injected content or upstream channel compromise, and does not address the technique's ISP-level or man-on-the-side execution vectors.
- T1659prevents — A.8.7 guidance explicitly requires controls that prevent or detect use of known/suspected malicious websites (blocklisting), reduce exploitable vulnerabilities, scan data received over networks before use, scan webpages when accessed, and place detection at network gateways per risk assessment and defense-in-depth, which stops many (but not all) upstream ISP-level or side/middle injection vectors that deliver malicious content via online traffic.
- T1659responds — A.8.7 explicitly requires preparing business continuity plans, isolating environments, defining procedures for reporting/recovering from malware attacks, and handling malware incidents (including training), which responds to content injection once the malicious payload has executed as malware; this is bounded by the upstream channel compromise and non-malware injection vectors that fall outside its malware-specific focus.
- T1665detects — A.8.7 requires regular automated validation of systems, scanning of received data/email/webpages for malware, collection of new malware intel from reputable sources, and risk-based placement of detection tools, which can surface some hiding techniques (e.g. anomalous traffic or artifacts at network gateways/endpoints) but does not broadly detect C2 infrastructure obfuscation, domain masking, traffic filtering, or sandbox evasion.
- T1667detects — A.8.7 explicitly requires regular automated validation of system content, scanning of incoming email/attachments at multiple points (servers, desktops, network entry), webpage scanning, and collection of new malware information from reputable sources, which can surface anomalous email floods or suspicious signup patterns as potential malware vectors, but does not guarantee detection of all non-malware email bombing (e.g., legitimate-looking newsletter floods or harassment without malicious payloads).
- T1667recovers — A.8.7 clause j) explicitly requires business continuity plans including backups and recovery measures for recovering from malware attacks; while email bombing is not malware, the flood of unwanted messages is an analogous inbox-denial event whose recovery (e.g. via backup/restore of mail stores or continuity procedures) is directly addressed by that language, but only a minority slice of the technique's full scope (harassment, precursor to spearphishing, etc.)
- T1671detects — A.8.7 requires regular automated validation of system software/content, scanning of received data/email/webpages, collection of new malware intel, and anomaly-oriented awareness training, all of which can surface malicious OAuth/SaaS app integrations when they exhibit observable malware-like or unauthorized behavior; this is a genuine but minority slice of the technique (most integrations are not delivered as malware binaries or files).
- T1673detects — A.8.7 requires malware detection software, regular automated system validation/scans, anomaly investigation, awareness training, and monitoring for new malware indicators; these can surface VM-enumeration activity when it is performed by malware or exhibits malware-like traits (e.g. anomalous CLI use or file changes), but the control is scoped to malware and does not broadly instrument or detect the discovery technique itself.
- T1674detects — A.8.7 requires regular automated validation/scans of systems plus malware detection software that can surface anomalous files, unauthorized changes, or known malware delivered via the technique (e.g. USB HID or dropped payloads), but does not broadly instrument for keystroke simulation itself
- T1675detects — A.8.7 requires regular automated validation of system content, malware scanning of received data/email/webpages, collection of new malware intel, and anomaly-oriented awareness training, all of which can surface indicators of ESXi admin-command abuse (e.g. unexpected guest processes or file changes) but only where those indicators overlap known malware signatures or observable anomalies; the technique itself is not inherently malware and much of its execution (API calls, vSphere SDK) sits outside the clause's scanning focus.
- T1677detects — A.8.7 requires regular automated validation of software/content (d), scanning of received data/email/webpages (f), collection of new malware info (n), and verification of sources (o), which can surface injected malicious code or files in a CI pipeline after the fact; this is limited to a slice because the technique often acts at design-time via trusted PRs/config changes that bypass runtime scans, and the clause is scoped to malware rather than arbitrary poisoned build logic.
- T1677prevents — A.8.7's rules to prevent unauthorized software (allowlisting), reduce exploitable vulnerabilities, scan/validate build artifacts and inputs before use, and block malicious sites directly stop several poisoning vectors (esp. indirect and public PR-based injection of malicious scripts/tests), but do not stop a privileged insider's direct modification of a trusted CI config file itself.
- T1678detects — A.8.7 requires regular automated validation of system content, malware detection software with scans at multiple layers (including email, web, downloads, and endpoints), anomaly investigation, and awareness of new malware, which can surface time-based delay artifacts (e.g., scheduled tasks, loops, or anomalous API hammering) when they trigger scans or monitoring, but this is limited to specific observable points rather than reliably catching all timing-based evasion natively or in sandboxes.
- T1679detects — A.8.7 requires regular automated validation of system software/data content, scanning for unapproved files/amendments, malware detection software with broad scanning (including at multiple layers), anomaly-oriented awareness/training, and collection of new malware intel; this surfaces selective-exclusion artifacts on Windows endpoints in many (but not all) deployment scopes and configurations.
- T1679recovers — A.8.7 point j) explicitly requires business continuity plans that include data/software backup and recovery measures for recovering from malware attacks, which directly restores state after a ransomware payload (even one using selective exclusion) has run.
- T1680detects — A.8.7 requires regular automated validation of system software/data content, scanning for unapproved files/amendments, malware detection software with scans at multiple layers, and procedures to collect/verify malware information, which can surface anomalous discovery activity (e.g. unusual enumeration commands or file access) as potential malware precursor; this is a genuine but minority slice of the broad technique that spans many benign admin uses and platforms.
- T1684detects — A.8.7 explicitly requires awareness/training on identifying malware-infected emails/files (m), regular collection/verification of new malware info (n/o), and scanning of email/IM attachments, downloads, webpages and received data (f), which surfaces social-engineering lures that deliver malware payloads; this is genuine but only a slice of T1684 because the technique also covers non-malware outcomes (credential theft, unauthorized approvals, data disclosure) that carry no technical malware indicator for the scanners or training to catch.
- T1684prevents — A.8.7 explicitly requires awareness/training on identifying/mitigating malware-infected emails/files (m), rules/controls preventing unauthorized software (a), protective measures for files from external networks (e), and scanning before use (f), which directly stop the user-authorized execution of adversary-supplied malicious payloads that is the core of T1684; this is only a slice because social engineering can target non-malware outcomes (e.g. credential disclosure, MFA changes, approvals) outside the malware-protection scope.
- T1684recovers — A.8.7 explicitly requires preparing business continuity plans including backups and recovery measures (item j) for recovering from malware attacks that social engineering may introduce, but this only addresses post-impact restoration of systems/data and does not cover the broader unauthorized access, disclosure, or approval outcomes named in T1684.
- T1684responds — A.8.7 explicitly requires procedures, responsibilities, awareness/training, and business continuity plans to respond to and recover from malware attacks once they occur, which directly addresses the malware-payload outcome of successful social engineering but does not address non-malware social engineering outcomes such as credential theft or unauthorized approvals.
- T1684.001detects — A.8.7 requires scanning of email/attachments, webpages, received files, and awareness training plus procedures to collect/verify malware indicators, which can surface impersonation attempts that deliver or rely on malware (e.g. via email or malicious sites), but the technique is fundamentally social-engineering-based with no malware required and many impersonation vectors (e.g. purely textual BEC without attachments or links) fall outside the malware-focused scope.
- T1684.001recovers — A.8.7 point j) explicitly requires business continuity plans including backups and recovery measures for recovering from malware attacks; while impersonation is a social-engineering technique that can enable malware delivery or follow-on actions, the control's recovery provisions address post-incident state restoration in those malware-linked cases but do not broadly restore from all impersonation outcomes such as divulged information or completed financial theft.
- T1684.002detects — A.8.7 explicitly requires scanning email and instant-messaging attachments/downloads for malware before use (including at email servers and when entering the network) plus awareness training on identifying malicious emails; this surfaces some spoofed phishing emails that carry malware but does not address header-only spoofing without a payload or non-malware social-engineering uses.
- T1684.002prevents — A.8.7 explicitly requires controls that prevent or detect use of known/suspected malicious websites (blocklisting), scanning of email/attachments/downloads/webpages for malware before use, reducing exploitable vulnerabilities, and awareness training on identifying/mitigating malicious emails — all of which stop many (but not all) spoofed emails used to deliver malware or enable phishing; however, pure header-spoofing without a malicious payload, weak DMARC policies, or internal Direct Send abuse fall outside malware-focused mechanisms.
- T1684.002recovers — A.8.7 point j) explicitly requires business continuity plans that include backup and recovery measures for recovering from malware attacks, which can be triggered by a successful spoofed email (e.g. as delivery vector for malware or phishing payload).
- T1685detects — A.8.7 explicitly requires regular automated validation of software/content, scanning for malware (including updates and new threats via n/o), anomaly investigation, and awareness-driven reporting of suspicious changes, which surfaces tampering with or disablement of malware tools themselves as a detectable event.
- T1685prevents — A.8.7 explicitly requires rules/controls that prevent unauthorized software (e.g. allowlisting), reducing exploitable vulnerabilities, protective measures against external files/software, and malware detection/repair software that can block known malware before use, which stops many (but not all) T1685 vectors such as installing tampered tools or using malicious payloads to disable defenses.
- T1685recovers — A.8.7 explicitly requires business continuity plans including backups and recovery measures (item j) to recover from malware attacks, which directly addresses restoration after T1685 has disabled or tampered with defensive tools (a malware vector).
- T1685.001detects — A.8.7 requires regular automated validation of system software/data content, scanning for unapproved files/amendments, malware detection software with scans at multiple layers (including email/web), awareness training, and procedures to collect/verify malware info, which can surface anomalous modifications like disabled EventLog service or altered audit policies as potential malware indicators, but this is indirect, scope-limited by risk assessment, and does not guarantee detection of the specific registry/service/auditpol changes described.
- T1685.001recovers — A.8.7 point j) explicitly requires business continuity plans that include backup and recovery measures for recovering from malware attacks, which can encompass restoration of disabled or modified event logging configurations altered by malware.
- T1685.002detects — A.8.7 requires regular automated validation of system software/data content, scanning for unapproved files/amendments, malware detection software with scans at multiple layers (including email/web/network), collection of new malware info, and verification of sources, which can surface tampering with logging components or anomalous changes as potential malware indicators, but this is limited to what such scans/tools observe and does not broadly target logging modifications across cloud platforms.
- T1685.002recovers — A.8.7 point j) explicitly requires business continuity plans that include data/software backup and recovery measures for recovering from malware attacks; while the technique is not itself malware, the control's recovery posture (and its cross-reference to 8.13) can restore logging state or lost log data after the modification has occurred.
- T1685.003detects — A.8.7 requires regular automated validation of system software/content, scans of received data/emails/webpages, collection of new malware intel, and awareness of anomalous indicators, which can surface spoofed UIs or tampered security tools as part of malware detection; this is limited to a slice because the control centers on malware binaries/behavior rather than UI spoofing of already-tampered tools, with placement/config left to risk assessment.
- T1685.004detects — A.8.7 requires regular automated validation of system software/data content, scanning of received files/emails/webpages, collection of new malware intel, and awareness of anomalous activity that can surface auditd tampering as suspicious (e.g. via rule changes or process kills), but this is only a slice of the technique's stealth methods such as library hooking or config edits that evade file-based scans.
- T1685.004recovers — A.8.7 point j) explicitly requires business continuity plans that include backup and recovery measures for recovering from malware attacks, which can restore system state (including re-enabling or reinstalling a disabled auditd configuration) after the technique has run.
- T1685.005detects — A.8.7 requires regular automated validation of system software/data content, scanning for unapproved files/amendments, malware detection software with scans at multiple layers, anomaly-aware placement via risk assessment, and procedures for reporting malware incidents; these can surface log-clearing activity as anomalous but only where it overlaps with malware-like behavior or monitored critical systems, leaving most direct administrative log wipes (wevtutil, PowerShell, file deletion) outside the malware-specific scope.
- T1685.005recovers — A.8.7 point j) explicitly requires business continuity plans that include data and software backup plus recovery measures for recovering from malware attacks; clearing event logs is a post-intrusion cover-up step that can be part of (or immediately follow) a malware attack, so the backup/recovery provisions can restore the cleared logs from offline copies, but this is only a slice of the technique (not all clearing is malware-driven, and online-only logs or rapid re-clearing limit it).
- T1685.006detects — A.8.7 requires regular automated validation of system software and data content (including scanning for unauthorized amendments) plus malware-information collection and awareness, which can surface anomalous log-clearing activity as potential malware or unauthorized change; this is a genuine but minority slice of the technique (most log-clearing is manual/admin or non-malware and outside malware-focused scanning).
- T1685.006recovers — A.8.7 clause j) explicitly requires business continuity plans that include data/software backup and recovery measures for recovering from malware attacks; while the technique is not malware, the control's recovery-from-attack provisions (and cross-reference to 8.13) can restore cleared logs from backups, but this is only a slice of the control's malware-centric purpose and does not address non-malware log clearing.
- T1686detects — A.8.7 requires regular automated validation of system software/content, malware scans at multiple layers (including network gateways and endpoints), collection of new malware intel, and awareness of anomalous behaviors that could surface firewall tampering as part of defense-in-depth monitoring.
- T1686.001detects — A.8.7 requires regular automated validation of system content, scans of received data/email/webpages, collection of new malware info, and procedures to detect unauthorized changes or malware presence, which can surface cloud firewall modifications as anomalous or malicious activity in some (but not all) cases.
- T1686.002detects — A.8.7 requires regular automated validation/scans of systems (d,f), collection of new malware info (n,o), anomaly-aware placement of detection tools (g), and procedures for reporting malware events (l), which can surface firewall-tampering artifacts when they involve known malware, anomalous files, or exploited vulnerabilities, but this is limited to a slice rather than the bulk of rule modifications or config changes that do not involve detectable malware payloads.
- T1686.002recovers — A.8.7 point j) explicitly requires business continuity plans that include backup and recovery measures for recovering from malware attacks; while the technique is not itself malware, the control's recovery posture (and its cross-reference to 8.13) addresses post-incident state restoration after an attack that used firewall tampering as a vector.
- T1686.003detects — A.8.7 requires regular automated validation of system software/content, scanning of received data/email/webpages, collection of new malware intel, and monitoring/reporting procedures that can surface anomalous firewall changes or malware-like activity used to disable it, but this is indirect, scope-limited by risk assessment, and does not target host firewall modifications themselves.
- T1687detects — A.8.7 requires regular automated validation of system software/data content, scanning for malware/unapproved files/amendments, and procedures to collect/verify malware intelligence, which can surface exploitation of defensive tools (especially when it manifests as anomalous files, disabled AV/EDR processes, or known malware artifacts), but this is only a slice of the technique's full scope including stealthy non-malware exploitation of EDR/firewalls/cloud boundaries that leaves no detectable malware footprint.
- T1687prevents — A.8.7(c) explicitly requires reducing exploitable vulnerabilities (via 8.8 technical vulnerability management) that malware can use, directly closing the programming-error vector that T1687 relies on to impair defenses; other clauses (allowlisting, scanning, awareness) add supporting slices but the core exploitation-of-vuln step is only partially reached because vulnerability management is not guaranteed to find or fix every defensive-component flaw before exploitation.
- T1687recovers — A.8.7 point j) explicitly requires business continuity plans including backups and recovery measures for malware attacks, which can restore defensive posture after impairment from exploitation of security tools (e.g., reimaging or restoring EDR/antivirus functionality).
- T1688detects — A.8.7 requires regular automated validation of system software/content, malware scanning at multiple layers (including on access), collection of new malware intel, and procedures for reporting/recovering from attacks, which can surface safe-mode abuse that leaves detectable artifacts or triggers scans when malware attempts to run or persist.
- T1688prevents — A.8.7 explicitly requires rules/controls that prevent unauthorized software (e.g. application allowlisting), reducing exploitable vulnerabilities, protective measures against obtaining malicious files, and defence-in-depth placement of malware tools; these directly stop the adversary from successfully forcing safe mode, registering malicious services/COM objects, or disabling EDR via limited boot on many but not all vectors (e.g. physical access, BCD edits during maintenance, or unpatched boot processes remain possible).
- T1688recovers — A.8.7 explicitly requires business continuity plans including data/software backup and recovery measures (point j) to recover from malware attacks, which directly addresses restoration after a safe-mode-enabled malware incident that has already run and disabled defenses.
- T1689detects — A.8.7 requires regular automated validation of software/content, scanning for malware/unapproved files/amendments, collection of new malware intel, and awareness of downgrade-like evasion (e.g. encrypted delivery), which can surface some downgrade attempts or their artifacts but not the core technique of forcing outdated/vulnerable modes across interpreters, protocols or boot components.
Prevented OWASP Web Top 10 (2025) risks (17)
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).
Why these map — AI rationale (under review)
- A01mitigates — A.8.7's malware scanning, website blocklisting, allowlisting, and defence-in-depth placement at gateways/endpoints can bound the blast radius or block delivery vectors for some A01 members (e.g. certain CSRF or SSRF payloads delivered via malicious email/web), but does not address the core authorization-decision failures that are the class's dominant members.
- A02mitigates — A.8.7's malware-specific controls (scanning, allowlisting, vulnerability reduction, web blocklisting, defence-in-depth placement) limit the realized impact or exploitation path of some misconfigurations that enlarge attack surface, but do not address the core weakness of insecure defaults or incomplete hardening itself.
- A02prevents — A.8.7 guidance explicitly includes reducing exploitable vulnerabilities (c), preventing unauthorized software via allowlisting (a), blocking malicious sites (b), scanning for unapproved changes (d), and hardening placement/configuration (g), which directly close many common misconfiguration vectors that malware exploits; however, the control's dominant focus is runtime malware detection/repair and awareness rather than systematic secure configuration of defaults, cloud settings, or frameworks, leaving a substantial remainder of the class untouched.
- A03mitigates — A.8.7's malware detection, scanning of received files/downloads, blocklisting of malicious sites, and vulnerability reduction can limit the impact or delivery of compromised supply-chain components (especially in the expanded category), but do not address build-pipeline or signing-infrastructure failures and leave many dependency risks untouched.
- A05mitigates — A.8.7's malware detection, scanning of inputs (email/attachments/webpages/downloads), blocklisting of malicious sites, and reducing exploitable vulnerabilities limit the successful payload delivery or execution of some injection vectors (esp. XSS, command injection via malicious files), bounding their realized impact without neutralizing the interpreter boundary itself.
- A05prevents — A.8.7 explicitly prevents malware vectors that deliver injection (e.g. via malicious websites, email attachments, untrusted files, and unpatched vulnerabilities), but leaves the dominant injection shapes (SQLi, command injection, XSS in trusted input paths) untouched.
- A07mitigates — A.8.7's malware scanning, website blocklisting, awareness training, and boundary placement can bound the blast radius or detect hijacking vectors that deliver credential-stealing malware, but do nothing to stop bypass, brute-force, weak reset flows or session flaws that are the core of A07.
- A08mitigates — A.8.7's malware scanning, allowlisting, vulnerability reduction, and recovery measures bound the blast radius or limit realization of some integrity failures (e.g. unsigned/malicious updates or deserialization via malware vectors) but do not address core causes like missing signatures, CI/CD pipeline compromise, or insecure deserialization logic.
- A08prevents — A.8.7 prevents a slice of A08:2025 via malware rules that block unauthorized software (a), reduce exploitable vulns (c), scan/validate data and software (d,f), and protect external sources (e), but leaves most of the class (insecure deserialization, unsigned updates, CI/CD pipeline tampering) untouched.
- A09mitigates — A.8.7's malware detection, scanning, awareness, and response measures (f, l, m) can surface or limit the impact of some logging/alerting failures when they enable malware delivery, but most of the class (absent logs, unmonitored events, unprotected log integrity) is untouched.
- A10mitigates — A.8.7's malware scanning, detection, and recovery measures (f, j, l) can bound the blast radius or consequence of an exception-path failure that delivers or is triggered by malware, but do not address the core weakness of error handling, fail-open logic, or inconsistent states in web application code.
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.