GitHub's 2015 Great Cannon DDoS Made On-Path Code Injection a Net

Summary

GitHub said a distributed denial-of-service attack began around 02:00 UTC on 26 March 2015 and used browsers belonging to uninvolved people to generate requests against targeted GitHub-hosted pages. [1]
GreatFire described an earlier attack against its services and later said malicious JavaScript had been substituted for resources associated with Baidu Analytics. GreatFire attributed the activity to Chinese authorities; Baidu denied that its products had been compromised. Those are attributed claims, not adjudicated findings. [7][8]
Citizen Lab and collaborating researchers reported a network-positioned system that could intercept selected plaintext HTTP requests, inject replacement responses and cause browsers outside China to send repeated requests. They called it the Great Cannon and assessed likely government operation while preserving uncertainty. [2][3][4][5]
The mechanism was not ordinary source-spoofed reflection. Browsers sent application requests from their real addresses after executing injected code, so source-address validation remained important but did not directly remove this traffic class. [6][11][12][13][14]
Responsibility was divided across path operators, third-party resource publishers, browsers, GitHub, transit providers and mitigation partners according to what each could actually observe, change and prove.
Authenticated encryption raises the cost of response substitution because it protects content integrity, but it does not eliminate every form of censorship, endpoint compromise, denial of service or traffic analysis. [15][16]
The durable accountability standard is evidence from the running network: multi-vantage response comparison, transport-authentication records, route and transit context, edge classification, mitigation actions, customer impact and a timeline that keeps observation separate from attribution.

In March 2015, GitHub became the visible target of an attack whose most important feature was not simply its size. The event reportedly turned browsers belonging to uninvolved users into request generators by changing what those browsers received on a network path. A person could visit an unrelated page, fetch an unencrypted third-party resource, receive substituted JavaScript and then have the browser send repeated requests toward pages hosted on GitHub. The browser's connection was real. Its source address was real. The user's intention was absent.

That distinction changes the accountability problem. A conventional discussion of denial of service often begins with malicious hosts, forged source addresses, reflection amplifiers or a botnet controlled through compromised devices. Those models remain important, but they do not fully describe the public reconstruction of the 2015 GitHub event. Here, the alleged control point sat in the delivery path for ordinary web traffic. It reportedly altered application content and borrowed the reach of browsers that neither GitHub nor their owners had volunteered for the attack.

GitHub controlled the service under pressure. It could classify traffic, allocate edge capacity, coordinate with mitigation providers, rate-limit abusive requests, protect targeted repositories and communicate operational status. It did not control the remote path on which a third-party response was reportedly altered. The website serving or embedding the resource controlled whether that dependency used authenticated encryption. Browser vendors controlled some execution and mixed-content boundaries. Transit and access operators controlled different path segments, logs and technical opportunities.

Users controlled almost none of this machinery.

The event therefore resists a single-victim, single-attacker explanation. It is a network accountability case because responsibility follows practical control over delivery, integrity, routing, execution and mitigation. Names, addresses, status notices and contracts describe intended relationships. They do not prove what code crossed a path or what a browser executed. The decisive evidence is the behavior of the running network.

What the public record establishes

GitHub's first-party notice provides the safest starting point. The company said the attack began at approximately 02:00 UTC on Thursday, 26 March 2015. It described the event as the largest DDoS attack in GitHub's history at that time and said it involved a combination of attack vectors, including techniques that used browsers of uninvolved people to flood the site. GitHub also said reports available to it led the company to believe the purpose was to convince it to remove a particular class of content. [1]

That statement establishes GitHub's observation of the victim-side event and its interpretation of the apparent objective. It does not establish every packet rate, the total number of browsers, every affected customer, a precise end time, a monetary loss, or the identity of an individual decision maker. It also does not transform GitHub's interpretation of motive into a judicial finding about the attack's sponsor.

GreatFire supplied a related chronology from the other target's perspective. It said its services had been under a large denial-of-service attack since 17 March. In a later post, GreatFire said browsers were being directed through malicious JavaScript toward GreatFire content and two GitHub pages. It attributed the attacks to Chinese authorities and discussed the use of resources associated with Baidu Analytics. GreatFire also recorded Baidu's denial that its products had been compromised. [7][8]

These statements matter because they connect the earlier GreatFire phase to the later GitHub-hosted targets. They must nonetheless be handled as statements by an affected party. GreatFire's technical observations and attribution are evidence to assess, not a substitute for independent measurement. Baidu's denial must remain visible because server compromise, knowing participation, third-party misuse and on-path substitution are different factual propositions.

The strongest public technical reconstruction came from Citizen Lab, the International Computer Science Institute, UC Berkeley, Princeton researchers and collaborators. Their report distinguished the system they named the Great Cannon from the Great Firewall while identifying code and network-location similarities. They described selective interception of unencrypted requests and the injection of replacement content that caused browsers to send requests toward targeted sites. Their analysis used measurements, side channels and observed behavior to localize the system and assess likely operation. [2][3][4][5]

The researchers' conclusion supported a likely Chinese government operator assessment. That is not the same as a public criminal judgment, a disclosed command order or proof about a named individual. Responsible analysis preserves the level of confidence and the method that produced it. The relevant statement is that measurements supported a likely operator assessment, not that every institutional or personal link was proven.

The public record therefore establishes a narrow but consequential chain. Plaintext third-party web traffic crossed a path where a system reportedly could substitute executable content. Browsers receiving that content generated traffic against targets. GitHub observed a major availability attack. Researchers reproduced and measured characteristics consistent with a distinct network injection system. Affected parties and researchers attributed responsibility at different confidence levels. Important details remained undisclosed.

The network mechanism is the accountability core

The key event occurred between an intended resource and the bytes a browser actually executed. A web page could reference a script or analytics resource over plaintext HTTP. The browser sent a request. A system positioned on the path reportedly recognized selected requests and injected a replacement response. The replacement contained code that directed the browser to issue repeated requests against specified targets.

The browser did not need to be permanently infected. The user did not need to install malware or join a botnet. The origin server did not necessarily need to be compromised. The injected response could win a race against the legitimate response or otherwise arrive in a position where the browser accepted it. Once accepted, normal browser behavior produced application-layer traffic from the user's real network address.

This mechanism separates three identities that incident reports often collapse.

First is the identity of the resource named in the page. A URL and DNS resolution indicate where the browser intended to retrieve content. Second is the identity of the network endpoint that actually supplied the accepted bytes. On plaintext HTTP, the browser lacked cryptographic proof that those bytes came from the intended publisher without alteration. Third is the identity of the browser that later contacted GitHub. Its source address identified the client connection but not the user's intent or the origin of the injected instruction.

The distinctions are operationally important. If analysts treat every request source as a willing attacker, they misclassify users whose browsers were enlisted. If they treat the resource publisher as necessarily compromised, they may overlook on-path alteration. If they treat a DNS record or route as proof of content authenticity, they confuse reachability with integrity. If they call the event source-spoofed reflection, they choose controls designed for a different traffic property.

The Great Cannon reconstruction therefore creates a chain-of-custody problem for network content. An accountable investigation needs to show what was requested, which paths carried the request and response, which bytes arrived at multiple vantage points, whether transport authentication was present, what timing differentiated injected and legitimate responses, and what browser behavior followed. Without that chain, labels such as attack, compromise, censorship or platform failure may be directionally plausible but operationally incomplete.

Running code outranks intended records

The Heng.lu doctrine is useful here as an operational test, not as a source of historical facts. A registry entry, DNS record, repository URL or hosting contract is a record of intended identity and authority. It can be important evidence. It is not sovereign over what the running network actually delivered.

The 2015 event makes that principle concrete. A browser could resolve the expected hostname and send a request toward the expected service, yet still execute bytes reportedly inserted on the path. The administrative record remained recognizable while the runtime result diverged. Accountability requires reconciling those two layers rather than treating the record as conclusive.

Running-code primacy does not mean records are irrelevant. DNS, routing tables, RPKI data where available, transit relationships, interface assignments, certificate chains, HTTP headers and status notices all help reconstruct the intended path and the observed deviation. The point is that they must be tested against packet captures, response hashes, timing, browser execution and multi-vantage observations.

This is also why the article's doctrine surface is directly network-infrastructural. Peering and transit determine which operators and interfaces may have carried traffic. Hosting and network identity determine what content and endpoints clients expected. Operator continuity determines whether GitHub could remain reachable while preserving the targeted material. Remove those elements and the accountability thesis disappears.

The reality layer also restrains advocacy. The technical record does not require endorsing GitHub, GreatFire, Baidu, a government, an encryption mandate or a particular censorship-circumvention strategy. It requires accurate statements about control and evidence. Who could alter plaintext delivery? Who could detect inconsistent responses? Who could authenticate content? Who could absorb or filter resulting traffic? Which records can be independently checked? Those questions remain valid regardless of a reader's view of the hosted material or the political dispute.

Why source-address validation was necessary but insufficient

Source-address validation is one of the most important defenses against denial-of-service attacks that rely on forged addresses. BCP 38 and related guidance describe filtering traffic with source addresses that should not legitimately originate behind an interface. Enhanced feasible-path unicast reverse-path forwarding develops operational methods for applying source validation in networks with multiple paths. NIST's interdomain resilience guidance places source-address validation alongside routing security and DDoS mitigation. [12][13][14][17]

Those controls reduce the ability of an attacker to send packets that pretend to come from a victim. That in turn constrains reflection and amplification attacks in which public services reply to a forged victim address. The Internet benefits when access, hosting and transit operators deploy these controls correctly.

The reported Great Cannon mechanism presents a different property. A browser executed injected code and opened genuine connections from its own address. The source address was not necessarily forged. A source-validation filter could correctly conclude that the traffic was topologically plausible and still pass it. The harmful purpose came from the instruction that caused the browser to send requests, not from a falsified network-layer source field.

This does not make anti-spoofing irrelevant to the broader DDoS environment. An incident can combine vectors. Strong source validation reduces other traffic classes and preserves mitigation capacity. It also improves the evidentiary value of source addresses by reducing obvious forgery. But claiming that BCP 38 alone would have stopped the 2015 browser-enlistment mechanism would confuse layers.

An accountable control map should therefore connect each control to the property it changes. Source validation constrains forged source addresses. Authenticated encryption constrains undetected content substitution between authenticated endpoints. Browser policy constrains code execution and mixed content. Edge controls constrain request rates and resource consumption. Traffic engineering and mitigation capacity constrain availability loss. No single control covers every part of the chain.

Authenticated transport changes the injection opportunity

Plaintext HTTP does not provide a browser with cryptographic assurance that a response remained unmodified between the named server and the client. A system on the path may observe the request and attempt to substitute a response. The public reconstruction of the Great Cannon depended on precisely this exposure.

Authenticated encryption changes the contest. TLS is designed to establish an authenticated encrypted channel that protects messages from eavesdropping, tampering and forgery within its threat model. TLS 1.3's later standard expresses these goals clearly. RFC 7258 likewise treats pervasive monitoring as an attack to be mitigated in protocol design. [15][16]

If a browser correctly validates an authenticated TLS connection to the intended origin, an on-path system cannot simply alter the protected response and produce a valid result without defeating the authentication or compromising an endpoint or trust dependency. That raises the operational cost of the substitution technique and creates clearer failure evidence. A forged or modified response should fail validation rather than silently execute as the intended resource.

The limitation matters as much as the benefit. HTTPS does not make a service immune to volumetric DDoS. It does not protect an endpoint that is itself compromised. It does not prevent blocking, connection resets, route manipulation, traffic analysis or pressure on intermediaries. It does not guarantee that third-party code is benign. It does not eliminate mistakes in certificate validation, browser policy or origin configuration.

The accountable claim is therefore bounded: authenticated encryption materially protects response integrity against straightforward on-path substitution. It is not a universal cure for censorship or denial of service. Operators should document which resources were encrypted, which were not, whether mixed-content behavior created downgrade paths, and how certificate or transport failures appeared across vantage points.

Multi-vantage evidence is essential

An on-path injection system may behave selectively. It may target only particular hostnames, resource paths, query strings, source networks, destinations or times. It may inject on some routes and remain absent on others. A single vantage point cannot show whether an anomalous response originated at the server, appeared on a path segment or resulted from a local device.

Multi-vantage measurement addresses that limitation. Investigators can request the same resource from different networks and regions, compare response bytes and hashes, record timing and IP metadata, and preserve packet-level evidence where lawful and proportionate. If one vantage receives altered content while another receives the expected response, the difference narrows the possible control points. If the first response differs and a later response matches the origin, timing may support a race-injection hypothesis.

If the origin logs do not show the substituted bytes, server compromise becomes less likely, though not automatically impossible.

The evidence package should separate raw observations from inference. Raw evidence includes timestamps, request details, received payloads, cryptographic hashes, certificate validation results, packet traces, route observations and resolver responses. Inference includes the likely location of the injector, its relationship to known filtering infrastructure and the likely operator. Conclusions should state what combination of measurements supports them and what alternatives remain.

Clock quality is especially important. Correlating a browser's resource fetch with injected code execution and later requests to GitHub requires timestamps that can be compared across systems. Collection delays, local clock error and time-zone conversion should be recorded. A compelling diagram without time integrity can still conceal a false sequence.

Retention policy also matters. Packet captures may contain sensitive user data, while browser traces may expose browsing behavior. An accountable investigation minimizes collection, restricts access, hashes artifacts, records transformations and preserves only what is necessary. Privacy is not a reason to abandon evidence, but evidence collection is not a license to retain unrelated user activity.

GitHub's control boundary

GitHub was the victim-side infrastructure operator. Its immediate obligation was to keep the service available, protect the integrity of hosted content, distinguish hostile load from legitimate use and communicate what users needed to know. The company could not directly change a remote plaintext response injected on another network path, but it controlled how its own edge and application responded to the resulting requests.

GitHub's earlier account of denial-of-service defense provides useful context. It discussed layered measures including network-stack tuning, load-balancer limits, filtering equipment and work with an external mitigation provider. [9] That account predates the 2015 incident. It shows the kinds of controls GitHub had discussed publicly; it does not prove that each control was active, configured identically or effective during the Great Cannon attack.

For the 2015 event, an accountable victim-side record would include request classification, source and network distribution, target URLs, connection behavior, cache and application load, filtering decisions, mitigation-provider handoffs, edge saturation, error rates and customer-visible performance. It would also record how controls avoided punishing legitimate users whose browsers had been enlisted without their knowledge.

This creates a difficult classification problem. The browser requests were unwanted from GitHub's perspective, but they could resemble valid HTTP traffic. Blocking every source after a burst could affect users sharing addresses or networks. Serving expensive responses could amplify resource consumption. Removing the targeted content might reduce the attacker's incentive but would transfer control over hosting policy to the attacker.

GitHub's public statement indicates that the company understood the pressure as content-directed. [1] That makes continuity partly a governance issue, but the technical response still needs network evidence. The question is not whether GitHub made a brave or correct political choice. It is whether its controls maintained service and content integrity under an attack designed to make ordinary client traffic expensive.

The best incident record would show decision thresholds. At what request rate did GitHub change filtering? Which indicators distinguished browser-enlisted traffic? When did it involve external mitigation? What was the effect of each change on target availability and unrelated traffic? Which controls were reversed after the event? Public disclosure may need to omit sensitive details, but internal evidence should preserve them.

Path operators and the burden of inspectable control

The reported injection opportunity existed because a system had a position on the delivery path. That position created technical power: the ability to observe selected plaintext requests and attempt to replace responses. With power comes an evidence burden.

An operator responsible for interfaces capable of content manipulation should be able to identify the policy that authorizes the function, the systems that implement it, the people or roles that can change it, the logs that record activation, and the controls that prevent unauthorized use. If the operator denies involvement, independently verifiable records are more persuasive than a categorical statement without technical support.

This does not mean every transit provider carrying a packet is responsible for every alteration. Internet paths cross multiple administrative domains. Routing can change during an incident. Some operators may have no visibility into encrypted application content or no ability to identify an upstream injector. Responsibility should attach to actual control and evidence, not physical proximity or political assumption.

Route data can narrow the inquiry but cannot resolve it alone. BGP observations can show which autonomous systems announced and propagated reachability and which paths external collectors observed. They generally cannot prove the location of application-layer content substitution. Traffic may traverse internal links or policy systems not visible in public control-plane data. An accountable reconstruction combines routing context with active measurements and packet behavior.

The same caution applies to IP geolocation and ownership records. An address registration identifies an allocation or administrative contact. It does not prove which device emitted a packet, who controlled that device at the time, or whether the visible source was part of a race. Registry data is an important ledger, not a verdict.

Peering and transit relationships complicate disclosure. Commercial contracts may restrict publication, and providers may fear exposing defensive architecture. Yet the absence of a public topology map does not eliminate the need for auditable internal records. Operators can preserve interface identifiers, route snapshots, change approvals and event hashes while disclosing only bounded findings.

Third-party resource publishers and dependency integrity

The attack path reportedly relied on browsers requesting third-party resources over plaintext HTTP. That makes resource publishers and embedding sites part of the control map, but not automatic perpetrators.

A publisher controls how it serves its resources, whether authenticated transport is available and enforced, how cache and integrity behavior are configured, and how it investigates reports of inconsistent content. A site embedding the resource controls whether it introduces a plaintext dependency into an otherwise protected page. Browser policy can warn, block or isolate some mixed-content patterns.

These responsibilities should not be converted into unsupported blame. The record includes Baidu's denial that its products were compromised. [8] On-path substitution is specifically important because it can make a legitimate publisher appear to have served code that the publisher says it did not serve. The correct inquiry is evidentiary: what did the origin log, what did clients receive from different paths, what transport protection was used, and what hashes or signed artifacts exist?

Subresource integrity and content security controls may help in some designs, but they have scope and deployment limits. A browser must receive a trustworthy integrity value, the page must enforce it, and dynamic resources may complicate use. These controls should be evaluated as parts of a system, not cited as magical protections after the fact.

Dependency inventory is another accountability requirement. Organizations should know which external scripts, analytics resources and content-delivery endpoints their pages cause browsers to contact. They should record scheme, hostname, ownership, expected behavior, update method and failure mode. A dependency that can execute code deserves stronger scrutiny than a static image.

The user's lack of agency is central. People whose browsers generated requests did not necessarily choose GitHub as a destination, understand the injected code or know that their bandwidth was being used. Telling users to behave more safely does not address a path-level system that changed ordinary traffic. Responsibility belongs primarily with actors controlling the path, the resource, the execution environment and the target's mitigation boundary.

Browser and platform controls

Browsers mediate the boundary between received code and network action. They decide whether to execute scripts, how to apply same-origin policy, how to handle mixed content, how to enforce certificate validation, and how to constrain repeated requests. Those decisions are shared across standards, vendors, site authors and user settings.

A browser cannot infer malicious intent from every repeated request. Modern web applications legitimately make many asynchronous calls. Rate limits that are too strict can break normal sites. Limits that are too permissive can allow a page to consume bandwidth and target resources. The Great Cannon event illustrates why browser abuse controls need evidence-based thresholds and isolation mechanisms.

Useful controls include clear mixed-content restrictions, authenticated transport by default, limits on abusive background activity, visibility into unexpected cross-origin request patterns and rapid security updates. Browser vendors can also provide diagnostic tooling that helps researchers preserve evidence without exposing unrelated personal data.

The platform operator's accountability is not unlimited. A browser cannot prevent a network from dropping packets. It cannot guarantee the honesty of every authenticated origin. It cannot absorb an attack on behalf of GitHub. But it can reduce the ease with which injected code silently turns a user into a request source.

An incident review should record browser versions, policy behavior and execution differences. If some browsers accepted the injected code and others did not, that is operational evidence about the attack surface. If behavior changed after updates, the timeline should distinguish event-time capabilities from later protections.

DDoS mitigation without false equivalence

IETF guidance on denial of service emphasizes protocol design, resource exhaustion, amplification and operational defense. [11] It is useful context for understanding why services need rate controls, capacity planning, filtering and coordination. It is not proof of the precise 2015 vector.

The browser-enlistment pattern generates legitimate-looking application requests. Mitigation therefore has to operate across layers. Network controls can absorb or distribute traffic. Transport controls can limit connection pressure. Application controls can identify repeated requests, expensive paths and anomalous behavior. Content delivery can cache safe responses. Human operators can coordinate with upstreams and mitigation providers.

Each intervention has costs. Aggressive filtering can block legitimate users. Challenges can impose accessibility or privacy burdens. Rate limits can punish shared networks. Moving traffic can overload a clean destination. Removing content can reward coercion. A credible response record explains these tradeoffs rather than reporting only that mitigation succeeded.

Mitigation providers also hold evidence. They may see traffic before and after filtering, classify request patterns, change route announcements and operate scrubbing capacity. Contracts should preserve the customer's access to incident evidence and define retention, clock integrity, data handling and after-action support. Outsourcing mitigation does not outsource accountability.

The response should be tested under realistic traffic. A tabletop exercise can verify contacts and decision rights but cannot prove that filters, routes, caches and applications behave safely under load. Controlled exercises should measure time to classification, clean-capacity headroom, false positives, application saturation and rollback behavior.

The 2015 public notice does not reveal every GitHub mitigation step. That absence should remain an unknown, not an invitation to invent a heroic or negligent response. The accountability standard concerns what evidence an operator should preserve and what claims the public record can support.

Separating attribution from mitigation

Operations teams often need to mitigate before attribution is mature. GitHub had to respond to traffic and service effects regardless of who operated the injection system. Researchers could later analyze network location, code similarity and behavior. These timelines should be connected but not conflated.

Mitigation decisions should rely on observable traffic properties: request paths, rates, connection behavior, source distribution, headers, response cost and service health. They should not depend solely on a geopolitical attribution that may be contested. Conversely, an attribution assessment should not be inferred merely from the fact that a mitigation method worked.

Attribution evidence can include technical infrastructure, code characteristics, deployment location, target selection, operational timing and historical context. Each category has alternatives and confidence limits. A strong assessment explains why the combined evidence favors one hypothesis and what evidence would change the conclusion.

Citizen Lab's work is valuable because it did not stop at a political label. It described a mechanism, differentiated systems and presented measurement. [2][3] Peer-reviewed presentations and related research added technical scrutiny. [4][5][6] The analysis still should not be rewritten as a court judgment.

GreatFire's attribution reflects the view of an affected organization. [7][8] GitHub's statement reflects the victim platform's interpretation of pressure. [1] Baidu's denial addresses its own products. These accounts can coexist in an evidence table without being merged into a false consensus.

This separation protects both fairness and response quality. It prevents operators from delaying mitigation until political certainty exists, and it prevents emergency traffic observations from being treated as conclusive proof of sponsorship.

A minimum evidence package for accountable response

An operator facing a comparable event should preserve a linked evidence package. The package does not need to expose sensitive data publicly, but it should support independent internal review and bounded external claims.

1. Event identity and time integrity

Create a stable incident identifier. Record UTC occurrence times, collection times, clock sources, known skew and ingestion delay. Hash exported artifacts. Preserve the distinction between first observation, confirmed incident, mitigation action, stabilization and closeout.

2. Resource and transport identity

Record the requested URL, scheme, hostname, resolver result, expected origin, certificate details where applicable, response headers, payload hash and browser decision. Preserve both injected and legitimate samples when lawfully available. Do not assume the hostname proves the bytes.

3. Multi-vantage path context

Record measurement vantage, network, approximate route context, resolver behavior and response timing. Compare results across paths. Preserve public BGP observations and operator route snapshots, while stating that routing data alone cannot prove injection location.

4. Browser execution evidence

Record the script behavior, destination requests, repetition pattern, browser version, relevant security policy and whether user action was required. Separate temporary execution from persistent compromise. Avoid labeling the user or device as malicious without evidence.

5. Victim-side service evidence

Preserve request rates, target paths, edge and application health, filtering actions, mitigation handoffs, error rates, latency and customer impact. Link each action to a measured change. Record false positives and collateral effects.

6. Operator-control evidence

For systems capable of traffic inspection or alteration, preserve policy authorization, configuration changes, deployment identifiers, access records and integrity logs. For operators outside the suspected path, preserve enough evidence to show their actual boundary rather than issuing an unsupported blanket denial.

7. Attribution assessment

Separate observed facts, analytical inferences, confidence and alternatives. Attribute external claims. State what is unknown. Record later evidence without silently changing the contemporaneous account.

8. Disclosure and retention

Define which findings can be public, which require restricted review and how long underlying artifacts remain available. Redact personal data without destroying the technical chain. Publish corrections when later evidence materially changes a claim.

This package turns accountability from rhetoric into reproducibility. It allows a platform, transit operator, resource publisher, browser vendor or regulator to test whether a claim follows from observable control.

Economic and governance incentives

Network defenses are shaped by incentives. The operator able to deploy a control may not bear the loss created when that control is absent. A third-party resource publisher may save operational effort by leaving a legacy plaintext endpoint available while targets and users bear the risk of substitution. A transit operator may see little commercial reward for retaining detailed evidence. A platform may bear the cost of absorbing traffic generated by browsers it does not control.

Contracts can reduce some gaps. Hosting and mitigation agreements can require event data access, route-change records, retention periods, test support and disclosure cooperation. Resource procurement can require authenticated delivery and inventory. Browser and platform policies can make insecure dependencies visible. None of these instruments proves technical compliance by itself; they create obligations that running evidence must test.

Insurance and incident reporting can also distort incentives if they reward coarse labels over accurate mechanisms. Calling every event a botnet attack may be administratively convenient but can hide the control point that made browser enlistment possible. Reporting should preserve the mechanism even when a category is needed for aggregation.

Regulators should avoid demanding impossible attribution certainty during response. They can instead require bounded facts: what service was affected, what control failed or was bypassed, what evidence was preserved, which actors were notified, what user data was involved and what restoration was verified. Where state activity is alleged, independent technical review becomes more important, not less.

Content policy adds another incentive problem. If an attacker can force a platform to remove material by imposing availability costs, the platform's technical resilience affects expressive freedom. That does not mean every hosting decision is beyond criticism. It means accountability should not describe the victim's choice to host content as the network cause of the attack.

Later recurrence does not rewrite 2015

Later technical reporting described systems called the Great Cannon being deployed again. [10][18] That history supports investment in durable detection, encrypted transport and cross-operator evidence exchange. It does not prove that every later event used identical infrastructure, targets, operators or command authority.

Incident records should therefore preserve event identity. The March 2015 GreatFire-to-GitHub sequence has its own dates, targets, measurements and public claims. Later observations may inform hypotheses or show that a technique remained relevant. They should not be merged into one continuous incident without evidence.

This boundary protects accuracy. Security narratives often become cleaner over time as repeated labels replace messy observations. The cost is that uncertainty disappears and technical differences are lost. Accountability requires the opposite: stable event records, explicit updates and versioned conclusions.

NTT's later technical discussion is useful as an independent analytical perspective on the Great Cannon and DDoS defense. [10] AT&T Alien Labs' later report provides a recurrence boundary. [18] Both belong in context, not as substitutes for the 2015 victim and measurement record.

Counterfactual controls and their limits

A disciplined review can ask how specific controls would have changed the event without claiming certainty about an unobserved alternative.

If the third-party resource had been delivered through correctly authenticated encryption, straightforward on-path response substitution would have been harder because the browser would expect a valid protected response. The counterfactual does not prove that the attacker would have abandoned the objective. Blocking, endpoint compromise, other injection opportunities or a different DDoS method might still have been available.

If browsers had stronger limits on unexpected repetitive background requests, the generated load might have been reduced. The counterfactual must account for legitimate applications and the possibility that code could vary timing or destinations.

If GitHub had more edge and mitigation capacity, the service might have absorbed more traffic. Capacity does not correct the remote content-integrity failure, and no public source establishes the exact additional capacity required.

If operators had richer multi-vantage monitoring, researchers and affected parties might have localized injection sooner or produced stronger attribution evidence. Monitoring itself does not prevent alteration and must be designed with privacy constraints.

If universal source validation had been deployed, many spoofed reflection attacks would have been harder. The browser-generated requests described here would still have carried plausible source addresses. That counterfactual reinforces the need for layered controls rather than diminishing anti-spoofing work.

The purpose of these questions is control design, not hindsight blame. A useful counterfactual names the property changed, the evidence needed and the remaining attack paths.

An accountability standard for on-path injection

The 2015 GitHub attack suggests a practical standard for operators and platforms.

First, authenticate executable resources. Plaintext delivery of code creates a path-level substitution opportunity. Inventory third-party dependencies and remove mixed or unauthenticated execution paths where feasible.

Second, measure from more than one network. A service's origin logs cannot reveal every response a client receives. External vantage points and response hashes help distinguish origin behavior from path behavior.

Third, map control by layer. Name who controls resource publication, DNS, routing, transit, browser execution, target edge, mitigation and customer communication. Do not assign total responsibility to the most visible brand.

Fourth, retain action-linked evidence. Every filter, route change, capacity shift and policy decision should have an owner, timestamp, reason, expected effect, observed effect and rollback condition.

Fifth, keep attribution confidence visible. Technical location and code similarity can support a strong assessment without proving an individual command chain. Public language should match the evidence.

Sixth, protect uninvolved users in mitigation design. Browser-enlisted sources are not equivalent to willing attackers. Controls should minimize collateral blocking and preserve privacy.

Seventh, test continuity without surrendering content decisions to traffic pressure. A platform should know how it will preserve service and lawful hosted material when requests are weaponized against a specific target.

Eighth, connect administrative records to runtime proof. DNS, certificates, routing records and contracts matter because they define expectations. Their accountability value appears only when they can be reconciled with observed delivery and service behavior.

Questions that boards, operators and reviewers should ask

Which resources could execute code in users' browsers, and were all of them delivered over authenticated transport?
What evidence would distinguish origin compromise, on-path substitution, local malware and ordinary publisher behavior?
Which networks and paths produced anomalous responses, and which produced the expected bytes?
Were clocks, captures, payload hashes, certificates, resolver results and route observations preserved on one timeline?
Which party could change the suspected injection system, and what inspectable records document that control?
How did the victim classify browser-generated requests without assuming that every source user intended the attack?
What filtering, rate-limiting, caching, capacity and mitigation-provider actions were taken, and what effect followed each action?
Which legitimate users or unrelated services were affected by mitigation?
What facts support operator attribution, what alternatives remain, and what confidence level is justified?
Were GreatFire's claims, GitHub's interpretation, Baidu's denial and independent measurements kept distinct?
Which controls address source spoofing, which address content integrity and which address target availability?
Could a qualified reviewer reproduce the incident boundary without relying on institutional trust?

Conclusion

GitHub's 2015 DDoS was a network accountability test because the reported control point lay between an intended web resource and the code that browsers actually executed. The attack borrowed ordinary clients, real addresses and shared paths. It exposed the limits of treating endpoint names, source addresses or administrative records as complete descriptions of network behavior.

The public record supports a careful conclusion. GitHub experienced a major content-directed DDoS. GreatFire described a preceding and connected victim-side sequence. Researchers measured a system capable of selective plaintext response injection and assessed a likely operator. Baidu denied that its products had been compromised. Important implementation, volume, cost and command details remain unknown.

Accountability follows control over those facts. Path operators must preserve inspectable evidence for systems capable of alteration. Resource publishers and embedding sites must manage executable dependencies and authenticated delivery. Browsers must reduce silent enlistment. GitHub and mitigation partners must connect edge actions to measured outcomes. Researchers and public authorities must keep observation, inference and attribution separate.

The enduring rule is simple but demanding: the network must be judged by the content, routes and service behavior it actually produced. Records identify intended authority. Running evidence shows whether that authority held. In an incident built on the gap between the two, accountability begins by making the gap visible.

GitHub's 2015 Great Cannon DDoS Made On-Path Code Injection a Network Accountability Test