Black October: Lessons from the Downstream Breaches

A security consultant who handled incident response for multiple victims of the October 2026 "Black October" breaches of developer and infrastructure platforms estimates that 90% or more of the initially leaked credentials belonged to applications that could have been restricted with a network-based allow list. The breaches followed a "hub and spoke" pattern in which compromised secrets control planes at the hubs exposed long-lived credentials — GitHub personal access tokens, long-lived AWS keys and AI platform keys — across many downstream customer environments. The consultant's recommended fix is a "full stack" network lockdown applying trusted-origin allow lists across networks, IAM and authentication portals, and credentials, which the consultant says could have prevented all of the incidents worked in October.

Black October: Lessons From the Downstream Breaches This last October 2026 I helped many victims during the serial platform breaches https://www.wiz.io/blog/black-october-for-ai-developer-platforms targeting dev and infra platforms. I normally don’t have this volume of IR work, so it was out of the ordinary for me. I wanted to share retrospective thoughts about what would have prevented them If you have leadership curious about “what can we do about Black October https://www.wsj.com/pro/cybersecurity/cyber-responders-strained-by-black-october-e259ea25 ” and willing to make a substantive change, these may be useful directions. Spoiler, they are: What happened TL;DR: a stretch of companies that support development or infrastructure were breached in a short period of time. Their secrets control planes and / or customer environments were compromised. This resulted in a “hub and spoke” pattern, where the hubs getting breached means an attacker suddenly has access to many spokes victim customers of the hub . Lots of credentials were breached quickly GH personal access tokens, long lived AWS keys, AI platform keys, and more . I mostly worked with the spokes: the companies downstream of these hubs that had trusted them with long lived credentials. Thankfully, each company was motivated toward an overall increase in resourcing security. But, they also wanted to discuss substantive and immediate projects relevant to their incident. Engineers across each victim shared the same question: What do we focus on after this is contained? Here is what I suggested 1. “Full stack” network lockdown The majority of these incidents began with credential leaks from the impacted neoclouds. I’d estimate that 90% probably more of the initially leaked credentials across the incidents I observed belonged to apps that could have restricted them with a network-based allow list https://docs.github.com/en/enterprise-cloud@latest/organizations/keeping-your-organization-secure/managing-security-settings-for-your-organization/managing-allowed-ip-addresses-for-your-organization , limiting remote use by an attacker. The majority of these leaked credentials then led to repeated pivoting to other credentials, mainly through github tokens that provided access to internal repositories holding more secrets. Most of those credentials also supported allow lists. Configuring networks, policies, and credentials to be aware of network usage may have prevented all of the incidents I worked in October. At the very least, the attackers would have needed more access than leaked credentials. In all but one of my personal observations the exposed credentials were exploited from remote, unfamiliar networks. An attacker would have had useless credentials in nearly all of the cases I observed unless they had also found a way to issue requests from a familiar network. The reason I use the loaded Full Stack term here is because there is no single bottleneck to enforce a network policy, and to be thorough, you should apply the same spirit of segmentation beyond just credentials. Networks, applications, authentication portals, etc. How to do it? 1. Origins: Identify trusted networks, such as your VPN, internal VPCs, and offices. 2. Network: Allow traffic from trusted origins and reject everything else at the security group / ACL level, except for obviously expected production traffic. 3. IAM / Auth: Make sure role assumption, identity or auth platforms SSO, SSH , or SSO managed apps respect the same network policy, and be careful not to lock yourselves out while implementing. 4. Credentials: Restrict AWS https://docs.aws.amazon.com/IAM/latest/UserGuide/reference policies examples aws deny-ip.html , Google Cloud https://docs.cloud.google.com/vpc-service-controls/docs/access-level-design , GitHub https://docs.github.com/en/enterprise-cloud@latest/organizations/keeping-your-organization-secure/managing-security-settings-for-your-organization/managing-allowed-ip-addresses-for-your-organization , Okta https://developer.okta.com/docs/guides/create-an-api-token/main/ , Microsoft https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-assignment-network , Salesforce https://help.salesforce.com/s/articleView?id=sf.login ip ranges.htm&language=en US&type=5 , and Slack https://slack.com/help/articles/55052468755347-Manage-access-to-Slack-with-IP-allowlists APIs to your trusted origins. 2. Reduce and manage secrets Some of the leaked credentials during Black October caught their owners off guard. “What key is this?” That made rotation difficult. You can’t just blindly rotate keys. Often, the keys did not need to exist at all, and could have been replaced with role-based credentials or Workload Identity Federation https://developer.hashicorp.com/hcp/docs/hcp/iam/service-principal/workload-identity-federation . These can provide short-lived credentials without manually rotating long lived keys, and would also benefit from network restrictions. With an infrastructure philosophy of “no unmanaged secrets”, you can treat any secret that can be found in plaintext as a problem. When retrieval of secrets is a managed process, you can more easily determine where they’re used. How to do it? 1. Inventory: Find your weakly stored API keys, database passwords, application secrets, certificates, etc. Use TruffleHog https://github.com/trufflesecurity/trufflehog . 2. Roles: Replace secrets with identity-based roles where possible. 3. Storage: Rotate remaining secrets. Move them into a secrets manager, like HashiCorp Vault, AWS Secrets Manager, Doppler, etc. 4. Reduce: Give each service separate, minimally privileged secrets retrieved at runtime. 5. Network: Where supported, restrict credential use to trusted networks, as described in network lockdown 1-full-stack-network-lockdown . 3. Forensic-ready logging Logs on their own don’t prevent incidents but their existence substantially improves everyone’s mood in incident response. To me, log readiness is a strong predictor of how long a response effort takes. Some of the Black October incidents I worked on were disclosed in days, and some were in weeks. With great confidence I can say that the variance was because of accessible logging. Get security relevant logs available and usable in a single place. A responder should be able to quickly pivot on forensic indicators and build a clear timeline of who did what, when, and where. Victims had to make disclosure calls to their customers. They ranged from positive to downright ugly. Explanations supported by evidence, along with sharing indicators of compromise IOCs and tactics, techniques, and procedures TTPs , go a long way in keeping customers happy. You can actually have happy customers after a breach. If you ask me, it depends on how much you’re able to share. The best approach is obviously to not have a breach at all, but after you do, share as much as possible. Logs make this happen. How to do it? 1. Storage: Choose a central logging platform or vendor. 2. Standards: Use consistent timestamps, identities, actions, resources, outcomes, and correlation IDs. 3. Retention: Decide on log volume, retention, rotation, and archiving policies. 4. Sources: Log identity, cloud, endpoint, network, application, database, and critical vendor activity. 5. Integrity: Restrict log changes, preserve tamper-resistant copies, and monitor for forwarding or collection failures. 6. Tabletop: Practice tracing a simulated incident across systems using the logs Conclusion These are all high lift projects, but very applicable to what I observed last month. If you’re looking at more holistic approaches to security, my other writing on scrty.io https://www.scrty.io might be useful. Good luck