Windows - Security - Retrieve Last Logged-In User Browser History

What the Windows browser history retrieval Worklet does

This Automox Worklet™ retrieves browser history for the last logged-on user on a Windows endpoint. The script identifies that user by querying local accounts via Get-LocalUser, sorts by the LastLogon property to find the most recent session, and then looks up that user's profile directory from the ProfileImagePath value in the registry under HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList. It then reads the Chrome, Microsoft Edge, and Brave Browser History databases out of %LOCALAPPDATA% and writes the parsed URLs to the Automox activity log so a security analyst can review them without opening a session on the endpoint.

Each Chromium-based browser stores browsing history in a SQLite database named History inside its user-data directory: Chrome at AppData\Local\Google\Chrome\User Data\Default\History, Edge at AppData\Local\Microsoft\Edge\User Data\Default\History, and Brave at AppData\Local\BraveSoftware\Brave-Browser\User Data\Default\History. The Worklet reads these files directly with Get-Content and extracts URL records using regex pattern matching against the raw database bytes. The regex matches http, https, ftp, smb, and sftp scheme URLs; internal browser scheme URLs (chrome://, edge://, brave://) are not present in the output because the pattern does not match them.

By default, the Worklet returns the 50 most recent URL records per browser. Set the numSites policy variable to 0 to retrieve the full history for that user. The script also supports non-standard profile locations, including folder redirection, roaming profile shares, and user profile disks on Remote Desktop Services hosts, because it resolves the profile path from the registry rather than assuming a fixed path.

Why retrieve last-user browser history on Windows

Browser history is one of the highest-signal artifacts on a Windows endpoint during an incident. Phishing follow-ups, drive-by malware sites, exfiltration to a cloud storage URL, policy-violating downloads, and data-loss-prevention triggers all leave traces in the Chrome, Edge, or Brave History database before other tools catch up. Pulling that history quickly -- without touching the endpoint -- is often the difference between a contained event and extended dwell time. Acceptable-use policy reviews and HR investigations follow the same workflow: retrieve the URLs, then decide the next step.

Triggering this Worklet from the Automox console acts on the endpoint the moment a security or HR ticket lands, instead of scheduling a technician visit or waiting for an after-hours window. You can target a single named Windows endpoint on demand, or scope the Worklet to an endpoint group for a wider investigation. Output is consistent across runs, making it straightforward to archive the activity-log entry alongside the policy run identifier as part of a case record.

How last-user browser history retrieval works

1. Evaluation phase: The evaluation script always exits with code 1 to trigger remediation on every run. There is no conditional check; the Worklet is designed to run the remediation script unconditionally.

2. Remediation phase: The remediation script calls Get-LocalUser, sorts accounts by LastLogon descending, and takes the first result to identify the target user. It retrieves that user's ProfileImagePath from the registry, then reads each supported browser's History file directly using Get-Content. URL records are extracted with a regex pattern, and the script selects the last numSites entries from the matched list (50 by default; 0 returns all). Results are printed per browser with each line showing the host domain and full URL. The Worklet exits 0 on a successful read and exits 2 if the user or profile path cannot be resolved.

Browser history retrieval requirements

• Windows 10, Windows 11, or Windows Server 2012 R2 and later running the Automox agent in SYSTEM context

• PowerShell 3.0 or later (PowerShell 5.1 recommended for the registry and file-system cmdlets the script depends on)

• Chrome, Microsoft Edge, or Brave Browser installed for the target user with at least one entry in the History SQLite database

• Filesystem access to the user's %LOCALAPPDATA% directory (folder redirection and user-profile-disk endpoints work, but the underlying share must be reachable from the SYSTEM context)

• Set numSites to the maximum number of URLs to return per browser; the default is 50, and 0 returns every URL in the database

• Coordinate with HR, legal, and privacy stakeholders before deploying broadly; browser history is regulated personal data under GDPR, CCPA, and most internal acceptable-use policies

Expected output and review workflow

On a successful run, the Automox activity log shows a labeled section per detected browser. Each section contains lines with the host domain and full URL for the matched records. Internal browser scheme URLs do not appear because the regex pattern only matches http, https, ftp, smb, and sftp schemes. A typical run completes in seconds on a workstation; setting numSites to 0 on an endpoint with years of accumulated history can extend the run time and produce a long activity-log entry.

Validate the output against a known visit by browsing to a controlled URL on a test endpoint, running the Worklet, and confirming the URL appears in that browser's section. For incident response, archive the activity-log entry alongside the policy run identifier as part of the case record. Failed executions surface as exit code 2 with a descriptive message. Typical failure reasons are no local user account found, the resolved profile path missing from disk, or all History database files absent. Each case is logged with the specific path the script attempted.