Archive file created in an uncommon staging directory

Siemphony@siemphonylowT1560unverified

Matches the file-write half of MITRE's AN1458: an archive or compressed container appearing in a directory that is a staging spot rather than a normal place for software to unpack itself. It carries no process gate on purpose, because the corpus already covers the utility-execution half under T1560.001 and the artefact is what remains visible when the compression is done by a third-party library or a custom method instead of a named tool. MITRE's ArchiveExtensions and SuspiciousDirectories knobs are populated here with the author's own lists, and the per-user and ProgramData temp trees are left out of them because installer extraction dominates those paths. Sysmon EventID 11 carries no file size, so MITRE's FileSizeThresholdMB knob has no representation and a single compressed document looks the same here as a staged collection. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0526, not hand-written and not tested by its author. Any lab result is on this rule's own page.Full description

The 4 SIEM queries below are previews produced by Siemphony’s own translator, not pySigma, and none has been executed against a real backend — review before you deploy.

detection.yml

Sentinel · KQL

Run this as a search.

DeviceFileEvents| where ((FolderPath endswith ".7z" or FolderPath endswith ".rar" or FolderPath endswith ".zip" or FolderPath endswith ".tar" or FolderPath endswith ".gz" or FolderPath endswith ".tgz" or FolderPath endswith ".bz2" or FolderPath endswith ".cab" or FolderPath endswith ".arj") and (FolderPath contains "\\Users\\Public\\" or FolderPath contains "\\PerfLogs\\" or FolderPath contains "\\Windows\\Temp\\" or FolderPath contains "\\Windows\\Tasks\\" or FolderPath contains "\\Windows\\debug\\" or FolderPath contains "\\Windows\\addins\\" or FolderPath contains "\\$Recycle.Bin\\"))

Splunk · SPL

Run this as a search.

index=* ((TargetFilename="*.7z" OR TargetFilename="*.rar" OR TargetFilename="*.zip" OR TargetFilename="*.tar" OR TargetFilename="*.gz" OR TargetFilename="*.tgz" OR TargetFilename="*.bz2" OR TargetFilename="*.cab" OR TargetFilename="*.arj") AND (TargetFilename="*\\Users\\Public\\*" OR TargetFilename="*\\PerfLogs\\*" OR TargetFilename="*\\Windows\\Temp\\*" OR TargetFilename="*\\Windows\\Tasks\\*" OR TargetFilename="*\\Windows\\debug\\*" OR TargetFilename="*\\Windows\\addins\\*" OR TargetFilename="*\\$Recycle.Bin\\*"))

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE ((TO_LOWER(file.path) LIKE "*.7z" OR TO_LOWER(file.path) LIKE "*.rar" OR TO_LOWER(file.path) LIKE "*.zip" OR TO_LOWER(file.path) LIKE "*.tar" OR TO_LOWER(file.path) LIKE "*.gz" OR TO_LOWER(file.path) LIKE "*.tgz" OR TO_LOWER(file.path) LIKE "*.bz2" OR TO_LOWER(file.path) LIKE "*.cab" OR TO_LOWER(file.path) LIKE "*.arj") AND (TO_LOWER(file.path) LIKE "*\\\\users\\\\public\\\\*" OR TO_LOWER(file.path) LIKE "*\\\\perflogs\\\\*" OR TO_LOWER(file.path) LIKE "*\\\\windows\\\\temp\\\\*" OR TO_LOWER(file.path) LIKE "*\\\\windows\\\\tasks\\\\*" OR TO_LOWER(file.path) LIKE "*\\\\windows\\\\debug\\\\*" OR TO_LOWER(file.path) LIKE "*\\\\windows\\\\addins\\\\*" OR TO_LOWER(file.path) LIKE "*\\\\$recycle.bin\\\\*"))

Wazuh · XML rule

Deploy to your manager — this is a rule, not a search.

<group name="sigma,windows,file_event,">  <!-- Rule ids must be unique on your manager; 100000+ is the user range. -->  <rule id="100000" level="5">    <!-- Set <if_sid> to the decoder/base rule for windows so this only evaluates relevant events. -->    <field name="TargetFilename" type="pcre2">(?i)(\.7z$|\.rar$|\.zip$|\.tar$|\.gz$|\.tgz$|\.bz2$|\.cab$|\.arj$)</field>    <field name="TargetFilename" type="pcre2">(?i)(\\Users\\Public\\|\\PerfLogs\\|\\Windows\\Temp\\|\\Windows\\Tasks\\|\\Windows\\debug\\|\\Windows\\addins\\|\\\$Recycle\.Bin\\)</field>    <description>Archive file created in an uncommon staging directory</description>    <mitre>      <id>T1560</id>    </mitre>  </rule></group>

At a glance

Logsource: file_event / windows
Level: low
Category: data_staging_exfil
Sigma status: experimental
Backends: 4 of 4 rendered
Updated: 30 Aug 2026
Rule ID: 6f295040-5233-463d-8b1b-1147c0f8eea1

ATT&CKT1560

T1560Archive Collected Data

ATT&CK® is a registered trademark of The MITRE Corporation. These mappings are the rule author’s, and are neither reviewed nor endorsed by MITRE.

Lessondata staging exfil

data staging exfilAI draft — unreviewed

01 · What this rule detects

AN1458 describes a correlation: a compression utility runs, then a large compressed or encrypted file appears. This rule keeps only the second half — a Sysmon file-creation event whose name ends in an archive extension and whose path falls inside a staging directory. There is no process gate at all, and the description says why: the utility-execution half already lives in the corpus as the T1560.001 rule, and this one is meant to catch the archive when it was produced by a library or a hand-rolled method that never shows up as a named process.

02 · Telemetry you need

category: file_event, product: windows — Sysmon EventID 11, copied verbatim from AN1458's second log source. FileCreate is not on in a bare Sysmon install, and the review flags something sharper: several widely deployed community configs (SwiftOnSecurity-style) explicitly exclude writes under C:\Windows\Temp as servicing noise — exactly the path carrying this rule's loudest arm. Run this against such a config and the rule returns nothing, and that reads as "quiet" rather than "blind." The sibling T1566.003 rule in this batch states this prerequisite for the same logsource; this one doesn't, which the review calls an inconsistency worth fixing before relying on it.

03 · How the logic works

Two selections, ANDed. selection_extension matches TargetFilename|endswith against nine values: .7z, .rar, .zip, .tar, .gz, .tgz, .bz2, .cab, .arj. selection_directory matches TargetFilename|contains against seven paths: \Users\Public\, \PerfLogs\, \Windows\Temp\, \Windows\Tasks\, \Windows\debug\, \Windows\addins\, \$Recycle.Bin\. Both lists are MITRE's ArchiveExtensions and SuspiciousDirectories knobs by name only — the members are the rule author's own choices. The description is explicit that the per-user %TEMP% tree and C:\ProgramData are deliberately absent, traded away because installer extraction dominates those paths; the honest cost is that the most common real staging location — an archive written beside the collected data inside the user's own profile — is invisible to this rule. FileSizeThresholdMB has no representation at all: Sysmon EID 11 carries no file-size field, so a single zipped document and a staged multi-gigabyte collection look identical here.

04 · Common false positives

The false positives are honest about the top source: Windows servicing and vendor patch agents write cabinet and zip payloads into Windows\Temp on every update cycle, and on a patched fleet that's the highest-volume match by a wide margin — the stated reason the rule sits at level: low. Helpdesk collectors and support-bundle packagers add more of the same. But the review surfaces a false positive the rule's own list misses entirely: the Recycle Bin. Deleting any archive from anywhere on disk moves it to C:\$Recycle.Bin\<SID>\$R......zip, keeping its original extension — a routine, per-deletion Sysmon EID 11 write that satisfies both selections and has nothing to do with collection.

05 · Detection maturity

tier_1: . Never executed against a log line; the extension-and-path logic was reasoned about on paper, not observed.
tier_2: requires first confirming the Sysmon config in use actually emits FileCreate for `Windows\Temp` — many don't — then running read-only and ranking hits by `TargetFilename` to size the patch-agent and Recycle Bin volume before committing to a level.
tier_3: ** means building the process half of AN1458 as a companion rule against process_creation and joining the two on MITRE's dropped TimeWindow, so an alert means "utility ran, then archive appeared" rather than "archive appeared."

Tuning & false positivesexperimental · 4 declared

experimental (current stage)
test
stable

Written and reasoned about, but not yet run against real telemetry. Expect to tune it before trusting it.

Tuning tips

Add the audit prerequisite to the description explicitly, naming Windows Temp exclusion as the specific config trap. State plainly that extension is the only gate: rar a C:\Users\Public\loot.dat or any tool told to omit the default suffix produces a byte-identical archive this rule cannot see, and there is no process-level backstop to catch the rename. If %TEMP% and ProgramData coverage matters more than the noise saved by excluding them, add them and re-weigh the level. Deploy this rule together with T1560.001 rather than alone — one covers the process, this one covers the artefact, and neither is a substitute for the other.

Declared by the author

Windows servicing and vendor patch agents, which use the Windows Temp directory as scratch space and write cabinet and zip payloads into it on every update cycle. On a patched fleet this is the highest-volume match by a wide margin, and it is the reason the rule is not levelled above low.
Diagnostic and log-collection tooling that packages its output to a fixed path. Helpdesk collectors, vendor support bundles and crash-report packagers routinely drop a zip in the Windows Temp directory or in the Public profile.
People sharing files through the Public profile, which is the documented location for content every account on the machine can read. An archive landing there is ordinary desktop behaviour and matches with nothing else required.
Scheduled tasks and service accounts that compress their own working data in place, for example an application writing a rotated log archive under the Windows Temp directory rather than into its own install path.

Noise check0 of 3 fired

Fires on none of the 3 ordinary behaviours the baseline holds for this log type. That is not a precision guarantee: it means only not caught by these 3 behaviours, and the next ordinary behaviour nobody wrote down may still match.

Run live against 65 hand-written events of ordinary corporate activity — backup agents, software distribution, patching, helpdesk scripts, EDR. It says nothing about how often the rule would fire in production, which is the number that actually exhausts an analyst.

Verification1 run

Not verified

Siemphony benign baseline
completed
Siemphony IR · 3 Sept 2026
No events matched, so this run proves nothing either way.

Test it yourselfin your browser

Runs here in your browser against public attack recordings. A preview — not the verification badge.

Recordings of T1560, evaluated against their file_event events.

Share this rule

/u/siemphony/6f295040-5233-463d-8b1b-1147c0f8eea1

More from this repertoire

All compositions

Verdicts · reactions · comments

Community

Verdicts from engineers who actually deployed it, and the conversation around it.

Not yet reported on

Nobody has run this in a real environment and said what happened.

Verdicts from engineers who deployed it

0 cast

No verdicts reported yet. The first one is worth more than the tenth — say what you ran it against.

No comments yet. Someone who deploys this will have something to say about it.

Archive file created in an uncommon staging directory

The detection

detection.yml

Sentinel · KQL

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Community

Verdicts from engineers who deployed it