Overview
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.
-
Initial Access
Step 1
Valid Accounts
The attacker required initial access to the victim system to carry out this attack.
-
Discovery
Step 2
Process Discovery
The attacker enumerated all of the processes running on the victim’s machine and identified the processes belonging to LLM desktop applications.
-
Credential Access
Step 3
OS Credential Dumping
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. -
Lateral Movement
Step 4
Application Access Token
The attacker used the extracted token to authenticate themselves with the LLM backend service.
-
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.
-
Execution
Step 6
Direct
The attacker sent malicious prompts directly to the LLM under any ongoing conversation the victim has.
-
Persistence
Step 7
Thread
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.
-
Persistence
Step 8
Memory
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.
-
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.
-
Impact
Step 10
Financial Harm
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.
-
Impact
Step 11
User Harm
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.
-
Impact
Step 12
Denial of AI Service
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.
-
Impact
Step 13
Denial of AI Service
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.
Original source
Original source links
Open the MITRE ATLAS data and public references used for this case study.