Overview

Local Data Staging (T1074.001) is the practice of collecting and consolidating files of interest — credentials, documents, database dumps, configuration files — into a single directory or archive on the compromised host before moving them off the network. Attackers do this to minimize the number of transfer operations, reduce noise, and make exfiltration faster and more reliable.

Every security team needs to detect this technique because it sits directly between collection and exfiltration — catching it here is one of the last opportunities to stop data loss before sensitive material leaves your environment. Staging activity often leaves distinct, detectable artifacts: archive creation in temp directories, bulk file copies, and compression tool invocations that stand out from normal user behavior.

Attacker Perspective

Once an adversary has identified valuable data on a compromised host, they consolidate it locally to prepare a clean, portable package for exfiltration.

• PowerShell archive compression: Attacker runs Compress-Archive -Path C:\Users\*\Documents -DestinationPath C:\Windows\Temp\out.zip to bundle user documents into a single ZIP in a world-writable temp directory.
• 7-Zip or WinRAR via command line: Attacker executes 7z.exe a -p[password] C:\Temp\loot.7z C:\Users\finance\ to create a password-protected archive, complicating forensic inspection of the staged file.
• Linux tar staging: Attacker runs tar czf /tmp/.hidden_data.tar.gz /home /etc/passwd /var/www to bundle credentials and web configs into a hidden file in /tmp before SCP exfiltration.
• Windows Registry or living-off-the-land copy: Attacker uses cmd.exe /c xcopy /s /e C:\Users\*\AppData\Roaming\*.kdbx C:\Windows\Temp\stage\ to silently mirror credential stores into a staging folder without using any third-party tools.

This technique is attractive to attackers because it requires no special privileges beyond file system read access, uses built-in or commonly available tools that blend into normal administrative activity, and dramatically reduces the time the attacker’s C2 channel needs to stay open during exfiltration.

Detection Strategy

Required Telemetry

• Windows — PowerShell Script Block Logging (Event ID 4104): Enable via GPO or registry: HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging → set EnableScriptBlockLogging = 1 (DWORD). This captures the full text of every PowerShell script block executed, including Compress-Archive invocations. Without this, PowerShell-based staging is largely invisible.
• Windows — PowerShell Module Logging (Event ID 4103): Enable via GPO: HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ModuleLogging → set EnableModuleLogging = 1 and add * to the module names list. Captures cmdlet-level pipeline execution context.
• Windows — Process Creation (Event ID 4688 or Sysmon Event ID 1): Enable process creation auditing via auditpol /set /subcategory:"Process Creation" /success:enable. For full command-line visibility, also enable HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit → ProcessCreationIncludeCmdLine_Enabled = 1. Sysmon with a well-tuned config (using the SwiftOnSecurity or Olaf Hartong base config) is preferred over native 4688 because it also captures parent/child relationships cleanly in a single event.
• Windows — File System Activity (Sysmon Event ID 11 — FileCreate): Sysmon’s FileCreate event captures the creation of new files including archives. Target paths like C:\Windows\Temp\, C:\Temp\, %APPDATA%\Local\Temp\, and any user-writable system directories. Without Sysmon or an EDR providing file events, you will miss file-drop staging that doesn’t involve a subprocess.
• Windows — Classic PowerShell Event Log (Event ID 400, 800): The legacy Windows PowerShell log (not the newer Operational log) records engine lifecycle events and is available even without Script Block Logging enabled. Useful as a fallback to detect PowerShell invocation patterns.
• Linux — Auditd: Add rules to /etc/audit/rules.d/staging.rules to monitor execution of archiving binaries: -a always,exit -F arch=b64 -F exe=/usr/bin/tar -k staging, -a always,exit -F arch=b64 -F exe=/usr/bin/zip -k staging, -a always,exit -F arch=b64 -F exe=/usr/bin/gzip -k staging. Also add a watch on suspicious output paths: -w /tmp -p w -k tmp_write. Reload with augenrules --load.
• Linux/macOS — EDR or osquery: If auditd is not available, osquery’s process_events table with cmdline visibility covers tar/zip/7z execution. On macOS, enable Endpoint Security Framework (ESF) via your EDR; native BSM auditing is deprecated on modern macOS.
• macOS — Unified System Log / EDR: Use your EDR to capture process execution with command-line arguments. The macOS Unified Log does not natively expose full process command lines without an EDR or audit framework in place.

Key Indicators

• Compression into temp directories (Windows): In PowerShell Script Block logs (EventID = 4104), field ScriptBlockText contains patterns like Compress-Archive -Path combined with destination paths matching \Temp\, \AppData\Local\Temp\, or C:\Windows\Temp\.
• Archiving tools writing to world-writable locations (Windows process): In Sysmon Event ID 1 or Windows Event ID 4688, field CommandLine contains invocations of 7z.exe, WinRAR.exe, rar.exe, pkzip.exe, or compress.exe with output flags (a, -o, -d) pointing to C:\Windows\Temp, C:\Temp, C:\ProgramData, or C:\Users\Public.
• Bulk file copy operations (Windows): In Event ID 4688 / Sysmon Event ID 1, CommandLine contains xcopy, robocopy, or copy /b with recursive flags (/s, /e) targeting sensitive source directories like \Users\, \Documents\, \Desktop\, or \AppData\Roaming\ with a destination in a temp or staging path.
• Archive file creation in suspicious locations (Sysmon FileCreate): In Sysmon Event ID 11, field TargetFilename ends with .zip, .7z, .rar, .tar, .tar.gz, or .gz, and the path contains Temp, ProgramData, Public, or Recycle.
• Linux tar/zip in /tmp or /dev/shm (Auditd): In auditd EXECVE records tagged with key staging, the a0–a4 argument fields contain czf, cjf, or cJf (tar compression flags) and an output path under /tmp/, /var/tmp/, or /dev/shm/.
• Anomalous parent-child relationships: In Sysmon Event ID 1, a staging command (compression or bulk copy) where ParentImage is an unexpected parent such as cmd.exe spawned by winword.exe, excel.exe, outlook.exe, or a web server process like w3wp.exe — this strongly suggests a macro or web shell spawning the staging activity.
• Registry-based data staging (Windows): In Sysmon Event ID 13 (RegistryValueSet), large amounts of data being written to unusual registry keys — particularly under HKCU\Software\ or HKLM\SOFTWARE\ — by non-system processes, consistent with the DarkWatchman-style technique of using the registry as a staging buffer.

Detection Logic

Rule 1 (Broad — High Sensitivity): PowerShell compression to temp path
IF EventID = 4104 AND ScriptBlockText CONTAINS "Compress-Archive" AND ScriptBlockText CONTAINS ("-DestinationPath") AND (ScriptBlockText CONTAINS "\Temp\" OR ScriptBlockText CONTAINS "env:TEMP" OR ScriptBlockText CONTAINS "\AppData\Local\Temp\")

This catches the most common PowerShell-based staging pattern seen in commodity ransomware and targeted intrusions. Expected alert volume is low-to-medium; most legitimate uses of Compress-Archive target explicit user-defined paths rather than temp directories. Still tunable — see the tuning section for exclusions.

Rule 2 (Medium Precision): Third-party archiver writing to staging paths
IF (EventID = 1 OR EventID = 4688) AND (Image ENDSWITH "7z.exe" OR Image ENDSWITH "rar.exe" OR Image ENDSWITH "WinRAR.exe" OR Image ENDSWITH "pkzip.exe") AND (CommandLine CONTAINS "C:\Windows\Temp" OR CommandLine CONTAINS "C:\Temp\" OR CommandLine CONTAINS "C:\Users\Public\" OR CommandLine CONTAINS "C:\ProgramData\") AND NOT (ParentImage ENDSWITH "explorer.exe" AND User NOT IN privileged_accounts)

Catches adversaries using pre-installed or dropped archiving tools to stage data in world-writable paths. Expect moderate false positives from IT tooling that calls 7-Zip programmatically — tune by excluding known admin tools.

Rule 3 (Medium Precision): Archive file created in suspicious directory (FileCreate)
IF EventID = 11 AND TargetFilename MATCHES ".*\.(zip|7z|rar|tar|gz|bz2)$" AND (TargetFilename CONTAINS "\Windows\Temp\" OR TargetFilename CONTAINS "\AppData\Local\Temp\" OR TargetFilename CONTAINS "\Users\Public\" OR TargetFilename CONTAINS "\ProgramData\") AND NOT Image IN (known_backup_tools)

Complements process-based rules by catching archive creation regardless of which process created the file. Useful for catching renamed or custom tools that might evade the process-name checks in Rule 2. Low expected volume outside of patch/backup windows.

Rule 4 (High Precision): Recursive bulk file copy from sensitive source to staging destination
IF (EventID = 1 OR EventID = 4688) AND (Image ENDSWITH "xcopy.exe" OR Image ENDSWITH "robocopy.exe") AND CommandLine MATCHES "(/s|/e|/S|/E)" AND (CommandLine CONTAINS "\Users\" OR CommandLine CONTAINS "\Documents\" OR CommandLine CONTAINS "\Desktop\") AND (CommandLine CONTAINS "\Temp\" OR CommandLine CONTAINS "\Public\" OR CommandLine CONTAINS "\ProgramData\") AND NOT ParentImage IN (known_backup_agents)

This rule has low false positive rates because the combination of recursive flag, sensitive source, and staging destination is rarely seen in legitimate workflows. High confidence on a hit — treat as medium-high severity immediately.

Tuning Guidance

• Backup and endpoint management software: Products like Veeam, Acronis, Backup Exec, or SCCM/MECM regularly create archives in temp locations as part of legitimate backup or software deployment workflows. Identify the specific process names and service account usernames these products use (e.g., VeeamAgent.exe, AcronisAgent.exe) and exclude them with Image IN [backup_tool_list] or User IN [backup_service_accounts].
• Developer and DevOps tooling: Build pipelines (Azure DevOps agents, Jenkins workers, GitHub Actions runners) often invoke Compress-Archive or 7z.exe to package build artifacts into temp directories. Exclude by ParentImage ENDSWITH "agent.exe" or by host membership in a “build servers” asset group.
• Legitimate IT admin scripts: Helpdesk or sysadmin scripts that zip log files or config backups before uploading to a share will trigger Rule 1 and Rule 2. Audit your environment for these scripts, move them to a known path (e.g., C:\IT_Scripts\), and exclude by ScriptBlockText CONTAINS "C:\IT_Scripts\" or by signing the scripts and filtering on code signature status if your EDR supports it.
• User-initiated compression: A user right-clicking a folder and choosing “Send to → Compressed folder” generates a FileCreate event in their profile’s Temp directory. This is nearly indistinguishable from malicious activity at the file level alone. Correlate with process parent (ParentImage = explorer.exe) and the absence of any preceding suspicious process chain to suppress this noise.
• High-volume Sysmon FileCreate noise: Rule 3 can be noisy on hosts with many applications writing temporary zips. Scope it initially to servers and high-value workstations (executives, finance, HR, IT admins) rather than running it fleet-wide. Expand scope gradually as you validate the exclusion list.

When the Alert Fires: Investigation Steps

1. Verify the alert is real: Pull the raw source event from your SIEM using the specific EventID and host identifier — confirm the ScriptBlockText, CommandLine, or TargetFilename field actually contains the staging pattern and was not a SIEM parsing artifact. Check that the timestamp aligns with the alert window.
2. Identify the affected host and user: Note the Computer (or hostname) and User fields from the event. Look up the user in Active Directory or your IdAM to determine if they are privileged (Domain Admin, service account, finance, HR, executive) — privileged account involvement escalates severity immediately.
3. Pull the full command-line and parent process chain: Using Sysmon Event ID 1 or your EDR, retrieve the full process tree: the staging process, its ParentImage and ParentCommandLine, and the grandparent. A chain like winword.exe → cmd.exe → 7z.exe or w3wp.exe → powershell.exe → Compress-Archive is a confirmed incident indicator — document the full chain.
4. Identify what data was staged: Examine the CommandLine or ScriptBlockText to determine the source path(s) that were collected. Cross-reference with Sysmon Event ID 11 (FileCreate) and Event ID 23 (FileDelete) around the same timestamp on the same host to identify what files were created, and whether the staged archive was subsequently deleted (which may indicate successful exfiltration).
5. Check for outbound network connections from the same host: Query Sysmon Event ID 3 (NetworkConnect), firewall logs, or proxy logs for outbound connections from the affected host in the 30 minutes before and after the staging event. Look for connections to unusual external IPs, known file-sharing services (mega.nz, anonfiles, transfer.sh), or cloud storage endpoints that are atypical for this host’s baseline.
6. Look for lateral movement indicators originating from this host: Search Windows Security Event ID 4624 (logon type 3 — network) and Event ID 4648 (explicit credential logon) in your SIEM for authentications sourced from the affected host to other internal systems in the same window. Also check Sysmon Event ID 3 for SMB (port 445) or WinRM (port 5985/5986) connections to other internal hosts.
7. Escalation decision: Treat the alert as a confirmed incident requiring IR escalation if any of the following are true: the parent process is an Office application, browser, or web server process; the staged data source includes credential stores, financial data paths, or HR directories; a subsequent outbound network connection is confirmed; or the archive was created and then deleted within a short window. If the parent is explorer.exe, the user is non-privileged, and no outbound connection is observed, classify as suspicious and place in a 24-hour monitoring queue before closing.

Response Playbook

Containment

• Isolate the host — do not power it off: Use your EDR console (CrowdStrike, Defender for Endpoint, Carbon Black, SentinelOne) to place the host in network containment mode. This blocks all network traffic except the EDR management channel, allowing you to continue live investigation. Powering the host off destroys volatile memory artifacts (running processes, network connections, encryption keys in memory) that are critical for forensics.
• Disable the affected user account: In Active Directory, run Disable-ADAccount -Identity [username] or use the ADUC console. If the account is an Azure AD or hybrid account, also disable it in the Azure portal and revoke all active sessions via Revoke-AzureADUserAllRefreshToken -ObjectId [user_object_id] in the Azure AD PowerShell module.
• Block identified C2 IPs and domains: If outbound connections were observed in the previous investigation step, submit the destination IPs and domains to your firewall team and DNS security platform (Cisco Umbrella, Zscaler, Palo Alto DNS Security) for immediate blocking. Document the block with a ticket number linked to this incident.
• Kill the malicious process and preserve the staged archive: If the EDR shows the staging process is still running, terminate it via the EDR console. Do not delete the staged archive file yet — collect it first (hash it with Get-FileHash on Windows or sha256sum on Linux, then copy it to an evidence share) before removing it from the host. This preserves evidence of what was collected.
• Preserve a memory image if possible: Before isolating, if your EDR or IR tooling (Magnet AXIOM, Velociraptor, WinPmem) supports live memory acquisition, capture a full memory image. This is especially valuable if the attacker used a fileless loader or if credentials were decrypted in memory.

Eradication

• Remove identified persistence mechanisms: Use Autoruns (Sysinternals) or your EDR’s persistence sweep to check for new scheduled tasks (schtasks /query /fo LIST /v), Run/RunOnce registry keys (HKCU\Software\Microsoft\Windows\CurrentVersion\Run), new services (sc query type= all), and WMI subscriptions. Remove any entries not present on a clean baseline image.
• Delete dropped payloads and tools: Search the host for the archive tools, scripts, or implants identified during investigation. Use your EDR’s file search or Velociraptor’s glob() hunt across the fleet to find the same files on other hosts (match by hash). Delete confirmed malicious files and document their paths and hashes as IOCs.
• Reset credentials for all involved accounts: Force a password reset for the affected user account and any other accounts that were authenticated from the compromised host during the incident window. If the staged data contained LSASS credentials, password hashes, or credential store files (KeePass .kdbx, browser credential databases), treat all accounts on the network as potentially compromised and scope a broader credential reset with your identity team.
• Check lateral movement targets for backdoors: For every internal host that received a network connection from the compromised host during the incident window, run a persistence sweep using the same Autoruns or EDR methodology. Do not assume only the initial host is compromised — attackers staging data often do so after moving laterally.
• Rotate secrets and API keys: If the staged source paths included application config files, environment variable dumps, cloud credential stores (.aws\credentials, service_account.json), or browser-saved passwords, rotate all associated secrets immediately through your secrets management platform (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault).

Recovery

• Verify the host is clean before reconnecting: Before lifting network isolation, run a full EDR scan and review all persistence locations one final time. If confidence in the cleanliness of the host is less than high — particularly if the initial access vector is unknown — re-image from a known-good baseline rather than attempting manual cleanup. The cost of a re-image is far lower than re-compromise.
• Re-enable the user account only after confirmation: Restore the affected user’s account access only after persistence has been confirmed removed, credentials have been reset, and the host has been verified clean or re-imaged. Brief the user on the incident and instruct them to report any unusual activity immediately.
• Monitor the host and user account for 72 hours post-remediation: Create a temporary, elevated-sensitivity watchlist in your SIEM for the affected hostname and username. Alert on any recurrence of staging indicators, any new outbound connections to previously unseen external destinations, and any new process creation from unusual parents. Set the watchlist to expire automatically at 72 hours unless extended.
• Document the full incident timeline and close formally: Write an incident report covering initial alert, investigation findings, confirmed attacker actions, data at risk, containment and eradication steps taken, and timeline from compromise to containment. Share with management and legal/compliance as required by your data breach notification obligations.
• Update detection rules with new IOCs and close coverage gaps: Add any new file hashes, process names, registry keys, or network indicators discovered during the investigation to your SIEM detection rules and threat intelligence platform. If the attacker used a staging path or technique not covered by existing rules, write and test a new rule before closing the incident. Run the new rule against 30 days of historical logs to check for earlier activity you may have missed.