A browser remembers a lot about its user. MITRE ATT&CK tracks the enumeration of that data as T1217, Browser Information Discovery, in the Discovery tactic. It applies to Linux, macOS and Windows.
How attackers use it
Data saved by browsers, such as bookmarks, accounts and browsing history, may reveal personal information about users, such as banking sites, relationships, interests and social media. It can also reveal details of internal network resources, including servers, tools, dashboards and other infrastructure.
MITRE adds that browser information can highlight further targets once an adversary holds valid credentials, especially credentials in files that are tied to logins cached by the browser.
Browser data is usually stored in local files and databases. The MITRE page gives the Chrome folder under APPDATA on Windows as an example, and locations vary by platform and application.
How to detect it
The detection strategy has an analytic for each platform. The common thread is that something other than the browser reads the browser's files.
- Windows: processes such as PowerShell, cmd.exe or unknown tools accessing browser artifact locations for Chrome, Edge or Firefox, then reading, decoding or exporting bookmarks, autofill or history databases.
- Linux: shells or scripts accessing browser configuration or SQLite history files in places such as the google-chrome and mozilla folders under the home directory.
- macOS: scripting or command line tools reading the Chrome folder under Application Support or the Safari bookmarks, cookies and history databases.
To act on this, you need file access telemetry on those paths, plus process lineage. On Linux, auditd file watch rules on browser profile folders can provide it. On Windows, Sysmon file events or EDR file read telemetry are the usual sources. Expect noise from backup tools and sync clients, so allow list them by name and path after you have confirmed them.
How to reduce the risk
The MITRE record for this technique lists no formal mitigations, because it relies on legitimate access to data the user already owns. Practical steps follow from the technique description itself:
- Do not let browsers save credentials for sensitive internal systems. Use a managed password manager.
- Limit which users and processes can run scripts on endpoints.
- Treat bookmarks and history as sensitive when you handle laptop disposal or incident triage.
Check your own environment
- Do endpoint tools record file reads on browser profile folders?
- Do you have a baseline for which processes legitimately read those folders?
- Is browser password saving governed by policy?
On Linux, this read-only command lists loaded audit rules so you can see whether any watch browser paths:
sudo auditctl -l
Where to start
Begin with the platform where you already have the best telemetry. If you run an endpoint detection tool on Windows, ask whether it records file reads on the browser profile folders and which processes show up. Review the list once. You will likely see backup agents, sync clients and security tools. Mark those as known, then alert on the rest.
On Linux and macOS, a handful of auditd or endpoint rules on the profile directories named in the MITRE analytics is enough to start. The goal is not to block reads of the browser's own files. It is to know when a shell or script is doing it.
Quick check
What is the main signal across all three platforms?
A process that is not the browser reading its bookmark, history or credential stores, often followed by decoding or export.
Why does browser data matter beyond privacy?
It can reveal internal servers and dashboards, and cached logins can give an adversary valid credentials for new targets.
Sources
- MITRE ATT&CK, T1217: https://attack.mitre.org/techniques/T1217
