Case study banner: Singapore Logistics Group Suffers LLMjacking by Threat Actors. Type: IR-1 Incident Response.

LLMjacking: Attacker Seizes Singapore Logistics Group's Cloud Access to Steal AI Compute

LAST EDITED:
PUBLISHED:
August 3, 2026

The credential surfaced on a criminal marketplace a month earlier and nobody knew. One live session was all the attacker needed to reach administrator rights.

Key facts

Organisation
Singapore logistics group
Threat
Cloud account takeover and theft of AI compute, a pattern known as LLMjacking
Initial access
Reuse of a live login session; assessed as infostealer malware on an unmanaged device
Impact
No data taken, no malware deployed, no persistence left behind
Core issue
A development environment held administrative rights that production refused

What this case shows

  • Multi-factor authentication stops a login. It does not stop an attacker who arrives with a session that has already been approved.
  • Attackers have started stealing artificial-intelligence capacity the way they once stole capacity for cryptocurrency, which widens the target list to anyone with a large cloud bill.
  • Least privilege protects the projects where somebody actually applied it, and nothing else.

Understand what a rebuilt endpoint costs an investigation, and what a preserved one buys, in our work on digital forensics, or talk to us about IR-1 response assurance.

What this would have cost without Blackpanda IR-1 in place

ODIRIR-1
Type of engagementOn-demand incident responseYearly subscription
Hours covered30 hoursUnlimited*
Pricing1USD $15,000USD $1,500

* Unlimited for one incident per year

1 Ad-hoc incident response pricing based on average market rates, from USD 500 per hour. Blackpanda IR-1 subscription pricing based on no. of endpoints, costing approx. 10x less than ad-hoc and retainer-based incident response. All figures are illustrative only, for guidance and marketing purposes and not to be relied upon by the reader. Actual incident response costs vary by scope, complexity, and provider.

CHALLENGE

The organisation runs almost everything in the cloud. Over the years, engineering teams across the global business established hundreds of projects under a single corporate account, creating an expansive, decentralised cloud environment that has become too complex to fully track or manage. This also means the security of the whole rests on whichever project is weakest.

In June 2026, within one of those projects, the infrastructure team discovered unauthorised elements, which included unrequested access keys, service accounts, and a virtual machine large enough to stand out on a billing report. The team revoked all of the elements that morning, stopped the machine, then activated its Blackpanda IR-1 subscription. None of it looked like ransomware or data theft. What the team had pulled down was the start of an attempt to run artificial intelligence on the company's account, LLMjacking as the industry now calls it.

The organisation could not see how the intruder got in. No failed nor successful login appeared in the records, and no employee had approved a multi-factor prompt by mistake. But the attacker was found to have arrived holding a live session, the trusted state that a service maintains for an individual who has already signed in, giving them access without further gates.

Blackpanda later traced the credential to a criminal marketplace, where it had been offered a month earlier, in May 2026. Nobody at the company knew, which is how a credential compromise usually behaves in the weeks before the stolen credential is used.

SOLUTION

1. Scope the whole estate, not the project that raised the alarm

Blackpanda pulled data-access logs across the entire cloud footprint rather than the one project where the artefacts had surfaced. Activity appeared in four projects out of hundreds. Two of those saw nothing beyond billing queries, which sounds harmless, until you ask why an intruder reads a billing page. It is working out how much compute it can burn before anyone notices.

2. Prove how the account was used, not merely that it was

The audit trail answered the question of initial access through an absence. Reconnaissance ran under the employee's identity, yet the identity logs held no matching sign-in anywhere, no password entry, and no multi-factor challenge. That gap is the evidence; it established session reuse rather than authentication, and it told the team that resetting the password on its own would have left the door open.

3. Take the rogue machine apart before it disappears

Blackpanda imaged the virtual machine's disk and examined it. Nothing was on it. No malware, no post-exploitation tooling, no persistence mechanism, no data staged and waiting to leave, and no cryptocurrency mining software either. The machine had run for roughly nine hours and never received a payload.

4. Ask the outside world what the rebuilt laptop could not answer

The employee's device had been reimaged before anyone collected evidence from it, so the artefacts that would have proved the initial-access method were gone. Blackpanda turned to dark-web and infostealer datasets instead. The captured password matched nothing in earlier collections, which points to a fresh infection rather than recycled data, and the same sweep surfaced over 10 other corporate accounts exposed the same way.

RESULTS

1. Containment verified against the logs

Blackpanda checked every containment action the team had taken against the audit record and confirmed the whole response closed inside two hours, from the first revocation to the machine being stopped.

2. Nothing left the environment

Forensic examination found no data staged on the rogue host and no evidence of exfiltration anywhere across the four affected projects.

3. The attacker's own infrastructure identified

One attacker-controlled account repeatedly checked the billing of a cloud project the group confirmed does not exist in its environment, which made that project attributable to the attacker and reportable to the provider's abuse team.

4. Production held, and proved why

Every write the attacker attempted in production failed, including an identical oversized machine, a new access-policy binding and an attempt to enumerate accounts. The hijacked identity held nothing there beyond viewer and billing rights, so each request came back denied.

5. Four enabling conditions documented

The investigation named what made the intrusion possible — outside identities accepted as valid principals, a broad administrative group able to rewrite access policy unchecked, freely creatable long-lived access keys, and machines permitted public addresses. Each one is a configuration decision rather than a defect.

Nothing in this incident needed a new class of attack. The intruder used an ordinary stolen session, ordinary administrative rights and ordinary cloud features, and the damage stopped where it did because one environment had been built to assume compromise while another had not. That is the part worth carrying upstream. Least privilege is not a posture an organisation holds in general; it is a setting, applied project by project, and it defends precisely the projects where someone bothered to apply it.

FREQUENTLY ASKED QUESTIONS

1. We have multi-factor authentication switched on. How did this happen?

Because the attacker never authenticated. It arrived holding a session that had already been approved, and a valid session is not challenged again. MITRE catalogues this as Web Session Cookie (T1550.004), noting that stolen session material bypasses some multi-factor protections precisely because the session is already authenticated.

2. Would phishing-resistant multi-factor authentication have prevented it?

It closes a different door, and it is still worth the migration. CISA's guidance on implementing phishing-resistant MFA treats hardware keys and certificate-based methods as the strongest form available and urges organisations to prioritise moving to them, because those methods cannot be phished or replayed at the point of login. What they cannot do is protect a session cookie after it has been issued. Session-theft defences have to sit alongside them, meaning shorter session lifetimes, revocation on demand, and monitoring on every device that reaches the cloud console.

3. Why would an attacker want our cloud account if it isn't after our data?

Because compute is worth money. Switching on the AI service, generating keys against it and standing up an oversized machine all point to an attempt to consume artificial-intelligence capacity on someone else's account and resell it, which the security industry calls LLMjacking. The bill lands with the victim, which is also why the attacker kept reading billing pages.

4. Our development projects are looser than production. Is that really a problem?

Here it was the entire problem. Production held and development did not, and the difference came down to the access model each environment had been handed, not to the attacker's skill. If your non-production projects grant administrative rights that production would refuse, they are the route into your estate.

5. The laptop was rebuilt before anyone examined it. Does that matter?

Yes, and it is among the most common ways an investigation loses its answer. Rebuilding the device destroyed the artefacts that would have proved how the session was stolen, which is why the initial access in this case remains an assessment rather than a confirmed finding. Preserving the endpoint, or simply imaging it first, costs an hour and buys the root cause.

6. How would we know whether this has already happened to us?

Session reuse leaves a specific signature, activity under an identity with no matching sign-in event, and finding it depends on data-access logging being switched on across every project rather than the ones you remember owning. A compromise assessment hunts for exactly that kind of evidence, and it earns its keep when a cloud estate has grown faster than the inventory describing it. Blackpanda has investigated the same session-theft mechanism inside a Singapore IT services firm's email environment.

WHAT THIS MEANS FOR YOUR ORGANISATION

Two things about this case travel well beyond it. The first is that large cloud estates now outgrow the inventories meant to describe them, and an attacker needs only the one project nobody watches. The second is newer and deserves attention from anyone budgeting for cloud. Attackers have begun stealing capacity for artificial intelligence much as they once stole it for cryptocurrency, and that changes who counts as a target. Any organisation whose cloud spend is large enough to hide someone else's consumption inside it is now worth breaking into, whatever its data happens to be worth.

The practical response is unglamorous. Apply the access model you trust in production to every project you own, revoke sessions and tokens instead of only resetting passwords, and monitor the devices that reach your cloud console, because that is where a session is stolen. Speed decides the rest. This group had a responder to call the morning it found the artefacts, which is the difference between an incident that ends the same day and one that runs for weeks, and it is what an IR-1 response assurance subscription exists to put in place before the morning arrives.

ABOUT BLACKPANDA

Blackpanda is a Lloyd's of London–accredited insurance coverholder and Asia's leading local cyber incident response firm, delivering end-to-end digital emergency support across the region. We are pioneering the A2I (Assurance-to-Insurance) model in cybersecurity — uniting preparation, response, and insurance into a seamless pathway that minimises financial and operational impact from cyber attack. Through expert consulting services, response assurance subscriptions, and innovative cyber insurance, we help organisations get ready, respond, and recover from cyber attacks — all delivered by local specialists working in concert.

Our mission is clear: to bring complete cyber peace of mind to every organisation in Asia, from the first moment of breach through full recovery and beyond.