MSAB Q3 2025: What BruteStorm Surge and Suite Upgrades Mean for Your DFIR Playbook

4n6 Beat
8 min read

MSAB’s Q3 2025 release introduces BruteStorm Surge, a GPU‑accelerated brute‑force add‑on for XRY Pro that targets long/complex passcodes, alongside major suite updates: XAMN 8.3 adds cross‑app conversation threading and support for Cash App warrant returns; UNIFY 25.9 can ingest Cellebrite UFDR and GrayKey extractions; and XEC 7.15 brings role‑based access control (RBAC). These capabilities are confirmed in MSAB’s official update and the initial news brief. See MSAB’s release post and feature breakdown (MSAB Q3 2025; Forensic Focus news).

  • XRY Pro 11.2 + BruteStorm Surge (GPU‑accelerated passcode attacks; add‑on license) (MSAB).
  • XAMN 8.3: cross‑app conversation threading and Cash App warrant return ingestion (MSAB).
  • UNIFY 25.9: ingestion of Cellebrite UFDR and GrayKey (Android/iOS) extractions (MSAB).
  • XEC 7.15: RBAC with defined role tiers and centralized control (MSAB; product overview for centralized logging: XEC Director).

MSAB also notes CRC hash‑tree integration for child protection workflows (XRY 11.2), enabling automated detection using Child Rescue Coalition’s data (MSAB; background on CRC mission/technology: Child Rescue Coalition).

BruteStorm Surge: GPU brute‑force in your lab

Why you care: GPU acceleration dramatically reduces time‑to‑unlock relative to CPU‑only cracking for many password classes. Public GPU cracking benchmarks (e.g., RTX 4090 hashcat tests) consistently show large speedups on fast and some slow hashes, illustrating the magnitude of parallelism modern GPUs bring to brute‑force workflows (Tom’s Hardware). While MSAB’s implementation details aren’t public, the design premise—massively parallel GPU evaluation—is well‑established in practice.

Actionable rollout plan:

  1. Hardware/driver readiness

    • Validate NVIDIA visibility and driver health: 
      nvidia-smi
nvidia-smi -q  # detailed view
      (Reference: NVIDIA’s nvidia-smi/NVML docs: NVIDIA Developer, NVML API, nvidia-smi User Guide).
    • On Windows, record driver versions for evidence reproducibility: 
      Get-CimInstance Win32_VideoController | Select-Object Name, DriverVersion
      (Background examples: Stack Overflow).

  2. Case policy and scope

    • Treat BruteStorm Surge as a specialized unlocking step under existing legal authority and SOPs. Document GPU/driver versions, workload parameters, and timing in the case notebook. MSAB’s case/logging model emphasizes extraction and case logs for defensibility (Forensic Focus webinar notes).

  3. Bench and calibrate

    • Before operational use, run controlled test sets (known passcodes, progressively longer/complex) to time the delta with/without GPU. Keep benchmarks with hash types/attack modes for your disclosure package (general GPU advantage context: Tom’s Hardware).

  4. Evidence integrity

    • Validate post‑unlock extraction integrity via MSAB’s validation guidance and XAMN validation tooling for .xry files (MSAB validation explainer).

Common pitfalls to watch:

  • Thermal throttling and mixed GPU models in a single box can create inconsistent speeds; record the exact GPU inventory/driver set (use nvidia-smi -q) (NVIDIA docs).
  • Ensure your power/cooling budget fits sustained cracking loads; speed claims from independent GPU tests illustrate how sustained load differs from peak (Tom’s Hardware).

XAMN 8.3: cross‑app conversation threading and Cash App returns

What’s new: XAMN now groups conversations “by participants” across apps/devices and adds support for Cash App warrant returns, exposing payment instruments, accounts, and transactions in‑tool (MSAB Q3 2025).

Analyst workflow guidance:

  • Cross‑app threading sanity checks

    • Expect participant resolution to rely on anchors like E.164 phone numbers, emails, or app‑specific IDs (e.g., WhatsApp JIDs like number@s.whatsapp.net)—validate your thread merges with spot checks. Forensically, JID structure is documented in public write‑ups and vendor blogs (Group‑IB WhatsApp artifact primer).
    • iMessage joins often require mapping message ↔ handle in ~/Library/Messages/chat.db; numerous tools and community docs discuss schema usage for correlation (imessage_reader PyPI; Apple community references to chat.db path: Apple Discussions). Note that newer macOS often stores message text in attributedBody, leaving message.text NULL—plan to decode that field during validation (community observation).

  • Cash App warrant returns

    • Block’s law enforcement page outlines legal process channels and what the Law Enforcement Response Team processes; use it to align scope/timelines and confirm the portal for service (Block/Legal–Government). Training/webinar materials in the LE community also describe typical return formats and field coverage (IAFCI webinar description).
    • Correlation tips: pivot on phone/email, transaction IDs, and timestamps vs. device artifacts (e.g., SMS/OTP, app logs). Normalize time zones before timeline fusion; XAMN’s unified threads should be spot‑checked against source app IDs.

Artifacts you can validate:

  • iMessage (macOS): ~/Library/Messages/chat.db, with message, handle, and join tables such as chat_handle_join; many open tools parse these tables for reporting (imessage_reader).
  • WhatsApp (Android): wa.db and msgstore.db contain contacts and chats; JID formats like number@s.whatsapp.net/xxxx@g.us are standard correlators (Group‑IB).

Quick SQL (validation idea for iMessage joins):

-- Minimal join to validate sender/recipient mapping and time normalization
SELECT m.rowid,
       h.id            AS handle,
       m.is_from_me,
       m.service,
       datetime((m.date/1000000000) + 978307200, 'unixepoch') AS msg_ts,
       m.text
FROM message m
LEFT JOIN handle h ON h.rowid = m.handle_id
ORDER BY m.date DESC
LIMIT 50;

(Schema usage background: imessage_reader; path reference: Apple Discussions; note attributedBody caveat: community observation).

UNIFY 25.9: centralized ingestion of UFDR and GrayKey

UNIFY now ingests third‑party extractions—explicitly Cellebrite UFDR and GrayKey (Android/iOS)—in addition to native .xry/.xrycase files, unifying workflow and custody in one platform (MSAB Q3 2025).

Validation tips:

  • Understand UFDR anatomy: UFDR is a compressed container with a root report.xml and categorized files. That structure can be independently verified by opening the package or using community tooling such as UFDR2DIR to reconstruct original paths from report.xml (DFIRScience UFDR2DIR). E‑discovery tools like Relativity also document automated UFDR conversions to RSMF, reflecting common industry treatment of UFDR as a standardized report container (Relativity UFDR processing).
  • GrayKey extractions: agencies widely use GrayKey for lawful access/extraction; public releases describe its expanding device coverage and extraction modes (context: Grayshift press release).

Chain‑of‑custody checklist when importing into UNIFY:

  • Compute and record SHA‑256 of UFDR/GrayKey package before ingest; retain originals read‑only.
  • After ingestion, export parsing logs/manifests from UNIFY and verify file counts vs. source report.xml for UFDR (UFDR2DIR README).

XEC 7.15: RBAC you can defend

XEC Director adds role‑based access control with tiered roles to constrain who can administer systems or log into the management interface (MSAB Q3 2025; centralized logging/management: XEC Director). Align your roles with least‑privilege practices from NIST SP 800‑53 (AC‑6/AC‑3) to reduce audit friction and insider‑risk exposure (NIST CSRC RBAC; representative AC‑6 discussion: NIST SP 800‑53 AC‑6 explainer).

Suggested mapping:

  • Manager: full administrative rights and role management (restricted to system owners; justify per AC‑6(1)).
  • Administrator: advanced configuration without role management (ops team; enforce separate accounts for non‑admin tasks per AC‑6(2)).
  • No access: deny admin console use to analysis‑only personnel; use case‑level permissions in XAMN/UNIFY instead.

Auditable controls:

Artifact and log considerations across the suite

  • XRY case/extraction logging: MSAB presentations note full extraction logs and case‑level logs, which you should export with reports for disclosure (Forensic Focus webinar).
  • iMessage (macOS) store path and DBs: ~/Library/Messages/ contains chat.db (plus -wal/-shm), the canonical source for analysis and cross‑app participant checks (Apple Discussions).
  • WhatsApp core DBs on Android: wa.db contacts and msgstore.db chats (schema overview, including jid use, in public DFIR write‑ups) (Group‑IB blog).
  • UFDR package verification: confirm report.xml presence and counts post‑import (DFIRScience UFDR2DIR; Relativity UFDR processing).

Response and detection playbook updates

  • Unlock operations (BruteStorm Surge)

    • Pre‑checks: record GPU inventory/driver versions; run nvidia-smi pre/post session and snapshot temperatures/clock throttles for repeatability (NVIDIA docs).
    • Case notes: document passcode policy (attack type/charset), elapsed time, and any fallbacks (e.g., CPU‑only) for the record (MSAB update overview; GPU speed context: Tom’s Hardware).

  • XAMN cross‑app threads

    • Detection: build saved searches that flag cross‑app participant merges where identifiers disagree (e.g., mismatched e‑mails against phone numbers); review a sample of unified threads manually each case cycle (MSAB XAMN 8.3 update).
    • iMessage caveat: where message.text is NULL, decode attributedBody or use a parser that does so; otherwise you’ll under‑count messages in QA (community note).

  • Cash App returns

    • Response: verify production scope via Block’s portal and time expectations; ensure warrants/subpoenas match identifiers you correlate in XAMN (phone/email/case IDs) (Block/Legal–Government; IAFCI webinar).

  • UNIFY ingestion of third‑party extractions

    • Detection: compare UNIFY’s post‑ingest object counts to UFDR report.xml; raise discrepancies if media or DBs are missing (DFIRScience UFDR2DIR).

  • RBAC in XEC

    • Response: implement least‑privilege role baselines on day one; log admin function execution and review quarterly per AC‑6(7) guidance (NIST AC‑6 explainer; NIST RBAC page).

Quick checklists

GPU flight‑check before a BruteStorm run:

  • nvidia-smi -q output captured in case notes (NVIDIA docs).
  • Room/case GPU and driver versions logged (Get-CimInstance Win32_VideoController) (Stack Overflow example).
  • Short known‑value passcode test completed and documented.

UNIFY import validation (UFDR/GrayKey):

  • SHA‑256 recorded pre‑ingest; custody preserved.
  • UFDR report.xml parsed; counts vs. UNIFY post‑ingest checked (DFIRScience UFDR2DIR).
  • Sample artifacts opened in XAMN for decode sanity.

Conversation threading QA:

  • 10% sample of unified threads reviewed; app‑ID/source fields preserved.
  • iMessage attributedBody parsing verified when text is NULL (community note).

RBAC rollout:

  • Manager/Admin membership justified and ticketed; non‑admin use enforced for analysis.
  • Quarterly privilege review scheduled; admin actions logged (XEC) (XEC Director; NIST AC‑6).

Takeaways

  • Turn on BruteStorm Surge only after you baseline GPUs, drivers, and lab SOPs; record environment details for court defensibility (MSAB; NVIDIA).
  • Use XAMN’s cross‑app threads to accelerate narrative building, but validate merges and handle iMessage attributedBody cases to avoid blind spots (MSAB; community note).
  • Centralize third‑party extractions in UNIFY; verify UFDR/GrayKey ingest against report.xml and maintain immutable originals (MSAB; DFIRScience UFDR2DIR).
  • Implement XEC RBAC with least‑privilege defaults and scheduled reviews to tighten audit posture (MSAB; NIST RBAC/AC‑6).

Sources / References