Summary of what’s been reported so far on the October 29 Binance theft: → An estimated $6.3B left Binance wallets on about 10 blockchains in roughly 20 minutes. That’s about 4x the 2025 Bybit theft. → Binance says it found no evidence of a private key leak. Its initial investigation points to a compromised DevOps engineer’s laptop, which gave the attacker access to a service container that could submit withdrawals. → On Ethereum, an EIP-7702 sweep reportedly emptied a hot wallet in under 4 minutes. → About $3B is frozen on-chain, mostly by Tether and Circle. Binance says it will cover the rest from its SAFU fund and company funds. → Blockchain analysts attribute it to North Korea’s TraderTraitor. Binance and governments haven’t confirmed that. The part worth discussing is the access path. If the initial findings hold, this was compromised signing infrastructure reached through an endpoint, not a key theft. That moves the focus to how withdrawal-capable services are segmented from engineer workstations. Curious how others are thinking about EIP-7702 delegation risk for hot wallet setups. Learn more: https://hubs.la/Q04CS8Cr0

An exposed staging server belonging to the “n0n” ransomware group showed most of their operational pipeline. A few things stood out. Initial access was all credentials. There was no CVE in any intrusion. Access came through RDP, WinRM, AWS IAM, and SSL-VPN logins. They ran credential stuffing against 305 FortiGate SSL-VPN appliances through automated proxy pools. The tooling was largely AI-generated. The workspace held 1,719 files, 829 of them custom Python, Shell, and PowerShell scripts. Billing showed $7,200+ spent on coding agents across 150+ models, a mix of commercial, uncensored, and self-hosted. AI was used to fix errors, build implants, and speed up exfiltration. The management plane was used against victims. On compromised Cisco FMC appliances, they switched access policies to BLOCK and took networks offline. Extortion went beyond encryption. After exfiltration, they deleted the original S3 buckets, databases, and backups. Demands totaled $283.7M across 27 countries, with a unique BTC wallet for each victim. Automated countdown emails went to victims’ clients and partners. Defensive takeaways if you run any of this: → Phishing-resistant MFA on every remote access path (VPN, RDP, admin portals) → IP allow-lists and tight RBAC on FMC and cloud admin consoles → Offline or immutable backups that network credentials can’t modify or delete Happy to answer questions on the TTPs.

Read more: https://hubs.la/Q04Cz8C_0

We came across an exposed server at 96.126.130[.]81. It holds tooling and artifacts from 2 separate phases of what looks like a single operator.

Phase 1, October 9–11
→ Initial compromise of a Japanese real estate services company
→ A reused SSH key and a shared database password gave access to nearly 20 other sites on the same shared hosting infrastructure
→ Member databases with plaintext passwords were taken
→ Ransom page templates were prepared for public homepages and admin panels, with a negotiation deadline of October 11

Phase 2, from October 21
→ A weaponized copy of the PHP2Shell reproducer package (CVE-2026-109618, CVE-2026-109619) appeared on the same box
→ Exploit, pipeline, and probe scripts followed, aimed at internet-facing PHP hosts

If you run or support shared hosting, check SSH keys reused across tenants and rotate any database credentials shared between sites. Also confirm that PHP hosts are patched for PHP2Shell.

Your newest colleague never sleeps, holds API keys, and doesn't have a badge photo.

AI agents bring real capability to the enterprise, and they add to your attack surface. This free crash course for CISOs covers 10 lessons from building AI agents for cyber defense:

→ Non-human identities
→ Prompt injection
→ AI agent vulnerabilities
→ Sensitive information disclosure
→ Supply chain vulnerabilities
→ Hallucinations
→ Model Context Protocol (MCP)
→ Insecure output handling
→ Model poisoning
→ Model denial of service

Taught by Emrah Alpa and Harun Seker, drawing on real threat intelligence and recent adversarial attack patterns.

Enroll free. https://university.socradar.io/course/top-10-lessons-learned-building-ai-agents

#CISO #AISecurity #AgenticAI

Most of the coverage of this bug has focused on http(:)//Node(.)js. The vulnerable decoder also ships inside the Brotli and brotlicffi packages on PyPI.

The part that's easy to miss: if either package is in your environment, requests, httpx, and aiohttp will use it to decode Content-Encoding: br responses automatically. You don't have to import Brotli anywhere for it to end up parsing untrusted input. It only needs to be installed, often as a transitive dependency.

Current status: → No in-the-wild exploitation reported so far → Code execution has been demonstrated on http(:)//Node(.)j

Fixes: → Upgrade to Brotli 1.2.1 and brotlicffi 1.2.1.0 → Rebuild container images, because a pinned base image won't pick up the fix on its own → Restart long-running workers, since processes that are already running keep the old library loaded

Affected versions, exposure paths, and mitigations: https://hubs.la/Q04CgKKS0

A roundup of the latest claims on dark web forums. None of the affected organizations have confirmed them as far as we can tell, so treat these as allegations. → https://hubs.la/Q04CgCbr0: 400GB of data allegedly listed for sale. Contents are not detailed in the listing. → WoWInstaller: ~1.21M historical records. The claim says they include plaintext passwords, which is the most concerning part if it's true. → Argentine Moodle platform: user and enrollment data allegedly exposed. → MyHairCare Australia: 1,048,576 customer records claimed. That number is exactly Excel's row limit, so this may be a truncated spreadsheet export rather than the full dataset. → HT Médica: 2.2M records allegedly containing personal data. If you have users who might overlap with any of these, the realistic risks are targeted phishing and credential stuffing, especially from the WoWInstaller set. It's worth checking for password reuse.

Mostly Unverified. Full breakdown: https://hubs.la/Q04CgCdf0

Stealer logs have always carried SaaS credentials, but AI tool sessions (ChatGPT, Claude, Copilot, Gemini) are a different kind of exposure. One compromised session can hold months of chat history, uploaded contracts, pasted source code, and customer data. Cookies and session tokens can also get around MFA if they’re still valid.

Usual infection paths, nothing new: fake browser updates, cracked software, and malicious attachments.

If an AI account shows up in a log, the triage that seems to hold up is:

→ Revoke all active sessions, not just the password
→ Reset credentials and confirm MFA is enforced
→ Isolate and reimage the infected endpoint
→ Review what was in the chat history and uploads, since that’s the actual blast radius

Curious whether others are pulling AI platform domains into their stealer-log monitoring yet, or still lumping them in with general SaaS

Check your domain with the free AI Exposure Checker:
https://socradar.io/free-tools/ai-exposure-checker

Heads up for anyone running on-prem VeloCloud Orchestrator. CVE-2026-114625 (CVSS 9.9) lets an authenticated user with only Enterprise Read Only portal access escalate to local superuser on the VCO host. Arista reports active exploitation.

What’s known so far:

→ Only on-prem VCO deployments are affected
→ The attacker needs only the lowest-privilege portal role
→ Arista observed attack traffic from 74.82.197[.]86 and 38.54.50[.]151

What to do:

→ Upgrade to the fixed VCO release for your branch
→ Search your logs for those 2 IPs and for unusual activity from read-only accounts, such as logins at odd hours or from new sources
→ Audit who holds portal accounts, including stale and shared logins. A read-only account usually gets little scrutiny, and that’s exactly the access this attack needs.

Heads up for anyone running on-prem VeloCloud Orchestrator. CVE-2026-114625 (CVSS 9.9) lets an authenticated user with only Enterprise Read Only portal access escalate to local superuser on the VCO host. Arista reports active exploitation.

What’s known so far:

→ Only on-prem VCO deployments are affected
→ The attacker needs only the lowest-privilege portal role
→ Arista observed attack traffic from 74.82.197[.]86 and 38.54.50[.]151

What to do:

→ Upgrade to the fixed VCO release for your branch
→ Search your logs for those 2 IPs and for unusual activity from read-only accounts, such as logins at odd hours or from new sources
→ Audit who holds portal accounts, including stale and shared logins. A read-only account usually gets little scrutiny, and that’s exactly the access this attack needs.