4N6 BEAT

DFIR-focused rundown of Apple’s 26.1/26.1-era security releases: WebKit and media-parser bugs, AppleMobileFileIntegrity/TCC/Gatekeeper ha...

Apple’s November 2025 patch wave: 110 fixes across iOS, macOS, watchOS, tvOS, visionOS, Safari, and Xcode

4n6 Beat
4 min read

Apple shipped coordinated security updates on November 3, 2025 for iOS/iPadOS 26.1, macOS Tahoe 26.1, watchOS 26.1, tvOS 26.1, visionOS 26.1, Safari 26.1, and Xcode 26.1. The Internet Storm Center counted 110 vulnerabilities across the set, with no CVEs marked as exploited in the wild by Apple at publication time. (support.apple.com)

Intrusion Flow

This is a likely attacker flow derived from Apple’s release notes and ISC’s summary; use it to guide triage and hypothesis testing.

What DFIR teams should do now to triage, hunt, and contain VS Code–compatible extension abuse via Open VSX token leaks and Unicode-stegan...

Open VSX token rotation after GlassWorm: an IR playbook for hunting malicious VS Code–compatible extensions

4n6 Beat
4 min read

On November 2, 2025, Open VSX said it rotated leaked access tokens after attackers abused exposed secrets to publish malicious VS Code-compatible extensions in a supply-chain incident tied to the “GlassWorm” campaign. The Eclipse Foundation removed the malicious packages, and reported the incident contained by October 21 with additional controls coming (shorter token lifetimes, faster revocation workflows, and automated scans) source source.

Intrusion Flow

  • Initial access to publishers: Researchers cataloged over 550 validated secrets inside VS Code and Open VSX extensions, including more than 100 VS Code Marketplace PATs and 30+ Open VSX tokens-enough to let an attacker push trojanized updates to projects with an install base around 150k in aggregate source source.
  • Weaponization and publish: Some leaked Open VSX tokens were subsequently abused to publish malicious extensions associated with the GlassWorm campaign source.
  • Payload concealment: Koi Security reported the use of invisible Unicode characters to hide JavaScript payloads (Unicode steganography) in extension code, hindering human review; claims included credential theft and targeting of crypto-wallet data in dozens of extensions source source. The Eclipse Foundation clarified GlassWorm did steal developer credentials but was not self-replicating as a worm on endpoints source.
  • Distribution surface: Open VSX is the Eclipse-run registry for VS Code-compatible extensions and is widely used by VS Code forks that can’t use Microsoft’s Marketplace (for example Cursor and Windsurf), increasing reach beyond Microsoft’s VS Code desktop source source.
  • Amplification factors: VS Code auto-updates extensions by default; a compromised publisher token can silently fan out malicious updates to enrolled developer machines source source.

Key Artifacts to Pull

  • Extension inventory and binaries
    • Enumerate installed extensions and lock versions:
      • code --list-extensions --show-versions (official CLI) source source.
    • File system paths for extensions:
      • Windows: %USERPROFILE%\.vscode\extensions
      • macOS/Linux: ~/.vscode/extensions source source.
    • Collect extension directories, their package.json, and any .vsix packages found on disk (portable mode keeps all data under the app data folder) source.
  • VS Code state and logs
    • Global state DB: %APPDATA%\Code\User\globalStorage\state.vscdb (or ~/.config/Code/User/globalStorage/state.vscdb) contains extension enable/disable state; also check workspace workspaceStorage/*/state.vscdb source.
    • Export extension logs via Developer: Open Extension Logs Folder (also exposed by GitHub Codespaces docs) source.
  • Indicators specific to GlassWorm
    • Review Koi’s rolling IoCs for compromised extension IDs/versions and infrastructure (IPs, Solana wallet, Google Calendar dead-drops) to guide triage source.

Detection Notes

  • Hunt for invisible Unicode control/steganography markers in extensions and project code
    • Background: Unicode bidi controls and zero-width/variation selectors can render code differently than it executes (the “Trojan Source” class of issues) source source.
    • Practical scans (target extension folders and recent repos):
      • Detect bidi controls (U+061C; U+200E-U+200F; U+202A-U+202E; U+2066-U+2069) with PCRE2/Perl one-liners as documented by the community:
        • Git/PCRE form: git grep -IP '(*UTF)[\x{061C}\x{200E}\x{200F}\x{202A}-\x{202E}\x{2066}-\x{2069}]' source.
        • Perl form: perl -CSD -ne 'print "$ARGV: $_" if /\p{Bidi_Control}/' $(fd -t f) source.
      • Detect zero-width and variation selectors often used for invisibility/steganography (e.g., U+200B-U+200D; U+FE00-U+FE0F):
        • ripgrep example: rg -nUP "[\x{200B}-\x{200D}\x{FE00}-\x{FE0F}]" ~/.vscode/extensions
        • FE0F (Variation Selector-16) is an invisible, non-spacing selector source source.
    • Focus on files executed on activation (e.g., extension.js, out/*.js, dist/*.js) and package.json activation events.
  • Look for outbound C2 patterns noted in public write-ups (Solana transaction lookups, Google Calendar shortlinks) and the specific HTTP hosts and paths in Koi’s IoCs source.
  • Prioritize forks using Open VSX (e.g., Cursor and Windsurf) since their marketplaces are independent of Microsoft’s and were in GlassWorm’s blast radius; Cursor publicly documented its transition to Open VSX source source.

Response Guidance

  • Containment on developer endpoints
    • Freeze extension churn: set "extensions.autoUpdate": false temporarily while you investigate source.
    • Snapshot and remove: export code --list-extensions --show-versions, then uninstall suspicious or listed IoC extensions; optionally pin safe versions via --install-extension publisher.ext@version source.
    • Inspect and neutralize Unicode-hidden payloads: if scans hit invisible characters in executable code, treat the extension as compromised; preserve copies, then disable/uninstall.
  • Credential hygiene
    • Rotate developer credentials targeted by reports (GitHub PATs, npm tokens, Open VSX access tokens) and invalidate saved tokens on endpoints. Open VSX documents token management and revocation in its publishing guide; tokens remain valid until deleted-revoke any that could be exposed in CI or builds source source.
  • Enterprise marketplace governance
    • Prefer allow-lists of publishers and pre-approved extensions for Open VSX-backed IDEs (Cursor/Windsurf). Where possible, pre-stage vetted .vsix and install via CLI to reduce live marketplace risk source.
    • Monitor Open VSX and vendor advisories; Eclipse’s post-incident measures include shorter token lifetimes, faster revocations, and automated publication-time scans-incorporate those changes into your risk model source.
  • Scope verification
    • Cross-check endpoints for Koi’s listed persistence keys (Windows Run) and network IoCs when applicable, acknowledging Eclipse’s clarification that the malware did credential theft but was not autonomously self-replicating on hosts source source.

Takeaways

  • Inventory and lock VS Code-compatible extensions now; disable auto-updates during triage and remove any listed by IoCs source source.
  • Hunt for Unicode control characters in extension code and recent repos; treat any invisible-character hits in executable files as suspicious until proven benign source source.
  • Rotate exposed tokens across Open VSX, GitHub, and npm; re-issue per-environment tokens and revoke unused ones source.
  • Track Open VSX advisories and Koi/Aikido updates; BleepingComputer confirms Eclipse removed the packages, rotated tokens, and is tightening controls, while Aikido reports the threat activity pivoting to GitHub with the same Unicode technique source source.
Hands-on guidance for DFIR teams to capture, parse, and correlate logs when Cloudflare-style anonymous credentials and Privacy Pass token...

Anonymous credentials in the wild: how to collect and analyze Privacy Pass, ARC/ACT, and OHTTP evidence

4n6 Beat
7 min read

Cloudflare proposed using anonymous credentials to rate-limit bots and AI agents while preserving user privacy on October 31, 2025, outlining issuance, presentation, and verification flows and comparing bandwidth/CPU trade-offs with existing Privacy Pass deployments (Cloudflare). The building blocks sit on standardized components: the Privacy Pass architecture and issuance protocols, and the HTTP “PrivateToken” authentication/challenge scheme (RFC 9576, RFC 9578, IETF draft: Auth Scheme). Expect to see more Authorization: PrivateToken headers, unlinkable single-use tokens or multi-show anonymous credentials (ARC/ACT), and, in some deployments, traffic tunneled via Oblivious HTTP (OHTTP), which intentionally splits client IP from request content (RFC 9458).

Microsoft’s 26220.7051 (Dev/Beta) Insider build introduces an opt‑in Ask Copilot entry on the taskbar. Here’s how that UX change surfaces...

Windows 11 Insider Build 26220.7051 adds “Ask Copilot” to the taskbar — what to baseline for DFIR

4n6 Beat
6 min read

Microsoft shipped Windows 11 Insider Preview build 26220.7051 (KB5067115) to Dev and Beta on October 31, 2025, introducing an opt-in “Ask Copilot” experience on the taskbar. You enable it at Settings > Personalization > Taskbar > Ask Copilot and can also toggle whether the Copilot app auto-starts at sign-in. Microsoft states Ask Copilot uses existing Windows APIs to return apps, files, and settings like Windows Search, and it does not grant Copilot access to personal content. (blogs.windows.com)

WhatsApp is rolling out passkey-encrypted cloud backups on iOS and Android. This replaces backup passwords and 64‑digit keys with device‑...

WhatsApp moves cloud chat backups to passkeys. Here’s what changes for DFIR.

4n6 Beat
5 min read

WhatsApp is rolling out passkey-encrypted chat backups for iOS and Android, letting users protect backup restores with Face ID/Touch ID, Android biometrics, or the device screen lock instead of a password or 64-digit key (BleepingComputer; The Verge). End-to-end encrypted (E2EE) backups themselves aren’t new-WhatsApp shipped them in October 2021 with a password or 64-digit key option and an HSM-backed Backup Key Vault design (Meta Engineering)-but the gate to restore is now a platform passkey instead of something you type. Enable path remains: Settings → Chats → Chat backup → End-to-end encrypted backup (BleepingComputer).

Hero image for DJI Fly App Forensics: Extracting and Analyzing Flight Logs on Android, iOS, and DJI RC

DJI Fly App Forensics: Extracting and Analyzing Flight Logs on Android, iOS, and DJI RC

4n6 Beat
8 min read

You often investigate incidents where a DJI aircraft is involved-flyaways, near-misses, restricted-area incursions, or simply reconstructing pilot actions. The DJI Fly app (dji.go.v5) is the default ground-control app for most recent DJI consumer drones, and it quietly records rich telemetry you can extract, preserve, and analyze for DFIR.

This guide shows you how it works, where to find the artifacts, and how to process them with current tools-on Android, iOS, and DJI RC-class smart controllers. You’ll also learn the common traps (Android scoped storage, missing DAT files, cropped logs, and cloud policy changes in the U.S.) and practical workflows to avoid data loss.

Check Point’s Oct 27 intel highlights a fast‑moving LockBit 5.0 wave and live exploitation of Magento’s SessionReaper (CVE‑2025‑54236). H...

LockBit 5.0 and Magento “SessionReaper”: DFIR notes on two active intrusion patterns

4n6 Beat
5 min read

Check Point’s October 27, 2025 weekly report flags two things we should treat as priority hunts: a fresh LockBit 5.0 build with cross-platform encryptors and faster runtime, and active abuse of Magento’s SessionReaper (CVE-2025-54236) to hijack sessions and drop PHP webshells via the REST API. Their write-up aligns with Trend Micro’s technical analysis of the LockBit 5.0 binaries and Adobe/Sansec guidance on SessionReaper exploitation in the wild. (Check Point report; Check Point blog on the comeback; Trend Micro analysis; Adobe APSB25-88; Sansec). (research.checkpoint.com)

A deep, practical guide for DFIR analysts on locating, interpreting, and correlating local artifacts from end‑to‑end encrypted Signal and...

Deconstructing Encrypted Communication Protocol Artifacts (Signal/WhatsApp)

4n6 Beat
11 min read

End-to-end encryption (E2EE) protects message content in transit, but mobile devices still maintain local state to function. On a physical or full file-system acquisition, you can frequently recover accounts, device identifiers, contact and group identifiers, message timing, call history, media references, and even local key material or key handles. Your goal in DFIR is to turn these device-resident artifacts into defensible timelines of who communicated with whom, when, and how often.

A deep, hands‑on DFIR guide to correlating scattered fragments of deleted NTFS files, mapping their physical disk locations, and building...

File System Fragmentation Mapping and Time-Lining

4n6 Beat
10 min read

You often can’t trust a standard “MAC times” timeline when an adversary timestomps $STANDARD_INFORMATION, renames files, or deletes entire directories. This guide teaches you how to map the physical fragments of a file across the disk and reconstruct a resilient chronology from NTFS internals and low-level journals-so you can explain what really happened even when typical metadata is gone.

At a high level, you will:

Why this works: NTFS separates “what data sits where” (runlists mapping VCNs to LCNs) from file names and times. It also appends low-level summaries of changes into the USN Journal ($Extend$UsnJrnl) and records transaction details in $LogFile. Even when $MFT timestamps are forged, those other structures often retain independent evidence of creation, writes, renames, and deletes USN Change Journal records behavior and NTFS attribute types including $STANDARD_INFORMATION and $FILE_NAME. (learn.microsoft.com)

Shufflecake hides multiple encrypted filesystems inside apparent free space on Linux. Here’s how it works, what deadbox can’t tell you, a...

Shufflecake on Linux: what deniable, multi-layer volumes mean for DFIR

4n6 Beat
6 min read

Shufflecake implements plausible deniability on Linux by scattering several independently-keyed volumes across what looks like random free space, making both the existence and the number of volumes hard to prove in deadbox exams. The design ships as a device-mapper target (kernel module) plus a userland CLI, with volumes exposed as virtual block devices under /dev/mapper when opened (Shufflecake project site). The project originated at Kudelski Security and EPFL in November 2022 (Kudelski Security blog), and the research was later peer-reviewed at ACM CCS 2023 (Shufflecake ePrint).