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):-

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

The post Hackers Don’t Need to Break Into the Cloud When They Can Steal the Keys appeared first on Cyber Security News.