M0948: Application Isolation and Sandboxing
Restrict the execution of code to a virtual environment on or in-transit to an endpoint system.
Analyst context for executives and security teams
Application Isolation and Sandboxing is an ICS ATT&CK mitigation focused on restricting code execution to a virtual environment on, or before it reaches, an endpoint. Its business value is reducing the chance that web content, public-facing application exposure, scripts, remote-service exploitation, or vulnerability exploitation can directly affect sensitive industrial systems.
Executive priority
Treat this as a resilience control for environments where compromise of exposed applications, browsing paths, scripts, or remote services could create operational risk. Leaders should ask which ICS-adjacent workflows depend on untrusted code or internet-facing software, where isolation is actually enforced, and whether compliance evidence maps to the referenced IEC 62443 SR/CR 5.4 and NIST SP 800-53 SI-3 labels.
Technical view
For SOC, IR, and detection engineering, validate whether isolation is applied to the behaviors this mitigation is related to: Drive-by Compromise, Exploit Public-Facing Application, Exploitation for Evasion, Scripting, Exploitation of Remote Services, and Exploitation for Privilege Escalation. Because ATT&CK provides no detection text or platform scope for this mitigation, teams should test locally whether sandboxing events, blocked execution, script activity, public-facing application activity, and remote-service activity are observable and correlated to protected ICS assets.
Likely telemetry
- Sandbox or application isolation policy events
- Blocked or contained code execution records
- Web access and proxy/security gateway logs relevant to drive-by compromise paths
- Public-facing application logs and exposure inventory
- Script interpreter execution logs where available
Detection direction
- Do not assume the mitigation produces detection by itself; ATT&CK does not provide detection guidance for M0948.
- Validate alerting for isolation bypass, policy disablement, failed containment, and code execution outside approved virtual environments.
- Tune detections around the related techniques: browser-driven compromise, exploitation of public-facing applications, scripting, remote-service exploitation, evasion through vulnerability exploitation, and privilege escalation through vulnerabilities.
- Check for blind spots where ICS workflows require legacy software, remote access, supplier access, or exposed management applications that may not tolerate sandboxing or may be excluded from policy.
- Use false-positive review to distinguish approved administrative scripts or maintenance activity from unexpected script execution or contained code events.
Mitigation priorities
- Prioritize isolation for code arriving from higher-risk paths, including web browsing, public-facing applications, remote services, and script execution points that can influence ICS environments.
- Define and document which systems, applications, and traffic flows are in scope, since ATT&CK does not specify platforms for this mitigation.
- Pair sandboxing with vulnerability management and configuration review for internet-facing and remotely reachable software.
- Maintain audit-ready evidence that isolation controls are configured, monitored, and periodically tested, especially where IEC 62443 SR/CR 5.4 or NIST SP 800-53 SI-3 are relevant.
- Ensure incident response playbooks can determine whether suspicious code executed only in the isolated environment or reached the endpoint or industrial network.
Analyst notes and limits
This mitigation is most decision-useful when mapped to concrete exposure paths in the local ICS environment. The supplied relationships indicate relevance to initial access-style web/application exposure, scripting, remote-service exploitation, evasion, and privilege escalation behaviors, but local architecture determines where sandboxing is feasible and valuable.
The ATT&CK object provides a short mitigation description, no official detection text, no platforms, and no tactics. Any coverage assessment requires local control configuration, asset inventory, logging validation, and testing evidence.
Application Isolation and Sandboxing
Restrict the execution of code to a virtual environment on or in-transit to an endpoint system.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| ICS | T0853 | Scripting | Consider the use of application isolation and sandboxing to restrict specific operating system interactions such as access through user accounts, services, system calls, registry, and network access. This may be even more useful in cases where the source of the executed script is unknown. |
| ICS | T0890 | Exploitation for Privilege Escalation | Make it difficult for adversaries to advance their operation through exploitation of undiscovered or unpatched vulnerabilities by using sandboxing. Other types of virtualization and application microsegmentation may also mitigate the impact of some types of exploitation. Risks of additional exploits and weaknesses in these systems may still exist. CitationDan Goodin March 2017 |
| ICS | T0820 | Exploitation for Evasion | Make it difficult for adversaries to advance their operation through exploitation of undiscovered or unpatched vulnerabilities by using sandboxing. Other types of virtualization and application microsegmentation may also mitigate the impact of some types of exploitation. Risks of additional exploits and weaknesses in these systems may still exist. CitationDan Goodin March 2017 |
| ICS | T0866 | Exploitation of Remote Services | Make it difficult for adversaries to advance their operation through exploitation of undiscovered or unpatched vulnerabilities by using sandboxing. Other types of virtualization and application microsegmentation may also mitigate the impact of some types of exploitation. Risks of additional exploits and weaknesses in these systems may still exist. CitationDan Goodin March 2017 |
| ICS | T0817 | Drive-by Compromise | Built-in browser sandboxes and application isolation may be used to contain web-based malware. |
| ICS | T0819 | Exploit Public-Facing Application | Application isolation will limit the other processes and system features an exploited target can access. Examples of built in features are software restriction policies, AppLocker for Windows, and SELinux or AppArmor for Linux. |
All related ATT&CK context
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | 8f5544657b7e… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack M0948Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.