ANY.RUN shows how early clarity, automation and shared data help SOC teams cut delays and speed up response during heavy alert loads.

_Disclosure: This article was provided by ANY.RUN. The information and analysis presented are based on their research and findings._

What slows your Security Operations Center (SOC) down when a critical alert hits? For many teams, it’s not the alert itself but the time lost searching for clarity, switching between tools, and trying to confirm what’s real and what’s noise.

Leading SOCs have already started adopting specific strategies that help them cut this delay, shorten response time, and keep control even during heavy alert loads. Let’s discover what these strategies are and how you can bring them into your workflow.

****Why Response Time Slows Down****

Most delays inside a SOC come from one simple problem: analysts don’t get the right information fast enough. When an alert arrives without context, the team has to dig for answers; check logs, compare sources, wait for results from separate tools. Minutes disappear before anyone can say whether the threat is serious or not.

This gap creates three predictable issues:

*   **Uncertain prioritisation:** Teams waste time on alerts that don’t matter.

*   **Slow confirmation:** Analysts spend too long verifying what the threat is actually doing.

*   **Longer MTTR:** The whole response chain stretches because early steps take too much time.

This is exactly where high-performing SOCs have changed their approach: they focus on cutting the “uncertainty window” at the very beginning of the process.

****Strategy 1: Get Clarity Early to Avoid Wasting Time****

One pattern stands out across fast, well-organised SOCs: they reduce uncertainty at the very beginning of an alert. Instead of waiting for scattered tools to catch up, many teams now rely on interactive sandboxes like ANY.RUN to see what the threat is actually doing within moments.

For most samples, analysts receive a clear verdict in about 60 seconds, and in many cases, the full attack chain becomes visible almost instantly. This cuts down the usual back-and-forth, removes guesswork, and lets the team decide on the next steps without delay.

Fake Google Careers page exposed inside ANY.RUN sandbox in 60 seconds

When clarity arrives this quickly, response time drops sharply, and the entire workflow moves with far more confidence and control.

****Strategy 2: Automate Early Steps to Speed Up Your Response Cycle****

A surprising amount of lost time inside a SOC comes from actions that don’t require analyst expertise at all; opening lures, clicking through fake pages, solving CAPTCHAs, following redirects, or coaxing a threat to finally reveal itself. These tiny steps slow down the very beginning of the response cycle, making it harder for teams to react quickly when it matters most.

Leading SOCs avoid this slowdown by automating the early phase of alert validation. ANY.RUN’s automated interactivity blends automation with human-like actions: it can follow QR-code chains, interact with fake login pages, trigger multi-stage loaders, and bypass common barriers that usually require manual effort. All of this happens automatically, within seconds.

CAPTCHA challenge automatically solved inside ANY.RUN sandbox

As a result, teams report up to a 20% decrease in Tier 1 workload and fewer unnecessary Tier 1-to-Tier 2 escalations, because routine checks no longer require human time. Analysts get to the important part of the investigation faster, and the whole response cycle moves noticeably quicker.

****Strategy 3: Strengthen Collaboration So Your Response Doesn’t Stall****

A SOC can move quickly only if everyone involved sees the same picture and works from the same information. When data is scattered, screenshots in chats, logs in tickets, partial notes in emails, the response slows down simply because teams spend too much time syncing.

Leading SOCs avoid this by giving analysts, engineers, and incident responders a shared workspace with consistent, ready-to-use data. ANY.RUN makes this simple: every analysis generates a structured report with timelines, IOCs, network details, and behavioural highlights, all in a format that can be shared instantly across teams and tools.

Well-structured report with relevant IOCs, TTPs and other important information

This removes the usual communication lag, cuts back on repeated checks, and ensures that everyone involved can act immediately without waiting for clarification. The result is faster coordination, cleaner handoffs, and a response process that keeps moving instead of stopping to gather missing details.

****Achieve the Response Speed Your SOC Needs****

As you can see, reaching ultra-fast response time is absolutely possible when teams combine the right strategies with solutions designed to remove delays from the very start of an alert. SOCs using ANY.RUN’s sandbox has already proven this through measurable, real-world results from our latest survey:

*   **Up to 21 minutes reduced MTTR** per incident
*   **95% of SOC teams speed up threat investigations**
*   **94% of users report faster triage**
*   **3× SOC efficiency boost**
*   **24× more unique IOCs** to power downstream detection
*   **Fewer false positives** and more accurate prioritisation

If you want to see how much faster your team can operate with the same advantages, there’s only one way to know: Try ANY.RUN and measure the difference yourself.

****Free Webinar: SOC Leader’s Playbook – 3 Steps to Faster MTTR****

For readers who want a deeper look at practical ways to speed up incident response, ANY.RUN is hosting a one-hour session titled “SOC Leader’s Playbook: 3 Steps to Faster MTTR.” It will take place on 25 November 2025 at 16:00 CET.

During the webinar, experts will cover how leading SOCs:

*   Cut MTTR by 21 minutes per incident
*   Detect new attacks earlier with intelligence from 15,000 organisations
*   Achieve a 3× performance boost by reducing false positives

Save your seat now to get a clear, structured playbook for speeding up detection and response.

How to Achieve Ultra-Fast Response Time in Your SOC

Schools in the US are installing vape-detection tech in bathrooms to thwart student nicotine and cannabis use. A new investigation reveals the impact of using spying to solve a problem.

Vaping Is ‘Everywhere’ in Schools—Sparking a Bathroom Surveillance Boom

The threat actor known as PlushDaemon has been observed using a previously undocumented Go-based network backdoor codenamed EdgeStepper to facilitate adversary-in-the-middle (AitM) attacks.
EdgeStepper "redirects all DNS queries to an external, malicious hijacking node, effectively rerouting the traffic from legitimate infrastructure used for software updates to attacker-controlled infrastructure

Cyber Espionage / Malware

The threat actor known as **PlushDaemon** has been observed using a previously undocumented Go-based network backdoor codenamed EdgeStepper to facilitate adversary-in-the-middle (AitM) attacks.

EdgeStepper "redirects all DNS queries to an external, malicious hijacking node, effectively rerouting the traffic from legitimate infrastructure used for software updates to attacker-controlled infrastructure," ESET security researcher Facundo Muñoz said in a report shared with The Hacker News.

Known to be active since at least 2018, PlushDaemon is assessed to be a China-aligned group that has attacked entities in the U.S., New Zealand, Cambodia, Hong Kong, Taiwan, South Korea, and mainland China.

It was first documented by the Slovak cybersecurity company earlier this January, detailing a supply chain attack aimed at a South Korean virtual private network (VPN) provider named IPany to target a semiconductor company and an unidentified software development company in South Korea with a feature-rich implant dubbed SlowStepper.

Among the adversary's victims include a university in Beijing, a Taiwanese company that manufactures electronics, a company in the automotive sector, and a branch of a Japanese company in the manufacturing sector. Earlier this month, ESET also said it observed PlushDaemon targeting two entities in Cambodia this year, a company in the automotive sector and a branch of a Japanese company in the manufacturing sector, with SlowStepper.

The primary initial access mechanism for the threat actor is to leverage AitM poisoning, a technique that has been embraced by an "ever increasing" number of China-affiliated advanced persistent threat (APT) clusters in the last two years, such as LuoYu, Evasive Panda, BlackTech, TheWizards APT, Blackwood, and FontGoblin. ESET said it's tracking ten active China-aligned groups that have hijacked software update mechanisms for initial access and lateral movement.

The attack essentially commences with the threat actor compromising an edge network device (e.g., a router) that its target is likely to connect to. This is accomplished by either exploiting a security flaw in the software or through weak credentials, allowing them to deploy caEdgeStepper.

"Then, EdgeStepper begins redirecting DNS queries to a malicious DNS node that verifies whether the domain in the DNS query message is related to software updates, and if so, it replies with the IP address of the hijacking node," Muñoz explained. "Alternatively, we have also observed that some servers are both the DNS node and the hijacking node; in those cases, the DNS node replies to DNS queries with its own IP address."

Internally, the malware consists of two moving parts: a Distributor module that resolves the IP address associated with the DNS node domain ("test.dsc.wcsset\[.\]com") and invokes the Ruler component responsible for configuring IP packet filter rules using iptables.

The attack specifically checks for several Chinese software, including Sogou Pinyin, to have their update channels hijacked by means of EdgeStepper to deliver a malicious DLL ("popup\_4.2.0.2246.dll" aka LittleDaemon) from a threat actor-controlled server. A first-stage deployed through hijacked updates, LittleDaemon is designed to communicate with the attacker node to fetch a downloader referred to as DaemonicLogistics if SlowStepper is not running on the infected system.

The main purpose of DaemonicLogistics is to download the SlowStepper backdoor from the server and execute it. SlowStepper supports an extensive set of features to gather system information, files, browser credentials, extract data from a number of messaging apps, and even uninstall itself.

"These implants give PlushDaemon the capability to compromise targets anywhere in the world," Muñoz said.

Found this article interesting? Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.

EdgeStepper Implant Reroutes DNS Queries to Deploy Malware via Hijacked Software Updates

Malicious actors can exploit default configurations in ServiceNow's Now Assist generative artificial intelligence (AI) platform and leverage its agentic capabilities to conduct prompt injection attacks.
The second-order prompt injection, according to AppOmni, makes use of Now Assist's agent-to-agent discovery to execute unauthorized actions, enabling attackers to copy and exfiltrate sensitive

AI Security / SaaS Security

Malicious actors can exploit default configurations in ServiceNow's Now Assist generative artificial intelligence (AI) platform and leverage its agentic capabilities to conduct prompt injection attacks.

The second-order prompt injection, according to AppOmni, makes use of Now Assist's agent-to-agent discovery to execute unauthorized actions, enabling attackers to copy and exfiltrate sensitive corporate data, modify records, and escalate privileges.

"This discovery is alarming because it isn't a bug in the AI; it's expected behavior as defined by certain default configuration options," said Aaron Costello, chief of SaaS Security Research at AppOmni.

"When agents can discover and recruit each other, a harmless request can quietly turn into an attack, with criminals stealing sensitive data or gaining more access to internal company systems. These settings are easy to overlook."

The attack is made possible because of agent discovery and agent-to-agent collaboration capabilities within ServiceNow's Now Assist. With Now Assist offering the ability to automate functions such as help-desk operations, the scenario opens the door to possible security risks.

For instance, a benign agent can parse specially crafted prompts embedded into content it's allowed access to and recruit a more potent agent to read or change records, copy sensitive data, or send emails, even when built-in prompt injection protections are enabled.

The most significant aspect of this attack is that the actions unfold behind the scenes, unbeknownst to the victim organization. At its core, the cross-agent communication is enabled by controllable configuration settings, including the default LLM to use, tool setup options, and channel-specific defaults where the agents are deployed -

*   The underlying large language model (LLM) must support agent discovery (both Azure OpenAI LLM and Now LLM, which is the default choice, support the feature)
*   Now Assist agents are automatically grouped into the same team by default to invoke each other
*   An agent is marked as being discoverable by default when published

While these defaults can be useful to facilitate communication between agents, the architecture can be susceptible to prompt injections when an agent whose main task is to read data that's not inserted by the user invoking the agent.

"Through second-order prompt injection, an attacker can redirect a benign task assigned to an innocuous agent into something far more harmful by employing the utility and functionality of other agents on its team," AppOmni said.

"Critically, Now Assist agents run with the privilege of the user who started the interaction unless otherwise configured, and not the privilege of the user who created the malicious prompt and inserted it into a field."

Following responsible disclosure, ServiceNow said the behavior is intended to be this way, but the company has since updated its documentation to provide more clarity on the matter. The findings demonstrate the need for strengthening AI agent protection, as enterprises increasingly incorporate AI capabilities into their workflows.

To mitigate such prompt injection threats, it's advised to configure supervised execution mode for privileged agents, disable the autonomous override property ("sn\_aia.enable\_usecase\_tool\_execution\_mode\_override"), segment agent duties by team, and monitor AI agents for suspicious behavior.

"If organizations using Now Assist's AI agents aren't closely examining their configurations, they're likely already at risk," Costello added.

Found this article interesting? Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.

ServiceNow AI Agents Can Be Tricked Into Acting Against Each Other via Second-Order Prompts

Singapore, Singapore, 19th November 2025, CyberNewsWire

**Singapore, Singapore, November 19th, 2025, CyberNewsWire**

The collaboration advances enterprise grade application security into decentralized ecosystems, uniting Checkmarx’s AppSec expertise with Web3 specialization by CredShields.

CredShields, a leading Web3 security firm, has partnered with Checkmarx, the global leader in agentic AI-powered application security testing, to work with AI-driven smart contract audits, vulnerability research, and blockchain security tooling from CredShields to work alongside the Checkmarx application security platform.

As the application security market accelerates toward an expected US $55 billion by 2029, decentralized architectures introduce new attack surfaces that traditional AppSec programs are not designed to address. Nearly half of the largest DeFi breaches trace back to smart contract flaws, and in 2025 to date, losses from cryptocurrency service hacks already surpass US $2.1 billion and are projected to climb further. Research further indicates that up to 89% of smart contracts contain vulnerabilities, highlighting the need for Web3-native security standards alongside legacy security frameworks.

Through this agreement, Checkmarx is adding CredShields as a Web3 security partner to provide customers with dedicated support for decentralized environments. The collaboration combines Checkmarx’s enterprise AppSec leadership with deep expertise in smart contract auditing, vulnerability assessment, and blockchain security research from CredShields, enabling organizations to extend their existing DevSecOps programs into Web3 with minimal friction.

> “This partnership represents a natural evolution in the AppSec landscape,” said **Shashank**, Co-founder of CredShields. “Together with Checkmarx, we’re delivering a seamless layer of security that protects enterprise systems, decentralized applications, and smart contracts with the same rigor and intelligence.”

**The partnership will focus on:**

*   Comprehensive security coverage for decentralized applications, smart contracts, and wallets
*   AI-assisted vulnerability detection and manual audits powered by CredShields’ proprietary systems
*   Joint contributions to global security frameworks, including OWASP Smart Contract Security Standards and Smart Contract Top 10
*   Enterprise enablement to integrate Web3 security into existing DevSecOps pipelines

> “As enterprises extend their digital footprint into Web3, new attack surfaces emerge,” said **Scott Sieper**, Director of Product Management at Checkmarx. “Partnering with CredShields enables us to bring our deep AppSec expertise to blockchain environments and help organizations innovate with confidence while maintaining the same rigorous security standards they expect from Checkmarx.”

Checkmarx and CredShields aim to redefine enterprise application security for the decentralized era, ensuring that innovation and security evolve in parallel as organizations adopt blockchain at scale.

For more information about securing code at the speed of AI and the Checkmarx One platform, users can visit the website.

**About CredShields**

CredShields is a Web3 security firm specializing in manual smart contract audits, AI-powered vulnerability detection, and security automation across blockchain ecosystems. A contributor to the OWASP Smart Contract Top 10, CredShields protects leading protocols and enterprises through full-spectrum decentralized security solutions.

Users can watch the demo: https://lnk.credshields.com/checkmarx-demo

**Contact**

**CredShields**  
**marketing@credshields.com**

CredShields Joins Forces with Checkmarx to Bring Smart Contract Security to Enterprise AppSec Programs

Fortinet has warned of a new security flaw in FortiWeb that it said has been exploited in the wild.
The medium-severity vulnerability, tracked as CVE-2025-58034, carries a CVSS score of 6.7 out of a maximum of 10.0.
"An Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') vulnerability [CWE-78] in FortiWeb may allow an authenticated attacker to execute

Vulnerability / Network Security

Fortinet has warned of a new security flaw in FortiWeb that it said has been exploited in the wild.

The medium-severity vulnerability, tracked as **CVE-2025-58034**, carries a CVSS score of 6.7 out of a maximum of 10.0.

"An Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') vulnerability \[CWE-78\] in FortiWeb may allow an authenticated attacker to execute unauthorized code on the underlying system via crafted HTTP requests or CLI commands," the company said in a Tuesday advisory.

In other words, successful attacks require an attacker to first authenticate themselves through some other means and chain it with CVE-2025-58034 to execute arbitrary operating system commands.

It has been addressed in the following versions -

*   FortiWeb 8.0.0 through 8.0.1 (Upgrade to 8.0.2 or above)
*   FortiWeb 7.6.0 through 7.6.5 (Upgrade to 7.6.6 or above)
*   FortiWeb 7.4.0 through 7.4.10 (Upgrade to 7.4.11 or above)
*   FortiWeb 7.2.0 through 7.2.11 (Upgrade to 7.2.12 or above)
*   FortiWeb 7.0.0 through 7.0.11 (Upgrade to 7.0.12 or above)

The company credited Trend Micro researcher Jason McFadyen for reporting the flaw under its responsible disclosure policy.

Interestingly, the development comes days after Fortinet confirmed that it silently patched another critical FortiWeb vulnerability (CVE-2025-64446, CVSS score: 9.1) in version 8.0.2.

"We activated our PSIRT response and remediation efforts as soon as we learned of this matter, and those efforts remain ongoing," a Fortinet spokesperson told The Hacker News. "Fortinet diligently balances our commitment to the security of our customers and our culture of responsible transparency."

It's currently not clear why Fortinet opted to patch the flaws without releasing an advisory. But the move has left defenders at a disadvantage, effectively preventing them from mounting an adequate response.

"When popular technology vendors fail to communicate new security issues, they are issuing an invitation to attackers while choosing to keep that same information from defenders," VulnCheck noted last week.

Found this article interesting? Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.

Fortinet Warns of New FortiWeb CVE-2025-58034 Vulnerability Exploited in the Wild

The collaborative effort combines multiple federal departments, along with private companies to reduce, if not eliminate, billions lost annually to fraud.

US Creates 'Strike Force' to Take Out SE Asian Scam Centers

A mongoc_bulk_operation_t may read invalid memory if large options are passed.

**Exploitability Metrics**

Attack Vector: This metric reflects the context by which vulnerability exploitation is possible. This metric value (and consequently the resulting severity) will be larger the more remote (logically, and physically) an attacker can be in order to exploit the vulnerable system. The assumption is that the number of potential attackers for a vulnerability that could be exploited from across a network is larger than the number of potential attackers that could exploit a vulnerability requiring physical access to a device, and therefore warrants a greater severity.

Attack Complexity: This metric captures measurable actions that must be taken by the attacker to actively evade or circumvent existing built-in security-enhancing conditions in order to obtain a working exploit. These are conditions whose primary purpose is to increase security and/or increase exploit engineering complexity. A vulnerability exploitable without a target-specific variable has a lower complexity than a vulnerability that would require non-trivial customization. This metric is meant to capture security mechanisms utilized by the vulnerable system.

Attack Requirements: This metric captures the prerequisite deployment and execution conditions or variables of the vulnerable system that enable the attack. These differ from security-enhancing techniques/technologies (ref Attack Complexity) as the primary purpose of these conditions is not to explicitly mitigate attacks, but rather, emerge naturally as a consequence of the deployment and execution of the vulnerable system.

Privileges Required: This metric describes the level of privileges an attacker must possess prior to successfully exploiting the vulnerability. The method by which the attacker obtains privileged credentials prior to the attack (e.g., free trial accounts), is outside the scope of this metric. Generally, self-service provisioned accounts do not constitute a privilege requirement if the attacker can grant themselves privileges as part of the attack.

User interaction: This metric captures the requirement for a human user, other than the attacker, to participate in the successful compromise of the vulnerable system. This metric determines whether the vulnerability can be exploited solely at the will of the attacker, or whether a separate user (or user-initiated process) must participate in some manner.

**Vulnerable System Impact Metrics**

Confidentiality: This metric measures the impact to the confidentiality of the information managed by the VULNERABLE SYSTEM due to a successfully exploited vulnerability. Confidentiality refers to limiting information access and disclosure to only authorized users, as well as preventing access by, or disclosure to, unauthorized ones.

Integrity: This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information. Integrity of the VULNERABLE SYSTEM is impacted when an attacker makes unauthorized modification of system data. Integrity is also impacted when a system user can repudiate critical actions taken in the context of the system (e.g. due to insufficient logging).

Availability: This metric measures the impact to the availability of the VULNERABLE SYSTEM resulting from a successfully exploited vulnerability. While the Confidentiality and Integrity impact metrics apply to the loss of confidentiality or integrity of data (e.g., information, files) used by the system, this metric refers to the loss of availability of the impacted system itself, such as a networked service (e.g., web, database, email). Since availability refers to the accessibility of information resources, attacks that consume network bandwidth, processor cycles, or disk space all impact the availability of a system.

**Subsequent System Impact Metrics**

Confidentiality: This metric measures the impact to the confidentiality of the information managed by the SUBSEQUENT SYSTEM due to a successfully exploited vulnerability. Confidentiality refers to limiting information access and disclosure to only authorized users, as well as preventing access by, or disclosure to, unauthorized ones.

Integrity: This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information. Integrity of the SUBSEQUENT SYSTEM is impacted when an attacker makes unauthorized modification of system data. Integrity is also impacted when a system user can repudiate critical actions taken in the context of the system (e.g. due to insufficient logging).

Availability: This metric measures the impact to the availability of the SUBSEQUENT SYSTEM resulting from a successfully exploited vulnerability. While the Confidentiality and Integrity impact metrics apply to the loss of confidentiality or integrity of data (e.g., information, files) used by the system, this metric refers to the loss of availability of the impacted system itself, such as a networked service (e.g., web, database, email). Since availability refers to the accessibility of information resources, attacks that consume network bandwidth, processor cycles, or disk space all impact the availability of a system.

GHSA-mwcc-7vpp-xmv9: MongoDB driver extension affected by mongoc_bulk_operation_t's read of invalid memory

Unsafe Deserialization vulnerability in Modular Max Serve before 25.6, specifically when the "--experimental-enable-kvcache-agent" feature is used allowing attackers to execute arbitrary code.

GHSA-7xcv-9j6c-2fmc: Modular Max Serve has Unsafe Deserialization vulnerability

IoT devices can be compromised, thanks to gaps in cloud management interfaces for firewalls and routers, even if they're protected by security software or not online.

Latest News