How T1217 browser information discovery reveals what an attacker learns about a user's browsers
T1217 Browser information discovery is the step where an adversary inventories the web browsers on an endpoint and the data those browsers hold about the user, which is why a discovery event on a workstation deserves triage before it is dismissed. In intrusions, this information shapes what comes next: a browser profile can reveal which web applications the user signs in to, which internal portals are bookmarked, and which password manager or session artifacts are present. For a SOC lead, the question at triage is not only whether a process touched browser folders, but whether the access matches a known administrative or user task. Under the ATT&CK definition, Discovery (TA0007) covers the adversary trying to figure out the environment, and T1217 sits there because the browser is a rich source of environment knowledge that sits outside the operating system's own inventory.
At a high level, an adversary learns several categories of information from browser data. The installed browsers themselves indicate which engines and update channels are in use. Profiles show account identities, synchronized settings and history locations. Extensions can reveal security tooling, password managers or developer utilities, and the locations where browsers store metadata indicate where cookies, saved logins and session data reside. Each category tells an attacker something different about the user's access and the organization's tooling. The mapping in this section targets Enterprise ATT&CK 20.0, so analysts should confirm that their detection content references that version and check the technique's current detection strategies and data components before relying on them. Any browser versions, extension stores or profile paths in your fleet should be confirmed against your own endpoint inventory rather than assumed from defaults.
Which telemetry shows browser information discovery on Linux, macOS and Windows
This table maps the telemetry that typically reveals T1217 activity on each platform to the open-source collector that gathers it. Read each row as a question to answer in your own environment: does this endpoint produce the event, and does the collector keep it long enough to correlate. The main takeaway is that Process Creation and Command Execution carry most of the signal, while File Access shows whether browser profile stores were touched.
| Telemetry (ATT&CK data component) | Signal to look for | Open-source collector | Confirm in your environment |
|---|---|---|---|
| Process Creation (DC0032) | Browser processes launched by unexpected parent processes, or launched headless with unusual arguments on Linux, macOS and Windows | Sysmon-style endpoint logging on Windows, auditd or Wazuh agent on Linux | Which parent-child process events are logged and retained |
| Command Execution (DC0064) | Shell or script activity that invokes a browser binary or inspects its configuration, including interpreter-driven execution | Wazuh agent command logs, Velociraptor artifacts for live collection | Whether full command lines are captured on each platform |
| File Access (DC0055) | Reads of browser profile, cookie, history or login-data stores by processes that are not the browser itself | Wazuh file integrity monitoring on Linux and macOS, Velociraptor file hunts, Sysmon file-access events where configured | Which profile paths are monitored and whether access (not only change) is logged |
| Process Access (DC0035) | A non-browser process opening browser processes or their memory, used as context for credential or artifact collection | Sysmon process access events on Windows, Velociraptor for targeted process review | Whether process access events are enabled and filtered |
| Network context (Zeek, Suricata) | Unusual outbound traffic from the host shortly after browser artifact access, used to corroborate rather than prove activity | Zeek connection logs, Suricata alerts, Security Onion for correlation | Whether sensor coverage includes the segments where endpoints sit |
| Platform gap check | Linux and macOS hosts often produce less file-access telemetry by default than Windows hosts | Wazuh configuration review, collector health reports | Which events each endpoint class actually produces during a test run |
Detection logic for T1217 that SOC teams can tune
The four ideas below pair process context, file access and command execution so that a single browser-data read is never judged alone. Each one names its false positive sources, so teams can separate legitimate browser management from discovery activity. Detection mappings in this section target Enterprise ATT&CK version 20.0, and teams should re-check mappings against the current version before deploying rules.
Non-browser process touching browser profiles
This idea flags a process that is not a browser, updater or sanctioned management agent opening browser profile or configuration locations. The logic is a rule on Process Creation and File Access telemetry where the initiating image is outside an allowlist of known browser binaries and the target path belongs to a browser profile directory. Tune the allowlist per operating system and per fleet, because the allowlist is the main control on noise. Expect false positives from backup agents, endpoint management suites, IT inventory scripts and browser migration tools. Review each hit by parent process and signing certificate before tightening the rule.
Bulk reads of browser data stores
This idea counts how many distinct browser data files a single process reads within a short window. The logic is a threshold on File Access events grouped by process and host, with the window and count set from a baseline of normal behavior on your own endpoints. Start with a high threshold and lower it only after measuring a quiet period. False positives come from password managers, sync clients, forensic and e-discovery collectors, and profile migration during device refresh. Record the exception list with an owner and a review date so suppressions do not become permanent blind spots.
Browser data access from scripting interpreters
This idea looks for command interpreters and scripting runtimes that run in the context of a user and then reach browser data. The logic correlates Command Execution with File Access in the same session, so a shell or script that touches a browser store within a short interval is surfaced for review. Scripted administration is common, so tune by excluding known management scripts signed by your own deployment tooling. Look for scripts that run from user-writable directories or that were launched by an unexpected parent, since those are the cases an analyst should triage first.
Browser configuration enumeration on Linux and macOS
This idea flags commands that list or print browser configuration directories and preference files, using Command Execution telemetry from endpoints where shell history and process arguments are logged. The logic matches directory listing and content printing commands whose arguments point at browser preference paths, filtered to exclude login scripts and configuration management runs. Confirm which command-line auditing you actually collect before writing the rule, because argument capture varies by platform. False positives are common from help desk troubleshooting and from configuration baselining, so route hits to a ticket reference check.
How to validate that the T1217 detection fires
This sequence proves that the T1217 Browser Information Discovery detection fires on the intended telemetry, with the right fidelity, on each platform in scope. It produces a scored test record, a gap log and a tuning backlog that the detection owner can act on.
Define the emulation scenario and scope
The detection owner and the range lead agree on the behavior to emulate: a process or script that reads browser-related files or stores on a lab endpoint, as described at a high level in the ATT&CK T1217 entry. They record the target platforms (Linux, macOS and Windows), the test accounts, the isolated range segment and the ATT&CK version the detection targets. The step is done when the scenario sheet is signed off and every platform in scope has a named owner. Confirm the exact sub-behaviors and any ATT&CK version changes against the current technique page before the range is booked.
Write expected telemetry per platform
Before any test runs, the team writes down which events should appear for each platform, drawn from the data components the detection strategy references, such as Process Creation, Command Execution and File Access. For each source, they note the expected log channel, the field names used in the detection logic and the minimum fields needed to attribute the activity to a user and host. The output is a short expectation matrix that the analyst can check against later. If a log source is not yet collected on a platform, the matrix marks that gap explicitly rather than assuming coverage.
Set pass criteria and recording fields
The team defines pass criteria in advance: the expected events are present in the SIEM within the agreed ingestion window, the rule or analytic produces an alert, and the alert contains the host, user, parent and child process lineage and originating log source. They also define a fail condition for each. For every run, they record timestamps (activity start, event ingestion, alert creation), host identifier, process lineage, log source, rule identifier and alert ID in a common template. Pass criteria should be agreed with the SOC lead, since they decide what counts as a tuning issue.
Execute the emulation and capture raw evidence
An operator runs the agreed scenario on each in-scope lab endpoint while a second person keeps the run log, noting start and stop times. The evidence collector preserves the raw endpoint logs, the Wazuh or SIEM event exports and any Velociraptor artifacts gathered from the host for later comparison. The step is complete when each platform has a labelled evidence package with a hash manifest and the run log is closed. Operators should not improvise beyond the signed-off scenario, because undocumented variations make the results hard to attribute.
Compare results with the detection logic
The analyst lines up the captured events against the expectation matrix and the detection logic, field by field. They check whether each expected event was ingested, whether the field values match what the rule expects and whether the alert fired with the intended severity and context. Each platform receives one of three outcomes: detected, partially detected (for example, telemetry present but rule did not match) or not detected (telemetry missing or unparsed). The result is a scored comparison table that links every outcome to the evidence package.
Document gaps and open a tuning backlog
For each partial or failed result, the analyst records the root cause category: missing log source, parsing or field mapping error, logic that is too narrow, or logic that is too broad and generates noise from legitimate administration. Each gap becomes a tracked item with an owner, a linked evidence reference and a retest requirement. The step is done when every non-passing platform has an open item and the detection owner has reviewed the list. This backlog, not the single test run, is the basis for tuning decisions.
Retest after tuning and retain the record
After fixes are deployed, the team reruns the same scenario on the same platforms and compares results with the original baseline, so the change is visibly an improvement rather than a new untested rule. They keep the scenario, expectation matrix, evidence and final scores under version control, tagged with the ATT&CK version and detection identifier. The output is a dated validation record that the SOC, compliance team and any independent assessor can review. Confirm with the internal audit or assessment body what retention and evidence format they expect.
Preventive controls that reduce browser information discovery exposure
Browser information discovery succeeds when a process running as a user can read browser profile data and nothing notices. The four ATT&CK mitigations below narrow what a process can reach, how accounts are managed, which features exist on a host, and what gets recorded. Confirm each mapping against the ATT&CK page for T1217 for the ATT&CK version your environment targets.
Audit to make profile access visible
Audit (M1047) covers configuring the host and platform to record activity that matters for discovery, such as reads of browser profile directories, credential stores and cookie databases. Without that record, a file read by a trusted browser process looks like normal use. Check that file access auditing is enabled for the browser profile paths on each operating system you support, that logs are forwarded off the host, and that someone reviews the output. Confirm the specific audit settings against the ATT&CK page for T1217.
Operating system configuration of profile paths
Operating System Configuration (M1028) reduces exposure by tightening how the operating system protects user data. On Linux and macOS, restrictive file permissions and access controls on browser profile directories limit which local processes can read stored session and history data. On Windows, the equivalent is correct NTFS permissions on user profile data. Check that default permissions have not been widened by image builds, configuration management or third-party software, and test them on each supported build.
Removing unneeded browsers and extensions
Disable or Remove Feature or Program (M1042) reduces the number of places discovery can look. Every installed browser, browser profile and extension adds stored data and another process that can be abused. On managed endpoints, inventory which browsers and extensions are actually needed, remove the rest, and disable features such as sync or password storage where the business does not require them. Track exceptions in writing so that approved software remains known to the security team.
Account management limits what a session exposes
User Account Management (M1018) controls which accounts can log on to a host and what each account can reach. Browser profiles usually hold the sessions and saved credentials of the account that owns them, so over-privileged or shared accounts widen the impact of a successful read. Review standard and administrative accounts on endpoints, separate administrative browsing from daily browsing, and confirm that saved sessions for privileged services are not stored in general-purpose browsers.
Triage and response when a T1217 alert fires
The first decision on any T1217 alert is whether it reflects real browser inventory activity or an unexpected process reading browser data. Validate the alert against the raw Process Creation and Command Execution events for the host before escalating: confirm the exact binary, its hash and path, and whether the event fields match what the rule expects. Then establish process lineage. Identify the parent process, the launching user and session, and whether the activity came from an interactive logon or a scheduled or management agent. Record the user context alongside the host name so the investigation can be tied to an identity, not just a machine. Next, check for an approved browser management or inventory job in the change calendar and in the configuration management or endpoint tooling that runs such jobs. Ask the owning team for the job name, schedule and target group. A match with an approved job, on the expected host and account, is a strong reason to close the alert with a documented note, and a mismatch is a reason to keep going.
Correlate the alert with other Discovery events on the same host within the same window, such as process, account, group or network enumeration recorded in your Wazuh or Security Onion data. A single browser-data read is weak evidence on its own, while a sequence of Discovery activity from one account is a stronger signal, so treat clusters as higher priority. Before any containment step, preserve evidence. Velociraptor or a comparable collection tool can gather the relevant artifacts, such as process listings, command history, browser profile file metadata and recent logon records, while the host is still in its current state. Document the collection time, the operator and the hash of each artifact. Confirm the retention and chain-of-custody steps with your legal and forensics teams, since the required handling depends on your own policies and any regulatory duties. Escalate to incident response when the activity is unapproved, involves a privileged or service account, occurs alongside credential access or lateral movement indicators, or cannot be explained within your agreed triage window. Containment, such as isolating the endpoint or disabling the account, should follow the escalation decision and your playbook.
Rehearsing T1217 detection in a private cyber range
A useful range for T1217 needs endpoints on all three operating systems in the scope of the detection, plus a log pipeline that collects the same telemetry you rely on in production. Include Linux, macOS and Windows workstations, each with a monitored user profile that has a realistic set of installed browsers and extensions. Route endpoint events into Wazuh or Security Onion so the team can test whether Process Creation, Command Execution and File Access records arrive intact and with usable fields. Keep the range network isolated from production and from the internet, and document every system's role in a topology diagram.
- Endpoint coverage: Confirm that each operating system produces the data components your analytics depend on, and record any gaps per platform.
- Log pipeline: Verify the path from agent to manager to analyst console, including parsing and field mapping for browser profile paths.
- Monitored workstation: Use a user workstation that mirrors your standard image so detections are tested against your real configuration choices.
- Time synchronization: Ensure all range hosts and the log pipeline share a reliable time source so alert timelines can be reconstructed.
- Versioning: Record the ATT&CK version your detection mappings target, since techniques can be renamed or revoked between releases.
Before the first exercise, ask your platform team to confirm the agent versions, retention settings and parsing rules in writing.
Scenario design determines whether the exercise tests detection logic or just confirms what the team already expects. Start with a benign discovery-style scenario in which a test account reads browser profile locations and enumerates installed browser data, using steps that a range operator documents in advance. Pair it with a noisy but legitimate admin inventory job, such as a scheduled software or browser compliance scan run by an endpoint management tool, as a false positive control. The control shows whether analysts can distinguish sanctioned inventory from unexpected discovery, and whether the tuning you made is too broad.
- Benign discovery scenario: Script the steps in a runbook so the same exercise can be repeated after rule changes.
- False positive control: Run the admin inventory job on a schedule that matches your production pattern, not just once.
- Variation across platforms: Repeat the scenario on Linux, macOS and Windows so the results are comparable.
- Injected context: Include a short note in the ticket queue that describes the sanctioned job, so triage practice reflects real analyst conditions.
- Scenario labels: Tag every inject with an identifier so detection results can be matched to the exact action taken.
Confirm with your range operator and legal or HR owners that the monitored user accounts and their data handling are approved for exercise use.
A rule that fires is only the start of a good result. Measure how long it takes from the endpoint action to the alert appearing in the console, and whether the alert contains enough context for an analyst to decide quickly. Review triage quality by asking whether the analyst identified the process, user and browser profile involved, and whether they correctly classified the sanctioned inventory job as expected activity. Record every decision and its reasoning, because documentation is what lets you tune rules and show auditors how detection was validated.
- Alert latency: Record the interval between the inject and the alert for each platform, and set a target with your own operations team.
- Triage quality: Score whether analysts gathered the right evidence before escalating or closing.
- False positive handling: Check that the admin inventory job was closed with a clear, repeatable reason, not a blanket exception.
- Response actions: Confirm that the runbook steps for isolating an endpoint or collecting artifacts were followed and timed.
- Documentation: Keep the exercise report, rule versions, data sources and findings in one place linked to the ATT&CK version you tested.
After each exercise, ask your team to confirm which findings they will fix, who owns each fix, and when the scenario will be rerun to verify it.
Questions detection engineers ask about T1217 browser information discovery
How do I separate T1217 browser information discovery from normal browser updates and profile activity?
Start by scoping on behavior, not on the browser binary. Normal browser updates, sync and extension activity touch the browser's own profile and update paths, while T1217 activity shows a non-browser process or an unexpected command reading the browser's profile databases, saved data or extension configuration. Build your baseline from a sample of managed endpoints first, then record which parent processes, users and file paths normally touch browser profile data. Alert on the deviation: a script interpreter, a scheduled task or an unfamiliar binary opening profile files is far more telling than the browser itself running. Confirm the exact analytic logic against the detection strategies for T1217 in the ATT&CK version you target, since ATT&CK v20.0 is the mapping this page uses.
Which data components should I prioritize for T1217 detection?
Prioritize File Access, Process Creation and Command Execution. File Access reveals reads of browser profile stores, which is the core signal for this technique. Process Creation gives you the parent and child relationships that tell you whether a browser-data read came from a legitimate browser or from an unexpected tool. Command Execution adds the arguments and interpreter context that help you triage an alert quickly. OS API Execution can add depth on Windows where your sensor supports it. Confirm which of these data components your chosen sensor actually emits on each operating system before you write rules against them, because coverage varies by platform and agent version.
How do I handle telemetry gaps between macOS, Linux and Windows?
Treat each platform as its own detection surface with its own confirmed data sources. Windows endpoints usually give the richest process and file telemetry through native event logging and an agent, while macOS and Linux often need an endpoint agent or audit configuration to capture file access at a useful level. Document, for each platform, which events you actually receive, which fields they include and where they are missing. Where a gap exists, use compensating controls such as monitoring the browser profile paths through file integrity tooling, or tightening process creation logging. Record the gap in your coverage matrix so reviewers see an honest picture rather than an assumed one.
How do I tune T1217 rules to reduce false positives?
Tune by allowlisting known-good process paths, signed vendor binaries, and approved backup, password manager and synchronization tools that legitimately read browser data. Add context such as user, host group and time window, and require a non-browser process before alerting. Review the top alert sources for two to four weeks, then document each exclusion with its owner and reason so exceptions remain auditable. Avoid broad exclusions on common directory names, since those create blind spots an attacker can use. Re-validate the tuned rule after every endpoint agent upgrade, because field names and event shapes can change.
How do I map my T1217 detections to ATT&CK v20.0 IDs?
Map by technique ID and sub-technique ID, and record the ATT&CK version next to every rule. T1217 is the technique ID, and detection content should reference its detection strategies and analytics as published for the version you target. The ATT&CK v18 release replaced technique-level detections with detection strategies and analytics and moved to data components, so older rule libraries may point at retired fields. Download the enterprise-attack STIX bundle for the version you target and script a check that flags any rule referencing a deprecated or revoked ID. Keep the mapping in version control so each detection shows its ATT&CK version, owner and last validation date.
How do I test T1217 detections after an ATT&CK release?
Re-run your validation after every ATT&CK release that touches Discovery content, and before you promote changed rules to production. First diff the STIX bundle for T1217 and any related techniques to see whether IDs, names, data components or detection strategies changed. Then replay recorded or simulated telemetry in a private cyber range that mirrors your endpoint estate, and confirm that each analytic still fires on the expected behavior and stays quiet on the baseline. Keep a short test log with the ATT&CK version, rule version, dataset and result. Do the same after any sensor upgrade, since a changed field name can silently break a rule that previously worked.
Can my own team run this detection work, or do we need outside help?
Many teams can build and maintain T1217 detections in house if they already run a SIEM, an endpoint agent and a process for rule change control. The work usually splits into four parts: confirming telemetry per operating system, writing and tuning analytics, validating them in a test environment, and keeping mappings current with each ATT&CK release. Outside help is most useful when you need a fixed-scope rollout across several platforms, a private cyber range for repeatable exercises, or an independent test of your coverage. DeployOpen implements and hardens self-hosted open-source platforms inside your own environment and runs cyber range exercises, and scope and deliverables are agreed in writing before work starts.
How DeployOpen builds T1217 detections and range exercises
DeployOpen approaches T1217 Browser information discovery as a fixed-scope piece of platform work inside the client's own environment. The work covers the telemetry, detection logic and cyber range rehearsal needed to see browser information discovery on Linux, macOS and Windows, documented so the client's own team can run it.
How we scope
- Confirm which operating systems, browsers and endpoint telemetry sources are in the written scope for T1217.
- Agree which ATT&CK version the detection mappings will target, and record it in the scope document.
- Identify which Process Creation, Command Execution and File Access sources the client already collects and which need enabling.
How we build
- Implement open-source collection and detection logic in the client's SIEM stack, such as Wazuh or Security Onion, as agreed in scope.
- Map candidate detections to the ATT&CK detection strategies and data components that apply to T1217 for the chosen version.
- Test detection content against benign browser activity in a private cyber range before it reaches production monitoring.
How we hand over
- Deliver detection rules, configuration and tuning notes that name the data sources each rule depends on.
- Provide range exercise runbooks so the client's analysts can rehearse detection and response for T1217 themselves.
- Document validation results, known blind spots and the evidence needed for compliance readiness reviews.
How we support
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and continuous testing for T1217 detections are available as a retainer.
- Ask any quote to itemize one-time build work separately from recurring support, tuning and ATT&CK version updates.
