Hackers Don’t Need to Break Into the Cloud When They Can Steal the Keys

Infostealer malware is giving criminals a quieter route into corporate cloud environments. Instead of forcing their way through a hardened cloud perimeter, they infect a developer or employee device and take the credentials, API keys, and active sessions already trusted by the organization.

The initial infection can arrive through phishing, deceptive downloads, or a poisoned software dependency. Once running, a stealer gathers browser data and local developer secrets quickly, then operators can sell that access to other criminals.

These campaigns increasingly put cloud, code, and AI environments at risk. Its analysis of infected systems found Lumma C2, RedLine, and Vidar accounted for 85.7 percent of detected incidents.

Wiz.io said in a report shared with Cyber Security News (CSN) that the AWS and Google Cloud secrets represented 46 percent and 13 percent of compromised secrets, respectively.

A valid token can open cloud consoles, code repositories, build pipelines, and AI services, exposing data or driving up costs. The pattern closely echoes infostealer logs fueling breaches, where criminals buy access rather than exploit flaws.

Hackers Don’t Need to Break Into the Cloud

Attackers often do not need to defeat multi-factor authentication. A browser session token is created after a legitimate user signs in. If malware steals that token and an attacker loads it into another browser, the service may treat the attacker as the authenticated user.

Long-lived credentials extend that opportunity. AWS access keys saved in developer configuration files can provide direct programmatic access, while cached AWS SSO tokens may let an attacker obtain fresh temporary credentials.

In Azure, local CLI and identity caches can reveal access or refresh tokens, tenant information, and accounts. Google Cloud developer machines are also attractive because command-line credentials and service-account key paths can provide durable access to valuable production projects.

Source-control platforms add another path: a stolen repository token, SSH key, or session can expose private code, CI/CD variables, and deployment settings.

GitHub tokens accounted for roughly 10 percent of stolen secrets, while AI platform secrets made up 5 percent. AI credentials have increasingly become part of the same prize: stolen keys can consume services at the victim’s expense, while stolen sessions may expose internal chat histories.

The risk resembles recent AI infrastructure attacks, where exposed systems created a route to keys and connected resources. Personal or lightly managed developer devices can contain privileged business access without the same corporate protections.

Attackers have abused legitimate Windows tools and trojanized gaming-related files, while supply-chain stealers now target build servers and CI/CD processes without relying on phishing.

From Infection to Recovery

Malware-as-a-service operators distribute stealers, then initial-access brokers sort stolen logs, validate valuable accounts, and resell them. A single careless download can therefore turn into a cloud incident after the infection, as developer-focused MacSync campaigns have shown.

Organizations should treat a confirmed infostealer infection as an identity incident, not simply a malware-cleanup task. Isolate the affected device, investigate accounts used on it, revoke active sessions, and rotate passwords, API keys, SSH keys, cloud credentials, and repository tokens from a clean device.

Teams should review cloud, identity, source-control, and CI/CD logs for unfamiliar sessions, new access keys, unusual token activity, changes to roles, and unexpected repositories.

Rebuilding affected endpoints from clean sources is safer than assuming malware removal also removes stolen access. Prevention should reduce the value of data available on endpoints.

Use short-lived credentials and workload identity where possible, protect secrets with the operating system keychain or a managed vault, keep developer devices managed, and tightly scope permissions.

Lessons from the LiteLLM supply-chain exposure also support pinning dependencies and reviewing build-time behavior. Strong multi-factor authentication remains important, but it is not enough when an attacker can replay a valid session.

Organizations should require device-based access controls for sensitive services, monitor for exposed credentials, and revoke sessions quickly when risk signals change. Protecting the cloud means protecting every endpoint that holds its keys.

Indicators of compromise (IoCs):-

Type	Indicator	Description
Targeted or abused file	vbc.exe	Legitimate Windows compiler the report says attackers abuse for execution.
Targeted or abused file	Roblox.exe	Example of a trojanized gaming-related file.
Targeted or abused file	SkinChanger.exe	File name shown in the report’s Valorant-themed example.
Targeted file	~/.aws/config	AWS profiles and account configuration.
Targeted file	~/.aws/credentials	AWS access keys and secret keys.
Targeted directory	~/.aws/cli/cache/	AWS CLI cache that can hold temporary credentials.
Targeted directory	~/.aws/sso/cache/	AWS SSO token cache.
Targeted file	.azure/accessTokens.json	Azure CLI access and refresh tokens.
Targeted file pattern	.azure/msal_token_cache.*	Azure CLI authentication cache.
Targeted file	azureProfile.json	Azure subscription and tenant details.
Targeted file	%localappdata%\.IdentityService\msal.cache	Microsoft identity cache.
Targeted file	msalv2.cache	Alternative Microsoft identity cache name.
Targeted directory	%USERPROFILE%\.azure	Azure CLI authentication directory.
Targeted file	credentials.db	Google Cloud CLI refresh tokens.
Targeted file	access_tokens.db	Google Cloud CLI access tokens.
Targeted file	application_default_credentials.json	Google Cloud application credentials.
Targeted directories	~/.config/gcloud/, %appdata%\gcloud\	Google Cloud CLI data locations.
Targeted environment variable	$GOOGLE_APPLICATION_CREDENTIALS	Points to a service-account key file.
Targeted files	~/.config/gh/hosts.yml, %APPDATA%\GitHub CLI\hosts.yml	GitHub CLI token and configuration locations.
Targeted files	~/.git-credentials, $XDG_CONFIG_HOME/git/credentials	Git authentication stores.
Targeted files	~/.ssh/id_rsa, ~/.ssh/id_ed25519	Private SSH keys.
Targeted environment variables	GITHUB_TOKEN, GH_TOKEN	GitHub access-token variables.
Targeted cookies	user_session, __Host-user_session_same_site, _gh_sess	GitHub browser sessions.
Targeted files	~/.config/glab-cli/config.yml, %USERPROFILE%\.config\glab-cli\config.yml	GitLab CLI token and configuration locations.
Targeted files	/etc/gitlab-runner/config.toml, ~/.gitlab-runner/config.toml	GitLab Runner configuration and tokens.
Targeted file	~/.netrc	Possible storage location for GitLab personal access tokens.
Targeted environment variables	GITLAB_TOKEN, GITLAB_ACCESS_TOKEN, CI_JOB_TOKEN	GitLab access-token variables.
Targeted cookie	_gitlab_session	GitLab browser session.
Targeted cookie	__Secure-next-auth.session-token	ChatGPT browser session.
Targeted files	credentials.json, .env	Possible storage locations for OpenAI API keys.
Targeted environment variable	OPENAI_API_KEY	OpenAI API key variable.
Targeted file	~/.claude/.credentials.json	Claude Code OAuth credentials on Linux.
Targeted files	~/.claude/settings.json, ~/.claude/settings.local.json	Claude Code configuration files.
Targeted environment variables	ANTHROPIC_API_KEY, ANTHROPIC_AUTH_TOKEN, CLAUDE_CODE_OAUTH_TOKEN	Anthropic API and session-token variables.
Referenced security-tool file	sensitive_files.yaml	Configuration file cited for credential-search rules; not identified as malware.

Note: IP addresses and domains are intentionally defanged (e.g., [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.

Cut every SOC alert investigation by 21 min. Power your SOC with instant IOC context for immediate response: Integrate TI Lookup in your SOC