LLMjacking via Malvertising: How Phished Cloud Credentials Become Six-Figure AI API Bills — Detection and Response Guide

A new wave of financially motivated attacks documented by Wiz demonstrates a threat chain that every cloud-first organization needs to understand right now: a single click on a malicious Google Search ad leads to credential phishing, full compromise of a cloud billing account, and hundreds of thousands of dollars in unauthorized LLM API consumption — a technique the industry now calls LLMjacking.

This is not cryptomining 2.0 in theory only. Attackers are actively monetizing stolen cloud credentials by invoking commercial large language model APIs (Amazon Bedrock, Azure OpenAI, Google Vertex AI) and reselling that access through gray-market AI proxy services. The victim organization discovers the breach not through an EDR alert, but through a finance team's panicked call about a cloud bill that is orders of magnitude above baseline.

Why defenders must act: the attack chain bypasses most traditional endpoint controls. The initial access is a browser-based phishing page that harvests credentials and session tokens. The post-compromise activity — LLM API invocation — is a legitimate API call made with legitimate credentials. If your detection strategy relies on malware signatures or impossible-travel alerts alone, you will miss this. Billing anomaly detection, IAM telemetry, and model invocation auditing are your tripwires.

Technical Analysis

Attack Chain Breakdown

Based on the Wiz research, the end-to-end kill chain looks like this:

1. Malvertising (Initial Lure): Threat actors purchase Google Search ads targeting high-intent queries — cloud console logins, AI platform sign-ups, popular SaaS tools. The ads impersonate legitimate services and rank above organic results.
2. Credential Phishing: The ad leads to a pixel-perfect phishing page (often an adversary-in-the-middle kit) that harvests cloud console credentials and, critically, session cookies — allowing MFA bypass via token theft.
3. Cloud Account Takeover: Stolen credentials are replayed against AWS, Azure, or GCP consoles. Attackers establish persistence by creating new IAM users, access keys, or federated identity providers to survive password resets.
4. LLM Abuse (LLMjacking): Attackers invoke foundation models via APIs such as Amazon Bedrock's InvokeModel / Converse operations at massive scale. In prior LLMjacking campaigns, actors used open-source reverse proxies (e.g., OAIReverseProxy-style tooling) to resell access to hijacked model endpoints, including access to premium models that incur significant per-token charges.
5. Monetization: The resold access feeds underground AI services. The victim pays the bill — in documented cases, tens of thousands of dollars per day of compromised access, scaling to hundreds of thousands overall.

Affected Platforms

• Amazon Web Services — Amazon Bedrock (bedrock:InvokeModel, bedrock:Converse, cross-region model invocation)
• Microsoft Azure — Azure OpenAI Service deployments
• Google Cloud Platform — Vertex AI endpoints
• Any IdP/cloud console reachable via phishing-assisted session token theft

No CVE applies here — this is an identity-and-configuration attack class, not a software vulnerability. The enabling weaknesses are:

• IAM users with long-lived access keys and overbroad permissions (e.g., bedrock:* or AdministratorAccess)
• Lack of MFA enforcement or phishing-resistant MFA (FIDO2/passkeys)
• Model access not explicitly restricted via Service Control Policies (SCPs)
• Bedrock model invocation logging disabled (it is off by default — a critical blind spot)
• No billing anomaly alerting configured

Exploitation Status

Confirmed active exploitation in the wild. Wiz's research documents real incidents with substantial financial impact, and LLMjacking has been an observed, monetized criminal business model since at least 2024, continuing and evolving into 2025–2026 with malvertising as an increasingly common entry vector. This is not theoretical — treat any unexpected Bedrock/Vertex/Azure OpenAI consumption as a potential incident until proven otherwise.

Detection & Response

The detections below target the two most reliable observables in this chain: (1) identity events indicating credential replay and persistence creation, and (2) LLM API invocation anomalies. A veteran SOC note upfront: InvokeModel alone is noisy in any org legitimately using Bedrock — the rules below key on new principals, cross-region anomalies, and invocation logging tampering, which are far higher fidelity.

Sigma Rules

---
title: AWS IAM Persistence Creation Following Potential Credential Compromise
id: 3f8c2a91-7b4e-4d5a-9c21-8e6f1a2b3c4d
status: experimental
description: Detects creation of IAM access keys, login profiles, or new users — a common persistence step after cloud credential theft via phishing/malvertising, as seen in LLMjacking campaigns.
references:
  - https://www.wiz.io/blog/from-phishing-to-llmjacking
  - https://attack.mitre.org/techniques/T1098/001/
author: Security Arsenal
date: 2026/02/12
tags:
  - attack.persistence
  - attack.t1098.001
logsource:
  product: aws
  service: cloudtrail
detection:
  selection:
    eventSource: iam.amazonaws.com
    eventName:
      - CreateAccessKey
      - CreateLoginProfile
      - CreateUser
      - AttachUserPolicy
      - CreateOpenIDConnectProvider
      - CreateSAMLProvider
falsepositives:
  - Legitimate IAM administration; alert on executions by principals that have not performed these actions historically, or from unusual source IPs/ASNs
level: high
---
title: Amazon Bedrock Model Invocation by New or Anomalous Principal
id: 9d4e7b12-3a6f-4c8d-b5e2-1f9a0c7d8e6f
status: experimental
description: Detects Bedrock InvokeModel/Converse API calls from IAM principals, cross-account activity characteristic of LLMjacking abuse of compromised billing accounts. Tune the filter to your known AI-consuming principals.
references:
  - https://www.wiz.io/blog/from-phishing-to-llmjacking
  - https://attack.mitre.org/techniques/T1098/
author: Security Arsenal
date: 2026/02/12
tags:
  - attack.impact
  - attack.t1496
logsource:
  product: aws
  service: cloudtrail
detection:
  selection:
    eventSource: bedrock.amazonaws.com
    eventName:
      - InvokeModel
      - InvokeModelWithResponseStream
      - Converse
      - ConverseStream
  filter_known_benign:
    userIdentity.type: AssumedRole
    userIdentity.arn|contains: '/your-approved-bedrock-role'
  condition: selection and not filter_known_benign
falsepositives:
  - Developers experimenting with Bedrock; establish a baseline of approved model-consuming roles and alert on deviation
level: medium
---
title: Bedrock Model Invocation Logging Disabled or Guardrail Deleted
id: 5b1c9e47-2d8a-4f6c-a3d9-7e4b2c1a8f5d
status: experimental
description: Detects tampering with Bedrock visibility controls — disabling model invocation logging, deleting guardrails, or stopping CloudTrail logging — an anti-forensics step observed in billing-abuse intrusions.
references:
  - https://www.wiz.io/blog/from-phishing-to-llmjacking
  - https://attack.mitre.org/techniques/T1562/008/
author: Security Arsenal
date: 2026/02/12
tags:
  - attack.defense_evasion
  - attack.t1562.008
logsource:
  product: aws
  service: cloudtrail
detection:
  selection_logging:
    eventSource: bedrock.amazonaws.com
    eventName:
      - DeleteModelInvocationLoggingConfiguration
      - DeleteGuardrail
      - PutModelInvocationLoggingConfiguration
  selection_trail:
    eventSource: cloudtrail.amazonaws.com
    eventName:
      - StopLogging
      - DeleteTrail
      - PutEventSelectors
  condition: selection_logging or selection_trail
falsepositives:
  - Rare legitimate configuration changes; any execution of these API calls outside a change window should page a human
level: critical

KQL — Microsoft Sentinel (AWS CloudTrail Connector)

This hunt surfaces the LLMjacking behavioral cluster: anomalous Bedrock invocation volume, invocation from principals with recent persistence activity, and invocation across previously unused regions. It assumes AWS CloudTrail is ingested into the AWSCloudTrail table via the Sentinel connector.

// LLMjacking hunt: anomalous Bedrock usage correlated with fresh IAM persistence
let lookback = 14d;
let persistenceActors = AWSCloudTrail
| where TimeGenerated > ago(lookback)
| where EventSource == "iam.amazonaws.com"
| where EventName in ("CreateAccessKey", "CreateLoginProfile", "CreateUser", "CreateOpenIDConnectProvider")
| extend ActorArn = tostring(UserIdentityArn)
| distinct ActorArn;
AWSCloudTrail
| where TimeGenerated > ago(lookback)
| where EventSource == "bedrock.amazonaws.com"
| where EventName in ("InvokeModel", "InvokeModelWithResponseStream", "Converse", "ConverseStream")
| extend ActorArn = tostring(UserIdentityArn)
| summarize InvokeCount = count(),
            Regions = dcount(AwsRegion),
            RegionList = make_set(AwsRegion),
            SourceIPs = make_set(SourceIpAddress),
            FirstSeen = min(TimeGenerated),
            LastSeen = max(TimeGenerated)
    by ActorArn, UserIdentityType, bin(TimeGenerated, 1h)
| where InvokeCount > 500                      // tune to baseline; attackers drive volume
   or Regions > 2                              // cross-region spraying is a strong LLMjacking signal
   or ActorArn in (persistenceActors)          // invoker created persistence in last 14d
| sort by InvokeCount desc

Velociraptor VQL — Endpoint Hunt

On the endpoint side, the forensic value is identifying (a) hosts where AWS credentials were created or modified unexpectedly, and (b) processes reading credential material outside of normal tooling. This artifact hunts for recently modified AWS credential files and suspicious process access patterns.

-- Hunt for recently created/modified AWS credential files and anomalous AWS CLI usage
-- Relevant when investigating phishing-driven cloud credential theft (LLMjacking chain)
LET credFiles = SELECT FullPath, Mtime, Ctime, Size,
       parse_pe(FilePath=FullPath) AS PE
FROM glob(globs='C:/Users/*/.aws/credentials', accessor='ntfs')
WHERE Mtime > now() - 86400 * 7

LET suspiciousAWSUsage = SELECT Pid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE CommandLine =~ '(?i)(bedrock|invoke-model|converse|iam create-access-key|configure set aws_secret)'
  AND NOT ParentName =~ '(?i)(code|pycharm|idea|terraform)'

SELECT * FROM foreach(row=credFiles,
  query={ SELECT FullPath, Mtime, Ctime, Size FROM scope() })
UNION ALL
SELECT Exe AS FullPath, CreateTime AS Mtime, CreateTime AS Ctime, Pid AS Size
FROM suspiciousAWSUsage

Hardening & Verification Script

This Bash script audits an AWS environment for the exact weaknesses LLMjacking campaigns exploit: stale access keys, missing invocation logging, unrestricted Bedrock access, and absent billing alerts. Run it with an auditor role; it makes no changes — it reports.

#!/usr/bin/env bash
# llmjacking-audit.sh — Audit AWS for LLMjacking exposure
# Requires: awscli v2, jq. Read-only. Run per-region where noted.
set -euo pipefail

echo "=== [1] IAM users with access keys older than 90 days ==="
aws iam list-users --query 'Users[].UserName' --output text | tr '\t' '\n' | while read -r u; do
  aws iam list-access-keys --user-name "$u" \
    --query "AccessKeyMetadata[?Status=='Active'].{User:'$u',Key:AccessKeyId,Created:CreateDate}" \
    --output json | jq -c '.[] | select(.Created < (now - 7776000 | strftime("%Y-%m-%dT%H:%M:%S")))'
done

echo "=== [2] Bedrock model invocation logging status (per region) ==="
for region in $(aws ec2 describe-regions --query 'Regions[].RegionName' --output text); do
  status=$(aws bedrock get-model-invocation-logging-configuration --region "$region" \
    --query 'loggingConfig' --output json 2>/dev/null || echo "{}")
  echo "$region => $status"
done

echo "=== [3] IAM policies granting broad bedrock:* permissions ==="
aws iam list-policies --scope Local --query 'Policies[].Arn' --output text | tr '\t' '\n' | while read -r p; do
  ver=$(aws iam get-policy --policy-arn "$p" --query 'Policy.DefaultVersionId' --output text)
  aws iam get-policy-version --policy-arn "$p" --version-id "$ver" \
    --query 'PolicyVersion.Document.Statement[?Effect==`Allow`] | [?contains(to_string(Resource), `bedrock`) && contains(to_string(Action), `*`)]' \
    --output json | jq -e 'length > 0' >/dev/null 2>&1 && echo "OVERBROAD: $p"
done

echo "=== [4] CloudWatch billing alarm existence (us-east-1) ==="
aws cloudwatch describe-alarms --region us-east-1 \
  --query "MetricAlarms[?Namespace=='AWS/Billing'].{Name:AlarmName,Threshold:Threshold}" --output table

echo "=== [5] Recent Bedrock invocation principals (last 24h, via CloudTrail Lake) ==="
echo "Run manually: SELECT userIdentity.arn, awsRegion, count(*) FROM cloudtrail WHERE eventSource='bedrock.amazonaws.com' AND eventTime > now() - interval '1' day GROUP BY 1,2"

echo "=== Audit complete. Remediate: rotate keys, enable invocation logging, apply SCPs, set billing alarms. ==="

Remediation

There is no patch to apply — this is an identity, configuration, and detection discipline problem. Prioritize in this order:

Immediate (24 hours):

1. Enable Bedrock model invocation logging in every region — it is off by default. Route logs to a locked-down S3 bucket with CloudTrail Lake or Sentinel ingestion. Without this, you cannot reconstruct abuse scope.
2. Audit and rotate all long-lived IAM access keys, especially any key older than 90 days or belonging to console-capable users. Invalidate active console sessions for any account touched by a phishing report.
3. Enable AWS Cost Anomaly Detection / Azure Cost Management alerts / GCP Budget alerts with a threshold tied to your actual baseline — and page someone, don't just email a distribution list. Attackers have burned six figures in days; a Monday-morning email review is too slow.
4. Search CloudTrail for the persistence artifacts in the Sigma rules above: CreateAccessKey, CreateLoginProfile, federated IdP creation, and any DeleteModelInvocationLoggingConfiguration events.

Short term (1–2 weeks): 5. Enforce phishing-resistant MFA (FIDO2/passkeys) on all cloud console access. Session-token phishing via AiTM kits defeats TOTP and push MFA. Passkeys break this chain at step 2. 6. Apply Service Control Policies to deny bedrock:* (and equivalent Azure OpenAI / Vertex AI actions) in OUs and regions where you do not intentionally run AI workloads. An SCP is the difference between a stolen credential being an incident and being a headline. 7. Adopt short-lived credentials everywhere — IAM Identity Center, instance roles, OIDC federation for CI/CD. Eliminate the standing credential the attacker came to steal. 8. Block malvertising at the browser layer: deploy DNS/category filtering for newly registered domains, and train users to navigate to console bookmarks rather than clicking search ads. The entry point here was an ad click — that is a control failure you can close cheaply.

If you confirm compromise: 9. Revoke all sessions and keys for affected principals, disable created IAM users/IdPs, snapshot billing and invocation logs before remediation (you'll need them for the cloud provider's abuse dispute process), and engage AWS/Azure/GCP support immediately — providers have formal processes for disputing fraudulent usage charges, but they expect timely reporting and evidence.

Reference: Wiz — From social engineering to LLMjacking

The strategic lesson for CISOs: your cloud bill is now a security telemetry source. Finance anomalies and SOC detections need to converge — the first person to see an LLMjacking incident is often the person who approves invoices, and by then the meter has been running for days.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub