APromptRiskDBThreat intelligence atlas
AI Case Study

AIKatz: Attacking LLM Desktop Applications - AI Case Study

Researchers at Lumia have demonstrated that it is possible to extract authentication tokens from the memory of LLM Desktop Applications. An attacker could then use those tokens to impersonate as the victim to the LLM backed, thereby gaining access to the victim’s conversations as well as the ability to interfere in future conversations. The attacker’s access would allow them the ability to directly inject prompts...

ExerciseLLM Desktop Applications (Claude, ChatGPT, Copilot)Lumia SecurityImpactPersistenceInitial Access

Overview

Case steps13Steps described in the case record.
Techniques12Attack methods mentioned in the case steps.
Linked CVEs0Known vulnerabilities mentioned in the record.

Risk patterns

Patterns found in the case record and its linked vulnerabilities.

  • 1Dominant ATLAS tactic. Impact appears in 4 case steps.
  • 2Multiple attack methods. The case connects to 12 unique AI attack methods.

Procedure timeline

Search the case steps or filter them by attacker goal.

Impact4Persistence2Initial Access1Discovery1Credential Access1Lateral Movement1AI Model Access1Execution1Defense Evasion1
  1. Discovery

    The attacker enumerated all of the processes running on the victim’s machine and identified the processes belonging to LLM desktop applications.

  2. Credential Access

    The attacker attached or read memory directly from /proc (in Linux) or opened a handle to the LLM application’s process (in Windows). The attacker then scanned the process’s memory to extract the authentication token of the victim. This can be easily done by running a regex on every allocated memory page in the process.

  3. AI Model Access

    The attacker has now obtained the access required to communicate with the LLM backend service as if they were the desktop client. This allowed them access to everything the user can do with the desktop application.

  4. Step 6

    Direct

    Execution

    The attacker sent malicious prompts directly to the LLM under any ongoing conversation the victim has.

  5. Step 7

    Thread

    Persistence

    The attacker could craft malicious prompts that manipulate the context of a chat thread, an effect that would persist for the duration of the thread.

  6. Step 8

    Memory

    Persistence

    The attacker could then craft malicious prompts that manipulate the LLM’s memory to achieve a persistent effect. Any change in memory would also propagate to any new chat threads.

  7. Defense Evasion

    Many LLM desktop applications do not show the injected prompt for any ongoing chat, as they update chat history only once when initially opening it. This gave the attacker the opportunity to cover their tracks by manipulating the user’s conversation history directly via the LLM’s API. The attacker could also overwrite or delete messages to prevent detection of their actions.

  8. Impact

    The attacker could send spam messages while impersonating the victim. On a pay-per-token or action plans, this could increase the financial burden on the victim.

  9. Step 11

    User Harm

    Impact

    The attacker could gain access to all of the victim’s activity with the LLM, including previous and ongoing chats, as well as any file or content uploaded to them.

  10. Impact

    The attacker could delete all chats the victim has, and any they are opening, thereby preventing the victim from being able to interact with the LLM.

  11. Impact

    The attacker could spam messages or prompts to reach the LLM’s rate-limits against bots, to cause it to ban the victim altogether.

Mitigations

Defenses connected to the attack methods in this case.

Sources

Original public records and references for this case.