Briefings

DFIR playbook for investigating a North Korea–linked campaign that steals Google credentials via signed MSI→AutoIt loaders on Windows, th...

APT37/KONNI abuse Google Find Hub to factory‑reset Androids mid‑intrusion

4n6 Beat
5 min read

North Korea-linked operators in the KONNI/APT37 orbit used stolen Google credentials to log into Google’s Find Hub and remotely trigger factory resets on victims’ Android phones and tablets, timing the wipes after checking GPS location to isolate targets and delay response (BleepingComputer, Nov 10, 2025; Genians Security Center report). Find Hub is Google’s rebranded “Find My Device” service that supports locating, locking, and erasing devices (Google Find Hub about; Android Authority rebrand coverage).

What DFIR teams on Ubuntu hosts should do about VMSCAPE cross‑VM data exposure and how to verify mitigations after patching.

Ubuntu’s USN‑7860‑5 patches VMSCAPE (CVE‑2025‑40300) in HWE kernels: DFIR response notes

4n6 Beat
4 min read

Canonical published USN-7860-5 on November 10, 2025 for Ubuntu 24.04 LTS HWE (6.14) to mitigate VMSCAPE (CVE-2025-40300), a Spectre-class issue where insufficient branch-predictor isolation lets a guest VM influence host userspace execution and leak data from processes like QEMU. The notice requires updating to 6.14.0-35 and rebooting; it also flags an ABI bump that will rebuild third-party kernel modules. (ubuntu.com)

Intrusion Flow

  • Guest training: A malicious guest poisons branch-predictor state (vBTI) while executing under KVM. On VMEXIT, host userspace (e.g., QEMU) runs with the tainted predictor, enabling Spectre-BTI-style mis-speculation and data disclosure via a cache side channel. (intel.com)
  • Target surface: The attack impacts userspace hypervisors; existing kernel/KVM Spectre defenses are not sufficient because the userspace VMM can run immediately after VMEXIT without a context switch. (ubuntu.com)
  • Practicality: Researchers report end-to-end exfiltration from a host userspace hypervisor, with measured leak rates on modern CPUs in public write-ups. (linuxjournal.com)
  • Affected CPUs: Kernel documentation lists Intel Skylake (parts without eIBRS), Cascade Lake (ITS guest/host separation), and Alder Lake and newer (BHI), plus AMD Zen families 0x17/0x19/0x1a and Hygon 0x18. Some BHI-affected Intel parts using BHB clearing (e.g., Icelake) are not vulnerable. (docs.kernel.org)
  • Kernel mitigation model: Linux adds conditional branch-predictor flushing around VMEXIT-IBPB before returning to userspace-and offers a more aggressive IBPB-on-every-VMEXIT mode; vendors note existing BTI/BHI guidance applies. (docs.kernel.org)

Key Artifacts to Pull

When you’re triaging Ubuntu virtualization hosts, collect:

Scanners are sweeping web servers for /.git, /.github, GitLab CI, SVN, and S3/AWS paths. This playbook shows how to hunt the requests in...

IR Playbook: Hunting Automated Probes for Exposed Repositories and Cloud Paths

4n6 Beat
5 min read

On November 8, 2025, the SANS Internet Storm Center reported honeypot hits probing common repository and cloud-related paths, including /.git/logs/refs/remotes/origin/main, /.git/objects/info, /.github/* (such as dependabot.yml), /.gitlab/*, /.gitlab-ci, /.git-secret, /.svnignore, and cloud-y paths like /aws/bucket, /s3/backup, /s3/bucket, /s3/credentials (ISC Diary). If any of these return 200s, you may be serving source, CI config, or credentials. The rest of this post walks through a fast, repeatable response.

Intrusion Flow

  • Recon and probing: Automated clients request telltale repo/CI paths such as /.git/HEAD, /.git/config, .github/*, .gitlab-ci*, .svn/*, or /s3/* looking for misdeployments (PortSwigger, GitHub Docs: dependabot.yml location, GitLab CI YAML).
  • Exploitation if exposed: If /.git/ is reachable, attackers can reconstruct history via targeted downloads (e.g., /.git/HEAD, refs, objects) or off-the-shelf dumpers (arthaud/git-dumper, GitTools). Advisory sites treat exposed VCS dirs as source disclosure risks (Acunetix on .git).
  • Post-exploitation: Harvest secrets embedded in history or CI files using secret scanners; leaked tokens often enable cloud pivots (Gitleaks, TruffleHog).
  • Cloud angle: Attackers also test S3 naming or credential endpoints; your guardrail here is account/bucket-level S3 Block Public Access-on by default for new buckets since April 28, 2023, and recommended broadly (AWS Prescriptive Guidance, S3 BPA user guide, AWS announcement).

Key Artifacts to Pull

  • Web access logs from the serving tier (reverse proxies, WAFs, app servers):
  • Server configs for containment validation:
    • NGINX: location ~ /\.(?!well-known) { deny all; } is a common pattern to block dotfiles while allowing ACME challenges (Bolt CMS nginx example).
    • Apache: <FilesMatch "^\."> Require all denied </FilesMatch> blocks dotfiles (Apache core / ).
  • Evidence if exposure occurred:
    • Sample served files (e.g., /.git/HEAD, /.git/config, .gitlab-ci.yml) for scoping; prefer capturing over the wire evidence and hash it in your case notes.
    • HTTP status codes context: 200 means the resource was served; 403 means refused; 404 means not found (MDN 200, MDN 403, MDN 404).

Detection Notes

The goal is to quickly identify requests to risky repo/CI/cloud paths and prioritize 200s.

Google’s November 7, 2025 ChromeOS LTS update fixes high‑severity flaws in Safe Browsing, Storage, V8, and libaom. Here’s the incident‑re...

ChromeOS LTS 138.0.7204.296: What DFIR Teams Should Pull, Check, and Enforce

4n6 Beat
4 min read

Google shipped ChromeOS Long-Term Support (LTS) 138.0.7204.296 (Platform 16295.81.0) on November 7, 2025, with security fixes for Safe Browsing (CVE-2025-11756), Storage (CVE-2025-11460), V8 (CVE-2025-12036), and libaom (CVE-2025-8879). Confirm the OS and platform versions during triage and push the update across your fleet. (chromereleases.googleblog.com)

Intrusion Flow

  • Likely initial vector: drive-by or content rendering via the Chrome browser on ChromeOS that triggers memory-safety bugs in browser components (Safe Browsing, Storage, V8) or the AV1 codec library (libaom), leading to crash or potential code execution in the browser context. Chrome Stable channel notes for CVE-2025-11756 (Safe Browsing) and CVE-2025-11460 (Storage) confirm high-severity use-after-free issues; CVE-2025-12036 is an “inappropriate implementation” in V8; CVE-2025-8879 is a heap buffer overflow in libaom. (chromereleases.googleblog.com)
  • On ChromeOS, crashes and related telemetry are collected by crash-reporter; browser and system crashes produce minidumps and logs in specific locations (see “Key Artifacts”). (chromium.googlesource.com)
  • Update application is handled by update_engine; successful or failed updates leave traces in update_engine logs. (chromium.googlesource.com)

Key Artifacts to Pull

  • Version and channel evidence
    • UI: Settings > About ChromeOS (records current ChromeOS version) and chrome://version (shows browser and platform versions). Capture screenshots or export the page during triage. (chromium.org)
    • Admin inventory: ChromeOS device records expose osVersion and platformVersion via the Directory API. Pull device lists or per-device records to validate fleet posture. (developers.google.com)
  • Update traces
    • update_engine logs at /var/log/update_engine and the active symlink /var/log/update_engine.log. These record payload URL, state transitions, success/failure, and rollback markers. (chromium.googlesource.com)
  • Browser/system logs
    • Chrome logs before login: /var/log/chrome/chrome; after login (non-test images): /home/chronos/user/log/chrome; early Chrome startup: /var/log/ui/ui.LATEST. (chromium.googlesource.com)
    • System logs: /var/log/messages and related rsyslog outputs can clarify browser startup/shutdown and service behavior. (chromium.googlesource.com)
  • Crash evidence
    • Crash report storage: system crashes in /var/spool/crash/; user-session crashes under /run/daemon-store/crash/<user_hash>/; logged-out Chrome crashes in /home/chronos/crash/. Also check /var/log/chrome/Crash\ Reports/uploads.log for upload status. (chromium.googlesource.com)
    • chrome://crashes shows IDs when user consented to crash reporting; minidumps can be symbolized with tast symbolize for deeper analysis. (chromium.org)

Detection Notes

  • Hunt for crash spikes or recurring signatures matching affected components:
    • Strings to grep in Chrome logs and minidumps: “SafeBrowsing”, “storage”, “V8”, “libaom”, “aom”. Combine with timestamps around user browsing sessions. Use Chrome logs and crash directories noted above. (chromium.googlesource.com)
  • Correlate update success/failure with exploitation windows:
    • Parse /var/log/update_engine.log for state=UPDATED_BUT_DEFERRED, failures, or rollbacks; align with crash timestamps to spot exposure pre-patch. (chromium.googlesource.com)
  • Fleet-level posture:
    • Query the Admin Directory API for devices not yet at Chrome 138.0.7204.296 (LTS milestone 138) using version search operators (example below). Device records also return platformVersion for cross-checks. (developers.google.com)

Example Directory API filter (Admin console/API search syntax supports prefix matching on Chrome version):

A hands-on incident-response guide that turns Google’s November 6, 2025 scams advisory into concrete intrusion flows, artifacts to pull,...

IR playbook: triaging Google’s November 2025 fraud advisory (AI impersonation, job‑lure malware, and review extortion)

4n6 Beat
5 min read

Google’s Trust & Safety team published a new scams advisory on November 6, 2025 that highlights three trends DFIR teams will encounter in the wild: job-lure campaigns that deliver RATs and info-stealers, negative-review extortion of merchants, and AI-product impersonation across apps, extensions, and malvertising chains (Google, Nov 6, 2025). The advisory also notes a rollout of a direct merchant extortion reporting flow and calls out protections in Chrome/Play you’ll see on endpoints during triage (Google).

Attackers are riding legitimate RMM tools through trucking/logistics networks while Apple and Google ship important platform fixes. Here’...

IR playbook: RMM abuse in trucking/logistics, plus Apple and Android patch priorities (Nov 2025)

4n6 Beat
5 min read

SANS ISC’s Stormcast on November 5, 2025 highlighted three items responders should act on: Apple’s latest cross-portfolio security updates, Google’s November Android security bulletin with a critical System RCE, and active criminal use of legitimate remote management tools (RMM) against trucking and logistics firms. Patch scheduling and RMM governance should be on the same ticket for this week’s change window. (SANS Stormcast 2025-11-05, Android Nov 2025 bulletin).

Apple shipped Safari 26.1 on November 3 with multiple WebKit memory-safety fixes, and broader OS updates (iOS/iPadOS 26.1, watchOS/tvOS/visionOS 26.1) that include additional WebKit issues; SANS notes Apple’s set also includes memory-corruption bugs in ImageIO and FontParser-classes historically associated with code-execution vectors-so prioritize roll-out. (Apple Safari 26.1, visionOS 26.1 WebKit entries, SANS diary summary). Google’s November 2025 Android bulletin calls out a critical RCE in the System component requiring no additional privileges and no user interaction; push devices to security patch level 2025-11-01 or later. (Android Nov 2025 bulletin).

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)