New SOC-Ready Reporting for Faster Triage, Escalation, and Incident Response with ANY.RUN 

Successful SOC operations require more than accurate detections. Instant access to context, clear conclusions, and operationally relevant insights allow incidents to move across workflows without delays: 

  • During alert triage, analysts need a quick threat overview to decide on the next steps. 
  • Efficient incident response decisions demand clear, actionable context to rely on. 
  • Swift incident reporting requires cross-tier visibility without the need for manual processing of raw technical data. 

Making ANY.RUN’s Interactive Sandbox a part of your standard SOC workflow helps eliminate bottlenecks that occur along the incident lifecycle by contributing to the optimization of each process, decision, and report. 

SOC-ready Tier 1 reports turn complex sandboxing analysis into structured, decision-ready intelligence for faster, efficient triage, escalation, response, and reporting. 

Executive Summary 

  • Whether operating as an internal SOC or delivering MDR and MSSP services, organizations need investigation workflows that scale efficiently under growing alert volumes. 
  • ANY.RUN’s Interactive Sandbox with Tier 1 Reports helps standardize triage, escalation, and incident reporting by becoming a decision-support layer for your security operations. 
  • Enterprise Suite teams can optimize sandbox investigations and reporting across the SOC at scale with unlimited Tier 1 report generation. 
  • The result is faster investigations, consistent escalations with less context lost, and optimized incident documentation for confident decisions and risk prioritization. 

Challenges SOC Teams Face Today  

With SOC teams continuously investigating suspicious files, URLs, phishing pages, and malware samples, turning the resulting massive volume of technical findings into actionable operational context fast enough to support efficient response becomes the key challenge. 

The lack of standardized reporting leads to: 

  • Slow triage due to excessive manual work for Tier 1 
  • Higher pressure on Tier 2/3 and incident response team due to lack on ready-to-apply context  
  • Context loss during escalations and critical delays occur 
  • Additional burden falling on SOC managers without clear visibility into incident severity and business impact 

ANY.RUN’s Interactive Sandbox already simplifies malware and phishing analysis through interactive, real-time investigation. Now, with Tier 1 Reports and AI Summary, it supports decision-making and reporting acrossSOC operations. 

Phishing sample analysis in ANY.RUN Sandbox 

SOC-Ready Reporting Built Into the Analysis Workflow 

New Tier 1 reports are integrated into SOC workflows through and offer complete, structured documents with operationally useful insights. 

Tier 1 report includes:   

  • A clear verdict on the analyzed sample   
  • AI Summary featuring threat classification and executive summary 
  • Key IOCs and behavioral indicators  

They can be generated directly within the Interactive Sandbox in a single click, making sandbox analysis immediately usable across operational workflows. 

Clarity for analysts. Visibility for decision-makers.
Faster response across the SOC.



Optimize Your SOC Workflow


Use Case #1: Fast Threat Understanding for Tier 1 During Triage 

Via Tier 1 reports featuring AI Summaries, ANY.RUN’s Interactive Sandbox provides immediate answers to the most critical questions that occur during alert triage

  • Is the sample malicious? 
  • What behavior indicates that? 
  • What type of threat is involved? 
  • What MITRE ATT&CK TTPs and IOCs are present? 
  • Does the incident require escalation? 
Threat verdict and tags at the top of Tier 1 reports already provide key info on the analyzed object 

Instead of manually reviewing raw technical data to answer these questions with confidence, the sandbox provides this context automatically in the form of a ready-to-use report that covers all findings into a clear operational document for fast and substantiated decision-making. 

ANY.RUN’s Interactive Sandbox & Tier 1 Reports  
Operational Impact  Business Impact 
Faster alert validation  Consistent triage quality  
Reduced manual enrichment   Better analyst productivity
Fewer unnecessary escalations  Reduced operational overhead 

Use Case #2: Easy Access to Context for Tier 2, Tier 3, IR teams  

In case of an escalation, Tier 2 analysts and incident responders frequently need to reconstruct investigation context manually before proceeding with containment. 

Raw sandbox outputs take time to process and interpret, stretching investigation time and creating friction, as higher tiers essentially have to go back to triage stage for verification. 

With Tier 1 reports, analysts get a structured information to pass on at the early stage, making ANY.RUN’s Interactive Sandbox more smoothly embedded into the entire investigation cycle, from triage to response

Clear breakdown of detected MITRE ATT&CK TTPs inside Tier 1 report 
ANY.RUN’s Interactive Sandbox & Tier 1 Reports  
Operational Impact  Business Impact 
Reduced friction during handoffs  Better collaboration between teams  
No context lost in the process  Full visibility for decision-makers 
Accelerated investigation pipeline  Optimized operations across tiers  

Use Case #3: Immediate Clarity for Decision-Makers 

SOC managers, Heads of SOC, and CISOs don’t have time to review every technical artifact associated with an incident. Traditional reports may contain too many low-level details, whereas security leaders must assess the general business impact and urgency of a threat. 

ANY.RUN’s Interactive Sandbox optimizes the hand-off workflow with a concise overview of the analysis in operational language suitable for leadership. 

With AI Summary as part of the structure, the report explains what happened, why the object is malicious, which assets or systems may be at risk.  

As a result, analysis outputs become standardized and practical, making them immediately usable for decision-making and internal communication. 

ANY.RUN’s Interactive Sandbox & Tier 1 Reports  
Operational Impact  Business Impact 
Faster incident understanding    Better executive visibility 
  
Easier communication between teams    Faster prioritization through clarity 
Consistent incident documentation  Stronger operational governance 

Hands-On Case: Generating a Response-Ready Report on a Phishing Attack 

View analysis 

In this phishing investigation, the Tier 1 report provides a clear, operational overview of the entire attack chain, helping both analysts and leadership quickly understand the threat severity and required response actions. 

AI Summary further structures the findings into operationally relevant context suitable for triage, escalation, and internal communication: 

AI Summary providing a clear, structured overview of the threat 

The AI summary highlights the detection of a ClickFix phishing technique, followed by PowerShell execution with Execution Policy bypass attempts used to launch malicious activity on the host. It also outlines payload delivery behavior, subsequent system modifications, and persistence attempts through Windows Registry changes. 

Instead of manually reconstructing the attack flow from raw sandbox telemetry, analysts receive a ready-to-use interpretation of the incident that can immediately support escalation and response workflows. 

The complete attack chain, behavioral indicators, and resulting conclusions are already structured for operational use and are ready for further processing: escalation, IR hand-off, and containment. 

Turn sandbox analysis into confident SOC decisions

with interactive investigations and refined reporting



Power Your SOC with ANY.RUN


From Analysis to Action: Faster Escalations, Response, and Reporting 

The new Tier 1 reports featuring AI Summary deliver direct operational value across the SOC: 

  • Faster Triage: Tier 1 analysts can quickly understand the nature of the threat and make confident decisions on whether to close or escalate alerts. 
  • Streamlined Escalation Process: Tier 2 and IR teams receive well-structured context instead of raw data, reducing handoff time and miscommunication. 
  • Accelerated Incident Response: Teams gain rapid visibility into attack behavior, helping reduce Mean Time to Respond (MTTR). 
  • Improved Internal Reporting: SOC managers and CISOs get consistent, professional summaries that are easy to read and share with stakeholders. 
  • More Consistent Performance: Standardized reports reduce quality variation between analysts and lower the risk of human error. 

Unlimited access is available for Enterprise Suite and Hunter plans. Free plan users have a shared limit of 5 generations for both the Tier 1 report and AI Summary. 

Conclusion 

ANY.RUN’s new Tier 1 reports and AI Summary convert sandbox analysis outputs into structured, operationally ready documents that support every stage of the incident lifecycle, from initial triage to executive visibility. 

Embedding Interactive Sandbox directly into a SOC workflow strengthens overall security operations maturity by allowing for faster and more confident decision-making across processes. 

About ANY.RUN 

ANY.RUN delivers cybersecurity solutions designed to support real-world SOC operations. They help security teams understand threats faster, make informed decisions, and operationalize threat intelligence across detection, investigation, and response workflows. 

The company’s solutions include Interactive Sandbox for enterprise-grade malware analysis, as well as ANY.RUN’s Threat Intelligence with its modules Threat Intelligence Lookup and Threat Intelligence Feeds, providing continuously updated intelligence based on live attack analysis. 

Used by over 15,000 organizations and 600,000 security professionals worldwide, ANY.RUN is SOC 2 Type II certified, ensuring strong security controls and protection of customer data. 

Request access to ANY.RUN’s solutions →  

FAQ 

What are SOC-ready reports in ANY.RUN? 

SOC-ready reports are sandbox analysis summaries that provide operational context for faster triage, escalation, incident response, and internal reporting. 

Are Tier 1 reports designed only for Tier 1 analysts? 

No. While Tier 1 reports are designed to accelerate initial triage, they also support Tier 2, Tier 3, incident response teams, SOC managers, and CISOs by providing structured operational context, standardized reporting, and fast visibility into threat severity and business impact. 

What is included in ANY.RUN Tier 1 reports? 

Tier 1 reports include a threat verdict, AI Summary, MITRE ATT&CK mapping, behavioral indicators, and IOCs generated directly from Interactive Sandbox analysis. 

How does AI Summary improve incident response? 

AI Summary converts technical sandbox findings into concise operational explanations that help analysts and decision-makers quickly assess threat severity, business impact, and required response actions. 

Can ANY.RUN reports support SOC and MDR workflows? 

Yes. ANY.RUN’s SOC-ready reporting helps standardize triage, escalation, and investigation workflows across internal SOC, MDR, and MSSP teams. 

The post New SOC-Ready Reporting for Faster Triage, Escalation, and Incident Response with ANY.RUN  appeared first on ANY.RUN’s Cybersecurity Blog.

ANY.RUN’s Cybersecurity Blog – ​Read More

LLMjacking: what these attacks are, and how to protect AI servers

AI security covers more than just data theft prevention, restricting rogue AI agents, or stopping assistants from giving harmful advice. A relatively simple but rapidly scaling threat has emerged: attempts to hijack computational power and exploit someone else’s neural network for personal gain. This is known as LLMjacking. With AI compute costs widely predicted to surge dramatically, the number of attackers driven by these motives is poised to grow. Consequently, when deploying proprietary AI servers and their supporting ecosystems like RAG or MCP, it’s critical to establish rigorous security measures from day one.

Statistics from a honeypot

The speed and scale of these resource-hijacking attempts are best illustrated by an experiment documented in detail in April 2026. The investigator configured a Raspberry Pi to masquerade as a high-performance private AI server, and made it accessible from the internet. When queried, it reported the availability of Ollama, LM Studio, AutoGPT, LangServe, and text-gen-webui servers — all tools commonly used as wrappers for locally hosted AI models. The server also appeared ready to accept API requests in the OpenAI format, which has become the industry standard.

All these services were seemingly powered by a local instance of Qwen3-Coder 30B Heretic, one of the most powerful open-source models, with its safety alignment removed. To throw in a sweetener, the honeypot reported the presence of various RAG databases and an MCP server with tempting capabilities like get_credentials on board.

In reality, the Raspberry Pi was simply hosting 500 pre-saved responses from an actual Qwen3 model, with a lightweight script selecting the most relevant answer for each incoming query. This setup was enough to pass a superficial check while allowing the researcher to probe the attackers’ intentions.

According to the author, Shodan, a popular internet scanning service, discovered the server within three hours of its going live. Just one hour later, requests resembling capability reconnaissance began pouring in. Over the following month, the server handled more than 113 000 requests from thousands of unique IPs, with 23% of that traffic specifically targeted at discovering AI capabilities and exploiting local LLMs and AI agents.

Requests to endpoints like /api/tags and /v1/models allow attackers to fingerprint which models are hosted on a server, while scanning for /.cursor/rules typically precedes an attempt to exploit an AI agent. Similarly, checking /.well-known/mcp.json serves as an inventory of the victim’s MCP servers. While the author makes no mention of the total number of attacks that progressed beyond simple scanning, there were 175 active attempts to hijack the LLM during the final week of the experiment alone.

What are the attackers after?

Based on the researcher’s observations, none of those targeting the decoy server attempted to execute arbitrary code or gain root access. (Editorial note: this is surprising and may point to gaps in logging.) Almost all attacks were aimed at siphoning resources. For example, the following activities were logged during the experiment:

  • A well-structured attempt to parse technical documentation for a microprocessor
  • A prompt to write an erotic novel
  • Requests to parse and structure social media text data regarding new vulnerabilities
  • An attempt to call Anthropic models using the compromised server as an API proxy

It’s worth noting that the reconnaissance of AI resources uses standardized and rapidly evolving tools. Requests from an application named LLM-Scanner originated from the infrastructure of seven different cloud providers across eight countries, suggesting that the raiders have put established methodologies in place, as well as specialized platforms for sharing techniques. By the third week of the experiment, the scanner had been updated with an additional check: it now used simple abstract questions to determine whether it’s interacting with live AI or a honeypot returning canned responses.

Among the non-specific attacks, the experiment recorded numerous attempts to exfiltrate credentials from the .env file. Attackers systematically hunted for this file across every conceivable directory on the server. Leaving an .env file publicly accessible is one of the most elementary mistakes when deploying projects on Laravel, Node.js, and other frameworks, yet it remains a common oversight — particularly among beginners and vibe coders. Consequently, attackers have every reason to expect their efforts to pay off.

Conclusions and defense tips

Scanning publicly accessible servers and attempting to exploit them is nothing new, but the rise of LLMs gives attackers another way to monetize their efforts — one that’s both highly lucrative for them and devastating for their victims. To understand how massive these attacks could become, look at their closest counterpart: the cryptojacking market — where criminals mine cryptocurrency using stolen computational resources. That market grew by 20% in 2025 alone. As AI-powered solutions proliferate, and as major providers hike subscription costs while local AI chips remain in short supply, we should expect LLMjacking to become an industrial-scale phenomenon.

Key defensive measures for private AI infrastructure

  • For AI systems running locally on a single machine, ensure that servers like LM Studio, Ollama, or similar are configured to accept connections only on the local interface (localhost), rather than all available network interfaces. This restricts LLM access to the host machine itself, and prevents the AI from being reachable over the internet.
  • For servers handling remote requests — even if the server only operates within a local corporate network — implement robust authentication and authorization rather than relying solely on API key validation. Solutions based on OIDC or OAuth2 with short-lived tokens are the most effective. This not only defends against LLMjacking, but also allows for more granular tracking of user activity, and prevents API key abuse. Furthermore, keys must be protected from more than just external attackers; a growing risk is the misuse of keys by AI agents themselves. This applies to LLM interfaces as well as MCP, RAG, and others.
  • Use network segmentation and IP allowlists to give AI server access only to the departments, employees, and services that require it.
  • Ensure that all client-server connections are secured with a current version of TLS.
  • Apply the principle of least privilege by separating access to specific services; for instance, MCP and LLM components should have their own distinct access tokens.
  • Ensure an EDR security agent is installed on all workstations and servers, including those hosting AI models.
  • Monitor AI resource consumption, establish usage quotas for different employee roles, and set up alerts for anomalous activity spikes.
  • Maintain detailed logs of LLM responses and requests made to the model and its supporting tools. Integrate these data sources with your SIEM. Ensure logs are resilient against tampering or deletion.

Kaspersky official blog – ​Read More

Microsoft Patch Tuesday for May 2026 — Snort rules and prominent vulnerabilities

Microsoft Patch Tuesday for May 2026 — Snort rules and prominent vulnerabilities

By Jaeson Schultz 

Microsoft has released its monthly security update for May 2026, which includes 137 vulnerabilities affecting a range of products, including 31 that Microsoft marked as “critical”. 

In this month’s release, Microsoft has not observed any of the included vulnerabilities being actively exploited in the wild. Out of 31 “critical” entries, 16 are remote code execution (RCE) vulnerabilities in Microsoft Windows services and applications including Microsoft Office, Microsoft Word, Windows Native WiFi Miniport Driver, Azure, Office for Android, Microsoft Dynamics 365, Windows GDI, Microsoft SharePoint, Windows Graphics Component, Windows Netlogon, and Windows DNS Client. 

CVE-2026-32161 is a critical use after free vulnerability. Concurrent execution using a shared resource with improper synchronization (‘race condition’) in Windows Native WiFi Miniport Driver allows an unauthorized attacker to execute code over an adjacent network. 

CVE-2026-33109 is a critical access control vulnerability in Azure Managed Instance for Apache Cassandra. Improper access control allows an authorized attacker to execute code over a network.

CVE-2026-33844 is a critical input validation vulnerability in Azure Managed Instance for Apache Cassandra. Improper input validation allows an authorized attacker to execute code over a network.

CVE-2026-35421 is a critical heap-based buffer overflow vulnerability in Windows GDI that allows an unauthorized attacker to execute code locally. For this vulnerability to be exploited, a user would need to open or otherwise process a specially crafted Enhanced Metafile (EMF) file using Microsoft Paint. This action is necessary to trigger the affected graphics functionality in the Windows component. 

CVE-2026-40358 is a critical use after free vulnerability in Microsoft Office which allows an unauthorized attacker to execute code locally. 

CVE-2026-40361 is a critical use after free vulnerability in Microsoft Word that allows an unauthorized attacker to execute code locally. 

CVE-2026-40363 is a critical heap-based buffer overflow in Microsoft Office which allows an unauthorized attacker to execute code locally. 

CVE-2026-40364 is a critical heap-based buffer overflow vulnerability. Access of resource using incompatible type (‘type confusion’) in Microsoft Office Word allows an unauthorized attacker to execute code locally. 

CVE-2026-40365 is a critical vulnerability affecting Microsoft SharePoint. Insufficient granularity of access control allows an authorized attacker to execute code over a network. In a network-based attack, an authenticated attacker, as at least a Site Owner, could write arbitrary code to inject and execute code remotely on the SharePoint Server. 

CVE-2026-40366 is a critical use after free vulnerability in Microsoft Word which allows an unauthorized attacker to execute code locally. 

CVE-2026-40367 is a critical vulnerability affecting Microsoft Word. An untrusted pointer dereference may allow an unauthorized attacker to execute code locally. 

CVE-2026-40403 is a critical heap-based buffer overflow vulnerability in Windows Win32K – GRFX that allows an authorized attacker to execute code locally. This vulnerability could lead to a contained execution environment escape. In the case of a Remote Desktop connection, an attacker with control of a Remote Desktop Server could trigger a remote code execution (RCE) on the machine when a victim connects to the attacking server with a vulnerable Remote Desktop Client. 

CVE-2026-41089 is a critical stack-based buffer overflow in Windows Netlogon that allows an unauthorized attacker to execute code over a network. An attacker could send a specially crafted network request to a Windows server that is acting as a domain controller. If successful, this could cause the Netlogon service to improperly handle the request, potentially allowing the attacker to run code on the affected system without needing to sign in or have prior access. 

CVE-2026-41096 is a critical heap-based overflow vulnerability in Windows DNS Client. An attacker could exploit this vulnerability by sending a specially crafted DNS response to a vulnerable Windows system, causing the DNS Client to incorrectly process the response and corrupt memory. In certain configurations, this could allow the attacker to run code remotely on the affected system without authentication. 

CVE-2026-42831 is a critical heap-based buffer overflow vulnerability in Office for Android that allows an unauthorized attacker to execute code locally. An attacker must send a user a malicious Office file and convince them to open it. 

CVE-2026-42898 is a critical code injection vulnerability in Microsoft Dynamics 365 (on-premises). Improper control of generation of code (‘code injection’) allows an authorized attacker to execute code over a network. An attacker with the required permissions could modify the saved state of a process session in Dynamics CRM and trigger the system to process that data, which could result in the server unintentionally executing malicious code.

Talos would also like to highlight the following “important” vulnerabilities as Microsoft has determined that their exploitation is “more likely:”   

  • CVE-2026-33835: Windows Cloud Files Mini Filter Driver Elevation of Privilege Vulnerability 
  • CVE-2026-33837: Windows TCP/IP Local Elevation of Privilege Vulnerability 
  • CVE-2026-33840: Win32k Elevation of Privilege Vulnerability 
  • CVE-2026-33841: Windows Kernel Elevation of Privilege Vulnerability 
  • CVE-2026-35416: Windows Ancillary Function Driver for WinSock Elevation of Privilege Vulnerability 
  • CVE-2026-35417: Windows Win32k Elevation of Privilege Vulnerability 
  • CVE-2026-40369: Windows Kernel Elevation of Privilege Vulnerability 
  • CVE-2026-40397: Windows Common Log File System Driver Elevation of Privilege Vulnerability 
  • CVE-2026-40398: Windows Remote Desktop Services Elevation of Privilege Vulnerability 

A complete list of all the other vulnerabilities Microsoft disclosed this month is available on its update page.    

In response to these vulnerability disclosures, Talos is releasing a new Snort ruleset that detects attempts to exploit some of them. Please note that additional rules may be released at a future date, and current rules are subject to change pending additional information. Cisco Security Firewall customers should use the latest update to their ruleset by updating their SRU. Open-source Snort Subscriber Ruleset customers can stay up to date by downloading the latest rule pack available for purchase on Snort.org.    

Snort 2 rules included in this release that protect against the exploitation of many of these vulnerabilities are: 1:66438-1:66445, 1:66451-1:66460, and 1:66470-1:66476.  

The following Snort 3 rules are also available: 1:301494-1:301497, 1:301500-1:301506, 1:66472-1:66473, and 1:66476. 

Cisco Talos Blog – ​Read More

ANY.RUN & Elastic Security: Bring Threat Intelligence into Detection and Investigation Workflows      

Security teams don’t lack data. They lack timely, usable intelligence. Analysts spend too much time validating indicators, switching between tools, and figuring out what actually matters. This introduces delays and puts organizations at risk of a missed incident.  

ANY.RUN solves this by bringing real-time, behavior-validated threat intelligence from ANY.RUN integrated into Elastic Security, where SOC and MSSP teams detect emerging cyberattacks earlier and respond faster without changing their workflows.  

ANY.RUN Threat Intelligence Feeds x Elastic Security: About the Integration  

Integrate ANY.RUN’s TI Feeds in Elastic Security → 

Elastic Security unifies SIEM, endpoint security, and cloud security to help teams protect, investigate, and respond to threats.  

Through the ANY.RUN Threat Intelligence Feeds integration, organizations can ingest third-party threat indicators into Elastic Security and use them in detection, investigation, and threat intelligence workflows. This helps analysts bring external threat context into the same platform they use for security operations.   

ANY.RUN’s Threat Intelligence Feeds are built from live sandbox investigations across more than 15,000 organizations and 600,000 SOC professionals. Indicators reflect infrastructure actively used in phishing, malware delivery, and attacker campaigns, not delayed or aggregated data. Each IOC includes context and a direct link to the sandbox report, allowing analysts to quickly understand threat behavior and TTPs.  

The integration is available as a plug-and-play solution that only requires an active TI Feeds license (via trial or a paid subscription).  

IOC overview of Threat Intelligence Feeds inside Elastic Security 

Once configured, Elastic Security can ingest indicators such as IPs, domains, and URLs from the integration on a scheduled basis. Those indicators can then be used across supported detection, investigation, and visualization workflows.     

The additional context associated with ingested indicators can help analysts triage and investigate alerts more efficiently.  

Bring fresh, sandbox-backed IOCs into your SOC workflows.
Give your team the context to investigate faster and reduce business risk.



Contact us


How Threat Intelligence Feeds Improve Detection and Shorten MTTR in Elastic Security  

The integration embeds threat intelligence directly into daily SOC workflows inside Elastic Security. Analysts don’t need to manually check indicators in external tools or move data between systems.  

Here is what your team gains:  

  • Detect threats early: Use fresh indicators from live attacks to identify malicious activity sooner.   
  • Validate alerts with real context: Use sandbox-backed evidence instead of relying only on static indicators.  
  • Reduce manual work: Eliminate repetitive enrichment steps and tool switching.  
  • Improve detection quality: Use high-confidence indicators directly in rules and correlation logic.   
  • Speed up triage and response: Access context instantly and make faster decisions.   

Together, these improvements help reduce MTTD and MTTR, lower incident response costs, and increase analyst efficiency by enabling teams to handle more cases without expanding headcount. 

Better detection coverage and earlier visibility into active threats contribute to overall business risk reduction by limiting the impact and spread of attacks.  

How to Set Up ANY.RUN’s Threat Intelligence Feeds in Elastic Security  

The integration is designed to be simple and flexible. Once you get an active TI Feeds access, you can navigate to the integration page and follow the instructions.  

Indicators are automatically ingested into Elastic and continuously updated. They become part of detection, search, and response workflows.  

With ANY.RUN Threat Intelligence Feeds in Elastic Security, teams can:  

  • Use ingested ANY.RUN indicators in Elastic Security detection workflows  
  • Match threat indicators against relevant security telemetry  
  • Support triage and investigation with additional indicator context  
  • Build dashboards and visualizations for threat intelligence monitoring  
  • Incorporate third-party indicators into detection and hunting workflows  

Conclusion  

With ANY.RUN Threat Intelligence Feeds integrated into Elastic’s Security  platform can further enhance customer’s security detection with timely, behavior-validated intelligence., Organizations can detect threats early, reduce manual effort, and make fast, confident decisions.   

This leads not only to better SOC performance, but also to measurable business impact. Early detection, fast response, and improved signal quality help reduce the likelihood and impact of incidents, ultimately lowering overall business risk.  

About ANY.RUN  

ANY.RUN helps security teams understand threats faster and take action with confidence. Its solutions are trusted by over 600,000 security professionals and more than 15,000 organizations across industries where speed and accuracy are critical for effective response.  

ANY.RUN’s Interactive Sandbox allows teams to safely analyze suspicious files and URLs, observe real behavior in real time, and confirm threats before they spread.  

Combined with Threat Intelligence Lookup and Threat Intelligence Feeds, it provides the context needed to prioritize alerts, reduce uncertainty, and stop advanced attacks earlier in the response cycle.  

Request access to ANY.RUN’s solutions →  

The post ANY.RUN & Elastic Security: Bring Threat Intelligence into Detection and Investigation Workflows       appeared first on ANY.RUN’s Cybersecurity Blog.

ANY.RUN’s Cybersecurity Blog – ​Read More

State-sponsored actors, better known as the friends you don’t want

  • State-sponsored actors don’t break in. They log in, and they use your own tools to stay invisible for months.
  • Responding to a state-sponsored threat is nothing like responding to ransomware, and the differences can make or break the outcome. 
  • From logging and baselines to OT segmentation and supply chain readiness, the work that matters happens long before the first alert.

State-sponsored actors, better known as the friends you don’t want

Most organizations operate under the assumption that anything residing within their trust boundary is trustworthy. Software arrives from vetted vendors, employees pass background checks, cloud providers hold compliance certifications, and build pipelines produce signed artifacts. 

In practice, these assumptions are rarely scrutinized, and state-sponsored actors have constructed their operational methodology around exploiting precisely this gap. They operate inside the trust boundary, using trusted tools, holding valid credentials, and performing actions that appear entirely authorized. Conventional security architecture is not designed to identify this, and that limitation warrants acknowledgment before turning to what incident response looks like when the adversary is a state-sponsored.

Responding to a state-sponsored intrusion is fundamentally different from responding to a criminal one. The adversary is better resourced, more patient, operationally disciplined, and often in pursuit of objectives that do not trigger any alarms, such as espionage or long-term data extraction. Standard incident response playbooks, typically built around malware containment and ransomware recovery, are not adequate for this category of threat. The tooling, decision-making, legal coordination, and even the definition of what constitutes a successful response all need to be reconsidered.  

This is also the context in which zero trust architecture becomes essential. This is a fundamental reorientation from a model in which trust is assumed to one in which it is continuously verified, and in which systems are architected to handle the case where verification fails. The operative principle is not “trust nothing,” which no organization can realistically operationalize, but rather “verify continuously and plan for failure.” 

The following sections cover how state-sponsored actors operate across the Cyber Kill Chain, why their techniques demand different detection and response approaches, and what organizations need to have in place before, during, and after an intrusion to mount an effective response.

Same Kill Chain, different objective 

Every cyber attack, from commodity ransomware to state-sponsored espionage, follows the same fundamental sequence as the Cyber Kill Chain developed by Lockheed Martin: reconnaissance, weaponization, delivery, exploitation, installation, command and control (C2), and action on objectives. State-sponsored actors do not deviate from this sequence. They execute each phase with greater patience, greater precision, and a fundamentally different objective. 

A financially motivated attacker requires the target to know it has been compromised. The ransomware note, the leak site, and the negotiation channel are all components of the business model. A state-sponsored actor requires the opposite. Whether the objective is espionage, intellectual property theft, or pre-positioning for future disruption, success depends on the target remaining unaware. That requirement for covertness shapes every technical decision the actor makes and determines what defenders need to look for at each phase. The following are common trends that change the dimensions of defense:

  • Reconnaissance: This stage tends to be deeper and more prolonged. Where a financially motivated actor might scan for exposed Remote Desktop Protocol (RDP) and move on, a state-sponsored adversary may spend weeks or months mapping an organization’s personnel, technology stack, vendor relationships, and communication patterns, often entirely outside the target’s perimeter through open-source intelligence (OSINT) and social engineering of adjacent organizations. This phase frequently leaves no artifacts in defender logs. State-sponsored actors also have lawful access laws in their respective countries that allow them to obtain some of this data without the target being aware that any reconnaissance is taking place.
  • Initial access: State-sponsored adversaries can afford to expend significant capabilities against a single target, including zero-days or supply chain vectors that signature-based detection will not identify. More commonly, however, they use legitimate credentials obtained through spear phishing or supply chain compromise, which produce no exploit signature at all. 
  • Lateral movement: This is where the covert imperative becomes most technically consequential. Rather than deploying custom malware, state-sponsored actors increasingly operate using tools already present on the target’s systems, such as PowerShell, WMI, and PsExec, or they take time to observe what tools are used in the environment. If the environment uses SCCM or Puppet to manage infrastructure, the state-sponsored actor will aim to gain access to these systems and use legitimate deployment methods to compromise additional hosts. When Active Directory is queried through PowerShell, the security stack registers a routine administrative task, because it is indistinguishable from one. Extended dwell times result not from slow operational tempo, but from deliberate use of trusted tools to minimize the detection surface. 
  • Persistence: State-sponsored actors operate on the assumption that any single access method may be discovered and therefore establish multiple mechanisms across different parts of the infrastructure. Think aboutscheduled tasks, modified service configurations, dormant accounts, and firmware-level implants. These footholds may remain inactive for extended periods, activating only when an intelligence requirement or geopolitical trigger demands it. 
  • Action on objectives: This stage may not resemble what most teams would identify as an incident. If the objective is long-term data collection, exfiltration is structured to blend into normal traffic patterns. If the objective is pre-positioned disruption, as CISA assessed with Volt Typhoon in U.S. critical infrastructure, the actor may take no visible action during peacetime. Salt Typhoon’s access to lawful intercept systems required no disruptive action to deliver intelligence value. The access itself was the operation. When that access gets used is a separate question. 
  • Anti-forensics: Advanced actors clear event logs, manipulate file timestamps, operate in memory where possible, and use encrypted channels that leave minimal artifacts. Attribution may be further complicated by the deliberate planting of indicators associated with a different threat actor. 

Detection methodology does not require reinvention. The Kill Chain remains the same. It does, however, need to be calibrated for an adversary that treats every phase as an exercise in remaining invisible, that can operate using the target’s own tooling, and that measures success in months of undetected access.

Attribution 

Attribution in the context of incident response deserves a straightforward treatment, because it is frequently misunderstood and its operational relevance is often overstated at the tactical level. Technical attribution, associating an intrusion with a known threat actor based on tactics, techniques, and procedures (TTPs); infrastructure; and malware characteristics is possible with varying degrees of confidence and is useful primarily for informing the threat model and anticipating likely next steps. An organization that can assess with reasonable confidence that Volt Typhoon is responsible for an intrusion can make better-informed decisions about what systems to prioritize, what persistence mechanisms to hunt for, and what the likely objectives are. Political attribution, the public or legal assignment of responsibility to a state-sponsored actor, is a government function -not a security team function – and attempting it without the intelligence resources to support it creates more risk than it resolves. 

The practical implication for incident response teams is that TTPs and infrastructure indicators should be shared with national authorities and relevant Information Sharing and Analysis Centers (ISACs), who are better positioned to place them in a broader intelligence context. Internal response should focus on containment, scope determination, and recovery regardless of whether attribution is ever formally established. 

Preparing for the long game 

Encountering a state-sponsored actor during incident response is not the time to discover logging gaps, missing baselines, or that the legal team has never discussed intelligence sharing with government agencies. The following sections cover the areas where preparation most directly determines whether detection and response are feasible. 

Logging and visibility 

Default logging configurations are not sufficient for detecting the techniques described above. 

  • Windows process creation (Event ID 4688): Enable full command-line argument logging to track exact parameters used during process execution. 
  • PowerShell script block logging (Event ID 4104): Capture the actual code being executed, not just the fact that PowerShell was launched. 
  • Sysmon: Deploy with a configuration tuned to detect suspicious parent-child process relationships, flagging legitimate binaries used as proxies for malicious activity, both on Windows and Linux environments. 
  • Strategic prioritization: If a full Sysmon rollout is impractical, prioritize critical servers, externally facing web applications, and cloud environments. Deploying Sysmon everywhere is sometimes not feasible due to very extensive and noisy logging. Prioritization is important here. 
  • Centralized log aggregation: Forward all logs to a write-once, centralized location, as sophisticated actors routinely clear local event logs, permanently destroying evidence left on compromised hosts 

More broadly, visibility needs to extend across identity systems, endpoints, network infrastructure, and cloud environments. 

Endpoint telemetry alone is insufficient. State-sponsored actors operating through legitimate tools will generate process events that are difficult to distinguish from normal administrative activity, and network-layer visibility provides an independent detection plane that host-based logging cannot replace. 

  • NetFlow analysis: Connection metadata without payload content is sufficient to identify unusual communication patterns, including beaconing behavior characteristic of C2 channels and lateral movement between systems that have no operational reason to communicate. 
  • DNS logging: Many C2 frameworks rely on DNS for command delivery and exfiltration. A host suddenly querying domains it has never previously resolved, or generating abnormal DNS query volumes, warrantsinvestigation. 
  • Encrypted traffic analysis: Machine learning models can identify C2 communication patterns in TLS sessions without breaking encryption, based on session timing, packet size distributions, and connection frequency. These capabilities do not require deep packet inspection and remain viable where privacy or compliance constraints limit payload visibility. 

Behavioral baselines 

CISA’s joint advisory on living-off-the-land techniques recommends maintaining continuous baselines across network traffic, user behavior, administrative tool usage, and application activity. The emphasis on “continuously” is not incidental. A baseline established once and left unattended can generate more problems than it resolves, creating false confidence that normal has been adequately defined, when in reality theorganization has moved on. Baselines need to reflect seasonal patterns, organizational changes, infrastructure updates, and role transitions. When an administrator changes teams, their access patterns shift. When a new application is deployed, new NetFlow patterns emerge. If the baseline fails to keep pace, genuine threats blend into an outdated picture of normal, and anomaly detection becomes a source of noise rather than signal.

Statistical anomaly detection can surface the low-and-slow deviations characteristic of state-sponsored lateral movement, but tuning is an ongoing commitment, and false positive management carries a real operational cost that should not be underestimated. 

State-sponsored actors do not typically maintain access through malware alone. Once inside, they move through identity infrastructure. Privileged access management deserves explicit treatment: administrative accounts should operate on a tiered model that prevents domain administrator credentials from being exposed on workstations, and service accounts should be scoped to the minimum access their function requires. Detection logic needs to account for credential abuse patterns that do not involve any malicious tooling. Pass-the-hash and pass-the-ticket attacks use legitimate authentication protocols and will not trigger antivirus. Kerberoasting, where an attacker requests service tickets for offline cracking, is visible in Kerberos event logs but only if those logs are collected and someone is looking. Anomalous authentication patterns, such as accounts authenticating at unusual hours, from unusual sources, or against systems they have never previously accessed, are among the more reliable behavioral signals available, provided the baseline exists to contextualize them. 

Operational security (OPSEC) 

If a state-sponsored breach is confirmed, the response needs to assume the adversary can see internal communications. If they have domain admin access, they can likely read email. If they have compromised a collaboration platform, they may be able to see the incident response channel. Here are some of the common aspects that should be considered:  

  • Out-of-band communications: Use encrypted channels on separate, unconnected devices to ensure investigative communications remain outside the compromised infrastructure. 
  • Compartmentalization: Limit knowledge of the investigation to essential personnel only, as each additional person aware of the response is a potential vector for the adversary to detect the investigation. 
  • Pre-established authority contacts: Maintain established relationships with national authorities, CERTs, and intelligence agencies before a crisis occurs, rather than identifying the right contacts during an active incident. 

Organizations should also have a pre-established relationship with national authorities, including the relevant contacts at national CERTs or intelligence agencies, rather than trying to find the right person during a crisis. 

OT and Industrial Control System (ICS) readiness 

For organizations with OT environments, the threat model extends beyond what most IT-centric IR plans address. 

The IT-OT boundary that appears on network diagrams is a logical construct, and state-sponsored actors treat it as a lateral movement path rather than a barrier. Volt Typhoon demonstrated this in concrete terms by moving from compromised IT infrastructure toward OT-adjacent systems, including those controlling water treatment plants and electrical substations. Through 2025, the group progressed from IT reconnaissance to directly interacting with OT network-connected devices and extracting sensor and operational data, representing a transition from passive espionage to what amounts to a sabotage-ready foothold, maintained quietly and positioned for activation when circumstances require it. Important aspects are:  

  • Availability as a safety constraint: OT systems often cannot be taken offline for forensic imaging, as production shutdowns in energy, water, or manufacturing carry significant safety and economic consequences.Investigations must work around live systems. 
  • Patching constraints: Many OT systems run legacy software that cannot be updated without vendor involvement, making virtual patching through IDS/IPS rules the only viable near-term remediation option. 
  • Insufficient software-defined segmentation: IT/OT boundaries relying solely on software-defined controls are inadequate, as a compromised account with sufficient privileges can reconfigure them. 
  • Hardware-enforced unidirectional gateways: Data diodes provide a physical, deterministic guarantee of network separation that cannot be overridden by a compromised account or software misconfiguration. 
  • Regulatory alignment: Both CISA and the UK’s NCSC recommend engineering-based, deterministic protections for OT boundaries as the baseline standard. 

Supply chain readiness 

Vendors, software dependencies, and network infrastructure are all extensions of the trust boundary, and preparing for supply chain compromise means understanding those dependencies and having response procedures ready before one of them is exploited. Some critical measures are as follows: 

  • Software Bill of Materials (SBOM): Maintain an SBOM for all applications and monitor it against vulnerability databases using automated tooling, connected directly to infrastructure. 
  • Vendor access inventory: Map which systems each third party can access, through what mechanisms, and at what privilege level. 
  • Contractual incident notification: Enforce 24-hour disclosure clauses in vendor contracts to ensure timely notification of compromise, preventing containment windows from closing before the organization is aware. 
  • Pre-authorized IR procedures: Define in advance what gets revoked, what gets isolated, and who makes the call for each vendor integration, eliminating delays while an adversary continues to operate. 
  • Firmware inventory: Maintain a firmware inventory with patch status for every network device, including firewalls, routers, switches, and VPN concentrators. 
  • Legacy and end-of-life (EOL) devices: Apply compensating controls such as network isolation, enhanced monitoring, and virtual patching to devices that can no longer receive patches, as they represent supply chain risk sitting inside the perimeter. 

Insider threat readiness 

In the state-sponsored context, the insider threat is not about a disgruntled employee stealing files. It is a structured intelligence operation that uses the hiring process itself as an attack vector, and preparation requires a cross-functional program spanning security, HR, legal, and finance because the indicators span all four domains. 

For planted insiders, the DPRK IT worker scheme being the most documented example, hiring verification needs to go beyond standard background checks. This includes live, multi-stage video interviews with liveness verification that current deepfake technology cannot reliably defeat (for now), digital footprint validation across independent data sources, detection of VoIP phone numbers and shared credentials across applications, and cross-referencing candidate information for the kinds of inconsistencies a fabricated identity cannot fully conceal. 

For all insider categories, behavioral baselines and data loss prevention policies should be in place before an incident occurs. Legal pre-authorization for employee monitoring is also important to establish ahead of time. Trying to build that legal framework during an active investigation will either delay the response or create legal exposure. 

Why your IR plan needs revisiting 

If your current IR plan covers malware and ransomware but typically it does not address supply chain compromise, insider threats, or living-off-the-land techniques. Most IR plans simply reflect a threat landscape that has already shifted. These gaps should be addressed through distinct playbooks, each with its own containment decision trees, evidence collection procedures, legal coordination requirements, and recovery verification steps. Each playbook should be tested through tabletop exercises built around realistic scenarios. 

One aspect of state-sponsored incident response sets it apart from criminal incident response is that the adversary may be observing the response in real time, will likely attempt to regain access after eviction, and the diplomatic, legal, and intelligence dimensions of the incident extend well beyond the security operations center. 

The containment decision in a state-sponsored incident is rarely straightforward. Treating it as a binary choice between immediate isolation and inaction understates the complexity involved. In a criminal incident, early containment is almost always the correct approach. In a state-sponsored incident, premature containment can eliminate the opportunity to understand the full scope of the adversary’s access, forfeit the ability to collect intelligence on their infrastructure, and signal to the adversary that they have been detected. That signal may trigger accelerated action on their objectives before defenses are fully in place. 

The deliberate choice to monitor silently while the adversary operates introduces its own legal, ethical, and operational risks. That decision should never be made unilaterally by the SOC. It requires input from legal counsel and senior leadership, and in many cases a conversation with national authorities before it is exercised. 

The incident response plan should define in advance who holds decision authority over containment timing, what criteria govern the transition from silent monitoring to active containment, and what evidence collection must be completed before containment begins. Tabletop exercises that do not incorporate this decision point are not adequately preparing teams for the reality of state-sponsored incident response. 

Post-incident 

After containment and recovery, the work is not finished. The intelligence collected during the incident has value beyond the organization that was targeted, and sharing it through ISACs and government channels contributes to a broader defensive picture that benefits the entire sector. Internally, the after-action review should map findings to MITRE ATT&CK, not as a compliance exercise but as a structured way to identify where detection failed, where response was too slow, and where controls need to be strengthened. That review should feed directly into updated detection logic, revised access controls, and adjusted monitoring priorities. 

Threat hunting should not stop when the incident is closed. A state-sponsored actor that has been evicted will often attempt to regain access using different infrastructure or modified techniques, and sustained hunting focused on the specific actor’s TTPs is the most reliable way to catch that early. Tabletop exercises should also be updated to reflect what was learned, so the next time a similar scenario plays out, the team is not relearning the same lessons under pressure. 

None of this is new guidance, but in the context of state-sponsored threats, where the adversary is persistent, well-resourced, and likely to return, these activities stop being procedural housekeeping and become direct preparation for the next intrusion. 

Where to start when you have low budget, minimal staff, and competing priorities 

Everything covered above assumes an organization can invest in logging, baselines, segmentation, supply chain controls, and dedicated IR planning in parallel. In reality, most security teams are operating under hiring freezes, flat budgets, and competing priorities, and the guidance to “do all of this” is not actionable without a sense of sequencing. The following is a pragmatic order of operations for teams that need to make meaningful progress without a step-change in resourcing. 

Start with visibility, because you cannot defend what you cannot see. Before buying new tooling, turn on what you already own. Enabling Windows command-line logging (Event ID 4688), PowerShell script block logging (Event ID 4104), and centralized log forwarding costs nothing in licensing and addresses the single largest gap most organizations have. If logs are not being collected and retained centrally, no amount of downstream investment will compensate. 

After this, prioritize identity over endpoints. State-sponsored actors move through credentials, not malware that can be easily fingerprinted, blocked, and made public through sandboxes. Enforcing multi-factor authentication (MFA) on all administrative accounts, implementing tiered admin models, and reviewing service account privileges typically delivers more risk reduction per hour invested than any endpoint initiative. These are configuration changes, not procurement cycles. 

Next, focus monitoring where the adversary has to go. If Sysmon everywhere is not feasible, then deploy it on domain controllers, identity infrastructure, externally facing systems, and critical servers. An adversary pursuing meaningful objectives will eventually touch these systems, and concentrated visibility on them is more valuable than thin visibility everywhere. 

The underlying principle is that state-sponsored readiness is not a single large investment. It is a sequence of smaller decisions where the early ones disproportionately determine whether the later ones are ever useful. Visibility and identity come first. Everything else builds on them.

Cisco Talos Blog – ​Read More

Eyes wide open: How to mitigate the security and privacy risks of smart glasses

Smart glasses allow anyone to track and record the world around them. That could put your data and the privacy of those nearby at risk.

WeLiveSecurity – ​Read More

The Evolution of Kaspersky SIEM | Kaspersky official blog

To put it simply, the classic logic of a SIEM system works as follows: if event A occurs, followed by event B, this may be a sign of an attack, and an information security specialist should be notified. But in today’s environment, this simple scenario is increasingly failing. Just recently, our experts analyzed a high-profile incident: attackers compromised the update infrastructure of the popular Notepad++ software, and distributed malware via the update mechanism. It’s simply impossible to have rules in place in advance that are specifically designed to counter such scenarios.

The attacks themselves have become more sophisticated: attackers use legitimate tools, they attack through the supply chain by compromising software outside the corporate perimeter, stretch out their scenarios over time, and disguise their actions as normal activity. In other words, they do not “break into” the infrastructure; more often than not, they log in and use legitimate software. As a result, the classic fixed rules of the past either fail to trigger, or generate too many false alerts. This is what prompted the shift toward more flexible correlation scenarios.

Dynamically updated SIEM content

Correlation content today isn’t a static set of rules, but a process: it’s constantly evolving and adapting to current threats. In 2025 alone, we released 55 rule-package updates for different versions and languages of our Kaspersky SIEM system. In just one year, we added 10 new rule packs, as well as 250 detection rules and numerous improvements to existing content. This year, we’ve already added 43 new rules and refined another 63. In total, this amounts to over 850 rules covering a significant portion of the MITRE ATT&CK framework.

Kaspersky SIEM rules are written based on insights from our experts who analyze real-world, recent attacks: we primarily draw on the findings of our managed detection and response (MDR) service and our threat research. As a result, our rules cover scenarios — from reconnaissance to privilege escalation — that involve the latest approaches used by attackers. For example, we detect the use of new attack techniques such as ToolShell.

In addition to scheduled updates, the team regularly releases so-called emergency content — rule sets for rapid response to new and unexpected attack techniques. In February, for example, detection rules were released for authentication bypass in Fortinet products via the SSO mechanism: attackers used specially crafted SAML requests to gain access to systems without credentials.

From events to attack chains

Moreover, modern SIEM rules no longer describe individual events, but rather sequences of actions. Scenarios are built around the stages of an attack: from initial access, to privilege escalation and persistence. Kaspersky SIEM’s effectiveness is enhanced through integration with Kaspersky EDR and dedicated rule sets for Active Directory, which implement dozens of attack detection scenarios at various stages. This approach allows us to see not just individual signals, but the full picture.

Integration and internal visibility

Another way to improve the effectiveness of an SIEM system is to expand data sources. A classic SIEM aggregates events from different levels of the infrastructure: from logs to telemetry from endpoints and internal systems. In addition to this, our SIEM system includes specialized rule sets for our other solutions (Kaspersky Security Center, Kaspersky Security for Mail Groups, K Anti-Targeted Attack platform), which allow monitoring of administrator actions, authentication, and service status. As a result, the system becomes a tool not only for detecting attacks, but also for monitoring internal activity.

 

Overall, SIEM is no longer just a set of rules, but has evolved into a continuously updated detection system. Its effectiveness is determined not by the number of detections, but by their relevance, coherence, and how accurately they reflect the actual actions of attackers. Stay up to date regarding our Kaspersky Unified Monitoring and Analysis Platform (SIEM) on its official product page.

Kaspersky official blog – ​Read More

Fixing the password problem is as easy as 123456

How come it’s still possible to ‘secure’ an online account with a six-digit string?

WeLiveSecurity – ​Read More

Fake call logs, real payments: How CallPhantom tricks Android users

ESET researchers uncovered fraudulent apps on Google Play that claim to provide the call history “for any number” and had been downloaded more than seven million times before being taken down

WeLiveSecurity – ​Read More

Unplug your way to better code

Unplug your way to better code

Welcome to this week’s edition of the Threat Source newsletter.

Hey, you. Yeah, you! The person endlessly scrolling or typing away at their computer. Did you touch grass today? It’s just an expression, but if nature’s your thing, that works just fine.

What I do mean is that due to the nature of the field, cybersecurity is incredibly intangible. You can’t reach out and touch your logs, or the packets traversing your network, or the concept of DNS exfiltration… and if you tried, you’d just feel the smooth surface of your computer screen. (What a boring texture.) Spending all our time in the abstract can create some serious mental fatigue.

My point is that there’s something powerful to be said about engaging with the physical world. When we engage in a tactile hobby, we give our brains a hard reset. By moving from the abstract to the physical, our brains get the time and space to process the complex problems we’ve been staring at, often leading to the “aha!” moment that never comes when you’re trying to force it.

The other week, I was working in the Talos office with the Creative team. It was a quiet afternoon, people’s energy sapped by stomachs full of Mediterranean food. That was swiftly interrupted (in the best way) when Joe Marshall came over into our work area with his miniature painting kit, broke it open, and started teaching us how to drybrush 3D-printed figurines. Everyone immediately came alive. While I didn’t partake (I know, “Do as I say, not as I do”), it reminded me of how revitalized I feel when I get outside for a walk during lunch or spend 10 minutes knitting in silence between meetings. There’s nothing to focus on but the feel of the yarn between your fingers, the clacking of the needles, and the repetitive motions that result in a physical object you can wear and fish for compliments about.

Speaking of, do you think the vest I knit is cool? All compliments can be sent to me on LinkedIn, and I refuse to accept any negative comments. (Critiques are fine.)

Unplug your way to better code

Ahem… anyway. Go on a walk without your earbuds, listen to the wind through the leaves, ask a stranger to pet their dog, watch a pigeon bop its head around, and reach out to touch a cool-looking rock or the lichen on a tree. I hear you saying, “That’s some tree-hugging bullshit,” and counter you with, “Just humor me, okay? What’s the worst that could happen?”

If you’re more of an inside person, the goal might be to find a physical anchor for your technical interest. Maybe it’s building a mechanical keyboard from scratch — feeling the weight of the switches and hearing the click of the keycaps. Maybe it’s a complicated LEGO set. Even something as simple as making espresso or organizing your bookshelf can provide that sensory feedback your brain is craving.

If you’re not currently facing a life-altering deadline, take 10 minutes and try it now. The rest of the newsletter isn’t going anywhere, I promise.

When you pay attention to the noises you hear, the colors you see, and the textures under your fingertips, you might come back to your laptop refreshed, focused, and ready to solve the next problem.

The one big thing 

Cisco Talos has recently expanded our threat intelligence capabilities to track phone numbers as critical indicators of compromise (IOCs) in scam emails. Our latest research reveals that attackers heavily favor API-driven VoIP numbers to execute high-volume, cost-effective Telephone-Oriented Attack Delivery (TOAD) campaigns. To evade detection, these threat actors rotate through sequential blocks of numbers, use strategic cool-down periods, and recycle the exact same digits across completely unrelated lures and impersonated brands. 

Why do I care? 

Tracking ephemeral sender email addresses is a losing game, but phone numbers are the true operational anchors for these organized scam call centers. Because attackers reuse these numbers across multiple document types and brand impersonations, defenders who cluster this telephony infrastructure can expose the broader network of malicious activity. Understanding these reuse patterns gives defenders a much-needed edge in mapping out and dismantling these operations before users are manipulated into handing over sensitive data. 

So now what? 

Security teams should shift their focus toward clustering scam lures based on shared phone numbers and prioritize real-time reputation monitoring to flag high-risk infrastructure. Deploying an AI-powered email security solution like Cisco Secure Email Threat Defense can also help evaluate different portions of incoming emails to catch these targeted threats. A full list of indicators of compromise (IOCs) associated with these campaigns can be found in the blog.

Top security headlines of the week 

DigiCert revokes certificates after support portal hack 
The attack, the company said in a detailed report, occurred on April 2, when a threat actor targeted DigiCert’s support team with a malicious payload delivered via a customer chat channel, disguised as a screenshot. (SecurityWeek

Ubuntu services hit by outages after DDoS attack 
The DDoS-for-hire service in this case claims to power attacks in excess of 3.5 Tbps, which is about half of the bandwidth of a cyberattack that Cloudflare last year called the “largest DDoS attack ever recorded.” (TechCrunch

Canvas maker Instructure reveals data breach 
Instructure said the actors accessed “certain identifying information of users” at affected institutions, including names, email addresses, student ID numbers, and user communications. (Tech Radar

Exploitation of “Copy Fail” Linux vulnerability begins 
Threat actors are exploiting a recently disclosed Linux kernel vulnerability leading to root shell access, the US cybersecurity agency CISA warns. Dubbed Copy Fail, the security defect impacts all Linux distributions since 2017. (SecurityWeek

Student hacked Taiwan high-speed rail to trigger emergency brakes 
According to local reports, the student halted four trains for 48 minutes by using software-defined radio (SDR) communications and handheld radios to transmit a high-priority “General Alarm” signal, triggering emergency braking procedures. (BleepingComputer

Can’t get enough Talos? 

Tales from the Frontlines 
In this briefing, we’ll share behind-the-scenes insights from the most critical and high-impact incidents we responded to in the last quarter. This isn’t a report walkthrough; it’s a look at what really happened, how we handled it, and what it means for your organization. 

UAT-8302 and its box full of malware 
Cisco Talos is disclosing UAT-8302, a sophisticated, China-nexus APT group targeting government entities in South America since at least late 2024 and government agencies in southeastern Europe in 2025. 

CloudZ RAT potentially steals OTP messages using Pheno plugin 
Cisco Talos discovered an intrusion, active since at least January 2026, where an unknown attacker implanted a CloudZ remote access tool (RAT) and a previously undocumented plugin called “Pheno.” 

The trust paradox: How attackers weaponize legitimate SaaS platforms 
In this episode of Talos Takes, Amy Ciminnisi sits down with researcher Diana Brown to discuss the rise of “platform-as-a-proxy” (PAP) attacks. 

Upcoming events where you can find Talos 

Most prevalent malware files from Talos telemetry over the past week 

SHA256: 9f1f11a708d393e0a4109ae189bc64f1f3e312653dcf317a2bd406f18ffcc507  
MD5: 2915b3f8b703eb744fc54c81f4a9c67f  
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=9f1f11a708d393e0a4109ae189bc64f1f3e312653dcf317a2bd406f18ffcc507  
Example Filename: VID001.exe  
Detection Name: Win.Worm.Coinminer::1201** 

SHA256: 96fa6a7714670823c83099ea01d24d6d3ae8fef027f01a4ddac14f123b1c9974  
MD5: aac3165ece2959f39ff98334618d10d9  
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=96fa6a7714670823c83099ea01d24d6d3ae8fef027f01a4ddac14f123b1c9974  
Example Filename: d4aa3e7010220ad1b458fac17039c274_63_Exe.exe  
Detection Name: W32.Injector:Gen.21ie.1201 

SHA256: 90b1456cdbe6bc2779ea0b4736ed9a998a71ae37390331b6ba87e389a49d3d59  
MD5: c2efb2dcacba6d3ccc175b6ce1b7ed0a  
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=90b1456cdbe6bc2779ea0b4736ed9a998a71ae37390331b6ba87e389a49d3d59  
Example Filename: APQ9305.dll  
Detection Name: Auto.90B145.282358.in02 

SHA256: e60ab99da105ee27ee09ea64ed8eb46d8edc92ee37f039dbc3e2bb9f587a33ba  
MD5: dbd8dbecaa80795c135137d69921fdba  
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=e60ab99da105ee27ee09ea64ed8eb46d8edc92ee37f039dbc3e2bb9f587a33ba  
Example Filename: u112417.dat  
Detection Name: W32.Variant:MalwareXgenMisc.29d4.1201 

SHA256: a31f222fc283227f5e7988d1ad9c0aecd66d58bb7b4d8518ae23e110308dbf91 
MD5: 7bdbd180c081fa63ca94f9c22c457376  
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=a31f222fc283227f5e7988d1ad9c0aecd66d58bb7b4d8518ae23e110308dbf91  
Example Filename: d4aa3e7010220ad1b458fac17039c274_62_Exe.exe  
Detection Name: Win.Dropper.Miner::95.sbx.tg** 

Cisco Talos Blog – ​Read More