MITRE ATT&CK T1659 Content Injection: Detecting and Blocking Injected Traffic

If an attacker controls a network path your users or machines rely on, they do not need to compromise a website to deliver malware: they can rewrite the response on its way to you. MITRE ATT&CK tracks this as T1659 Content Injection, a technique listed under both Initial Access and Command and Control for Linux, macOS and Windows. It covers adversaries who sit in the middle of client-server traffic, or race a forged reply to the client from the side, usually from an upstream position such as an internet service provider. This guide is for network security, endpoint and detection engineering teams. It explains how the technique differs from drive-by compromise and enterprise adversary-in-the-middle, which traffic is exposed, the controls that make injection fail, and what to log so you notice when it is tried. It is written for defenders and describes behaviour at the level of the ATT&CK description, not as an attack procedure.

Key takeaways

• Integrity, not secrecy, is the control that matters. Content injection only works where the client accepts a response it cannot verify, so authenticated encryption (TLS with proper certificate validation) and signed payloads defeat it, whatever the attacker's network position.
• The attacker is outside your perimeter. MITRE separates T1659 from Adversary-in-the-Middle (T1557), which describes interception inside the enterprise; T1659 abuses upstream channels such as ISP links, where your network controls never see the tampering point.
• Plain HTTP and unauthenticated DNS are the exposed surface. Connectivity checks, update agents, legacy internal tools and third-party scripts loaded over HTTP are the routes recorded in public cases.
• Detection is mostly on the endpoint. MITRE's analytics look for files written by a browser or download utility and executed shortly after, correlated with odd responses on the wire.
• High-risk locations need a trusted tunnel. For staff in countries or networks where the provider itself may be hostile, route all traffic through an end-to-end encrypted tunnel to a location you trust.

What T1659 describes and how it differs from related techniques

ATT&CK v20 describes Content Injection as gaining access to, and continuing to communicate with, victims by injecting malicious content into online network traffic. Instead of luring the victim to a payload hosted on a compromised site, the adversary manipulates a data-transfer channel the victim already uses. The same channel can later deliver further tools, which ATT&CK tracks as Ingress Tool Transfer (T1105), which is why the technique also sits under Command and Control.

MITRE names two positions. From the middle, the adversary is on the path between client and server and can alter or replace the response. From the side, the adversary observes a request and races a forged response to the client before the genuine server answers. MITRE notes the technique is often the result of a compromised upstream channel, for example at ISP level, including abuse of lawful interception capability.

For the related techniques see the MITRE ATT&CK T1557 Adversary-in-the-Middle guide and the Drive-by Downloads Guide. For the full set of initial access doors, see the Initial Access Techniques Guide.

Two reference cases, in defensive terms

MoustachedBouncer and Disco (diplomats in Belarus)

ATT&CK describes MoustachedBouncer (G1019) as a cyberespionage group active since at least 2014 targeting foreign embassies in Belarus. It records that the group injected content into DNS, HTTP and SMB replies to redirect specifically targeted victims to a fake Windows Update page to download malware, and that its Disco malware (S1088) gained initial access and execution the same way. The route in was plain, unauthenticated traffic.

The defensive lessons are specific. Genuine Windows updates never arrive as a downloadable archive from a web page; outbound SMB to the internet should not be possible from a client; and ATT&CK's mitigation for this technique (M1041) is to make sure online traffic is appropriately encrypted, for example through trusted VPNs. Our recommendation (NHI Mgmt Group) for organisations in high-risk jurisdictions is an end-to-end encrypted tunnel to a trusted location for all internet traffic, ideally built out of band rather than from the endpoint itself.

The Great Cannon (2015)

Citizen Lab's April 2015 report on what it named the Great Cannon describes an in-path system that intercepted unencrypted requests for analytics, social and advertising scripts served from Baidu infrastructure. For a small fraction of requests it dropped the request and returned a malicious script, which turned visitors' browsers into a denial-of-service source against GreatFire.org and two GitHub repositories. Visitors were often outside China and had simply loaded a site that embedded those scripts. Citizen Lab concluded that replacing legacy protocols such as HTTP with cryptographically strong versions was urgent, and noted that, reconfigured, the same capability could deliver a malicious payload to targeted users communicating with unencrypted servers it covers.

The lesson for website owners: every third-party script you embed is part of your users' attack surface. Loading it over HTTPS with Subresource Integrity, or self-hosting it, means a tampered copy is refused by the browser.

Which traffic is exposed

Map your estate against the channels below. Anything in the left column that still runs without authenticated integrity is a candidate for injection.

Prevention: making injected content fail

MITRE maps two mitigations to T1659: Encrypt Sensitive Information (M1041), with the note that online traffic should be appropriately encrypted, for example through trusted VPNs, and Restrict Web-Based Content (M1021), blocking download and execution of uncommon file types used in campaigns. In practice the work breaks into five layers.

1. Authenticated transport everywhere you own the server. Serve sites and APIs over HTTPS only, redirect HTTP, and set Strict-Transport-Security with a long max-age and includeSubDomains. RFC 6797 is explicit that a browser only learns the policy after one secure connection, which it calls the bootstrap MITM vulnerability; preloading closes that gap. The NCSC advises enabling and preloading HSTS, adding upgrade-insecure-requests to your CSP, using TLS 1.3 and disabling TLS 1.0, 1.1 and all SSL. See the HSTS and HSTS Preload guide and the TLS Server Configuration Baseline Guide.
2. Browsers that refuse plain HTTP. Use enterprise policy to turn on HTTPS-first or HTTPS-only behaviour so unencrypted navigations warn or fail. See Chrome HTTPS by Default.
3. Integrity on what you embed. Add Subresource Integrity hashes to third-party scripts and stylesheets, or self-host them, and restrict script sources with a Content Security Policy. A mismatched hash means the browser refuses to execute the response. See the Content Security Policy Guide.
4. Signed updates over a protected channel. Every update path should verify a signature before install. Microsoft's WSUS documentation warns that without TLS an attacker can modify update information in transit and install malicious software; WSUS protects metadata over HTTPS (8531 by default) and payloads by signature and a hash delivered on that HTTPS channel. Apply the same test to internal package mirrors and agent self-update. See the Code Signing Security Guide.
5. Trusted resolution and egress. Validate DNSSEC where your zones support it, send endpoint DNS to a trusted resolver over DoH or DoT, and block outbound SMB at the internet edge. See the DNSSEC Deployment Guide and the Encrypted DNS Enterprise Guide.

Decision guidance: VPN or not

• Ordinary remote working: TLS everywhere plus HTTPS-only browsing and signed updates removes most of the exposure. A full-tunnel VPN adds little integrity protection for traffic that is already authenticated.
• High-risk travel and in-country offices: where the ISP or state may tamper, tunnel all traffic to a trusted location, in line with ATT&CK's M1041 guidance on trusted VPNs. A dedicated travel router or gateway that builds the tunnel keeps the endpoint's own pre-VPN connectivity checks off the hostile network.
• Small organisations: prioritise HSTS on your own domains, managed browser policy and automatic signed updates. These are configuration changes with no new infrastructure.
• Large organisations: add egress controls, TLS inspection only where policy allows it (see the TLS Inspection Guide), and a register of every plain-HTTP dependency with an owner and retirement date.

Where identity fits

Machine identities are the quiet exposure. Scripts, CI runners, agents and service clients often call APIs with certificate validation turned off to get past an internal CA error, or call an HTTP endpoint because nobody updated the URL. An injected response to one of these clients can deliver a tampered configuration or binary that then runs with the service account's privileges, and the same channel can capture bearer tokens sent in the clear. Treat "TLS with validation" as a non-negotiable property of every non-human identity's connections, scan code for disabled verification flags, and use mutual TLS where a service must prove who it is talking to. See the mTLS Guide.

Detection and measurement

You will rarely see the tampering point itself, because it is upstream. ATT&CK v20's detection strategy for T1659 therefore pairs network anomalies with what happens on the endpoint next.

Add three detections that fit the public cases: requests to update or vendor domains that resolve to unexpected addresses, any outbound SMB to the internet, and a user downloading an "update" archive from a browser session rather than through the managed update agent.

Metrics that show the controls are working:

• Percentage of your public hostnames serving HSTS with includeSubDomains, and the number on the preload list.
• Count of plain-HTTP requests leaving managed endpoints per week, trending to zero outside an approved exception list.
• Percentage of third-party script tags on your sites with Subresource Integrity or self-hosting.
• Number of code repositories with disabled TLS verification flags, and time to fix.
• Blocked outbound SMB connection attempts per month (should be near zero; spikes need triage).
• Percentage of staff in high-risk locations whose traffic egresses through the approved tunnel.

Rolling out the controls

1. Inventory (weeks 1 to 2): pull a month of proxy and DNS logs and list every destination still reached over HTTP, every third-party script on your sites, and every update channel.
2. Own domains first (weeks 2 to 6): enable HTTPS redirects and HSTS with a short max-age, check nothing breaks, then raise it and submit for preload. Rollback is lowering max-age before preloading; after preloading, removal takes much longer, so preload last.
3. Browser policy (weeks 4 to 8): enable HTTPS-first in a pilot ring, collect the warnings, fix or except internal sites, then extend to all users.
4. Update and agent paths (weeks 6 to 12): move WSUS and package mirrors to TLS, confirm signature verification is on, and remove any updater that fetches unsigned content.
5. Egress and DNS (weeks 8 to 12): block outbound SMB, move endpoint DNS to the trusted resolver, and deploy the tunnel for high-risk travel.
6. Detections (ongoing): deploy the endpoint analytics in alert-only mode, tune for software installers and developer tools, then add to triage queues.

These timescales are NHI Mgmt Group suggestions; adjust them to your change process.

Framework mapping

Common failure patterns

• HSTS without preload on the login domain. First visits from a new device or a cleared browser remain exposed, exactly the bootstrap gap RFC 6797 describes.
• Trusting plain HTTP background requests. Captive portal and connectivity probes and other background HTTP requests are unauthenticated; the MoustachedBouncer case shows a tampered HTTP reply can become the first lure.
• Analytics and advertising scripts loaded without integrity. The Great Cannon turned visitors of ordinary sites into attack traffic through exactly these scripts.
• "verify=False" left in production clients. A workaround for a certificate error becomes a permanent opening for injected responses to a privileged service account.
• Update servers on HTTP only. WSUS and internal mirrors set up without TLS leave update metadata open to modification, which Microsoft's own documentation warns can lead to malicious software installs.
• Outbound SMB allowed. Second-stage payloads fetched over SMB from internet hosts should be impossible at the egress.

Practitioner checklist

• List every destination your managed devices reach over plain HTTP and assign an owner to retire each one.
• Serve all your domains over HTTPS with HSTS, includeSubDomains and preload.
• Enforce HTTPS-first or HTTPS-only browsing through managed browser policy.
• Add Subresource Integrity or self-host every third-party script and stylesheet.
• Confirm every update channel verifies signatures and carries metadata over TLS.
• Block outbound SMB (TCP 445, plus legacy NetBIOS 137 to 139) to the internet.
• Send endpoint DNS to a trusted resolver over DoH or DoT and validate DNSSEC where supported.
• Scan code and configuration for disabled TLS verification in service clients.
• Deploy MITRE's endpoint analytics for download-then-execute behaviour from browsers and download utilities.
• Provide an always-on tunnel to a trusted egress for staff in high-risk locations.

Standards and references

• MITRE ATT&CK: Content Injection
• MITRE ATT&CK: MoustachedBouncer
• Microsoft Learn: Secure SMB traffic in Windows Server
• Citizen Lab: China's Great Cannon
• IETF: RFC 6797 HTTP Strict Transport Security (HSTS)
• NCSC: Using TLS to protect data
• W3C: Subresource Integrity
• Microsoft Learn: Configure WSUS

Related NHI Mgmt Group resources: CDN Security Guide · How TLS Works Guide · Watering Hole Attacks Guide · Command and Control (C2) Guide