CIS Controls Email and Web Browser Protections Capability Group

Email-server attachment scanning and sandboxing can identify, quarantine, or remove malicious attachments before they reach the recipient.

Removing a malicious attachment before delivery prevents the user from opening the file and initiating its execution chain. The safeguard is limited to malicious files delivered through the protected email environment.

Email sandboxing can detonate weaponized Office documents, PDFs, archives, and other attachments to identify exploit behavior before delivery.

Email detonation chambers can open suspicious documents and observe attempts to retrieve or execute remote templates and payloads before the message reaches the recipient.

Email scanning can identify suspicious LNK attachments and inspect icon-location or target fields that reference remote payloads.

Anti-malware scanners can compare file headers, MIME types, extensions, and content to detect attachments disguised as benign file formats.

Email-server anti-malware directly addresses malicious attachments.

Blocking malicious attachments prevents one major form of user execution.

Email anti-malware can use static, heuristic, and behavioral analysis to identify obfuscated files before delivery.

Heuristic scanning and sandbox detonation can identify packed executables attached to messages, even when packing changes their static signature.

A sandbox capable of executing active HTML attachments may detect JavaScript that reconstructs and writes a malicious payload to disk.

Attachment scanners and sandboxes can identify malicious payloads hidden within documents, scripts, executables, or other carrier files.

Anti-malware can identify encoded or high-entropy attachments and may block encrypted archives that cannot be inspected.

Email anti-malware capable of recursively unpacking ZIP, RAR, 7z, self-extracting archives, and nested archives can identify malicious files before delivery.

A sandbox that renders SVG attachments and executes their embedded scripts may identify payload construction or malicious follow-on behavior.

Anti-malware analysis can identify malicious attachments whose content, signature, or behavior conflicts with their apparent name or file type.

Email gateways can inspect the complete filename and actual file type rather than relying on the first visible extension, allowing attachments such as invoice.pdf.exe or report.pdf.lnk to be blocked.

Email anti-malware and sandboxing can analyze Visual Basic scripts and macro-enabled attachments and quarantine files that exhibit malicious behavior. This does not prevent Visual Basic abuse originating outside email.

Email anti-malware can block suspicious script attachments before they reach an interpreter. Most command and scripting activity occurs after compromise or through channels unrelated to email.

Email scanning or sandboxing may identify PowerShell script attachments or documents that launch PowerShell.

Email anti-malware may quarantine malicious Python scripts or packed Python payloads sent specifically as email attachments. Python activity originating from installed tools or post-compromise execution remains unaffected.

A sandbox may execute JavaScript, JScript, HTA, HTML, or SVG attachments and identify malicious file creation or process execution. Depends on the email security product supporting active-content detonation.

Browser extension allowlists, denylists, installation restrictions, and removal of unauthorized extensions directly prevent malicious browser extensions from establishing persistence or abusing inherited browser permissions.

Disabling unauthorized Outlook add-ins prevents those add-ins from automatically loading code when the email client starts. This directly reduces persistence through email-client add-on functionality.

This technique includes browser extensions, which are directly addressed by the safeguard.

Restricting email-client add-ins mitigates the add-in portion of this parent technique.

Malicious browser extensions may access browser cookies and session information. Restricting extensions removes one important cookie-theft path.

Malicious extensions may access credentials stored in browsers. Extension restrictions reduce that attack surface, but malware already executing with access to the browser profile may still extract stored credentials.

Removing unnecessary or vulnerable browser plug-ins reduces components that a malicious website can enumerate and exploit during a drive-by attack.

Uninstalling unnecessary browser or email-client plug-ins removes potential client-side exploitation targets.

DNS filtering can prevent resolution of known malicious domains used for DNS-based command and control and can sinkhole requests before an endpoint reaches adversary infrastructure.

Blocking known malicious or compromised domains prevents browsers from reaching websites used to exploit users or deliver malicious content.

DNS filtering can block the destination of a malicious link delivered through email before the user reaches a credential-harvesting page, exploit site, or malware download. Newly registered, compromised, or uncategorized domains may initially evade filtering.

Even when a user clicks a malicious link, DNS filtering can prevent successful navigation when the destination domain is known to be malicious.

DNS filtering directly affects DNS and can also prevent connections to malicious domains used for web-based application-layer command and control.

DNS filtering can prevent HTTP, HTTPS, and WebSocket command-and-control connections when the destination domain has been classified as malicious.

DNS and other domain-based destinations may be used as alternative exfiltration channels. DNS filtering only impedes implementations that depend on resolving a known malicious domain.

DNS can carry encoded exfiltrated data over an unencrypted non-command-and-control protocol. Blocking resolution of an adversary-controlled domain can interrupt DNS-based exfiltration, although newly registered or uncategorized domains may initially be allowed.

DNS filtering can prevent a compromised endpoint from resolving known malicious domains used to host tools or secondary payloads. Transfers over direct IP addresses, approved cloud services, compromised legitimate domains, or uncategorized domains may still succeed.

DNS filtering materially mitigates phishing that directs users to malicious domains. It does not mitigate phishing attachments, voice phishing, or messages that do not require visiting a domain.

DNS filtering can block tunnels that depend on resolving known malicious domains, including some DNS and web-based tunnels. Tunnels using direct IP addresses, trusted domains, or infrastructure not yet classified as malicious may still succeed.

DNS sinkholing and reputation-based filtering can prevent resolution of identified dynamic-DNS and generated domains used to reestablish command and control.

DNS filtering services may block or sinkhole known and predicted algorithmically generated domains, for example those that have high entropy in the name.

DNS filtering can block resolution of a known malicious exfiltration destination regardless of whether the transmitted data is encrypted.

Blocking a known malicious destination domain may interrupt an asymmetric encrypted exfiltration channel.

Browsers and email clients are common targets for vulnerabilities. Requiring the latest vendor-supported versions directly reduces exposure to known client-software vulnerabilities.

Browsers and email clients are common targets for vulnerabilities. Requiring the latest vendor-supported versions directly reduces exposure to known client-software vulnerabilities.

Browsers and email clients are common targets for vulnerabilities. Requiring the latest vendor-supported versions directly reduces exposure to known client-software vulnerabilities.

Fully supported, current browsers contain vendor patches and modern security features that reduce successful exploitation when users visit compromised or malicious websites.

Browsers and email clients are common targets for vulnerabilities that provide adversary code execution. Requiring the latest vendor-supported versions directly reduces exposure to known client-software vulnerabilities.

Current Outlook versions include vendor changes that restrict or warn about custom Outlook forms that may otherwise be abused for persistence and execution. The safeguard ensures those security updates are present.

Microsoft updates removed or restricted the legacy Outlook Home Page functionality used for persistence. Preventing obsolete Outlook versions from executing directly prevents continued access to older vulnerable implementations.

Vendor patches address Outlook mechanisms that adversaries may use to establish rule-triggered persistence or execution. Requiring current supported Outlook versions ensures the relevant security changes are applied.

Allowing only the latest supported browser and email-client versions prevents adversaries or users from running obsolete versions that lack current protections. This directly reduces downgrade opportunities involving older, weaker software versions.

This is a partial mapping because several sub-techniques specifically abuse Outlook features addressed by vendor patches. Other Office startup methods involving templates, test keys, and general add-ins are outside the browser-and-email-client scope.

Current browsers incorporate newer extension permission models, security controls, and protections against outdated installation methods. This does not prevent users or adversaries from installing an otherwise permitted malicious extension.

Updating browsers reduces the likelihood that known vulnerabilities can be exploited to extract cookies from browser storage or memory. It does not prevent malware with sufficient local access from directly reading cookies or browser data.

Current browser versions reduce exploitation of known weaknesses that expose stored passwords and authentication data. Updating the browser does not prevent credential theft by malware already executing with access to the user's browser profile.

Keeping browsers current affects browser extensions.

ATT&CK explicitly discusses DMARC, SPF, and DKIM on the Email bombing technique page, including how enabling these mechanisms within an organization (through policies such as DMARC) may enable recipients (intra-org and cross domain) to perform similar message filtering and validation to mitigate this technique.

DMARC may materially reduces phishing campaigns that rely on spoofed or unauthenticated sender domains. DMARC may reduce link-led spearphishing at the sender-authentication and mail acceptance time. It does not inspect the attachment itself though.

DMARC may materially reduces phishing campaigns that rely on spoofed or unauthenticated sender domains. DMARC may reduce attachment-led spearphishing when the campaign depends on spoofed sender trust and domain authentication failure. It does not inspect the attachment itself though.

DMARC may materially reduces phishing campaigns that rely on spoofed or unauthenticated sender domains.

Social engineering is broadly defined as influencing users into actions while minimizing technical indicators, DMARC can be a meaningful control against the email-spoofing branch of this broader technique.

DMARC may not stop all impersonation, but it reduces a major subset where trust is created through control of the visible sender identity and aligned sending domain.

ATT&CK explicitly discusses DMARC, SPF, and DKIM on the Email Spoofing technique page, including how weak or absent DMARC leaves spoofed messages deliverable and how DMARC-enabled filtering mitigates the behavior

Adversaries may abuse container files such as compressed/archive (.arj, .gzip) and/or disk image (.iso, .vhd) file formats to deliver malicious payloads. The execution prevention mitigation mentions the use of blocking container file types at web and/or email gateways which could apply to the implementation of this safeguard.

Adversaries may use VB payloads to execute malicious commands. Common malicious usage includes automating execution of behaviors with VBScript or embedding VBA content into spearphishing Attachment payloads. If .VB objects are blocked at the email boundary then it can mitigate the spearphishing delivery of this technique.

A custom CHM file containing embedded payloads could be delivered to a victim through email then triggered by User Execution If those custom CHM files are blocked at the email boundary, then it can mitigate the delivery of this technique.

dversaries often weaponize Office add-ins (e.g., Excel .xll files or Outlook .wll / .ecf extensions) by sending them via phishing campaigns. Blocking these file types at the email boundary prevents the initial execution and subsequent installation of malicious persistence mechanisms.

File blocking mitigates embedded payloads by completely stripping high-risk file types at the perimeter, denying attackers the ability to deliver the initial malicious file or its nested, obfuscated components. Attackers frequently embed malicious scripts (e.g., .js, .vbs) inside legitimate document formats (e.g., PDFs, Word docs). By blocking macro-enabled or script-based file types, gateways prevent these malicious combinations from ever reaching the user's inbox

LNK files are used as phishing payloads and when a user invokes them they can download or execute additional payloads. If .lnk objects are blocked at the email boundary then it can mitigate the delivery of this technique.

For this technique, adversaries may smuggle data and files past content filters by hiding malicious payloads inside of seemingly benign HTML files. If the implementation for 9.3 can mitigate this technique if it disallows .html, .htm, .hta, and similar active content files as email attachments on the block list.

9.6 can prevent this type of technique if it blocks RAR, 7z, and other known unauthorized self-extracting archive types from specific machines.

9.6 enforcement can reduce user exposure by removing risky files upstream at the point of email delivery.

9.6 enforcement can reduce user exposure by removing risky files upstream at the point of email delivery.

9.6 is a preventive email-gateway control that blocks disallowed attachment types before delivery.

9.6 is a preventive email-gateway control that blocks disallowed attachment types before delivery.

CIS 9.3 helps prevent link-based and web-based initial access by stopping users from reaching malicious or unapproved content in the first place. It does this by requiring updated network-based URL filtering across all enterprise assets, using methods such as category-based filtering, reputation-based filtering, and block lists. In practice, this means enforcing controls that restrict access to unsafe websites, malicious downloads, risky scripts, and unauthorized browser extensions, reducing the risk of phishing, exploitation, and malware delivery.

9.3 helps prevent link-based and web-based initial access by stopping users from reaching malicious or unapproved content by requiring updated network-based URL filtering across all enterprise assets, using methods such as category-based filtering, reputation-based filtering, and block lists. In practice, this means enforcing controls that restrict access to unsafe websites, malicious downloads, risky scripts, and unauthorized browser extensions, reducing the risk of phishing, exploitation, and malware delivery. If 9.3 implementation blocks outbound traffic from machines to unapproved external destinations. Restricting access to known, trusted IP addresses and protocols can prevent attackers from downloading malicious tools or payloads onto compromised servers after gaining initial access.

9.3 helps prevent link-based and web-based initial access by stopping users from reaching malicious or unapproved content in the first place. Adversaries may exfiltrate data to text storage sites instead of their primary command and control channel. If 9.3 implementation blocks unauthorized text storage sites, the technique is defensible.

9.3 helps prevent link-based and web-based initial access by stopping users from reaching malicious or unapproved sites. If 9.3 implementation blocks the URLs of unauthorized cloud storage services that are not approved by the organization then this technique is defensible.

9.3 helps prevent link-based and web-based initial access by stopping users from reaching malicious or unapproved content. If 9.3 implementation blocks unapproved code repositories and repository APIs, this is applicable.

If 9.3 implementation includes outbound web-service use broadly enough to block unauthorized services and risky websites, then this technique is applicable. ATT&CK describes two-way C2 via legitimate web services and again points to web proxies and blocking unauthorized external services as mitigation.

Popular websites and social media acting as a mechanism for C2 may give a significant amount of cover due to the likelihood that hosts within a network are already communicating with them prior to a compromise. Using common services, such as those offered by Google or Twitter, makes it easier for adversaries to hide in expected noise. 9.3 helps prevent link-based and web-based initial access by stopping users from reaching malicious or unapproved content. If 9.3 implementation includes outbound web-services used broadly enough to block unauthorized services and restrict access to unsafe websites, then this technique is defensible.

CIS 9.3 helps prevent link-based and web-based initial access by stopping users from reaching malicious or unapproved content. If 9.3 implementation blocks unapproved social media, code repositories, paste sites, and similar web services across enterprise HTTP/S traffic, this becomes defensible. Adversaries may post content, known as a dead drop resolver, on Web services with embedded (and often obfuscated/encoded) domains or IP addresses. Once infected, victims will reach out to and be redirected by these resolvers.

CIS 9.3 helps prevent link-based and web-based initial access by stopping users from reaching malicious or unapproved content in the first place. It does this by requiring updated network-based URL filtering across all enterprise assets, using methods such as category-based filtering, reputation-based filtering, and block lists. In practice, this means enforcing controls that restrict access to unsafe websites, malicious downloads, risky scripts, and unauthorized browser extensions, reducing the risk of phishing, exploitation, and malware delivery. If 9.3 implementation includes certain risky or suspicious web-services used broadly enough to block unauthorized services, then this technique is applicable.

9.3 helps prevent link-based and web-based initial access by stopping users from reaching malicious or unapproved content in the first place. It does this by requiring updated network-based URL filtering across all enterprise assets, using methods such as category-based filtering, reputation-based filtering, and block lists. In practice, this means enforcing controls that restrict access to unsafe websites, malicious downloads, risky scripts, and unauthorized browser extensions, reducing the risk of phishing, exploitation, and malware delivery. If 9.3 is implemented as a secure web gateway or proxy that can stop the post-click fetch/download, then this technique is applicable.

9.3 helps prevent link-based and web-based initial access by stopping users from reaching malicious or unapproved content in the first place. It does this by requiring updated network-based URL filtering across all enterprise assets, using methods such as category-based filtering, reputation-based filtering, and block lists. In practice, this means enforcing controls that restrict access to unsafe websites, malicious downloads, risky scripts, and unauthorized browser extensions, reducing the risk of phishing, exploitation, and malware delivery. If 9.3 is implemented as a secure web gateway or proxy that can stop the post-click fetch/download, then this technique is applicable.

9.3 helps prevent link-based and web-based initial access by stopping users from reaching malicious or unapproved content in the first place. It does this by requiring updated network-based URL filtering across all enterprise assets, using methods such as category-based filtering, reputation-based filtering, and block lists. In practice, this means enforcing controls that restrict access to unsafe websites, malicious downloads, risky scripts, and unauthorized browser extensions, reducing the risk of phishing, exploitation, and malware delivery.

9.3 helps prevent link-based and web-based initial access by stopping users from reaching malicious or unapproved content in the first place. It does this by requiring updated network-based URL filtering across all enterprise assets, using methods such as category-based filtering, reputation-based filtering, and block lists. In practice, this means enforcing controls that restrict access to unsafe websites, malicious downloads, risky scripts, and unauthorized browser extensions, reducing the risk of phishing, exploitation, and malware delivery.