Talk to any threat hunter long enough, and beneath the polished case studies and conference talks, the same frustrations surface. Hunting is supposed to be proactive. In practice, it often feels reactive. You are chasing whispers of activity through log noise, querying SIEM fields that barely reflect real attacker behavior and writing detections against technique descriptions that were never meant to be operationalized directly. 

The challenge is not that analysts lack skill. Most hunting teams are sharp, methodical, and deeply familiar with attacker playbooks. The real friction is structural: the intelligence feeding hunts is often stale, decontextualized, or missing the behavioral granularity needed to write anything more than a broad, noisy detection. 

The core tension 

Threat hunting is a high-skill, time-intensive activity that justifies itself by finding what automated systems miss. But when the intelligence inputs are low-fidelity, even the most skilled hunters spend the majority of their time generating work rather than reducing risk. 

MITRE ATT&CK tells you a technique exists. It does not tell you how it behaves in a real attack chain against a real target. That gap between abstract TTP and concrete execution behavior is where many hunts quietly die. IOCs arrive stripped of context: you block an IP, a rotated domain from the same campaign lands in your environment three days later, and sails straight through.  

And then there is the false-positive problem. Not a technical inconvenience but a morale and process killer. Every alert that turns out to be Outlook talking to a Microsoft licensing server erodes confidence in the detection pipeline. Over-tuned rules miss real threats; under-tuned rules train analysts to discount the queue. 

In this article, we’ll explore how threat intelligence supports core hunting workflows and how ANY.RUN’s Threat Intelligence solutions help analysts investigate threats with greater speed and confidence. 

Key Takeaways

• Threat hunting fails structurally, not skillfully. The bottleneck is intelligence quality.
• Behavioral context beats indicators. A single IOC blocked solves nothing if the campaign behind it isn’t understood. Pivoting from one artifact — a mutex, a file path, a Suricata tag — into a full attack chain is what separates hunting from blocklisting.
• Hypothesis validation requires real attack data. ATT&CK describes techniques in the abstract. Effective hunting needs to know how a technique behaves in live, active campaigns — which tools operationalize it, what infrastructure it touches, what artifacts it leaves.
• False positives are a strategy problem, not just a noise problem. Every low-fidelity alert that consumes analyst attention is a detection that wasn’t built right. Validating rules against real samples before deployment is the difference between a detection pipeline and a distraction pipeline.
• Intelligence layers serve different operational needs. TI Lookup drives active investigations; TI Feeds keep automated defenses current; TI Reports bridge the gap between raw campaign data and detection engineering or executive briefings.
• AI-assisted triage is a force multiplier, not a replacement. Tier 1 reports, AI summaries, and sandbox recommendations don’t replace analyst judgment — they eliminate the translation work between analysis output and operational action, freeing analysts for work that actually requires them.
• Hunting ROI is measurable — if you instrument it correctly. Earlier detection, defense calibrated to active threats, and analyst time redirected to genuine risk: each is quantifiable. Programs that cannot demonstrate these outcomes don’t lack value — they lack the intelligence infrastructure to produce it consistently.

1. Hypothesis Validation: Device Code Phishing

Scenario: A hunter develops a hypothesis: adversaries may be abusing Microsoft’s Device Code authentication flow to compromise organizational accounts without triggering MFA. The technique is real, but the team needs evidence it is active now and a way to identify the behavioral signatures that distinguish attacks from legitimate device authorization. 
 
The struggle: Generic queries against authentication logs produce enormous volume. Without knowing what a malicious device code flow actually looks like in practice — which referrer domains initiate the redirect, which PhaaS kits are operationalizing the technique, what the email delivery chain looks like — the team is essentially querying blind. 

The solution: TI Lookup allows the hunter to query the Microsoft device auth endpoint directly and immediately retrieve sandboxed sessions where the technique is observed in the wild. 
 
url:”https://login.microsoftonline.com/common/oauth2/deviceauth?code=*” 

Sessions are tagged automatically: Phishing, oauth-ms-phish, and kit-specific tags like Kali365 (a PhaaS platform specializing in Device Code Phishing). 

We can view any of the analyses sessions, for example: https://app.any.run/tasks/fc973b26-7cc8-4253-a313-1b77ff27f04c/  

The hunter can inspect the full referrer chain: 

In live cases, the redirect to Microsoft’s legitimate device auth endpoint originates from external domains, including those with unusual TLDs. 

Subsequent queries can filter by TLD against the device code URL, giving the team a concrete list of suspicious referring domains to feed into SIEM monitoring or block lists. 

url:”https://login.microsoftonline.com/common/oauth2/deviceauth” and domainName:”.de$” 

For more targeted investigation, the hunter can also query by threat name and file path to retrieve the actual phishing emails (.eml files) used to deliver the initial lure, exposing sender patterns, subject line templates, and infrastructure metadata. 

Impact: 

• Hypothesis validated against real, live attack data rather than technique abstractions. 
• Concrete IOCs and behavioral signatures ready for SIEM query development. 
• Email metadata exposed for deeper organizational log correlation. 

2. Behavioral Pivots: Tracking a Stealer Family via Mutex 

Scenario: A suspicious executable is submitted for analysis and identified as a stealer. The analyst notices a mutex with a hardcoded prefix — GlobalEVOLUTION — followed by a randomized suffix. The question is whether this prefix is unique to this malware family and, if so, how widely deployed it is. 
 
The struggle: A mutex with a random suffix has no stable IOC value. Standard threat feeds will not carry it. Searching for the full string is guaranteed to miss variants. The behavioral pattern is clearly significant but there is no obvious path from a single sample to campaign-level coverage. 

The solution: A wildcard query in TI Lookup (syncObjectName:”Global\EVOLUTION*”) immediately surfaces a number of additional samples sharing the same hardcoded prefix with different randomized tails, confirming the pattern is not incidental but a structural artifact of this malware family. 

Cross-referencing the mutex results against file path artifacts reveals that affected systems consistently produce a dump archive at C:UsersadminAppDataLocalTempevo_[random]stolen.zip — a second independent behavioral indicator that definitely looks like a stealer.  

Running OR and AND lookup combinations of both indicators allows the hunter to tune coverage: OR for maximum reach, AND for high-confidence, low-noise detections:

• filePath:”C:UsersadminAppDataLocalTempevo_stolen.zip” OR syncObjectName:”GlobalEVOLUTION”
• filePath:”C:\Users\admin\AppData\Local\Temp\evo_*\stolen.zip” AND syncObjectName:”Global\EVOLUTION*” 

Starting from a single mutex observation, the hunter has now built a multi-indicator behavioral profile of an entire malware family. 

Impact:  

• Single behavioral artifact expands into full campaign coverage. 
• Multi-indicator detection logic developed and validated before touching production systems. 
• No reliance on stable IOCs — detection survives malware updates. 

3. Enrichment: Suspicious Domain in an Inbound Email 

Scenario: An email from an unknown sender arrives containing a link to an unfamiliar domain. Standard policy would flag this for review. The analyst needs to determine quickly whether the domain is genuinely malicious or simply unknown, and if malicious, what the full attack chain looks like. 

The struggle: WHOIS data shows the domain is recently registered. Passive DNS shows limited history. Reputation feeds return no verdict. The analyst has a suspicious domain but no behavioral context — no sense of what the domain delivers, what it steals, or what infrastructure it connects to. 

The solution: The domain search in TI Lookup returns sandbox sessions where the domain has been analyzed. 

domainName:”miracleplayssystems.com” 

The hunter opens one and immediately sees a Microsoft 365 login page clone hosted on the suspicious domain, automatically tagged by ANY.RUN.  

Suricata network threat detections reveal the specific phishing kit — FlowerStorm.

The rule details expose the exfiltration endpoint:  

HTTP tab features a separate domain to which stolen credentials are posted:  

The HTTP traffic view makes the data flow explicit: M365 credentials submitted to the fake login page are forwarded to infrastructure the attacker controls, not to any Microsoft domain.  

This gives the analyst not just a verdict but a full attack chain — delivery domain, phishing kit identity, exfiltration endpoint — all from a single lookup. 

Impact:  

• Unknown domain enriched with full attack chain in minutes. 
• Exfiltration infrastructure identified and added to block lists proactively. 
• Phishing kit attribution enables broader campaign hunting. 

4. Expansion: LOLBin Abuse and Campaign Attribution 

Scenario: An alert fires: MSBuild.exe — a standard Microsoft .NET build component — is establishing a network connection to an unknown IP on a non-standard port. This is a textbook living-off-the-land technique, but the specific context (which campaign, which malware family, how widespread) is unknown. 
 
The struggle: MSBuild.exe connecting outbound is not inherently malicious; it is used legitimately in CI/CD pipelines. The challenge is distinguishing targeted abuse from normal build activity and understanding whether the destination IP is part of a broader campaign or an isolated incident. 

The solution: Combining the destination IP with the MSBuild.exe command-line pattern in a TI Lookup query surfaces sessions where the same combination has been observed. 

destinationIP:”212.34.141.103″ and commandLine:”C:\Windows\Microsoft.NET\Framework64\v*\MSBuild.exe” 

Opening a representative session shows MSBuild.exe establishing a C2 connection and exfiltrating host reconnaissance data — CPU, OS version, running processes:  

The Processes tab in the sandbox shows what user data gets exfiltrated:

A vendor-specific detection tag (rmrlx) links this activity to a named malware family: 

threatName:”rmrlx” 

Pivoting on that tag reveals associated infrastructure across multiple IP addresses and exposes the threat actor group responsible — Colombian Smugglers — which uses SVG smuggling as a delivery mechanism and has evolved from targeting Colombian organizations to targeting US and European companies. The hunter can now see the full threat actor profile: initial delivery technique (SVG smuggling), malware families used (vjw0rm, quasar, remcos, xworm, rmrlx), geographic targeting, and infrastructure overlap with adjacent groups like BlindEagle. 

threatName:”colombian-smugglers” 

Use this TI Lookup request to find sandbox analyses exposing SVG smuggling technique:  

threatName:”colombian-smugglers” and filePath:”.svg$” 

Impact: 

• Single alert pivots into full threat actor profile and campaign map. 
• Infrastructure correlation surfaces additional C2 endpoints for blocking. 
• Geographic and targeting intelligence enables prioritized defensive response. 

5. False Positive Validation: Hunting Rule Noise Reduction 

Scenario: ANY.RUN’s hunting rules include a signature that fires when a Windows PC hostname is observed being transmitted in network traffic — a behavior common to stealers and RATs that use hostname as a victim identifier.  

suricataMessage:”HUNTING [ANY.RUN] Windows PC hostname observed” 

The rule catches real threats, but the analyst needs to verify that every hit is genuinely malicious before adding it to production detection. 

The struggle: Hunting rules cast wide nets by design. A rule targeting hostname exfiltration will fire on legitimate software that also transmits device identifiers. Without behavioral context, distinguishing malicious exfiltration from legitimate telemetry requires manual investigation of every hit. 

The solution: Let’s view one of the found sandbox analyses: https://app.any.run/tasks/56e01444-87a2-4cf4-874a-41e56ce60221/ 

The analyst sees the Suricata alert firing on Outlook.exe, but the destination is licensing.m365.svc.cloud.microsoft, a legitimate Microsoft licensing endpoint.  

The HTTP details confirm the behavior: Outlook is sending device and license metadata as part of a standard Office perpetual license renewal (renewperpetuallicense), and the server responds with a 200 OK confirming the HomeBusiness2021Retail license status. This is unambiguously legitimate. The analyst documents this as a known false-positive pattern and adds an exclusion for Microsoft licensing endpoints — keeping the rule sharp without discarding it. 

Impact:  

• False positive identified and documented before reaching production. 
• Detection logic refined without reducing coverage of genuine threats. 
• Analyst time focused on confirmed malicious activity. 

6. Detection Engineering: YARA Rule Development and Validation 

Scenario: During stealer sample collection, an analyst encounters a .NET executable that drops a zip archive named with a consistent pattern: Unix-[HOSTNAME]-[ID].zip. The behavioral artifact is interesting but the analyst wants to build a durable, validated detection rule, not just add a file path indicator that will break when the malware author changes the naming convention. 

The struggle: Writing YARA rules against behavioral artifacts requires understanding what strings are genuinely hardcoded into the binary versus what is generated at runtime. Testing rules against a small sample set risks both false positives from broad string matches and false negatives from a sample set too small to represent the full malware family. 

The solution: Static analysis of the .NET binary in Detect It Easy reveals human-readable strings embedded in the assembly — a common characteristic of .NET malware.  

Filtering for strings containing “Unix” surfaces several hardcoded identifiers specific for this malware:  

• Unix Stealer Log 
• UnixStealer 
• UnixStealerIV!@# 
• UnixStealer2024Key! 

A YARA rule built around these strings uses wide matching for Unicode-encoded strings and fullword to minimize false positives.  

rule UnixStealer { 

    meta: 

        description = "Detects UnixStealer malware" 

        date = "2025-12-18" 

        author = "ANY.RUN:A.Adhikara" 

    strings: 

        $x1 = "Unix Stealer Log" fullword wide 

        $x2 = "UnixStealer" fullword 

        $x3 = "UnixStealerIV!@#" fullword wide 

        $x4 = "UnixStealer2024Key" fullword wide 

    condition: 

        uint16(0) == 0x5A4D and any of ($x*) 

}

Running the rule through TI Lookup’s YARA Search validates it against millions of real malware samples — returning 17 matching samples with no unrelated hits.  

Noticing that the year is hardcoded in one string, the analyst refines it to a regex pattern (/UnixStealer20d{2}Key/ wide) to ensure the rule covers future builds where the author updates the year.  

Re-validation against the corpus confirms the refined rule catches the same 17 samples and introduces no new noise. 

Impact:  

• YARA rule validated against millions of real samples before deployment. 
• Rule designed to survive malware version updates through regex generalization. 
• Detection shipped with high confidence — no post-deployment tuning required. 

How Threat Intelligence Feeds Support Threat Hunting 

WhileTI  Lookup excels at interactive investigations, Threat Intelligence Feeds help operationalize hunting at scale. 

Threat Intelligence Feeds can be integrated directly into SIEM, EDR, XDR, SOAR, firewalls, and other security platforms, providing continuously updated indicators and threat context. 

For threat hunters, this supports several key workflows: 

• Prioritizing investigations involving known malicious infrastructure. 
• Correlating internal telemetry with active attacker infrastructure. 
• Identifying emerging campaigns before internal detections trigger. 
• Automating enrichment during hunts. 
• Reducing manual IOC collection and maintenance. 

By continuously injecting fresh intelligence into security tooling, feeds allow hunting teams to focus on analysis rather than data gathering. 

Accelerating Hunts with Sandbox Intelligence 

ANY.RUN’s Interactive Sandbox provides additional capabilities that reduce investigation time and improve analyst productivity. 

Tier 1 Reports 

Tier 1 Reports automatically summarize malware behavior in analyst-friendly language, making it easier for junior and mid-level analysts to understand threats without spending significant time reviewing every artifact manually. 

This helps SOC teams rapidly assess suspicious files and decide whether deeper hunting activities are necessary. 

AI Summary 

AI Summary condenses complex malware executions into concise narratives, highlighting the most important findings, suspicious behaviors, and attack stages. Hunters can quickly understand what happened during execution before diving into technical details. 

AI Recommendations 

AI Recommendations suggest potential next steps for investigation, including relevant artifacts, indicators, and behaviors worth examining further. This helps analysts identify additional hunting opportunities and reduces the likelihood of missing important evidence. 

Why Threat Hunting Matters to the Business 

Threat hunting is often discussed as a purely technical discipline, but its ultimate purpose is business protection. Organizations invest in hunting because reactive security alone is no longer sufficient. Modern attackers frequently evade automated detections, abuse legitimate tools, and remain hidden for extended periods. 

However, threat hunting itself introduces operational challenges: 

• Significant analyst time requirements. 
• Skill shortages. 
• Investigation fatigue. 
• High volumes of telemetry. 
• Difficulty prioritizing hunting activities. 
• Challenges demonstrating measurable business value. 

Without proper intelligence support, threat hunting can become expensive and inefficient. Threat intelligence helps address these challenges by reducing investigation time, improving prioritization, increasing analyst productivity, and enabling teams to focus on the threats that matter most to the business. 

The result is faster threat discovery, reduced dwell time, lower incident response costs, and improved resilience against advanced attacks. 

For MSSPs, intelligence-driven hunting also enables more scalable operations, allowing analysts to investigate more environments without proportionally increasing staffing requirements. 

Conclusion 

Threat hunting is no longer about manually searching through massive volumes of logs and hoping to uncover something suspicious. 

Successful hunting depends on context. 

Threat intelligence provides that context by connecting indicators, behaviors, infrastructure, malware families, campaigns, and threat actors into a coherent picture. It transforms hunting from a reactive research exercise into a focused, intelligence-driven process. 

With Threat Intelligence Lookup, Threat Intelligence Feeds, Threat Intelligence Reports, YARA Search, and AI-assisted analysis capabilities, SOC teams can validate hypotheses, enrich investigations, expand discoveries, improve detections, and reduce time spent on manual research. 

The result is a threat hunting program that is faster, more scalable, and more closely aligned with both security and business objectives. 

About ANY.RUN 

ANY.RUN, a leading provider of interactive malware analysis and threat intelligence solutions, helps SOC teams, MSSPs, and enterprises investigate threats faster and make more confident security decisions. 

With its cloud-based Interactive Sandbox, security teams can safely analyze suspicious files, links, and emails in real time, observe malicious behavior, and receive clear evidence for response without maintaining complex in-house infrastructure. 

ANY.RUN’s Threat Intelligence solutions also help organizations uncover threat context, enrich security workflows, and improve visibility into emerging risks. Together, these capabilities support faster triage, stronger incident prevention, and more efficient security operations at scale. 

ANY.RUN is SOC 2 Type II attested and committed to strong security control and customer data protection.

Scale your SOC with faster threat validation →

FAQ

The post Intelligence-Driven Threat Hunting: How SOCs Find What Alerts Miss appeared first on ANY.RUN’s Cybersecurity Blog.

ANY.RUN’s Cybersecurity Blog – ​Read More

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.

Kaspersky official blog – ​Read More