“The injected code runs two operations against a site’s visitors: a mobile ad-fraud and gambling-redirect

Two critical vulnerabilities affecting Langflow and Ruby on Rails deployments are being actively exploited, with attackers quickly moving from public disclosure to reconnaissance, secret harvesting, and potential remote code execution, according to VulnCheck telemetry.

The first issue, tracked as CVE-2026-0768, affects Langflow, a low-code platform for building AI-powered applications, agents, and workflow automations.

VulnCheck observed exploitation attempts against its internet-facing Canary systems shortly after the vulnerability was added to its Known Exploited Vulnerabilities catalog.

CVE-2026-0768 is an unauthenticated remote code execution flaw in the code validator used by Langflow’s custom component editor. An attacker may be able to execute code on a vulnerable server without first authenticating.

The flaw was disclosed through Trend Micro’s Zero Day Initiative in January, and VulnCheck said no public proof-of-concept exploit was known at the time of the observed attacks.

The company initially recorded more than 50 detections, but the volume later increased to around 360 exploitation events. The malicious requests appeared to be designed to identify valuable credentials and access paths rather than immediately deploy ransomware or other destructive payloads.

Langflow RCE and Rails Vulnerability Exploited

Observed commands attempted to retrieve environment variables associated with Langflow administration, OpenAI APIs, and AWS cloud access.

Attackers also tried to read Langflow’s local secret key file at /root/.cache/langflow/secret_key, inspect SSH access, and determine the size of .bash_history files. These checks could help an intruder identify administrator activity, stolen credentials, cloud resources, and possible routes for lateral movement.

VulnCheck said the Langflow traffic primarily originated from Russia and, at the time of reporting, targeted Canary systems located in the United Kingdom.

The activity adds to a growing pattern of exploitation targeting Langflow. Several other Langflow vulnerabilities have reportedly been added to VulnCheck’s KEV catalog during 2026.

Separately, researchers observed exploitation of CVE-2026-66066, a critical Ruby on Rails vulnerability described as an Active Storage file-read-to-RCE issue.

The attacks hit Canary systems in Singapore, Israel, and the United Kingdom. VulnCheck linked the activity to a single source IP address in France. At the same time, command-and-control communication was established with a host in Israel.

The Rails flaw is particularly dangerous because an attacker may first use file-reading capabilities to obtain sensitive application secrets, including secret_key_base, API tokens, database credentials, and cloud-storage keys.

Those secrets can remain useful even after the vulnerable software is patched. A compromised Rails secret_key_base, for example, may allow session forgery or other abuse until it is rotated.

Organizations running Langflow or Ruby on Rails should immediately identify exposed instances, apply vendor fixes, restrict public access to administrative interfaces, and review server logs for unusual commands targeting environment variables, secret files, SSH directories, or shell-history files.

Security teams should also rotate credentials, API keys, cloud secrets, and application signing keys if exploitation is suspected.
The incidents highlight how AI application platforms and widely deployed web frameworks are becoming high-value targets.

For defenders, patching alone is not enough; any secrets accessible to a compromised application should be treated as potentially exposed and replaced.

Prevent incidents due to slow investigations. Power your Tier 1 with threat intelligence from 15K SOCs: Integrate TI Lookup in your SOC

The post Hackers Actively Exploiting Critical Langflow RCE and Rails Vulnerability appeared first on Cyber Security News.

Attackers are turning Microsoft Teams help desk calls into an entry point for malware and network compromise. A campaign tracked as Spring Ring used external accounts that resembled internal IT support to chat with employees, then call them and press for remote access or software execution.

The activity ran from January through April 2026 and approached more than 150 employees at at least 10 organizations.

Its danger lies in the human element: a familiar sounding technician and a live conversation can make an unexpected request feel urgent and legitimate.

Analysts at Unit 42 identified the operation after detecting suspicious chat creation across multiple Microsoft 365 tenants, uncovering 26 distinct attacker identities.

Palo Alto Networks said in a report shared with Cyber Security News (CSN) that the group did not exploit a flaw in Teams. Instead, it abused external communication features and the trust users place in workplace collaboration tools.

The campaign shows why Teams impersonation deserves the same scrutiny as email phishing. Attackers can adjust their story during a call, persuade a victim to run a remote support utility, and quickly move from a single workstation toward systems that control an entire network.

Hackers Weaponize Microsoft Teams Help Desk Calls

Spring Ring began with a one-to-one Teams chat from attacker-controlled .onmicrosoft.com tenants. The accounts carried authoritative display names such as help desk, IT assistance, or support staff, while some used names of real people to make the contact appear more credible.

After a chat request, the operator placed unsolicited voice calls, sometimes leaving voicemails and repeatedly trying different targets.

Successful conversations commonly lasted 10 to 15 minutes, giving the caller time to guide an employee through steps that would normally trigger suspicion in a written message.

In Campaign A, the fake technician persuaded victims to launch Quick Assist or download remote monitoring and management software.

Once remote control was granted, the intruder checked the host and domain, then used PowerShell to retrieve an obfuscated remote-access trojan from its infrastructure.

That method closely echoes a recent Microsoft Teams phishing campaign in which fake support staff pushed malware through the collaboration service.

It also reinforces a basic rule: employees should independently verify an unexpected support request using a known company contact, never the caller’s instructions.

From Remote Access to Domain Control

Campaign B used a tailored cloud-hosted executable whose name included the target company and employee.

The program copied itself into the Temp directory, created vhlp-.exe and scnr-.exe components for persistence, and launched a hidden Microsoft Edge process that loaded a sideloaded extension.

The attackers then used Python to scan internal systems over SMB and generate NTLM traffic toward the domain controller.

They attempted PetitPotam, a technique intended to force the controller to authenticate to an attacker-controlled machine, where that authentication could be relayed for domain-level access.

The attempted takeover was blocked, but the sequence illustrates how a help desk call can become a serious identity attack. Readers following Teams helpdesk impersonation scams will recognize the same reliance on external accounts and a convincing support pretext.

Organizations should limit external Teams chats to genuine business needs, flag a rapid chat-to-call shift, and investigate unusual remote-tool launches, cloud downloads, and SMB activity.

Security teams should also watch authentication events involving domain controllers, an issue explained in coverage of MITM6 and NTLM relay.

User education must be specific: IT staff should never ask workers to install unapproved tools or grant screen control after an unsolicited call.

Combining that policy with behavioral monitoring and review of Teams audit data can catch the chain early, as outlined in reporting on external collaboration feature abuse.

The trusted communication platforms are now being used as a route to domain-level exploitation. The immediate defense is simple: stop, verify the request out of band, and report the external account before any tool is opened.

That approach reduces the chance that an attacker can turn a routine Teams exchange into a costly enterprise-wide incident overnight.

Indicators of compromise (IoCs):-

Note: IP addresses and domains are intentionally defanged (e.g., [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.

Prevent incidents due to slow investigations. Power your Tier 1 with threat intelligence from 15K SOCs: Integrate TI Lookup in your SOC

The post Hackers Weaponize Microsoft Teams Help Desk Calls for Malware and Network Lateral Movement appeared first on Cyber Security News.

Boston Scientific is investigating a cybersecurity incident that disrupted parts of its global operations, affecting manufacturing, order processing, and product shipments.

The company said the incident was detected on August 25, 2026. It caused a network outage involving certain internal information technology systems and business applications.

The medical device manufacturer has engaged CrowdStrike and other third-party cybersecurity specialists to investigate, contain, and recover from the incident.

In its latest update issued August 30 at 8:25 p.m. ET, Boston Scientific said it had found no indication of unauthorized activity in its environment since August 25.

The company said the incident is limited to certain on-premises systems. Its cloud-based systems and applications have not been impacted, according to the ongoing investigation.

This distinction is significant because it indicates that the disruption is affecting localized enterprise infrastructure rather than the company’s broader cloud environment.

Boston Scientific said the affected systems include operational technology support functions and business applications required to manufacture products, process customer orders, and ship medical devices.

Boston Scientific Cyberattack

While customers can continue to submit orders electronically through electronic data interchange, or EDI, and local applications, those orders are being placed into a fulfillment queue until processing and shipping services are restored.

The company said it is working toward a partial restoration of shipping for some products during the week following the August 30 update. Full ordering and shipping capacity will resume after the company validates that the restored systems are fully operational.

The disruption has raised concerns for hospitals, clinicians, suppliers, and patients that depend on Boston Scientific products. However, the company said there is no known impact on devices that are not connected to a Boston Scientific network.

It also reported no known impact on clinicians’ ability to use disconnected devices and no evidence that the incident has increased cybersecurity risks to hospital networks through Boston Scientific medical devices.

Boston Scientific also provided an update on its Cardiac Rhythm Management device portfolio, including implantable cardiac devices such as pacemakers, implantable cardioverter defibrillators, cardiac resynchronization therapy devices, subcutaneous ICDs, and insertable cardiac monitors.

According to the company, existing remotely monitored CRM devices remain functional. Remote patient monitoring for devices enrolled before the outage is also operational, and programmer interrogations are unaffected.

Boston Scientific said there is no evidence that the incident has disrupted transfers of CRM monitoring data to electronic medical record systems.

However, new remote monitoring activations are affected. New communicators for newly implanted CRM devices cannot currently be activated, delaying transmission of device data to remote patient management systems.

Newly implanted insertable cardiac monitors can continue recording episodes after activation through the Boston Scientific Clinic Assistant app. However, they cannot pair with patient mobile phones for remote transmission until systems are restored.

Boston Scientific said it is prioritizing systems that have the greatest effect on customer access, product delivery, and patient care. The company has not disclosed the threat actor, attack method, data theft, ransomware involvement, or a timeline for full recovery.

Prevent incidents due to slow investigations. Power your Tier 1 with threat intelligence from 15K SOCs: Integrate TI Lookup in your SOC

The post Boston Scientific Cyberattack Disrupts Medical Device Manufacturing and Global Operations appeared first on Cyber Security News.

A critical authentication bypass vulnerability in JFrog Artifactory, tracked as CVE-2026-82329, is being actively exploited, allowing unauthenticated attackers with network access to gain administrator-level privileges.

WatchTowr said its intelligence team has observed attackers exploiting the issue and “minting themselves admin tokens.” An attacker with a valid administrator token could control the affected Artifactory environment, including repositories, user accounts, access permissions, build artifacts, and software packages stored in the platform.

JFrog disclosed the vulnerability on August 28, 2026, and classified it as critical. The company described CVE-2026-82329 as an improper authentication issue, tracked under CWE-287.

Under the default configuration, a remote attacker does not need valid credentials to exploit the weakness and may obtain administrative privileges.

JFrog Artifactory Auth Bypass Exploited

Artifactory is widely used by development and DevOps teams to manage packages, container images, binaries, build dependencies, and other software artifacts.

Because it often sits within CI/CD pipelines, compromising an Artifactory server can pose a serious risk to the software supply chain.

Attackers who gain admin control may be able to alter repository settings, create privileged accounts, steal stored secrets, access private packages, or attempt to introduce malicious artifacts into trusted build and deployment workflows.

According to exposure management firm WatchTowr, the reported creation of administrator tokens is particularly concerning because they can provide persistent access even after an organization changes passwords or terminates active user sessions.

Security teams should investigate whether any unexpected administrator tokens, new privileged users, unusual API activity, or configuration changes were created around the time the vulnerable instance was exposed.

JFrog said its cloud environments have already been fortified, meaning customers using the vendor-managed cloud service do not need to take action for this specific issue.

However, organizations running self-hosted Artifactory must upgrade immediately to a fixed release on their supported branch. The patched versions are 7.111.21, 7.117.28, 7.125.20, 7.133.29, 7.146.38, and 7.161.20.

The affected ranges include Artifactory versions 7.111.4 through 7.111.21, 7.117.0 through 7.117.27, 7.125.0 through 7.125.19, 7.133.0 through 7.133.28, 7.146.0 through 7.146.36, and 7.161.0 through 7.161.19.

Organizations should also restrict external access to Artifactory management interfaces, review reverse-proxy and firewall rules, and ensure only trusted networks can reach administrative endpoints.

Teams should inspect access logs for unfamiliar source IP addresses, failed or abnormal authentication requests, token-generation events, and calls to user, permission, or repository administration APIs.

Administrators should treat any internet-exposed, unpatched self-hosted Artifactory deployment as potentially compromised.

After patching, organizations should revoke and reissue administrator tokens, review all privileged accounts, validate repository integrity, and examine CI/CD credentials that may have been accessible through the platform.

The active exploitation report makes rapid remediation essential. A compromised artifact repository can turn a single authentication bypass into a broader breach affecting developers, build systems, production workloads, and downstream software users.

Prevent incidents due to slow investigations. Power your Tier 1 with threat intelligence from 15K SOCs: Integrate TI Lookup in your SOC

The post JFrog Artifactory Auth Bypass Exploited in Attacks to Gain Admin Access appeared first on Cyber Security News.

A newly patched Linux kernel vulnerability, tracked as CVE-2026-46215, allowed any local user with access to a GPU render node to escalate privileges to root, without requiring any special permissions.

The flaw affected mainline kernels from v6.18-rc1 through the fix, and was reported to security@kernel.org on 12 April 2026, with a patch landing in late May 2026.

The bug is a use-after-free in the DRM GEM core ioctl DRM_IOCTL_GEM_CHANGE_HANDLE, added in v6.18-rc1 for AMD’s CRIU checkpoint/restore work.

This ioctl moves a graphics buffer object from one handle to another but never updates the object’s handle_count. During a brief window, the object has two IDR (ID lookup) entries while its handle count still reads 1.

If a second thread calls DRM_IOCTL_GEM_CLOSE on the old handle during that window, it drives the count to 0 and frees the object while the new handle still points to the now-freed memory.

Both ioctls carry the DRM_RENDER_ALLOW flag, meaning any process that can open /dev/dri/renderD* can trigger the race. On most desktop Linux systems, systemd-logind grants this access to any logged-in user by default.

From Race Condition to Root

The Cyberstan proof-of-concept chains several techniques to turn the freed object into full root access:

• Reclaims the freed memory slot using a sprayed array of pipe_buffer structures
• Leaks a kernel pointer through overlapping struct fields to defeat KASLR
• Sets PIPE_BUF_FLAG_CAN_MERGE via a GEM object naming trick, bypassing the 2022 DirtyPipe fix
• Overwrites the read-only /etc/passwd file through the page cache, removing root’s password field

Across 100 test boots, the exploit succeeded 99 times, taking on average under 100 race iterations to win.

Researcher Puttimet Thammasaeng reported the same bug first before Cyberstan and received the official CVE credit and upstream “Reported-by” attribution. The author of this analysis discovered and reported it independently, contributing separate exploit research.

AMD’s David Francis and kernel maintainer Dave Airlie shipped a fix that closes the race window with a two-stage idr_replace operation, rolling back cleanly if a concurrent close wins the race.

Kernel maintainers went further, disabling the GEM_CHANGE_HANDLE ioctl entirely in the upcoming 7.1 release, removing the vulnerable code path altogether. Fixed versions are 6.18.32, 7.0.9, and 7.1-rc3 onward.

The vulnerability illustrates a recurring kernel bug pattern: compound operations on refcounted objects in which a reference is added, removed, and counted in separate steps, creating windows where concurrent teardown can free memory still in use, as the Cyberstan advisory notes.

Subsystems that skip established helper functions for this bookkeeping remain at risk of similar race conditions.

Stop Accepting SLAs Written for 2019 SOCs – Here’s the 2026 AI SLA Vendor Checklist – Download Free AI SOC SLA Guide

The post Linux Kernel Vulnerability Enables Passwordless Root Through DRM Render Nodes appeared first on Cyber Security News.

A newly identified threat group tracked as UNC6692 is hijacking Microsoft Teams to install a custom malware suite called SNOW.

The campaign relies almost entirely on social engineering, which makes it dangerous because it feels routine to the people who fall for it.

Attackers pose as IT helpdesk staff, exploiting a target’s trust in familiar collaboration tools to walk victims through handing over control of their machine.

The attack begins with a wave of spam emails sent to a target’s inbox, creating chaos and urgency.

Once the victim is overwhelmed, the same attacker reaches out through Microsoft Teams, posing as an IT support agent offering to fix the problem they caused.

This staged setup convinces users to trust a stranger who appears to be solving an issue rather than creating one.

Analysts at ExtraHOP said in a report shared with Cyber Security News (CSN) identified and detailed how this coordinated chain plays out from first contact to full network compromise.

Once a victim accepts the fake Teams invitation, the attacker sends a link claiming to install a patch that stops the spam.

Clicking it downloads a renamed AutoHotkey binary along with a script sharing the same file name, pulled from an attacker controlled cloud bucket.

That download becomes the first stage of the SNOW malware ecosystem, a modular toolkit built to support activity after the breach.

It includes a malicious browser extension, a Python based tunneling tool, and a lightweight local backdoor, each handling a part of the intrusion.

Together they let the attacker maintain a presence long after the phishing message is forgotten.

Once inside, UNC6692 does not rush. The group moves carefully through compromised systems, harvesting credentials, exploring internal networks, and expanding access before doing anything that might trigger alarms.

UNC6692 Hackers Uses Microsoft Teams Helpdesk Impersonation

The impersonation trick is simple but effective because it mirrors real corporate support interactions.

After the spam flood, the attacker contacts the victim through a Teams chat request from an account outside the organization, posing as a helpful colleague.

Many users accept external chat invitations without a second thought, especially when the message promises to fix a problem they already face.

Victims are directed to a phishing page disguised as a mailbox repair and sync utility, complete with a professional interface and a health check button.

That button triggers a login prompt, and the page asks for credentials multiple times under the guise of verification, which helps the stolen data hold up if checked later. The captured logins are then quietly sent to a cloud location controlled by the attacker.

This is the entry point for everything that follows. Once the AutoHotkey script runs, it performs reconnaissance and installs SNOWBELT, a rogue browser extension, by launching Microsoft Edge in a hidden mode using command line settings that skip normal installation checks.

Inside the SNOW Malware Toolkit

SNOW is not a single piece of malware but a layered pipeline built for persistence and stealth.

SNOWBELT operates within the browser and can survive restarts, while a Python based tunneling utility supports SOCKS5 style traffic to route commands through the compromised host, blending in with normal web activity.

A separate local HTTP backdoor gives the attacker a direct channel for issuing commands and pulling data without relying on infrastructure that might get flagged.

The toolkit also supports screenshot capture, file exfiltration, and session termination, giving operators control over how long they stay hidden.

Because the traffic moves through legitimate cloud services and familiar Windows features, standard network monitoring often misses it entirely.

Security teams should watch for unusual browser extension installations, scheduled tasks that launch Edge in headless mode, and unexpected outbound connections to unfamiliar endpoints.

Organizations are advised to restrict external chat permissions on Microsoft Teams to approved contacts and train employees to treat unsolicited helpdesk outreach with caution.

Blocking unapproved file sharing platforms and requiring verification before remote assistance can reduce exposure to this kind of intrusion.

This campaign shows how attackers favor patience and disguise over brute force, turning ordinary workplace habits into an opening for deep compromise.

Indicators of Compromise (IoCs):-

Note: IP addresses and domains are intentionally defanged (e.g., [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.

Prevent critical incidents and financial loss with stronger proactive defense. Integrate a live threat feed from 15K SOC Teams.

The post UNC6692 Hackers Uses Microsoft Teams Helpdesk Impersonation to Deploy SNOW Malware appeared first on Cyber Security News.

Threat intelligence feeds have become a staple line item in security budgets. Yet a persistent gap exists between purchasing a feed and actually using it to stop attacks.

Many SOC teams receive a steady stream of indicators — IP addresses, domains, URLs — that flows into a SIEM or threat intel platform and largely stays there, rarely making it into detection rules, analyst workflows, or response playbooks in a timely, structured way.

This is the operationalization gap. And closing it is one of the highest-leverage moves a SOC leader can make.

Why Most Threat Intelligence Sits Unused 

The failure mode is rarely a lack of data. It is a lack of structure around the data. 

When feeds arrive as undifferentiated bulk exports, analysts face several problems simultaneously.

The volume is too high to manually triage. Context is missing — an IP address alone tells you nothing about which threat actor uses it, which campaigns it is associated with, or how recently it was observed as malicious. Confidence levels are opaque.

And integration with enforcement points firewalls, EDR platforms, SIEMs is often manual or scheduled in batch cycles that introduce dangerous lag. 

The result: intelligence arrives too slowly, in a form that requires too much analyst effort to act on, and without the context needed to prioritize it over the hundreds of other alerts already in the queue. 

What Operationalized Threat Intelligence Actually Looks Like 

Operationalized threat intelligence is intelligence that automatically flows from collection through enrichment to detection and response with minimal friction at each handoff. 

In practice, this means: 

• Automated ingestion. The Feeds connect directly to your SIEM, SOAR, or TIP via standardized formats (STIX/TAXII, MISP, CSV/JSON) or native integrations, eliminating manual export-import cycles. 

• Contextual enrichment at ingestion time. Each indicator arrives with metadata — associated malware family, threat actor attribution, first/last seen timestamps, confidence score, and relevant MITRE ATT&CK technique mappings. Analysts immediately know whether an IP is linked to a ransomware group targeting their sector or to low-confidence commodity spam infrastructure. 

• Freshness that matches attacker infrastructure lifecycles. Threat actor IP addresses turn over in hours to days. A feed updated weekly delivers intelligence that is, at best, historical. Operational feeds update continuously, ensuring that what you are blocking and alerting on reflects today’s threat landscape, not last week’s. 

• Bidirectional integration. Intelligence feeds — into detection rules. Alerts generated by those rules feed back into the intel workflow, generating new indicators and refining existing ones. The SOC is not a passive consumer of intelligence — it is a participant in the intelligence cycle. 

Operationalize your threat intelligence. See how ANY.RUN TI Feeds help security teams automate IOC ingestion, enrich detections with real-world context, and reduce time to detect and respond. 

The Integration Stack: Where Feeds Plug In 

A threat intelligence feed delivers full value only when it is connected to the tools that enforce policy and generate alerts. The primary integration points are: 

• SIEM. IOCs from the feed populate lookup tables or correlation rules. Any internal log event matching a known malicious indicator triggers an alert with context already attached — the analyst sees not just a match but the associated campaign and recommended response. 

• SOAR. Playbooks reference feed data for automated enrichment during triage. When an alert fires, the SOAR platform instantly queries the feed for additional context on the involved indicators, accelerating analyst decision-making and reducing mean time to respond. 

• Firewall / network controls. High-confidence IOCs — particularly IPs and domains associated with active C2 infrastructure — are pushed directly to blocklists, providing automatic prevention without requiring analyst intervention. 

• EDR. File hashes and behavioral indicators from the feed inform endpoint detection, allowing security teams to hunt retroactively across the environment for artifacts associated with active threat campaigns. 

The key requirement across all of these: the feed must support the integration formats your stack already uses. A feed that needs custom scripting to ingest is a feed that will not be used consistently. 

ANY.RUN Threat Intelligence Feeds: Built for Operational Integration 

ANY.RUN TI Feeds are designed specifically to close the operationalization gap — delivering sandbox-sourced, continuously updated threat intelligence in the formats and integrations your SOC already relies on. 

• Sandbox-sourced indicators, not scraped aggregations. Every indicator in ANY.RUN TI Feeds originates from dynamic analysis of real malware samples inside the ANY.RUN interactive sandbox. This means indicators are verified against actual malicious behavior, not inferred from passive observation or aggregated from third-party sources. The result is higher fidelity, lower false positive rates, and richer contextual metadata per indicator. 
   
• Continuous updates. ANY.RUN processes thousands of malware samples daily. TI Feeds are updated in near-real time, ensuring that newly identified C2 infrastructure, fresh phishing domains, and emerging dropper hashes reach your defenses while they are still operationally relevant. 
   
• Rich context by default. Each indicator is delivered with associated malware family, threat actor context where attributable, MITRE ATT&CK technique tags, confidence scores, and first/last seen timestamps. Analysts are not handed a raw IP — they are handed an IP with a complete picture of why it matters and what to do with it. 
   
• Flexible delivery formats. ANY.RUN TI Feeds support STIX/TAXII, MISP, and direct CSV/JSON export, covering the integration  requirements of the major SIEM, SOAR, and TIP platforms in use across enterprise security stacks. For teams running Splunk, Microsoft Sentinel, IBM QRadar, or Palo Alto XSOAR, native connectors further reduce integration effort. 
   
• Broad threat coverage. Feeds cover the malware families and threat actor infrastructure most active in the current threat landscape — including ransomware groups, banking trojans, infostealers, and commodity loaders — with coverage that reflects what is being actively deployed against organizations today.

• On-demand investigation with Threat Intelligence Lookup. TI Feeds handle continuous, automated intelligence ingestion. But operationalization also requires the ability to answer ad-hoc questions — when an analyst encounters an unfamiliar indicator mid-investigation, they need to query the full intelligence corpus instantly, not wait for the next feed cycle. 
   
  ANY.RUN TI Lookup provides exactly that: a searchable threat intelligence database built on the same sandbox-derived data that powers the feeds, queryable by IP, domain, hash, MITRE technique, threat actor, malware family, and more. TI Feeds and Lookup work as complementary layers — one automates coverage at scale, the other empowers analysts to investigate on demand. 

Together with the Interactive Sandbox, TI Feeds and TI Lookup form a unified intelligence ecosystem: from automated indicator delivery, through investigative deep-dives, to hands-on malware analysis all drawing from the same continuously updated, behavior verified data source. 

Making the Business Case to Leadership 

For CISOs presenting to boards or justifying budget, operationalized threat intelligence has a clear value story: it reduces the cost of detection and response. 

Every hour an analyst spends manually enriching an alert with context that an integrated feed could have provided automatically is an hour not spent on investigation, hunting, or response.

Every day a malicious IP remains unblocked because the feed update cycle is too slow is a day of unnecessary exposure. 

The operational metrics that matter: reduction in mean time to detect (MTTD), reduction in mean time to respond (MTTR), analyst hours saved per week on manual enrichment tasks, and false positive rates on feed-sourced detections.

These are the numbers that demonstrate whether your threat intelligence investment is translating into security outcomes. 

Conclusion 

The fastest path to operationalized threat intelligence is a feed that is already built for integration — one that does not require significant engineering effort to connect to your existing stack and that delivers context-rich, continuously updated indicators from the moment it goes live. 

Bridge the gap between threat data and real security outcomes. Use ANY.RUN TI Feeds to power faster detection, automated enrichment, and more effective incident response with continuously updated threat intelligence. 

The post Operationalizing Threat Intelligence: Bridging the Gap Between Feed Data and SOC Action appeared first on Cyber Security News.