{"slug": "black-october-lessons-from-the-downstream-breaches", "title": "Black October: Lessons from the Downstream Breaches", "summary": "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.", "body_md": "# Black October: Lessons From the Downstream Breaches\n\nThis 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.\n\nI wanted to share retrospective thoughts about what would have prevented them!\n\nIf 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.\n\nSpoiler, they are:\n\n## What happened\n\nTL;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.\n\nThis 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).\n\nI mostly worked with the spokes: the companies downstream of these hubs that had trusted them with long lived credentials.\n\nThankfully, 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.\n\nEngineers across each victim shared the same question: *What do we focus on after this is contained?*\n\nHere is what I suggested!\n\n## 1. “Full stack” network lockdown\n\nThe 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.\n\nThe 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.\n\nConfiguring 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.\n\nIn 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.\n\nThe 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.)\n\n**How to do it?**\n\n1. Origins: Identify trusted networks, such as your VPN, internal VPCs, and offices.\n2. Network: Allow traffic from trusted origins and reject everything else at the security group / ACL level, except for obviously expected production traffic.\n3. 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.\n4. 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.\n\n## 2. Reduce and manage secrets\n\nSome of the leaked credentials during Black October caught their owners off guard.\n\n“What key is this?”\n\nThat 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.\n\nWith 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.\n\n**How to do it?**\n\n1. Inventory: Find your weakly stored API keys, database passwords, application secrets, certificates, etc. Use [TruffleHog](https://github.com/trufflesecurity/trufflehog) .\n2. Roles: Replace secrets with identity-based roles where possible.\n3. Storage: Rotate remaining secrets. Move them into a secrets manager, like HashiCorp Vault, AWS Secrets Manager, Doppler, etc.\n4. Reduce: Give each service separate, minimally privileged secrets retrieved at runtime.\n5. Network: Where supported, restrict credential use to trusted networks, as described in [network lockdown](#1-full-stack-network-lockdown) .\n\n## 3. Forensic-ready logging\n\nLogs on their own don’t prevent incidents but their existence substantially improves everyone’s mood in incident response.\n\nTo 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.\n\nGet 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.\n\nVictims 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.\n\nThe best approach is obviously to not have a breach at all, but after you do, share as much as possible. Logs make this happen.\n\n**How to do it?**\n\n1. Storage: Choose a central logging platform or vendor.\n2. Standards: Use consistent timestamps, identities, actions, resources, outcomes, and correlation IDs.\n3. Retention: Decide on log volume, retention, rotation, and archiving policies.\n4. Sources: Log identity, cloud, endpoint, network, application, database, and critical vendor activity.\n5. Integrity: Restrict log changes, preserve tamper-resistant copies, and monitor for forwarding or collection failures.\n6. Tabletop: Practice tracing a simulated incident across systems using the logs!\n\n# Conclusion\n\nThese 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.\n\nGood luck", "url": "https://wpnews.pro/news/black-october-lessons-from-the-downstream-breaches", "canonical_source": "https://scrty.io/black-october", "published_at": "2026-11-05 22:25:49+00:00", "updated_at": "2026-11-05 22:50:57.477477+00:00", "lang": "en", "topics": ["ai-safety", "ai-infrastructure"], "entities": ["GitHub", "AWS", "Google Cloud", "Wiz"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/black-october-lessons-from-the-downstream-breaches", "markdown": "https://wpnews.pro/news/black-october-lessons-from-the-downstream-breaches.md", "text": "https://wpnews.pro/news/black-october-lessons-from-the-downstream-breaches.txt", "jsonld": "https://wpnews.pro/news/black-october-lessons-from-the-downstream-breaches.jsonld"}}