Why this matters now
Long before an infostealer phones home, it watches what you copy and what you see. Modern stealers such as Lumma, RedLine, and Raccoon are documented clipboard thieves and screen grabbers: they read the clipboard for passwords, seed phrases, and cryptocurrency wallet addresses, and they screenshot the desktop to capture what never reaches the clipboard at all — open documents, banking sessions, two-factor codes displayed on screen, and password-manager windows. The theft is quiet, needs no privilege escalation, and uses documented Windows APIs that legitimate software also uses, which is why it survives in environments that block the louder techniques.
This hunt matters because clipboard and screenshot capture is an early-collection signal. Catch it and you interrupt the theft before exfiltration; miss it and your next alert is a credential-stuffing wave, a drained wallet, or a session hijack using tokens the stealer screenshotted. The same behaviour shows up in the run-up to ransomware too — see Hunting Data Theft Before the Ransom Note — because stealers are frequently the first stage of a longer intrusion.
There is no single event ID that says "clipboard stolen." Windows does not log clipboard reads to the Security log, and Sysmon has no dedicated clipboard event. This is a behaviour hunt built from process telemetry, API-adjacent signals, file writes, and network connections, correlated together. Any one signal alone is noisy; the combination is not.
The technique, step by step
In MITRE ATT&CK terms, this is two Collection techniques: T1115, Clipboard Data, and T1113, Screen Capture. Infostealers typically run both in the same session, and hunting them together is what separates a real hit from background noise.
Stage 1: Clipboard polling and hijacking
The stealer opens the clipboard with the documented OpenClipboard and GetClipboardData APIs, reads its contents, and repeats on a short polling loop or via a clipboard-format listener. Two variants matter. The passive variant simply copies whatever is there — passwords copied from a manager, text from a document, a wallet address. The active variant, clipboard hijacking, watches for a cryptocurrency address pattern and silently replaces it with the attacker's address, so the victim pastes the wrong destination into a transfer. Lumma is publicly documented doing exactly this kind of clipboard manipulation.
Stage 2: Screenshot capture
Alongside the clipboard loop, the stealer captures the screen using the standard BitBlt and GetDC graphics APIs — the same calls screenshot tools use. Captures are typically written to disk as PNG or JPG files under a temporary or application-data folder, sometimes one file per capture, sometimes overwritten on each cycle. A screenshot taken seconds after a clipboard read, by the same process, is one of the strongest correlations in this hunt.
Stage 3: Staging and exfiltration
Captured text and images are staged — often in the same temporary folder — then compressed or bundled with the stealer's other loot (browser credentials, cookies, session tokens, as covered in Hunting Token Theft via Microsoft Teams Message Exfiltration) and sent to attacker infrastructure. The exfiltration channel is usually plain HTTPS to a new or rarely seen domain, from a process that has no legitimate reason to browse.
Why legitimate software makes this hard
Clipboard managers, remote-support tools, screenshot utilities, Office, and browsers all touch the clipboard and the screen legitimately. A hunt that flags "any process reading the clipboard" will drown you. The discriminators are: an unusual process doing it (a freshly dropped executable, a script host, a LOLBin child), high-frequency polling, clipboard reads paired with screenshot file writes, and network connections to new destinations shortly after. Baseline your known-good clipboard and screenshot tools first, then hunt everything else.
Hunt 1: Clipboard readers that are not your known tools (Defender KQL)
Defender for Endpoint does not expose a clipboard-read event directly, so hunt the surrounding behaviour: processes with clipboard-adjacent characteristics — script hosts, unsigned or newly created binaries, and LOLBins — spawning from unusual parents, combined with screenshot file writes and outbound connections. Start with processes that write image files to temporary folders, a classic screenshot-staging pattern, then pivot to their parents and network activity.
DeviceFileEvents
| where ActionType == "FileCreated"
| where FolderPath has @"\AppData\Local\Temp\" or FolderPath has @"\AppData\Roaming\"
| where FileName endswith ".png" or FileName endswith ".jpg" or FileName endswith ".jpeg"
| where InitiatingProcessFileName !in~ ("SnippingTool.exe", "SnipSketch.exe", "explorer.exe", "chrome.exe", "msedge.exe", "firefox.exe", "Teams.exe", "OneDrive.exe")
| summarize ScreenshotWrites = count(), FirstSeen = min(Timestamp), LastSeen = max(Timestamp),
Processes = make_set(InitiatingProcessFileName), Devices = make_set(DeviceName)
by InitiatingProcessFileName, FolderPath
| where ScreenshotWrites >= 3
| order by ScreenshotWrites desc
Three or more screenshot writes from one process outside your allowlist is worth a look; ten or more, on a tight interval, is worth an incident. The allowlist above is a starting point — replace it with the screenshot tools your estate actually uses, and treat anything that survives the filter as a lead, not a verdict.
Hunt 2: The clipboard-to-network correlation (Defender KQL)
The strongest single query in this playbook joins the staging behaviour to exfiltration: a process that writes image files and then connects out to a destination it has never contacted before. New-destination logic is the filter that kills most false positives, because legitimate screenshot tools do not suddenly start uploading to unknown hosts.
let ScreenshotWriters =
DeviceFileEvents
| where ActionType == "FileCreated"
| where FileName endswith ".png" or FileName endswith ".jpg"
| where FolderPath has @"\Temp\" or FolderPath has @"\AppData\"
| summarize by DeviceId, InitiatingProcessFileName;
DeviceNetworkEvents
| where InitiatingProcessFileName in (ScreenshotWriters)
| where isnotempty(RemoteUrl)
| summarize FirstConnection = min(Timestamp), ConnectionCount = count(), Destinations = make_set(RemoteUrl)
by DeviceId, DeviceName, InitiatingProcessFileName, RemoteUrl
| where ConnectionCount <= 10
| order by FirstConnection desc
Filter the results against your proxy and firewall allowlists. A screenshot-writing process connecting to a newly registered or rarely seen domain, especially within minutes of the file writes, is your triage queue. Cross-check the destination against threat intelligence before concluding — but do not wait for a blocklist hit to start triage, because stealer infrastructure rotates fast.
Hunt 3: The same behaviour in Splunk (SPL)
In Splunk, Sysmon gives you the same three legs: process creation (EventCode 1), file creation (EventCode 11), and network connections (EventCode 3). The query below finds processes creating image files in temporary locations, then joins their network connections in the same window.
index=windows EventCode=11 (TargetFilename="*\\Temp\\*.png" OR TargetFilename="*\\Temp\\*.jpg" OR TargetFilename="*\\AppData\\*.png")
| stats count as ScreenshotWrites, values(Image) as Processes, values(Computer) as Hosts by Image, TargetFilename
| where ScreenshotWrites >= 3
| join type=left Image [
search index=windows EventCode=3
| stats values(DestinationHostname) as Destinations, count as NetConnections by Image, Computer
]
| table Computer, Image, ScreenshotWrites, NetConnections, Destinations
| sort - ScreenshotWrites
As with the KQL, maintain an allowlist of legitimate screenshot and screen-sharing tools for your estate and filter them out before triaging. The residual — an unknown binary writing screenshots and connecting out — is the same lead in either stack. For the credential-theft family this belongs to, the triage discipline in Hunting LSASS Credential Dumping applies: assume the credentials are already gone until you prove otherwise.
Triage: five questions before you call it
1. What process, and where did it come from? Check the parent process, the binary's path, its first-seen date on the host, and whether it is signed. A stealer dropped by a phishing attachment or a cracked-software installer will usually be young, unsigned, and living in Downloads, Temp, or AppData.
2. What was in the clipboard and on screen? You cannot replay the victim's clipboard from telemetry, but you can reconstruct exposure: was a password manager open, was a crypto wallet or banking tab active, was a document with credentials on screen? Ask the user what they copied in the window — that answer sets the rotation scope.
3. Did anything leave the host? Check proxy and firewall logs for the process's destinations in the minutes after the screenshot writes. A connection to a new domain with a POST of staged data is confirmation; no connection means you may have caught it pre-exfiltration.
4. What else did the process touch? Stealers rarely do one thing. Check the same process for browser credential-store access, cookie and token theft, and persistence mechanisms — Run keys, scheduled tasks, or startup-folder drops. One technique confirmed means the whole host is in scope.
5. Is it one host or many? Search the same process name, hash, and destination across the estate. Infostealers delivered by malvertising or phishing often land on several hosts at once, and the hosts you find second are the ones that have not been noticed yet.
Remediation and hardening
Isolate the host first, then remove the binary and any persistence it created — Run keys, scheduled tasks, and startup entries. Rotate every credential the victim plausibly copied or displayed during the window: passwords, session tokens, and any cryptocurrency wallet whose address could have been swapped in the clipboard. For wallet exposure, treat a swapped address as a live theft risk and move funds to a fresh wallet immediately rather than waiting for a fraudulent transaction to confirm it.
Clear the clipboard on affected hosts and push the habit estate-wide: password managers with auto-clear, and clipboard-history policies that limit retention, reduce what a stealer can grab in the first place. Block or alert on unsigned binaries writing image files to Temp and AppData folders, and alert on first-seen destinations contacted by processes that write screenshots — that detection is the durable version of Hunts 1 and 2, and it survives the next stealer rebrand.
Finally, feed the finding back into your allowlist. Every legitimate screenshot tool you baseline today is one fewer false positive tomorrow, and the cleaner that baseline is, the faster the next clipboard thief stands out.
