M0921: Restrict Web-Based Content
Restrict use of certain websites, block downloads/attachments, block Javascript, restrict browser extensions, etc.
Analyst context for executives and security teams
Restrict Web-Based Content is an ICS ATT&CK mitigation focused on reducing the chance that routine browsing, downloads, attachments, JavaScript, or browser extensions become an entry point into operational environments. Its business value is preventive: it helps limit exposure to drive-by compromise, user-driven execution, and malicious attachments before they reach systems or users connected to industrial operations.
Executive priority
Leaders should treat this as a resilience and control-governance issue, not only a web filtering setting. The key decision is whether personnel and systems with access to ICS-related environments can freely browse, download files, run browser scripts, or install extensions in ways that could introduce malware or unsafe code execution. This mitigation also has compliance relevance because the ATT&CK object maps to IEC 62443 SR/HDR 2.4 and NIST SP 800-53 SC-18 labels.
Technical view
For SOC, IR, and security engineering teams, validate whether web content restrictions are applied where ICS users, engineering workstations, jump hosts, or other ICS-adjacent access paths exist. The relationship context ties this mitigation to Drive-by Compromise, User Execution, and Spearphishing Attachment, so defensive validation should focus on blocking or controlling risky website access, downloads and attachments, JavaScript execution, and browser extensions. ATT&CK does not provide detection text or platforms for this mitigation, so local architecture and telemetry must determine where coverage can be proven.
Likely telemetry
- Web proxy or secure web gateway logs showing allowed, blocked, and categorized website access
- Browser policy or endpoint configuration evidence for JavaScript, extension, download, and attachment controls
- Email security or attachment filtering logs where web-delivered or attached content is restricted
- Endpoint security events for blocked downloads, script execution attempts, or browser extension activity
- Change management and compliance evidence showing which ICS-related user groups and systems are subject to content restrictions
Detection direction
- Do not assume the control is effective because a policy exists; validate enforcement against the user groups and systems that can affect ICS operations.
- Review whether blocked-download, blocked-attachment, JavaScript, and browser-extension events are logged in a way the SOC can search during phishing or drive-by compromise investigations.
- Tune monitoring to distinguish routine business browsing from access to newly seen, uncategorized, or blocked sites, while accounting for legitimate vendor, supplier, and industry websites that ICS personnel may need.
- Use the relationship context to test visibility for precursor activity associated with Drive-by Compromise, User Execution, and Spearphishing Attachment, without treating this mitigation as a complete detection strategy.
- Identify blind spots where browsing occurs outside managed paths, such as unmanaged endpoints, vendor access paths, or systems not covered by central web/content policy.
Mitigation priorities
- Prioritize restrictions for users and systems with access to ICS environments or ICS support workflows.
- Block or tightly control risky downloads, attachments, JavaScript execution, and browser extensions according to operational need.
- Align web-content restrictions with email attachment controls because the mitigation is related to spearphishing attachment and user execution risk.
- Maintain documented exceptions for required business, supplier, or engineering sites, and review them periodically.
- Collect policy and enforcement evidence to support IEC 62443 and NIST SP 800-53 control-readiness discussions where those frameworks apply.
Analyst notes and limits
This object is a mitigation, not a technique, and ATT&CK provides no official detection text, no platforms, and no tactics for it. The strongest supported context is its role in reducing exposure to Drive-by Compromise, User Execution, and Spearphishing Attachment in the ICS ATT&CK domain.
The supplied ATT&CK fields do not specify affected platforms, implementation methods, vendors, or detection logic. Effectiveness depends on local network architecture, identity/access paths, browser management, email controls, and SOC log collection. No claim is made that this mitigation prevents all related activity or that any environment currently has coverage.
Restrict Web-Based Content
Restrict use of certain websites, block downloads/attachments, block Javascript, restrict browser extensions, etc.
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 | T0863 | User Execution | If a link is being visited by a user, block unknown or unused files in transit by default that should not be downloaded or by policy from suspicious sites as a best practice to prevent some vectors, such as .scr, .exe, .pif, .cpl, etc. Some download scanning devices can open and analyze compressed and encrypted formats, such as zip and rar that may be used to conceal malicious files. |
| ICS | T0865 | Spearphishing Attachment | Consider restricting access to email within critical process environments. Additionally, downloads and attachments may be disabled if email is still necessary. |
| ICS | T0817 | Drive-by Compromise | Restrict browsers to limit the capabilities of malicious ads and Javascript. |
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 | 2d995e8439c0… |
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 M0921Open 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.