Non-browser process writes into a browser session cookie store

Siemphony@siemphonylowT1606.001unverified

Matches AN0484's observable: a process outside the browser itself creating a file inside a browser's session-cookie store. That is the forge-and-present half of this technique — a cookie value the adversary generated is injected into the store so the browser presents it as a live session — and it is deliberately a different observable from T1539's rule already in this corpus, which matches a process naming a cookie database on its command line and is the read-and-steal half. MITRE's BrowserCookiePaths knob names the paths to watch; the three fragments matched here are authored from the Chromium layout where the store sits under a per-profile Network directory, the older User Data\Default location, and Firefox's cookies.sqlite. The ProcessWhitelist knob maps onto the browser filter, which is where an approved profile-migration or backup agent belongs. Two limits are structural rather than tunable. Sysmon EventID 11 is file *creation*, so an in-place SQLite update of an existing Cookies file raises nothing by itself; what makes the write visible is the journal and WAL sidecars the engine creates alongside it, which is why the fragments are substrings rather than exact paths. And the store's own filename has no extension, so the FileCreate section of most shipped Sysmon configurations — which include by extension — will not record it unless a path rule for these directories is added first; without that this rule returns zero rows while looking healthy. This rule is written in the Sysmon-shaped file_event vocabulary (TargetFilename, Image). AN0485's Linux leg was not used: its only Linux log source is raw auditd, where the accessed path arrives on a PATH record and the accessing binary on the paired SYSCALL record, so "a process outside the browser" cannot be expressed within one record and the rule would fire on the browser itself on every launch. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0171, 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 contains "\\Network\\Cookies" or FolderPath contains "\\User Data\\Default\\Cookies" or FolderPath contains "cookies.sqlite") and not ((InitiatingProcessFolderPath endswith "\\chrome.exe" or InitiatingProcessFolderPath endswith "\\msedge.exe" or InitiatingProcessFolderPath endswith "\\firefox.exe" or InitiatingProcessFolderPath endswith "\\brave.exe" or InitiatingProcessFolderPath endswith "\\opera.exe" or InitiatingProcessFolderPath endswith "\\vivaldi.exe" or InitiatingProcessFolderPath endswith "\\chromium.exe")))

Splunk · SPL

Run this as a search.

index=* ((TargetFilename="*\\Network\\Cookies*" OR TargetFilename="*\\User Data\\Default\\Cookies*" OR TargetFilename="*cookies.sqlite*") AND NOT ((Image="*\\chrome.exe" OR Image="*\\msedge.exe" OR Image="*\\firefox.exe" OR Image="*\\brave.exe" OR Image="*\\opera.exe" OR Image="*\\vivaldi.exe" OR Image="*\\chromium.exe")))

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE ((TO_LOWER(file.path) LIKE "*\\\\network\\\\cookies*" OR TO_LOWER(file.path) LIKE "*\\\\user data\\\\default\\\\cookies*" OR TO_LOWER(file.path) LIKE "*cookies.sqlite*") AND NOT ((TO_LOWER(process.executable) LIKE "*\\\\chrome.exe" OR TO_LOWER(process.executable) LIKE "*\\\\msedge.exe" OR TO_LOWER(process.executable) LIKE "*\\\\firefox.exe" OR TO_LOWER(process.executable) LIKE "*\\\\brave.exe" OR TO_LOWER(process.executable) LIKE "*\\\\opera.exe" OR TO_LOWER(process.executable) LIKE "*\\\\vivaldi.exe" OR TO_LOWER(process.executable) LIKE "*\\\\chromium.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)(\\Network\\Cookies|\\User Data\\Default\\Cookies|cookies\.sqlite)</field>    <field name="Image" negate="yes" type="pcre2">(?i)(\\chrome\.exe$|\\msedge\.exe$|\\firefox\.exe$|\\brave\.exe$|\\opera\.exe$|\\vivaldi\.exe$|\\chromium\.exe$)</field>    <description>Non-browser process writes into a browser session cookie store</description>    <mitre>      <id>T1606.001</id>    </mitre>  </rule></group>

At a glance

Logsource: file_event / windows
Level: low
Category: browser_credential_theft
Sigma status: experimental
Backends: 4 of 4 rendered
Updated: 30 Aug 2026
Rule ID: 6429330a-0692-4d34-a7e5-66126802ffcc

ATT&CKT1606.001

T1606.001Web Cookies

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.

Lessonbrowser credential theft

browser credential theft

01 · What this rule detects

Access to what a browser keeps on disk and in memory: the saved-password database, the cookie store, and the keys that protect them. Cookies are usually the real target, because a stolen session token is a logged-in session that has already satisfied multi-factor authentication. The theft itself is quiet — a file copy — so the detection has to be about who is touching those paths, not about what happens next.

02 · Telemetry you need

Sysmon EventID 11 (FileCreate) and EventID 1 command lines for copies of the profile store — Login Data, the Cookies database under the profile's Network directory, Local State, logins.json and key4.db
Sysmon EventID 10 (ProcessAccess) with TargetImage set to the browser, for the memory-reading route that app-bound encryption pushes attackers towards
Security 4663 (object access) on the browser profile directory — requires Audit Object Access and a SACL applied to that directory; without the SACL the rule returns nothing and reads as clean
Sysmon EventID 3 (NetworkConnect) from the process that performed the read, which is what turns a file copy into an incident
DPAPI master key activity where it is collected — the Crypto-DPAPI operational log is not enabled by default, and Security 4692 covers only the backup path

03 · How the logic works

The path is the anchor. The rule is: a file or handle event against a browser credential store where the accessing image is not the browser that owns it, with a short allowlist for the tools that legitimately touch profiles. That is dramatically more durable than matching infostealer binary names, which change constantly and are the one thing the attacker can rename for free. The maintenance burden sits in the paths themselves: Chromium moved the cookie database into a Network subdirectory of the profile and later added app-bound encryption, so a rule that hardcodes an older layout keeps validating, keeps deploying, and quietly matches nothing after a browser update. Check the paths against a real profile on a current build rather than against an example, and keep the memory-access rule alongside the file rule, because hardening the file has pushed the technique towards the running process.

04 · Common false positives

Endpoint backup and file sync agents that include the user profile, and roaming profile or folder redirection
Profile management in virtual desktop environments — FSLogix, Citrix profile management and similar containers
Browser migration and password-manager import tooling, which reads exactly these files on purpose
Antivirus and DLP agents scanning the profile directory, and forensic or e-discovery collection agents
The browser's own updater and secondary installs running from a different path than the one you allowlisted

05 · Detection maturity

Tier 1 — starting point: Matches known credential-stealer binary names and obvious copy command lines against the profile.
Tier 2 — tuned: Matches any non-browser process touching the credential and cookie stores, allowlisted by signed path.
Tier 3 — correlated: Adds browser memory access and correlates the read with the accessing process's origin, signature and outbound activity.

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

Allowlist by full signed path of the accessing process; a filename allowlist is an invitation to name a binary chrome.exe
Re-derive the store paths after major browser releases and treat that as maintenance the rule owns, not an incident to discover later
Alert far louder when the same process that read the store makes an outbound connection shortly afterwards
Cover the Chromium family and Firefox separately — the file layout, the key material and the sensible allowlists differ
Scope by directory rather than by exact filename where the telemetry allows, so a tool you have never heard of still trips the rule

Declared by the author

Profile-roaming and folder-redirection agents that write a user profile back onto disk at logon — FSLogix, OneDrive known-folder move, VDI profile containers and roaming-profile services all recreate the cookie store and its journal under their own service binary, and on a managed fleet this is the largest source of hits by a wide margin.
Backup, restore and endpoint-DLP agents that walk the user profile by absolute path, plus antivirus quarantine-restore, all of which create the same files under a vendor binary rather than under the browser.
Browser automation and test harnesses that seed a profile directory before a run — the store is written by chromedriver.exe, node.exe or the test runner, never by the browser image the filter excludes, so an ordinary CI build matches.
Enterprise browser deployment and migration tooling that imports an existing profile when a user is moved between browsers or between machines, which is exactly a non-browser process populating a cookie store.

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 T1606.001, evaluated against their file_event events.

Share this rule

/u/siemphony/6429330a-0692-4d34-a7e5-66126802ffcc

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.

Non-browser process writes into a browser session cookie store

The detection

detection.yml

Sentinel · KQL

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Community

Verdicts from engineers who deployed it