HackBrowserData decrypts and exports passwords, cookies, history and storage artifacts from 20 browsers, built for authorized forensics, incident response and security research workflows.
| Tool | moonD4rk/HackBrowserData — Go CLI that decrypts and exports browser data (passwords, cookies, history, bookmarks, cards, storage) from Chromium-based browsers, Firefox and Safari |
| Category | Digital forensics / browser artifact extraction and decryption (DFIR) |
| Primary Use | Collecting and decrypting browser artifacts (password, cookie, history, localstorage) during authorized incident response, plus offline restore of packed profiles on an analyst host |
| Safe Use | Use only on systems you own or are explicitly authorized to assess — internal forensic labs, incident response engagements, and security research environments; the project itself carries a research-only disclaimer |
| Telemetry Note | AV/EDR products commonly flag the binary as malicious per the README; dumpkeys writes plaintext master keys to disk (0600), and --keychain-pw leaks the macOS keychain password into ps output and shell history — all observable defensive signals |
HackBrowserData sits in that narrow band between attacker convenience kit and genuine forensic utility, and the repository leans deliberately toward the second identity. Written in Go and carrying topics like dfir, digital-forensics and incident-response, it is a single static binary that decrypts and exports nine categories of browser data — passwords, cookies, bookmarks, history, downloads, credit cards, extensions, localStorage and sessionStorage — from twenty browsers across Windows, macOS and Linux. The README opens with a research-only disclaimer that puts legal responsibility on the user, which is the correct framing for a tool whose output is, by definition, plaintext credentials and session tokens.
The engineering story here is the cross-browser and cross-platform coverage matrix. On the Chromium side it handles Chrome, Chrome Beta, Chromium, Edge, Brave, Opera, OperaGX, Vivaldi, Yandex, CocCoc, Arc, DuckDuckGo and a set of Windows-only regional browsers (QQ, 360 Speed, Sogou, DC, Browser from Vought), plus Firefox everywhere and Safari on macOS. Not every category maps to every engine: credit cards and sessionStorage are Chromium-only, while passwords, cookies, bookmarks, history, downloads, extensions and localStorage cut across all three engines. That asymmetry reflects real differences in how each engine persists secrets, and the README documents it honestly rather than overclaiming uniform coverage.
The most interesting architectural feature is what the author calls cross-host decryption, and it is what separates this from the usual copy-paste credential dumpers. The workflow is a clean three-command pipeline: dumpkeys on the origin host derives each Chromium installation's master keys and writes portable keys.json; archive packs only the decryption-relevant profile files into browser-data.zip; then restore on the analyst host performs the full decryption offline. The immediate DFIR payoff is that nothing platform-bound — Windows DPAPI, the macOS Keychain, Chrome's App-Bound Encryption — has to be wrestled with on the analysis machine. You can decrypt Sogou or QQ Browser data on a Mac even though those browsers never ship for macOS.
That pipeline also dictates the tool's internal structure. Because keys.json is a portable, engine-level secret rather than an OS-protected blob, decryption becomes a pure file-and-key computation detached from any host security boundary. The README is refreshingly candid about the risk this creates: keys.json contains plaintext master keys, is written with 0600 permissions, and should be streamed over a secure channel rather than left on disk. In an incident response context, that file is effectively a full credential compromise artifact and needs to be handled with the same chain-of-custody care as a memory image — its mere presence on a host is itself an indicator worth documenting.
The CLI surface is compact and idiomatic. Running hack-browser-data with no subcommand defaults to dump, the extraction-and-decryption action; list enumerates detected browsers and profiles, which is the sensible first step during triage. Filtering is via -b/--browser and -c/--category (comma-separated categories), output goes to -d/--dir (default results), and -f/--format selects csv, json or cookie-editor — the last writing cookies as a JSON array compatible with the Cookie-Editor extension's import format, a convenience for analysts who replay sessions in a sandboxed browser rather than a weaponization feature in itself.
macOS support comes with honest operational caveats that experienced examiners will recognize. Some Chromium-based browsers on macOS require the current user's password to decrypt, and the README warns that password decryption may fail on macOS 26.4 or later — presumably an API or Keychain change upstream. Safari extraction requires Full Disk Access granted in System Settings, or you get silently empty results, which is a classic forensic triage trap. The --keychain-pw flag exists for scripting this, but the help text itself warns that the value is visible in ps and shell history; --keychain-pw-stdin is the disciplined alternative, reading the password from the first line of stdin.
On Windows, the tool confronts Chrome's modern defensive posture head-on. Chromium 127+ protects cookies with App-Bound Encryption (ABE), and decrypting cookies for Chrome, Chrome Beta, Edge, Brave and CocCoc requires a small C payload compiled via make build-windows, with Zig 0.13+ as the recommended toolchain (make payload invokes zig cc); MinGW-w64 gcc works if you bypass the Makefile step. A standard cross-compile with GOOS=windows go build ./cmd/hack-browser-data/ produces a binary without ABE cookie support — a deliberate split that keeps the default build clean while making the ABE capability an explicit, opt-in compilation choice. From a defensive standpoint, that embedded payload is precisely why antivirus engines flag the binary, a fact the README acknowledges plainly.
Build hygiene is notably mature for this class of project. The repo carries CI badges for lint, build, release and test workflows plus codecov coverage tracking, and building from source requires only Go 1.20+ via the standard go build ./cmd/hack-browser-data/ invocation. Distribution is through GitHub Releases, and the README's advice when Defender quarantines the download — read the open source and compile it yourself — is the correct answer for a tool whose fingerprint will always resemble infostealer behavior, because functionally the decryption primitives overlap almost entirely.
Where this fits in an authorized workflow is worth stating precisely. During incident response on a compromised endpoint, an examiner with appropriate authorization can use archive to collect browser state, dumpkeys to capture keys, and restore on a clean analysis VM to determine whether saved credentials or session cookies were exposed to the intruder — turning a guessing game about breach impact into a deterministic inventory. The -p/--profile-path flag, which the README suggests sourcing from chrome://version, lets you point at collected or non-standard profile directories rather than live ones. In research contexts, the tool doubles as a reference implementation of how each engine's key hierarchy actually works.
For defenders, the telemetry angle is straightforward: this binary looks like an infostealer to every major AV engine, dumpkeys leaves a high-value 0600 JSON file on disk, and naive macOS usage exposes keychain passwords in process listings. Any of those on an unexpected host deserves immediate investigation regardless of who ran it. HackBrowserData is ultimately a well-engineered dual-use artifact — 14,675 stars, MIT licensed, actively documented — and the difference between it being a forensic instrument or an attack tool is entirely a matter of whose machine it runs on and under what authority.
moonD4rk/HackBrowserData.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.