The Infostealer Incursion: How Stolen Credentials Breach Cloud, Code, and AI Environments

Token persistence: which stolen artifact actually matters

The summary lists the file paths; what it can't carry is that these artifacts differ enormously in how long stolen access survives — which is the whole risk calculus. From the page:

• AWS STS cache (~/.aws/cli/cache/): temporary tokens lasting 1–12h. The page explicitly notes this makes them "somewhat less useful" to operators unless sold immediately.
• AWS SSO OIDC tokens (~/.aws/sso/cache/): the long-lasting tokens generated at initial SSO login, lasting up to 90 days. Until aws sso logout runs or an admin revokes, an attacker can continuously mint fresh AWS credentials. This is the high-value AWS target, not the STS cache.
• GCP credentials.db OAuth 2.0 refresh tokens: do not expire automatically unless explicitly revoked — granting persistent programmatic access to the whole project.
• Claude Code ~/.claude/.credentials.json: OAuth refresh tokens (mode 0600) that are portable — copying the file to another machine grants immediate access; a stolen refresh token mints new access tokens, reads conversation history, and can invoke any configured MCP servers.

Detection artifacts the summary doesn't name

The page gives specific token prefixes and cookie names usable for grep/DLP rules:

• Token prefixes: gho_ (GitHub CLI plaintext tokens in hosts.yml when no keyring), glrt- (GitLab Runner tokens in config.toml, allowing rogue runner registration to intercept CI/CD jobs).
• Session cookies for MFA-bypass hijacking: GitHub — user_session, __Host-user_session_same_site, _gh_sess; GitLab — _gitlab_session; ChatGPT — __Secure-next-auth.session-token (grants chat-history access).
• Plaintext credential sinks beyond the main config files: git-credential-store writes ~/.git-credentials as https://username:token@github.com; GitLab PATs often in ~/.netrc as machine gitlab.com login oauth2 password <token>.

macOS Keychain weakness (Claude Code)

The page states a specific design flaw: on macOS, Claude Code tokens live in the Keychain, but the item is locked to the security binary rather than to Claude Code. Any process running as the same user can invoke security and extract the tokens without triggering a password prompt. This defeats the assumption that Keychain storage is safe against same-user malware.

Named threats and tooling

• CVE-2023-7028 in self-hosted GitLab has been exploited to distribute StealC via the Amadey loader, then harvest browser cookies including GitLab sessions.
• Vidar 2.0 has hardcoded logic to enumerate %USERPROFILE%\.azure; TeamPCP (LiteLLM supply-chain infostealer) targeted application_default_credentials.json.
• PEASS-ng (linPEAS/winPEAS) now ships AI-credential detection: its sensitive_files.yaml scans ~/.claude/ for settings.json/settings.local.json and patterns ANTHROPIC_API_KEY, ANTHROPIC_AUTH_TOKEN, apiKeyHelper, mcpServers — meaning these appear in both attacker and defender playbooks.

What to do

The page names concrete hardening choices:

• On AWS, prefer Granted, which leverages the OS keychain, over writing long-term keys to ~/.aws/credentials; run aws sso logout to cut the 90-day OIDC window.
• On GitLab CLI, authenticate with --use-keyring so glab does not write plaintext tokens to config.yml.
• Treat GCP refresh-token DBs and Claude .credentials.json as non-expiring: rotation/revocation is the only reliable kill switch.

Caveat

The page states it is not aware of public occurrences of stolen AI keys being used to reach historical chat logs, despite flagging the risk — that path is hypothesized, not observed.