Moving at the speed of scripting

At LifePoint Health, my role is to make security work smarter, more consistent, and easier to scale. I focus on recurring pain points, then turn them into repeatable procedures that reduce time to resolution and produce clear evidence for ticket documentation.

A recent example involved browser hijacking across endpoints. Home pages were being changed, default search engines were swapped, and popups became persistent. Manual cleanup often took 20 to 30 minutes per device, and outcomes varied depending on the browser and profile state. I set a goal to reduce remediation to about 60 seconds per endpoint, complete the cleanup in a single pass, and generate ticket ready evidence for what was removed.

To counter this threat, I built two production PowerShell scripts designed to run through CrowdStrike Falcon Real Time Response. Real Time Response is CrowdStrike’s controlled remote operations channel that allows authorized analysts to run commands and scripts on endpoints while maintaining auditability. I developed these tools using an iterative approach: form a hypothesis about persistence, codify the procedure, validate results on multiple endpoints, then release once the result is repeatable. Before rollout, I also shared the approach and output format with local peers for review so the scripts would be usable by the broader team.

Script 1: Browser Hijacker Remediator

Purpose Remove common persistence mechanisms used by browser hijackers across Chromium based browsers and Firefox, while producing a concise summary that can be pasted into the ticket.

Why “file locks” matter Browsers frequently keep profile files open while running. Those open handles prevent deletion or modification of key databases and cache files. The script safely closes active browsers first to release locks and reduce the risk of corrupting profile data.

High level steps

1. Close active browsers to release profile file locks.
2. Wait briefly to allow pending profile writes to complete.
3. Enumerate local Windows user profiles on the endpoint.
4. Discover browser profile paths for Chromium based browsers and Firefox.
5. Remove extension related stores and state that can reload on startup.
6. Delete browser history databases, associated journal files, and derived caches.
7. Clear runtime storage that can keep malicious code alive between sessions, including service workers, site storage, code cache, and network cache.
8. For Firefox, also clear extension registry artifacts and the primary history database.
9. Print a compact run summary suitable for ticket notes.
10. Perform a “leftover artifacts” scan and report any profiles still showing indicators of persistence.

What “leftover artifacts” means In this context, leftover artifacts are files or directories that suggest persistence may still exist after cleanup, such as extension directories that reappear, service worker related storage that remains populated, or profile items that cannot be removed due to active handles or permissions. The script reports these by profile path so an analyst can quickly decide whether additional investigation is required.

The script also collects read only signals that help explain reappearance, such as effective browser policy at the machine and user scope and scheduled tasks that launch a browser. These checks are inspection only and do not modify policy.

Script 2: Browser Extensions Removal

Purpose Provide a faster, narrower tool for extension driven cases where a full history and cache reset is not required.

High level steps

1. Close active browsers to release profile file locks.
2. Enumerate local Windows user profiles.
3. Discover browser profile paths for Chromium based browsers and Firefox.
4. Remove only extension stores for Chromium based browsers and extension registries for Firefox.
5. Output a short report showing the user, browser, profile path, and items removed, plus any profiles that still present artifacts.

Design principles and why a second run could be useful

Each script is purpose built with a single, well defined objective and clear naming so intent is obvious to the reader. They are safe to re run, meaning a second pass should not introduce changes beyond removing anything that was missed due to timing, file locks, or delayed browser write activity. This matters in real operations because the first run can occur while the endpoint is still settling, for example after a browser auto restart or a profile sync event. A second run is not required in normal cases, but it is a safe option when the leftover artifacts scan reports persistence indicators.

The scripts are lock aware to reduce the risk of corrupting profile assets. They do not change browser policy or enterprise configuration. Output is observable by default with timestamps, counts, pass or fail indicators, and minimal ticket ready text that an analyst can paste into the case notes. Everything executes entirely in PowerShell and is compatible with CrowdStrike Real Time Response.

Impact

With cleanup reduced to about a minute per endpoint, analysts can spend more time on root cause questions: how the hijack occurred, what persistence mechanism was used, and what control changes prevent recurrence. The scripts also standardize evidence collection so remediation work is documented consistently across the team.

Request for peer comparison

I would like to compare notes with others handling similar persistence. If you have encountered service worker or extension based persistence across multiple users, profiles, or endpoints, I would value your perspective. I am especially interested in alternative ways to handle browser profile file locks beyond closing the browser and waiting, and any validation checks you use to confirm the endpoint is truly clean. Feedback will help me test new approaches, strengthen the scripts’ validation logic, and share back what measurably reduces reinfection.