T1113 Google Chronicle · YARA-L

Detect Screen Capture in Google Chronicle

Adversaries may attempt to take screen captures of the desktop to gather information over the course of an operation. Screen capturing functionality may be included as a feature of a remote access tool used in post-compromise operations. Taking a screenshot is also typically possible through native utilities or API calls, such as CopyFromScreen (.NET), xwd (Linux), or screencapture (macOS). Threat actors including Dragonfly, Gamaredon (Pteranodon), APT33 (TURNEDUP), Agent Tesla, and BlackEnergy have all used screen capture as part of post-compromise collection operations.

MITRE ATT&CK

Tactic
Collection
Technique
T1113 Screen Capture
Canonical reference
https://attack.mitre.org/techniques/T1113/

YARA-L Detection Query

Google Chronicle (YARA-L)
yaral
rule t1113_screen_capture_process {
  meta:
    author = "Argus Detection Engineering"
    description = "Detects MITRE ATT&CK T1113 screen capture via known utilities from suspicious parents or scripting engines using screenshot APIs"
    mitre_attack_technique = "T1113"
    mitre_attack_tactic = "Collection"
    severity = "MEDIUM"
    confidence = "MEDIUM"
    version = "1.0"

  events:
    $e.metadata.event_type = "PROCESS_LAUNCH"
    (
      // Branch 1: Known screenshot tool launched from suspicious scripting parent
      (
        (
          re.regex($e.target.process.file.full_path,
            `(?i)(scrot|xwd|gnome-screenshot|ksnapshot|spectacle|screencapture|psr\.exe|snippingtool\.exe|snipingtool\.exe|screenshot\.exe|xrandr)`) or
          re.regex($e.target.process.command_line,
            `(?i)(CopyFromScreen|GetDC|BitBlt|PrintWindow|xwd\s+-root|scrot\s+|screencapture\s+|xrandr\s+--screenshot)`)
        ) and
        re.regex($e.principal.process.file.full_path,
          `(?i)(cmd\.exe|powershell\.exe|pwsh\.exe|wscript\.exe|cscript\.exe|mshta\.exe|regsvr32\.exe|rundll32\.exe|svchost\.exe)`)
      ) or
      // Branch 2: Scripting engine invoking screenshot .NET or Win32 APIs
      (
        re.regex($e.target.process.file.full_path,
          `(?i)(powershell\.exe|pwsh\.exe|cscript\.exe|wscript\.exe|mshta\.exe)`) and
        re.regex($e.target.process.command_line,
          `(?i)(CopyFromScreen|System\.Drawing\.Graphics|System\.Windows\.Forms\.Screen|Graphics\.CopyFromScreen|PrintWindow|VK_SNAPSHOT|keybd_event|0x2C)`)
      )
    )

  condition:
    $e
}

rule t1113_screen_capture_file_staging {
  meta:
    author = "Argus Detection Engineering"
    description = "Detects suspicious image file creation in temp/staging paths by non-UI processes, indicating screenshot staging for exfiltration (T1113)"
    mitre_attack_technique = "T1113"
    mitre_attack_tactic = "Collection"
    severity = "MEDIUM"
    confidence = "MEDIUM"
    version = "1.0"

  events:
    $e.metadata.event_type = "FILE_CREATION"
    re.regex($e.target.file.full_path, `(?i)\.(png|jpg|jpeg|bmp|gif)$`)
    re.regex($e.target.file.full_path,
      `(?i)(\\Temp\\|\\AppData\\Local\\Temp\\|\\ProgramData\\|\\Users\\Public\\|/tmp/|/var/tmp/)`)
    not re.regex($e.principal.process.file.full_path,
      `(?i)(explorer\.exe|chrome\.exe|firefox\.exe|msedge\.exe|iexplore\.exe|outlook\.exe|teams\.exe|slack\.exe|zoom\.exe|mspaint\.exe|photoshop\.exe|gimp\.exe|OneDrive)`)

  condition:
    $e
}
medium severity medium confidence

Two Chronicle YARA-L 2.0 rules targeting T1113 Screen Capture. Rule 1 (t1113_screen_capture_process) fires on PROCESS_LAUNCH events where a known screenshot utility (scrot, xwd, psr.exe, screencapture, snippingtool.exe) is launched from a suspicious scripting parent, or where a scripting engine command line references CopyFromScreen, PrintWindow, or VK_SNAPSHOT APIs. Rule 2 (t1113_screen_capture_file_staging) fires on FILE_CREATION events where an image file is written to a staging path by a process that is not a known UI or browser application.

Data Sources

Google Chronicle Security OperationsWindows endpoint logs via Chronicle forwarder agentEDR telemetry normalized to Chronicle UDM

Required Tables

UDM events with event_type PROCESS_LAUNCHUDM events with event_type FILE_CREATION

False Positives & Tuning

  • Authorized red team or penetration testing tooling (Cobalt Strike screenshot beacon, Metasploit screengrab module) during sanctioned engagements that will trigger the scripting engine API branch
  • Enterprise screen recording or video conferencing software (Zoom local recording, Microsoft Teams background blur) that creates intermediate image frames in temp directories during meetings
  • Batch image processing or document conversion pipelines (ImageMagick, LibreOffice headless) that write PNG/JPEG output to /tmp or %TEMP% as part of standard document rendering workflows

Other platforms for T1113


Testing Methodology

Validate this detection against 5 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.

  1. Test 1 Windows Screen Capture via PowerShell CopyFromScreen

    Expected signal: Sysmon Event ID 1: Process Create — Image=powershell.exe, CommandLine containing 'CopyFromScreen', 'System.Drawing.Graphics', 'System.Windows.Forms.Screen'. Sysmon Event ID 11: File Create — TargetFilename=C:\Users\<user>\AppData\Local\Temp\df00tech-capture.png, Image=powershell.exe. PowerShell ScriptBlock Log Event ID 4104 with full script content. Sysmon Event ID 7: Image Load — gdi32.dll loaded by powershell.exe.

  2. Test 2 Windows Screen Capture via PSR.exe (Problem Steps Recorder)

    Expected signal: Sysmon Event ID 1: Process Create — Image=C:\Windows\System32\psr.exe, CommandLine containing '/start /output ... /sc 1 /maxsc 5'. Second Event ID 1 for the /stop invocation. Sysmon Event ID 11: File Create — TargetFilename ending in .zip in TEMP path, created by psr.exe. Security Event ID 4688 (if command line auditing enabled) for psr.exe execution.

  3. Test 3 Linux Screen Capture via xwd (X Window Dump)

    Expected signal: Linux auditd syscall log: execve syscall for xwd with arguments '-root -silent -out /tmp/df00tech-capture.xwd'. File creation event in /tmp/. Syslog entry if auditd is configured with -a always,exit -F arch=b64 -S execve rule. Process accounting record for xwd execution. /var/log/auth.log may show the user context.

  4. Test 4 macOS Screen Capture via screencapture Utility

    Expected signal: macOS Unified Log: log show --predicate 'process == "screencapture"' will show the invocation. Endpoint security framework (ESF) event for ES_EVENT_TYPE_NOTIFY_EXEC for screencapture. File creation event in /tmp/ for the PNG file. If Defender for Endpoint macOS agent is deployed: DeviceProcessEvents with FileName=screencapture and DeviceFileEvents for the output file.

  5. Test 5 Windows VK_SNAPSHOT Keyboard Simulation Screenshot

    Expected signal: Sysmon Event ID 1: Process Create — Image=powershell.exe, CommandLine containing 'keybd_event', '0x2C', 'VK_SNAPSHOT'. PowerShell ScriptBlock Log Event ID 4104 with full P/Invoke code. Sysmon Event ID 7: Image Load — user32.dll loaded by powershell.exe. Sysmon Event ID 11: File Create for .png in TEMP if clipboard contained image data.


Response Playbook

Triage

  1. Identify the process taking screenshots — is it a known RAT/malware signature (Pteranodon, Agent Tesla, Pupy) or a legitimate tool? Check the binary hash against VirusTotal or internal threat intel.
  2. Determine the parent process chain — was the screenshot process spawned by a browser, document viewer (mshta.exe, wscript.exe), or Office application? Office-spawned screenshot processes are near-certain malicious.
  3. Review the screenshot file destination path — malware often writes to staging paths like \ProgramData\Mail\MailAg\, \AppData\Roaming\, or \Temp\. Legitimate tools write to user-selected paths (Desktop, Pictures).
  4. Check for a file creation followed by a network connection from the same process — screenshots staged then immediately exfiltrated via HTTP/FTP/DNS indicate active data collection and exfiltration.
  5. Assess cadence — was this a single screenshot or a recurring pattern? Query DeviceFileEvents for the past 24h scoped to the same process to detect periodic captures (e.g., every 30 seconds like Ramsay).
  6. Check user context — is this a service account, a headless server session (RDP/console), or a shared account? Automated screenshot activity on servers or service accounts with no interactive sessions is highly suspicious.
  7. Review the command line for interval/loop flags — e.g., scrot with a sleep loop, PowerShell with a Timer, or xwd in a while loop — indicating an automated collection campaign rather than a one-time action.

Containment

  1. If active RAT/malware confirmed: immediately isolate the endpoint from the network via EDR isolation or VLAN quarantine to prevent screenshot exfiltration to C2.
  2. Terminate the malicious process and its parent process tree — use EDR process kill capability or Task Manager with attention to preserving memory dump for forensics before termination.
  3. Revoke the compromised user's active sessions, OAuth tokens, and reset credentials — screenshot capture during an active session can expose credentials, MFA codes, and sensitive data.
  4. Block the malicious binary's hash at the EDR policy layer and any C2 IPs/domains identified in network telemetry at the firewall and DNS sinkhole.
  5. If screenshots were already staged in a shared path or network share, restrict access to those paths and audit who else accessed the directory to assess lateral exposure.
  6. Preserve staged screenshot files as forensic evidence before containment actions remove them — they reveal what the adversary saw and help scope the data exposure.

Evidence Collection

  1. Screenshot files themselves — capture all .png/.jpg/.bmp files from staging paths (\ProgramData\, \Temp\, \AppData\) as they reveal what the adversary observed and helps scope data exposure.
  2. Sysmon Event ID 1 (Process Create) — full command line, parent process, user, timestamp of the screenshot process execution.
  3. Sysmon Event ID 11 (File Create) — timestamp, target file path, and initiating process for each screenshot file written.
  4. Sysmon Event ID 3 (Network Connection) — any network connections from the screenshot process to external IPs immediately after file creation indicate exfiltration.
  5. Sysmon Event ID 7 (Image Load) — for Windows GDI-based capture, look for gdi32.dll, gdi32full.dll, and user32.dll loaded by unusual processes.
  6. Windows Prefetch — C:\Windows\Prefetch\ for the screenshot binary's .pf file to determine execution frequency and first/last execution timestamps.
  7. Process memory dump of the screenshotting process — may contain C2 configuration, encryption keys, and captured bitmap data in memory.
  8. PowerShell ScriptBlock Logging (Event ID 4104) — if PowerShell was used to invoke CopyFromScreen, the full script will be logged here.
  9. MFT ($MFT) and file system timeline — use tools like Velociraptor or FTK to enumerate all image files created in the investigation window and correlate with known staging paths.

Escalation Criteria

  • !Screenshot process spawned by a known malicious parent chain (Office → wscript → screenshot tool) — immediate escalation to Incident Response.
  • !Periodic screenshot capture detected (multiple files at regular intervals over hours) — indicates an active persistent RAT maintaining a surveillance operation.
  • !Network connection from the screenshot process to a public IP immediately after file creation — active exfiltration in progress, escalate immediately.
  • !Screenshot files found in paths matching known malware staging conventions (\ProgramData\Mail\MailAg\ for Trojan.Karagany, \AppData\Roaming\ for Agent Tesla).
  • !Screenshots captured on a privileged workstation (executive, finance, HR, IT admin) — data exposure impact is significantly elevated.
  • !Same screenshot pattern observed across multiple endpoints within a short time window — indicates lateral movement or automated deployment of a RAT.
  • !Screenshots captured during after-hours or outside normal working hours for the affected user — anomalous access timing corroborates malicious automation.

Investigation Guide

Related Techniques

Forensic Artifacts

  • >File System: Screenshot files in staging paths — \ProgramData\Mail\MailAg\shot.png (Trojan.Karagany), \AppData\Roaming\<random>\ (Agent Tesla), /tmp/<random>.png (Linux RATs)
  • >File System: Prefetch — C:\Windows\Prefetch\PSR.EXE-*.pf and SNIPPINGTOOL.EXE-*.pf for execution timestamps
  • >Registry: HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RecentDocs — tracks recent file access and may show screenshot files opened
  • >Registry: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options — for any debugger hijacking of screenshot utilities
  • >Event Log: Microsoft-Windows-Sysmon/Operational Event ID 11 — file creation records with initiating process details
  • >Event Log: Microsoft-Windows-PowerShell/Operational Event ID 4104 — ScriptBlock logs for CopyFromScreen .NET API usage
  • >Memory: Process memory of suspicious processes — look for GDI bitmap objects, captured framebuffer data, and C2 server strings
  • >MFT ($MFT): File system timeline showing creation, modification timestamps for all image files in staging directories
  • >Network: Proxy/firewall logs for HTTP POST requests with image/png or multipart/form-data MIME types from unusual processes
  • >macOS: Unified Log (log show --predicate 'process == "screencapture"') for screencapture utility invocations
  • >Linux: bash_history and auditd logs for xwd, scrot, or import commands; /var/log/audit/audit.log for execve syscalls

Tuning Guidance

Screen capture detection requires careful baselining to avoid alert fatigue from legitimate tools. Start by building an allowlist of known-good processes and their typical file creation paths: helpdesk tools (TeamViewer, AnyDesk) write to their own installation directories, conferencing tools write to user-specified locations via UI. Key tuning levers: (1) Focus on staging paths (\Temp\, \ProgramData\, \AppData\Roaming\) rather than user-selected destinations — malware automates staging but users manually pick destinations. (2) Require a network connection correlation for Branch 3 (file creation) to reduce noise from legitimate screenshot archiving. (3) For periodic capture detection, tune the file count threshold (default: 3 files within 2 hours) based on your environment's baseline — high-frequency monitoring environments may need to raise this to 10+. (4) Add your IT helpdesk remote-support tool names to the exclusion list. (5) For Linux/macOS environments, baseline which users legitimately run scrot or screencapture from shell — developers and QA engineers may do this regularly. Consider restricting detection to non-standard parent processes (not bash/zsh directly invoked by user) rather than the tools themselves.


Hunting Queries

Hunt for processes creating multiple image files in staging paths within a short time window — a strong indicator of automated periodic screen capture by a RAT. Legitimate screenshot tools typically create one file per user action, not batches of 3+ files in under 2 hours.

Hunting — KQL
kql
DeviceFileEvents
| where Timestamp > ago(7d)
| where ActionType == "FileCreated"
| where FileName endswith ".png" or FileName endswith ".jpg" or FileName endswith ".bmp"
| where FolderPath has_any ("\\Temp\\", "\\AppData\\", "\\ProgramData\\", "\\Users\\Public\\")
| where InitiatingProcessFileName !in~ (
    "chrome.exe", "firefox.exe", "msedge.exe", "iexplore.exe", "outlook.exe",
    "teams.exe", "slack.exe", "zoom.exe", "mspaint.exe", "explorer.exe"
  )
| summarize
    FileCount=count(),
    UniqueFiles=dcount(FileName),
    FirstCapture=min(Timestamp),
    LastCapture=max(Timestamp),
    SamplePaths=make_set(FolderPath, 5)
  by DeviceName, InitiatingProcessFileName, InitiatingProcessAccountName
| where FileCount >= 3
| extend CaptureSpanMinutes=datetime_diff('minute', LastCapture, FirstCapture)
| where CaptureSpanMinutes < 120
| sort by FileCount desc
Hunting — SPL
spl
index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=11
  (TargetFilename="*.png" OR TargetFilename="*.jpg" OR TargetFilename="*.bmp")
  (TargetFilename="*\\Temp\\*" OR TargetFilename="*\\AppData\\*" OR
   TargetFilename="*\\ProgramData\\*" OR TargetFilename="*\\Users\\Public\\*")
  NOT (Image="*\\chrome.exe" OR Image="*\\firefox.exe" OR Image="*\\msedge.exe"
       OR Image="*\\outlook.exe" OR Image="*\\teams.exe" OR Image="*\\explorer.exe"
       OR Image="*\\zoom.exe" OR Image="*\\slack.exe" OR Image="*\\mspaint.exe")
| stats count as FileCount, dc(TargetFilename) as UniqueFiles,
        earliest(_time) as FirstCapture, latest(_time) as LastCapture,
        values(TargetFilename) as SampleFiles
  by host, Image, User
| where FileCount >= 3
| eval CaptureSpanMinutes=round((LastCapture - FirstCapture) / 60, 1)
| where CaptureSpanMinutes < 120
| sort - FileCount

Hunt for unusual processes loading GDI32.dll or Direct3D libraries from non-standard paths. Screen capture via BitBlt or CopyFromScreen requires GDI32.dll. Processes loading these DLLs from AppData, Temp, or user-writable paths outside Program Files and Windows directories are high-priority investigation candidates.

Hunting — KQL
kql
DeviceImageLoadEvents
| where Timestamp > ago(7d)
| where FileName in~ ("gdi32.dll", "gdi32full.dll", "d3d11.dll", "dxgi.dll")
| where InitiatingProcessFileName !in~ (
    "explorer.exe", "chrome.exe", "firefox.exe", "msedge.exe",
    "dwm.exe", "winlogon.exe", "csrss.exe", "svchost.exe",
    "mspaint.exe", "photoshop.exe", "teams.exe", "zoom.exe",
    "taskmgr.exe", "calc.exe"
  )
| where InitiatingProcessFolderPath !startswith "C:\\Program Files"
    and InitiatingProcessFolderPath !startswith "C:\\Windows"
| summarize
    LoadCount=count(),
    DLLs=make_set(FileName),
    Devices=dcount(DeviceName)
  by InitiatingProcessFileName, InitiatingProcessFolderPath, InitiatingProcessSHA256
| where LoadCount >= 2
| sort by Devices desc
Hunting — SPL
spl
index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=7
  (ImageLoaded="*\\gdi32.dll" OR ImageLoaded="*\\gdi32full.dll" OR ImageLoaded="*\\d3d11.dll")
  NOT (Image="*\\explorer.exe" OR Image="*\\chrome.exe" OR Image="*\\firefox.exe"
       OR Image="*\\dwm.exe" OR Image="*\\winlogon.exe" OR Image="*\\csrss.exe"
       OR Image="*\\svchost.exe" OR Image="*\\teams.exe" OR Image="*\\zoom.exe")
  NOT (Image="C:\\Program Files\\*" OR Image="C:\\Windows\\*")
| stats count as LoadCount, dc(host) as Devices, values(ImageLoaded) as DLLs
  by Image, User
| where LoadCount >= 2
| sort - Devices

Hunt for processes that both create image files in staging paths AND make outbound network connections to public IPs — the complete screen capture + exfiltration kill chain. Correlating file creation and network events on the same ProcessGuid within a short window provides high-confidence detection of active RAT exfiltration.

Hunting — KQL
kql
let ScreenCapturePaths = dynamic([
  "\\ProgramData\\Mail\\MailAg\\",
  "\\AppData\\Roaming\\",
  "\\AppData\\Local\\Temp\\",
  "\\Temp\\"
]);
DeviceFileEvents
| where Timestamp > ago(14d)
| where ActionType == "FileCreated"
| where FileName endswith ".png" or FileName endswith ".bmp"
| where FolderPath has_any (ScreenCapturePaths)
| join kind=inner (
    DeviceNetworkEvents
    | where Timestamp > ago(14d)
    | where RemoteIPType == "Public"
    | project NetworkTimestamp=Timestamp, DeviceName, InitiatingProcessId,
             RemoteIP, RemotePort, InitiatingProcessFileName as NetworkProcess
  ) on DeviceName, $left.InitiatingProcessId == $right.InitiatingProcessId
| where abs(datetime_diff('second', Timestamp, NetworkTimestamp)) < 60
| project FileTimestamp=Timestamp, NetworkTimestamp, DeviceName, AccountName,
         FileName, FolderPath, InitiatingProcessFileName, RemoteIP, RemotePort
| sort by FileTimestamp desc
Hunting — SPL
spl
index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational"
  (EventCode=11 OR EventCode=3)
| eval EventType=case(EventCode=11, "FileCreate", EventCode=3, "NetworkConn", true(), "Other")
| eval FileName=if(EventCode=11, TargetFilename, null())
| eval DestIP=if(EventCode=3, DestinationIp, null())
| eval IsPublicIP=if(EventCode=3 AND NOT match(DestinationIp, "^(10\.|172\.(1[6-9]|2[0-9]|3[01])\.|192\.168\.|127\.)"), 1, 0)
| eval IsScreenshotFile=if(EventCode=11 AND (match(TargetFilename, "\.(png|bmp|jpg)$")
    AND match(TargetFilename, "(\\\\Temp\\\\|\\\\AppData\\\\|\\\\ProgramData\\\\)")), 1, 0)
| stats values(eval(if(IsScreenshotFile=1, TargetFilename, null()))) as ScreenshotFiles,
        values(eval(if(IsPublicIP=1, DestinationIp, null()))) as ExfilIPs,
        sum(IsScreenshotFile) as FileCreateCount,
        sum(IsPublicIP) as NetworkConnCount
  by host, ProcessGuid, Image, User
| where FileCreateCount > 0 AND NetworkConnCount > 0
| sort - FileCreateCount

Atomic Red Team Tests

Test 1 Windows Screen Capture via PowerShell CopyFromScreen
windows

Uses .NET System.Drawing.Graphics.CopyFromScreen to capture the primary screen and save it to a JPEG file in the TEMP directory. This is a common technique used by malware (including Agent Tesla and custom RATs) to capture the desktop without requiring external tools. The command uses reflection-style .NET invocation that appears in PowerShell process telemetry.

Command

powershell
powershell.exe -Command "Add-Type -AssemblyName System.Windows.Forms; Add-Type -AssemblyName System.Drawing; $screen = [System.Windows.Forms.Screen]::PrimaryScreen.Bounds; $bmp = New-Object System.Drawing.Bitmap($screen.Width, $screen.Height); $g = [System.Drawing.Graphics]::FromImage($bmp); $g.CopyFromScreen($screen.Location, [System.Drawing.Point]::Empty, $screen.Size); $bmp.Save(\"$env:TEMP\\df00tech-capture.png\"); $g.Dispose(); $bmp.Dispose()"

Cleanup

powershell
Remove-Item $env:TEMP\df00tech-capture.png -ErrorAction SilentlyContinue

Expected Telemetry

Sysmon Event ID 1: Process Create — Image=powershell.exe, CommandLine containing 'CopyFromScreen', 'System.Drawing.Graphics', 'System.Windows.Forms.Screen'. Sysmon Event ID 11: File Create — TargetFilename=C:\Users\<user>\AppData\Local\Temp\df00tech-capture.png, Image=powershell.exe. PowerShell ScriptBlock Log Event ID 4104 with full script content. Sysmon Event ID 7: Image Load — gdi32.dll loaded by powershell.exe.

Expected Detection

KQL Branch 2 (ScriptingEngineScreenshotAPI) fires on ProcessCommandLine containing 'CopyFromScreen'. KQL Branch 3 (SuspiciousScreenshotFileInTempPath) fires on .png file created in Temp by powershell.exe. SPL detects via EventCode=1 with has_screenshot_api=1.

Test 2 Windows Screen Capture via PSR.exe (Problem Steps Recorder)
windows

Abuses the built-in Windows Problem Steps Recorder (psr.exe) to silently capture a series of screenshots. PSR.exe is a LOLBin that can be invoked with flags to capture a set number of screenshots without user interaction and save them in a ZIP archive. Used by threat actors to leverage a signed Microsoft binary for screenshot collection to evade detection.

Command

powershell
psr.exe /start /output %TEMP%\df00tech-psr-capture.zip /sc 1 /maxsc 5 & timeout /t 5 & psr.exe /stop

Cleanup

powershell
del %TEMP%\df00tech-psr-capture.zip 2>nul

Expected Telemetry

Sysmon Event ID 1: Process Create — Image=C:\Windows\System32\psr.exe, CommandLine containing '/start /output ... /sc 1 /maxsc 5'. Second Event ID 1 for the /stop invocation. Sysmon Event ID 11: File Create — TargetFilename ending in .zip in TEMP path, created by psr.exe. Security Event ID 4688 (if command line auditing enabled) for psr.exe execution.

Expected Detection

KQL Branch 1 fires when psr.exe is in ScreenshotProcesses list and parent is cmd.exe (SuspiciousParents). KQL Branch 3 fires on ZIP file creation in TEMP by psr.exe. SPL detects via EventCode=1 with is_screenshot_tool=1 and suspicious_parent=1.

Test 3 Linux Screen Capture via xwd (X Window Dump)
linux

Uses xwd (X Window Dump utility), a standard X11 tool, to capture the root window of the X display and save it to a file in /tmp. This technique is used by Linux RATs including Pupy and custom implants. The output file is in XWD format but can be converted to PNG with ImageMagick. Requires an active X11 display (set DISPLAY environment variable).

Command

bash
DISPLAY=:0 xwd -root -silent -out /tmp/df00tech-capture.xwd && file /tmp/df00tech-capture.xwd

Cleanup

bash
rm -f /tmp/df00tech-capture.xwd

Expected Telemetry

Linux auditd syscall log: execve syscall for xwd with arguments '-root -silent -out /tmp/df00tech-capture.xwd'. File creation event in /tmp/. Syslog entry if auditd is configured with -a always,exit -F arch=b64 -S execve rule. Process accounting record for xwd execution. /var/log/auth.log may show the user context.

Expected Detection

KQL Branch 1 would fire if Defender for Endpoint Linux agent is deployed (FileName=xwd in ScreenshotProcesses). SPL Sysmon detection would require Linux auditd forwarding. Hunting query detects xwd file creation in /tmp/ by non-standard parent. Linux-specific detection requires auditd rules for execve of xwd/scrot/import.

Test 4 macOS Screen Capture via screencapture Utility
macos

Uses the macOS native screencapture utility to silently capture the entire display and save it to /tmp. The -x flag suppresses the shutter sound, and -t png specifies PNG format. This is the macOS equivalent of xwd and is used by macOS-targeting malware referenced in the Antiquated Mac Malware analysis. Simulates a RAT using native OS capabilities to avoid detection by avoiding third-party binaries.

Command

bash
screencapture -x -t png /tmp/df00tech-capture.png && ls -la /tmp/df00tech-capture.png

Cleanup

bash
rm -f /tmp/df00tech-capture.png

Expected Telemetry

macOS Unified Log: log show --predicate 'process == "screencapture"' will show the invocation. Endpoint security framework (ESF) event for ES_EVENT_TYPE_NOTIFY_EXEC for screencapture. File creation event in /tmp/ for the PNG file. If Defender for Endpoint macOS agent is deployed: DeviceProcessEvents with FileName=screencapture and DeviceFileEvents for the output file.

Expected Detection

KQL Branch 1 fires on screencapture in ScreenshotProcesses when InitiatingProcessFileName is a suspicious parent (e.g., bash spawned from a web process). KQL Branch 3 fires on PNG creation in /tmp/ by screencapture if parent is non-UI process. macOS-specific detection via Unified Log query for screencapture with -x flag (silent capture).

Test 5 Windows VK_SNAPSHOT Keyboard Simulation Screenshot
windows

Simulates the JHUHUGIT/Gamaredon technique of pressing the Print Screen key (VK_SNAPSHOT = 0x2C) programmatically using keybd_event via .NET P/Invoke, then accessing the clipboard bitmap. This technique is notable because it uses keyboard simulation rather than direct GDI APIs, making it harder to detect via API hooking. The captured image is accessed from the clipboard.

Command

powershell
powershell.exe -Command "Add-Type -TypeDefinition 'using System; using System.Runtime.InteropServices; public class KbdCapture { [DllImport(\"user32.dll\")] public static extern void keybd_event(byte bVk, byte bScan, int dwFlags, int dwExtraInfo); }'; [KbdCapture]::keybd_event(0x2C, 0, 0, 0); Start-Sleep -Milliseconds 200; Add-Type -AssemblyName System.Windows.Forms; $img = [System.Windows.Forms.Clipboard]::GetImage(); if ($img) { $img.Save(\"$env:TEMP\\df00tech-vksnapshot.png\") }"

Cleanup

powershell
Remove-Item $env:TEMP\df00tech-vksnapshot.png -ErrorAction SilentlyContinue

Expected Telemetry

Sysmon Event ID 1: Process Create — Image=powershell.exe, CommandLine containing 'keybd_event', '0x2C', 'VK_SNAPSHOT'. PowerShell ScriptBlock Log Event ID 4104 with full P/Invoke code. Sysmon Event ID 7: Image Load — user32.dll loaded by powershell.exe. Sysmon Event ID 11: File Create for .png in TEMP if clipboard contained image data.

Expected Detection

KQL Branch 2 fires on ProcessCommandLine containing 'keybd_event' AND '0x2C'. SPL detects via is_script_engine=1 and has_screenshot_api=1 (matching '0x2c' pattern). This atomic simulates the exact JHUHUGIT/Gamaredon technique documented in MITRE procedure examples.

Related Detections