The report states the malware 'employed file copying commands, suggesting targeted sensitive data exfiltration' and that containment involved 'blocking external connections exploited by the malware,' implying the malware relied on outbound network connections for exfiltration and/or C2. An egress allow-list would have blocked these connections to any non-approved destination, preventing the actual exfiltration objective even though the 49 endpoints were still infected. This stops the exfiltration/C2 step rather than the initial infection, so it falls in the 0.7-0.9 band.

The attack chain involved a RAT establishing persistent unauthorized access and multi-year bulk exfiltration of ~500 million guest records (names, passport numbers, payment data) to attacker infrastructure. Egress allow-listing would not stop the initial RDP/legacy-system exploitation, but it would block the RAT's command-and-control channel and, critically, prevent the sustained exfiltration of guest data to non-allow-listed external destinations, denying the attacker's core objective even though the compromise itself occurred.

The initial phishing/malware execution (Mivast/Sakula) still succeeds, but both malware families required outbound C2 connections for 'remote connections and covert operations' and 'remote command execution'; these connections to attacker infrastructure (e.g., we11point.com, the two flagged IPs) would be blocked since they are not on any allow list. Critically, the final exfiltration of 78.8 million records from the data warehouse to attacker-controlled infrastructure would also be blocked, denying the attacker's objective even though the initial foothold is not prevented.'

The attack chain's final step was data harvesting and exfiltration: 'Collected payment data was sent to remote attacker-controlled servers via sophisticated obfuscation methods.' Egress Control would block outbound connections to any non-allow-listed destination, meaning the POS malware could never transmit stolen card data to attacker infrastructure. The initial compromise via stolen vendor credentials and malware deployment could still occur, but the attacker's ultimate objective—exfiltrating 56 million card records—would be denied, placing this in the 'compromise happens but objective blocked' band.

The report states stolen card data was 'transmitted to an external FTP server' and that 'anomalous network traffic, particularly FTP engagements with Russian IP addresses' went unmonitored. Under strict egress allow-listing, POS systems and internal servers would only be permitted to reach explicitly allow-listed destinations; the external FTP server used for exfiltration would not be on that list, blocking the bulk exfiltration of the 40 million card records. This does not stop the initial phishing/credential theft or lateral movement, but it denies the attacker's ultimate objective of getting stolen card data out of the network, which is why the score falls in the 0.7-0.9 band rather than 1.0.

The attack chain involved a malicious program planted on a LinkedIn employee's machine to steal credentials (requiring exfiltration of those credentials to Nikulin's infrastructure) and, later, exfiltration of the 117 million SHA1-hashed password records to external cybercrime forums/LeakedSource. Egress control would block both the credential-theft callback traffic and, critically, the bulk exfiltration of the user database to non-allow-listed external destinations, denying the attacker's ultimate objective of monetizing the stolen data even though the initial employee compromise and internal database access could still occur.'

The attack chain involved Hydraq establishing a covert backdoor via encrypted channels and exfiltrating data to command-and-control servers located in the US and Taiwan. Since attacker infrastructure would not be on an allow list maintained for hosts, the initial IE exploit and phishing could still succeed, but the malware's C2 communication and subsequent data exfiltration to external CnC servers would be blocked. This does not stop the initial compromise (spear-phishing, IE zero-day exploitation) but denies the attacker's core objective of exfiltrating intellectual property and maintaining a persistent covert channel, placing it in the 0.7-0.9 band.

This invariant would not stop the initial exploitation of Cisco IOS XE web-UI (CVE-2023-20198/CVE-2023-20273), since that is an inbound authentication-bypass exploit, not an outbound connection. However, the report describes the attacker's downstream objectives as heavily dependent on outbound network paths not native to legitimate operations: GRE/mGRE/IPsec tunnels used for persistent access and exfiltration, one case explicitly routing data back to China via GRE/MPLS tunnels, TACACS+ capture files (tac.pcap) exported via FTP/TFTP to attacker infrastructure, STOWAWAY providing encrypted multi-hop relays and SOCKS5/HTTP proxying to C2, and custom Go SFTP clients (cmd1/cmd3) exfiltrating encrypted archives. None of these attacker-controlled destinations (VPS infrastructure, China-based C2, external FTP servers) would appear on a correctly maintained allow list for legitimate carrier traffic, so egress control would block C2 callback and bulk exfiltration even though the routers themselves remain compromised. This matches the 0.7-0.9 band: compromise occurs, but the attacker's collection/exfiltration objective is denied.

The report describes a point-of-sale attack against a third-party merchant processor resulting in exposure and presumed exfiltration of card data (names, account numbers, expiration dates). This directly matches the invariant's stated example of 'Point-of-sale malware tries to send stolen card data to an external FTP server; the transfer is blocked because the server is not on the allow list.' Even though the initial unauthorized access to the POS/vendor environment would not be prevented, egress control at the compromised host/service would block the outbound transfer of stolen cardholder data to attacker infrastructure, denying the attacker's ultimate objective of exfiltrating usable payment data. Confidence is medium because the report does not detail the exact exfiltration mechanism or confirm data actually left the network via an outbound connection versus being read/captured in place.

The report states the actor exfiltrated or obtained administrator credentials, network diagrams, a geographic map, service-member PII, and counterpart network traffic/configuration data from every other state and at least four territories. Egress allow-listing would not block the initial access via the weakly configured remote-access service or edge-device exploitation, but it would block outbound transfer of this collected data to any non-allow-listed attacker infrastructure, and would also block C2 callbacks the actor used to maintain nine months of access. Since the report does not establish that exfiltration occurred through an already allow-listed channel, this invariant denies the attacker's core objective (data theft) even though the initial foothold and internal lateral spread/privileged-account control are unaffected.'

The report explicitly documents attackers attempting to connect to transfer.sh for data exfiltration/malware upload and pinging external addresses like google.com for reconnaissance, plus reliance on C2 infrastructure (multiple listed IPs) to coordinate PsExec/smbexec lateral movement and exfiltrate the 6TB of data. Egress allow-listing would have blocked the transfer.sh connection and any C2 callbacks to attacker IPs, preventing bulk exfiltration of the 6TB dataset and disrupting coordinated ransomware deployment, even though the initial Citrix compromise itself would not have been prevented.

The report describes data exfiltration via SQL injection or similar methods that allowed 'systematic data extraction' of 815 million records, ultimately ending up for sale on the dark web/BreachForums. Regardless of how the attacker got in (phishing, stolen credentials, or SQLi), moving 815 million records out of ICMR's network required an outbound connection to attacker-controlled infrastructure not on any legitimate allow list. Egress control would have blocked this bulk transfer, denying the attacker's ultimate objective of extracting and monetizing the data, even though the initial compromise or internal access might still have occurred. Because exact exfiltration mechanics are undocumented, some uncertainty remains about whether an allow-listed channel could have been abused instead, but the described 'systematic extraction' pattern strongly implies external transfer that egress control would stop.

The attack involved ransomware deployment and possible double-extortion data exfiltration per the report's attack chain. Initial access method is unspecified, so egress control would not block entry, but it would block command-and-control callbacks and any bulk exfiltration of employee PII to attacker-controlled infrastructure, denying the extortion/exfiltration objective even if encryption of local files might still occur. Since the report notes potential exfiltration threats aligned with double extortion, blocking that egress channel is a significant containment of the attacker's objective. Score reflects that ransomware encryption itself is not egress-dependent, but data theft (a key harm here) would be prevented. Confidence is medium due to lack of confirmed exfiltration details.

The report states Money Message exfiltrated 4.7 terabytes of data and used double extortion (encrypt + threaten to publish stolen data), which requires an outbound channel to attacker-controlled infrastructure for both C2 and bulk data exfiltration. Egress allow-listing would not have stopped the initial third-party-connection intrusion, but it would have blocked the large-scale transfer of the 4.7TB of SSNs, health records, and insurance data to attacker servers, denying the attacker's core objective even though the compromise itself occurred.'

The attack chain included large-scale data exfiltration (approx. 500GB) to Vice Society's infrastructure prior to the dark-web leak in October 2022, and likely required C2 communication for lateral movement and ransomware coordination after initial access via leaked VPN credentials. Egress control would block outbound connections to attacker-controlled servers, stopping both the bulk exfiltration of student/contractor data and any C2 channel, even though initial credential-based access and possibly local encryption of systems could still occur. This denies the attacker's exfiltration/extortion objective, though the ransomware encryption itself (a local action) may not require egress and could still disrupt operations.

The initial injection of SUNBURST into the Orion build occurs regardless of network egress rules at customer sites, so the compromise itself is not prevented. However, the report states SUNBURST relied on DGA-generated C2 domains (e.g., avsvmcloud[.]com) to communicate with attacker infrastructure, and that TEARDROP/Cobalt Strike were used for further reconnaissance and data theft. With strict egress allow-listing at all 18,000 customer environments, these C2 connections and any exfiltration or secondary payload downloads would be blocked because attacker infrastructure would never be on the allow list, neutralizing the backdoor's ability to achieve its espionage/data-theft objective even though the malicious update was installed.

The attack chain culminated in exfiltration of ~30GB of data from S3 buckets via AWS CLI commands (e.g., 's3 sync') to systems outside Capital One's environment (the attacker's own storage, later shared via Slack/GitHub). Egress control on the compromised EC2 instance/production service would restrict outbound connections to an allow list, blocking the transfer of the exfiltrated data to any non-allow-listed destination. This does not stop the initial SSRF compromise or credential theft via the internal metadata service (169.254.169.254 is typically excluded from egress filtering as it's a link-local/internal address), but it directly blocks the attacker's ultimate objective of getting the 30GB of PII out of the network, matching the 0.7-0.9 band for blocking exfiltration after compromise.'

The RCE via CVE-2017-5638 on the dispute portal is an inbound exploit that egress control cannot stop, so the initial compromise still occurs. However, the report describes 'systematic extraction of PII from 145.5 million accounts over weeks' - a sustained bulk exfiltration that necessarily required outbound connections from compromised Equifax servers to attacker-controlled infrastructure. With a strict outbound allow-list, this exfiltration channel (and any C2 channel used to control the compromised dispute-portal host and pivot systems) would be blocked, denying the attacker's ultimate objective even though the foothold on the vulnerable server persists. This matches the invariant's stated benefit of stopping 'bulk data exfiltration to attacker-controlled servers.'

The attack chain culminated in prolonged, undetected data exfiltration of 21.5 million records over an extended period (reconnaissance from Nov 2013 through disclosure in June 2015), with the report explicitly noting 'inadequate real-time monitoring complicating detection and response' and Einstein's failure to catch the exfiltration. Egress control would not have stopped the initial credential-based access via USIS/KeyPoint contractors, but by blocking outbound connections to any non-allow-listed destination it would have prevented the sustained bulk exfiltration of SSNs, fingerprint data, and background investigation records to attacker infrastructure, as well as blocked any C2 channels used to maintain the backdoors described in May 2014. This directly denies the attacker's ultimate objective even though initial compromise still occurs.

The report states attackers established command-and-control mechanisms traced to international locations and exfiltrated data from over 90 compromised servers. Egress control restricting outbound connections to allow-listed destinations would have blocked the C2 channel used to coordinate the intrusion and would have blocked bulk exfiltration of the 76 million households' and 7 million businesses' contact data to attacker infrastructure. It does not stop the initial credential theft or lateral movement (steps prior to egress), so the compromise itself still occurs, but the attacker's ultimate objective—data exfiltration and sustained C2—would be denied, placing this in the 0.7-0.9 band per the described attack chain.'

The attack chain culminated in extraction of ~145 million user records from eBay's databases. The report does not detail the exfiltration channel, but bulk exfiltration of that scale would require outbound transfer to attacker-controlled infrastructure. Egress allow-listing would block such transfers from internal database/corporate hosts to non-allow-listed destinations, stopping the attacker's objective (data exfiltration) even though initial credential compromise and internal network traversal already occurred. It does not address the initial phishing/credential theft or lateral movement itself.

The initial compromise via unpatched ColdFusion vulnerabilities (an inbound web server exploit) would not be stopped by egress control. However, the attack's objective—exfiltrating the 153 million user records (users.tar.gz, 3.8GB compressed) and stolen Adobe source code—required outbound transfer of data to attacker-controlled infrastructure. With a strict egress allow-list, this bulk exfiltration channel would be blocked since attacker servers would not be on any legitimate allow list for Adobe's production/backup systems, denying the attacker's ultimate objective even though the network compromise and lateral movement still occurred.

The attack chain involved spear-phishing for initial access, backdoor installation for persistence, and data exfiltration of the user database. Egress control would not stop the spear-phishing compromise itself, but it would block the backdoor's command-and-control callbacks and, critically, the bulk exfiltration of the 3 billion user records to attacker-controlled infrastructure, since that infrastructure would not be on an allow-list. The report explicitly cites 'Data Exfiltration: Focused on Yahoo's user database, extracting sensitive data' and 'Persistent access was ensured via backdoor installations' as key steps this control directly targets, denying the attacker's ultimate objective even though initial compromise occurs.'

The report describes 'Data Exfiltration' as the final stage of the attack chain, noting that sensitive data was extracted 'without detection, possibly due to insufficient monitoring.' If attackers exfiltrated the 9,000,000 records to external servers or command-and-control infrastructure (as is typical for large-scale data breaches), an egress allow-list would have blocked the outbound transfer since attacker-controlled destinations would not be on the allow list. This would not stop the initial exploitation (phishing, SQL injection, or vulnerability exploitation), but it would deny the attacker's ultimate objective of exfiltrating the data, placing this in the 0.7-0.9 band. Confidence is medium because the report does not confirm the exact exfiltration mechanism, and if data was extracted via legitimate-looking database queries returned through an already-compromised web application (inbound-style abuse), egress control would not apply.'

The attack chain involved SQL injection for initial access, followed by installation of sniffer malware that captured payment card data over months and exfiltrated it undetected. Egress control would not stop the SQL injection itself (an inbound web application attack), but the sniffer malware necessarily had to communicate stolen card data to attacker-controlled infrastructure to be useful, and would need outbound C2/exfiltration channels. Since the report notes standard security solutions failed to detect this traffic and the malware operated for months capturing data, an egress allow-list would have blocked the malware's communication to any non-allow-listed destination, denying the attacker's ultimate objective of exfiltrating the 130 million card records even though the initial SQLi foothold might still occur.

The attack chain culminated in prolonged data exfiltration (~80GB over 18 months) via a sniffer capturing card data from the compromised WLAN. WEP exploitation itself would not be stopped by egress control, so the initial compromise still occurs, but the attacker's objective—getting the captured card/customer data out to attacker-controlled infrastructure—requires outbound connections that would be blocked if destinations weren't allow-listed. This denies the ultimate exfiltration even though initial wireless intrusion and internal data capture are unaffected.reasoning.'

The initial compromise (SSRF via CVE-2021-26855, inbound exploitation) is not blocked by egress control since it's an inbound attack against the Exchange server, not an outbound connection. However, the report states attackers used China Chopper web shells for persistence, conducted 'Data Exfiltration' via Exchange PowerShell to extract emails and sensitive data, and deployed additional payloads like ransomware (DearCry, Black Kingdom) and cryptomining malware (Lemon Duck) that would need to be fetched from attacker infrastructure or used to transmit stolen data outward. With strict egress allow-listing, the server could not reach attacker-controlled destinations to exfiltrate stolen emails/data or download second-stage tools, denying the attacker's ultimate objective even though the web shell foothold itself (driven by inbound HTTP requests) would remain.

The report confirms exfiltration occurred: Conduent's SEC filing states the actor 'exfiltrated files' associated with clients, and SafePay/other claims describe transfer of terabytes of data. The exact transfer mechanism and destination are not established (the LinkedIn claim of 'ordinary transfer mechanisms' is explicitly flagged as unverified), but any bulk transfer to attacker-controlled infrastructure, file-sharing sites, or non-approved cloud storage would be blocked under a correctly implemented allow-list egress control, since attacker infrastructure would not be on the allow list. This does not stop the initial October 21 access or file discovery/collection step, but it would deny the attacker's ultimate objective of moving stolen data out of the environment, which is the core harm described (PII/PHI exfiltration). Confidence is medium because the transfer channel is unconfirmed, and if exfiltration occurred through an already allow-listed channel (e.g., an approved cloud service or email), the control would not have helped, per the invariant's own counterexamples.

The attack chain culminated in exfiltration of 490,191 files (573GB) to Rhysida's infrastructure and eventual publication/auction on a leak site, plus reliance on native admin tools for lateral movement rather than external C2. Strict egress allow-listing would have blocked the bulk exfiltration of internal HR and other data to attacker-controlled servers, denying the double-extortion objective (data leak) even though it would not have stopped the initial VPN credential compromise, Zerologon privilege escalation, or local encryption/disruption of systems, which do not necessarily require novel outbound connections. This blocks one major attacker objective (data theft) while the ransomware deployment/outage impact could still occur.

The attack chain involved exploiting an LFI vulnerability to access files and potentially achieve RCE, followed by lateral movement and extraction of 412M accounts' worth of data across multiple databases. While the initial LFI exploitation itself (reading files via the web application) would not necessarily require an outbound connection and thus would not be blocked, the bulk exfiltration of hundreds of millions of records to attacker-controlled infrastructure would require an outbound channel not on any legitimate allow list. Egress control would block this final exfiltration step, denying the attacker's ultimate objective of getting the stolen data off the network, even though the initial compromise and internal data access via the vulnerable application would still occur. Report does not specify the exfiltration mechanism, adding some uncertainty.

Initial access was inbound (unauthenticated /api/v1/validate/code RCE), so egress control does not stop the compromise itself. It would, however, block the 30-minute crontab beacon to 45.131.66.106:4444, the ENCFORGE curl fetch to 34.153.223.102:9191, and any exfiltration attempt to 64.20.53.230, denying C2 and exfil channels. But the material destructive impact—AES_ENCRYPT of 1,342 Nacos config items, table drops, README_RANSOM creation, and the later ENCFORGE .locked file encryption delivered via internal procfs/Docker escape rather than external download—occurs through local execution and database operations that do not require outbound connections, so the core damage still occurs. This is partial containment: some channels (C2, exfil) are blocked but a material outcome (database destruction, ransomware encryption) still happens.

The attack chain's exfiltration of PII (names, SSNs, driver's license numbers) to attacker-controlled infrastructure would require an outbound connection not on any legitimate allow list, so egress control would block that channel. However, the attackers gained privileged access via Okta/Azure through stolen credentials and used that legitimate, authenticated administrative access to deploy ALPHV/BlackCat ransomware across 100+ ESXi hypervisors; this deployment does not necessarily depend on the compromised hosts making new outbound connections to attacker infrastructure, so the ransomware encryption and resulting operational disruption (slot machines, ATMs, key cards, payment systems across 29 properties) would likely still occur. This is a partial containment: exfiltration is blocked but the material ransomware impact still happens.

The report states the exact initial intrusion method is undefined, but the ultimate objective was exfiltration of 33GB / 360M records that was later sold via 'The Real Deal' marketplace. If the attacker used an outbound channel (e.g., dumping the database to an external server or C2 infrastructure) to move that bulk data off MySpace's network, an egress allow-list would have blocked the transfer since attacker infrastructure would not be on the allow list. However, the report does not confirm this was the exfiltration mechanism versus, for example, direct access to backup files or insider access, so the benefit is plausible but not certain, and partial containment is the appropriate band rather than full prevention or total irrelevance.

The attack chain centered on vishing employees and redirecting them to a fraudulent VPN login portal to harvest credentials and MFA details, then using those credentials to log into Twitter's internal admin tools to hijack accounts and post the Bitcoin scam. If the spoofed VPN domain was not on the employee endpoint's egress allow-list, the connection to submit credentials could have been blocked, disrupting the initial phishing step. However, the attackers' subsequent use of stolen credentials to authenticate into Twitter's VPN/admin tools is an inbound access using valid (stolen) creds, which egress control does not govern. The core damage—account takeover, tweet posting, and the Bitcoin scam—occurred through legitimate internal tool sessions rather than outbound C2 or bulk exfiltration to external attacker infrastructure, so egress control provides only partial disruption of one attack vector without stopping the material outcome.

The report describes unauthorized data access via a vulnerability in a third-party application without specifics on how data was extracted or whether it was exfiltrated to an external attacker-controlled destination. If the vulnerability allowed direct query/access to data through the application itself (e.g., API abuse or logic flaw returning data in responses), no outbound connection from a compromised host would be involved, which is explicitly a counterexample. Since no details on exfiltration method, malware, or C2 are given, egress control cannot be confidently credited with stopping the breach; at best it may have raised the bar if any bulk transfer to an external server was needed, but this is unconfirmed.The score reflects the possibility that egress control would have been circumvented by direct application-layer data access, which is unaddressed by this invariant.

The attack chain involved former employees using legitimate/retained credentials to access and exfiltrate ~100GB of data, which was ultimately leaked to Handelsblatt, a media outlet. The report states 'no suspicious IP addresses or malware signatures existed due to the insider nature of the breach' and that the exfiltration required 'no external tools or software.' This suggests the data was likely transferred via legitimate channels (e.g., personal email, physical media, or direct handoff to journalists) rather than to an unlisted attacker-controlled server or C2 infrastructure. Egress Control is designed to block connections to non-allow-listed destinations, but an insider with legitimate access can exfiltrate through allow-listed channels (e.g., corporate email, approved cloud storage) as explicitly noted in the invariant's counterexamples. Since the mechanism of exfiltration to a media outlet is not detailed as a blocked network destination, this invariant would only partially interact with the attack, providing minimal containment.

The report states the former employee used 'standard internal systems' to access and download reports, with no external malware or attacker infrastructure involved. The exfiltration event was the act of downloading data through the employee's own retained legitimate access, not a network transfer to an unlisted external destination. Egress allow-listing constrains where compromised hosts can send data, but here the harm occurs the moment the insider retrieves data they were previously authorized to reach; there is no indication the data needed to traverse an outbound connection to a non-allow-listed destination to constitute the breach. If the employee subsequently moved the downloaded data off internal systems to an external service, egress control could have added a partial barrier, but the report gives no evidence of this step, so the invariant only marginally interacts with the attack chain.

The report explicitly states LockerGoga was distributed 'without traditional C2 channels' via Pass-the-Hash and Active Directory propagation, and encryption used embedded RSA4096/AES-256 keys rather than remote key-fetching, so the ransomware's core deployment and encryption did not depend on outbound Internet connections. Egress control might block a secondary payload download during the initial spear-phishing stage, but the documented lateral movement (Mimikatz, Pass-the-Hash, AD-based propagation) and the encryption/impact phase occurred over internal network protocols, not egress traffic, so this invariant would not meaningfully change the outcome.

The report describes the extraction path as delegated third-party application authorization within the CRM/customer-servicing platform itself: the agent connected the CRM instance to an attacker-controlled data-extraction application, which then collected records directly from the SaaS platform. This is a cloud-to-cloud (or cloud-to-attacker-app) data flow rather than data leaving through a Qantas-controlled host's outbound network connection. Egress allow-listing on employee endpoints and production hosts would not intercept this platform-level, delegated-access exfiltration channel. The agent's initial navigation to a CRM-related website (per the vishing script) could theoretically be blocked if that domain were not allow-listed, but the report does not establish that this navigation itself was the exfiltration channel—the extraction occurred via the authorized application against the CRM platform, not via the agent's outbound browsing session. Given this, the control has only marginal, speculative interaction with the actual documented chain.

The attack chain here is credential-based: attackers obtained plaintext admin credentials exposed on a web interface/archive (members.zip on RecordsCheck.net) and used them to log into NPD's systems and pull data out through what appears to be a legitimate administrative access channel. This resembles the documented counterexample of inbound/API-style access where the attacker's client connects into the victim system to retrieve data, rather than an NPD host initiating an outbound connection to attacker infrastructure. Egress allow-listing governs outbound connections from internal hosts to external destinations; it does not block an external party authenticating in and reading/downloading data via the exposed credentials. No malware, C2 beaconing, or outbound bulk transfer to an unlisted attacker server is described in the report, so the control does not clearly interact with the exfiltration mechanism as documented. It could plausibly raise the bar if some automated exfil script pushed data outward, but this is not established, so score is low.

The attack chain was SQL injection (CVE-2023-34362) followed by web shell deployment (human2.aspx/LEMURLOOT) that operated by receiving attacker HTTP requests (with the X-siLock-Comment header) and returning stolen data directly in the HTTP response to the inbound connection. This mirrors the documented counterexample: 'data returned in the normal responses of a public web application' does not involve an outbound connection from the victim host, so an egress allow-list would not block it. Egress control does not stop the initial SQLi exploitation either, since that too is an inbound exploitation of the public-facing MOVEit service. It offers little to no protection against this specific exfiltration methodology.

The attack chain was entirely credential-based: the attacker phished login credentials from an HR employee via SMS, then used those valid credentials to access internal systems and the Azure database directly. The report notes no malware was deployed and the mechanism of lateral movement/data exfiltration is unconfirmed. Because access appears to have occurred via valid credential-based login (likely from attacker-controlled infrastructure reaching an already allow-listed cloud service such as Azure, or via VPN/SSO with stolen creds) rather than an Activision host making unauthorized outbound connections to attacker infrastructure, egress control would not have interposed on this path—this matches the invariant's own counterexample of data exfiltrated through an allow-listed channel or of attackers using stolen credentials to interact directly with legitimate services. It offers little protection against this specific credential-theft-and-direct-login attack chain.

The report states the compromise was confined to a third-party, cloud-based CRM (likely Salesforce), not to Allianz-owned hosts or endpoints; Allianz found no evidence of access to its own network or systems. Egress allow-listing governs outbound connections from Allianz's fleet, but the reconstructed attack chain (connected-app/Data Loader authorization and bulk export) occurred via legitimate, already-authorized API calls to the CRM vendor's own infrastructure, a destination that would almost certainly already be allow-listed as a business-critical SaaS service. The invariant does not interact with cloud-to-cloud exfiltration that never traverses Allianz's network boundary, and the subsequent Telegram leak occurred on attacker infrastructure outside Allianz's control entirely.

The reported collection and exfiltration path used the attacker's authenticated session against the PowerSource portal's legitimate 'export data manager' functionality, with the attacker's source IP (91.218.50.11) connecting inbound to PowerSource rather than the compromised environment initiating an outbound connection to attacker infrastructure. This matches the stated counterexample of data returned via normal responses of a portal to an authenticated (if illegitimate) session, which egress allow-listing on PowerSchool's hosts would not block. No malware, C2 beaconing, or outbound transfer from a compromised host to an unlisted destination is documented; the report only alleges a later transfer to a leased Ukrainian server by the attacker's own infrastructure, not PowerSchool's. The invariant does not interact meaningfully with this credential-abuse-via-portal chain.

The attack chain used a stolen BeyondTrust Remote Support SaaS API key to reset local application account passwords and then rode over BeyondTrust's own legitimate technician-to-endpoint remote-access channel to reach Treasury workstations and documents (per Wired/TechCrunch: the actor 'used the compromised API key to bypass system defenses and gain access to Treasury workstations'). This is functionally the counterexample case of 'an attacker using an allowed cloud service' — the Remote Support SaaS connection between Treasury endpoints and BeyondTrust's infrastructure would already be on any reasonable allow list since it is a production support tool in active use, so outbound traffic tied to the intrusion would not be blocked. The report describes no separate C2 channel to unlisted attacker infrastructure or a distinct bulk-exfiltration destination; collection occurred directly through the trusted remote-support session itself. The unauthenticated command-injection chain (CVE-2024-12356) also occurred inbound against BeyondTrust's own appliance, not as outbound traffic from a Treasury host, so egress control does not interact with that path either.

The report states the attacker used stolen credentials to log into U-Haul's reservation tracking system and directly extract customer data (names, DOB, driver's license numbers) - described as 'seamless extraction of sensitive data' via the compromised access itself, not a malware beacon or bulk transfer to an external C2/file-sharing server from a compromised internal host. This looks like an inbound authenticated access to a legitimate application returning data in normal responses, which the invariant's own counterexample excludes ('data returned in the normal responses of a public web application do not involve an outbound connection'). No IoCs, external C2, or malware are reported, so there is no clear outbound connection this control would have blocked. It offers little to no protection against this particular access pattern.

The attack was credential stuffing via normal login (authentication) endpoints, and data exfiltration occurred through the platform's own legitimate DNA Relatives data-sharing feature returned via normal API/web responses, not via an outbound connection from a compromised host to attacker infrastructure. Per the counterexample, API abuse and data returned in normal responses of a web application are not blocked by egress control. No malware download or C2 traffic is described in the report, so this invariant does not meaningfully interact with the attack chain beyond marginal detection value.'

The attack chain here is fundamentally different from malware-based C2/exfiltration: Storm-0558 authenticated directly to Microsoft's own cloud services (OWA, Outlook.com, Exchange Online) using forged tokens that were accepted as valid. This is analogous to the 'inbound attack' or 'API abuse' counterexample in the invariant description — the attacker interacts with a public-facing service using seemingly legitimate credentials/tokens rather than exfiltrating data outbound from a compromised internal host to an unlisted attacker server. Egress allow-listing on Microsoft's or victim organizations' hosts would not have blocked legitimate-looking authenticated API calls to Microsoft's own email infrastructure, and the report gives no indication that data was pulled through a compromised host reaching out to non-allow-listed attacker infrastructure. It might marginally help if the initial engineer device compromise involved outbound C2, but this is speculative given the report's admitted information gap on how the key was obtained.

The attack chain here was compromised customer support credentials being used to log into and browse the legitimate support ticketing platform (an allow-listed destination) to view/export ticket contents and user data, not a compromised host reaching out to attacker-controlled C2 or exfiltration infrastructure. Since access and data viewing/exfiltration occurred through the normal, already-allowed support system channel, egress allow-listing would not interfere with this credential-based abuse, matching the stated counterexample of exfiltration through an allow-listed channel.'

This was a credential stuffing attack against public login endpoints (mobile app/website), not a case of a compromised internal host establishing outbound C2 or exfiltrating via a separate channel. The attacker's 'data exfiltration' occurred through the normal, allow-listed response path of the authentication API itself (successful logins returning account data), which the report explicitly notes is not blocked by egress controls per the counterexamples ('data returned in the normal responses of a public web application'). Egress control does not govern inbound login attempts or data returned in legitimate API responses, so it would not have stopped credential testing or the resulting account takeovers and data viewing.'

The report states the employee forwarded sensitive records 'using a standard office email client' to a personal email account, exploiting trusted, authorized access with no lateral movement, malware, or external C2 involved. Corporate email traffic (including to common email providers) is a routine, business-required destination that would almost certainly be on any allow list for an office environment, since blocking all outbound email would break normal business function. This scenario is explicitly called out as a counterexample to this invariant: 'Data exfiltrated through an allow-listed channel, such as an employee sending sensitive data to a personal email account... is not prevented.' The invariant does not interact meaningfully with this specific exfiltration vector.

The initial compromise was inbound API abuse/data scraping against T-Mobile's systems ('Attackers exploited T-Mobile's API, enabling data scraping'), which the invariant explicitly does not address ('Inbound attacks are not prevented: API abuse, scraping...'). The subsequent SIM swap was executed via social engineering of customer service staff, not via an outbound connection from a compromised host, so egress control has no bearing on that step either. It does not interact meaningfully with the attack chain as described.

The report describes a misconfigured, publicly accessible database with no password protection or MFA; the attackers connected directly to the database (an inbound exposure) rather than compromising an internal host and exfiltrating outward. This is analogous to the stated counterexample that egress control does not stop inbound attacks or data returned in response to external requests, since no outbound connection from an NCB-controlled host is described in the attack chain. Egress control would not have blocked the initial unauthorized inbound connection, and the report gives no evidence that a compromised internal host later pushed data outbound through a channel that egress allow-listing would govern.'

The attackers used social-engineered employee credentials to log directly into Mailchimp's internal support tool and export audience data through that tool's normal interface. This is analogous to inbound API abuse or data returned via a legitimate application response rather than an outbound connection from a compromised host to attacker infrastructure. The report notes no malware or C2 traffic was involved ('the breach leaned on compromised credentials solely'), so there is no outbound connection for an egress allow-list to block. It would not have prevented credential theft, tool access, or the export of audience data via the legitimate interface.

The primary exfiltration method was copying ~570,000 files from a company laptop directly to two personal external (USB) storage devices, a local physical transfer that never traverses the network egress path this control monitors. Egress control only governs outbound network connections, so it would not have blocked this method. The report notes a possible secondary intent to use WeChat cloud backup, which egress control could in theory block if attempted, but the actual documented theft occurred via physical storage devices, not a network upload, so the control does not meaningfully interact with the attack as it happened.

The core exfiltration vector in this breach was inbound abuse of an unsecured, poorly authenticated API endpoint and grievance-redressal search facility, with attackers running automated scripts to scrape bulk data directly from the responses of a public-facing service. This is exactly the counterexample scenario the invariant lists: 'API abuse, scraping, or data returned in the normal responses of a public web application do not involve an outbound connection from the victim.' There was no reported malware C2 channel or outbound exfiltration from a compromised internal host to attacker infrastructure; the data was pulled out via legitimate-looking inbound queries, and later resold via WhatsApp by third parties, not exfiltrated from a UIDAI host. Egress allow-listing on UIDAI servers would not have blocked queries coming in from the internet requesting data through the exposed API.ults

NotPetya's initial access came from a trusted vendor update channel (MeDoc's own servers), which would be an allow-listed destination for any host running MeDoc, so the malicious update delivery is not blocked. Lateral movement occurred via internal SMB exploitation (EternalBlue/EternalRomance) and internal credential-harvesting tools (Mimikatz, WMI, PsExec), which is east-west traffic rather than outbound connections to unlisted external destinations. Critically, NotPetya acted as a wiper with no C2 channel and no bulk exfiltration of stolen data to external servers, so the control's primary strengths (blocking C2 and exfiltration) do not apply to this attack's actual impact, which was MBR/file destruction achieved entirely through internal propagation.'

The attack was inbound API abuse: attackers queried a public-facing API directly to retrieve customer data (names, addresses, DOBs, etc.) over roughly six weeks. This matches the explicit counterexample in the invariant description: 'Inbound attacks are not prevented: API abuse, scraping, or data returned in the normal responses of a public web application do not involve an outbound connection from the victim.' No internal host was compromised and made to reach attacker infrastructure outbound; the data left via the API's normal response channel to the requesting client, which egress controls on internal hosts would not block.

The breach was executed via inbound abuse of a public-facing API endpoint and its phone-number lookup functionality, using automated scripts to scrape data that was returned in normal API responses. The report states there was 'no known malware or ransomware deployment' and no C2 traffic; data was extracted directly through the API response channel, not exfiltrated via an outbound connection from a compromised host to attacker infrastructure. This matches the invariant's stated counterexample: inbound API abuse and scraping do not involve an outbound connection and are not prevented by egress control.'

The breach chain consisted of (1) publicly accessible AWS S3 buckets with no access controls, allowing any external party to read data directly, and (2) automated abuse of Facebook's contact importer API to enumerate phone numbers and retrieve associated account data. Both are inbound access patterns—unauthenticated reads from an exposed bucket and API responses returned to scraping requests—not outbound connections initiated by a compromised internal host. The report explicitly notes 'data accessibility... not secured by any authentication measures on AWS, allowing unrestricted access' and describes the contact importer exploit as 'automated enumeration' via legitimate API calls, matching the invariant's own counterexample that 'API abuse, scraping, or data returned in the normal responses of a public web application do not involve an outbound connection from the victim.' No internal host needed to reach attacker infrastructure for either vector, so egress allow-listing would not have blocked the exposure or the scraping.

The attack chain involved an external attacker using stolen AWS access keys (found in a GitHub repo) to directly call AWS/S3 APIs from their own infrastructure, not outbound connections initiated from a compromised Uber host or endpoint. Egress control governs what Uber's own hosts can reach outbound; it does not restrict an external party's direct API calls to AWS using valid stolen credentials. The report describes credential-based direct access to S3, not C2 traffic or exfiltration originating from a compromised internal host, so this control does not meaningfully interact with the attack chain as described.

The breach was caused by a publicly accessible, unauthenticated cloud database that anyone could directly query and read over the Internet. There was no compromised internal host making outbound connections to attacker infrastructure; the attacker (researcher) connected inbound directly to the exposed database and retrieved data via normal read access. Egress allow-listing constrains outbound connections from hosts in the environment, but this incident involved inbound API/database access to a misconfigured public-facing service, which the invariant's own counterexamples explicitly exclude ('Inbound attacks are not prevented... data returned in normal responses of a public web application'). The invariant does not interact with this attack chain at all.

The attack was entirely inbound: attackers made API calls to a publicly exposed DuoLingo endpoint and received data in normal API responses (cross-referencing email addresses). Per the explicit counterexample, egress control does not prevent 'API abuse, scraping, or data returned in the normal responses of a public web application' since there is no outbound connection from a victim host being blocked. The data flowed out via the API responses themselves to the attacker's own scraping client, not via a compromised internal host reaching out to an attacker server.'

The breach was not an outbound data exfiltration event; it was a caching/session-isolation bug in redis-py that caused users' personal and payment data to be displayed to other logged-in users via the subscription management page and confirmation emails within ChatGPT's own normal application responses. No attacker-controlled external destination, C2 channel, or bulk exfiltration occurred, so an egress allow-list has nothing to block—this matches the stated counterexample of 'data returned in the normal responses of a public web application.'

The attack was a credential stuffing campaign consisting of automated inbound login attempts against Norton LifeLock's customer authentication endpoint using credentials sourced from dark web dumps. There is no evidence of outbound connections from compromised Norton hosts to attacker infrastructure, malware downloads, or data exfiltration via a Norton-controlled host; the 'exfiltration' here is simply viewing account data through the normal authenticated web session, which is an inbound/API interaction, not an outbound connection this control would inspect. Egress control governs outbound traffic from Norton's own hosts/services and does not interact with mass login attempts arriving from the internet or with data returned in normal authenticated responses (explicitly called out as a counterexample in the invariant description).

The breach was caused by a publicly misconfigured S3 bucket accessed via inbound, unauthenticated internet access (standard internet searches/scans), not by an outbound connection from a compromised host. Egress Control only governs outbound connections from hosts in the environment; it does not restrict inbound access to a publicly exposed data store. The report explicitly notes 'absence of authentication controls allowed open access via standard internet searches and scans' - this is data being read directly from public infrastructure, not exfiltrated by a compromised host reaching out to attacker infrastructure. This invariant does not interact with the attack chain at all.

The exfiltration method was physically copying files to a USB drive, not a network-based transfer to an external server. Egress control only governs outbound network connections and would not intercept or block a local USB copy operation, so it does not interact with this attack chain at all.

The attack was inbound API abuse: the threat actor queried LinkedIn's publicly accessible API and data was returned in normal API responses, not exfiltrated via an outbound connection from a compromised host. The report explicitly states the scraping 'operated entirely through API misuse' with no malware or C2, and no internal LinkedIn system was compromised to originate an outbound transfer. This matches the invariant's own counterexample: 'API abuse, scraping, or data returned in the normal responses of a public web application do not involve an outbound connection from the victim.' Egress control does not interact with this attack chain.

The attack was inbound API/web scraping: the developer's tooling sent HTTP requests to Taobao's public-facing APIs and received data in the normal responses. No compromised host was making unauthorized outbound connections to attacker infrastructure; the data flowed back through legitimate response channels to the attacker's own client. This matches the invariant's explicit counterexample: 'API abuse, scraping, or data returned in the normal responses of a public web application do not involve an outbound connection from the victim.' The invariant does not interact with this attack chain at any step (initiation, extraction, or storage).

The breach involved an attacker (or anyone) sending inbound HTTP requests to a public-facing web application and receiving sensitive documents in normal HTTP responses due to an IDOR flaw. No outbound connection from a compromised host was required; the data was retrieved directly via requests.get() against firstam.com as documented in the attack chain. This matches the explicit counterexample: 'data returned in the normal responses of a public web application do not involve an outbound connection from the victim.' Egress allow-listing on First American's servers would not block legitimate-looking inbound web requests returning documents, so the invariant does not interact with this attack chain.

The exfiltration of private keys occurred from end-users' own devices running the compromised Copay wallet app (versions 5.0.2-5.1.0), sending data to the attacker's server at 111.90.151.134 / copayapi.host:8080. Egress allow-listing as described protects an organization's own fleet of production servers and employee endpoints, not the millions of independent consumer devices running a distributed cryptocurrency wallet application. BitPay's internal infrastructure was not the channel through which private keys and funds were stolen; the theft happened client-side on user hardware outside BitPay's controlled environment, so this invariant does not interact with the actual exfiltration step of this attack chain.

The breach resulted from a publicly accessible AWS S3 bucket (dra-dw) with no authentication or password protection; Chris Vickery simply connected inbound to the exposed bucket and retrieved data. There was no outbound connection initiated by a compromised host inside Deep Root Analytics' environment to an attacker-controlled destination—the data flowed out via a normal, allowed response to an external read request, analogous to the documented counterexample of 'data returned in the normal responses of a public web application' not involving an outbound connection from the victim. Egress allow-listing governs outbound traffic from hosts, not inbound requests to a misconfigured public storage endpoint, so it does not interact with this attack chain at any step.

The breach was an internal email sent via Microsoft Outlook to an unintended but presumably legitimate email recipient, not a connection to attacker-controlled infrastructure. The email was likely allow-listed or internal, and the exfiltration channel was standard email delivery, not a novel outbound connection to a malicious destination. Egress control governs network destinations for compromised hosts reaching attacker infrastructure; here there was no compromise or malicious external destination—just human error in addressing an email within normal, permitted communication channels.'

The attacker did not compromise an internal Uber host and then exfiltrate data outward; instead, they used a stolen AWS access key exposed on GitHub to directly authenticate to AWS's S3 API from an external location. This is analogous to the documented counterexample of inbound API abuse rather than outbound exfiltration from a compromised host, so an egress allow-list on Uber's fleet would never see this traffic pass through a controlled host—it's essentially external, credentialed access to a cloud API, not egress from a compromised endpoint or server.

The attack chain involved no malware, no compromised host reaching out to attacker infrastructure, and no unauthorized outbound connection. Ngo was onboarded as a purportedly legitimate business customer of Court Ventures/US Info Search and simply queried the database through the normal, sanctioned service interface (over 3.1 million queries via Superget.info), receiving data back through the legitimate, allow-listed business channel he was granted. This mirrors the explicit counterexample of 'data returned in the normal responses of a public web application' or API abuse by an authorized user—egress controls do not interact with this exfiltration path because the channel used was the very channel meant to be allowed for a paying business customer.

This breach involved physical loss of unencrypted magnetic tapes in transit between IBM/Iron Mountain facilities, not a network-based intrusion. There was no compromised host, no command-and-control traffic, and no digital exfiltration channel involved. Egress control governs outbound network connections and has no bearing on physical media being lost during shipping. The report explicitly states 'no electronic network breach tactics were involved.'