Credential Exposure

Scoping sounds like the easy part of incident response, because you already know how to search a filesystem and you already know how to read an audit log, so the work appears to be a matter of running the search and writing down the result.

It isn't, and the reason is that scoping is not a search problem, it's an evidence problem, and the question you're actually answering is not "what can I find" but "what am I willing to assert," which means the boundary you draw is a claim about reality rather than a list of files.

That distinction matters because the people downstream of your scope are making decisions with it, which means legal is deciding on notification, finance is deciding on exposure, and engineering is deciding what to rebuild, and none of them can see the uncertainty that sits behind the number you gave them.

So here is how to scope credential exposure honestly, which means the four tiers of exposure, the evidence hierarchy that determines how much you can claim, how to handle the negative space, and how to write a scope that survives being read by someone who wants to disagree with it.

Important Disclaimer

This article is intended for educational and defensive purposes only, and it describes general incident response practices rather than guarantees or legal advice. Notification obligations differ by jurisdiction, sector, and contract, so involve legal counsel before making a determination on disclosure. 

Every command described is read-only and intended for systems you own or administer. Discovery output contains live secrets, so never paste it into a ticket, a chat, or a third-party tool. The author assumes no liability for regulatory outcomes, business outcomes, or damages resulting from the use or misuse of this information.

The Four Tiers of Exposure

The single most useful thing you can do for everyone downstream is stop using the word "compromised" as if it were one condition, because it collapses four genuinely different situations into a single term and then forces the reader to guess which one you meant.

• Reachable means the attacker's position permitted access to the credential, and there is no evidence either way about whether they took it. The .env file was readable by the user they ran as, the secret was in the vault the role could open, the key was in the bucket the token could list.
• Read means there is evidence the credential was accessed, which usually means a recorded file read, an API call that returned the value, a GetSecretValue entry in a provider log, or a filesystem access record, and it doesn't mean the credential was used to authenticate anywhere.
• Used means the credential authenticated successfully somewhere, which is the first tier where you can say the attacker had the value rather than merely having access to the value, and it's also the tier where the question shifts from "did they get it" to "what did they do with it."
• Exfiltrated means the value left your environment, which is the strongest claim and the hardest to evidence, and it's usually established by an outbound transfer you can observe, or by a read performed by a process that was itself sending traffic somewhere, or by the credential appearing somewhere it shouldn't, which is the least pleasant form of confirmation.

The reason to be pedantic about this is that each tier drives a different decision, and collapsing them produces either an over-claim you can't defend or an under-claim that leaves a live credential in the attacker's hands.

Why the Tiers Drive Different Decisions

• A reachable credential is a rotation candidate rather than a confirmed loss, so the sensible response is to rotate it if that's cheap and to document that you did so as a precaution rather than as a remedy, and it doesn't on its own trigger a notification obligation because there's no evidence anything was taken.
• A read credential is a confirmed loss, so rotation is mandatory and it should be treated as though the attacker holds the value, because they do, and the notification question moves from "whether" to "what was accessible through it," which is a different analysis.
• A used credential is a confirmed capability, so rotation is urgent and insufficient on its own, because you also need to establish what the attacker did while authenticated, which is a fresh scoping exercise one layer deeper, and this is where investigations expand rather than close.
• An exfiltrated credential is a permanent loss, so the decision is not about whether to rotate but about whether the exposure created a notification obligation based on what the credential could reach, and the honest position is that the value should be treated as public from the moment it left.

The Evidence Hierarchy

Not all evidence is equally trustworthy, and the difference matters enormously once a host is compromised, because the attacker had the ability to change what you're about to read.

Rank your sources before you start, and treat the ranking as fixed rather than negotiable, because the temptation to cite the most convenient source is strong and it is how scopes become indefensible.

• Provider-side control plane logs sit at the top, which means cloud audit logs, identity provider sign-in logs, SaaS admin logs, and secrets manager access logs, and the reason they rank highest is structural, which is that the attacker had to interact with your provider's API to reach those systems and the provider's record of that interaction is not on your machine.
• Network and flow telemetry sits second, which means DNS resolution logs, proxy logs, firewall and flow records, and TLS metadata, because those observe connections rather than their content and they're usually stored off-host in a system the attacker didn't reach.
• Endpoint and process telemetry sits third, which means EDR or Sysmon records, because they're rich and detailed but they're generated on the machine the attacker may have controlled, so their integrity depends on whether the agent was running, whether it was tampered with, and whether the records were forwarded off-host in real time.
• Application logs sit fourth, because they're the most likely to be edited, deleted, or rotated, and a webshell that knows to clear an access log is not an exotic technique.
• Filesystem timestamps sit fifth, because access times are frequently disabled at mount time, are not updated by every read depending on the kernel and options, and are trivially changed by anyone with write access, which makes them supporting context rather than evidence.
• The attacker's own claims sit at the bottom, which means a ransom note, a leak site post, or a message in a chat, and the reason to include them at all is that ignoring them is worse than weighting them low, but a claim is not an observation and shouldn't be recorded as one.

The Tampering Problem, and What It Forces

The moment you conclude that a host was compromised, everything generated on that host becomes unreliable, and that conclusion propagates through your scope in a way that surprises people.

It means the application log showing no access to the secrets endpoint is not evidence of no access, because the log is on the box. It means the filesystem access time showing nothing recent is not evidence of no read, because the attacker could have changed it or the mount never tracked it. It means the EDR agent's silence is not evidence of nothing happening, because the agent could have been disabled or the process could have been excluded.

What survives is the provider's record, the network's record, and anything forwarded off-host before the compromise, which is why the first practical scoping question is not "what happened" but "which of my sources were outside the attacker's reach," because only those can support a claim.

If the incident is application-only and the host is not compromised, this problem mostly disappears, and host logs can be used at full weight, which is one more reason the app-versus-host distinction from earlier analysis matters so much to everything downstream.

Timeline: Duration Multiplies Everything

A credential that was readable for nine hours is a different finding from one that was readable for nine months, and the scoping document needs both ends of that window rather than a single date.

The start of the window is the earliest credible evidence of access, which is usually the first entry in a provider log that you can't explain, and it is almost always earlier than the detection date, because detection lags access and the lag is frequently measured in weeks.

The end of the window is containment, which means the moment the credential became unusable rather than the moment you decided to rotate it, because a key marked for rotation at 10:00 and actually revoked at 16:00 was live for those six hours and the scope should say so.

The multiplier effect is the part leadership understands immediately, because a credential exposed for a week is not just a longer list of possibilities, it's a longer list of things the attacker could have done with it, which expands the investigation one layer down.

The Negative Space, Which Is the Hardest Part

Most scoping effort goes into establishing what was touched, and the harder and more important work is establishing what wasn't, because a scope that can't describe its negative space is a list of findings rather than a boundary.

The honest formulation is almost never "this credential was not used," and it's usually "there is no evidence of use within the retained window," which is a weaker and more accurate claim, and the difference between those two sentences is the difference between a defensible statement and an overreach.

That phrasing forces you to state your retention limits explicitly, which means how far back each log source actually goes, whether there are gaps, and whether the gap period overlaps the incident window, because a thirty-day retention policy on a ninety-day intrusion means the earliest evidence is already gone and the scope must say so.

The second thing that strengthens a negative claim is structural impossibility, which is more powerful than absence of evidence, so if you can show that the credential's permissions could not reach the affected system, or that no network path existed between the compromised host and the vault, or that the encryption key required was held somewhere the attacker never reached, then you have a ruled-out finding rather than an unobserved one.

Grading Confidence, So the Reader Knows What They're Reading

Each credential in the scope should carry a confidence grade, and the grades should be defined in the document rather than left to intuition.

The grade is what makes the scope usable, because a reader who sees "confirmed" and "possible" in the same list will treat them the same way unless you've told them not to, and treating a possible exposure as a confirmed one leads to mass rotation and unnecessary notification, while treating a confirmed one as possible leads to recurrence.

The Cost Asymmetry, Stated Honestly

There is a real asymmetry between over-scoping and under-scoping, and pretending otherwise is what makes scoping arguments go in circles.

Over-scoping costs operational disruption, because mass rotation breaks integrations, invalidates sessions, and produces outages that are themselves incidents, and it also costs credibility, because a team that declares everything compromised every time stops being believed when it matters.

Under-scoping costs recurrence, because a credential you didn't rotate is a credential the attacker still has, and it costs regulatory and contractual standing, because a scope that excluded a system the attacker actually reached is the finding that turns an incident into a compliance problem.

The useful way to resolve the tension is to let privilege and reach set the default rather than letting the tier do it alone, which means a "possible" exposure of a credential that can read production secrets gets rotated anyway, because the cost of rotation is low and the cost of being wrong is high, while a "possible" exposure of a read-only token for a decommissioned service gets documented and monitored rather than triggering an outage.

A Decision Matrix You Can Defend

The matrix isn't a substitute for judgement, and it's valuable because it forces the judgement to be recorded, which is what an auditor, an insurer, or a regulator will actually ask for.

What the Deliverable Looks Like

The output of scoping is not a spreadsheet of findings, it's a scope statement, and it has a predictable shape.

It states the incident window with both ends and the basis for each, it states the positions the attacker occupied, meaning which hosts, which identities, and which tokens, and it states the evidence sources used with their retention limits and any gaps, and that last part is what distinguishes a professional scope from a confident guess.

It then lists the credentials with tier and confidence and owner, and it records the ruled-out set with the basis for exclusion, because the exclusions are as important as the inclusions when someone later asks why a system wasn't in scope.

And it ends with a decision log, which means who decided what, on what evidence, and when, because the scope will be revisited and the reasoning is the part that doesn't survive memory.

Two Scenarios

Scenario 1: The Scope That Answered the Wrong Question

The Setup

An application is compromised through an authorisation flaw, the team reviews the application logs, identifies the endpoint that was abused, and scopes the exposure to the database credentials in that application's configuration file.

What Happened

The flaw allowed file reads as well as data access, and the file read reached the deployment directory, which contained an environment file with a cloud key and a build artifact with an embedded token, and neither appeared in the application log because the log recorded business events rather than file reads.

The Result

The scope is published, the rotation completes for the database credential, and eleven days later the cloud key is used from an address outside the estate, and the second scope finds the two credentials that were always reachable and never enumerated, which damages confidence in the first scope far more than the original incident did.

The Lesson

The scope answered "what was used" and presented it as "what was exposed," and the two questions differ by everything the attacker could read without leaving a business-event log entry.

Scenario 2: The Scope With Its Limits Written Down

The Setup

Another organisation runs the same investigation but grades every finding, states which sources were inside the attacker's reach, records that one log source only retained fourteen days against a twenty-three-day window, and lists four credentials as ruled out because their permissions could not reach the compromised host.

What Happened

The rotation proceeds against the confirmed and probable set, the two possible exposures with high privilege are rotated as a precaution and documented as such, and the ruled-out four are recorded with the permission evidence that excluded them.

The Result

Legal reviews the statement and can see exactly which claims are strong and which are bounded by retention, the notification decision rests on the confirmed set rather than on the whole list, and when a reviewer challenges the exclusion of a system six weeks later the basis is in the document rather than in someone's recollection.

The Lesson

The value wasn't in the size of the list, it was in the document being honest about what each entry meant, which is what made every downstream decision faster rather than more conservative.

How to Spot a Scope You Shouldn't Sign Off On

• It uses "compromised" without defining it. Four different conditions are being collapsed into one word.
• It contains only credentials that appear in logs. That's the used set presented as the exposure set.
• It has no confidence grades. Every entry reads as equally certain, which means none of them are.
• It doesn't state retention limits. Absence of evidence is being presented as evidence of absence.
• It has no ruled-out section. Nothing was excluded on principle, which means nothing was actually analysed.
• It was written after the rotation. The boundary was reverse-engineered from the remediation, which is confirmation bias with a deadline.
• One person decided it and nobody recorded why. The reasoning is the part that disappears first.
• It expands to include everything. A scope that excludes nothing isn't a boundary, it's an abdication.

Quick Reference: Tier, Evidence, and What You Can Claim

The Bottom Line

Scoping credential exposure is the discipline of deciding what you're willing to assert, and the four tiers plus a confidence grade are what turn a list of files into a statement that someone else can act on, because reachable, read, used, and exfiltrated are four different findings that drive four different decisions.

The practical method is to rank your evidence sources before you start, discount everything generated on a compromised host, state your retention limits instead of hiding them, prove exclusions with structural evidence rather than absence, and record the decision and its reasoning so the scope can survive being challenged.

So write the tier and the confidence next to every entry, and write the limits of your evidence in the same document, because the sentence that protects you six months from now isn't the list of what you found, it's the paragraph explaining what you could and couldn't see.

FAQ

What does scoping credential exposure actually mean?

It means drawing a defensible boundary around what an attacker could have obtained, graded by how strongly you can evidence each item, which is a different exercise from listing what you found and a different exercise again from listing what was used.

What is the difference between a reachable and a used credential?

A reachable credential was accessible from the attacker's position with no evidence either way, while a used credential authenticated successfully somewhere, which means the attacker demonstrably held the value rather than merely having the ability to read it.

How do I prove a credential was not accessed?

You usually can't prove it absolutely, so the honest claim is that there's no evidence of access within the retained window, supported by stating your retention limits and any gaps, and strengthened considerably where you can show access was structurally impossible because permissions or network paths didn't allow it.

Which logs can I still trust after a host compromise?

Provider-side control plane logs, identity provider logs, and network telemetry, because those are generated and stored outside the compromised machine, while anything written on the host itself becomes unreliable the moment you conclude the host was controlled.

How do I decide whether to rotate a credential that was only reachable?

Let privilege and reach set the default, which means rotating a possibly-exposed credential that can read production secrets because rotation is cheap relative to being wrong, and documenting rather than rotating a possibly-exposed read-only token for a system that no longer exists.

When does a credential exposure trigger a notification obligation?

That's a legal and regulatory determination rather than a technical one, and it depends on what the credential could reach and what data sat behind it, which is why the scope has to distinguish confirmed exposure from possible exposure so counsel can reason about it.

How long should I keep investigating before publishing a scope?

Long enough to rank your evidence sources, enumerate the reachable set, and test the exclusions, and it's better to publish a graded scope with stated limits early than a definitive one late, because downstream decisions are waiting on the boundary rather than on completeness.

Who should sign off on the final scope?

The incident lead owns the technical content and legal owns the exposure determination, and the important thing is that the document records who decided what and on which evidence, because a scope without a decision log can't be defended when it's challenged later.