Update: Google Findings on ShinyHunters SSO-Driven SaaS Intrusions
Recent intrusions tied to ShinyHunters, Scattered Spider, and the Scattered LAPSUS$ Hunters label reinforce the idea that identity has become the primary entry point into SaaS environments. Instead of exploiting software flaws, operators impersonate IT or support over the phone and push employees into actions that grant real access. Because SSO links many services together, one successful interaction can open multiple business systems and rapidly expand exposure. Once inside, attackers rely on built-in admin and export capabilities to inventory connected apps and pull large datasets, which can look normal in logs. The public-facing branding does not reliably indicate who performed the intrusion; the SLH name functions more as a pressure tool and a way to blur attribution. The business impact is driven by data theft first and, later, by extortion, sometimes delayed long enough to complicate investigation and customer messaging. New reporting from Google and Mandiant shows this playbook expanding in January 2026, with multiple crews tracked under internal identifiers (UNC6661, UNC6671, UNC6240), pointing to more than one operator set using similar tactics. Compared to our earlier reporting that focused on consent-based OAuth and federated SSO abuse, this activity shows a shift toward stealing SSO credentials and MFA codes through victim-branded login sites, then registering attacker-controlled devices to make access more durable. Victims were told MFA settings were being updated and were directed to company-branded SSO pages hosted on deceptive domains following patterns including companyname-sso.com and companyname-internal.com; those sites captured usernames, passwords, and MFA codes, then enabled the attackers to enroll their own device, with many domains tied to NICENIC and a parallel set more often registered through Tucows. After initial access, attackers pivoted through Okta-connected environments and pulled data from cloud platforms used for collaboration, sales operations, document signing, and internal messaging, with targeted searches for sensitive business terms and personal data. In at least one incident, the actor enabled the ToggleBox Recall add-on in Google Workspace and deleted security notification emails, reducing the likelihood that the victim would notice new MFA enrollment activity. Google Threat Intelligence Group links follow-on extortion to UNC6240, including ShinyHunters-branded emails, a consistent negotiation channel, proof samples hosted via Limewire, 72-hour payment pressure, and escalation through harassment, SMS outreach, DDoS, and a new ShinyHunters-branded leak site that appeared in late January 2026. Defenders should move high-risk users to phishing-resistant MFA using FIDO2 keys and passkeys, tighten help-desk and account recovery with strong identity checks and verified call-backs, restrict new app authorizations and device enrollments to approved workflows, and alert on new MFA devices, new OAuth or connected-app authorizations, unusual bulk exports, and first-time access to sensitive SaaS data from unfamiliar locations, devices, or off-hours sessions.
State-Backed Supply Chain Attack on Notepad++ Update Servers
Notepad++ was affected by a supply chain intrusion in which attackers compromised the project’s update infrastructure and used it to deliver malicious installers to a narrow set of targets. The activity began in June 2025, when the threat actors gained access to the shared hosting environment supporting the update management system, and they maintained a long-running presence to study and control update traffic. Their direct access was disrupted on September 2, 2025, but stolen credentials enabled them to continue accessing internal services and interfering with updates until December 2, 2025. The operation was selective rather than broad, redirecting update checks for specific users to attacker-controlled servers, which is consistent with a high-confidence, intelligence-driven campaign. Researchers assessing the incident point to a China-aligned, state-backed operator based on the restraint, targeting discipline, and technical execution. The key issue was not a flaw in the editor’s core code, but weaknesses in older update verification that made update traffic easier to manipulate. From a business risk perspective, this is the core supply chain problem: trusted update workflows can become a delivery channel even when endpoints are otherwise well defended. The attackers appear to have used infrastructure control to alter an update endpoint that returns download locations, sending targeted victims to malicious packages that looked legitimate at first glance. Investigation notes suggest the operation focused only on Notepad++ rather than opportunistic compromise of other tenants on the same server, reinforcing that this was a deliberate campaign. Notepad++ responded by moving to a new hosting environment and hardening its updater, adding stronger checks for certificates and installer signatures in version 8.8.9. It also introduced digital signing of update responses, with mandatory verification expected in version 8.9.2 within about a month. Recommendations include ensuring all users are upgraded to at least 8.8.9 and move to 8.9.2 as soon as it is available; block or retire older versions that lack modern verification; restrict software installs to approved sources and enforce installer signature checks; and monitor for unusual update behavior, including unexpected download domains, repeated update prompts, or installer launches that do not match standard IT workflows.
ShadowHS Stealthy Fileless Linux Malware for Post-Compromise Control in Enterprise Environments
ShadowHS is a fileless Linux malware framework built for post-compromise control rather than quick smash-and-grab outcomes. It runs fully in memory, avoids disk writes, and uses anonymous file descriptors plus process-name spoofing to blend into routine system activity. The infection chain starts with a multi-stage, encrypted shell loader that unwraps and executes the payload only after verifying key runtime dependencies are present, including OpenSSL, Perl, and gzip. The payload is reconstructed via a decoding pipeline and executed directly from memory via paths that reference /proc/<pid>/fd/<fd>, thereby avoiding the traditional artifacts that defenders rely on. Reporting does not tie ShadowHS to a single Linux distribution or a specific kernel release; the technique is applicable across common enterprise Linux server builds where these standard features and utilities are available. The net effect is a hands-on, operator-controlled framework that can persist quietly and remain effective even when file-based security controls are strong. Operationally, ShadowHS behaves with restraint early on, prioritizing environmental mapping, security control discovery, and safety checks before taking more aggressive actions. It fingerprints enterprise security agents and hunts for competing malware to maintain exclusive control of the host, which can manifest as unusual process termination and repeated scanning of system services, kernel protections, and /proc telemetry. Key things to watch for include processes whose backing executable appears as “deleted” or originates from /proc/*/fd/*, mismatches between the visible process name and the true execution path, sudden bursts of reconnaissance commands, and outbound connectivity that does not match baseline patterns for that server role. When operators escalate, the framework supports data theft via covert user-space tunneling, attempts lateral movement by probing for SSH services, and later activates cryptocurrency mining that produces sustained CPU spikes and new outbound connections to mining infrastructure. Defenders should prioritize detections for memory-backed execution and /proc file-descriptor launches, add alerts for process-name spoofing and abnormal parent-child process chains, enforce strict egress allowlists on Linux servers, and tighten SSH hygiene with key rotation, removal of unused keys, password authentication controls, and rapid review of new or unexpected access paths across your Linux fleet.
Arsink Cloud-Native Android RAT Abusing Trusted Platforms for Data Theft and Remote Control
Arsink is an Android remote access trojan built to steal sensitive data and give attackers hands-on control of infected devices. It spreads mainly through social engineering, with malicious apps pushed through Telegram channels, Discord posts, and direct download links hosted on MediaFire. The campaign appears high-volume and fast-moving, with researchers tracking over 1,200 distinct app packages, indicating constant repackaging and churn. Many variants hide their infrastructure by using common cloud services for command-and-control and file transfer, helping their traffic blend in with normal app behavior. The lures impersonate more than 50 popular consumer brands, including Google, YouTube, WhatsApp, Instagram, Facebook, and TikTok, and often pitch “premium” versions that offer little real value. Once installed, these apps quickly request broad permissions and then run quietly while harvesting device details, account emails stored on the device, SMS messages, call history, contacts, microphone audio, and files stored on the device. Beyond collection, Arsink supports remote commands that let operators manipulate the device, including sending on-screen prompts, running text-to-speech, initiating calls, managing files, and even wiping external storage. For stealth and persistence, it can hide its launcher icon and keep running through a foreground service that looks routine to the user. Infrastructure analysis suggests a wide victim footprint, with notable concentrations in Egypt and Indonesia, followed by Iraq, Yemen, and Türkiye, plus additional clusters across Pakistan, India, and Bangladesh. The good news is that known versions are not reported to be distributed through Google Play, and Google Play Protect can warn on suspicious apps, including sideloaded installs. zLabs coordinated reporting to disrupt parts of the abused backend, but rapid variant changes mean user behavior still drives most risk. The most effective steps are to block sideloading where possible, treat “mod” app links in chat platforms as high risk, require installs only from approved app stores, review and revoke excessive app permissions, and monitor mobile fleets for apps that hide icons, request SMS or accessibility access without a clear business need, or show sudden spikes in background network activity.
