One Threat Actor Is Looting Every Cloud Provider at the Same Time

#One set of stolen credentials. Every cloud you use. All at once.

Most breaches start in one place and stay there long enough for someone to notice. This one doesn't.

A threat actor tracked as JINX-0163 is running an active credential harvesting campaign across AWS, Azure, GCP, Okta, and multiple SaaS platforms simultaneously. Not one cloud. Not two. All of them. The campaign has been observed since spring 2026 and is still active as of June 2026.

The playbook is simple and brutally effective: steal one set of cloud credentials, then use automated tooling to enumerate every resource, pull every secret, and export every database across every connected cloud and SaaS environment. One compromise becomes a multi-cloud foothold in minutes.

And they're routing everything through Mullvad VPN, which means IP-based detection and attribution are functionally useless.

#How this actually works.

JINX-0163 isn't exploiting a zero-day. They're not finding some exotic vulnerability in your cloud provider's infrastructure. They're using valid credentials that were already stolen. The attack chain:

1. Obtain stolen cloud credentials. Infostealers, phishing, credential dumps, dark web purchases. The method of initial theft varies. The result is the same: valid access keys, tokens, or passwords.

1. Automated resource discovery. The actor runs enumeration tooling across every cloud environment those credentials touch. AWS accounts, Azure subscriptions, GCP projects. If the credentials have access, the tooling finds everything they can reach.

1. Secret harvesting. Environment variables, secrets managers, API keys, database connection strings, OAuth tokens. Everything that connects your cloud to other services gets pulled.

1. Database exports. Once they have database credentials, they export the data. Customer records, financial data, internal documents. Whatever's in there.

1. OAuth and identity provider abuse. This is the part that makes JINX-0163 particularly dangerous. They abuse Okta tokens and OAuth grants for persistence. That means even if you reset passwords, they can maintain access through refresh tokens and OAuth app grants that survive the reset.

1. Repeat. When defenders find and remediate the initial access, the actor attempts to regain entry. They've already harvested credentials for connected services, so cutting access in one cloud doesn't cut access in all of them.

This is the part that should concern you: containment in one provider rarely ends the intrusion. If your AWS credentials are connected to services that have Azure credentials that have Okta tokens that have GCP access, the blast radius is everything.

#Why this matters if you're a small business.

You might be thinking this is an enterprise problem. It's not.

If your business uses any of the following, you're in scope:

• AWS, Azure, or GCP for hosting, storage, or compute
• Google Workspace or Microsoft 365 for email and documents
• Okta, Auth0, or any SSO provider for authentication
• Any SaaS tool that connects to your cloud via OAuth

That's every business with more than a Gmail account.

Small businesses are actually more vulnerable to this kind of attack because they typically have fewer access controls, less monitoring, and more overprivileged credentials floating around. Your AWS access key that has admin permissions? The one your developer created two years ago and never rotated? That's exactly what JINX-0163 is looking for.

We've written before about how the SaaS tools your team uses are a liability and how the Vercel breach cascaded through a third-party AI tool. JINX-0163 is the logical conclusion of those risks: an actor who has industrialized the process of turning one stolen credential into access across every cloud service you use.

And the GitHub token validation campaign we covered last week? Same principle. Stolen credentials get tested, triaged, and exploited at scale. JINX-0163 is doing that across every major cloud provider simultaneously.

#What to do.

1. Rotate your cloud credentials. Today. Every AWS access key, every Azure service principal secret, every GCP service account key. If you don't know where all your credentials are, that's the first problem to solve. Check IAM consoles for every cloud provider you use. Look for access keys older than 90 days and kill them.

2. Enforce phishing-resistant MFA on everything. Not SMS. Not push notifications. Hardware security keys (FIDO2/WebAuthn) or passkeys. JINX-0163 abuses OAuth tokens that can bypass password-based MFA. Phishing-resistant MFA is the only kind that holds up against token theft.

3. Audit and revoke OAuth grants. Go to your Google Workspace admin panel (Security > API Controls > App Access Control) or Azure AD (Enterprise Applications). Look at every connected app. If you don't recognize it or don't use it, revoke it. Each OAuth grant is a persistence mechanism an attacker can exploit.

4. Scope down permissions. If a service account has admin access when it only needs read access to one S3 bucket, fix it. The principle of least privilege exists specifically to limit blast radius. An overprivileged credential in JINX-0163's hands gives them everything. A properly scoped one gives them almost nothing.

5. Enable and monitor cloud audit logs. AWS CloudTrail, Azure Monitor, GCP Cloud Audit Logs. You need to be alerting on unusual patterns: mass resource enumeration, secrets access from new IP ranges, database export operations. If you're not watching the logs, you won't see the actor until the data is gone.

6. Revoke suspicious refresh tokens and OAuth app grants. Password resets alone don't stop this actor. You need to explicitly revoke refresh tokens and review OAuth app grants in your identity provider. In Okta: check for unfamiliar app integrations and active sessions. In Google Workspace: revoke third-party app access for compromised accounts.

7. Assume re-intrusion. JINX-0163 has been observed repeatedly attempting to regain access after remediation. Don't treat containment as a one-time event. Monitor for the same enumeration patterns for weeks after you think you've kicked them out. They harvested credentials during their initial access and will try to use them.

#The uncomfortable truth.

Cloud security is identity security. The perimeter is the credential. If your credentials are stolen, your cloud is stolen. All of it. Across every provider.

JINX-0163 didn't invent this problem. They industrialized it. One actor, automated tooling, every major cloud and identity platform, running continuously. The only thing standing between this actor and your data is how well you manage your credentials, your permissions, and your monitoring.

If you don't know the answer to "where are all our cloud credentials and who has access to them," you have work to do. Start today.

#Further reading

• AWS CloudTrail - enable and monitor cloud API activity
• Azure Monitor - centralized monitoring for Azure resources
• GCP Cloud Audit Logs - audit logging for Google Cloud
• FIDO Alliance: FIDO2 - phishing-resistant MFA standard
• Google Workspace: Managing Connected Apps - audit and revoke OAuth grants
• CISA: Implementing Phishing-Resistant MFA - federal guidance on MFA