Stored business data file deleted by a process that does not own it

Siemphony@siemphonymediumT1565.001unverifiedPlaybook · Destructive impact

Matches the deletion of a business-record file — a SQL Server data or log file, an Access database or an Outlook store — by any process other than the engine or client that owns it, which is the destructive arm of AN0555 and the only arm that produces a discrete event. The exclusion list is MITRE's AuthorizedProcesses knob populated here with the engines and clients that legitimately remove their own files; anything else unlinking one of these extensions is left to alert. Two limits decide what this can be read as. Backup archives are deliberately not in the extension list: deleting backups to block recovery is T1490, not this technique, and retention jobs pruning .bak files would have dominated the output. And Sysmon has no file-modification event, so the arm the technique is actually named for — a non-owning process writing false values into an existing database file in place — generates no record at all and is structurally invisible here. This rule therefore covers destruction of a record, never falsification of one, and a quiet result says nothing about tampering. File-delete telemetry is also absent from most shipped Sysmon configurations and is expensive to collect, so confirm EventID 23 or 26 is actually being gathered before reading silence as an absence. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0193, 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

1title: Stored business data file deleted by a process that does not own it2id: 95361a8a-b91f-43e3-a3ef-f1eafc6f5a1b3status: experimental4description: |5  Matches the deletion of a business-record file — a SQL Server data or log6  file, an Access database or an Outlook store — by any process other than the7  engine or client that owns it, which is the destructive arm of AN0555 and the8  only arm that produces a discrete event. The exclusion list is MITRE's9  AuthorizedProcesses knob populated here with the engines and clients that10  legitimately remove their own files; anything else unlinking one of these11  extensions is left to alert. Two limits decide what this can be read as.12  Backup archives are deliberately not in the extension list: deleting backups13  to block recovery is T1490, not this technique, and retention jobs pruning14  .bak files would have dominated the output. And Sysmon has no15  file-modification event, so the arm the technique is actually named for — a16  non-owning process writing false values into an existing database file in17  place — generates no record at all and is structurally invisible here. This18  rule therefore covers destruction of a record, never falsification of one,19  and a quiet result says nothing about tampering. File-delete telemetry is20  also absent from most shipped Sysmon configurations and is expensive to21  collect, so confirm EventID 23 or 26 is actually being gathered before22  reading silence as an absence.23  UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0193, not hand-written and not tested by its author. Any lab result is on this rule's own page.24references:25  - https://attack.mitre.org/techniques/T1565/00126  - https://attack.mitre.org/detectionstrategies/DET019327author: Siemphony pipeline (machine-derived from MITRE ATT&CK v19.2)28date: 2026-08-1629tags:30  - attack.impact31  - attack.t1565.00132logsource:33  category: file_delete34  product: windows35detection:36  selection_stored_data:37    TargetFilename|endswith:38      - '.mdf'39      - '.ldf'40      - '.ndf'41      - '.mdb'42      - '.accdb'43      - '.pst'44      - '.ost'45  filter_owning_applications:46    Image|endswith:47      - '\sqlservr.exe'48      - '\sqlagent.exe'49      - '\sqlwriter.exe'50      - '\mysqld.exe'51      - '\postgres.exe'52      - '\outlook.exe'53      - '\msaccess.exe'54  condition: selection_stored_data and not filter_owning_applications55falsepositives:56  - "Database maintenance done by hand. A DBA detaching a database and deleting its .mdf and .ldf from Explorer, cmd.exe or PowerShell, or a developer resetting a local instance, matches precisely because the deleting image is a shell rather than the engine, and on a shared development server this is the most frequent source."57  - "Antivirus and EDR engines removing a file. A scheduled scan quarantining an infected .pst or .ost attachment store, or deleting a corrupted Access or SQL data file, deletes it under the scanner's own image, which is a non-owning process exactly like an attacker's shell."58  - "Mailbox cache and profile churn driven by something other than outlook.exe — profile migration tooling, a mail-archiving product clearing a stale .ost, or a user deleting an old .pst archive from Explorer."59  - "Installers and uninstallers. msiexec.exe and vendor setup programs remove bundled Access .mdb files and SQL Express data files during an upgrade, a repair run or a clean removal."60level: medium

Sentinel · KQL

Run this as a search.

DeviceFileEvents| where ((FolderPath endswith ".mdf" or FolderPath endswith ".ldf" or FolderPath endswith ".ndf" or FolderPath endswith ".mdb" or FolderPath endswith ".accdb" or FolderPath endswith ".pst" or FolderPath endswith ".ost") and not ((InitiatingProcessFolderPath endswith "\\sqlservr.exe" or InitiatingProcessFolderPath endswith "\\sqlagent.exe" or InitiatingProcessFolderPath endswith "\\sqlwriter.exe" or InitiatingProcessFolderPath endswith "\\mysqld.exe" or InitiatingProcessFolderPath endswith "\\postgres.exe" or InitiatingProcessFolderPath endswith "\\outlook.exe" or InitiatingProcessFolderPath endswith "\\msaccess.exe")))

Splunk · SPL

Run this as a search.

index=* ((TargetFilename="*.mdf" OR TargetFilename="*.ldf" OR TargetFilename="*.ndf" OR TargetFilename="*.mdb" OR TargetFilename="*.accdb" OR TargetFilename="*.pst" OR TargetFilename="*.ost") AND NOT ((Image="*\\sqlservr.exe" OR Image="*\\sqlagent.exe" OR Image="*\\sqlwriter.exe" OR Image="*\\mysqld.exe" OR Image="*\\postgres.exe" OR Image="*\\outlook.exe" OR Image="*\\msaccess.exe")))

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE ((TO_LOWER(file.path) LIKE "*.mdf" OR TO_LOWER(file.path) LIKE "*.ldf" OR TO_LOWER(file.path) LIKE "*.ndf" OR TO_LOWER(file.path) LIKE "*.mdb" OR TO_LOWER(file.path) LIKE "*.accdb" OR TO_LOWER(file.path) LIKE "*.pst" OR TO_LOWER(file.path) LIKE "*.ost") AND NOT ((TO_LOWER(process.executable) LIKE "*\\\\sqlservr.exe" OR TO_LOWER(process.executable) LIKE "*\\\\sqlagent.exe" OR TO_LOWER(process.executable) LIKE "*\\\\sqlwriter.exe" OR TO_LOWER(process.executable) LIKE "*\\\\mysqld.exe" OR TO_LOWER(process.executable) LIKE "*\\\\postgres.exe" OR TO_LOWER(process.executable) LIKE "*\\\\outlook.exe" OR TO_LOWER(process.executable) LIKE "*\\\\msaccess.exe")))

Wazuh · XML rule

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

<group name="sigma,windows,file_delete,">  <!-- Rule ids must be unique on your manager; 100000+ is the user range. -->  <rule id="100000" level="7">    <!-- Set <if_sid> to the decoder/base rule for windows so this only evaluates relevant events. -->    <field name="TargetFilename" type="pcre2">(?i)(\.mdf$|\.ldf$|\.ndf$|\.mdb$|\.accdb$|\.pst$|\.ost$)</field>    <field name="Image" negate="yes" type="pcre2">(?i)(\\sqlservr\.exe$|\\sqlagent\.exe$|\\sqlwriter\.exe$|\\mysqld\.exe$|\\postgres\.exe$|\\outlook\.exe$|\\msaccess\.exe$)</field>    <description>Stored business data file deleted by a process that does not own it</description>    <mitre>      <id>T1565.001</id>    </mitre>  </rule></group>

At a glance

Logsource: file_delete / windows
Level: medium
Category: impact_destruction
Sigma status: experimental
Backends: 4 of 4 rendered
Updated: 30 Aug 2026
Rule ID: 95361a8a-b91f-43e3-a3ef-f1eafc6f5a1b

ATT&CKT1565.001

T1565.001Stored Data Manipulation

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.

Evidence

Verificationnone

Never run

The lab has not evaluated this composition. A run needs a dataset of its log type — a capture of the technique it claims, or the benign baseline — and not every rule has one. Some are also held back by the evaluator’s own safety limits.

Other compositions here have been run and some carry the badge — this one has not, so nothing about it has been shown either way. Read the rule and its noise check on their own terms; silence here is the absence of evidence, not evidence of a problem.

Noise checknot tested

No baseline event covers this rule’s log type (file_delete / windows), so the rule was never evaluated. This is missing data, not a clean result — nothing was checked either way.

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.

Test it yourselfin your browser

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

Recordings of T1565.001, evaluated against their file_delete events.

Using it

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 more specific file extensions to the selection_stored_data list to narrow down the detection to specific types of business data
Include additional owning applications in the filter_owning_applications list to reduce false positives
Modify the condition to also consider the user or group responsible for the file deletion to further filter out legitimate administrative activity
Consider adding a threshold for the number of files deleted within a certain timeframe to reduce noise from single-file deletions

Declared by the author

Database maintenance done by hand. A DBA detaching a database and deleting its .mdf and .ldf from Explorer, cmd.exe or PowerShell, or a developer resetting a local instance, matches precisely because the deleting image is a shell rather than the engine, and on a shared development server this is the most frequent source.
Antivirus and EDR engines removing a file. A scheduled scan quarantining an infected .pst or .ost attachment store, or deleting a corrupted Access or SQL data file, deletes it under the scanner's own image, which is a non-owning process exactly like an attacker's shell.
Mailbox cache and profile churn driven by something other than outlook.exe — profile migration tooling, a mail-archiving product clearing a stale .ost, or a user deleting an old .pst archive from Explorer.
Installers and uninstallers. msiexec.exe and vendor setup programs remove bundled Access .mdb files and SQL Express data files during an upgrade, a repair run or a clean removal.

Lessonimpact destruction

impact destructionAI draft — unreviewed

01 · What this rule detects

This Sigma rule detects the deletion of stored business data files by a process that does not own them, indicating potential impact destruction. The rule focuses on files with specific extensions related to databases and email, such as .mdf, .mdb, and .pst, which are typically owned and managed by specific applications like SQL Server or Microsoft Outlook.

02 · Telemetry you need

Log source: Windows file deletion events (category: file_delete)
Specific fields: TargetFilename and Image
Audit setting: File deletion events may need to be enabled in the Windows audit policy, which could be off by default

03 · How the logic works

The rule works by first selecting file deletion events where the target filename ends with specific extensions related to business data files (selection_stored_data). It then filters out events where the image (process) responsible for the deletion is a known owning application for these file types (filter_owning_applications). The condition for the detection is met when a file deletion event matches the selection_stored_data criteria but does not match the filter_owning_applications criteria, indicating a potential unauthorized deletion of business data.

04 · Common false positives

Backup and archiving software that may delete files as part of their operation
Antivirus software that may quarantine or delete files
System maintenance tasks that involve cleaning up temporary or unused files
Third-party file management tools used by administrators for legitimate purposes

05 · Detection maturity

tier_1: This rule as written provides a basic detection capability for unauthorized deletion of business data files but may generate false positives due to its broad criteria.
tier_2: With tuning, such as adding more specific file extensions and owning applications, this rule can become more accurate and reduce noise, making it more suitable for production environments.
tier_3: Correlating this rule with other signals, such as suspicious process execution or network activity, can provide a more comprehensive detection capability for impact destruction tactics and improve the overall maturity of the detection strategy.

Related detections3 nearby

Ranked by how alike the detection logic reads, computed offline. Proximity is not evidence — each of these carries its own verification state on its own page.

Share this rule

/u/siemphony/95361a8a-b91f-43e3-a3ef-f1eafc6f5a1b

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.

Stored business data file deleted by a process that does not own it

The detection

detection.yml

Sentinel · KQL

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Community

Verdicts from engineers who deployed it