A few days ago, security researcher Johann Rehberger (Embrace The Red) published a hands-on write-up building on the paper "Stealing Reasoning Traces from Proprietary LLM APIs." The research demonstrates a simple but elegant technique to recover the hidden reasoning traces — the internal chain-of-thought tokens — that providers like OpenAI and Anthropic transmit inside their messaging protocols as encrypted, base64-encoded blobs.
This matters to defenders for one uncomfortable reason: reasoning traces frequently contain the most sensitive data in the entire conversation. System prompt fragments, tool-call arguments, retrieved documents from RAG pipelines, internal user identifiers, and intermediate decisions all flow through the model's reasoning before the sanitized final answer is produced. Organizations assumed these blobs were opaque. The research shows that assumption no longer holds.
No CVE has been assigned — this is a cryptographic/design weakness technique rather than a patched vulnerability — but the defensive implications are immediate for any enterprise routing sensitive data through proprietary LLM APIs, and for any SOC responsible for detecting interception or misuse of that traffic.
Technical Analysis
How the technique works (defender's view)
Modern reasoning models (OpenAI's o-series and GPT-5-class reasoning endpoints, Anthropic's extended-thinking models) return reasoning content to clients in encrypted form so that the traces can be passed back in multi-turn conversations without being human-readable in transit at the application layer. The blob is base64-encoded and symmetrically encrypted.
The published attack, reproduced by Rehberger, exploits the practical reality that this protection is obfuscation-grade, not access control:
- The encrypted blob must be processable client-side (or recoverable from the wire). Any client, proxy, or intermediary that terminates TLS for the API session can capture the ciphertext. That includes corporate TLS-inspecting proxies, browser sessions with
SSLKEYLOGFILEenabled, and endpoint-based interception tools such as mitmproxy. - The encryption scheme can be defeated via known-plaintext and structural analysis of the reasoning stream. Because reasoning tokens follow predictable distributions and the blobs are reused across turns, the researchers demonstrated recovery of plaintext reasoning content from captured blobs without breaking the provider's infrastructure at all.
- No exploitation of the vendor is required. The "victim" is anyone whose threat model assumed reasoning traces were confidential once encrypted. An attacker positioned on an endpoint, an intercepting proxy, or with access to logged API payloads can recover the traces offline.
What is actually exposed
From an IR and data-governance perspective, treat recovered reasoning traces as capable of containing:
- Full or partial system prompts (including proprietary instructions, guardrail logic, and embedded secrets that developers mistakenly place there)
- Tool-call parameters and results — file paths, database query fragments, internal API URLs, credentials passed to function calls
- RAG-retrieved context — document excerpts that may include PII, PHI, PCI data, or intellectual property
- User identifiers and session metadata embedded in reasoning
Affected surface
- Applications consuming OpenAI reasoning models and Anthropic extended-thinking models via official APIs
- Any environment where API traffic traverses TLS-inspecting infrastructure (ZGNA/SSE stacks, DLP proxies, corporate MITM)
- Endpoints where browser-based AI sessions can be captured (SSLKEYLOGFILE abuse, endpoint interception tooling)
- Log pipelines that store raw API request/response payloads (SIEM, API gateways, observability platforms) — these now store recoverable sensitive data
Exploitation status
The technique is published and reproducible today — Rehberger's post confirms practical recovery, not a theoretical result. There is no confirmed in-the-wild campaign and no CISA KEV entry (no CVE exists). However, the barrier to weaponization is low: anyone already capturing API traffic for other purposes can now mine historical captures for reasoning traces retroactively.
Detection & Response
Realistically, you cannot signature the offline decryption itself. What you can detect are the preconditions: TLS interception of LLM API traffic, capture tooling on endpoints, anomalous access to stored API payloads, and unexpected processes talking to LLM API endpoints. These are the rules we'd deploy for clients.
Sigma
---
title: TLS Interception Tooling Execution on Endpoint
tid: 3f8a2b71-9c4d-4e6f-a1b2-7d8e9f0a1b2c
status: experimental
description: Detects execution of TLS interception/proxy capture tooling commonly used to capture encrypted API traffic, including LLM reasoning trace blobs. Also flags SSLKEYLOGFILE persistence which enables offline decryption of browser TLS sessions.
references:
- https://embracethered.com/blog/posts/2026/recovering-encrypted-llm-thoughts/
- https://attack.mitre.org/techniques/T1557/002/
author: Security Arsenal
date: 2026/06/15
tags:
- attack.credential_access
- attack.t1557.002
- attack.collection
logsource:
category: process_creation
product: windows
detection:
selection_tools:
Image|endswith:
- '\mitmproxy.exe'
- '\mitmdump.exe'
- '\mitmweb.exe'
- '\fiddler.exe'
selection_keylog:
CommandLine|contains:
- 'SSLKEYLOGFILE'
condition: selection_tools or selection_keylog
falsepositives:
- Authorized proxy debugging by developers and network teams
level: high
---
title: Unexpected Process Connecting to LLM API Endpoints
id: 8c1d4e52-2b6a-4f89-b3c4-5e6f7a8b9c0d
status: experimental
description: Detects network connections to OpenAI or Anthropic API endpoints from processes other than approved client applications or browser sessions, which may indicate credential theft, payload harvesting, or replay of captured reasoning traces.
references:
- https://embracethered.com/blog/posts/2026/recovering-encrypted-llm-thoughts/
- https://attack.mitre.org/techniques/T1041/
author: Security Arsenal
date: 2026/06/15
tags:
- attack.exfiltration
- attack.t1041
logsource:
category: network_connection
product: windows
detection:
selection_hosts:
DestinationHostname|contains:
- 'api.openai.com'
- 'api.anthropic.com'
filter_approved:
Image|endswith:
- '\msedge.exe'
- '\chrome.exe'
- '\firefox.exe'
- '\python.exe'
- '\node.exe'
condition: selection_hosts and not filter_approved
falsepositives:
- Custom internal integrations not yet on the approved process list
level: medium
KQL (Microsoft Sentinel / Defender)
This hunt surfaces endpoints generating unusual volumes of LLM API traffic from non-browser processes — the profile of scripted harvesting of responses (and their embedded reasoning blobs) using stolen or misused API keys.
// Hunt: Anomalous LLM API egress from non-standard processes
// Tune ApprovedProcesses to your environment's sanctioned AI clients
let ApprovedProcesses = dynamic(["msedge.exe","chrome.exe","firefox.exe","python.exe","node.exe","cursor.exe","code.exe"]);
DeviceNetworkEvents
| where TimeGenerated > ago(7d)
| where RemoteUrl has_any ("api.openai.com","api.anthropic.com")
| extend IsApproved = InitiatingProcessFileName in~ (ApprovedProcesses)
| summarize ConnectionCount = count(),
DistinctRemoteIPs = dcount(RemoteIP),
FirstSeen = min(TimeGenerated),
LastSeen = max(TimeGenerated)
by DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine, IsApproved
| where IsApproved == false or ConnectionCount > 500
| order by ConnectionCount desc
Also hunt your proxy and firewall logs (ingested as CommonSecurityLog) for TLS-inspection bypass events or certificate errors on LLM API destinations — attackers decrypting captured streams often trigger certificate pinning failures in SDK clients:
// Hunt: TLS errors / inspection events against LLM API endpoints
CommonSecurityLog
| where TimeGenerated > ago(7d)
| where DestinationHostName has_any ("api.openai.com","api.anthropic.com")
or RequestURL has_any ("api.openai.com","api.anthropic.com")
| where DeviceAction !in~ ("Allow","Allowed","accept")
or Message has_any ("certificate","ssl","tls","decrypt")
| summarize EventCount = count() by SourceIP, DestinationHostName, DeviceAction, Message
| order by EventCount desc
Velociraptor VQL
This artifact enumerates live connections to LLM API infrastructure alongside installed interception tooling and SSLKEYLOGFILE configuration — a quick triage sweep when you suspect trace capture on an endpoint.
-- Hunt: LLM API connections, interception tooling, and TLS key logging on endpoints
SELECT Pid, Name, Path AS ExePath, CommandLine
FROM pslist()
WHERE Name =~ '(?i)mitm|fiddler|wireshark|tshark|charles|burp'
OR CommandLine =~ '(?i)SSLKEYLOGFILE'
// Correlate with live connections to LLM API infrastructure
SELECT Pid, Name, Family, Type, Laddr, Lport, Raddr, Rport, Status
FROM netstat()
WHERE Status =~ 'ESTABLISHED'
AND (Raddr =~ '^104\.18\.' OR Raddr =~ '^160\.79\.' OR Raddr =~ '^34\.' OR Raddr =~ '^52\.')
(Note: LLM providers sit behind major CDNs, so the netstat filter is heuristic — enrich with DNS resolution history via SELECT * FROM parse_dns_cache() where available, or join against your DNS query logs for api.openai.com / api.anthropic.com lookups prior to connection establishment.)
Endpoint Hardening / Verification Script
Use this PowerShell script to audit endpoints for the preconditions of trace capture: TLS key logging, recently added root certificates (rogue proxy CAs), and interception tooling. Run via your RMM or as a scheduled audit.
# Security Arsenal - LLM Trace Capture Precondition Audit
# Checks: SSLKEYLOGFILE, interception tools, recent root CA additions
$findings = @()
# 1. Check for SSLKEYLOGFILE environment variables (user + machine scope)
foreach ($scope in 'User','Machine') {
$val = [Environment]::GetEnvironmentVariable('SSLKEYLOGFILE', $scope)
if ($val) {
$findings += [pscustomobject]@{ Check='SSLKEYLOGFILE'; Detail="$scope scope -> $val"; Severity='High' }
}
}
# 2. Check running processes and installed binaries for interception tooling
$toolPattern = 'mitmproxy|mitmdump|mitmweb|fiddler|charles|burp'
Get-Process | Where-Object { $_.Name -match $toolPattern } | ForEach-Object {
$findings += [pscustomobject]@{ Check='InterceptTool-Running'; Detail="$($_.Name) (PID $($_.Id))"; Severity='High' }
}
# 3. Root CA certificates added in the last 90 days (rogue proxy CA indicator)
$cutoff = (Get-Date).AddDays(-90)
Get-ChildItem Cert:\LocalMachine\Root | Where-Object { $_.NotBefore -gt $cutoff } | ForEach-Object {
$findings += [pscustomobject]@{ Check='RecentRootCA'; Detail="$($_.Subject) | $($_.Thumbprint)"; Severity='Medium' }
}
# 4. Report
if ($findings.Count -eq 0) {
Write-Host "[+] No trace-capture preconditions detected on $env:COMPUTERNAME" -ForegroundColor Green
} else {
$findings | Format-Table -AutoSize
$findings | Export-Csv -Path "$env:TEMP\llm_trace_audit_$env:COMPUTERNAME.csv" -NoTypeInformation
Write-Host "[!] $($findings.Count) finding(s) exported to $env:TEMP\llm_trace_audit_$env:COMPUTERNAME.csv" -ForegroundColor Yellow
}
# 5. Remediate: remove SSLKEYLOGFILE if found (uncomment to enforce)
# [Environment]::SetEnvironmentVariable('SSLKEYLOGFILE', $null, 'User')
# [Environment]::SetEnvironmentVariable('SSLKEYLOGFILE', $null, 'Machine')
Remediation
Because this is a design-level technique with no patch, remediation is about reducing what reasoning traces can expose and controlling who can capture API traffic:
- Purge secrets from system prompts and tool schemas. Audit every system prompt, function definition, and tool description your organization sends to reasoning models. Assume anything in the request context can end up in a recoverable reasoning trace. Rotate any credentials ever embedded in prompts.
- Minimize sensitive data in RAG context. Apply redaction/tokenization to PII, PHI, and PCI data before retrieval results are injected into model context. If your compliance scope (HIPAA, PCI-DSS) assumed reasoning blobs were unreadable, reassess that assumption in your data-flow documentation.
- Restrict and monitor API payload logging. If your API gateway, observability stack, or DLP tooling stores raw request/response bodies, those stores now contain recoverable sensitive data. Encrypt at rest, restrict access, shorten retention, and alert on bulk reads.
- Control TLS inspection of AI traffic. Inventory which proxies inspect traffic to
api.openai.comandapi.anthropic.com. Where inspection isn't required, bypass it. Where it is, treat the inspection tier as a high-value target and audit its logs. - Harden endpoints against session capture. Block
SSLKEYLOGFILEvia policy, alert on new root CA installations, and restrict interception tooling to approved security/network staff (detections above). - Watch vendor guidance. Monitor OpenAI and Anthropic security advisories for protocol changes to reasoning trace handling (encryption upgrades, trace redaction options, or enterprise controls to disable trace return entirely). If your use case doesn't require multi-turn trace persistence, prefer configurations that don't return encrypted reasoning items.
- Update your threat model and IR playbooks. Add "reasoning trace recovery" as a data-exposure scenario. If an endpoint or proxy with AI traffic visibility is compromised, scope the incident to include reasoning trace contents, not just final outputs.
Related Resources
Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.