# Black October: Lessons from the Downstream Breaches

> Source: <https://scrty.io/black-october>
> Published: 2026-11-05 22:25:49+00:00

# 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