What does incident response look like for stolen credentials and vendor silence?

By Ramin Moradi · Published 2 November 2026 · Sources checked 1 November 2026

Incident access shows up as a stolen token in Slack, a vendor that stops answering while your only archive sits behind their login, or hours before anyone notices an attacker. Classify what was exposed, cut only that access, prove you own an export path, and shrink detection time.

This post merges three thin news notes we published in August into one runbook-shaped guide. It sits under black-box security audit and penetration testing. Pricing context lives in penetration testing cost; method context lives in penetration testing vs vulnerability scanning.

What happens when a GitHub PAT lands in Slack?

Someone pastes a classic personal access token into a channel "just for a minute." Screenshots, search, and bot logs keep a copy. Treat the paste as a live credential until you prove revoke and no post-revoke use in the org audit log.

That failure mode is boring and common. The token is long-lived, often org-scoped, and easy to copy. Chat is not a secrets vault. If your first move is "rotate everything," you will spend the night re-wiring deploy keys and Actions secrets that were never in the paste.

I lead engineering and security work at OVERLORD Team LTD (DevSecOps, CI/CD, cloud hardening). The inventories that survive a leak are the ones that already separate token classes before anyone opens Slack: classic PAT, fine-grained PAT, OAuth grant, user SSH key, deploy key, and short-lived GITHUB_TOKEN in Actions. If those names are not on a page your on-call can open in ten minutes, the revoke step will be guesswork.

How do you revoke a stolen token without killing deploy keys?

Revoke the credential class that leaked for the identity that owned it, leave working deploy keys alone unless they were also exposed, then watch the org audit log for use after revoke and rotate only the pipeline that needed that secret.

On 18 August 2026, GitHub's changelog for credential revocation and deauthorization by token type documented finer kill switches for incident response. Enterprise owners, organization admins, and people with the Manage enterprise credentials permission can revoke or deauthorize a single credential type (for example classic PATs, fine-grained PATs, SSH keys, or OAuth app tokens) across an enterprise or for one user, instead of wiping every credential that user holds.

That is the operational difference between containing a paste and taking Friday's publish offline. A deploy key on a mirror repo is a different object from a classic PAT that showed up in Slack. An OAuth app a contractor approved years ago is a third object. Blanket "rotate all secrets" feels decisive. It also breaks workflows that never touched the stolen secret.

A practical sequence:

1. Name the secret class (PAT classic, fine-grained PAT, OAuth, SSH, deploy key, Actions secret).
2. Revoke that class for that identity using the type-scoped controls GitHub now documents.
3. Search the org audit log for authentication or API use after the revoke timestamp.
4. Re-issue only what the affected pipeline still needs, preferably a fine-grained token with an expiry, or prefer Actions' built-in GITHUB_TOKEN where it fits.
5. Confirm deploy keys and unrelated OAuth grants still match their owners on the inventory page.

If step 1 takes longer than about ten minutes, the rest of the night is theatre. The control you cannot name is the control you cannot kill.

When does vendor silence count as an incident?

When a vendor that holds your only production copy stops answering, treat it as an availability and custody incident even if there is no ransomware note. Silence that blocks restore is an outage class, not a support inconvenience.

Current reported in August 2026 that St. Louis affiliate Nine PBS sued to recover approximately 50TB of archival material after its cloud storage provider went quiet and access was lost. Court coverage in that piece describes the archive stuck behind a defunct vendor relationship with a data-centre host. No encryptor. No ransom portal. The archive was still unavailable.

That pattern shows up in smaller shops without the PBS headline. Object storage billed as cheap. One login. Keys "held by the vendor for convenience." The last restore test is a sentence in a Slack thread from last year. When the ticket stays on Waiting on vendor, you discover you rented a room whose landlord can lose the key.

Call it what it is in the incident channel: vendor silence / custody loss. Assign a severity the same way you would for a failed restore during ransomware, because the business effect (cannot retrieve the archive) matches. Legal and procurement join early. Engineering's job is the leave path you already proved, not a hope that support replies before the invoice cycle ends.

Who should own the archive export if a vendor goes quiet?

You should. The customer of record needs encryption keys you control, a second destination you have restored from this quarter, a named human who can still pay or escalate if the champion quits, and an export format written down (not "we can get a zip").

Write those four into the build or the maintenance scope before the vendor is interesting. A periodic job that proves rclone (or the vendor's own export tool) still works after an API change is more useful than a contractual sentence about "reasonable assistance." Git LFS and GitHub Releases are not a media archive, but the same rule applies: if the only copy lives behind one login you do not administer, you do not have a copy.

When silence starts, the runbook questions are blunt:

• Which account and region hold the objects?
• Who has the customer-managed keys?
• When was the last successful restore into an account we control?
• What format comes out, and how long did that restore take on the last drill?

If any answer is missing, the incident is already worse than the support ticket. Cheap object storage without an export drill is not a disaster plan.

Why does eight hours of dwell time matter more than the headcount?

Because the headcount describes legal exposure after the fact, while dwell time describes how long an attacker could export, persist, or move before anyone interrupted them. Detection that starts at the lawyer letter is too late for operators.

The Record reported on 19 August 2026 that healthcare software firm CareCloud filed with the U.S. Department of Health and Human Services confirming 3,756,469 people had information leaked after a hacker spent eight hours in one of the company's electronic health record environments. The same piece says breach notices described unauthorized access to one AWS environment from 10 March to 16 March 2026, with data exfiltration claimed from databases in that environment. CareCloud's earlier SEC Form 8-K for the March event also described a temporary network disruption that partially impacted one of six EHR environments for approximately eight hours until functionality was restored that evening.

Use the public numbers carefully. The 3,756,469 figure is the HHS-reported affected count as covered by The Record. The eight-hour figure appears in that reporting as time spent in the EHR environment, and in the SEC disclosure as the approximate disruption window before restore. Either reading is enough for the operator lesson: a full workday without a useful alert is the failure mode, not the press release's soft "unauthorized access" phrasing.

What fits in eight hours inside a medical SaaS tenant is concrete. Bulk export. Persistence. Soft tenant boundaries. The useful sentence in the post-incident review is "we did not see them for a workday," not only the headcount counsel needs from the HHS figure The Record reported.

Signals worth wiring before you need them:

• New admin or break-glass sessions outside change windows
• Bulk export or large database read jobs from unusual identities
• Identity-provider anomalies (impossible travel, sudden MFA fatigue patterns you already treat as real)
• Egress from an environment to networks you do not bill in

Patching and segmentation help. None of them substitute for noticing the session while it is still a session. If the first "detection" is a regulator letter, the product you sold yourselves was hope.

What belongs in an incident-access runbook this week?

A one-page inventory of credential classes and owners, a type-scoped revoke path you have rehearsed, a tested export into an account you control, and a short list of dwell-time alerts with a human who will call before hour two.

Skip the generic marketing blocks. If a section does not name a control, an owner, or a verification step, cut it. A workable minimum:

Credentials

• Table of PAT / OAuth / SSH / deploy key / Actions secret owners
• Link to GitHub's type-scoped revoke UI or API you will actually use
• Audit-log query saved for "use after revoke"
• Rule: chat is not a secret channel; paste equals rotate that class

Vendor custody

• Primary store, secondary restore target, last successful restore date
• Customer-managed key location
• Named commercial owner for the vendor relationship
• Severity label for vendor silence equal to failed restore

Detection

• Admin-session, bulk-export, and IdP anomaly alerts on the tenant boundary
• On-call expectation measured in hours, not business days
• Written note that vendor status pages are not your detect story

You do not need a binder. You need those three lists where the people who get paged can find them.

FAQ

Is rotating every secret the safest first move?

Only if you already know every secret was exposed. Otherwise you extend downtime for systems that never held the stolen credential. Classify first, revoke the leaked class, then rotate what that identity still needs.

Does a tested export replace backups?

No. Backups answer "can we restore a point in time." A tested export answers "can we leave this vendor with our data in a format we can read." You usually need both. The PBS-scale story is what happens when the leave path was never drilled.

Is vendor silence the same as ransomware?

Not legally and not technically. Operationally it can produce the same outage: the archive is unreachable. Severity should follow business impact, not whether a ransom note arrived.

What number should security leaders take from the CareCloud reporting?

Keep both public figures straight. About 3.76 million people in the HHS count in The Record's CareCloud report, and about eight hours called out there (and as an approximately eight-hour disruption in CareCloud's March SEC Form 8-K). Build alerts and on-call expectations against the hours, and let counsel own the headcount process.

What to do next

Open your GitHub org inventory and confirm you can revoke one credential type without touching deploy keys. Schedule a restore into a second account you control this quarter. Put a human on admin-session and bulk-export alerts with a same-day call expectation. If you want an outside black-box look at the public surface that sits next to that runbook, book a free 30-min assessment.