Defense by accumulation
Sixty-four years of credential security, and why the first hour of every incident is still the same question
In the spring of 1966, Allan Scherr was a Ph.D. student at MIT who wanted more time on the Compatible Time-Sharing System than his weekly four-hour allocation permitted. CTSS, built by Fernando Corbató's group, was among the first systems to require per-user authentication. Late one Friday night, Scherr submitted a punched card requesting that the system print the password file offline. He returned Saturday morning, retrieved the printout, and handed copies to friends. J.C.R. Licklider used the credentials to log in as Robert Fano, the lab director, and leave taunting messages. Scherr confessed twenty-five years later. Fano told him his doctorate was safe.
It is one of the first credential thefts in the recorded history of computing. The shape of it has not changed. The credential is a file. The file is somewhere accessible. The trust placed in the file is administrative, not architectural. The theft is detected when the attacker chooses to be detected, or, more often, not at all.
This is a history of credentials at rest: the files, environment variables, key stores, sockets, and persistent artifacts that hold trust material between authentication events. Credentials in memory during an active session are a parallel story, mostly told by EDR vendors and forensics teams. The two histories overlap at specific moments (Mimikatz is one of them) but they have different shapes and different responses. This piece is about the first one.
Sixty-four years after Scherr, an alert fires on a developer laptop. The on-call engineer pages the IR lead. The lead opens the EDR console, confirms the host, and starts the questions that always come next. What credentials does this machine have access to. What does each credential reach. Where else in the environment does that pattern exist. The first hour is not a forensics exercise. It is a credential exercise. The artifact has changed at every layer in the intervening decades. The question has not.
This is a short history of how the question got so hard to answer.
I. They're all files
In 1979, Robert Morris and Ken Thompson published Password Security: A Case History in Communications of the ACM. The paper describes the redesign of the Unix password mechanism: hash with a modified DES function, prepend a 12-bit salt, store the result in /etc/passwd. It includes a survey of 3,289 passwords on the Bell Labs system. Eighty-six percent were trivially weak: short, all-lowercase, or drawn from a dictionary. The paper's conclusion, in 1979, was that user behavior is the binding constraint on password security. That conclusion has not aged.
/etc/passwd remained world-readable through the 1980s. The hash was considered uncrackable in practice; various Unix utilities depended on resolving UIDs to usernames. This was the design hole the Morris Worm walked through on the night of November 2, 1988.
The worm, released from MIT by Robert Tappan Morris, son of the Password Security co-author, pulled the hashed password file from each infected machine, ran a built-in dictionary of about 432 words through crypt(), and used cracked credentials together with .rhosts trust relationships to hop laterally. It crippled roughly 6,000 of the 60,000 machines on the early internet within twenty-four hours. The technical response was /etc/shadow, which moved the hashes to a root-only file. The cultural response was CERT and the incident-response industry that followed.
A father wrote a paper warning that user behavior was the binding constraint. Nine years later, his son's worm exploited exactly that fact, against exactly that file, on a network the elder Morris had helped design.
II. In memory
Kerberos was developed at MIT's Project Athena beginning in 1986. Steve Miller, Clifford Neuman, Jeff Schiller, and Jerry Saltzer designed it on the premise that passwords should not traverse the network. A user authenticates once to a Key Distribution Center, receives a time-bounded Ticket Granting Ticket, and uses derived service tickets to access individual resources. By January 1987 it was the sole authentication mechanism for Athena's 5,000 users, 650 workstations, and 65 servers. Microsoft adopted Kerberos as the default protocol for Windows 2000. An absolute majority of enterprise authentication events in the world today still run on a protocol designed for an MIT research network in the late 1980s.
Active Directory inherited Kerberos and added the architectural choice that defined the next two decades: the domain controller would hold the credential material, including password hashes, ticket-signing keys, and a special account called krbtgt whose hash signs every Kerberos ticket in the domain. The DC became the trust anchor of the enterprise.
In 2007, Benjamin Delpy, writing under the handle gentilkiwi, built Mimikatz. The first public release in 2011 demonstrated, with a single binary, that Windows kept plaintext passwords and credential material in the memory of the Local Security Authority Subsystem Service (LSASS) in ways Microsoft was officially denying. The module names became infrastructure for an entire criminal economy. sekurlsa::logonpasswords to dump LSASS. sekurlsa::pth for pass-the-hash. kerberos::golden to forge a TGT given the krbtgt hash. lsadump::dcsync to impersonate a domain controller and request password hashes for any account.
Delpy demonstrated that the credential at rest was no longer the only target. After authentication, credential material lived in memory: NTLM hashes, Kerberos tickets, plaintext passwords cached by single-sign-on layers. Memory was readable by any process running with sufficient privilege. The artifact class doubled. The defender's surface doubled with it.
The Target breach of November 2013 is the canonical worked example. Initial access came via stolen credentials belonging to Fazio Mechanical Services, an HVAC vendor in Sharpsburg, Pennsylvania, that had a partner-portal account for billing and project management. (The popular narrative that attackers entered through HVAC controls is wrong. Fazio had vendor-portal access, not store-floor access.) Phishing malware harvested those credentials. Inside the vendor application, the attackers used pass-the-hash to escalate to Domain Admin, then deployed point-of-sale RAM-scraping malware to 1,797 stores and their payment terminals. Forty million card numbers, seventy million PII records, and two hundred million dollars in direct cost. The CEO and CIO out.
The story is less about "vendors and HVAC contractors" and much more about a "flat network plus pass-the-hash plus unmonitored Active Directory."
III. Tokens
SAML 2.0 became an OASIS standard in March 2005. OAuth 2.0 was published as RFC 6749 in October 2012. OpenID Connect followed in 2014. By the late 2010s, the typical enterprise had SAML for identity-provider-to-SaaS browser SSO and OAuth and OIDC for everything mobile, API-driven, or programmatic. The unit of theft changed shape. A password typed into a form became a base64-encoded SAML assertion. The SAML assertion became a JWT bearer token. The JWT became a refresh token persisted in a cookie store.
The credential moved outward, from the operating system to the directory service to the federation provider to the SaaS application, and at each step the consequences of theft grew.
The 2011 RSA SecurID breach demonstrated that the issuer itself could be compromised. Two small groups of RSA employees received spear-phishing emails titled 2011 Recruitment Plan with an Excel attachment containing an Adobe Flash zero-day. One target retrieved the message from their junk folder and opened it. Within months, the seed warehouse, the database of secret values that mapped to every SecurID hardware token RSA had issued, was exfiltrated. Lockheed Martin, Northrop Grumman, and L-3 were attacked using the harvested seeds. Lockheed replaced every token in the company.
The Office of Personnel Management breach, disclosed in 2015, demonstrated the same lesson at scale. Attackers attributed to the Chinese Ministry of State Security (MSS) first breached OPM in November 2013. They then breached KeyPoint Government Solutions, a contractor performing background investigations, harvested KeyPoint user credentials, used them to log into OPM's network in May 2014, and operated with persistence for over a year. They exfiltrated Standard Form 86 background-check records, including fingerprints, on 21.5 million people. The breach was detected in April 2015 by a Cylance product during a deployment. Andy Ozment of DHS testified to Congress that encryption would not have helped. The attackers had valid credentials. They authenticated. The system handed them the data.
Most postmortems of the modern era resolve to that sentence.
IV. Sessions
By the early 2020s, the dominant unit of theft was the session itself.
The infostealer ecosystem matured in the same period. Lumma, RedLine, Vidar, StealC, and Rhadamanthys, sold as Malware-as-a-Service for $250 a month and up through Russian-language Telegram channels, silently dump browser-stored passwords, autofill data, cryptocurrency wallets, Discord tokens, VPN configurations, and the session cookies and authentication tokens that prove a browser is already logged in. SpyCloud's 2025 reporting indicates that an average infection yields tens of credentials and roughly 1,800 cookies. Verizon's 2025 DBIR found that 54% of ransomware victims had their domain credentials appear in stealer logs before the attack.
The Snowflake incident of 2024 is the worked example. The actor, tracked as UNC5537 and also as ShinyHunters, did not breach Snowflake. They purchased infostealer logs going back to 2020 from criminal markets, found Snowflake-customer credentials, and logged into roughly 165 customer tenants where multi-factor authentication had never been enforced and credentials had never been rotated. Ticketmaster. AT&T. Santander. Neiman Marcus. Mandiant attributed much of the initial infection to contractor laptops used for both work and personal activities (gaming, pirated software) outside the corporate security boundary.
In parallel, adversary-in-the-middle phishing toolkits (Evilginx, Tycoon 2FA, EvilProxy) solved the MFA problem differently. Instead of asking the user for the second factor, the attacker stands up a reverse-proxy phishing site that proxies the real login flow. The user types their password. The user receives a legitimate MFA prompt from the legitimate identity provider. The user completes it. The legitimate identity provider issues a session cookie. The proxy captures the cookie and replays it from the attacker's browser. Multi-factor authentication is not bypassed. It is waited out, and the proof of completion is stolen.
The identity providers themselves became concentrated trust targets. Okta has had multiple instructive incidents. In January 2022, a customer-support engineer at Sitel, a third-party Okta subcontractor, had their laptop compromised by the LAPSUS$ group, which gave screenshot-shared access to up to approximately 366 customer tenants. In October 2023, an Okta support engineer signed into a personal Google account in Chrome on an Okta-managed laptop; saved credentials for an Okta support service account synced to Google's password manager; the personal account was compromised; the attacker logged into the Okta support portal and downloaded HAR files uploaded by customers (1Password, BeyondTrust, Cloudflare, and the ability to access roughly 131 others) for troubleshooting. The HAR files contained live session cookies. The cookies were replayed.
The credential was no longer the password. It was no longer the hash, the ticket, the token, or the assertion. It was the live session — the artifact that proves authentication has already happened — and a HAR file uploaded for support purposes was sufficient to forge it.
V. Now agents
The most consequential quiet shift of 2018–2025 is that most authentication events in a modern enterprise are now machine-to-machine. Microservices calling other microservices. CI jobs calling cloud APIs. SaaS applications calling each other through OAuth integrations. Observability agents pulling logs. Terraform applying changes to production.
Vendor estimates of the ratio of non-human to human identities vary widely — 10× to 50×, sometimes higher — and should be read as order-of-magnitude indicators rather than precise figures. The direction is not in dispute, and neither is the operational state: long lifetimes, broad scopes, weak rotation, and no second factor are the default rather than the exception.
GitGuardian counted 29 million new hardcoded secrets pushed to public GitHub in 2025 alone. 70 percent of valid secrets detected in their 2022 scan were still active in 2026. The Uber 2016 breach, the cover-up of which produced the first criminal conviction of a security officer, was caused by AWS credentials in a GitHub repository.
The newest layer is the agentic one. Anthropic released the Model Context Protocol in late 2024 as a standard for connecting AI agents to external tools and data sources. By 2026 it had become the de facto interface for agent-to-tool authentication. A 2025 scan of approximately hundreds of publicly accessible MCP servers found that over a third of them had authentication configured. GitGuardian identified 24,008 hardcoded secrets in MCP configuration files on public GitHub, of which 2,117 remained valid. The likely causes can be traced to MCP server quickstart documentation showing API keys hardcoded in example configuration files.
Beneath the implementation problems sits a deeper one. An AI agent operating on a user's behalf holds the user's authority. If untrusted content (a webpage the agent is summarizing, a GitHub issue it is reading, a PDF it is analyzing) contains instructions that the model interprets as a high-trust directive, the agent will execute those instructions using the user's credentials. The May 2025 Invariant Labs GitHub MCP disclosure, in which a poisoned issue in a public GitHub repository caused an AI agent to read a private repository and emit its contents via a public pull request. The security boundary between instruction and data does not exist in the model's representational geometry. Every prior credential system assumed an honest-but-fallible holder. Agents are not honest holders. They have no robust mechanism to distinguish instruction from data; the boundary is statistical, and a sufficiently confident-sounding string in the data channel is treated as an instruction.
VI. Everywhere
The history above traces the evolution of the credential as an artifact. It leaves a separate fact unstated: the operational state of those artifacts in any given enterprise on any given day.
A developer laptop in 2026 typically holds, on disk:
- AWS access keys in
~/.aws/credentials, often with administrator-level IAM policies because that is what the developer needed to ship something three years ago - A GitHub personal access token in a dotfile, configured with
repoandworkflowscope because that is what the tutorial illustrated - A kubectl config with cluster-admin context to one or more production clusters
- A Docker config with credentials to private registries
- An
.envfile from a project the developer has not touched in six months - SSH keys for every server, jump host, and bastion the developer has ever needed
- Slack, Notion, and Linear OAuth tokens that grant access to every channel, document, and ticket the user can see
- A password manager unlocked for the working session, granting access to everything stored in it Browser cookies for every SaaS the company uses, valid for whatever lifetime the issuer chose
The number of services this single laptop can authenticate to, without any additional credentials being typed, often exceeds the number an IR lead can enumerate in a working day.
CI runners are worse. GitHub Actions secrets are exposed as environment variables to every step of every workflow that requests them. A workflow that builds a Docker image, runs tests, and pushes to production touches secrets for the registry, the package manager, the deployment target, the observability backend, and frequently the source-control provider itself. The Codecov compromise of early 2021 — in which a single Bash uploader script ran in tens of thousands of CI pipelines for two months while exfiltrating environment variables — surfaced this fact for the broader industry. CircleCI's January 2023 incident — initial access via an infostealer on an engineer's laptop, lateral movement via a session cookie that bypassed MFA, access to the secrets vault of every customer — surfaced it again. CircleCI ordered every customer to rotate every secret.
Token rotation is theoretical for most of these. GitGuardian's 2026 reporting indicates 64% of valid secrets detected in their 2022 scan were still active four years later. The token was created. It worked. Nothing in the operational pipeline requires it to ever stop working.
Token scope is, in practice, "whatever happened to work." IAM policies default to toward *:*. GitHub PATs get the broadest scope the documentation example showed. Service account keys are issued with project-wide roles because the developer ran out of time to figure out a tighter binding. The token does what the policy says, and the policy says everything nobody had time to remove.
Credentials in unstructured tools are the final layer. The OneNote with the production database password. The pinned Slack message with the AWS root access key. The Confluence runbook that lists the SSH key passphrase. The Jira ticket attachment with the SAML signing certificate. The shared spreadsheet with the API keys for every third-party integration. These are invisible to every tool that operates at the network or process layer. They are, for many enterprises, among the most readily-stolen credential classes in existence.
An IR lead reading the host inventory after an incident is rarely surprised that the developer laptop had AWS keys on it. They are surprised by what the AWS keys could do.
VII. Patterns
Defense in depth has become defense by accumulation.
A 2026 enterprise simultaneously runs:
- Local accounts on legacy Unix systems
- NTLM hashes in SAM hives on Windows workstations
- Kerberos tickets against Active Directory domain controllers
- SAML assertions to dozens of SaaS applications
- OAuth access and refresh tokens for hundreds of integrations
- JWTs flying between microservices
- IAM roles assumed via STS in AWS
- Managed identities in Azure, federated to GitHub Actions OIDC
- Service account keys in Google Cloud
- API keys for Salesforce, Twilio, OpenAI, Snowflake, Datadog
- Personal access tokens in GitHub
- SSH keys in
~/.ssh/files - SSH agent sockets and forwarded agents
- Code-signing certificates
- TLS private keys rotated by cert-manager
- Browser session cookies, password manager databases, OS keychains
- Passkeys for the small fraction of human-facing applications that support them
- Agent passports, MCP OAuth tokens, and delegation receipts for AI agents
Some of these are credentials in the classical sense, strings that prove identity. Others are handles: an SSH agent socket, a forwarded agent connection, a session cookie, a browser autofill entry, an OS keychain unlocked for the duration of a login session. The handle grants access to the credential without revealing it. The defender gets to track both.
Each layer was created because the previous one had failed. None has been retired, because something still depends on it. The attacker does not have to break the strongest layer. They choose whichever is softest, and softness is a property of operations, not cryptography. The credential is an organizational problem disguised as a cryptographic one.
VIII. The first hour
Every postmortem of the modern era resolves to roughly the same description. The attacker authenticated, the credential was real, and the system did what it was designed to do.
The cryptography isn't necessarily weak. FIDO2 protects against adversary-in-the-middle. Encryption secrets might be secured in KMS. Short-lived OIDC tokens with workload identity federation work against the long-lived service account key class. Bearer tokens bound to client certificates work against the cookie-replay class. The techniques exist and the math is sound.
But the deployments are partial.
What's missing, and what every IR lead encounters in the first hour of every investigation, is visibility across the layers. The questions are simple and the answers are nowhere.
- What credentials are on this host
- What does each credential reach.
- Where else in this environment does that pattern exist.
The questions are not answered by any existing tool category cleanly. Identity governance covers humans and partially covers service accounts. Secret managers cover what teams have migrated into them, which is rarely everything (or the authorization tokens are scattered about) EDR sees process behavior but does not reason about credentials as objects. Cloud security posture management sees cloud roles but not the developer laptop that holds the keys to assume them. And at some point something will be decrypting the keys. Cloud infrastructure entitlement management sees the entitlements but not where the credentials sit on disk in the wild.
The IR lead reconstructs the answer manually under time pressure, from scratch.
This is a piece about credentials at rest. The scope of the visibility problem extends slightly further, to the access surface each credential authenticates against, and to the relationships among credentials and the resources they reach. Credentials in memory during an active session are a parallel problem, partially addressed by EDR, with its own history and its own tools. The two problems are linked at specific points; this piece has dwelt on one of them.
The operational shift the next decade has to make is not necessarily fewer credentials. The historical record says that they'll be around for some time to come. Credentials accumulate. New artifact classes will continue to be invented; old ones will continue to refuse to retire. The shift is in knowing the credentials you already have: where they live, what they can do, and what changes about them between yesterday and today. The first hour is not the place to discover the answers. The first hour is the place to read them.
Coda
Allan Scherr walked to the file cabinet on a Saturday morning in 1966 and picked up a printout. The shape of that problem has not changed. The shape of the enterprise has. There are shadowed file cabinets in every cloud account, every developer laptop, every CI runner, every browser, every MCP server, every agent. The artifact has changed at every layer and the principle has not.
The next era of credential security will not be defined by a new artifact. It will be defined by whoever can see across all the old ones.