Tuesday, May 12, 2026

New TrickMo Variant Uses TON C2 and SOCKS5 to Create Android Network Pivots

Cybersecurity researchers have flagged a new version of the TrickMo Android banking trojan that uses The Open Network (TON) for command-and-control (C2).

The new variant, observed by ThreatFabric between January and February 2026, has been observed actively targeting banking and cryptocurrency wallet users in France, Italy, and Austria.

"TrickMo relies on a runtime-loaded APK  (dex.module), used also by the previous variant, but updated with new features adding new network-oriented functionality, including reconnaissance, SSH tunnelling, and SOCKS5 proxying capabilities that allow infected devices to function as programmable network pivots and traffic-exit nodes," the Dutch mobile security company said in a report shared with The Hacker News.

TrickMo is the name assigned to a device takeover (DTO) malware that's been active in the wild since late 2019. It was first flagged by CERT-Bund and IBM X-Force, describing its ability to abuse Android's accessibility services to hijack one-time passwords (OTPs).

It's also equipped with a wide range of features to phish for credentials, log keystrokes, record screen, facilitate live screen streaming, intercept SMS messages, essentially granting the operator complete remote control of the device.

The latest versions, labeled TrickMo C, are distributed via phasing websites and dropper apps, the latter of which serve as a conduit for a dynamically loaded APK ("dex.module") that's retrieved at runtime from attacker-controlled infrastructure. A notable shift in the architecture entails the use of the TON decentralized blockchain for stealthy C2 communications.

"TrickMo carries an embedded native TON proxy that the host APK starts on a loopback port at process start," ThreatFabric said. "The bot's HTTP client is wired through that proxy, so every outbound command-and-control request is addressed to an .adnl hostname and resolved through the TON overlay."

Dropper apps containing the malware masquerade as adult versions of TikTok, whereas the actual malware impersonates Google Play Services -

  • com.app16330.core20461 or com.app15318.core1173 (Dropper)
  • uncle.collop416.wifekin78 or nibong.lida531.butler836 (TrickMo)

While previous iterations of "dex.module" implemented the accessibility-driven remote control functionality through a socket.io-based channel, the new version utilizes a network-operative subsystem that turns the malware into a tool for managed foothold than a traditional banking trojan.

The subsystem supports commands like curl, dnslookup, ping, telnet, and traceroute, giving the attacker a "remote shell-equivalent for network reconnaissance from the victim's network position, including any internal corporate or home network the device is currently associated with," per ThreatFabric.

Another important feature is a SOCKS5 proxy that turns the compromised device into a network exit node that routes malicious traffic, while defeating IP-based fraud-detection signatures on banking, e-commerce and cryptocurrency exchange services.

Furthermore, TrickMo includes two dormant features that bundle the Pine hooking framework and declare extensive NFC-related permissions. But neither of them are actually implemented. This likely indicates the core developers are looking to expand on the trojan's capabilities in the future. 

"Instead of relying on conventional DNS and public internet infrastructure, the malware communicates through .adnl endpoints routed via an embedded local TON proxy, reducing the effectiveness of traditional takedown and network-blocking efforts while making the traffic blend with legitimate TON activity," ThreatFabric said.

"This latest variant also expands the operational role of infected devices through SSH tunnelling and authenticated SOCKS5 proxying, effectively turning compromised phones into programmable network pivots and traffic-exit nodes whose connections originate from the victim’s own network environment."



from The Hacker News https://ift.tt/zo0Y2ip
via IFTTT

Veeam High Availability Cluster: failover and automation – Part 2

After creating a Veeam High Availability Cluster, the next step is to verify how the environment behaves when the primary node becomes unavailable. In this part of the series, we walk through a simulated primary node failure and show how to perform a manual failover to the secondary node.

The article then explains how to use Veeam ONE to monitor the HA cluster state, detect primary node communication issues, and configure action handling for a faster recovery workflow. This helps reduce downtime for the Veeam Backup & Replication server and gives administrators better visibility into HA cluster events.

Primary node failure

To test whether the Veeam High Availability Cluster works as expected, you need to take the Primary Node offline by simulating a failure.

From the vSphere Client, power off the Primary Node of the Veeam High Availability Cluster. Right click the Primary Node and select Power > Power off.

 

wp-image-34101

 

Ensure the connection is lost from the Veeam Backup & Replication Console.

 

wp-image-34102

 

Manual failover of the Veeam High Availability Cluster

Once the Primary Node has failed, close and re-open the Veeam Console. The process takes about 10 minutes to complete the failover.

Enter the IP Address of the HA Cluster and click Connect. You cannot initiate a failover using the cluster DNS name.

 

wp-image-34104

 

The new certificate thumbprint is detected. Click Yes to trust the server.

 

wp-image-34105

 

The system detects the Primary Node has failed. Click Connect to connect to the Secondary Node.

 

wp-image-34106

 

Enter the credential to login to the Secondary Node and click Sign in.

 

wp-image-34107

 

Click Failover.

 

wp-image-34108

 

The system attempts to connect the cluster through the Secondary Node.

 

wp-image-34109

 

The Veeam Console now opens showing a warning about the missing Secondary Node in the HA Cluster. The previously configured Secondary Nodes has assumed the Primary Node role after failover.

 

wp-image-34111

 

Automate failover operation with Veeam ONE

Although manual failover is a simple task to perform, an automated failover process can be a better and more efficient option to maintain protection for mission-critical VMs.

 

wp-image-34112

 

To automate the failover operation for a Veeam High Availability Cluster, Veeam ONE must be installed in your infrastructure. Make sure Veeam ONE is installed and configured.

Enable monitoring in the Veeam appliance

To configure automated failover, you need to register the two Veeam 13 Appliances in Veeam ONE. To allow correct registration with Veeam ONE, you need to enable Data Collection from the Veeam Host Management Console.

Using your preferred browser, type the address https://<Veeam_Primary_Node>:10443. Enter the veeamadmin credentials and click Sign in.

 

wp-image-34113

 

Go to Backup Infrastructure and click Submit Request in the Data Collection section.

 

wp-image-34114

 

Click OK.

 

wp-image-34115

 

The request is placed in Waiting for approval status. Click veeamadmin > Sign out to logoff the current user.

 

wp-image-34116

 

Enter the veeamso (security officer) credentials and click Sign in.

 

wp-image-34117

 

Select the pending request and click Approve.

 

wp-image-34118

 

Once the request has been approved, click veeamso > Sign out.

 

wp-image-34119

 

Login again with the veeamadmin account to verify the request is displayed as Request Approved.

 

wp-image-34120

 

Before proceeding with the configuration of Veeam ONE, repeat the same procedure for the Secondary Node.

Register Veeam Nodes in Veeam ONE

Access the Veeam ONE server and login to the Veeam ONE Web Client.

 

wp-image-34121

 

In the Overview tab, click Data Source > Add server.

 

wp-image-34122

 

Select Veeam Backup & Replication.

 

wp-image-34123

 

Enter the DNS name or IP Address of the Primary Node then click Next.

 

wp-image-34124

 

Click Add credentials to specify the user for authenticating against the Primary Node.

 

wp-image-34125

 

Select Standard account.

 

wp-image-34126

 

Specify the veeamadmin credentials and click Finish.

 

wp-image-34127

 

Make sure veeamadmin is seleted in the Credentials drop-down menu and click Next.

 

wp-image-34128

 

Click Trust and Continue to accept the certificate.

 

wp-image-34129

 

Click Finish to register the Primary Node.

 

wp-image-34130

 

The system detects the node members of the cluster and starts installing the required agents.

 

wp-image-34131

 

After a few seconds, the agents are installed successfully.

 

wp-image-34132

 

Configure automated failover

Now login to Veeam ONE Client and click Connect to proceed with the configuration of the automated Veeam High Availability Cluster failover.

 

wp-image-34133

 

Go to the Alert Management area and select Veeam Backup & Replication. In the Filter box type ha cluster to filter HA cluster options.

 

wp-image-34134

 

Right click Veeam Backup & Replication HA cluster primary node state and select Edit.

 

wp-image-34135

 

Navigate to the Action section and select Automatic in the Execution type drop-down menu. Clic Save to save the configuration.

 

wp-image-34136

 

Test automated failover

From the vSphere Client, Power Off the Veeam Primary Node (veeam-v13sa in the example).

 

wp-image-34137

 

The Veeam Console loses the connection with the Primary Node.

 

wp-image-34138

 

In the Veeam ONE Client, go to the Veeam Backup & Replication section and click on the grayed-out Primary Node. In the Alarms tab of the right pane, the failure of the node is detected.

 

wp-image-34139

 

The system requires about 10 minutes to complete the automated failover operation. When the failover is completed, the Secondary Node assumes the role of Primary Node restoring the Veeam Server functionality.

 

wp-image-34140

 

Leveraging the Veeam ONE’s capability to trigger an automated failover when the Primary Node fails allows you to maintain maximum efficiency of the Veeam Backup Server, limiting the service outage to just a few minutes.



from StarWind Blog https://ift.tt/2NQGqeS
via IFTTT

Webinar: What the Riskiest SOC Alerts Go Unanswered - and How Radiant Security Can Help

Why do the Riskiest SOC Alerts Go Unanswered?

Security operations teams are drowning in alerts. But the real problem isn't always alert volume; it's the blind spots. The most dangerous alerts are the ones no one is investigating.

A recent report from The Hacker News examined why certain high-risk alert categories - WAF, DLP, OT/IoT, dark web intelligence, and supply chain signals- consistently go uninvestigated across enterprise SOCs. The findings point to a structural gap in how security coverage is delivered today: not a lack of tooling, but a ceiling built into every existing model.

Your SOC Model Has a Coverage Ceiling

In-house SOC teams are the first to feel the gap. Overloaded with high-volume, routine alerts, analysts rarely have the capacity, or the specialized expertise, to investigate WAF events, DLP anomalies, or signals from operational technology environments. These alert types require deep, domain-specific knowledge that most SOC teams simply don't have on staff.

MSSPs and MDRs face a different version of the same problem. Complex, specialized alerts are time-consuming to investigate and require business context that managed providers don't have. The economics don't work in their favor, so they escalate these alerts back to the client, the same in-house team that lacked the capacity to investigate them in the first place.

AI SOC automation platforms have made significant progress on common alert types, but most cap out at four to six pre-defined categories. They rely on static, pre-built triage logic. When an alert falls outside that logic, whether it's a novel threat, an unfamiliar alert source, or an emerging attack vector, the platform deprioritizes it or passes it on.

The result is a blind spot at the intersection of all existing SOC models: the alerts most likely to result in a breach are precisely the ones for which no one has a workflow to handle.

Who Offers True Coverage

On May 21, 2026, Radiant Security and German cybersecurity firm Cirosec are hosting a technical webinar to address this gap directly: "Alert Coverage No One Else Can Triage."

The session will examine the structural reasons behind the coverage ceiling, walk through the specific alert types most commonly left uninvestigated, and demo live how Radiant's AI SOC platform triages them.

Radiant is built on a fundamentally different architecture than other AI SOC platforms. Rather than relying on pre-built playbooks, its AI generates custom triage logic on the fly, for any alert type, including ones the platform has never seen before. 

Webinar Details

  • Date: May 21, 2026
  • Time: 15:00 CEST (6:00 AM PDT)
  • Format: Microsoft Teams — technical, interactive session
  • Host: Cirosec & Radiant Security
  • Language: English

Register here to register (click translate page to English on your browser translator)

Important note: the webinar will be in English.

Found this article interesting? This article is a contributed piece from one of our valued partners. Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.



from The Hacker News https://ift.tt/6mIVF9A
via IFTTT

Why Agentic AI Is Security's Next Blind Spot

Agentic AI is already running in production environments across many organizations today. It is executing tasks, consuming data, and taking actions — most likely without meaningful involvement from the security team. The industry conversation has largely framed this as a question of policy: allow it, restrict it, or monitor it? However, that framing misses the point. 

The more urgent question is whether security professionals actually understand what they are dealing with. In most organizations, they don't right now. And that gap is compounding by the week.

You cannot secure what you do not understand

The foundational principle of information security has not changed: genuine fluency in a technology must come before you can meaningfully defend it.

Think about firewalls. You cannot configure one well without understanding networking. When cloud computing arrived, organizations that skipped the foundational work ended up with environments they could not reason about — tools purchased, policies written, and still no real control. We have cloud security as its own discipline today precisely because the technology demanded that practitioners develop deep familiarity with it before security could follow.

The same dynamic is playing out with AI, at a faster pace and with higher stakes.

The practical consequence of being behind on agentic AI goes beyond technical exposure. Security teams that cannot speak the language of AI engineering — that cannot challenge design decisions, propose workable controls, or ask informed questions — get bypassed. Business units move forward without them, not out of bad faith, but because a security team that cannot engage substantively with the technology is not a useful partner for decisions about it. This has played out with every major technology shift over the past two to three decades. AI will be no different.

The starting point is engagement. Try building an agent. Experiment with the tools your developers are already using. This hands-on familiarity is where real understanding begins, and real understanding is what makes everything else possible.

Three categories of agents, three categories of risk

The agentic AI landscape is broad, and the risk profile varies significantly across it. Three categories are worth understanding distinctly.

The first is general-purpose coding and productivity agents — tools like Claude Code and GitHub Copilot. These are already embedded in developer and engineering workflows across your organization. Whether they have been formally approved or not, they are being used. What data they can access, how they interact with codebases, and what actions they can take is baseline security knowledge at this point.

The second is vendor-built agents powered by the Model Context Protocol, or MCP. MCP is the integration layer that allows agents to connect to external services and act on their behalf. Nearly every major vendor either has an MCP server in production or is actively building one. In practice, this means an agent managing a user's calendar, email, or internal ticketing system can receive input from those channels and act on it. A malicious calendar invite carrying hidden instructions in the event description is a real attack vector — the agent reads it, interprets the embedded prompt, and executes. This is a live attack surface that requires deliberate configuration and security review.

The third category is custom agents built by individual users, and this is where the dynamic gets particularly interesting. For years, a real barrier existed between security practitioners who understood risk and the code that ran in their environments. Most security professionals are not programmers. Building custom tooling required development skills that were not widely distributed across security teams.

That barrier is gone.

With agentic AI, anyone in the organization can build functional tools — automations, workflows, agents with real system access — without writing traditional code. For security teams, this is genuinely valuable. Incident investigation, forensic triage, threat hunting workflows — these can be accelerated when practitioners can build the tools they actually need. But that same capability extends to every other team. Marketing, finance, operations — everyone can build agents now. Many will. Most of those agents will not go through a security review before they go live. This is a supply chain problem in a different form.

The cost of arriving late

When security teams lag behind on a major technology shift, the pattern is consistent.

First, the rest of the organization moves forward without security input. Developers deploy, business units adopt, and security is consulted as a formality — or not at all. Second, the exposure compounds. The more powerful the agents an organization deploys, the more access those agents require. Broad permissions are what make agents useful: access to calendars, communication platforms, file systems, code repositories, internal APIs. That access is also what makes the blast radius significant when something goes wrong.

An agent with access to both a terminal and an email inbox can be manipulated through either channel to act in the other. That is a lateral movement path an attacker will look for. Reasoning about it requires understanding how the agent was built — the kind of understanding that only comes from genuine engagement with the technology.

The skills that matter right now

Building competency in agentic AI security requires two distinct layers of knowledge.

The first is understanding how AI applications are architected — from a practitioner's perspective, not a data scientist's. What are the components of an AI application? How do agents consume inputs, chain tools together, and produce outputs? What does a session with an MCP-connected agent actually look like from an access control standpoint? This is the foundation that makes everything else actionable.

The second layer is currency. The tooling and threat landscape around AI is moving fast. Vendors are building security controls for AI systems, though most are still maturing. Open-source frameworks are emerging. OWASP and others are publishing threat taxonomies that evolve week to week. Once the foundational layer is in place, staying current becomes the ongoing discipline — knowing which tools are worth evaluating, which frameworks are gaining traction, and what questions to ask when vendors come in with solutions.

That second point matters more than it might seem. Security teams are already being approached by vendors selling AI security products. Without foundational knowledge of how these applications are built, those conversations are almost impossible to navigate well. You cannot distinguish a well-designed control from a marketing wrapper if you don't understand what you're trying to control.

Configuration as a security control

Many agentic AI deployments carry risk because they were stood up without security-conscious configuration — not because the underlying tools are fundamentally broken.

Take a self-hosted AI assistant connected to a communication channel like Telegram, which can be common. without proper controls, the agent could respond to anyone who messages it. That is a wide-open entry point. A simple configuration change — pairing the agent with a single trusted account — closes most of that exposure. One decision, made early, with a meaningful security outcome.

The broader principle is scope. An agent built to manage your calendar should not have access to your terminal. An agent processing incoming requests should not have write access to your code repository. Scoping agents to their intended function limits the blast radius and reduces the attack surface available for exploitation.

The tension is real: powerful agents need broad access to be useful. That is the trade-off organizations will push back on. Finding the right balance requires security involvement early in the design process — before the architecture is set and before the permissions are already in place.

Getting ahead of it at SANSFIRE 2026 

The organizations building genuine AI security fluency now will be positioned to shape how these systems are deployed. Those who arrive late will find themselves, once again, applying controls to an architecture that was already decided without them.

This July, I will be teaching SEC545: GenAI and LLM Application Security at SANSFIRE 2026. The course covers how AI applications are actually built, how agentic systems work in practice, the real attack surfaces security teams need to understand, and the tools and controls available to address them — including hands-on work with techniques like model scanning to detect compromised models before they run in your environment. For practitioners who want to engage with AI systems from a foundation of real understanding, this is where to start. 

Register for SANSFIRE 2026 here.

Note: This article has been expertly written and contributed by Ahmed Abugharbia, SANS Certified Instructor.

Found this article interesting? This article is a contributed piece from one of our valued partners. Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.



from The Hacker News https://ift.tt/l91cKon
via IFTTT

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.



from Cisco Talos Blog https://ift.tt/bYhAndX
via IFTTT

Mini Shai-Hulud Worm Compromises TanStack, Mistral AI, Guardrails AI & More Packages

TeamPCP, the threat actor behind the recent supply chain attack spree, has been linked to the compromise of the npm and PyPI packages from TanStack, UiPath, Mistral AI, OpenSearch, and Guardrails AI as part of a fresh Mini Shai-Hulud campaign.

The affected npm packages have been modified to include an obfuscated JavaScript file ("router_init.js") that's designed to profile the execution environment and launch a comprehensive credential stealer capable of targeting cloud providers, cryptocurrency wallets, AI tools, messaging apps, and CI systems, including Github Actions, Aikido Security, Endor Labs, SafeDep, Socket, and StepSecurity said. The data is exfiltrated to the "filev2.getsession[.]org" domain.

Using Session Protocol infrastructure is a deliberate attempt on the part of the attackers to evade detection, as the domain is unlikely to be blocked within enterprise environments, given that it belongs to a decentralized, privacy-focused messaging service. As a fallback option, the encrypted data is committed to attacker-controlled repositories under the author name "claude@users.noreply.github.com" via the GitHub GraphQL API using the stolen GitHub tokens.

The malware is also capable of establishing persistence hooks in Claude Code and Microsoft Visual Studio Code (VS Code) to survive reboots and re-execute the stealer on every launch of the IDEs.

Furthermore, it installs a gh-token-monitor service to monitor and re-exfiltrate GitHub tokens, and injects two malicious GitHub Actions workflows to serialize repository secrets into a JSON object and upload the data to an external server ("api.masscan[.]cloud"). 

TanStack has since traced the compromise to a chained GitHub Actions attack involving the "pull_request_target" trigger, GitHub Actions cache poisoning, and runtime memory extraction of an OIDC token from the GitHub Actions runner process. "No npm tokens were stolen, and the npm publish workflow itself was not compromised," TanStack said.

Specifically, the attackers are assessed to have staged the malicious payload in a GitHub fork, injected it into published npm tarballs, then hijacked the project's legitimate "TanStack/router" workflow to publish the compromised versions with valid SLSA provenance. 

What makes the worm stand out is its ability to spread itself to other packages by locating a publishable npm token with bypass_2fa set to true, enumerating every package published by the same maintainer, and exchanging a GitHub OIDC token for a per-package publish token to sidestep traditional authentication entirely.

The TanStack supply chain compromise has been assigned the CVE identifier CVE-2026-45321. It carries a CVSS score of 9.6 out of a maximum of 10.0, indicating critical severity. The incident has impacted 42 packages and 84 versions across the TanStack ecosystem.

"The attack published malicious versions through the project's own GitHub Actions release pipeline using hijacked OIDC tokens," StepSecurity researcher Ashish Kurmi said.

"In an extremely rare escalation, the compromised packages carry valid SLSA Build Level 3 provenance attestations, making this the first documented npm worm that produces validly attested malicious packages. The worm has since spread beyond TanStack to packages from UiPath, DraftLab, and other maintainers."

Besides TanStack, the Mini Shai-Hulud campaign has also spread to several other packages, including some in PyPI -

  • guardrails-ai@0.10.1 (PyPI)
  • mistralai@2.4.6 (PyPI)
  • @opensearch-project/opensearch@3.5.3, 3.6.2, 3.7.0, and 3.8.0
  • @squawk/mcp@0.9.5
  • @squawk/weather@0.5.10
  • @squawk/flightplan@0.5.6
  • @tallyui/connector-medusa@1.0.1, 1.0.2, and 1.0.3
  • @tallyui/connector-vendure@1.0.1, 1.0.2, and 1.0.3

Microsoft, in its analysis of the malicious mistralai PyPI package, said it's designed to download a credential stealer from a remote server ("83.142.209[.]194") that includes country-aware logic to avoid Russian-language environments and a "geofenced destructive branch that has a 1-in-6 chance of executing rm -rf / when the system appears to be in Israel or Iran."

"The guardrails-ai@0.10.1 compromise is especially notable because the malicious code executes on import," Socket said. "The package checks for Linux systems, downloads a remote Python artifact from https://ift.tt/0wvSjJy, writes it to /tmp/transformers.pyz, and executes it with python3 without integrity verification."

"This latest activity shows the campaign continuing to propagate across both npm and PyPI, with affected packages spanning search infrastructure, AI tooling, aviation-related developer packages, enterprise automation, frontend tooling, and CI/CD-adjacent ecosystems."



from The Hacker News https://ift.tt/8Y2TOyC
via IFTTT