Trending Topics

UNC6783’s Okta Phishing Playbook: When Your BPO Helpdesk Becomes the Front Door

Google’s Threat Intelligence Group is tracking a new data‑theft extortion crew, UNC6783, that breaks into large enterprises by first compromising their business process outsourcers (BPOs), the third‑party support and customer‑service providers that sit between corporations and their customers. Using tailored social engineering over live chat, the group convinces helpdesk staff to click links to fake Okta login pages hosted on look‑alike domains such as <org>zendesk-support<##>com, then abuses captured session data and clipboard contents to enroll attacker‑controlled devices for long‑term access. This ecosystem‑first approach means the real targets are the big brands behind those BPOs, while the initial intrusion happens through a trusted partner that often has broad access but weaker defenses. Once in, UNC6783 layers additional tricks: fake “security update” prompts that deliver RATs, allowing full remote control of compromised machines and enabling large‑scale data theft before ransom demands are sent via Proton Mail. Industry experts quoted in the research stress that this is more than just another phishing wave; it's a deliberate shift to attacking relationships and support channels rather than core enterprise networks, exploiting the high‑trust, high‑volume nature of helpdesk interactions to bypass otherwise strong security controls. Researchers noted that the attackers do not need to technically break security systems if they can reliably persuade people to “open the door” on their behalf. Defenders should respond on two fronts: identity and ecosystem. On identity, Mandiant and Google recommend moving to phishing‑resistant FIDO2 security keys (such as Titan keys) instead of SMS or app‑based codes, tightening device‑enrollment workflows, and regularly auditing which devices are authorized in Okta and other IdPs. In an ecosystem, organizations must monitor and lock down support channels used by BPOs, inspect live chat logs for suspicious patterns and Zendesk‑style look‑alike links, and include partner helpdesks in phishing simulations and security training so that front‑line staff can recognize and escalate these chat‑based lures before UNC6783 turns them into a beachhead.

Adobe Reader Zero‑Day: Malicious PDFs Turn Built‑In Tools into Silent Data Exfiltration Channels

Hackers have been exploiting an unpatched zero‑day in Adobe Reader since at least November 2025, using specially crafted PDFs that execute as soon as they are opened, no extra clicks required. Researcher Haifei Li (EXPMON) found samples such as “Invoice540[.]pdf” that, once opened, run heavily obfuscated JavaScript which abuses built‑in APIs like util[.]readFileIntoStream and RSS[.]addFeed to read local files and exfiltrate data to a remote server at 169[.]40[.]2[.]68. This initial data theft and system fingerprinting stage could pave the way for more serious follow‑on activity, including RCE or sandbox escape to fully compromise the host. The lure content appears carefully tailored: analysis by Giuseppe Massaro (Gi7w0rm) shows Russian‑language PDFs themed around news and events in the Russian oil and gas industry, likely sent as realistic‑looking email attachments to selected targets. The campaign echoes a previous Adobe Reader issue, CVE‑2024‑41869, also reported by Li, illustrating a pattern of high‑impact Reader flaws attractive to targeted attackers. Adobe was notified of the new zero‑day around April 7 but has not yet released a patch, leaving users temporarily reliant on workarounds and defensive hygiene. Until an official fix is available, organizations should treat unsolicited or unexpected PDFs as high‑risk, especially invoice‑ or industry‑themed files, and consider opening them only in hardened, isolated viewers. Network defenders should monitor and block outbound connections to the identified C2 infrastructure and follow Li’s advice to filter traffic that references “Adobe Synchronizer” in headers, which can disrupt the malware’s communication channel. Enterprises may also want to restrict JavaScript in PDF readers where operationally feasible, tighten email filtering around PDF attachments, and prioritize rapid patching of Adobe Reader once an update is released.

GlassWorm’s Zig Dropper: One Fake Extension, Every IDE on Your Machine

A new phase of the GlassWorm campaign is abusing a malicious Open VSX extension to silently plant its malware across virtually every IDE a developer uses. Researchers at Aikido Security found a trojanized extension named code-wakatime-activity-tracker that impersonates the legitimate WakaTime time‑tracking plugin, matching its commands, UI, and API prompt flow while quietly bundling a Zig‑compiled native binary. When the extension’s activate() function runs, it loads this binary (e.g., win[.]node on Windows, mac[.]node on macOS), which scans the system for installed editors like VS Code, Cursor, and VSCodium, then force‑installs a second‑stage [.]vsix into each one using that editor’s own CLI installer. The second‑stage extension is the same GlassWorm dropper previously seen in supply‑chain attacks against Open VSX, Microsoft’s Visual Studio Marketplace, npm, and GitHub, where it hid malicious logic in invisible Unicode characters and used Solana blockchain “dead drops” to resolve C2 infrastructure. Once deployed, it geofences out Russian systems, beacons to Solana‑based C2, and pulls additional payloads that steal credentials, drain cryptocurrency wallets, turn infected machines into SOCKS proxies, and install a persistent RAT plus a fake Chrome extension for surveillance. This evolution, from JavaScript‑only implants to a native Zig dropper that automatically propagates to every detected IDE, marks a significant escalation in the efficiency with which GlassWorm can turn a single developer compromise into a multi‑tool, multi‑environment foothold. For engineering and security teams, the takeaway is that IDE extensions now represent a critical supply‑chain layer, not just developer “productivity” add‑ons. Defenses should include strict policies around which extensions can be installed (and from where), code‑signing and allow‑listing for approved plugins, and continuous monitoring for unexpected [.]vsix installs or new extensions appearing across developer fleets. Organizations should also scan existing extensions for known GlassWorm indicators (e.g., invisible Unicode in source, Solana‑based C2 beacons), lock down developer credentials and tokens that could be abused to force‑push malicious updates, and treat alerts from developer machines as potential supply‑chain issues with blast radius far beyond an individual workstation.

Marimo RCE in Hours: CVE‑2026‑39987 Shows How Fast “Niche” Tools Become High-Value Targets

A critical pre‑auth RCE bug in Marimo, an open‑source Python notebook for data science, was exploited less than 10 hours after public disclosure, underscoring how quickly attackers can weaponize newly disclosed advisories. Tracked as CVE‑2026‑39987 (CVSS 9.3), the flaw affects all Marimo versions up to and including 0.20.4 and is fixed in 0.23.0. The issue stems from the /terminal/ws WebSocket endpoint, which, unlike other endpoints that call validate_auth(), performs no authentication checks, allowing any unauthenticated remote user to obtain a full PTY shell and execute arbitrary system commands on exposed instances via a single WebSocket connection. Sysdig observed the first exploitation attempt against a honeypot just 9 hours and 41 minutes after the advisory went live, even though there was no published PoC at the time. The attacker manually connected to /terminal/ws, enumerated the file system, and quickly pivoted to credential theft, targeting the [.]env file, SSH keys, and other sensitive files, then returned an hour later to re‑access the environment file and check whether other actors had appeared on the same host. Over a 90‑minute window, they connected four times with pauses, behavior consistent with a human operator working through a target list rather than automated mass exploitation, and notably did not deploy miners or persistent backdoors, suggesting a focused credential‑harvesting operation. For defenders, this incident is a clear reminder that “obscure” internet‑facing services are not safe simply because they are niche. Any application with a critical advisory, and especially one that exposes shell or notebook functionality to the web, should be assumed exploitable within hours of disclosure, leaving a shrinking window for patching and hardening. Organizations running Marimo should immediately upgrade to 0.23.0 or later, remove /terminal/ws from direct internet exposure (e.g., put it behind VPN or Zero Trust access), and audit affected hosts for unauthorized shell access and credential theft from [.]env files and SSH directories. More broadly, teams should treat dev and data‑science tools like Marimo as production‑grade services in their vulnerability management: track them in asset inventories, monitor new CVEs, and be prepared to respond as rapidly as they would for mainstream platforms like web servers or CI/CD systems.

Chrome 146’s DBSC: Turning Stolen Cookies into Useless Loot for Info‑Stealers

Google is rolling out Device Bound Session Credentials (DBSC) to all Windows users on Chrome 146, with macOS support planned next, aiming to blunt one of today’s most profitable attack paths: session cookie theft by infostealer malware such as Atomic, Lumma, and Vidar. DBSC cryptographically binds a user’s authenticated session to a specific device using hardware security modules like the TPM on Windows (and soon the Secure Enclave on macOS), generating a non‑exportable key pair and requiring Chrome to prove possession of the private key before issuing short‑lived cookies. As a result, even if malware exfiltrates session cookies, they quickly expire and cannot be replayed on a different machine, dramatically reducing the value of cookie “logs” traded on criminal markets. If a device lacks secure key storage, DBSC gracefully falls back to standard behavior, avoiding login breakage while still enabling broader adoption over time. Google says early telemetry shows a significant drop in successful session hijacking for users participating in DBSC testing, and it is working with Microsoft to push the mechanism as an open web standard that other browsers and services can adopt. The protocol is explicitly designed to be privacy‑preserving: each site gets its own per‑session public key, and no device identifiers or attestation data are exposed, preventing DBSC from becoming a cross‑site tracking or fingerprinting mechanism. For defenders and enterprises, DBSC is a strong additional layer, not a replacement for existing controls such as MFA, EDR, and malware filtering. Security teams should plan to enable and support Chrome 146+ on Windows (and upcoming macOS releases), treat DBSC as part of their strategy to contain infostealer damage, and update user awareness materials to explain why keeping browsers current is now directly tied to protecting account sessions. In parallel, organizations should continue monitoring for infostealer infections, limit session lifetimes and scope for critical apps, and prepare to take advantage of DBSC integration options as Google extends support to more platforms and enterprise use cases.