Ukraine Says Russian Intelligence Used Fake Support Texts to Steal Messaging Credentials

The Security Service of Ukraine (SSU) said it, together with the U.S. Federal Bureau of Investigation (FBI), uncovered a long-running campaign orchestrated by Russian intelligence services to break into the messaging accounts of government officials, military personnel, politicians, and activists in Ukraine, Europe, and the U.S.

The systematic cyber attacks aimed at stealing sensitive information from the victims, the agency added.

"The goal of these 'hacks' is to gain access to sensitive military, political, and economic information exchanged by users, as well as to steal their personal data," the agency warned in a post shared on Telegram.

To pull off the operation, the attackers send SMS messages that masquerade as the messaging platform's support bot and urge users to disclose their account credentials. 

The SSU noted that these attacks include not only organizations, officials or public figures, but also personal accounts belonging to Ukrainian nationals. It did not attribute the campaign to a specific hacking group.

However, similar attack waves directly aimed at Signal and WhatsApp messaging app users have been attributed to Russian threat activity clusters tracked as Star Blizzard, UNC5792 (aka UAC-0195), and UNC4221 (aka UAC-0185).

To counter the risk posed by such threats, it's advised to periodically review active messaging app sessions and log out of unknown connections, enable two-factor authentication, refrain from scanning QR codes received from unknown users, not disclose confirmation codes, PIN codes, passwords, and account recovery keys, and click on suspicious links or open files from unknown or dubious chats.

The development comes as the FBI attributed Russian Intelligence Services (RIS) cyber threat actors to an ongoing commercial messaging application (CMA) phishing campaign aimed at high-value targets to deceive them into handing over their backup recovery keys.

Late last month, the Computer Emergency Response Team of Ukraine (CERT-UA) attributed to the Belarus-aligned threat actor known as UNC1151 (aka Ghostwriter and UAC-0057) a spear-phishing campaign that targeted government organizations using compromised accounts to deliver an information stealer called OYSTERBLUES.

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

OpenAI Previews GPT-5.6 Sol With Restricted Access and Stronger Cyber Safeguards

OpenAI on Friday released three versions of GPT-5.6, called Sol, Terra, and Luna, as a limited preview to a small number of companies as part of an ongoing engagement with the U.S. government.

While Sol is the latest flagship model and the most powerful, Terra strikes a balance between efficiency and power, and Luna is fine-tuned for speed and affordability.

"GPT‑5.6 Sol launches with our most robust safety stack to date. We strengthened protections for higher-risk activity, sensitive cyber requests, and repeated misuse, and spent multiple weeks finding weaknesses, pressure-testing our system, and hardening it against real-world attacks," OpenAI said.

The model has also been touted as the "most capable model yet" for cybersecurity, making it much more suitable for vulnerability research and exploitation. On ExploitBench , GPT‑5.6 Sol is competitive with Anthropic Mythos Preview using only about one-third of the output tokens, OpenAI noted.

The goal, it added, is to enable access to legitimate work such as code review, vulnerability research, patch development, debugging, security education, and defensive testing, while enforcing strong guardrails that block offensive activity and swiftly remediating newly discovered jailbreaks. This includes adversarial attempts to jailbreak the model and refuse what it describes as "prohibited cyber assistance." 

"As these capabilities continue to advance, our priority is to make sure they reach and benefit defenders, who can use these tools to find weaknesses, develop patches, and strengthen systems more broadly," the artificial intelligence (AI) company explained.

That said, OpenAI is also warning that there may be scenarios during the preview phase where users may encounter safeguards that block or refuse legitimate requests, or have their requests paused for additional review, owing to the "dual-use" nature of the technology.

According to OpenAI's GPT-5.6 Preview System Card, although the model is more adept at finding vulnerabilities in code and developing exploits, the capabilities do not extend to carrying out autonomous, end-to-end attacks against hardened targets or weaponizing those cyber vulnerabilities in real attacks.

"Separate evaluations examined misaligned behavior in agentic coding tasks and found GPT-5.6 shows a greater tendency than GPT-5.5 to go beyond the user's intent, including by taking or attempting actions that the user had not asked for, though absolute rates remain low," it pointed out.

An evaluation of GPT-5.6 Sol against widely deployed hardened software projects using VulnLMP, which is OpenAI's internal framework designed to test end-to-end exploit chain development against real-world targets, has found the model to produce credible memory safety leads, some of which could lead to disclosure, mutation, or control flow corruption.

"This suggests that substantial parts of real world vulnerability research are becoming increasingly automatable when models are paired with tool use, build systems, and verification infrastructure," the tech upstart said.

OpenAI intends to make GPT‑5.6 Sol, Terra, and Luna generally available in the coming weeks, and it previewed the model capabilities to the U.S. government. It's also launching a limited preview for a small group of trusted partners whose participation has been approved by the government before a broader launch.

Earlier this month, U.S. President Donald Trump signed an executive order on AI and cybersecurity, calling for the creation of a framework that grants the federal government the ability to evaluate AI models' capabilities and determine which qualify as "covered frontier models," a designation for AI systems with advanced cyber capabilities.

The staggered release comes days after the company released an improved version of its GPT‑5.5‑Cyber model to trusted defenders as part of the Daybreak initiative and launched a new project called Patch the Planet in collaboration with Trail of Bits to help secure open-source projects.

It also follows the U.S. government's decision to permit Anthropic to release its Mythos AI model to a group of about 100 trusted companies and federal government agencies that "operate and defend critical infrastructure," more than two weeks after the powerful cybersecurity-focused models were pulled from the market.

"We're restoring access for these organizations quickly, and we're continuing to work with the government to expand access to Mythos 5 and make Fable 5 available for general use again," Anthropic said in a statement posted on X.

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

What Does EU AI Act Compliance Require?

For teams building AI-governed systems, the EU AI Act adds compliance obligations to every stage of the development lifecycle, from documenting training data to reporting incidents in production. With phased enforcement already underway, now is the time to assess where your workflows stand.

The EU AI Act (Regulation (EU) 2024/1689) is the world’s first comprehensive AI regulation. It entered into force in August 2024 with requirements rolling out in phases through 2027. The Act applies, among others, to any organization that places an AI system on the EU market, deployers of AI systems established in the EU, or whose AI system’s output is used in the EU, regardless of where that organization is headquartered.

This guide covers what each risk tier requires, the full compliance timeline (including the 2026 Digital Omnibus adjustments), transparency obligations, penalties, and what compliance looks like for the teams building and operating AI systems.

Key takeaways

• The EU AI Act uses a four-tier risk model; your obligations depend on how your system is classified.
• Prohibited practices and GPAI rules are already in effect; high-risk deadlines run through 2027.
• Article 50 regarding deepfake and synthetic content labeling obligations take effect August 2, 2026.
• Penalties reach €35 million or 7% of global turnover, enforced by national authorities and the EU AI Office.

The four risk tiers

The AI Act takes a risk-based approach. Every AI system falls into one of four categories, and the category determines the regulatory obligations that apply. This classification drives the entire compliance process.

1. Unacceptable risk (prohibited)

AI systems in this tier are banned outright under Article 5. These prohibitions have been in effect since February 2, 2025. The prohibited practices include:

• Subliminal, manipulative, or deceptive techniques that distort behavior and cause significant harm
• Exploitation of vulnerabilities related to age, disability, or socioeconomic circumstances
• Social scoring systems that evaluate individuals based on social behavior or personal traits
• Predictive policing based solely on profiling or personality traits
• Untargeted scraping of facial images from the internet or CCTV to build facial recognition databases
• Emotion recognition in workplaces and educational institutions (except for medical or safety reasons)
• Biometric categorization to deduce or infer certain protected characteristics (except for labelling or filtering of lawfully acquired biometric datasets)
• Real-time remote biometric identification in publicly accessible spaces for law enforcement, with narrow exceptions for missing persons, imminent threats, and serious crime investigations

2. High risk (regulated)

High-risk AI systems are subject to the most extensive compliance obligations. The Act identifies two paths to high-risk classification:

• Annex I systems: AI used as a safety component or product covered by existing EU product safety legislation (medical devices, machinery, vehicles) that requires a third-party conformity assessment.
• Annex III systems: AI used in eight sensitive areas: biometrics, critical infrastructure, education, employment, essential public and private services, law enforcement, migration and border control, and administration of justice.

Any AI system used to profile individuals within an Annex III use case is automatically classified as high-risk, regardless of other exemptions. Providers who believe their Annex III system is not high-risk must document that assessment before placing it on the market.

This is the tier that puts the heaviest demands on your logging, testing, and documentation pipelines.

Annex III exceptions: An AI system listed under Annex III is not considered high-risk if it performs a narrow procedural task, improves a previously completed human activity, detects decision-making patterns without replacing human judgment, or performs a preparatory task for an Annex III assessment.

3. Limited risk (transparency risk)

AI systems in this tier face requirements focused on transparency and disclosure. Under Article 50, deployers must ensure that users know they are interacting with an AI system (e.g., chatbots), and providers of generative AI must mark synthetic content as AI-generated. This tier is where deepfake obligations sit, covered in detail below.

For software engineers, this comes down to marking generated content in a machine-readable way and surfacing the disclosure where users actually see it.

4. Minimal risk (unregulated)

The majority of AI systems currently on the market, including spam filters, AI-enabled games, and recommendation engines, fall here. No specific regulatory obligations apply, though the Act encourages voluntary codes of conduct.

The compliance timeline

The EU AI Act’s requirements take effect in phases, not all at once. Some obligations are already enforceable. Others will not apply until late 2027.

Date	What takes effect
August 1, 2024	AI Act enters into force (Regulation (EU) 2024/1689 published).
February 2, 2025	Prohibited AI practices under Article 5 become unlawful. AI literacy obligations begin (Article 4).
August 2, 2025	General-purpose AI (GPAI) model obligations take effect (Chapter V). Governance bodies established. Penalty provisions become applicable. Code of Practice for GPAI published.
August 2, 2026	General date of application of the AI Act. Transparency obligations under Article 50 take effect, including deepfake labeling and synthetic content marking. Member States must have at least one AI regulatory sandbox operational.
December 2, 2026*	Machine-readable marking obligations under Article 50(2) apply to AI systems, including GPAI systems, which have been placed on the market before August 2, 2026 (four-month grace period). Article 5 prohibition on AI-generated non-consensual intimate imagery and child sexual abuse material becomes applicable.
August 2, 2027	Obligations for high-risk AI systems embedded in regulated products under Annex I (Article 6(1)). GPAI models placed on the market before August 2025 must be in compliance.
December 2, 2027*	Standalone Annex III high-risk AI system requirements take full effect (risk management, conformity assessment, technical documentation, CE marking, EU database registration).
August 2, 2028*	High-risk AI systems that are components of products covered by Annex I product safety legislation.

*Omnibus adjustment: The Digital Omnibus package revised these high-risk deadlines, moving the Annex III standalone high-risk deadline from August 2026 to December 2, 2027, and the Annex I embedded high-risk deadline from August 2027 to August 2, 2028. The European Parliament approved the package on June 16, 2026.

Obligations for high-risk systems by role

The EU AI Act distinguishes between providers, deployers, importers, and distributors. Their obligations differ by role.

Providers of high-risk AI systems carry the heaviest compliance burden. Among other obligations, they must:

• Risk management system: Establish and maintain a risk management process throughout the AI system’s lifecycle, not just at launch.
• Data governance: Ensure that training, validation, and testing datasets are subject to appropriate data governance and management practices and are relevant, sufficiently representative, and as free of errors as possible. Where these datasets contain personal data, the GDPR also applies: you need a lawful basis, data minimization, and, for any special-category data used to detect and correct bias, the specific safeguards.
• Technical documentation: Produce documentation that demonstrates compliance and provides authorities with the information to assess it. It shall contain, at minimum, the elements contained in Annex IV.
• Record-keeping and documentation: Design the system to automatically log events relevant to identifying risks and tracking modifications. Providers must keep certain documents for up to 10 years at the disposal of the competent authorities.
• Transparency and instructions for use: Provide deployers with clear documentation on the system’s capabilities, limitations, intended use, and human oversight requirements, which allows deployers to interpret a system’s output and use it appropriately.
• Human oversight: Design the system so that deployers can implement effective human oversight during use.
• Accuracy, robustness, and cybersecurity: Achieve appropriate performance levels across all three dimensions.
• Quality management system: Establish and document a QMS that covers the full compliance process.
• Corrective actions: Take necessary corrective action in case of suspected non-conformity of the AI system with the AI Act, including bringing it into conformity, withdrawing it, disabling it or recall it, as appropriate.
• Cooperation with authorities: Provide information and documentation necessary to competent authorities and giving access to automatically generated logs, upon request, to demonstrate conformity of the AI system with the AI Act.
• Authorized representatives: Providers established in third-party countries must appoint a representative established in the Union prior to making the high-risk AI system available on the Union market.
• Conformity assessment: Ensure that the appropriate conformity assessment procedure is completed prior to placing the AI system on the market. Additionally, drawing up an EU declaration of conformity, affix CE marking, and register the system in the EU database before placing it on the market.
• Post-market monitoring: Providers shall establish and document a post-market monitoring system in a manner that is proportionate to the nature of the AI technologies and the risks of the high-risk AI system.
• Reporting: Providers shall report any serious incident to the market surveillance authorities. The AI Act establishes different terms for reporting, which vary according to the incident’s severity. 

Deployers are natural or legal persons, public authorities, agencies or other bodies that use an AI system under its authority. Those using AI systems in the course of a personal non-professional activity are not considered deployers. Under Article 26, deployers of high-risk systems must:

• Use the system as instructed: Operate it the way the provider’s instructions for use specify.
• Assign human oversight: Put oversight in the hands of people with the competence and authority to exercise it.
• Govern input data: Where the deployer controls the input data, make sure it’s relevant and sufficiently representative for the system’s intended purpose.
• Monitor and escalate: Monitor the operation of the AI system, and if it starts to present a risk, notify the provider or the distributor and the market surveillance authority and suspend use.
• Keep logs: Retain the logs the system generates automatically, to the extent they’re under the deployer’s control, for at least six months.
• Notify the workforce: Tell affected workers and their representatives before a high-risk system goes live in the workplace.
• Inform affected people: When an Annex III system makes decisions, or assists in making decisions, about individuals, those individuals have to be told. This overlaps with GDPR transparency and where the system makes solely automated decisions with legal or similarly significant effects, so coordinate the AI Act notice with your GDPR notices.
• Support data protection assessments: Use the information the provider supplies to meet any data protection impact assessment obligation under the GDPR.
• Cooperate with authorities: Work with competent authorities on any action they take regarding the system.
• Register, if public: Public authorities must register the deployment in the EU database and shall not run a system while it isn’t.

Article 27 adds a fundamental rights impact assessment for a narrower group: public bodies, private entities providing public services, and deployers using Annex III systems for credit scoring or insurance pricing. Before first use, they document how the system will be used, who it could affect, the risks involved, and the human oversight in place, then file the results with the market surveillance authority.

For engineering teams, most of these duties come down to monitoring, log retention, and the ability to suspend a system fast. They get solved in your infrastructure, not in a policy document.

Important: Under the EU AI Act, operators in the AI-value chain can be considered both providers and deployers. Put your name on a high-risk system, modify one substantially, or repurpose a non-high-risk system into a high-risk use, and you’re reclassified as a provider with the full obligation set (Article 25).

Importers are the EU-based persons or organizations that place a non-EU provider’s high-risk AI system on the market, and Article 23 makes them a checkpoint for conformity before the system reaches EU users. Importers must:

• Verify conformity before import: Confirm the provider has completed the conformity assessment, drawn up the technical documentation (Annex IV), affixed CE marking with the EU declaration of conformity and instructions for use, and appointed an authorized representative.
• Block non-conforming systems: If there’s reason to believe a system isn’t in conformity, or its documentation is falsified, don’t place it on the market until it’s corrected. If the system presents a risk, inform the provider, the authorized representative, and the market surveillance authorities.
• Add contact details: Put the importer’s name, registered trade name or trademark, and contact address on the system, its packaging, or its accompanying documentation.
• Protect compliance in storage and transit: Make sure storage and transport conditions under the importer’s responsibility don’t compromise the system’s compliance.
• Keep records for 10 years: Retain a copy of the notified-body certificate (where applicable), the instructions for use, and the EU declaration of conformity for 10 years after the system is placed on the market or put into service.
• Respond to authorities: On a reasoned request, give competent authorities the information and documentation needed to demonstrate conformity, in a language they can readily understand.
• Cooperate with authorities: Work with competent authorities on any action they take to reduce or mitigate the risks of a system the importer placed on the market.

An importer that puts its own name or trademark on a high-risk system, or substantially modifies one already on the market, is reclassified as a provider and takes on the full provider obligation set (Article 25).

Distributors are the other parties in the supply chain who make a high-risk system available on the EU market. Their duties under Article 24 overlap with an importer’s but focus on what happens at and after the point of sale. Distributors must:

• Verify documentation before distribution: Confirm the system bears CE marking, comes with the EU declaration of conformity and instructions for use, and that the provider and importer have met their own obligations.
• Block non-conforming systems: If there’s reason to believe a system isn’t in conformity, don’t make it available until it’s corrected. If it presents a risk, inform the provider or importer.
• Protect compliance in storage and transit: Make sure storage and transport conditions under the distributor’s responsibility don’t compromise the system’s compliance.
• Act on non-conformity after sale: If a system already made available turns out to be non-conforming, take corrective action to fix, withdraw, or recall it, or ensure the provider or importer does. If it presents a risk, immediately inform the provider or importer and the competent authorities.
• Respond to authorities: On a reasoned request, provide the information and documentation on these actions needed to demonstrate conformity.
• Cooperate with authorities: Work with competent authorities on any action they take regarding a system the distributor made available.

The same reclassification rule applies: a distributor that brands a high-risk system as its own or substantially modifies one already on the market becomes a provider under Article 25.

Deepfake and transparency obligations (Article 50)

Article 50 creates specific transparency requirements for AI systems that interact with people or generate synthetic content. These obligations generally apply from August 2, 2026 and are relevant regardless of the system’s risk classification.

Who must comply

• Providers of AI systems that interact directly with people must ensure that individuals are informed they’re interacting with an AI system, unless this is obvious from the circumstances.
• Providers of AI systems that generate synthetic content (audio, image, video, or text) must mark that output in a machine-readable format that’s detectable as AI-generated or manipulated. The marking must be effective, interoperable, robust, and reliable.
• Deployers who use AI to create deepfakes must disclose that the content has been artificially generated or manipulated. The Act defines a deepfake as AI-generated or manipulated image, audio, or video content that resembles existing persons, objects, places, or events and would falsely appear authentic.
• Deployers who publish AI-generated text on matters of public interest must label it as AI-generated, unless the content has been through human editorial review and a natural or legal person holds editorial responsibility.
• Deployers of emotion recognition or biometric categorisation systems must inform the people exposed to the system that it’s operating, and handle their personal data in line with the GDPR.

Artistic exception regarding deepfakes: When AI-generated content is part of an evidently artistic, creative, satirical, or fictional work, only minimal and non-intrusive disclosure is required. The deepfake labeling obligation still applies, but the disclosure format can be lighter.

The Code of Practice for transparency

The European Commission developed a Code of Practice on marking and labeling AI-generated content to operationalize Articles 50(2) through 50(5). The code provides practical and technical guidance for real-world implementation of the marking and disclosure requirements. Its final version was published on June 10, 2026.

General-purpose AI model obligations

Chapter V of the Act creates a separate set of obligations for providers of general-purpose AI (GPAI) models. These rules have been applicable since August 2, 2025 (models placed on the market before that date have until August 2, 2027 to comply). The European Commission has published guidelines to support providers in meeting these requirements.

General-purpose AI models are the broad, multi-purpose models that show significant generality, perform a wide range of distinct tasks, and can be used directly as well as integrated into other AI systems.

All GPAI model providers

Every provider of a GPAI model must draw up and maintain technical documentation (which shall contain at minimum the information set out in Annex VI), provide information and documentation to downstream providers integrating the model, establish a policy to respect the EU Copyright Directive, and publish a sufficiently detailed summary of the content used for training.

Providers of free and open-license GPAI models (where parameters, architecture, and usage information are publicly available) do not need to comply with the obligations regarding technical documentation and provision of information to downstream providers, unless the model presents a systemic risk.

GPAI models with systemic risk

A GPAI model is presumed to carry systemic risk if it was trained using more than 10²⁵ floating point operations (FLOPs) of compute. That bar was set to capture the frontier models of the day: GPT-4 is widely estimated to sit above it, while the earlier GPT-3 was trained on roughly 30 times less. The Commission can also designate other models as systemic on criteria like the number of end users, high-impact capabilities, or output modalities.

Providers of systemic-risk models carry every GPAI obligation above, plus four more:

• Model evaluation: Run model evaluations, including adversarial testing.
• Risk mitigation: Assess and mitigate the systemic risks the model could pose.
• Incident reporting: Track and report serious incidents to the AI Office.
• Cybersecurity: Maintain an adequate level of protection for the model.

A voluntary Code of Practice for general-purpose AI models was published in July 2025. Following a code of practice creates a presumption of conformity until European harmonized standards are in place.

Penalties and enforcement

The EU AI Act establishes a three-tier penalty structure under Article 99, designed to be effective, proportionate, and dissuasive.

Violation	Maximum fine	Turnover threshold
Prohibited AI practices (Article 5)	€35 million	7% of global annual turnover
High-risk AI system non-compliance (specific provisions)	€15 million	3% of global annual turnover
Supplying incorrect or misleading information to authorities	€7.5 million	1% of global annual turnover

Enforcement is split between the European AI Office, which oversees GPAI model providers, and national competent authorities in each Member State, which handle all other operators.

Each Member State must designate at least one national authority for implementation and market surveillance. The penalty provisions are designed to account for the interests of small and medium-sized enterprises and startups, and Member States report annually to the Commission on fines issued.

What compliance looks like for engineering teams

The EU AI Act’s requirements are written in regulatory language, but they translate to concrete engineering concerns. If your team builds or deploys AI systems that serve EU users, here’s where the Act’s obligations intersect with your development workflow.

Inventory and classification come first

Compliance starts with knowing what you have. Every AI system the organization builds, uses, or procures needs to be cataloged and classified against the Act’s risk tiers. Record, for each system, whether it processes personal data and link the entry to your GDPR records of processing (Article 30) so the AI inventory and the privacy record stay aligned.

This is not a legal exercise alone. Engineering teams are typically the only ones who understand the actual capabilities, data flows, and deployment contexts of the systems they build. If your organization has an AI governance framework in place, the AI inventory is usually its foundation.

Audit trails are non-negotiable

The Act requires automatic event logging for high-risk systems and structured documentation across almost every tier. This means every decision an AI system makes, the categories of data sources it accesses, and every action it takes needs to be logged in a way that is auditable. 

Teams already shipping AI agents need structured event capture of system actions, including timestamp, session context, the tool or rule invoked, and the agent or service identity, scoped to system-health and security telemetry rather than individual worker performance. Exporting these logs to existing SIEM and compliance systems closes the gap between agent behavior and audit requirements.

Prepare your risk management system

Article 9 requires a continuous risk management process, including control measures for risks that can’t be removed by design. 

The ability to enforce policies is the mechanism that makes your chosen controls binding at the moment the agent acts, therefore acting as a risk mitigating strategy. This can happen at the agent level, by applying policies and rules to sandboxed agents, and at the tool level, with policies applied to the gateway that manages agent tool access.

Runtime isolation supports human oversight

The EU AI Act requires that high-risk AI systems be designed for human oversight, and that deployers can intervene during operation. For agentic workloads, where AI acts autonomously, this maps directly to runtime isolation: running agents inside sandboxed environments where network access, filesystem scope, and tool permissions are policy-controlled. 

If an agent exceeds its intended scope, isolation constrains the blast radius. This is the mechanism that makes oversight enforceable at the infrastructure level.

Transparency can be instrumented

Article 50’s deepfake and synthetic content marking requirements are a metadata problem. Providers need to embed machine-readable markers in generated content, and deployers need to surface human-readable disclosures. 

For teams building generative AI systems, this means integrating content provenance marking (such as C2PA or IPTC standards) into the generation pipeline. Where generated content depicts a real, identifiable person, it is also personal data under the GDPR, so the marking is necessary but not sufficient and the usual lawful-basis and rights obligations still apply. The AI governance controls your organization uses can enforce these policies at the platform layer rather than relying on each application to implement them independently.

Use the official compliance tools

The European Commission has launched the AI Act Service Desk, a single information platform that includes an official Compliance Checker to help organizations determine which obligations apply to their AI systems, an AI Act Explorer for navigating the full regulation text, and a helpdesk for submitting questions. These tools are free, official, and available in English, French, and German (with all 24 EU languages planned for 2026).

Start building compliance into your AI infrastructure

EU AI Act compliance is not a document you file. It’s a set of technical controls, organizational processes, and audit practices that need to be embedded in how your team builds and operates AI systems.

To make things easier, Docker AI Governance supports operationalizing these requirements. It does not replace the human oversight, classification, and legal accountability the AI Act assigns to providers and deployers, and customer code, configurations, and telemetry are not used to train Docker’s or third-party models. Instead, Docker AI Governance includes sandbox-based runtime isolation for blast-radius risk mitigation and real time monitoring, policy enforcement across network, filesystem, and MCP tool access, and structured audit logging that exports to existing SIEM and compliance systems.

Explore Docker AI Governance to see how runtime policy, audit trails, and agent isolation support the regulatory controls the EU AI Act requires.

Frequently asked questions

Does the EU AI Act apply to companies outside the EU?

Yes. Under Article 2, the EU AI Act applies to providers and deployers of AI systems regardless of whether they’re established in the EU. You are in scope if you place an AI system on the EU market, or if the system’s output is used in the EU.

Is there an official EU AI Act compliance checker?

The European Commission’s AI Act Service Desk includes a Compliance Checker tool that helps organizations determine which obligations apply to their AI systems. It walks through a series of questions about the system’s purpose, deployment context, and risk profile to identify relevant articles and requirements.

What are the EU AI Act deepfake requirements?

Under Article 50, providers of AI systems that generate synthetic audio, image, video, or text must mark the output in a machine-readable format as AI-generated. Deployers who use AI to create deepfakes (content resembling existing persons or events that would falsely appear authentic) must disclose that the content is artificially generated, even when the content is lawful. Artistic, creative, and satirical uses require only minimal disclosure.

These obligations take effect on August 2, 2026. Where a deepfake depicts a real, identifiable person, that content is also personal data under the GDPR, so labeling is necessary but not sufficient.

What is the difference between the AI Act and the Cyber Resilience Act?

The EU Cyber Resilience Act (CRA) targets products with digital elements and focuses on cybersecurity requirements across their lifecycle. The AI Act specifically targets AI systems and AI models, with requirements that scale based on risk classification. A product could be subject to both regulations, for example an AI-powered medical device that is both a product with digital elements (CRA) and a high-risk AI system (AI Act).

When do the high-risk AI system rules actually take effect?

The timeline depends on the type of high-risk system. Under the Digital Omnibus package, approved by the European Parliament on June 16, 2026, standalone Annex III high-risk systems must comply by December 2, 2027. Annex I embedded high-risk systems (products covered by EU product safety legislation) must comply by August 2, 2028. Check the official implementation timeline for the latest confirmed dates.

from Docker https://ift.tt/6lQjAIN
via IFTTT

FBI Warns Russian Intelligence Hackers Target Signal Backup Recovery Keys

The FBI and CISA have updated their March warning about Russian intelligence phishing Signal accounts, and the operators have added a step: they now coax targets into handing over their Signal Backup Recovery Key.

Hand it over once, and the attacker can restore the account's backup, read the private and group message history, and take over the account. Worse, the key keeps working. Make a new account on the same phone number, and the old key can still be used against it, the advisory warns.

The fix is blunt: generate a new key in Settings, which kills the old one for future backup downloads, and accept that anything the attacker already pulled is gone.

The updated advisory, PSA I-062626-PSA, adds two public tracking names the March notice lacked: UNC5792 and UNC4221. The FBI ties the activity to multiple Russian Intelligence Services (RIS) groups, including FSB officers embedded with the FSB Border Guards and others working for the Russian military services. The campaign hits Signal and WhatsApp accounts; the new recovery-key tactic the advisory describes is specific to Signal.

The targets are individuals of high intelligence value: current and former U.S. and international government officials, military personnel, political figures, journalists, and officials in Ukraine. The March notice said the broader campaign had already compromised thousands of accounts worldwide.

The phishing message poses as Signal support. Earlier waves asked for SMS verification codes and account PINs, or used doctored "group invite" links that silently linked an attacker's device to the account.

The updated version walks the target through turning on Signal backups, opening the Recovery Key, and pasting it into the chat. The advisory prints two sample messages: one dressed up as a mandatory two-factor rollout, the other as an urgent "data recovery" fix for messages supposedly at risk of loss.

As in March, the agencies are clear that none of these breaks Signal's encryption or the app itself. The actors compromise individual accounts through social engineering, then walk in through a legitimate feature.

Alongside the update, the State Department's Rewards for Justice program is offering up to $10 million for information on UNC5792.

The activity overlaps with warnings from Dutch intelligence (AIVD and MIVD), Germany's BfV and BSI, and France's ANSSI earlier this year. Google's Threat Intelligence Group first documented UNC5792 abusing Signal's linked-device feature in early 2025, and saw the same tradecraft turn up against WhatsApp and Telegram.

What to do now

• Treat any in-app message from "Signal support" as hostile. Real support does not message you inside the app to ask for codes, PINs, or your Recovery Key.
• Never paste your Backup Recovery Key, verification code, or PIN into a chat. Nothing legitimate asks for them that way.
• Open Settings, check Linked Devices, and remove anything you do not recognize.
• If you think you handed over your Recovery Key, generate a new one in Settings now, and assume any backup made before that is already in someone else's hands.

The March notice warned the tactics would shift. They have, from chasing one-time codes to taking the key that opens the entire archive. The encryption holds. The account is the weak point, and the person holding it is the target.

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

New SharkLoader Malware Deploys Cobalt Strike in StrikeShark Cyberattacks

A newly discovered cyber attack campaign has been observed delivering a previously undocumented malware family called SharkLoader that acts as a loader for deploying Cobalt Strike Beacon on compromised hosts.

Kaspersky, which is tracking the activity under the moniker StrikeShark, said the campaign has targeted a diplomatic organization in Indonesia, government organizations in Taiwan, software development companies across multiple countries, and entities associated with other sectors located in Hong Kong, Lebanon, Syria, Colombia, North Macedonia, Nepal, and Serbia. 

"The observed victimology suggests a campaign with broad geographic reach and a diverse target set rather than a narrow focus on a specific industry or region," the Russian cybersecurity vendor said.

The campaign does not exhibit direct links to any known threat actor or group, although the operators have utilized several open-source post-compromise tools like FScan and Pillager, commonly put to use by Chinese-speaking developers. It's believed that the campaign is the handiwork of a Chinese-speaking threat actor.

Attack chains involve the two initial access pathways: the exploitation of known Exchange Server flaws, such as CVE-2021-26855 (aka ProxyLogon), to strike the Indonesian diplomatic entity, or through a path traversal vulnerability impacting Openfire (CVE-2023-32315) in the case of Taiwanese software development organizations, or a critical remote code execution bug in GeoServer (CVE-2024-36401) to target a Colombian organization.

Other remote code execution and authentication bypass vulnerabilities weaponized by the threat actor are listed below -

It's assessed that the threat actors are likely employing publicly available proof-of-concept (PoC) exploits hosted on GitHub or other open-source platforms to gain initial access in an opportunistic manner. Upon gaining a foothold, the threat actors establish persistence by deploying web shells to trigger a DLL side-loading chain involving "SystemSettings.exe" (CVE-2021-27076) to deliver SharkLoader ("SystemSettings.dll").

A second method used by StrikeShark to distribute the loader is via custom dropper executables masquerading as legitimate software installers or applications like Google Update and Cisco AnyConnect, and executing the malware loader once the installation process completes. The method by which these droppers are delivered is currently unknown.

"In addition to installer-themed lures, several SharkLoader droppers use decoy PDF documents to persuade victims to open the malicious file," Kaspersky explained. "However, not all samples employ this technique, as some droppers function solely as a delivery mechanism for SharkLoader without presenting any lure content."

Once the DLL is loaded, SharkLoader implements what's called Perfect DLL Hijacking, a technique detailed by security researcher Elliot Killick in October 2023, to execute malicious code while bypassing Windows Loader Lock, a system-wide lock held by the operating system when loading and unloading DLLs.

Specifically, it's engineered to decrypt and load "DscCoreR.mui," which is then used to decompress and load Cobalt Strike in a new thread created in a suspended state, along with two other components -

• SyncRes.dat, which installs multiple Windows API hooks by using the Microsoft Detours library to monitor exceptions generated during runtime.
• MinHook DLL, which installs API hooks for the VirtualAlloc and Sleep functions to copy the decompressed Cobalt Strike Beacon into the allocated memory region using VirtualAlloc. The Sleep-related hook is triggered when the Beacon calls Sleep, likely in an attempt to evade memory scanning techniques that identify executable (RWX) code regions in memory.

"Finally, after the API hooks are installed and the Cobalt Strike Beacon shellcode has been written to the thread buffer, the malware calls the ResumeThread API to resume the suspended thread and begin execution of the beacon," Kaspersky explained.

While SharkLoader does not come with persistence mechanisms built into it, the threat actor has been found to leverage Registry Run keys and scheduled tasks as a way to activate the launch of "SystemSettings.exe" either when a user logs in, or even if no user is logged in.

The attacks also involve an extensive reconnaissance phase following initial compromise and persistence, with the threat actor engaging in Active Directory enumeration, credential theft by targeting the LSASS process and the NTDS database file, and deploying open-source scanners and information gathering tools like FScan, Searchall, and Pillager.

Given the absence of active data exfiltration, it's unclear what the end goals of StrikeShark are. However, the targeting of government and software development organizations suggests a cyber espionage bent with a potential interest in hoovering political intelligence or intellectual property.

"At the same time, the use of SharkLoader and Cobalt Strike, alongside the exploitation of public-facing applications and malicious installers and droppers, suggests the attacker may also be opportunistically targeting vulnerable systems," Kaspersky said. "The absence of clear evidence of data exfiltration thus far does not exclude this possibility, as Cobalt Strike’s file operation and data exfiltration modules could be employed at a later stage."

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

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