#threat_intelligence

---------------- 🛠️ Tool =================== zsazsa CTI is a cyber threat intelligence program management and production platform built around MISP. It links collection, triage, analyst workflows, requirement management, publishing, and stakeholder delivery in a single integrated workflow. The platform targets teams that treat threat intelligence as an operational capability rather than a collection of loose documents and disconnected scripts. Analysts move from source events to validated intelligence products, align output to PIR and GIR priorities, distribute to stakeholders, and feed response back into program maturity signals. Key functional areas: Dashboard provides a live snapshot: active PIRs and GIRs, stakeholder counts, analyser freshness, the last 24 hours of processing, and scraper events awaiting triage. Stakeholders records who receives output, with role, organisation, TLP clearance, product subscriptions, and notification channels. Includes a power and interest matrix for engagement planning. Requirements (PIR and GIR) hold the intelligence questions driving collection, with scope, ownership, and distribution. Adding scope to a requirement highlights matching events in the data collection view. RFIs handle one-off requests from intake to closure, with SLA, owner, linked PIR or GIR, response confidence, attachments, notes, and feedback. Data collection is the cached view of everything arriving from the scraper MISP, other MISP servers, and manual or newsletter sources. Analysts browse and triage events, enrich them with scope from MISP galaxies, generate AI summaries, and start a product straight from a source event. Products form a searchable catalogue: Flash Intel Alerts, Vulnerability Advisories, Daily Threat Briefings, Threat Landscape Reports, Indicator Feeds, and Threat Actor Profiles. Statistics cover pipeline and program metrics, RFI and feedback figures, and a scope coverage view. A CTI-CMM maturity panel maps the program against levels CTI0 to CTI3. MISP integration All operational data resides in MISP using events, object templates, attributes, and event reports. This preserves auditability and allows teams to inspect raw records directly in MISP. The MISP event history serves as an audit trail for every change to a product, stakeholder, or requirement. Product content and supporting context sit together, so analysts move from collection evidence to published output without losing traceability. The built-in reference panel helps teams apply common intelligence concepts consistently, including the Admiralty Scale, TLP, and CTI evaluation criteria. Considerations The platform assumes you are already running or willing to adopt MISP as the backbone of your CTI stack. Teams without an existing MISP instance face additional deployment overhead. The AI summary feature in data collection is mentioned but the underlying model or service is not specified. Not independently verified. For CTI teams struggling with fragmented workflows, zsazsa provides a structured path from collection to delivery with built-in maturity measurement. The MISP-native design eliminates data silos between stages. 🔹 CTI #MISP #threat_intelligence #tool #zsazsa 🔗 Source: https://github.com/zsazsa-project/zsazsa

---------------- 🦠 Malware Analysis =================== KuinaExtractor: Six Months of a Rust Infostealer's Evolution ThreatRay published a detailed analysis tracking a Rust-based infostealer family across four major build iterations and two parallel experiments from December 2025 through June 2026. December 2025 — First Build The earliest builds were already full-featured: Chrome v20 App-Bound-Encryption bypass via LSASS impersonation for master key recovery, theft of Roblox cookies, Steam sessions, crypto wallets, and Discord tokens. Exfiltration used a Discord webhook. Privilege escalation relied on a single fodhelper/ms-settings UAC bypass. GitHub served as both CDN and disposable VPS/RDP infrastructure via GitHub Actions. January 2026 — Rewrite A rapid rebuild added substantial reconnaissance: eight WMIC hardware queries, WiFi SSID enumeration, Windows Credential Manager dump, a routine terminating 17 browser processes, victim-IP geolocation, and a loop disabling Microsoft Defender. Exfiltration shifted to a Telegram bot. The single UAC bypass was replaced by a function-pointer table with seven methods. March 2026 — Production Hardening The cookie-theft mechanism remained (LSASS/ABE chain, extended with ChaCha20-Poly1305 for newer Chrome versions). UAC bypass moved to SilentCleanup. Browser coverage grew to roughly 40 targets including CocCoc. Broad VM and sandbox detection was added. This variant is still observed today. June 2026 — "k0to" Rebrand The build dropped the "Kuina" name and shifted focus to concealment. It uses a self-contained HTTP stack (reqwest over hyper and rustls) with its own CA roots, 28-byte XOR string wrapping including the Telegram C2 URL, and scans PowerShell window titles for analyst tools. The Telegram channel is push-only. Parallel Experiments • KuinaCookieExtractor (January): Leaner codebase, Discord webhook exfiltration, lighter anti-analysis (logs VM warning and continues). Linked to same author via kuina build user, KUINA_UAC_BYPASS_ATTEMPTED sentinel, and kuina1999 handle. Disappeared after two weeks. • Zenith (April-May): Short-lived C2 experiment. Debug build shipped with verbose [DEBUG] traces to zenith_debug.txt, including author self-attribution. Mutex disguised as network adapter name. Panel at 103.229.53[.]18:3000 (Vietnamese AS135918). Abandoned within days. The developer iterates quickly and learns from deployment feedback. The self-contained TLS stack and XOR wrapping in k0to indicate awareness of network-based detection signatures. 🔹 KuinaExtractor #infostealer #malware_analysis #Rust #threat_intelligence 🔗 Source: https://www.threatray.com/blog/kuinaextractor-six-months-of-a-rust-infostealers-evolution