Skip to content
Reverse Engineering
Anti-Forensicbeginner

Browser Artifact Wiping

Attackers clear browser history, cache, and cookies to hide payload downloads and C2 visits, but SQLite WAL and disk slack retain the records.

Web browsers are a rich source of intrusion evidence: the URL a victim was lured to, the domain a payload was downloaded from, and the C2 endpoints a malicious extension or browser-based loader contacted all land in the browser's history, cache, cookie, and download databases. An attacker — or an infostealer covering its exfil — clears these artifacts to sever the link between the host and the malicious infrastructure, hoping the responder never learns which domain delivered the second stage.

Wiping the browser store is easy (a single "clear browsing data" call or deleting the profile's SQLite files), but it is rarely complete. Chromium and Firefox store history in SQLite databases that use write-ahead logging and VACUUM-based deletion, both of which leave recoverable rows, and the OS keeps independent copies of the same DNS and connection facts the browser tried to erase.

How it works

The common approach deletes or empties the profile's history and cache databases:

bash
# Chromium: drop the history DB and cache, then let the browser rebuild
rm -f "$HOME/.config/google-chrome/Default/History"
rm -rf "$HOME/.config/google-chrome/Default/Cache"
# Firefox: clear visited URLs in place
# sqlite3 places.sqlite "DELETE FROM moz_places; VACUUM;"

Deleting History/places.sqlite (or running DELETE + VACUUM) removes the visible rows; clearing Cache/Code Cache discards downloaded objects; deleting Cookies and Network/Cookies removes session evidence. Infostealers often wipe only their own download and C2 entries, leaving the profile otherwise intact to avoid suspicion.

Detection & analysis

Static analysis:

  • Recover deleted rows from the SQLite stores. A DELETE marks pages free but leaves the data until VACUUM, and even after VACUUM the WAL/journal (History-wal, places.sqlite-wal) and freelist pages retain entries. Tools: Hindsight, BrowsingHistoryView, sqlite3 with .recover, and the Eric Zimmerman SQLECmd maps. Carve unallocated space for the SQLite SQLite format 3\0 header to recover whole deleted databases.
  • Pull corroborating artifacts the wipe usually misses: the Cache index and data blocks (which embed source URLs and timestamps), Top Sites, Favicons, Sessions/Current Tabs, the Visited Links file, and download metadata in History's downloads table. A deleted history paired with a surviving favicon for a malicious domain is conclusive.

Dynamic analysis:

  • The browser is not the only record of where it connected. Correlate against host DNS history (dnscache / Resolve-DnsClientCache, systemd-resolved logs), proxy/firewall logs, and EDR network telemetry — these contain the same C2 and download domains and are outside the attacker's reach inside the profile.
  • Watch for the wipe action itself: processes deleting History, Cookies, or Cache under a browser profile path, or a browser launched with --incognito/private-mode flags immediately around the suspicious activity. Sysmon Event ID 11 (file delete/create) on profile database files flags the clearing.

Detection rule hint: Alert when a non-browser process deletes or truncates SQLite files under a known browser profile directory, and reconstruct visited and downloaded URLs from the WAL/journal, recovered cache index, and host DNS cache. The download domain recovered from the cache or DNS history is typically what re-identifies the malware delivery and C2 infrastructure the wipe was meant to hide.

Votes

Comments(0)