Two million home routers, smart TVs, and baby monitors — rented out as proxy nodes to cybercriminals, and the device owners had no idea. The FBI’s seizure of the NetNut residential proxy platform is the lead story today, and it is the kind of infrastructure-level takedown that forces a real conversation about device visibility. If your network has unmanaged IoT devices (it does), you need to know whether any of them are talking to someone else’s command infrastructure. Separately, CitrixBleed 2.0 is already in the wild, Medtronic confirmed a 3.8-million-record breach, and a ToddyCat-linked malware family is reading corporate Gmail without ever stealing a password.

In the News

FBI Seizes NetNut Proxy Network — 2M+ Home Devices Enrolled Without Consent

The FBI dismantled the NetNut residential proxy platform and its underlying POPA botnet infrastructure, which had enrolled over 2 million compromised consumer devices — home routers, smart TVs, streaming sticks, and assorted IoT hardware — as proxy relay nodes. The service sold this bandwidth to paying customers, many of whom used it to mask malicious traffic including credential stuffing, ad fraud, and ransomware command-and-control communications.

The devices were enrolled without their owners’ knowledge. The compromise vector varied: some devices were infected through known firmware vulnerabilities that were never patched, others through default credentials that were never changed. Once enrolled, each device became a proxy exit node, making the criminal’s traffic appear to originate from a residential IP address. This defeats IP reputation lists and geographic access controls — the traffic looks like a legitimate home user browsing the internet.

For enterprise defenders, the operational question is straightforward: do you have visibility into every device on your network, and would you detect one of them proxying outbound traffic it should not be generating? Most organizations have unmanaged IoT devices on corporate or branch networks. A compromised smart TV in a conference room or a consumer-grade router on a retail site could be doing exactly this. The network segmentation fundamentals that matter here are device profiling (know what is on the network), micro-segmentation (restrict what each device class can reach), and east-west traffic monitoring (flag devices generating traffic patterns inconsistent with their function).

What defenders should do: Deploy device profiling and network access control to identify and segment unmanaged IoT devices. Monitor for anomalous outbound connection volumes from devices that should be near-silent — a smart TV making hundreds of outbound connections per hour is a high-fidelity indicator of proxy enrollment.

CitrixBleed 2.0 (CVE-2025-5777) Exploited Same Day as Disclosure

A new vulnerability in Citrix NetScaler ADC and Gateway, immediately dubbed CitrixBleed 2.0, is being actively exploited by Anubis ransomware operators. CVE-2025-5777 is an information-disclosure flaw that allows remote, unauthenticated attackers to retrieve arbitrary memory contents from the appliance — including session tokens, authentication cookies, and cached credentials. The mechanism mirrors the original CitrixBleed (CVE-2023-4966): a crafted HTTP request triggers an out-of-bounds memory read, and the response contains sensitive data that was never meant to leave the device.

A public proof-of-concept appeared within hours of the vulnerability’s disclosure, and confirmed exploitation followed the same day. Anubis ransomware operators are using stolen session tokens to bypass authentication entirely, establish VPN sessions as legitimate users, and move laterally into target environments. This is the zero-day to exploitation timeline collapsing to zero — there was no patch window at all for organizations that did not apply the fix before the PoC went public.

What defenders should do: Patch NetScaler ADC and Gateway immediately. If patching is delayed, invalidate all active sessions and rotate all credentials that may have been cached by the appliance. Segment NetScaler appliances so that a compromised edge device cannot reach internal resources without passing through additional authentication and authorization controls. Monitor for session token reuse from unexpected source IPs — MITRE ATT&CK T1550.004 (Use Alternate Authentication Material: Web Session Cookie).

Medtronic Confirms 3.8M Customer Records Stolen by ShinyHunters

Medical device manufacturer Medtronic disclosed that ShinyHunters compromised its corporate IT systems and exfiltrated 3.8 million customer records containing personal and medical data. The breach is part of ShinyHunters’ sustained 2026 campaign, which has also hit Nissan and Oracle. Medtronic has begun customer notification and is cooperating with law enforcement.

The critical architecture question for organizations in healthcare and device manufacturing is whether a corporate IT compromise can reach systems that store patient or device data. If the corporate network and the device-management or patient-data environment share authentication infrastructure, flat network segments, or common administrative credentials, then a breach of one is a breach of both. The IT/OT segmentation principles that apply to industrial control systems apply equally to medical device data stores — these environments must be architecturally isolated, not just logically separated by a VLAN tag.

What defenders should do: Enforce strict segmentation between corporate IT and any environment that stores regulated data (patient records, device telemetry, manufacturing systems). Implement data loss prevention controls that would detect and alert on bulk data exfiltration from these segments. Review authentication infrastructure for shared credentials or trust relationships that would allow lateral movement from corporate IT into regulated data environments.

ToddyCat-Linked Umbrij Malware Abuses OAuth to Hijack Corporate Gmail

Researchers linked a new malware family called Umbrij to the ToddyCat APT group. Umbrij abuses legitimate OAuth tokens to access corporate Gmail accounts through Google’s API, bypassing every password-based detection in the environment. The malware never steals a credential — it manipulates the OAuth consent flow to obtain an authorized token, then uses that token to read, search, and exfiltrate email through Google’s own API endpoints.

This exposes a blind spot that exists in most cloud-identity monitoring: organizations watch for password spray, credential stuffing, and token theft, but rarely monitor for anomalous OAuth consent grants or unusual API-based mailbox access patterns. The attack is entirely within the bounds of “authorized” API usage from Google’s perspective — the token is valid, the API calls are well-formed, and the access is indistinguishable from a legitimate integration unless you are auditing OAuth grants and correlating them with expected application behavior. MITRE ATT&CK T1550.001 (Application Access Token) and T1114.002 (Email Collection: Remote Email Collection) apply.

What defenders should do: Audit all OAuth consent grants in Google Workspace Admin Console. Restrict OAuth scopes to pre-approved applications. Monitor Google Workspace audit logs for anomalous mail.readonly or gmail.modify API access patterns from unrecognized application IDs. Deploy cloud access security broker controls that can detect and block unauthorized OAuth token grants in real time.

Defender Action Items

  • IoT/proxy exposure: Run a device profiling sweep across all network segments. Flag any device generating outbound connections inconsistent with its function. Segment unmanaged IoT devices into restricted VLANs with no lateral access.
  • CitrixBleed 2.0: Patch Citrix NetScaler ADC and Gateway immediately. Invalidate all active sessions post-patch. Rotate any credentials that were cached by the appliance. Monitor for session token reuse from unexpected source IPs.
  • Medtronic/data segmentation: Verify that corporate IT and regulated data environments (patient records, device management) do not share flat network segments or common administrative credentials.
  • OAuth/API abuse: Audit Google Workspace OAuth consent grants. Restrict OAuth scopes to approved applications only. Alert on mail.readonly API access from unrecognized application client IDs.

Detection Spotlight

Detect anomalous OAuth token grants in Google Workspace that could indicate Umbrij-style API abuse. This Splunk SPL query identifies new OAuth consent grants for Gmail scopes from application IDs not in your approved list:

index=gws sourcetype="gws:reports:admin" event.name="authorize"
| spath output=app_name path=events{}.parameters{}.value
| spath output=scopes path=events{}.parameters{}.multiValue{}
| where like(scopes, "%mail%") OR like(scopes, "%gmail%")
| search NOT [| inputlookup approved_oauth_apps.csv | fields app_name]
| stats count by app_name, actor.email, scopes, _time
| sort -_time

This query pulls OAuth authorization events from Google Workspace admin logs, filters for any grant involving Gmail-related scopes, and excludes known-good application IDs from a lookup table. Any hit is a high-fidelity indicator that warrants immediate investigation — legitimate OAuth grants for mail access should be rare and pre-approved. Maintain the approved_oauth_apps.csv lookup with your sanctioned integrations. False positive rate is low if the lookup is current.

References

Subscribe to the it-learn Brief

Get the daily cybersecurity brief in your inbox every weekday morning — news, SE angles, and detection queries.