Database or ledger file created by a script host or LOLBin

Siemphony@siemphonylowT1565unverifiedPlaybook · Destructive impact

Matches a file-create event where a database, ledger or embedded-store file is laid down by a scripting host, a signed-binary proxy or a transfer utility rather than by the engine that owns it, which is the "abnormal changes to structured data outside expected business process activity" half of AN0162. Read the scope narrowly: this is suspicious data-store file *creation*, not detection of records being altered in place. Sysmon EventID 11 fires on create and overwrite only, so a row edited through the application or through SQL produces nothing here, and a freshly dropped store is at least as consistent with T1074-style local staging as with manipulation meant to deceive — the rule cannot separate the two. The brief's EventID 2 (`file_change`) source sits closer to genuine in-place manipulation but is a different logsource and needs its own rule. It also stands in for the stored-data case at the parent level: this is really T1565.001 territory, and when a T1565.001 rule is authored the two should be revisited and merged, with the parent left to carry .002 (transmitted) and .003 (runtime), neither of which this logic touches. Both lists are assembled here: MITRE names the `MonitoredFilePaths` and `AuthorizedProcesses` knobs, and a site should replace the extension list with its own critical data formats and the process list with the services that are actually entitled to write them. The rule is written in the Sysmon EventID 11 vocabulary (`TargetFilename`, `Image`); the Security EventID 4663 feed the brief also maps onto `file_event` splits the same facts into `ObjectName` and `ProcessName`, so it needs a field mapping before a SACL on the data directory would buy anything. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0059, 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: Database or ledger file created by a script host or LOLBin2id: e8c7777d-947b-4c81-b66b-99b3838612263status: experimental4description: |5  Matches a file-create event where a database, ledger or embedded-store file is6  laid down by a scripting host, a signed-binary proxy or a transfer utility7  rather than by the engine that owns it, which is the "abnormal changes to8  structured data outside expected business process activity" half of AN0162.9  Read the scope narrowly: this is suspicious data-store file *creation*, not10  detection of records being altered in place. Sysmon EventID 11 fires on11  create and overwrite only, so a row edited through the application or through12  SQL produces nothing here, and a freshly dropped store is at least as13  consistent with T1074-style local staging as with manipulation meant to14  deceive — the rule cannot separate the two. The brief's EventID 215  (`file_change`) source sits closer to genuine in-place manipulation but is a16  different logsource and needs its own rule. It also stands in for the17  stored-data case at the parent level: this is really T1565.001 territory, and18  when a T1565.001 rule is authored the two should be revisited and merged,19  with the parent left to carry .002 (transmitted) and .003 (runtime), neither20  of which this logic touches. Both lists are assembled here: MITRE names the21  `MonitoredFilePaths` and `AuthorizedProcesses` knobs, and a site should22  replace the extension list with its own critical data formats and the process23  list with the services that are actually entitled to write them. The rule is24  written in the Sysmon EventID 11 vocabulary (`TargetFilename`, `Image`); the25  Security EventID 4663 feed the brief also maps onto `file_event` splits the26  same facts into `ObjectName` and `ProcessName`, so it needs a field mapping27  before a SACL on the data directory would buy anything.28  UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0059, not hand-written and not tested by its author. Any lab result is on this rule's own page.29references:30  - https://attack.mitre.org/techniques/T156531  - https://attack.mitre.org/detectionstrategies/DET005932author: Siemphony pipeline (machine-derived from MITRE ATT&CK v19.2)33date: 2026-08-1634tags:35  - attack.impact36  - attack.t156537logsource:38  category: file_event39  product: windows40detection:41  selection_data:42    TargetFilename|endswith:43      - '.mdf'44      - '.ldf'45      - '.ndf'46      - '.mdb'47      - '.accdb'48      - '.sqlite'49      - '.sqlite3'50      - '.db'51      - '.dbf'52      - '.gdb'53      - '.qbw'54  selection_process:55    Image|endswith:56      - '\powershell.exe'57      - '\pwsh.exe'58      - '\cmd.exe'59      - '\wscript.exe'60      - '\cscript.exe'61      - '\mshta.exe'62      - '\rundll32.exe'63      - '\regsvr32.exe'64      - '\certutil.exe'65      - '\curl.exe'66      - '\python.exe'67      - '\pythonw.exe'68      - '\notepad.exe'69  condition: selection_data and selection_process70falsepositives:71  - "Developer, build and automation hosts. There, Python and PowerShell create .db and .sqlite files as a matter of routine and this is the highest-volume match by a wide margin across the whole rule."72  - "Backup, restore and migration windows: a scripted restore lays down .mdf and .ldf under a service account, and curl or PowerShell staging an .accdb or .mdb copy before a cutover matches the same way."73  - "Endpoint protection and backup agents that quarantine and recreate a live store in place during on-access scanning, where the recreate step runs through a PowerShell or cmd wrapper rather than the agent binary itself."74  - "Reporting and ETL jobs that regenerate an Access or dBase extract on a schedule for finance or BI teams, writing the file through cscript.exe or PowerShell on every cycle."75  - "Application installers and first-run setup that seed an empty SQLite or Access store for a line-of-business tool, unpacked by a script wrapper rather than by the application itself."76level: low

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 ".sqlite" or FolderPath endswith ".sqlite3" or FolderPath endswith ".db" or FolderPath endswith ".dbf" or FolderPath endswith ".gdb" or FolderPath endswith ".qbw") and (InitiatingProcessFolderPath endswith "\\powershell.exe" or InitiatingProcessFolderPath endswith "\\pwsh.exe" or InitiatingProcessFolderPath endswith "\\cmd.exe" or InitiatingProcessFolderPath endswith "\\wscript.exe" or InitiatingProcessFolderPath endswith "\\cscript.exe" or InitiatingProcessFolderPath endswith "\\mshta.exe" or InitiatingProcessFolderPath endswith "\\rundll32.exe" or InitiatingProcessFolderPath endswith "\\regsvr32.exe" or InitiatingProcessFolderPath endswith "\\certutil.exe" or InitiatingProcessFolderPath endswith "\\curl.exe" or InitiatingProcessFolderPath endswith "\\python.exe" or InitiatingProcessFolderPath endswith "\\pythonw.exe" or InitiatingProcessFolderPath endswith "\\notepad.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="*.sqlite" OR TargetFilename="*.sqlite3" OR TargetFilename="*.db" OR TargetFilename="*.dbf" OR TargetFilename="*.gdb" OR TargetFilename="*.qbw") AND (Image="*\\powershell.exe" OR Image="*\\pwsh.exe" OR Image="*\\cmd.exe" OR Image="*\\wscript.exe" OR Image="*\\cscript.exe" OR Image="*\\mshta.exe" OR Image="*\\rundll32.exe" OR Image="*\\regsvr32.exe" OR Image="*\\certutil.exe" OR Image="*\\curl.exe" OR Image="*\\python.exe" OR Image="*\\pythonw.exe" OR Image="*\\notepad.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 "*.sqlite" OR TO_LOWER(file.path) LIKE "*.sqlite3" OR TO_LOWER(file.path) LIKE "*.db" OR TO_LOWER(file.path) LIKE "*.dbf" OR TO_LOWER(file.path) LIKE "*.gdb" OR TO_LOWER(file.path) LIKE "*.qbw") AND (TO_LOWER(process.executable) LIKE "*\\\\powershell.exe" OR TO_LOWER(process.executable) LIKE "*\\\\pwsh.exe" OR TO_LOWER(process.executable) LIKE "*\\\\cmd.exe" OR TO_LOWER(process.executable) LIKE "*\\\\wscript.exe" OR TO_LOWER(process.executable) LIKE "*\\\\cscript.exe" OR TO_LOWER(process.executable) LIKE "*\\\\mshta.exe" OR TO_LOWER(process.executable) LIKE "*\\\\rundll32.exe" OR TO_LOWER(process.executable) LIKE "*\\\\regsvr32.exe" OR TO_LOWER(process.executable) LIKE "*\\\\certutil.exe" OR TO_LOWER(process.executable) LIKE "*\\\\curl.exe" OR TO_LOWER(process.executable) LIKE "*\\\\python.exe" OR TO_LOWER(process.executable) LIKE "*\\\\pythonw.exe" OR TO_LOWER(process.executable) LIKE "*\\\\notepad.exe"))

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)(\.mdf$|\.ldf$|\.ndf$|\.mdb$|\.accdb$|\.sqlite$|\.sqlite3$|\.db$|\.dbf$|\.gdb$|\.qbw$)</field>    <field name="Image" type="pcre2">(?i)(\\powershell\.exe$|\\pwsh\.exe$|\\cmd\.exe$|\\wscript\.exe$|\\cscript\.exe$|\\mshta\.exe$|\\rundll32\.exe$|\\regsvr32\.exe$|\\certutil\.exe$|\\curl\.exe$|\\python\.exe$|\\pythonw\.exe$|\\notepad\.exe$)</field>    <description>Database or ledger file created by a script host or LOLBin</description>    <mitre>      <id>T1565</id>    </mitre>  </rule></group>

At a glance

Logsource: file_event / windows
Level: low
Category: impact_destruction
Sigma status: experimental
Backends: 4 of 4 rendered
Updated: 30 Aug 2026
Rule ID: e8c7777d-947b-4c81-b66b-99b383861226

ATT&CKT1565

T1565Data 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

Verification1 run

Not verified

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

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.

Test it yourselfin your browser

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

Recordings of T1565, evaluated against their file_event events.

Using it

Tuning & false positivesexperimental · 5 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 additional file extensions to the selection_data selection to include other types of database or ledger files
Remove processes from the selection_process selection that are known to be used for legitimate purposes in your environment
Add a filter to exclude files created in specific directories or by specific users
Consider adding a threshold for the number of file creation events within a certain time period to reduce noise

Declared by the author

Developer, build and automation hosts. There, Python and PowerShell create .db and .sqlite files as a matter of routine and this is the highest-volume match by a wide margin across the whole rule.
Backup, restore and migration windows: a scripted restore lays down .mdf and .ldf under a service account, and curl or PowerShell staging an .accdb or .mdb copy before a cutover matches the same way.
Endpoint protection and backup agents that quarantine and recreate a live store in place during on-access scanning, where the recreate step runs through a PowerShell or cmd wrapper rather than the agent binary itself.
Reporting and ETL jobs that regenerate an Access or dBase extract on a schedule for finance or BI teams, writing the file through cscript.exe or PowerShell on every cycle.
Application installers and first-run setup that seed an empty SQLite or Access store for a line-of-business tool, unpacked by a script wrapper rather than by the application itself.

Lessonimpact destruction

impact destructionAI draft — unreviewed

01 · What this rule detects

This Sigma rule detects the creation of database or ledger files by a script host or Living Off The Land Binary (LOLBin), which could indicate malicious activity such as data exfiltration or ransomware. The rule focuses on files with specific extensions that are typically associated with databases or financial data, and it looks for these files being created by processes that are often used for scripting or executing malicious code.

02 · Telemetry you need

Log source: file_event
Product: windows
Specific fields: TargetFilename, Image
Audit setting: File creation events must be audited, which may be off by default depending on the system configuration

03 · How the logic works

The rule uses two selections: selection_data and selection_process. The selection_data selection looks for files with specific extensions (such as .mdf, .ldf, .mdb, etc.) using the TargetFilename field. The selection_process selection looks for processes that are known script hosts or LOLBins (such as powershell.exe, cmd.exe, wscript.exe, etc.) using the Image field. The condition then requires both selections to be true, meaning that the file creation event must involve one of the specified file extensions and one of the specified processes.

04 · Common false positives

Legitimate database administration tools creating database files
Financial software creating ledger files
Scripting processes used for automated system maintenance or deployment
Development environments where developers are creating and testing database files

05 · Detection maturity

tier_1: This rule as written may generate a high volume of false positives due to its broad selection criteria.
tier_2: With tuning, such as adding filters and thresholds, this rule can become more effective at detecting malicious activity while reducing noise.
tier_3: Correlating this rule with other signals, such as network traffic or system calls, can help to further confirm the detection of malicious activity and provide a more comprehensive understanding of the attack.

Related detections6 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/e8c7777d-947b-4c81-b66b-99b383861226

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.

Database or ledger file created by a script host or LOLBin

The detection

detection.yml

Sentinel · KQL

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Community

Verdicts from engineers who deployed it