macOS - Data Collection & Auditing - Get Browser History

What the macOS browser history collector does

This Automox Worklet™ pulls the most recent browser history entries for Google Chrome, Mozilla Firefox, Safari, and Brave from a macOS endpoint and prints them to the Automox Activity Log. The Worklet resolves the last interactive user from the output of last, then walks ~/Library to locate each browser's SQLite history database. Chrome history lives at ~/Library/Application Support/Google/Chrome/Default/History and Brave at ~/Library/Application Support/BraveSoftware/Brave-Browser/Default/History. Firefox stores its profile at ~/Library/Application Support/Firefox/Profiles/*.default-release/places.sqlite, and Safari at ~/Library/Safari/History.db.

For Chrome, Brave, and Firefox the Worklet copies the history database to a working file before reading it, so an open browser session does not lock the source database during the query. Safari is read in place. Each browser's query selects URL, page title, visit timestamp, and (where the schema supports it) visit count, then tail -n trims the output to the most recent entries based on the number_of_lines variable.

Five variables control behavior at the top of remediation.sh: number_of_lines (default 25) and show_chrome_history, show_firefox_history, show_safari_history, and show_brave_history (each on or off). The Worklet only attempts to read a browser's database when the matching /Applications/<browser>.app bundle is present, so absent browsers do not generate noise in the log.

Why pull browser history through Automox

Forensic browser history is one of the highest-signal artifacts in an incident response timeline. When a macOS endpoint shows up in a malware alert, a credential phishing report, or an acceptable use complaint, the URLs visited in the hours before the event matter. They tell the analyst whether the user clicked a drive-by link, hit a typosquatted login page, or downloaded a payload that bypassed the web proxy. Reaching that data manually means physical possession of the Mac, an SSH session into a user-owned profile, or pulling the user off a productive workstation. None of those scale to a multi-site fleet.

Running this Worklet as a FixNow against the affected Mac, or scoping it to a device group during an active incident response, executes the SQLite query, database copy, per-browser gating, and Activity Log output under the Automox Agent's context. The analyst pulls the browser history evidence directly from the console without an SSH session, a screen share, or asking the user to ship a file from a laptop that may be subject to a preservation hold.

How macOS browser history retrieval works

1. Evaluation phase: The Worklet runs last | head -1 | awk '{print $1}' to identify the most recent interactive user. It then uses find against the four canonical history paths under that user's ~/Library tree. If any one of the Chrome History file, Firefox places.sqlite, Safari History.db, or Brave History file exists, the endpoint exits 1 and is flagged for remediation. If none are found, the Worklet exits 0 with a message stating the endpoint is not eligible.

2. Remediation phase: For each browser whose show_<browser>_history variable is on and whose .app bundle is installed, the Worklet copies the SQLite database to a local backup (History.bak, places.sqlite.bak, Brave_History.bak) and runs sqlite3 against it. Chrome and Brave query the urls table for last_visit_time, url, title, and visit_count, converting the Chromium WebKit epoch (last_visit_time/1000000-11644473600). Firefox joins moz_places and moz_historyvisits on place_id. Safari joins history_visits and history_items on history_item, offsetting visit_time by 978307200 for the Cocoa epoch. Each result set is piped through tail -n $number_of_lines and printed to the Activity Log. The working .bak files are removed at the end of each function.

Browser history retrieval requirements

• macOS workstation with Automox Agent 1.42.22 or later (this Worklet is workstation-only by metadata)

• /usr/bin/sqlite3 available (ships with macOS by default)

• Full Disk Access granted to the Automox Agent under System Settings → Privacy and Security → Full Disk Access for Safari history. Without it, the Safari branch logs a permission-denied notice and the other browsers continue normally

• At least one of /Applications/Google Chrome.app, /Applications/Firefox.app, /Applications/Safari.app, or /Applications/Brave Browser.app present on the endpoint

• Edit the variable block at the top of remediation.sh: set number_of_lines to the row cap per browser (default 25) and toggle show_chrome_history, show_firefox_history, show_safari_history, and show_brave_history to on or off

• Inform end users of forensic collection under your acceptable use policy; browser history is personal data in most jurisdictions and pulling it without a documented policy invites a compliance issue

Expected output in the Activity Log

The Worklet opens with a single header line: "This worklet will report the last <N> events of browser history for the user: <username>". Each enabled browser produces a labeled block separated by "=============== <BROWSER> HISTORY ===============". Inside the block, the cp -vp line shows the source and destination of the database copy, followed by the sqlite3 result rows. Each row contains ISO-formatted last-visited timestamp, full URL, page title, and (for Chromium browsers) visit count, pipe-delimited as sqlite3's default output. Disabled browsers print a "Reporting <Browser> history is not enabled. Skipping..." line and produce no rows.

Safari has one expected failure mode worth calling out. If Full Disk Access has not been granted to the Automox Agent, the Safari function logs "an error was encountered while finding the Safari History. This likely means that the Safari directory is protected from within macOS's Security Settings. To use this worklet for Safari, you must enable Full Disk Access for the Automox Agent." The other browsers are unaffected; their history is still collected. Validate a clean run by spot-checking the Chrome block against the user's recent activity, then store the Activity Log entry alongside the policy run ID for chain-of-custody. The Worklet does not modify the source databases, so re-running it produces an identical timeline up to the new tail window.