The concept of a completely autonomous security operations center (SOC) — where data collection, analysis of suspicious events, investigations, and incident response happen without human intervention — is extremely compelling. This is especially true for organizations grappling with a chronic shortage of cybersecurity talent and a threat landscape that’s growing faster and more sophisticated by the day. Organizations everywhere would welcome an approach where automation helps relieve analyst workloads, shortens alert triage times, and finally eliminates the backlog of unaddressed alerts — which, by some estimates, accounts for 67% of all security events in the average corporate SOC.

While many vendors are already pitching solutions in this space, real-world implementation remains highly problematic. Practitioners report tangible success when using these tools for alert enrichment and filtering out low-priority noise or false positives. However, when it comes to autonomous decision-making and response, very few organizations have managed to achieve a meaningful return on investment.

Foundational roadblocks of an autonomous SOC: looking beyond AI

While leveraging AI for data analysis and decision-making sounds like a logical and relatively easy-to-implement idea, actually putting it into practice exposes and amplifies the exact same challenges organizations faced with SIEM, XDR, and SOAR platforms:

Source data quality. Issues with coverage, enrichment quality, tagging and normalization, which detection engineering teams in every SOC battle daily, become even more acute when AI is introduced. AI agents are more sensitive to data gaps than human analysts, so incomplete data can magnify the resulting errors.

Data consolidation and tool integration. The very problem SIEM was once invented to solve remains a headache for most organizations today. Interestingly, marketing for AI-driven SOCs often claims that “the SIEM is dead” because “agents can just query the EDR directly for telemetry”. In reality, however, even in a best-case scenario, this just means the SIEM disappears as a user interface while its core functions remain embedded within the data fabric of the agentic SOC.

Analysts’ trust. Even when AI is restricted to preliminary data gathering and recommendations, human analysts frequently don’t trust the output, leading them to waste time re-collecting and re-analyzing the same data. Practitioners frequently point to several flaws in current AI SOC implementations: poor handling of gray-area verdicts (when an alert is suspicious but not definitively malicious), lack of safe escalation workflows, and systems that fail to learn when a human analyst corrects their mistakes.

Context deficit. SOCs and security teams in general naturally rely on scantily documented information, such as business context and tribal knowledge, to accurately assess alerts and incidents. It’s very difficult to populate an AI system with that knowledge in a systematic way.

AI-specific issues critical for a SOC

Beyond traditional operational hurdles, fully autonomous SOCs face inherent flaws deeply rooted in the fundamental architecture of language models and AI agents.

Hallucinations and prompt injections. In a SOC environment, a single manipulated log field can easily become a viable exploit vector aimed directly at the agent. In a semi-autonomous setup, an AI hallucination is just a frustrating distraction that erodes analyst trust. In a fully autonomous SOC, however, a hallucination can trigger instantaneous, harmful actions across hundreds or thousands of endpoints simultaneously. A prime example of this risk is the widely cited incident at a Fortune 50 company, where an AI agent went rogue and rewrote access policies on its own.

Need for control. To combat hallucinations and over-automation, organizations typically rely on a human-in-the-loop (HITL) model to approve an agent’s actions. While this improves safety, it completely defeats the primary selling point of agentic AI: response times.

Compliance, audits, and accountability. The inherently stochastic nature of LLM outputs makes logging problematic. They often lack reproducibility and explanations. Consequently, an autonomous SOC will likely struggle to pass regulatory compliance audits. Simply put, current compliance frameworks were never designed to handle the unpredictable behavior of multiple interacting AI agents.

Strategies to overcome the challenges of an autonomous SOC

Specialized frameworks are emerging to address these built-in flaws of AI agents and language models. For the most part, these solutions focus on enforcing formal boundaries around AI privileges, and validating its actions.

Rigorous context engineering. Assuming source data is correct and properly enriched, the number of hallucinations can be minimized, and agent decision quality significantly improved by feeding the language model structured layers of context — such as alerts, user accounts, asset data, and enrichment data.

Narrowing the scope of work. AI agents are less likely to go off the rails when confined to highly repetitive, narrow tasks. For example, an “agent for collecting additional host data” is going to be more effective than an “autonomous threat hunter”.

Neurosymbolic validations and guardrails for agent actions. An Agent-Lock pipeline cleans untrusted log fields, and verifies proposed actions against existing CMDB/IAM policies. This approach enforces key rules, such as making it impossible for the AI to disable telemetry, while managing “autonomy budgets”.

Tiered autonomy over all-or-nothing automation. The Trusted Autonomy framework maps out progressive levels of AI independence based on human-in-the-loop roles and trust thresholds across monitoring, detection, and response. Low-risk operations like data enrichment and alert deduplication run fully automated, while high-blast-radius actions require mandatory human approval.

Governance-first architecture. The LanG platform, which utilizes a hierarchical approach: Governance → MCP → Agentic AI → Security, is one example. It enforces two mandatory human analyst check-ins, fully aligning the workflow with NIST SP 800-61 guidelines. The trade-off, however, is that this framework significantly scales back the solution’s autonomy.

Deterministic execution for high-risk actions. Triage and investigation are handled by a probabilistic AI model, but high-impact actions — like deciding to isolate a host or terminate a session — are based on deterministic code. This approach allows the system to satisfy the strict requirements of SOC 2 and other major regulatory frameworks.

Stateful admission control. For example, the recently proposed ACP protocol monitors behavioral patterns across agent execution logs. This makes it possible to catch rogue agents that are executing a series of individually harmless requests that add up to a coordinated attack.

Key takeaways and pitfalls

We can already confidently state that an autonomous SOC is highly unlikely to bring any improvements for organizations burdened by significant technical and operational debt in areas like data collection and enrichment or standardized incident response workflows. No layer of AI infrastructure will function without that baseline foundation firmly in place.

It’s also clear that, while AI streamlines analyst workflows, it doesn’t completely replace them. This is why Gartner’s prediction that there will never be an autonomous SOC still rings true in 2026. Deploying autonomous agents into the SOC shifts the center of gravity to complex investigations, but most importantly, to complex engineering. Teams will simply trade fine-tuning detection rules for managing AI agent playbooks, data pipelines, and decision-handling workflows.

For mature SOCs, the core hypothesis for the next one to two years is this: an autonomous SOC should be viewed as a direction rather than a destination. AI is already delivering tangible value today — specifically in correlation, enrichment, draft detection rules, and attack reconstruction — provided that each capability has proper security guardrails. These include a well-balanced human-in-the-loop review process for any action that impacts production environments. Security teams investing now in a structured, verifiable approach — one that actively anticipates emerging regulations — will be able to gradually integrate new agentic features into their SOC pipelines. Conversely, organizations that skip this layer will almost certainly run into roadblocks, likely forcing them to rebuild their systems and processes from the ground up.

Scientists at Graz University of Technology in Austria recently published a paper detailing a new method for tracking users’ activity through their web browsers. The most fascinating thing about this new technique — which they’ve named FROST — is that it relies on a computer’s solid-state drive (SSD) to do the spying. Without getting bogged down in technical details, here’s how the attack works: a hacker lures a victim to a specially crafted website; as long as the site is kept open, the attacker can track exactly what apps the user is launching, and what other web pages they’re visiting.

So, how do they pull this off? The first instinct is naturally to blame the browser. But in modern web browsers, every website runs in an isolated sandbox and is generally locked out from touching other tabs — let alone the computer’s actual hardware. While hackers do find loopholes in these defenses from time to time, that’s not what’s happening here. The FROST attack doesn’t need to break the browser; it works perfectly even with all standard security measures in place. Instead, it hijacks a completely legitimate browser feature called the origin private file system (OPFS), which gives websites their own virtual storage space to store data. However, while this storage is digitally isolated, the data is still physically written to the exact same SSD that every other app and website opened on the computer is using. The researchers discovered that if a malicious page constantly bombards the SSD with data requests, the microscopic delays in data access can help map out what else is running on the PC. Before we dive into the details of how they manage this, let’s take a quick look at the theory behind the attack.

A quick primer on side-channel attacks

The term “side-channel” refers to a method of spying on a computer — or even a single microchip — indirectly. Instead of intercepting the data itself, an attacker might analyze fluctuations in power consumption, monitor the temperature of specific components, or listen in on electromagnetic radiation, among other things. In theory, this means that someone could eavesdrop on a conversation in a room just by using a computer mouse, since the optical sensor can pick up sound vibrations. Similarly, watching a CPU’s clock speed fluctuate could allow a hacker to steal an encryption key. Even a simple LED light on a badge reader can leak enough data about the device’s inner workings for an attacker to clone a smart card.

The beauty of these indirect data leaks — at least from a hacker’s perspective — is that they’re not easy to spot. Device manufacturers rarely account for them when building security systems. The downside, however, is just as obvious: extracting information through a mechanism that was never meant for data transmission is often complex, slow, and laborious. The Austrian researchers focused on a specific subtype known as a contention side-channel attack. This is where a leak occurs because multiple processes are competing for the same resource. In this case, that contested resource is the storage drive’s bandwidth.

Inside the FROST attack

This specific side channel has actually been studied before, including in a 2025 research paper. Back then, however, the setup was rather straightforward: the researchers ran one program on a computer to act as the data source, while a second program running on the same machine tried to intercept that data. While that’s fine for a theoretical academic study, the attack model wasn’t exactly groundbreaking. After all, if a hacker can already run any program they wish, they don’t need to rely on complex side channels — they have plenty of direct ways to steal the data.

Still, last year’s study wasn’t a complete waste of time. It proved that the resolution obtained from monitoring an SSD is quite high, the data leak is real, and the captured information can actually be useful. The FROST attack is essentially a logical continuation of the same idea.

Here’s how it works in practice. Let’s say there’s a fairly large file on an SSD packed with random data. A specific process reads this data at regular intervals and clocks how fast it gets a response. This speed fluctuates depending on how busy the drive is with other tasks. These access delays are the telltale signs of the drive’s activity. The Austrian researchers demonstrated that plotting these delays over time can help pinpoint with reasonable accuracy what other task is running on the computer at that very moment.

The researchers mapped out latency graphs, like the ones shown above, for a wide variety of websites and locally running apps. What they found were distinct patterns — or digital fingerprints — generated every single time a specific site loads, or an app launches. Capturing these split-second launch or load windows requires monitoring the SSD continuously over a long period of time. However, these patterns proved to be remarkably consistent across different systems; the authors successfully tested their method on both a Linux desktop and an Apple Mac Mini. From there, the next step sounds simple enough: take a catalog of known fingerprints, measure real-world SSD delays, match the two up, and you know exactly what apps the user is opening, and what sites they’re visiting. But how to actually pull off this kind of surveillance under the radar, without planting malware on the victim’s computer?

And that’s where a relatively new browser feature called the origin private file system (OPFS) comes into play. A hypothetical attacker doesn’t have to trick the user into downloading a shady Trojan. All they need do is have the victim visit a specially crafted webpage, and that page will leverage OPFS to quietly track the SSD’s activity. The clever acronym brings all these moving parts together: FROST stands for Fingerprinting Remotely using OPFS-based SSD Timing. Here’s the step-by-step breakdown of how the entire attack plays out:

Method limitations

Like any side-channel attack, FROST isn’t exactly built for speed. It’s a slow, methodical process. To figure out just how slow, the researchers built a dedicated testbed to measure it.

The team ran a program on a computer to transmit data indirectly. Think of it as a digital spy broadcasting a secret message by changing how it interacts with the hard drive. For instance, a 1 in the binary message code could mean the program is actively using the SSD, while a 0 means it’s sitting idle. At the same time, they set up a receiver inside the web browser that accessed the storage drive via OPFS. Because both the browser receiver and the transmitter program were competing for the SSD’s bandwidth, the browser experienced tiny speed delays whenever the transmitter was actively sending data.

This bizarre setup managed to transmit data at 661 bits per second, with nearly 90% accuracy on a Linux desktop with an AMD processor. On an Apple Mac Mini running macOS, the transfer rate hit 719 bits per second, also hovering around 90% accuracy. While these numbers are slightly lower than those in last year’s study — which relied on apps installed directly on the computer — the gap isn’t actually that huge.

That said, the real threat of the FROST attack isn’t raw data transmission; it’s tracking what the user does. Even if a hacker has a database of digital fingerprints for specific apps and websites, the information leaked through a malicious site using OPFS is too noisy. After all, a computer is constantly reading and writing data from/to the SSD in the background. To slice through that digital noise, the researchers turned to a tool that’s becoming standard practice in modern cyberattacks: a neural network. AI trained on known SSD fingerprints could confidently pick out user activity even from a chaotic mess of background data. The final results are eye-opening. On the Apple Mac Mini, the AI accurately identified which website the user opened 89% of the time, and nailed local app launches with 96% accuracy. Crucially, it could even detect what websites were opened in a completely different browser than the one running in the malicious tab. It sounds like a total home run for hackers — except for a massive list of real-world catches.

Is the FROST attack a real-world threat?

Simply knowing which apps are opened or what websites are visited doesn’t give an attacker much leverage. This kind of data is usually useful to advertisers looking to build a user’s digital profile without their permission; however, rolling out this tracking method on a massive scale is hardly realistic. The roadblock comes down to the fundamental way computers handle data: the system regularly dumps frequently accessed data into its RAM. Because the entire FROST attack relies on measuring the relatively slow bandwidth of the physical SSD, the data in RAM is effectively invisible to this method. To bypass this hurdle, the malicious webpage would have to force the OPFS to create a massive file — well over a gigabyte in size. Needless to say, a website that hogs hard drive resources in such an aggressive way would immediately raise red flags. EDR or XDR solutions will most likely flag it as anomalous activity.

Ultimately, this means the FROST attack — like most side-channel spying methods — is only practical for highly targeted operations. But that brings us right back to square one: knowing what apps someone opens or what web pages they browse is a pretty measly reward for the massive effort required to pull off such a sophisticated stunt.

Even so, FROST is light-years ahead of most academic side-channel attacks when it comes to real-world practicality. It doesn’t require preinstalled malware, and the victim doesn’t have to do anything more than open a malicious page. If nothing else, this research is a stark reminder of just how complex modern computers are, and how many unexpected blind spots can lead to data leaks. When building ultra-secure systems for highly classified data, one absolutely has to consider hardware peculiarities. If the prize is big enough, a determined attacker will gladly invest the time to build a hyper-specific complex attack. Research like this serves as proof that, in the world of cybersecurity, that scenario isn’t impossible.

Unchecked AI in the workplace quickly becomes a massive loophole for data leaks and security breaches. All too often, employees drop sensitive company data into public chatbots, or install rogue AI assistants on their own — in the process handing over way too much access. In a previous post, we broke down the different types of risky AI systems, and later shared some tips on how to turn off the built-in AI features on major tech platforms. Today let’s take a look at practical ways to block or restrict the unauthorized “helpers” employees might be using — from ChatGPT and Grammarly, to meeting bots like Fireflies and Read AI.

How to detect and restrict ChatGPT

ChatGPT is the biggest culprit when it comes to unauthorized AI use worldwide. A quick word of warning, though: an outright ban only sends users hunting for sketchy third-party sites or messaging app chatbots that hook into the same service. That’s why it’s always a good idea to offer an approved alternative before pulling the plug.

Detecting it: keep an eye on the NGFW or web filter for traffic heading to chat.openai.com, chatgpt.com, oaistatic.com, oaiusercontent.com, or cdn.oaistatic.com. It’s also smart to use EDR/EPP tools to scan browser histories, installed apps, and browser extensions across corporate devices.

Locking it down: use the firewall or web filter to block the entire AI Services category, and set up DNS to reroute traffic away from those OpenAI domains. Browser policies can also be used to ban ChatGPT-powered extensions. Better yet, block all extensions not on a pre-approved allowlist. Finally, use application controls and EPP solutions to stop users from installing the official desktop app (ChatGPT.exe or com.openai.chat).

How to detect and restrict Claude and Claude Code

Detecting it: use the NGFW or web filter to track traffic going to claude.ai, anthropic.com, *.anthropic.com, and api.anthropic.com. EDR/EPP or application control tools can also be used to scan employee computers for the desktop app (claude.exe).

Locking it down: drop a blanket block on the AI Services category through the NGFW or web filter, and tweak DNS settings to reroute traffic away from the aforementioned Anthropic domains. Next, use browser policies to shut down Claude-powered extensions. Finally, use application controls and the EPP platform to prevent users from installing the desktop app.

How to detect and restrict Perplexity AI

Detecting it: keep tabs on the NGFW or web filter to flag any traffic heading to *.perplexity.ai or pplx.ai.

Locking it down: just like the others, add the AI Services category to the NGFW or web filter blocklist, and use DNS routing to redirect traffic away from those domains.

Configure the browser to block third-party extensions from being installed. If Firefox is used in the organization, be aware that recent versions come with Perplexity built in. Luckily, these AI features can be turned-off company-wide using enterprise policies — specifically, by setting SidebarChatbot = blocked. The full list of tweaks can be found in the Firefox documentation.

How to detect and restrict DeepSeek

Detecting it: keep an eye on the NGFW or web filter for traffic hitting deepseek.com, chat.deepseek.com, api.deepseek.com, or platform.deepseek.com. For better precision, analyze the SNI (server name identification) in TLS connection requests. For mobile devices, look out for the official app (com.deepseek.chat).

Locking it down: blocklist the AI Services category on the NGFW or web filter, and reroute traffic to DeepSeek’s domains via DNS settings. Use browser policies to block third-party extensions, and lean on MDM/EMM tools to restrict the mobile app.

How to detect and restrict Mistral, xAI Grok, and Character.ai

The playbook for these tools is exactly the same as DeepSeek, so here’s the quick list of domains to watch for and block: chat.mistral.ai, mistral.ai, console.mistral.ai, grok.com, x.ai, api.x.ai, character.ai, beta.character.ai, and c.ai.

A quick word of warning on Grok: because Grok is baked into X, blocking this specific AI access point means blocking the entire social media platform.

How to detect and restrict Slack AI

Detecting it: in the Slack workspace admin dashboard, look under Analytics → Slack AI usage. If an enterprise plan is used, the detailed Slack logs can be searched for any events starting with the ai_ prefix.

Blocking it with policies: in the organization’s Slack settings, click through the Workspace settings → Roles & permissions → Feature access, and change the permission to “no one”. Slack has a step-by-step guide in their help center.

Locking it down: shutting this down at the network level is tricky; it can be pulled off with a finely tuned CASB solution in place. Also, don’t forget the importance of blocking rogue integrations and keeping external AI services from tapping into Slack data in the first place. We covered how to lock this down using OAuth controls in a previous post.

How to detect and restrict Zoom AI Companion

Detecting it: if a corporate Zoom subscription is in use, just head to Admin Center → Reports → AI Companion usage. Detecting Zoom’s AI when employees join external meetings or use free accounts is a lot tougher, but email filters can be set up to flag incoming AI-generated meeting notes by scanning for subject lines or text containing “Meeting summary” or “Meeting assets”.

Blocking it with policies: for the company’s own Zoom subscription, go to the Admin Portal → Account Management → Account Settings → Meeting → AI Companion and toggle it OFF for everyone.

Locking it down: unfortunately, AI Companion is baked into Zoom’s DNA, so the only real option is blocking Zoom altogether.

How to detect and restrict Grammarly

What looks like an innocent spellchecker is actually one of the biggest culprits for workplace data leaks.

Detecting it: check the NGFW or web filter logs for traffic hitting grammarly.com, *.grammarly.com, and gnar.grammarly.com. EDR and MDM/EMM tools can also be used to hunt down the standalone desktop apps (Grammarly Desktop.exe and the macOS version), as well as the Grammarly browser extension.

Locking it down: use firewalls to block those domains at the network level, and EPP to stop employees from installing the desktop app, browser extensions, or the Grammarly add-ins for Microsoft Word and Excel.

How to detect and restrict meeting assistants: Fireflies, Read.ai, Tactiq, Fathom, and Granola

This massive category of third-party SaaS tools records and analyzes meetings — creating a massive risk for data leaks. The trickiest part? Outside clients or vendors can bring these bots into a meeting just as easily as employees can.

Detecting them: run an audit on calendar invites, and look for bot participants using email domains like @fireflies.ai, @read.ai, @tactiq.io, @fathom.video, or @granola.ai. Zoom, Teams, or Google Meet logs can also be used to review external participants who joined past calls.

Locking them down: since it’s impossible to control what outsiders do, blocking these bots comes down to tightening meeting rules. The best moves are: blocking users from granting OAuth permissions for bots to join calls, restricting employees from inviting unapproved external participants, or locking down meeting recording access for external users. That last option is usually the least painful way to keep bots out without disrupting business.

How to detect and restrict AI code editors: Cursor, Windsurf, and the like

Detecting them: use EDR/EPP tools to scan for executables like cursor.exe or windsurf.exe. It’s also worth monitoring network traffic heading to cursor.com and windsurf.com, as well as traffic hitting various AI model API providers. Keep in mind that there’s a pretty extensive list of API hosts to monitor here, since these editors aren’t tied to just one specific AI vendor.

Blocking them with policies: these apps can be prevented from being installed by setting up filters based on the developer’s digital signature certificate. Alternatively, a strict application allowlist can be employed where only pre-approved software is allowed to run.

Locking them down: rely on the EPP/EDR platform to actively detect and block these applications from running.

How to detect and restrict local AI tools: Ollama, LM Studio, and GPT4All

On one hand, this category carries fewer data leak risks because the AI models run completely locally on the user’s machine. On the other hand, it opens up a whole new can of worms: these apps themselves aren’t always highly secure, and can become targets for cyberattacks. Plus, it still means that employees can misuse models or process data in unauthorized ways.

Detecting them: EDR/EPP tools are the best line of defense here. They should be used to flag known local AI files and processes like ollama.exe, ollama serve, lmstudio.exe, LM Studio.app, jan.exe, or gpt4all.exe. From a network perspective, it’s worth scanning for open ports on local devices — typically port 1234 for Ollama and LM Studio, or port 8080 for WebUIs (using an additional fingerprint check of the server response). Another massive red flag is the presence of large files (often several gigabytes) containing language model weights. Look out for extensions like .gguf, .bin, or sometimes .safetensors.

Locking them down: use EPP/EDR platforms or windows AppLocker to block these applications by name, or switch to an application allowlist.

How to detect and restrict autonomous agents: OpenClaw, NemoClaw, and NanoClaw

This is easily one of the most dangerous categories of AI tools out there. These agents mix high-level independence with access to untrusted data, making them a massive security headache.

Detecting them: use EPP/EDR tools to sniff out active processes like openclaw, nanoclaw, nemoclaw, or clawdbot. Also keep an eye out for devices running Node.js that suddenly start launching Bash or Python scripts. Another dead giveaway is the appearance of system folders like ~/openclaw, ~/nanoclaw, ~/.claw*, or ~/clawhub. At the network level, monitor connections to the AI model APIs we mentioned earlier, as well as traffic hitting servers like openclaw.ai, nanoclaw.dev, or clawhub.*.

Locking them down: the safest bet is to use strict application allowlisting (only allowing approved software to run), or to specifically ban the known agent apps listed above. On top of that, consider blocking non-developers from installing Node.js and Docker, neither of which they need on their computers anyway.

Lately, software developers have been baking AI features straight into everyday work tools, operating systems, and browsers. In some cases, they’re genuinely handy. However, their presence introduces specific risks, which means plenty of companies are hesitant to give employees access to these tools. In a previous post, we categorized these unwanted AI systems, looked at how to spot them at the network and endpoint levels, and covered the ultimate universal kill switch: managing OAuth access across major corporate platforms. In this deep dive, we’re getting tactical: breaking down how to disable or restrict the AI built into popular platforms.

A quick heads-up: major software vendors occasionally change the names of their AI settings and tweak how they function. If any of the options mentioned below are missing or aren’t working as expected, a quick web search for the setting’s name will usually point you to its new location or branding.

How to turn off Microsoft 365 Copilot

Detection: you can check actual Copilot usage in the logs by going to Microsoft 365 admin →  Copilot usage report.

Disabling via policies: in the Microsoft 365Admin Center, go to Settings →  Integrated Apps, find Copilot in the Available Apps list, and select Block. More granular configuration policies are available under Customization →  Policy Management. The Policies page here contains over two thousand entries, so you’ll want to filter them by the keyword “Copilot” (detailed guide). Given that Copilot is a paid add-on for Office, another way to block it — and save money by doing so — is to simply avoid assigning users SKUs that include Copilot.

We recommend separately blocking Copilot Chat, which is available in Teams, Edge, Outlook, and several other services. Yes, it’s not Copilot itself. And yes, it has to be blocked separately by following this guide.

Additional layer of protection: you can block the domains copilot.cloud.microsoft and m365.cloud.microsoft/chat at the web filter or NGFW level. However, Microsoft explicitly advises against this, warning that it could break other Microsoft 365 features.

How to turn off Windows Copilot

Beyond the Office version of Copilot, you also need to manage its consumer-facing cousin.

Detection: look through your NGFW or other network logs for traffic hitting copilot.microsoft.com, bing.com/chat, or edgeservices.bing.com.
Disabling via policies: in Windows Group Policy, navigate to Computer Config →  Admin Templates →  Windows Components →  Windows Copilot. In Microsoft 365 Group Policy, go to Admin center →  Block consumer Copilot for organizational accounts.

Additional layer of protection: block the Copilot.exe executable from running entirely.

How to turn off the Copilot sidebar in Edge

Detection: look through your NGFW or other network logs for traffic hitting copilot.microsoft.com, bing.com/chat, or edgeservices.bing.com.

Blocking: configure the following MS Edge Group Policies: HubsSidebarEnabled = false, EdgeShoppingAssistantEnabled = false, CopilotPageContext = Disabled (false), CopilotNewTabPageEnabled = false, Microsoft365CopilotChatIconEnabled = false, GenAILocalFoundationalModelSettings = 1 (note that disabling this unexpectedly requires a 1 instead of a 0).

Second layer of protection: block the domains copilot.cloud.microsoft and m365.cloud.microsoft/chat at the web filter or NGFW level. However, Microsoft explicitly advises against this, warning that it could break other features.

How to turn off the Gemini Assistant in Google Workspace

Detection: check the Workspace Admin Console (admin.google.com), Gemini usage report section.

Blocking via policies: in the Admin Console, navigate to Apps →  Additional Google services → > Gemini app, and set it to OFF. Then, go to Manage Workspace smart feature settings →  Smart features in Google Workspace, and set it to OFF.

Second layer of protection: block network traffic to the domains gemini.google.com, bard.google.com, and aistudio.google.com.

How to turn off Gemini in Google Chrome

Detection: check your Chrome Enterprise reports (Chrome management →  Reports), or look through network traffic logs for connections to the previously mentioned domains.

Blocking via policies: in your Chrome Enterprise policies, configure the following settings: GenAILocalFoundationalModelSettings = 0, HelpMeWriteSettings = 2 (disabled), TabOrganizerSettings = 2, CreateThemesSettings = 2, DevToolsGenAiSettings = 2.

Additional layer of protection: block network traffic to the domains gemini.google.com, bard.google.com, and aistudio.google.com. Additionally, block unauthorized Chrome/Chromium installations (those outside your policy management) with the help of host-based application control tools like EPP/EDR or AppLocker.

How to turn off Apple Intelligence

Detection: on your NGFW and web filters, traffic hitting apple-relay.apple.com and *.apple-cloudkit.com is a clear indicator that Apple Intelligence is active.

Blocking via policies: any managed Apple device allows you to disable individual AI features, though there isn’t a master switch you can flip to shut down “all AI”. In your MDM profile, you need to set the following keys to false (disabled): allowWritingTools, allowMailSummary, allowGenmoji, allowImagePlayground, allowImageWand, allowPersonalizedHandwritingResults, allowExternalIntelligenceIntegrations, allowExternalIntelligenceIntegrationsSignIn, allowNotesTranscription, and allowNotesTranscriptionSummary. Here is a brief configuration example:

<dict>
<key>PayloadType</key>
<string>com.apple.applicationaccess</string>
<key>allowWritingTools</key>
<false/>
<key>allowMailSummary</key>
<false/>
</dict>

Despite Apple’s shift toward declarative device management, these AI features still need to be managed through traditional MDM payload settings.

Second layer of protection: block network traffic to the hosts mentioned above — though the obvious downside for mobile devices is that this won’t work once they leave the corporate network.

The Future of Threat Defense Resides at the IP Layer

For years, network security operated on a relatively predictable premise: inspect traffic, identify malicious content, and block it. Because deep content inspection created a seemingly robust defense in depth, relatively static legacy approaches—like reliance on threat intelligence feeds—were allowed to simply persist in the background.

The weaponization of agentic AI and highly evasive techniques has fundamentally shattered that model. Attackers are no longer just iterating on old threats. They are launching attacks at staggering velocity, completely outpacing threat feeds, and employing evasion tactics that actively starve legacy prevention solutions of the content they rely on to inspect.

Our new research report from Unit 42, Attackers Are Evading Threat Prevention at the Internet Edge, reveals how adversaries are actively exploiting the contextual vacuum at the IP layer to bypass standard security controls. For security leaders, understanding this shift is no longer optional. As the nature of the threat fundamentally changes, our strategic approach to network security must definitively change with it.

The AI-Accelerated, Evasive Attack Lifecycle

To understand why legacy defenses are failing, we must look at how adversaries are accelerating and obfuscating every stage of the attack lifecycle. As these threats progress, the commonly used network indicators we have long relied upon are vanishing, collapsing traditional defenses and leaving defenders with little to act on.

Powered by frontier AI, adversaries now automate reconnaissance and exploitation at huge scale and speed, while using anonymizers to mask their intent. Once an intrusion is launched, orchestration shifts to highly evasive command and control (C2). Attackers hide communications using advanced encryption and AI-built malware-less techniques. They’re also bypassing traditional web and DNS inspection entirely by routing traffic directly to IP addresses—a tactic Unit 42 found in 23% of modern malware

Ultimately, the takeaway is clear: network threat prevention can no longer rely solely on detecting malicious payloads. As AI-driven attacks continue to minimize their footprint, security strategies must augment content inspection with real-time IP layer monitoring to left-shift threat detection and counter these rapid, machine-speed threats at the network foundation.

Existing Approaches Aren’t Working

Where content-based detection falls short, many security vendors and organizations still rely on IP threat intelligence feeds to pick up the slack in an attempt to filter out malicious connections on the network layer. However, after years of operating under this model, the results are in—the traditional feed is showing its age.

Attackers have long relied on proxies, anonymizers, residential routers and public cloud providers as a tactic to evade detection. However, agentic AI morphs this process, enabling rapid infrastructure rotation and stealth at an unprecedented scale. As this autonomous evasion accelerates, experienced network defenders continue to run into the well-known limitations of classic IP blocklists:

• Too slow to keep pace: Unit 42 found an average 20-day lag time before new threats hit popular feeds. Because agentic AI enables adversaries to autonomously rotate proxy IPs in hours, these lists are obsolete at the moment of delivery.
• Fundamentally incomplete: IP feeds are unable to see a massive portion of the modern attack surface. Unit 42 research indicates that 52% of malicious IPs used for direct-to-IP connections are completely absent from these lists.
• Unactionable on shared infrastructure: Even known threats are often impossible to block. The Unit 42 team reports that 37% of direct-to-IP traffic uses reputable CDNs and cloud providers. IP feeds cannot distinguish malicious connections from legitimate ones, making blocking too risky for business continuity.
• A management nightmare: Among the security teams that Unit 42 polled, 30% indicate resource-intensive vetting and false-positive triage as their top pain point. To avoid breaking legitimate traffic, feeds are frequently relegated to an alert-only mode, defeating the entire purpose of prevention.

If modern and agentic AI-enabled attacks can outrun traditional network payload-based detections, we need a new weapon in the network defender’s arsenal. We can no longer depend on yesterday’s IP feeds to secure such an extremely agile threat environment.

The Blueprint for Modernizing the Internet Edge

To outpace the impact of agentic AI and advanced evasion on network threat prevention, security leaders must redefine their defense strategy and shift-left to track the attacker infrastructure itself—monitoring the exact IP layer locations where adversaries build and control their campaigns. Deep content inspection remains essential, but securing the modern edge requires establishing the context and intent of a connection before a session is established.

To achieve this goal, organizations must move beyond the limitations of static defense and adopt a modern security blueprint:

• Proactive protection against attacker infrastructure: While high-quality threat feeds remain essential for SOC investigations and incident response, relying on them for frontline, real-time prevention creates major blind spots. Instead, security teams must use real-world, global telemetry to proactively identify and block connections to attacker-controlled hosts before requesting a URL or file.
• Zero trust principles applied to the network layer: An IP address without a negative reputation does not equal a safe connection. Continuous verification requires extending zero trust down to the network foundation. It validates the real-time behavior and intent of every single session to ensure attackers cannot hide in the contextual vacuum of the IP layer.  
• Reducing the attack surface with rich contextual attributes: Traditional IP blocking is like a blunt instrument that creates unacceptable false positives and alert fatigue. To modernize the edge, security teams need deep, attribute-based visibility across the entire Internet address space to reduce noise and replace legacy IP feeds entirely.  

By moving away from point-in-time assumptions and embracing real-time, inline protection, security leaders can reclaim the advantage at the network foundation.

To see how these evasion tactics operate in the wild, read the latest Unit 42 report, Attackers Are Evading Threat Prevention at the Internet Edge. You’ll find this report valuable in understanding the systemic gaps in legacy risk models and learning why continuous verification must be our new mandate.

The post How AI and Evasion Demand a Radical Shift in Network Threat Prevention appeared first on Palo Alto Networks Blog.

According to global research, the market share of highly automated, driverless vehicles is growing rapidly. Analysts estimate that the next 10 to 15 years will mark a major shift from pilot projects to the mass adoption of autonomous transport. The momentum is building worldwide: Europe has already rolled out over 35 autonomous vehicle pilots, while the U.S. and China log more than 450 000 and 250 000 commercial trips per week, respectively. However, the report notes several roadblocks slowing down this progress. One such hurdle is the uncertainty surrounding legal liability and regulation, including in the areas of safety and security. The allocation of responsibility among suppliers, manufacturers, enterprise clients, and end users remains a major point of discussion.

Each market stakeholder sees the issue of ensuring the safety of autonomous vehicles differently. For automakers, it means taking responsibility for how a vehicle behaves on the road and for vetting their suppliers. For the suppliers themselves, it means designing security mechanisms directly into their solution architecture from day one and guaranteeing their adequacy. For insurance companies, it means completely overhauling their risk models to account for not just accidents, but also potential software glitches and cyberattacks. Ultimately, everyone agrees on one fundamental point: security must be a foundational feature of the vehicle — not an optional add-on.

Ensuring vehicle security in the modern era

For years, discussions around automotive safety focused strictly on functional safety. In other words, the goal was to ensure that vehicle systems operated correctly, and that risks associated with potential failures were fully mitigated or reduced to an acceptable level. The ISO 26262 standard “Road vehicles — Functional safety” helps address this very challenge, and serves as the baseline for the automotive industry.

However, the modern connected vehicle is a complex cyberphysical system that stores and processes massive amounts of data, including sensitive information. And this leads to the emergence of new basic needs. To draw an analogy with two levels of Maslow’s hierarchy of needs, a modern vehicle must:

• Satisfy the need for “esteem” — meaning it must securely and reliably store user profile data, such as account credentials, biometric data, payment details, and more.
• Satisfy the user’s cognitive needs — meaning it must provide secure internet connectivity, transmit vehicle telemetry, and send reminders for scheduled or emergency maintenance.

All of this means equipping vehicles with a wide array of interfaces — telematics, Bluetooth, Wi-Fi, cellular connectivity, OTA updates, and V2X — which opens the door to remote attacks. Therefore, it becomes necessary to ensure not only the functional security, but also the information security of the vehicle. As a result, specialized industry standards that help address automotive cybersecurity challenges have emerged in most countries. The key international standards are ISO/SAE 21434 “Road vehicles — Cybersecurity engineering”, UNECE R155, and UNECE R156.

China’s regulations are evolving too. In 2024, the country published the national standard GB 44495-2024 “Technical Requirements for Vehicle Cybersecurity”, which went into effect on January 1, 2026. The document introduces mandatory cybersecurity requirements for vehicles, including communications protection, security event management, threat monitoring, and secure vehicle interaction with external infrastructure.

Understanding and applying these standards is becoming absolutely critical. Research shows that cybersecurity risks are escalating daily, and their impact on functional safety can sometimes trigger far more dangerous incidents than an internal system failure. What happens if an attacker gains access to a self-driving truck’s remote-control system, or manages to reflash a critical electronic control unit during an unauthorized diagnostic session?

One of the key components for mitigating these scenarios is a security gateway, which isolates the vehicle’s architecture into different domains based on criticality, while providing secure routing, filtering, and traffic control. Developing this type of software solution is precisely what our team focuses on as we build the Kaspersky Automotive Secure Gateway based on KasperskyOS.

Why Kaspersky Automotive Secure Gateway?

The primary purpose of Kaspersky Automotive Secure Gateway (KASG) is to secure the vehicle’s CAN domain, since the CAN bus is used to transmit a vast number of critical control commands. This impacts nearly 80% of the electronic control units inside the car, which handle engine management, braking, body electronics, and more. Because of this, we utilize the Safety-Aware Cybersecurity approach — a unified architecture that accounts for both functional safety and cybersecurity requirements.

For example, standard End-to-End Protection (E2E) mechanisms are typically used to mitigate risks associated with dropped, out-of-order, or corrupted CAN messages. However, these mechanisms were not originally designed to counter targeted cyberattacks. If an attacker manages to construct a malicious frame that conforms to the required E2E format, the system may accept it as valid.

This introduces a new factor: it’s critical not only to verify that a message was delivered without errors, but also to ensure that it was actually generated by a trusted electronic control unit (ECU), and was not altered in transit. This is particularly vital for transmitting control commands — such as those sent to the vehicle’s braking system — or for implementing keyless entry (NFC) systems.

To address that challenge, Secure Onboard Communication (SecOC) mechanisms are integrated into the vehicle’s architecture. They use cryptographic methods to verify message authenticity and integrity, protecting the system against message spoofing and replay attacks. KASG successfully implements these mechanisms, which, in addition to message verification, perform the crucial function of centralized key management. This allows encryption keys to be distributed and updated from a single point within the vehicle, reducing both the cost and the processing load on the ECUs involved in SecOC-backed data exchange.

Automotive IDS

However, in complex systems, it’s no longer enough to apply security mechanisms only to individual messages or separate network segments. It’s essential to provide vehicle-wide monitoring and control, tracking behavioral anomalies, unusual cross-domain interactions, and unauthorized tampering attempts. In the IT domain, this is known as an Intrusion Detection System (IDS). These systems have been successfully adopted by the automotive industry as well.

At the same time, it’s important to realize that for a modern vehicle, an IDS is not a single magic point of data collection and analysis; the vehicle requires a distributed monitoring system. Monitoring is carried out at various architectural levels: within domains, at the individual controller level, and at network boundaries.

The security gateway becomes a critical monitoring point because all cross-domain interaction passes through. Additionally, the gateway provides visibility into data exchange across different segments of the vehicle network. Its job is to detect deviations from normal behavior and generate security events.

When it comes to the CAN domain monitoring implemented in KASG, the IDS looks at the following criteria for traffic analysis:

• Alignment of CAN message parameters (CAN ID, DLC) with their descriptions in the DBC specification.
• Frequency and periodicity of CAN messages.
• Allowable ranges for CAN signals.

In practice, however, an important limitation becomes clear: even with an onboard IDS, more context is required to determine the exact characteristics of an attack. Furthermore, when operating highly automated vehicles — where fleet-wide monitoring is essential — such isolated analysis becomes inherently insufficient.

Connecting a vehicle to an SIEM

Multi-object monitoring, data correlation, and data analysis can be efficiently handled externally — specifically in SIEM (Security Information and Event Management) systems, which are traditionally used in corporate and industrial cybersecurity operations centers. Therefore, utilizing a SIEM system fleet-wide is a logical step that makes it possible to:

• Collect security events from multiple vehicles.
• Correlate events over time and across contexts.
• Detect advanced and distributed attacks.
• Provide incident auditing and investigation.
• Respond to individual incidents and manage cyber-risks fleet-wide.

When integrating with external SIEM systems, several critical tasks must be addressed: ensuring a secure connection, tuning the security event transmission process, and establishing baseline rules for event processing and correlation. We are actively working through all of these challenges using our own SIEM system — Kaspersky Unified Monitoring and Analysis Platform — as a blueprint.

There are still many issues ahead that need to be resolved. This article covered only a fraction of the approaches currently used in KASG to ensure vehicle safety and security. Yet even this small part demonstrates that automotive security cannot be achieved by solving a single problem or applying a single mechanism. Achieving it requires an approach that enables methodical architecture development — balancing diverse requirements for vehicle functionality, security, and reliability.

On the surface, the Superbox media streaming devices for sale at retailers like BestBuy and Walmart may seem like a steal: They offer unlimited access to more than 2,200 pay-per-view and streaming services like Netflix, ESPN and Hulu, all for a one-time fee of around $400. But security experts warn these TV boxes require intrusive software that forces the user’s network to relay Internet traffic for others, traffic that is often tied to cybercrime activity such as advertising fraud and account takeovers.

Superbox bills itself as an affordable way for households to stream all of the television and movie content they could possibly want, without the hassle of monthly subscription fees — for a one-time payment of nearly $400.

“Tired of confusing cable bills and hidden fees?,” Superbox’s website asks in a recent blog post titled, “Cheap Cable TV for Low Income: Watch TV, No Monthly Bills.”

“Real cheap cable TV for low income solutions does exist,” the blog continues. “This guide breaks down the best alternatives to stop overpaying, from free over-the-air options to one-time purchase devices that eliminate monthly bills.”

Superbox claims that watching a stream of movies, TV shows, and sporting events won’t violate U.S. copyright law.

“SuperBox is just like any other Android TV box on the market, we can not control what software customers will use,” the company’s website maintains. “And you won’t encounter a law issue unless uploading, downloading, or broadcasting content to a large group.”

There is nothing illegal about the sale or use of the Superbox itself, which can be used strictly as a way to stream content at providers where users already have a paid subscription. But that is not why people are shelling out $400 for these machines. The only way to watch those 2,200+ channels for free with a Superbox is to install several apps made for the device that enable them to stream this content.

Superbox’s homepage includes a prominent message stating the company does “not sell access to or preinstall any apps that bypass paywalls or provide access to unauthorized content.” The company explains that they merely provide the hardware, while customers choose which apps to install.

“We only sell the hardware device,” the notice states. “Customers must use official apps and licensed services; unauthorized use may violate copyright law.”

Superbox is technically correct here, except for maybe the part about how customers must use official apps and licensed services: Before the Superbox can stream those thousands of channels, users must configure the device to update itself, and the first step involves ripping out Google’s official Play store and replacing it with something called the “App Store” or “Blue TV Store.”

Superbox does this because the device does not use the official Google-certified Android TV system, and its apps will not load otherwise. Only after the Google Play store has been supplanted by this unofficial App Store do the various movie and video streaming apps that are built specifically for the Superbox appear available for download (again, outside of Google’s app ecosystem).

Experts say while these Android streaming boxes generally do what they advertise — enabling buyers to stream video content that would normally require a paid subscription — the apps that enable the streaming also ensnare the user’s Internet connection in a distributed residential proxy network that uses the devices to relay traffic from others.

Ashley is a senior solutions engineer at Censys, a cyber intelligence company that indexes Internet-connected devices, services and hosts. Ashley requested that only her first name be used in this story.

In a recent video interview, Ashley showed off several Superbox models that Censys was studying in the malware lab — including one purchased off the shelf at BestBuy.

“I’m sure a lot of people are thinking, ‘Hey, how bad could it be if it’s for sale at the big box stores?'” she said. “But the more I looked, things got weirder and weirder.”

Ashley said she found the Superbox devices immediately contacted a server at the Chinese instant messaging service Tencent QQ, as well as a residential proxy service called Grass IO.

GET GRASSED

Also known as getgrass[.]io, Grass says it is “a decentralized network that allows users to earn rewards by sharing their unused Internet bandwidth with AI labs and other companies.”

“Buyers seek unused internet bandwidth to access a more diverse range of IP addresses, which enables them to see certain websites from a retail perspective,” the Grass website explains. “By utilizing your unused internet bandwidth, they can conduct market research, or perform tasks like web scraping to train AI.” 

Reached via Twitter/X, Grass founder Andrej Radonjic told KrebsOnSecurity he’d never heard of a Superbox, and that Grass has no affiliation with the device maker.

“It looks like these boxes are distributing an unethical proxy network which people are using to try to take advantage of Grass,” Radonjic said. “The point of grass is to be an opt-in network. You download the grass app to monetize your unused bandwidth. There are tons of sketchy SDKs out there that hijack people’s bandwidth to help webscraping companies.”

Radonjic said Grass has implemented “a robust system to identify network abusers,” and that if it discovers anyone trying to misuse or circumvent its terms of service, the company takes steps to stop it and prevent those users from earning points or rewards.

Superbox’s parent company, Super Media Technology Company Ltd., lists its street address as a UPS store in Fountain Valley, Calif. The company did not respond to multiple inquiries.

According to this teardown by behindmlm.com, a blog that covers multi-level marketing (MLM) schemes, Grass’s compensation plan is built around “grass points,” which are earned through the use of the Grass app and through app usage by recruited affiliates. Affiliates can earn 5,000 grass points for clocking 100 hours usage of Grass’s app, but they must progress through ten affiliate tiers or ranks before they can redeem their grass points (presumably for some type of cryptocurrency). The 10th or “Titan” tier requires affiliates to accumulate a whopping 50 million grass points, or recruit at least 221 more affiliates.

Radonjic said Grass’s system has changed in recent months, and confirmed the company has a referral program where users can earn Grass Uptime Points by contributing their own bandwidth and/or by inviting other users to participate.

“Users are not required to participate in the referral program to earn Grass Uptime Points or to receive Grass Tokens,” Radonjic said. “Grass is in the process of phasing out the referral program and has introduced an updated Grass Points model.”

A review of the Terms and Conditions page for getgrass[.]io at the Wayback Machine shows Grass’s parent company has changed names at least five times in the course of its two-year existence. Searching the Wayback Machine on getgrass[.]io shows that in June 2023 Grass was owned by a company called Wynd Network. By March 2024, the owner was listed as Lower Tribeca Corp. in the Bahamas. By August 2024, Grass was controlled by a Half Space Labs Limited, and in November 2024 the company was owned by Grass OpCo (BVI) Ltd. Currently, the Grass website says its parent is just Grass OpCo Ltd (no BVI in the name).

Radonjic acknowledged that Grass has undergone “a handful of corporate clean-ups over the last couple of years,” but described them as administrative changes that had no operational impact. “These reflect normal early-stage restructuring as the project moved from initial development…into the current structure under the Grass Foundation,” he said.

UNBOXING

Censys’s Ashley said the phone home to China’s Tencent QQ instant messaging service was the first red flag with the Superbox devices she examined. She also discovered the streaming boxes included powerful network analysis and remote access tools, such as Tcpdump and Netcat.

“This thing DNS hijacked my router, did ARP poisoning to the point where things fall off the network so they can assume that IP, and attempted to bypass controls,” she said. “I have root on all of them now, and they actually have a folder called ‘secondstage.’ These devices also have Netcat and Tcpdump on them, and yet they are supposed to be streaming devices.”

A quick online search shows various Superbox models and many similar Android streaming devices for sale at a wide range of top retail destinations, including Amazon, BestBuy, Newegg, and Walmart. Newegg.com, for example, currently lists more than three dozen Superbox models. In all cases, the products are sold by third-party merchants on these platforms, but in many instances the fulfillment comes from the e-commerce platform itself.

“Newegg is pretty bad now with these devices,” Ashley said. “Ebay is the funniest, because they have Superbox in Spanish — the SuperCaja — which is very popular.”

Ashley said Amazon recently cracked down on Android streaming devices branded as Superbox, but that those listings can still be found under the more generic title “modem and router combo” (which may be slightly closer to the truth about the device’s behavior).

Superbox doesn’t advertise its products in the conventional sense. Rather, it seems to rely on lesser-known influencers on places like Youtube and TikTok to promote the devices. Meanwhile, Ashley said, Superbox pays those influencers 50 percent of the value of each device they sell.

“It’s weird to me because influencer marketing usually caps compensation at 15 percent, and it means they don’t care about the money,” she said. “This is about building their network.”

BADBOX

As plentiful as the Superbox is on e-commerce sites, it is just one brand in an ocean of no-name Android-based TV boxes available to consumers. While these devices generally do provide buyers with “free” streaming content, they also tend to include factory-installed malware or require the installation of third-party apps that engage the user’s Internet address in advertising fraud.

In July 2025, Google filed a “John Doe” lawsuit (PDF) against 25 unidentified defendants dubbed the “BadBox 2.0 Enterprise,” which Google described as a botnet of over ten million Android streaming devices that engaged in advertising fraud. Google said the BADBOX 2.0 botnet, in addition to compromising multiple types of devices prior to purchase, can also infect devices by requiring the download of malicious apps from unofficial marketplaces.

Several of the Android streaming devices flagged in Google’s lawsuit are still for sale on top U.S. retail sites. For example, searching for the “X88Pro 10” and the “T95” Android streaming boxes finds both continue to be peddled by Amazon sellers.

Google’s lawsuit came on the heels of a June 2025 advisory from the Federal Bureau of Investigation (FBI), which warned that cyber criminals were gaining unauthorized access to home networks by either configuring the products with malicious software prior to the user’s purchase, or infecting the device as it downloads required applications that contain backdoors, usually during the set-up process.

“Once these compromised IoT devices are connected to home networks, the infected devices are susceptible to becoming part of the BADBOX 2.0 botnet and residential proxy services known to be used for malicious activity,” the FBI said.

The FBI said BADBOX 2.0 was discovered after the original BADBOX campaign was disrupted in 2024. The original BADBOX was identified in 2023, and primarily consisted of Android operating system devices that were compromised with backdoor malware prior to purchase.

Riley Kilmer is founder of Spur, a company that tracks residential proxy networks. Kilmer said Badbox 2.0 was used as a distribution platform for IPidea, a China-based entity that is now the world’s largest residential proxy network.

Kilmer and others say IPidea is merely a rebrand of 911S5 Proxy, a China-based proxy provider sanctioned last year by the U.S. Department of the Treasury for operating a botnet that helped criminals steal billions of dollars from financial institutions, credit card issuers, and federal lending programs (the U.S. Department of Justice also arrested the alleged owner of 911S5).

How are most IPidea customers using the proxy service? According to the proxy detection service Synthient, six of the top ten destinations for IPidea proxies involved traffic that has been linked to either ad fraud or credential stuffing (account takeover attempts).

Kilmer said companies like Grass are probably being truthful when they say that some of their customers are companies performing web scraping to train artificial intelligence efforts, because a great deal of content scraping which ultimately benefits AI companies is now leveraging these proxy networks to further obfuscate their aggressive data-slurping activity. By routing this unwelcome traffic through residential IP addresses, Kilmer said, content scraping firms can make it far trickier to filter out.

“Web crawling and scraping has always been a thing, but AI made it like a commodity, data that had to be collected,” Kilmer told KrebsOnSecurity. “Everybody wanted to monetize their own data pots, and how they monetize that is different across the board.”

SOME FRIENDLY ADVICE

Products like Superbox are drawing increased interest from consumers as more popular network television shows and sportscasts migrate to subscription streaming services, and as people begin to realize they’re spending as much or more on streaming services than they previously paid for cable or satellite TV.

These streaming devices from no-name technology vendors are another example of the maxim, “If something is free, you are the product,” meaning the company is making money by selling access to and/or information about its users and their data.

Superbox owners might counter, “Free? I paid $400 for that device!” But remember: Just because you paid a lot for something doesn’t mean you are done paying for it, or that somehow you are the only one who might be worse off from the transaction.

It may be that many Superbox customers don’t care if someone uses their Internet connection to tunnel traffic for ad fraud and account takeovers; for them, it beats paying for multiple streaming services each month. My guess, however, is that quite a few people who buy (or are gifted) these products have little understanding of the bargain they’re making when they plug them into an Internet router.

Superbox performs some serious linguistic gymnastics to claim its products don’t violate copyright laws, and that its customers alone are responsible for understanding and observing any local laws on the matter. However, buyer beware: If you’re a resident of the United States, you should know that using these devices for unauthorized streaming violates the Digital Millennium Copyright Act (DMCA), and can incur legal action, fines, and potential warnings and/or suspension of service by your Internet service provider.

According to the FBI, there are several signs to look for that may indicate a streaming device you own is malicious, including:

-The presence of suspicious marketplaces where apps are downloaded.
-Requiring Google Play Protect settings to be disabled.
-Generic TV streaming devices advertised as unlocked or capable of accessing free content.
-IoT devices advertised from unrecognizable brands.
-Android devices that are not Play Protect certified.
-Unexplained or suspicious Internet traffic.

This explainer from the Electronic Frontier Foundation delves a bit deeper into each of the potential symptoms listed above.