Chinese-Speaking APT Deploys New TinyRCT Backdoor in Southeast Asia Campaign

A Chinese-speaking advanced persistent threat (APT) actor has been linked to a new custom backdoor called TinyRCT as part of cyber attacks aimed at government entities and critical infrastructure in Southeast Asia.

The activity, particularly aimed at state-owned enterprises in the energy and government sectors, has been attributed to a threat actor called CL-STA-1062, which Palo Alto Networks Unit 42 said shares overlaps with UAT-7237, a hacking group that was first flagged by Cisco Talos in August 2025 in relation to a campaign directed against web infrastructure entities in Taiwan.

Unit 42 said it also observed CL-STA-1062 campaigns in prior operations targeting strategic sectors in East Asia since March 2022, suggesting a broader but sustained focus in the region.

"From a technical standpoint, the attackers behind CL-STA-1062 rely on a hybrid toolkit," Unit 42 said in a technical report. "While they frequently use common open-source tools such as SoftEther VPN, Mimikatz, and VNT, they have recently introduced TinyRCT, a bespoke, previously undocumented backdoor."

TinyRCT is equipped to run arbitrary commands, enumerate files and exfiltrate them, capture the device's screen, and delete itself from the compromised host.

In one campaign detected in September 2025, the threat actor is said to have infiltrated a Southeast Asian government entity and deployed a web shell to exfiltrate data from an MS SQL server. During the same attack, the threat actors have been found to conduct network reconnaissance on a separate government entity in the same country.

"This suggests an effort to identify lateral movement opportunities and broaden their access. In one case, we observed the attacker staging and exfiltrating an entire directory of web server source code from the government entity," Unit 42 said, adding it detected the breach of at least 10 different organizations in Southeast Asia between October and December 2025.

Since at least mid-2025, CL-STA-1062 has trained its sights on the critical infrastructure, with the adversary scanning multiple entities in the region for vulnerabilities and then establishing a foothold via ASPX web shells that facilitate initial reconnaissance and outbound requests from the infected networks to attacker-controlled infrastructure, leading to the deployment of additional payloads.

This includes SoftEther VPN components and RAR archives containing the group's toolset, including open-source utilities such as Yuze (a SOCKS5 proxy) and VNT (a VPN), often disguising them as VMware executables or an XDR agent (e.g., "XDRAgent.exe," "vmtools.exe," and "vmwared.exe").

Further analysis of the campaign's infrastructure has led to the discovery of a previously undocumented .NET backdoor dubbed TinyRCT ("PerfWatson2.exe"), a lightweight remote access trojan that enables system reconnaissance, command execution, file uploads, screenshot capture, remote control, and wipe traces of itself, while taking steps to avoid running in sandboxed environments.

It establishes a persistent communication channel with a remote server ("45.32.113[.]172") over HTTP, but encrypts the exchanged data using AES-128 encryption in CBC mode.

"The malware operates on a beaconing model, with a default 10-second sleep interval between requests," Unit 42 explained. "It polls the C2 server for instructions using GET requests, while it sends exfiltrated data via POST requests."

As for how TinyRCT is delivered, it takes the form of a malicious archive named "chrome_setup.zip" containing a legitimate executable ("chrome_setup.exe"), a configuration file ("chrome_setup.exe.config"), and a rogue DLL ("MyAppDomainManager.dll") that's used to trigger an AppDomainManager injection attack to load the malicious DLL, which functions as a downloader by contacting "139.180.134[.]221" to retrieve "PerfWatson2.exe."

"The combination of tools observed in this activity cluster reflects a pragmatic approach to tool selection and attack capabilities," Unit 42 concluded. "The attackers behind this cluster continue to leverage common open-source tools such as SoftEther VPN and VNT to facilitate lateral movement."

"Our discovery of the TinyRCT backdoor in the attackers' infrastructure underscores their ability to customize tools to gain specific capabilities. The combination of targeting critical infrastructure and the development of custom malware suggests that CL-STA-1062 activity will continue to pose a threat to the region."

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

Terraform MCP server: Four real-world AI infrastructure patterns

AI is rapidly becoming the new operational interface for infrastructure. What once required deep expertise in Terraform, cloud platforms, security policies, and operational workflows can now begin with a simple prompt. Platform engineering and DevOps teams are increasingly experimenting with AI agents to accelerate provisioning, automate governance, simplify operations, and improve developer productivity. 

However, organizations face a fundamental challenge when adopting AI for infrastructure operations. Large language models (LLMs) are inherently non-deterministic systems. While they can dramatically improve productivity, they can also produce incomplete, inconsistent, or misleading responses. In infrastructure environments where security, compliance, cost management, and operational reliability are critical, relying solely on an LLM’s general knowledge can introduce significant risk. 

This is where the Terraform MCP server becomes transformational. Rather than allowing AI agents to operate based solely on training data and probabilistic reasoning, MCP provides authoritative context directly from Terraform workflows, modules, policies, workspaces, and infrastructure configurations. It grounds AI agents in the organization’s actual infrastructure standards and operational practices, helping reduce hallucinations, improve decision quality, and ensure recommendations are based on real infrastructure data rather than assumptions. 

The result is not simply faster automation. It is a more reliable and trustworthy operating model for AI-assisted infrastructure management. Throughout this article, we’ll explore four common patterns where engineering teams are using the Terraform MCP server to help AI agents make better decisions, reduce operational risk, and deliver value across the infrastructure lifecycle. 

Pattern 1: No-code infrastructure workflows for platform consumption

Summary

The Terraform MCP server extends the reach of no-code modules by introducing a new AI-driven entry point for infrastructure consumption. Organizations may already expose no-code modules through self-service platforms such as Waypoint, ServiceNow, Harness, or internal developer portals. With MCP, those same no-code modules become accessible through AI agents that can discover available modules, explain their purpose, guide users through required inputs, and help validate deployment outcomes using natural language interactions. 

Instead of requiring newly onboarded engineers to immediately learn complex Terraform implementations or navigate multiple self-service systems, organizations can use MCP-enabled AI workflows to provide a conversational experience around approved no-code infrastructure patterns. Engineers can ask questions, test modules, troubleshoot deployment issues, and understand infrastructure behavior through an AI assistant while continuing to leverage the same approved no-code modules and governance controls already established by the platform team. 

User scenario

A newly hired DevOps engineer joins a platform engineering organization that manages standardized infrastructure across multiple cloud environments. The organization already provides approved no-code modules for common infrastructure patterns such as Kubernetes clusters, networking, observability stacks, and application environments. 

Rather than giving the engineer direct responsibility for modifying production Terraform code, the platform team starts onboarding with controlled testing workflows using no-code modules. The engineer is asked to validate and test a newly released non-production Kubernetes no-code module before it is rolled out more broadly to development teams. 

Using an AI assistant powered by the Terraform MCP server, the engineer asks: 
“Test the no-code module terraform-aws-eks-standard in the dev environment and validate whether the module follows organizational standards.” 

MCP server response sample: 

Sample source code generated by the MCP server: 

The MCP-enabled AI agent understands the no-code module configuration, retrieves the module contract, validates required inputs and outputs, executes Terraform validation and speculative plans, runs tflint checks, and analyzes deployment results automatically. During testing, the AI agent explains what the module is deploying, identifies validation failures, interprets Terraform plan results, and recommends remediation steps when configuration issues are detected. 

The engineer can safely learn Terraform workflows, infrastructure standards, and deployment patterns through guided AI-assisted testing rather than manually navigating large Terraform repositories or complex cloud configurations. Over time, the engineer develops a deeper understanding of Terraform operations while contributing meaningful validation work to the platform engineering team. 

Benefits

This approach provides organizations with a safer and more scalable onboarding model for platform engineering and DevOps teams. New engineers can begin contributing immediately through guided testing workflows while learning infrastructure standards incrementally instead of being overwhelmed by complex Terraform implementations on day one. 

For platform engineering teams, MCP-enabled AI agents reduce onboarding overhead, improve consistency in module validation, and help standardize operational workflows around no-code infrastructure patterns. For engineering leadership, this creates a practical pathway for scaling Terraform adoption across teams while reducing skills gaps, operational risk, and dependency on a small number of Terraform experts. 

Pattern 2: Self-service infrastructure with Private Module Registry

Summary

As organizations mature their Terraform adoption, the next challenge becomes standardization and scalability. The Terraform MCP server enables AI agents to leverage the private module registry as a curated catalog of approved infrastructure patterns. Instead of manually building infrastructure from scratch, AI agents can discover modules, understand their contracts, compose configurations, and validate deployments automatically. 

This capability extends across both Day 1 and Day 2 operations. On Day 1, AI agents help teams rapidly deploy compliant infrastructure using approved modules. On Day 2, AI assists with module lifecycle management, provider upgrades, breaking change analysis, validation testing, and operational maintenance. 

User scenario

After a few weeks, the DevOps engineer becomes more comfortable with Terraform workflows and starts contributing directly to development environment deployments. However, the organization operates across multiple cloud accounts and business units, making consistency increasingly difficult to maintain. Different teams are deploying slightly different versions of networking, Kubernetes, and observability configurations, creating operational drift and governance challenges. 

To address this, the platform engineering team standardizes infrastructure delivery through approved Terraform modules stored in the organization’s private module registry. When the engineer needs to deploy a new application environment, they work with an MCP-enabled AI assistant that can discover and understand the organization’s approved modules, their inputs and outputs, and the intended deployment patterns. 

The engineer asks: 

Build a compliant development environment using approved modules terraform-aws-eks-standard, rds, redis-ec2, and route53-subdomain from the private module registry.

MCP server response: 

Sample source code generated by the MCP server: 

The AI agent identifies the appropriate networking, Kubernetes, and observability modules from the private module registry and generates a compliant Terraform configuration. It then performs iterative validation throughout the workflow, executing Terraform validate, plan, and tflint checks, while specialized AI reviewers can perform security and code quality reviews before changes move through CI/CD approval gates. 

Later, when the platform team releases updated module versions and provider upgrades, the DevOps engineer uses the MCP-enabled AI assistant to evaluate the impact of the changes on existing environments. Depending on the organization’s AI tooling maturity, this may involve prompting the AI assistant to analyze compatibility, identify potential breaking changes, test upgrade scenarios, and recommend remediation steps. Organizations that invest in specialized agents and workflows can further automate portions of this analysis, reducing the operational burden associated with module and provider lifecycle management. 

Rather than manually reviewing hundreds of Terraform configurations, the platform team can use AI-assisted workflows to scale infrastructure operations more safely and efficiently while maintaining consistency across environments. 

Benefits

This model enables organizations to achieve velocity without governance trade-offs. Infrastructure becomes standardized through validated golden patterns while remaining highly consumable for application teams. AI-assisted workflows reduce operational burden associated with provider upgrades, module lifecycle management, and compliance validation. 

For platform engineering organizations, this creates a scalable self-service operating model. Application teams can provision infrastructure using natural language workflows, while platform teams maintain centralized governance, auditability, and operational consistency through approved modules and validation pipelines.   

Pattern 3: Policy enforcement and governance with Sentinel or OPA

Summary

As infrastructure consumption accelerates, governance becomes increasingly critical. The Terraform MCP server enhances policy as code workflows by helping AI agents understand organizational governance requirements and apply them throughout the infrastructure lifecycle. Rather than treating policy enforcement as a reactive step after Terraform execution, organizations can use MCP-enabled AI workflows to assist both policy authors and infrastructure consumers. 

Most organizations standardize on either Sentinel or OPA depending on their existing tooling, operational model, and engineering preferences. Regardless of the policy framework, the Terraform MCP server helps AI agents understand policy requirements, assist with policy development and testing, and provide actionable feedback when infrastructure changes violate organizational guardrails. 

User scenario

As cloud adoption expands across the enterprise, the security and compliance teams begin raising concerns around governance consistency. Different application teams are deploying resources across multiple cloud providers and regions, increasing the risk of non-compliant configurations, excessive spending, and operational drift. 

A lead platform architect is tasked with implementing organization-wide governance using either Sentinel or OPA. However, translating security and compliance requirements into policy as code can be time-consuming and often requires specialized expertise. 

Using the Terraform MCP server, the architect works with an AI assistant to accelerate policy development. The architect provides high-level requirements such as: 

• Restrict deployments to approved regions 

• Enforce mandatory tagging 

• Ensure encryption is enabled 

• Prevent public exposure of SSH and RDP 

• Apply cost control policies for non-production environments 

The AI assistant helps generate initial Sentinel or OPA policies, explains policy logic, assists with policy testing, and validates that policies behave as intended before they are promoted into production policy sets.  

Once governance policies are established, application and DevOps teams encounter them through their normal Terraform workflows. A DevOps engineer deploying a new application environment may generate a Terraform configuration that violates one or more organizational policies. During policy evaluation, the Terraform run reports failures related to missing tags, unencrypted resources, prohibited regions, or other governance requirements. 

Instead of manually investigating the failures, the engineer works with an MCP-enabled AI assistant and asks: 

Analyze the policy failures, explain the violations, update the Terraform configuration to satisfy the policies, rerun validation and policy checks, and summarize the required changes.

MCP server response sample: 

Sample source code generated by the MCP server: 

The AI assistant reviews the Terraform plan, explains the policy violations, updates the Terraform configuration, and guides the engineer through an iterative workflow of validation, policy evaluation, and remediation. The process continues until a compliant configuration is produced and ready for deployment. 

Over time, the organization evolves toward continuous compliance, where policy development, infrastructure generation, and governance validation operate together as an integrated workflow rather than independent processes. 

Benefits

This approach significantly reduces policy violations, deployment friction, and operational risk. Security teams gain centralized governance, auditability, and consistent policy enforcement across multi-cloud environments while reducing the effort required to create and maintain policy sets. 

Engineering teams benefit from faster feedback loops and less time spent diagnosing policy failures. Rather than treating governance as a downstream blocker, teams can use AI-assisted workflows to understand, remediate, and validate policy compliance earlier in the delivery process. 

For executives and technical leaders, this creates a more intelligent governance model where automation and compliance reinforce each other. The result is stronger security and regulatory posture without sacrificing developer productivity or delivery velocity. 

Pattern 4: Simplifying infrastructure at scale with Terraform Stacks

Summary

As organizations scale globally, managing infrastructure across multiple environments, regions, and accounts becomes increasingly complex. Terraform Stacks introduce a higher-level orchestration layer that simplifies dependency management and infrastructure coordination. Combined with the Terraform MCP server, AI agents can reason about complete systems instead of isolated Terraform resources or modules. 

This enables organizations to standardize and orchestrate landing zones, Kubernetes platforms, networking, security baselines, and application environments at enterprise scale. 

User scenario

A global enterprise platform engineering team is tasked with building standardized landing zones across multiple business units and cloud providers. The organization operates across AWS, Azure, and GCP environments with strict security, compliance, and networking requirements. Historically, platform teams managed dozens of Terraform workspaces independently, requiring manual coordination for deployments and updates. 

The lead platform engineer adopts Terraform Stacks together with the Terraform MCP server to simplify orchestration at scale. Using AI-assisted workflows, the engineer defines reusable Stack configurations for networking, identity, Kubernetes clusters, observability tooling, and security baselines. 

When the organization expands into a new region, the engineer requests: 

“Deploy the approved landing zone architecture with regional requirements using Terraform Stacks.”

MCP server response sample: 

Sample source code generated by the MCP server: 

The MCP-enabled AI agent provisions the full stack, coordinates dependencies automatically, and applies standardized configurations consistently across environments. Future updates to shared services such as networking or observability can then be rolled out globally using controlled orchestration rules without duplicating Terraform code or manually coordinating deployments. 

Instead of spending weeks managing dependencies and repetitive configurations, platform teams can focus on higher-value architecture and operational improvements. 

Benefits

Terraform Stacks combined with MCP enable organizations to scale infrastructure operations globally while dramatically reducing operational overhead. Infrastructure becomes easier to replicate, easier to manage, and more consistent across regions and environments. 

For CIOs, CTOs, and platform engineering leaders, this provides a scalable foundation for enterprise platform engineering. Teams can accelerate global expansion, improve deployment consistency, and reduce the complexity traditionally associated with multi-environment infrastructure orchestration.   

Final thoughts

The Terraform MCP server is more than an AI integration layer. It represents a fundamental evolution in how organizations design, consume, govern, and scale infrastructure. By introducing structured context, governance, and operational intelligence into AI-assisted workflows, MCP enables enterprises to operationalize AI safely while improving developer productivity and platform efficiency. 

Across these four patterns, a common theme emerges: Successful organizations are not simply using AI to automate tasks. They are using AI to redefine the operating model for infrastructure itself. Developers express intent in natural language, AI agents translate that intent into compliant infrastructure workflows, and Terraform executes within a secure and auditable framework. 

For platform engineers and DevOps teams, this means less time spent on repetitive operational work and more time focused on innovation and architecture. For CIOs, CTOs, and business decision makers, it creates a path toward scalable platform engineering, operational standardization, and intelligent infrastructure operations. 

The future of infrastructure is not simply automated. It is intelligent, governed, composable, and accessible — and the Terraform MCP server is becoming one of the foundational technologies enabling that transformation. 

To learn more about Terraform MCP server, visit Terraform MCP server overview. 

from HashiCorp Blog https://ift.tt/p8JEIPi
via IFTTT

CL-STA-1062 Targets Southeast Asian Governments and Critical Infrastructure

Executive Summary

Throughout 2025, we observed a cluster of activity targeting government entities and critical infrastructure in Southeast Asia. Specifically, the activity targeted state-owned enterprises in the energy and government sectors.

The Chinese-speaking attackers behind this cluster, which we track as CL-STA-1062, have been active since at least March 2022. We assess with high confidence that this is the same cluster, known as UAT-7237, that was reported for its campaigns against web hosting infrastructure in Taiwan in mid 2025. We also observed CL-STA-1062 campaigns in earlier operations targeting strategic sectors in East Asia, indicating a broader, sustained regional focus.

From a technical standpoint, the attackers behind CL-STA-1062 rely on a hybrid toolkit. While they frequently use common open-source tools such as SoftEther VPN, Mimikatz and VNT, they have recently introduced TinyRCT, a bespoke, previously undocumented backdoor.

TinyRCT’s capabilities include:

• Arbitrary command execution
• File enumeration and exfiltration
• Screen capture
• A self-destruct mechanism

We detail the latest campaign linked to CL-STA-1062 against the energy and government sectors in Southeast Asia, and provide a technical analysis of the new TinyRCT backdoor.

Palo Alto Networks customers are better protected from the threats discussed above through the following products and services:

• Cortex XDR and XSIAM
• Advanced WildFire
• Advanced URL Filtering and Advanced DNS Security

If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team.

Related Unit 42 Topics

CL-STA-1062, Malware, Backdoor, VPN, Mimikatz

Latest Campaign Analysis

While this article focuses on CL-STA-1062 activity against targets in Southeast Asia during 2025, our telemetry reveals that the attackers behind this cluster have been conducting operations across East Asia since 2022. We assess with high confidence that this is the same activity cluster tracked by Cisco Talos as UAT-7237, previously reported for its campaigns against web hosting infrastructure in Taiwan. Building on recent observed activity, our investigation into CL-STA-1062 activity highlights a broader long-term strategy in the Asia-Pacific region.

Targeting Southeast Asian Government Entities

In September 2025, we discovered that the attackers behind CL-STA-1062 had compromised a Southeast Asian government entity by deploying web shells and exfiltrating database information. Figure 1 shows the command line used to exfiltrate data from an MSSQL server.

Figure 1. Exfiltrating data from the MSSQL server.

During this intrusion, the attackers were also able to conduct network reconnaissance on a separate government entity in the same country. This suggests an effort to identify lateral movement opportunities and broaden their access. In one case, we observed the attacker staging and exfiltrating an entire directory of web server source code from the government entity, as Figure 2 shows.

Figure 2. Archiving the folder containing the web server source code.

Between October and December 2025, we observed the likely compromise of at least ten different organizations in Southeast Asia.

Focusing on Critical Energy Infrastructure

Since mid 2025, as part of activities in Southeast Asia, the threat actor behind CL-STA-1062 focused on critical infrastructure. We identified that a critical infrastructure entity had been under attack for several months. The activity within the compromised network was comprehensive, covering the entire attack lifecycle from initial access to data exfiltration.

The following month, we discovered that the attackers behind CL-STA-1062 had also compromised two state-owned critical energy infrastructure (CEI) entities in the same Southeast Asian country. We observed attackers scanning the entities for vulnerabilities, shortly followed by outbound requests from the infected networks. These requests connected to attacker-controlled infrastructure and resulted in the victim networks downloading malicious payloads that included SoftEther VPN components and RAR archives containing the group's tools.

Figure 3 shows HTTP requests that download the attackers’ tools to the targeted networks.

Figure 3. Examples of outbound requests from an infected network.

Evolving TTPs and Open-Source Toolkit

The intrusions we observed typically begin with the attackers exploiting web applications to deploy ASPX web shells. These web shells function as the central mechanism for executing arbitrary commands, dropping additional tooling and conducting initial reconnaissance. As part of our observations of CL-STA-1062, we noted activity sending the results of network and system enumeration directly to an actor-controlled IP address using curl. Figure 4 shows an example of the command lines used.

Figure 4. System enumeration command lines.

From this foothold, the activity includes open-source tools and custom malware. The attackers also adapt techniques to the target environment.

The attackers behind the activity frequently use tunneling tools for command and control (C2) and data exfiltration. They deployed a variety of these tools, including:

• SoftEther VPN
• yuze
• VNT

These tools were often disguised as legitimate system files, such as VMware executables or an XDR agent. Figure 5 shows the command line used by the group to execute a yuze instance.

Figure 5. yuze command-line execution.

In one case, the attackers used a web shell to extract a password-protected RAR archive containing a SoftEther VPN binary masquerading as vmtools.exe. Figure 6 shows the extraction and execution of the SoftEther VPN binary.

Figure 6. Extracting and executing SoftEther VPN.

In another case, the attackers attempted to disguise VNT as a VMware executable, as shown in Figure 7.

Figure 7. Creating a scheduled task to execute a VNT binary.

In one instance, the attackers used traceroute to identify potential lateral movement paths to another government entity. To escalate privileges, the attackers deployed known open-source tools, such as JuicyPotato. For data staging and exfiltration, they frequently compressed findings into password-protected RAR archives.

ֿTechnical Analysis of TinyRCT

During our investigation into the campaign's infrastructure, we observed the server at 139.180.134[.]221 hosting a suspicious executable named PerfWatson2.exe. By pivoting on this IP address, we were able to retrieve and analyze the binary, identifying it as a previously undocumented .NET backdoor. Analysis of the binary's internal strings revealed that the authors refer to this tool as TinyRCT.

TinyRCT is a lightweight, C#-based remote access Trojan (RAT) targeting Windows. It operates as a backdoor, enabling attackers to execute arbitrary system commands, exfiltrate files, capture screenshots and remotely manage the infected host.

Upon execution, the malware performs an environment validation to explicitly verify that it was executed from %LOCALAPPDATA%. If the malware was executed from any other location – such as a sandbox environment or a malware analyst’s desktop – the binary terminates immediately.

The execution of TinyRCT can be blocked by implementing strict behavioral monitoring and execution restrictions on untrusted binaries. Figure 8 shows how an execution attempt by the TinyRCT malware, masquerading as PerfWatson2.exe, is prevented and alerted by Cortex XDR.

Figure 8. A prevention alert of blocking the TinyRCT malware execution attempt as seen in Cortex XDR in prevent mode.

Host Fingerprinting and Registration

Before entering its main command loop, TinyRCT conducts initial reconnaissance to fingerprint the infected host. It aggregates critical system information to generate a unique victim profile, collecting the following data points:

• User and system context: Current username, machine name and OS version.
• Network and execution: Local IP addresses, the complete execution path of the malware and the current process ID (PID).
• Identity: A randomly generated globally unique identifier (GUID) to serve as the bot's identifier.

This data is concatenated, encrypted and immediately transmitted to the C2 server via an HTTP POST request. This registration packet allows the attacker to profile the newly infected host and decide whether to issue further commands or terminate the infection based on the host's assessed value.

C2 Communication

After successful registration, TinyRCT establishes a persistent communication channel with the C2 server at 45.32.113[.]172. The malware uses standard HTTP for network traffic, but it encrypts all exchanged data using AES-128 encryption in CBC mode. The encryption key (ThisIsASecretKey87654321) and a null Initialization Vector (IV) are hard-coded directly within the binary.

The malware operates on a beaconing model, with a default 10-second sleep interval between requests. It polls the C2 server for instructions using GET requests, while it sends exfiltrated data via POST requests.

Supported Commands and Capabilities

The backdoor is designed for surveillance and remote management and executes a concise set of commands. When the C2 server responds to a beacon, the malware decrypts and parses the payload, and then executes the appropriate commands from the following functions:

• Shell execution: Executes the command via cmd.exe (or direct process execution) and returns stdout/stderr.
• Update configuration: Updates the sleep interval.
• File listing: Enumerates directories and files in the specified path. Returns format: Filename*Date*Size.
• Read text file: Reads a text file and returns content.
• Download file: Downloads a file from a URL and saves it to the desired path.
• Exfiltrate file: Reads a binary file from the requested path, compresses its contents using gzip, encrypts them using AES and sends them to the C2 in 40 KB chunks.
• Screen capture: Captures the primary screen, saves the capture as a JPEG file, compresses it, encrypts it and sends it to the C2.
• Self-destruct: Triggers the cleanup routine.

Figure 9 shows the C2 server response parsing function of TinyRCT, including a line of code in Simplified Chinese.

Figure 9. The C2 response parsing function of TinyRCT.

Self-Destruct Mechanism

A notable feature of TinyRCT is its cleanup capability, triggered by the self-destruct command. This routine is designed to remove forensic evidence of the infection.

Upon receiving the self-destruct command, the malware first deletes the GoogleUpdater scheduled task created by the loader. It then executes a self-deletion routine using a legacy batch command technique involving the choice.exe program. This routine deletes the malware’s PerfWatson2 executable, as Figure 10 shows.

Figure 10. The complete choice.exe command line.

The use of choice.exe creates a three-second delay, ensuring the primary malware process has fully terminated and released its file handle before the delete command executes.

Infection Vector

Our analysis began with the discovery of the PerfWatson2.exe payload hosted on the attacker’s C2 infrastructure. By pivoting from this artifact, we reconstructed the infection chain, identifying its origin as a malicious archive named chrome_setup.zip.

Inside the zip were three files:

• A legitimate executable
• A configuration file
• A malicious DLL

This specific combination of files is used to perform AppDomainManager Injection – a technique that exploits the trust relationship between a .NET application and its configuration file. The archive contains a legitimate, signed chrome_setup.exe executable paired with a malicious chrome_setup.exe.config configuration file.

When the user runs the executable, the .NET runtime reads the adjacent configuration file. This forces the loading of a malicious DLL (MyAppDomainManager.dll) to act as the application's manager. This allows the malicious code to execute instantly and covertly within the context of a trusted process.

Once injected into the legitimate setup process, the malicious MyAppDomainManager.dll functions primarily as a stealthy downloader and persistence enabler.

Upon initialization, the malicious loader runs a critical environmental check to validate its execution context. It explicitly verifies that the host process is running from %USERPROFILE%\Downloads — the user’s Downloads directory. If this check fails, it likely indicates the sample was moved to a sandbox or an analyst's desktop, and the loader terminates immediately. Figure 11 shows this check in the loader source code.

Figure 11. The loader's initial environment check.

If the validation passes, the loader contacts the staging server at 139.180.134[.]221 to retrieve the secondary payload. The loader saves this payload to the user’s %LOCALAPPDATA% directory as PerfWatson2.exe, mimicking the legitimate telemetry component associated with Microsoft Visual Studio.

To ensure this payload runs continuously without user interaction, the loader constructs and executes a specific schtasks command. This command creates a scheduled task named GoogleUpdaterTaskSystem140.0.7272.0 {ACE7A46F-50FD-481C-AB32-3D838871DB40}. The task is configured to run the malware with the highest available privileges (e.g., /rl highest) every time the user logs on to the system (e.g., /sc onlogon). This ensures that the infection survives system reboots.

Conclusion

Our investigation into CL-STA-1062 reveals a persistent activity cluster likely operated by Chinese-speaking actors. The attackers are expanding operations from Taiwan to critical infrastructure and government entities in Southeast Asia. They demonstrated their ability to infiltrate strategic sectors – specifically energy and government organizations.

The combination of tools observed in this activity cluster reflects a pragmatic approach to tool selection and attack capabilities. The attackers behind this cluster continue to leverage common open-source tools such as SoftEther VPN and VNT to facilitate lateral movement. Our discovery of the TinyRCT backdoor in the attackers’ infrastructure underscores their ability to customize tools to gain specific capabilities.

The combination of targeting critical infrastructure and the development of custom malware suggests that CL-STA-1062 activity will continue to pose a threat to the region. Organizations in Southeast Asia, particularly within the energy and government sectors, should remain vigilant against this evolving activity.

Palo Alto Networks Protection and Mitigation

Palo Alto Networks customers are better protected from the threats discussed above through the following products:

• Cortex XDR and XSIAM help to prevent the threats described in this article, by employing the Malware Prevention Engine. This approach combines several layers of protection, including Advanced WildFire, Behavioral Threat Protection and the Local Analysis module, to prevent both known and unknown malware from causing harm to endpoints.
• The Advanced WildFire machine-learning models and analysis techniques have been reviewed and updated in light of the indicators shared in this research.
• Advanced URL Filtering and Advanced DNS Security identify known domains and URLs associated with this activity as malicious.

If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:

• North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42)
• UK: +44.20.3743.3660
• Europe and Middle East: +31.20.299.3130
• Asia: +65.6983.8730
• Japan: +81.50.1790.0200
• Australia: +61.2.4062.7950
• India: 000 800 050 45107

Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.

Indicators of Compromise

SHA256 Hashes

chrome_setup.zip file:

• 00e09754526d0fe836ba27e3144ae161b0ecd3774abec5560504a16a67f0087c

fscan:

• f34bd1d485de437fe18360d1e850c3fd64415e49d691e610711d8d232071a0b1

SoftEther VPN:

• dce5df29bddff5a4ddaea5c4fec14da91f7b69063a6e1c45ed61e5da4fc6c87b

TinyRCT downloader:

• cbfe8de6ffadbb1d396f61e63eb18e8b11c29527c1528641e3223d4c516cf7c3

TinyRCT:

• 4e1f8888d020decd09799ec946f1bf677cac6612b24582ddbf4d8ede425d8384

VNT:

• 9b481b69cd91b09fa7bae7428f646dd89473a4c03393e43da81fe756cde1c472

C2 Servers

IPv4 addresses:

• 139.180.134[.]221
• 202.182.102[.]5
• 45.76.210[.]43
• 45.32.113[.]172

URLs:

• hxxp[:]//139.180.134[.]221/sdksdk608/1.zip
• hxxp[:]//139.180.134[.]221/sdksdk608/anydesk%5f0117.zip
• hxxp[:]//139.180.134[.]221/sdksdk608/hamcore.se2
• hxxp[:]//139.180.134[.]221/sdksdk608/httpdf
• hxxp[:]//139.180.134[.]221/sdksdk608/vpn%5fbridge.config
• hxxp[:]//139.180.134[.]221/sdksdk608/win-vpn.rar
• hxxp[:]//139.180.134[.]221/PerfWatson2.exe

Additional Resources

• UAT-7237 targets Taiwanese web hosting infrastructure – Cisco Talos
• VNT - An efficient VPN – GitHub
• JuicyPotato Malware Family – Malpedia
• Hijack Execution Flow: AppDomainManager – MITRE ATT&CK® documentation
• SoftEther VPN – Wikipedia

from Unit 42 https://ift.tt/OgdW7Is
via IFTTT

Scaling without friction: Aliases at project scope in Boundary

In Boundary, a target alias is a simple, powerful tool. It lets you connect to infrastructure using a memorable name instead of a random, generated ID. It gives developers something intuitive to work with. But those aliases lived exclusively at the global scope. They must be globally unique across your entire deployment. 

As infrastructure scales, so does everything around it. 

More teams. More environments. More cloud accounts. More services. 

What doesn't scale well is centralization. Especially when it shows up in places you don't expect — like naming. 

With our 1.0 release, Boundary introduces target aliases at the project scope level. Teams can now independently create, manage, and use aliases within their own project boundaries, aligned with how they already map their deployment structures. 

The enterprise scale problem: alias collisions 

At small scale, a global alias makes sense. It's simple: 

• Define an alias once 

• Ensure it's unique 

• Use it with any target under any scope in Boundary 

 

But at enterprise scale, this model starts to break down. The infrastructure spreads locally, across targets, teams, projects and environments. And those units repeat patterns. 

Every network project needs an ssh-jumper.  

Every data center org needs an api-gateway. 

Every staging environment has a postgres.db. 

In a global namespace, only one team can claim those intuitive names. Everyone else is locked out. When a global alias forces all of these to be unique, you don't get clarity—you get friction: 

• Teams invent increasingly complex naming conventions for aliases 

• Simple workflows depend on global administrators 

• Visibility expands beyond what's necessary for governance 

The system remains correct, but it stops being scalable across projects and teams. 

Decentralizing naming with project boundaries 

This is a simple shift, but an important one: Alias ownership now lives where the infrastructure lives. Instead of managing aliases globally: 

• Project teams create and manage their own aliases 

• Project admins see only what belongs to their scope 

• Global admins retain oversight across all projects 

 

This aligns Boundary with how organizations actually operate today — not as a single system, but as a collection of independent, parallel systems that share a common platform. 

From namespace conflicts to independent execution 

In large environments, coordination is often the hidden cost. 

Two teams want to onboard similar infrastructure: same service type, same naming preference, completely different contexts. In a global model, they compete for the same namespace. In a project-scoped model, they don't. 

Each team can define db, api, ssh-bastion within their own scope, without conflict. 

The result isn't just cleaner naming. It's faster onboarding. Fewer dependencies. Less operational overhead. 

Solving the constraint: global uniqueness 

There's a reason aliases were global in the first place. They need to resolve unambiguously. 

The challenge is simple: How do you allow teams to reuse names locally while keeping them distinct globally? 

Introducing structured suffixes 

The answer is not more rules. It's better structure. 

Aliases are now automatically constructed as: <alias>.<project-suffix>.<org-suffix> 

By introducing structured suffixes with aliases at both the project and organization levels, we are bringing a natural, DNS-style hierarchy mimicking the Boundary deployment structure directly to your access paths. 
 

This lets you preserve the simplicity of local naming, while maintaining global uniqueness. 

For example: 

• Db.payments.dc-canada 

• Db.marketing.dc-spain 

Both teams can use db. The system ensures these aliases remain globally distinct. 

Why this Hierarchy works 

This isn't just about avoiding collisions. It introduces a naming model that scales with the organization. 

Natural hierarchy for enterprise infrastructure: Organizations structure infrastructure hierarchically — data centers, teams, environments. This suffix model mirrors that structure in names, making connections more intuitive. 

Reduced namespace collisions: Org suffixes scope project suffix uniqueness within each org. Multiple orgs can safely reuse dev, prod, payments, or ml without conflicts. Each org owns its namespace. 

Better deployment structure: The hierarchy aligns with enterprise org structures, creating clearer namespace ownership and governance boundaries. Teams know their aliases are isolated within their own scope. 

Scalability for multi-tenant deployments: No risk of exhausting globally unique project suffixes. As you add more orgs and projects, the namespace grows naturally without conflicts. 

Transparent sessions integration: For transparent sessions users, a structure like myhost.proj.org is more natural to connect to than myhost.uniquesuffix. 

Key behaviors 

• Both suffixes are mandatory for project-level aliases:. Configure org suffix first, then project suffix. 

• Project suffixes validated within the org: No two projects in the same org can use the same suffix. 

• Suffix updates are non-breaking: Existing aliases keep the old suffix. New aliases use the updated suffix. 

• Real-time conflict detection: Boundary validates uniqueness immediately and throws an error if the name is taken. 

• Instant UI/CLI feedback: Fully qualified name displayed immediately after creation. No surprises. 

Real-world example: global enterprise deployment 

Consider a large enterprise structuring Boundary across geographic regions and business departments. Organizations represent physical regional data centers: 

Org ID	Description
DC-INDIA	India datacenter
DC-CANADA	Canada datacenter
DC-NA	North America datacenter
DC-SPAIN	Spain datacenter

<p></p>

Within these orgs, projects are grouped to map directly to internal business teams: Marketing, R&D, and sales. With project-scoped aliases, the same alias name works across contexts: 

Aspect	DC-INDIA / Marketing	DC-SPAIN / R&D	DC-CANADA / R&D
Org suffix	.dc-india	.dc-spain	.dc-canada
Project suffix	.marketing	.rnd	.rnd
Alias name	postgres-db	postgres-db	postgres-db
Fully qualified	postgres-db.marketing.dc-india	postgres-db.rnd.dc-spain	postgres-db.rnd.dc-canada

<p></p>

Now imagine 30 datacenters across the globe with 10 different departments in each DC. Every account can use postgres-db without conflicts. 

Configuring grants 

To support this new workflow, two new actions are introduced that will enable users with project admin and org admin roles to create or remove suffixes at project scope and org scopes respectively. 

For org admin roles, create a role in the global scope if it does not exist, then assign the following grant: 

boundary roles add-grants \ 
  -id <role_id> \ 
  -grant "ids=*;type=scope;actions=set-alias-suffix,remove-alias-suffix" 

For project admin roles, create a role in the parent org scope if it does not exist, then assign the following grant: 

boundary roles add-grants \ 
  -id <role_id> \ 
  -grant "ids=*;type=scope;actions=set-alias-suffix,remove-alias-suffix" 

Alternately you can use the all-new grant builder now live with Boundary release 1.0 with Project access and Org access role templates to manage suffixes at project and org scopes respectively. 

Boundary scales with you 

Project-scoped aliases are a step toward a more natural model of access — one that scales with your organization instead of constraining it. As infrastructure grows, Boundary evolves with it — removing friction without compromising control. 

See Boundary in action 

Create a free HCP account and deploy Boundary for your environment. 

View aliases details in our documentation. 

Check out our many tutorials on Boundary. 

Download the latest version of Boundary installer to try it out yourself. 

from HashiCorp Blog https://ift.tt/K58FO2z
via IFTTT

How to Generate an SBOM for Container Workflows

According to Omdia’s 2026 software supply chain security report, 86% of organizations find SBOM generation challenging. A major driver is tool sprawl: teams cobbling together different scanners for different artifact types, getting inconsistent output across pipelines, and spending engineering time reconciling the results rather than acting on them.

SBOMs have become important to how security teams respond to vulnerability disclosures, how compliance teams satisfy auditors, and how procurement decisions get made. That makes the generation step load-bearing. If the SBOM your pipeline produces misses transitive dependencies, records declared versions instead of resolved ones, or is not cryptographically bound to the artifact it describes, every downstream decision built on that data inherits the gap.

This post covers the decisions that determine SBOM quality: when and where to generate, what separates actionable output from data that just checks a box, and how to keep generation reliable as your image portfolio grows.

Key takeaways

• Build-time SBOM generation produces more complete, accurate output than post-build scanning.
• Completeness, accuracy, freshness, and verifiability determine whether an SBOM is actionable.
• Generation tooling runs with elevated build access and may require additional security considerations, for example pinning to immutable references.
• Images that ship with pre-built SBOMs eliminate the generation burden for your base layer.

When to generate: Build-time vs. post-build

The single decision that most affects SBOM quality is when you generate it. There are two broad approaches, and they produce meaningfully different results.

Build-time generation

Build-time generation hooks into the build system itself. The generator has access to the resolved dependency tree, the package manager files, and the full build context. It knows exactly what went into the artifact because it was present when the artifact was assembled.

Container build systems with native attestation support can produce an SPDX SBOM during the image build, attach it as an in-toto attestation, and push both the image and the SBOM to the registry in a single operation. Language-specific build plugins take a similar approach for application dependencies, generating SBOMs as part of the standard build lifecycle.

The advantage is structural: build-time generation captures the resolved state of every dependency, including transitive dependencies that post-build scanners may miss.

Post-build scanning

Post-build tools scan a finished artifact and reverse-engineer its contents. They work by identifying package manager metadata, file signatures, and known patterns within the artifact. This approach works on any OCI-compatible image, regardless of how it was built.

The trade-off is coverage. Statically linked binaries, vendored dependencies, and OS packages installed in intermediate build stages may commonly be missed by post-build scanners. The scanner can only report what it can detect, and detection is heuristic-based rather than derived from the actual build graph.

When you have build system access, generate at build time. Post-build scanning is the right choice for third-party images you consume but did not build, or for legacy artifacts without build system integration.

For container images, our documentation covers how to configure build-time SBOM attestation in detail, including the specific flags and generator options for different build workflows.

What makes an SBOM useful

Generating an SBOM is not the same as generating a useful one. The file format is standard, but the quality of the content varies dramatically depending on how and when the SBOM was produced. Five criteria separate actionable SBOMs from checkbox artifacts.

1. Completeness

A complete SBOM accounts for every component in the artifact across all layers and all package types. This includes OS packages from the base image, application dependencies from every package manager in the build, and any tooling or utilities added during the build process. 

This is where multi-stage and minimal base images create real gaps. A Dockerfile with a Node frontend, a C or C++ component compiled into a static binary, and a distroless final stage presents three distinct challenges: the Node layer has deep transitive dependency trees, the statically linked binary often carries no dependency manifest on disk, and the distroless base has no package manager at all. Post-build scanners can miss the statically linked dependencies and may undercount the Node tree. Build-time generation with access to each stage’s resolved dependency graph is the only way to get a complete picture.

2. Accuracy

Accuracy means the SBOM records resolved versions, not declared ranges. A package manifest might declare “^4.17.0” but the resolved version in the lock file is 4.17.21. The SBOM must reflect what was actually installed, not what was requested.

3. Freshness

An SBOM is a point-in-time snapshot tied to a specific build. Every time the artifact is rebuilt, the SBOM should be regenerated. Stale SBOMs create a false sense of visibility.

4. Verifiability

A verifiable SBOM is one that consumers can confirm was produced by the build system and has not been tampered with. Cryptographic signing and attestation frameworks bind the SBOM to a specific artifact digest, along with build provenance that records where and how the artifact was built.

5. Format compliance

Standard formats like SPDX and CycloneDX define required and optional fields. An SBOM that validates against the schema is interoperable across scanning tools, policy engines, and compliance workflows. One that does not may work with your current tools but will break when you change them.

Some base images already ship with SBOMs that meet all five criteria, along with SLSA Build Level 3 provenance and exploitability data. These SBOMs were generated at build time on hardened build platforms with non-falsifiable provenance, cryptographically signed, and attached as in-toto attestations bound to the image digest. They are continuously regenerated with every rebuild, so freshness is maintained without manual intervention. For those images, the generation question is answered for the most critical layer of the stack, and your effort shifts to generating a complete SBOM for the application layer you add on top.

Your generation toolchain is attack surface

The tools you use to generate SBOMs run with elevated access to your build environment. They read your source code, your dependency trees, and your build artifacts. A compromised generator does not just produce bad output; it has the access to exfiltrate or modify what it scans.

This is not a theoretical concern. Version tags on GitHub Actions and container images are mutable. A tool you pinned to v2.1 today can silently become something different tomorrow if a maintainer account is compromised or a tag is force-pushed. The exposure window for incidents like these is typically measured in hours, but automated pipelines can pull compromised versions within minutes.

Treat your generation tooling with the same rigor you apply to any other build dependency:

• Pin to immutable references (commit SHAs, not version tags).
• Verify checksums before execution.
• Run generation in CI, not on developer machines, for reproducible and auditable output.
• Monitor for upstream security advisories on your generation tools.

This is one dimension of a broader software supply chain security challenge: every tool in your pipeline is a dependency that needs the same scrutiny as your application code. For base images, you can sidestep this risk entirely. Images built on hardened build platforms with non-falsifiable provenance carry their supply chain metadata from the point of origin, cryptographically verified end-to-end.

Integrating SBOM generation into CI/CD

Manual SBOM generation works for one-off audits. For production workflows, generation needs to be automatic, reproducible, and wired into the rest of your delivery pipeline. The pattern is consistent across CI systems.

Generate at build

Add SBOM generation as a build stage step, immediately after the image is produced. For container images, BuildKit attestation flags are the most reliable approach. For application dependencies, language-specific plugins (CycloneDX for Maven/Gradle, npm/yarn for Node) produce the highest-quality output because they access the resolved dependency graph.

For multi-stage builds, generate from the final stage only. Intermediate stages often install build tools and test frameworks that do not ship in the production image. Generating against intermediate stages inflates the SBOM with components that are not deployed, creating noise in vulnerability scans.

Choose an attestation format

SPDX is the native output format for BuildKit attestation and the stronger choice if license compliance is a primary concern. CycloneDX has richer vulnerability correlation support and more granular component classification, making it the better fit for security-focused workflows. If your consumption tools (policy engines, vulnerability scanners, compliance dashboards) have a preference, follow it. If they support both, default to SPDX for container images since it requires no additional tooling beyond BuildKit’s built-in generator.

Attach to the artifact

Store the SBOM alongside the artifact it describes. For container images, this means attaching it as an OCI attestation in the registry rather than saving it as a separate file in an artifact store. Attestation-based storage keeps the SBOM discoverable, versioned, and bound to the specific image digest. When the image is promoted from dev to staging to production, the SBOM travels with it through every registry, rather than requiring a separate copy-and-sync workflow that inevitably drifts.

Validate before publishing

Add a validation step between generation and registry push. Run the SBOM through a format validator (SPDX and CycloneDX both provide official schema validators), check that the component count is reasonable for the artifact, and verify that the SBOM references the correct image digest. A build that produces 12 components for an image you know contains 200+ packages should fail the pipeline, not ship silently.

Scan and enforce continuously

SBOM generation at build time captures what’s shipped. Continuous scanning tells you what’s become vulnerable since. New CVEs drop daily, and an SBOM that was clean at build time can have critical exposures within weeks. Continuous analysis against SBOM data matches new disclosures against your inventory without re-pulling images, and surfaces policy violations as they emerge. With SBOMs attached to every image, you can gate deployment: no image ships without a valid SBOM, no image deploys with a known-vulnerable package above your severity threshold.

Implementation details vary by CI system. Our documentation covers the specific flags and configuration for generating and attaching SBOM attestations across common container build workflows.

Verifying your SBOM output

Before relying on your SBOM output for compliance reporting or vulnerability management, verify that it meets the quality criteria below.

• Component count sanity check: Compare the number of components in your SBOM against what you expect from the Dockerfile, lock files, and base image. A Node.js app with 200 declared dependencies should produce substantially more entries once transitive dependencies are included.
• Resolved versions, not ranges: Spot-check entries to confirm the SBOM records specific versions (4.17.21) rather than declared ranges (^4.17.0).
• Transitive dependency depth: Verify that transitive dependencies appear, not just top-level packages. If your app declares 30 direct dependencies but the SBOM contains 32 entries, transitive coverage is likely incomplete.
• OS package coverage: Confirm that base image OS packages appear alongside application dependencies.
• Digest binding: Verify the attestation references the correct image digest. An unbound SBOM cannot be trusted to describe its artifact.
• Format validation: Run the SBOM through a schema validator (SPDX and CycloneDX both provide official tools).

Start generating, then start verifying

The best time to add SBOM generation to your pipeline is the next time you touch your CI configuration. Start with your highest-traffic production image. Configure build-time generation, attach the SBOM as an attestation, and validate the output against the checklist above. Then expand to the rest of your portfolio.

If you want a head start, Docker Hardened Images ship with complete SBOMs, SLSA Build Level 3 provenance, and OpenVEX data already attached, so you can skip the generation step for your base layers entirely. For everything you build on top, Docker Scout provides continuous vulnerability matching against your SBOM data and enforces policies across your image portfolio.

• Get started with Docker Hardened Images →
• Explore vulnerability monitoring with Docker Scout →

Frequently asked questions

What is the best format for an SBOM?

For container images, default to SPDX since it is the native BuildKit attestation output and requires no additional tooling. Choose CycloneDX if your primary use case is security scanning and your downstream tools prefer it.

Do I need to generate an SBOM if my images already come with one?

If you are using base images that ship with pre-built SBOMs, provenance, and exploitability data, you do not need to regenerate for that layer. The included SBOM was generated at build time with full access to the build graph and is cryptographically bound to the image.

To verify the pre-built SBOM is trustworthy, check two things: 

1. Is the SBOM attached as a signed attestation (not a loose file)?
2. Does the attestation include SLSA provenance?

If the provenance traces back to a hardened build platform with non-falsifiable provenance, you can treat the SBOM as authoritative for that layer. You still need to generate an SBOM for the application dependencies you add on top.

How often should I regenerate my SBOM?

Every time the artifact is rebuilt. If your CI pipeline produces a new image, it should produce a new SBOM to match. Between rebuilds, the existing SBOM is still accurate because the artifact has not changed.

Is SBOM generation required for compliance?

In the United States, Executive Order 14028 helped set SBOM requirements in motion for software sold to federal agencies. The EU Cyber Resilience Act extends SBOM requirements to all products with digital elements sold in the EU.

And as AI workloads come under newer regulations like the EU AI Act with its technical documentation and transparency expectations, component-level inventories are becoming a practical way for teams to show what is inside high-risk systems. Industry frameworks like NIST SSDF and CISA’s SBOM guidance increasingly reference SBOMs as a baseline expectation. Whether legally required today, SBOMs are becoming a procurement prerequisite.

Sources

Omdia, Securing the Software Supply Chain: Strategic Approaches to Support Scaling Development with AI Adoption, May 2026.

from Docker https://ift.tt/NKoaFAv
via IFTTT

Beyond IOCs: AI-enabled threat intelligence

Welcome to this week’s Threat Source newsletter. 

The issue of AI in cybersecurity is often portrayed as a binary choice: either a force multiplier for our adversaries, or a tool bringing professional obsolescence. The reality is more nuanced. While AI certainly brings some advantage to attackers, it also offers advantages to the defender, notably in how we manage, index, and derive value from threat intelligence. 

Currently, our industry excels in the use and dissemination of indicators of compromise (IOCs). These atomic indicators fit neatly into key-value data stores and their value can be enhanced with added context, neatly structured in STIX/MISP format. However, this is only the tactical layer. 

Ultimately, we want the consumers of threat intelligence reports to develop their knowledge and to build a picture of the relevance of the threat to their own situation, along with understanding of how they can respond given their resources and constraints. This capability is conferred by the natural language found within strategic and operational intelligence briefings. 

These reports provide the context required for meaningful response, yet they remain notoriously difficult to index. We are often left with disparate incident reports, darknet monitoring, and malware analysis that fail to cross-reference effectively, further complicated by inconsistent naming conventions for threat actors. 

This is a problem that large language models (LLMs) may be able to solve. Although AI models have no real understanding of an issue, they can identify synonyms and relate entities across vast, unstructured datasets. This can only make the retrieval of relevant threat intelligence reports easier, and facilitate the generation of relevant advice to protect against threats. 

There are still issues to resolve. We need to be vigilant regarding the veracity of the data that LLMs ingest, and of the confidentiality of the queries made of such a system. However, the development of personal, domain-specific LLMs offers the possibility of a world of integrated threat intelligence where relevant reports from disparate sources can be easily retrieved, and specific advice returned to even the vaguest of queries. 

Rather than fearing AI’s potential negative effects on our employment, we can consider AI’s development as a powerful tool that enables access to threat intelligence reports and allows us to provide tailored actionable advice faster to those who need to know it. Ultimately, AI can help us do what we do best: making a difference and making the bad guy’s lives harder. 

The one big thing 

Cisco Talos is highlighting how Windows threats increasingly abuse the Component Object Model (COM) to execute malicious activities. While COM is a fundamental Windows technology for legitimate inter-process communication, malware families like Qakbot and WarmCookie hijack it for lateral movement, persistence, and evasion. Because COM functionality relies on opaque GUIDs and indirect vtable calls, it obscures the attacker's intent and makes manual analysis incredibly labor-intensive. 

Why do I care? 

Threat actors love COM because it provides convenient access to built-in Windows functionality while making static analysis a nightmare. By hiding malicious behavior behind indirect function calls, attackers easily bypass basic scrutiny and blend in with legitimate system processes. Adversaries are effectively turning Windows' own architecture against itself. If analysts aren't prioritizing COM during triage, they are likely missing critical pieces of the infection chain. 

So now what? 

Defenders must sharpen their skills in recognizing COM usage and translating evidence like ProgIDs and vtable offsets into human-readable actions. Leverage specialized tools like OleView.NET, IDA’s COM Helper, and DispatchLogger to map anonymous indirect calls to clear behaviors. Security teams should also build static hunting logic to track these threats. You can find a simplified YARA hunting rule for binaries referencing the Task Scheduler COM class in the full blog post. 

Top security headlines of the week 

FortiBleed campaign used custom FortiGate sniffer to steal credentials 
Security firm SOCRadar says the large-scale FortiBleed campaign targeting Fortinet FortiGate devices used custom sniffers to harvest authentication secrets from compromised firewalls and steal credentials. (BleepingComputer) 

Scattered Spider hackers plead guilty on Day 1 of trial 
Two men pleaded guilty in the United Kingdom this week to criminal charges stemming from an August 2024 cyber attack affecting Transport for London, the entity responsible for the public transport network in the Greater London area. (Krebs on Security) 

Klue says hackers stole credential from 2022 that led to customer data breaches 
Market research company Klue has confirmed that a credential dating back to 2022, which was part of a limited pilot, was used by hackers earlier this month to steal data from its corporate customers, including several cybersecurity companies. (TechCunch) 

New exploit bypasses Apple’s boot defenses, affects millions of iPhones 
Baked permanently into the device’s SoC, SecureROM is the first code an iPhone runs on startup and the foundation of Apple’s entire secure boot chain. The exploit chains a USB controller bug and a device firmware configuration weakness. (SecurityWeek) 

Windows 11 KB5095093 update rolls out new Point-in-Time restore feature 
This update introduces numerous new features, including a standout Point-in-Time Restore feature that allows Windows users to easily roll back their operating system, applications, and files to a previous point in time. (BleepingComputer) 

Can’t get enough Talos? 

AI is finding bugs faster. Now what? 
In this episode of Beers with Talos, the team is joined by Nick Biasini to unpack what attackers are doing with AI-assisted vulnerability discovery, review FIFA World Cup threat trends, and phish the Pope. 

Patching in the dark: Managing unknown threats in complex environments 
If you're tired of being told to "just patch," we understand. Amy and Pierre explore the logistical, technical, and business realities that make patching a complex, high-stakes operation rather than a simple button click — and break down the things defenders often miss that build true resilience in organizations. 

Hypotheses, telemetry, and human judgment: Inside Cisco Talos Threat Hunting 
Learn how Cisco Talos Threat Hunting uses hypothesis-driven methods and multi-domain telemetry correlation to find stealthy threats operating below automated detection thresholds. 

Upcoming events where you can find Talos 

• Black Hat USA (Aug. 1 – 6) Las Vegas, NV 
• DEF CON 34 (Aug. 6 – 9) Las Vegas, NV 

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: 9896a6fcb9bb5ac1ec5297b4a65be3f647589adf7c37b45f3f7466decd6a4a7f 
MD5: 38de5b216c33833af710e88f7f64fc98  
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=9896a6fcb9bb5ac1ec5297b4a65be3f647589adf7c37b45f3f7466decd6a4a7f 
Example Filename: SECOH-QAD.exe 
Detection Name: Win.Tool.Procpatcher::1201 

SHA256: afc8a00883a4ea07df2dc1d4ed02f8a23b35c9456413b438a2d9ce3ae5076638 
MD5: cc4d231df34e57f59eb970353c7d9de2  
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=afc8a00883a4ea07df2dc1d4ed02f8a23b35c9456413b438a2d9ce3ae5076638 
Example Filename: AutoPico.exe  
Detection Name: PUA.Win.Tool.Kmsactivator::1201 

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

SHA256: 853baab97b1f3b03c1ffa55797e87867f5fb7ce33457411f56afd270cb395453 
MD5: 41acb30b9d662d48b7b4fc0ac3d4b79f 
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=853baab97b1f3b03c1ffa55797e87867f5fb7ce33457411f56afd270cb395453 
Example Filename: SignInfoConsole.exe 
Detection Name: W32.853BAAB97B.in12.Talos

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