Attack of the Extensions

[carlospolop]

🤖 Automated Content Update

This PR was automatically generated by the HackTricks News Bot based on a technical blog post.

📝 Source Information

• Blog URL: https://specterops.io/blog/2026/08/13/chromium-extension-c2-persistence
• Blog Title: Attack of the Extensions
• Suggested Section: Pentesting Web > Browser Extension Pentesting Methodology > Forced Extension Load Preferences; cross-reference from Windows Hardening > Windows Local Privilege Escalation/Post-Exploitation and Mythic

🎯 Content Summary

Overview and prerequisites

The post presents a Windows post-exploitation technique for converting Chrome or Edge into a persistent Mythic command-and-control agent. The proof-of-concept SilentChrome-BOF modifies Chromium profile state so an unpacked extension is accepted on the next browser launch without requiring the user to visit chrome://extensions and select Load unpacked. The installed extensio...

🔧 Technical Details

Silent Chromium extension persistence: After obtaining same-user local execution and profile write access, an attacker can insert an unpacked extension into extensions.settings.<extension_id>, set extensions.ui.developer_mode = true, and calculate the associated legacy HMACs using Chromium's hard-coded seed, the user's trimmed SID, the exact preference path, and the compact serialized value. The attacker must also recalculate protection.super_mac. On Chromium versions using encrypted split-HMACs, deleting only the malicious extension's encrypted member fails; deleting the complete protection.macs.extensions.settings_encrypted_hash dictionary while preserving valid legacy MACs causes Chromium to accept the state through its fallback path and regenerate the encrypted dictionary.

Stable extension IDs and ID-only allowlist bypass: Chromium derives an extension ID by Base64-decoding the...

🤖 Agent Actions

Plan:

1. Map browser-extension, Chromium, Windows post-exploitation, and Mythic documentation.
2. Read at least five relevant pages and search for existing coverage to prevent duplication.
3. Verify the blog’s key implementation details against primary Chromium/tool sources where needed.
4. Edit only the best-fitting existing page, add numbered citations/references, and preserve structure.
5. Review the diff and run focused Markdown/repository checks.
   The repository-mapping step is in progress. I’ll first identify existing browser-extension, Chromium credential, persistence, native-messaging, IWA, and Mythic coverage, then inspect the strongest candidate pages before choosing any edit.
   The exact suggested topic already has a dedicated page, so I’ll now determine whether it is pre-existing, complete, and already cited. I’ll compare it with the section index, permissions/API guidance, forensic artifact guidance, macOS Chromium abuse, and Mythic documentation—six files total—before deciding whether changes are warranted.
   The batched inspection command hit a quoting error before execution. I’m retrying the same read-only comparison with safer command quoting; no repository state was changed.
   The shell is POSIX sh rather than Bash, so the array syntax was rejected. I’m retrying with a portable loop and keeping the inspection scope unchanged.
   The dedicated page covers the older MAC-forgery technique but not the newer encrypted split-HMAC fallback, SID-bound calculations, dual Developer Mode MACs, native-host/IWA sidecars, or concrete telemetry. I’ll inspect the remaining candidate pages through headings and focused excerpts, plus all links to this page, to confirm that the extension page is the single authoritative location and avoid duplicating content elsewhere.
   The focused scan confirms the target page is already linked from both the browser-extension methodology and the book summary. I’ll finish the required file review with narrow line ranges from the four remaining pages, especially existing native-messaging guidance and Mythic’s current scope, then move to source verification.
   The methodology already documents generic native messaging, and the forensics page only catalogs profile artifacts. I’ll now read the complete macOS Chromium-abuse and Mythic pages separately; their small scope will clarify whether either should receive a link or whether doing so would violate the single-file placement rule.
   Repository review is complete: the browser-extension page is the correct single source of truth; the generic methodology already covers native messaging, the forensic page only inventories artifacts, the macOS page is platform-specific, and Mythic is framework-level documentation. I’ll now verify the new Chromium behavior and tool syntax against the author’s repositories, Chromium source, and official Chrome documentation before editing only the dedicated Windows forced-load page.
   Brave search is rate-limited (HTTP 429), so I’m switching to the available Google search endpoint for the same primary-source queries. I’ll ignore any banned-domain results and use only the author’s repositories, Chromium source, and official Chrome documentation.
   Both search providers are unavailable (Brave 429; Google key exhausted). Because the exact primary URLs are known from the supplied article, I’ll fetch those pages directly with curl and inspect only relevant markers; this avoids relying on search snippets or forbidden sources.
   Primary-source verification confirms the command syntax, profile targets, per-user native-host keys, Ditto’s browser/IWA/native sidecar model, and Chromium’s coexistence of legacy and encrypted split hashes. I’ll inspect the exact current line structure and the fallback branch one more time, then patch the existing page with concise version-aware additions and append references [5+] without altering other pages.
   The edit plan is finalized:

• Correct the Windows HMAC construction to include the SID-derived device ID and both Developer Mode paths.
• Add the Chrome 148 encrypted split-hash fallback and super_mac sequence.
• Add operational SilentChrome usage, ABE-resistant browser-API cookie access, per-user native-host registration, and the IWA/Direct Sockets authorization chain.
• Replace generic detection advice with precise Sysmon/file/registry/process signals and the mandatory Developer Mode policy.
• Append the original SpecterOps research and the primary tool/Chromium/Chrome documentation as numbered references.
  Only the existing forced-load page will be modified.
  The page has been updated. I’m now reviewing the diff for citation coverage, Markdown correctness, forbidden-domain leakage, accidental duplication, long new code blocks, and unintended edits before running repository checks.
  The diff is clean and touches one file only. The review found a few attribution-placement improvements (citations should introduce whole derived lists rather than appear only on their final items), plus an opportunity to link Ditto back to the existing Mythic page without duplicating content. I’ll make those small refinements, then validate all new reference URLs and run final checks.
  The citation placement and internal Mythic link are refined. Final validation will now check: URL reachability, citation/reference number consistency, internal-link existence, forbidden domains, duplicate material, whitespace errors, and an mdbook build if the binary is available.
  Updated:

src/pentesting-web/browser-extension-pentesting-methodology/forced-extension-load-preferences-mac-forgery-windows.md

Added:

• SID-bound MAC calculations and dual Developer Mode MACs.
• Encrypted split-HMAC fallback behavior.
• SilentChrome-BOF usage.
• Native Messaging Host and IWA Direct Sockets sidecars.
• Browser-resident cookie access implications.
• Sysmon detection guidance and enterprise hardening.
• Numbered primary-source references and citations.
• Internal Mythic cross-reference.

Validation passed:

• git diff --check
• Citation/reference consistency
• Forbidden-source check
• All seven new reference URLs returned HTTP 200
• mdbook build skipped because mdbook is unavailable.

---

This PR was automatically created by the HackTricks Feed Bot. Please review the changes carefully before merging.

[carlospolop]

🔗 Additional Context

Original Blog Post: https://specterops.io/blog/2026/08/13/chromium-extension-c2-persistence

Content Categories: Based on the analysis, this content was categorized under "Pentesting Web > Browser Extension Pentesting Methodology > Forced Extension Load Preferences; cross-reference from Windows Hardening > Windows Local Privilege Escalation/Post-Exploitation and Mythic".

Repository Maintenance:

• MD Files Formatting: 1029 files processed

Review Notes:

• This content was automatically processed and may require human review for accuracy
• Check that the placement within the repository structure is appropriate
• Verify that all technical details are correct and up-to-date
• All .md files have been checked for proper formatting (headers, includes, etc.)

Bot Version: HackTricks News Bot v1.0