Cloud Service Hijacking
After compromising a cloud environment, adversaries can potentially hijack large language models (LLM) to siphon computing power, distribute illicit content, and more.
Why do adversaries hijack cloud services?
Adversaries may compromise software-as-a-service (SaaS) applications to perform various malicious activities at scale against victims. This may take the form of mass spam campaigns or large-scale phishing operations by leveraging services such as AWS Simple Notification Service (SNS) or Twilio to send text messages or emails.
With the rise of large language model (LLM) usage, services such as AWS Bedrock, Azure OpenAI, and GCP Vertex AI have become prime targets for adversaries, in an attack known as “LLMJacking.” Adversaries have reportedly sold access to these hijacked models as part of their own SaaS “business.” They will also deliver content (often illicit) to end users through services such as OAI reverse proxy, using multiple accounts to avoid service interruptions if one has their access disabled. Overall, this technique allows adversaries to sell access and pass all LLM usage costs to the victim.
How do adversaries hijack cloud services?
Typically, adversaries gain access to these cloud services through compromised valid cloud accounts. Initial access vectors vary, but typically take the form of harvested credentials that are sold from initial access brokers. Once adversaries obtain credentials for a cloud environment, they can begin reconnaissance activities. For example, for LLMjacking, they may run API commands like ListFoundationModels in AWS or query the OpenAI azure endpoint for available models.
Once the adversary has identified which models are available, they can request access or leverage existing ones if they’re enabled. In AWS this can take the form of the InvokeModel or InvokeModelWithResponseStream commands. This allows a user to prompt the model and return a response.
Regardless of the targeted service, adversaries typically follow the same behavioral patterns of compromise.
Adversaries hijack various cloud services to sell access and pass all LLM usage costs to the victim.
Defenders can take several actions to secure their environments and to quickly respond to affected cloud accounts that may have been compromised to perform service hijacking. Fortunately, the activities for hijacking are limited to specific services, which allows defenders to craft explicit Service Control Policies (SCP) that can eliminate the risk of abuse, barring total account takeover.
Prevention
Understanding the services being used in your environment is key to effective prevention. If you are not currently using a service in your business, it is wise to have an explicit deny policy in place to prevent any abuse. It is important that explicit deny policies are in place at the highest organization level possible in the environment, as any explicit deny policy will overrule an allow policy that is applied at a lower level in the environment. This will prevent adversaries from abusing these services even if they fully compromise an account in your organization.
A full blanket deny policy may not be feasible for your environment due to many factors. In this case, relying on limiting access to only those necessary (i.e., the principle of least privilege) is key. Role-based access control (RBAC) limits the vectors by which adversaries can access resources and allows for simplified logging, as you only have to monitor certain roles and services rather than numerous users. Setting conditional policies that explicitly deny except for certain roles will have similar effects as blanket deny policies.
Response
Response boils down to removing the access to the service that the adversary has gained. The simplest scenario is removing the tokens or credentials for the compromised user. If they are leveraging static, long-term keys, then this is as simple as deactivating them to prevent the access. This is only a short-term solution as adversaries typically gain methods to continue their persistence in the environment to frustrate response methods.
As with prevention, being able to conditionally deny certain users from access will allow you to prevent the adversary from continuing their activity while also limiting the business impacts if your company relies on a certain service such as Bedrock or Azure OpenAI.
For example, in AWS, if you have a role for Bedrock access and you have comprehensive user tracking with fields such as SourceIdentity, you can conditionally deny access to the role by the SourceIdentity field, which will limit the access only for that one account. An example SCP for this type of response is provided below.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"StringLike": {
"aws:SourceIdentity": [
"suspicious_user@example.com"
]
}
}
}
]
}
Cloud service logs will be the centerpiece for visibility for this activity. Most cloud environments provide a set of logs for each service they offer, which will log the various API commands that users may interact with when using the service. Commonly, these API events will be delineated between management and data events. For each service, both types of logs should be investigated for their ability to provide detection coverage. Management events will most often be enabled by default and data events will have to be enabled before you can ingest them.
For LLMjacking specifically, there are also options to enable tracking the prompts issued by the end user, which will give greater context on how the adversary is abusing the service. This may come with privacy concerns with end users. We should also note that these services can be used to share explicit content, which may be disturbing to defenders processing the logs.
Cloud service logs
Logs generated by your specific cloud service provider will provide an overview of all API interactions between the user and the service:
- In AWS, CloudTrail will generate robust logs for management events, including relevant API events for LLMjacking, which will likely have bedrock.amazonaws.com as their eventSource
- In Azure, we recommend enabling an Azure API Management Gateway as a front end to the service to greatly enhance logging capabilities. Otherwise, visibility will be greatly limited.
- For GCP, all admin activity related to Vertex AI will be stored in the audit logs. This will consist of various activities, including model execution and job creation/deletion. It is also possible to enable all “data-level” activities but this will also drastically increase the number of events, which may incur cost.
Comprehensive tracking and collection of API events across the various services is key to building a robust dataset to detect this activity. As with all security collections, it is imperative to fully understand the narrative of user behavior. Combinations of multiple log sources of all services may be critical to understanding what the adversary is trying to achieve. Fortunately, the cloud providers generally provide a central location to collect API activities across various services.
AWS
AWS CloudTrail will, by default, collect management logs from various services that adversaries may attempt to hijack. Bedrock, Simple Email Service (SES) and Simple Notification Service (SNS) all have API events present when CloudTrail is configured. These events will generally detail the activities the user performs on the control plane. It may also be possible to collect the content used in the campaigns through different configurations. For example, Bedrock allows for invocation logging, which allows for prompt content to be sent to either CloudWatch or S3. SES email content may also be collected by configuring certain domains or email addresses to ship their emails to S3 or CloudWatch as well. This may incur significant cost if the volume is high.
Azure
There are various places where logs may be stored in Azure. Log Analytics is the main, and default, method for storing API activity across Azure. For specific services, such as OpenAI, you can also find relevant logs in the AzureDiagnostics table. These logs will provide some but not all relevant information about OpenAI use in Azure. We recommend enabling ApiManagementGatewayLogs as this will allow you full visibility into all API activity surrounding the services you place behind the gateway. We have a full analysis of understanding the logs and how to collect them in our blog.
GCP
The central repository for all administrative activities is stored in the audit log. This is enabled by default and cannot be disabled. These logs will typically consist of the following information:
logName– associated project or folder ID the log was generated fromserviceName– API endpoint, for example:aiplatform.googleapis.comcallerIdentity– user information like IP address
It is also possible to expand the logging by enabling the data-level events, which expands the activity that can be collected for a specific service. As with AWS, enabling these events might incur cost as the number of events can rise drastically.
As with most cloud-based security, anomaly detection remains one of the main methods of uncovering malicious activity. Unfortunately, this is incredibly difficult in practice. Understanding your environment is key to performing any sort of anomaly detection.
For LLMjacking, if your business does not use GenAI services, then monitoring for any use of LLM models, such as InvokeModel in AWS, may be sufficient for detection and will provide high-fidelity alerts with low false positives. If Bedrock or similar services are being used in your environment, it can become more difficult to find the anomalous behavior. One method can be filtering API calls by various factors such as user agents, user types, or other indicators of compromise (IOC).
Across AWS, Azure and GCP adversaries will typically opt for long-lived credentials over short-term access.
In AWS this could take the form of InvokeModel requests with userIdentity.type of IAMUser and userIdentity.accessKeyId that starts with AKIA. This indicates a long-term credential being used to authenticate to the service. Adversaries prefer this type of access due to the long lived nature of these types of access keys. Across AWS, Azure, and GCP adversaries will typically opt for long-lived credentials over short-term access.
If the adversary compromises SES, SNS, or similar services for mass spamming campaigns, defenders can detect this through large volume differences from normal operations. Tracking typical volume counts of emails or notifications to endpoints and customers can help you detect spikes in activities that could indicate malicious activity. As with LLMjacking, you should look for anomalous user activity such as long-lived credentials usage where short-term credentials are typically used.
Any testing that is performed should be oriented toward a specific goal. You should not approach testing an alert the same way you test a prevention or security policy. For LLMjacking, testing could entail performing InvokeModel calls with an IAM user leveraging long-term credentials in AWS.
You can test for anomalous spikes in activity in threshold detections in two ways.
Lowering quotas to below your normal “baseline”
For the first, you simply have to lower the thresholds on your detections to alert within your normal business operations. By looking at historical data, if you can determine times when users typically leverage email services and then lower the quota during that time to artificially generate an alert. This can be a simple and low-effort method to verify the functionality of the alert. This should only be done for detection mechanics and not prevention, as it can disrupt normal business operations.
Automating a mock campaign
The second method is automation of a mock campaign to trigger a detection or prevention mechanism. By leveraging services such as AWS Lambda, you can connect to SNS or SES and send any number of notifications or emails using a few lines of python. You can control the number of items to send and the timeframe to various patterns to stress-test your alerts. As an added benefit, you can tie detections and automated testing together in the same way you unit-test new code. Whenever a user pushes a change to the detection, you can automatically trigger the mock campaign to verify the alert is functioning.
Security gaps? We got you.
Get curated insights on managed detection and response (MDR) services, threat intelligence, and security operations—delivered straight to your inbox every month.