Hackers Breach Polish Power Plant Controls via Private Cellular Network and Shut Turbine

Attackers shut down a steam turbine and the process-water treatment system at a Polish combined heat and power plant by coming in over the private cellular network the local grid operator uses to reach remote equipment.

The plant supplies heat to roughly 50,000 residents. Recovery began at about 7:30 a.m. while the intruders were still active inside the network, and customers lost neither heat nor electricity.

CERT Polska disclosed the December 2025 incident on August 8 after an investigation lasting more than three months. Poland's prime minister had said in January that two CHP plants were hit. This is the second.

The route ran through a private APN, or access point name: a dedicated cellular data network managed by the distribution system operator. A configuration that allowed arbitrary devices on that APN to communicate with one another let the attacker pivot from a compromised wind-farm network to a controller at the CHP plant.

CERT says reaching an industrial control network through a private APN was, to the best of its knowledge, "the first instance of this attack vector being observed in a real-world cyberattack." The wind farm and the plant are separate facilities, and neither of them runs the network that linked them.

The report does not establish a CVE as the cause of the intrusion, and investigators could not determine whether a vulnerability in the Teltonika router had been exploited, so there is no single software patch to apply.

The WAGO controller reachable through the APN still had default admin credentials, while the private APN allowed client-to-client traffic. CERT's first recommendation is to audit the private APN configuration and switch on client isolation.

It also advises treating the APN as untrusted from the operational technology (OT) side, segmenting and restricting traffic, removing unnecessary management services from APN-reachable interfaces, and changing default credentials.

CERT says its surveys found that Polish organizations running private APNs commonly let any device on the network reach any other. It believes similar configurations are widely deployed in other countries. The router's SSH service, the controller's web interface and the permissive APN were all working as configured.

The attack path began at a wind farm, where a FortiGate device served as both firewall and VPN concentrator. Its VPN was exposed to the internet and allowed accounts without multi-factor authentication. The attacker had administrative privileges on the device and likely used them to obtain VPN credentials that could reach all network segments.

The distribution operator required communications to the substation's remote terminal unit to run over the serial DNP3.0 protocol, and that requirement was met. But no equivalent requirements covered the cellular router's management interface, which sat on a second interface, an Ethernet port connected to a VLAN behind the compromised firewall.

The wind farm met the DNP3.0 requirement it had been given and still supplied the route in. That requirement governed how data travelled, not how the device carrying it was administered.

The router was a Teltonika RUTX50 whose default password had been changed during deployment. Investigators recovered repeated successful SSH logins but could not establish how the attacker obtained that password.

As of August 11, The Hacker News reviewed the published vulnerabilities in the router's own firmware and found none that would hand an unauthenticated attacker its password. The two RUT-series flaws in CISA's 2023 Teltonika advisory, CVE-2023-32349 and CVE-2023-32350, both require existing privileges on the device, and the RUTX50's modem flaws cause only denial of service. An unpublished flaw is not ruled out.

Mobile-operator logs led CERT to assess that the attacker most likely used SSH tunneling through the router to reach the private APN. Starting December 18, the attacker scanned the APN and found a WAGO PFC200 controller exposing its web administration interface with default admin credentials. Subsequent SSH activity suggests the service was likely enabled through that interface, and timestamp correlation led CERT to assess that the attacker most likely tunneled through the WAGO into the plant's OT network.

On December 25, the attacker successfully connected to three Siemens PLCs over the S7 protocol, activity CERT considers most likely to have been reconnaissance for the later destructive actions.

On December 29, attacker activity inside the CHP network ran from about 5:30 a.m. until about 10:10 a.m., with plant recovery beginning at about 7:30 a.m. According to plant personnel, Siemens S7-300, S7-1200, and S7-1500 controllers were switched to STOP mode and password-protected, shutting down the turbine and the process-water treatment system and interrupting cogeneration.

Seven Moxa serial device servers and three switches were also factory-reset, given changed passwords and assigned unreachable IP addresses such as 127.0.0.1. CERT says the timing indicates with a high degree of confidence that those actions were automated. None of it required malware, and the report describes none.

Every destructive step used a supported device function, invoked over the protocols the plant runs on.

The attacker then damaged the way in. The WAGO controller's partition table was corrupted, leaving it unable to boot and yielding no useful logs. About 30 minutes after the last observed activity at the CHP plant, the attacker factory-reset the Teltonika router, changed its administrator password and assigned it the unreachable address 127.0.0.1, then factory-reset the FortiGate, causing its logs to be lost.

CERT says RutOS versions earlier than 7.07 retained their event database after a factory reset, which is why the SSH login records survived.

The plant did not initially read it as an attack. Maintenance was underway, so the operator logged the interruption as probable contractor error and reported it for information only; CERT opened an incident because it already knew of similar events. Reconnaissance inside the plant's network had run from December 18 to 25, including a port scan that started at the SCADA system's address.

No actor is named for this incident. The wider December campaign drew four separate assessments in January, from Poland's government, CERT Polska, ESET, and Dragos. Each is scoped differently, to the campaign's preparation, its infrastructure, the wiper malware used against its other targets, and its broader shape. None of them addresses this intrusion.

Private APNs still appear in federal guidance as an isolation option. A July 30 FBI and EPA advisory on attacks against internet-facing water-sector PLCs lists a private APN among the isolated architectures operators should consider for reaching OT equipment over cellular links.

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

Kimsuky Builds Offline AI Stack to Boost Phishing and Automate Malware Development

North Korea's state hackers are no longer content to type prompts into public chatbots. One of the country's main espionage groups has begun running artificial intelligence (AI) offline on its own servers, connecting document-search tools to files in its possession, and collecting the software parts needed to build AI into its malware.

South Korean security firm Genians says it uncovered the setup after months of tracking and log analysis on infrastructure tied to Kimsuky, a hacking unit under North Korea's Reconnaissance General Bureau.

Genians found no evidence that the group had trained an AI model of its own, and the firm does not offer that as reassurance. It describes an actor in a "research and knowledge acquisition" stage, assembling and testing existing tools rather than making new models, with the apparent aim of folding AI through the operation, from writing malware to analyzing data.

For an intelligence unit that has spent years phishing government, research, and other strategic targets, that points to attacks that are quicker to prepare and harder to spot.

With nothing here to patch, the weight lands on defenders. Once AI writes the bait, the tells they once relied on weaken: stilted translation, clumsy formatting, spelling mistakes. What an intrusion does on the machine becomes the thing to watch.

Genians' report tells defenders to correlate LNK execution, PowerShell, hidden scheduled tasks, GitHub traffic, and later payload activity instead of judging a lure mainly by how polished it looks.

The core evidence is tools for running language models offline: Ollama, GPT4All and Msty, all found on infrastructure Genians linked to the group. The report says they were run or configured, not merely downloaded: Ollama generated the keys created on first launch, while GPT4All carried a configured localdocs_v3.db, the database used by its LocalDocs retrieval-augmented generation (RAG) feature.

RAG lets a model answer from a private collection of documents. The database is evidence that the actor tried to connect documents in its possession to an AI system; it does not establish that those documents were stolen.

The researchers separately recovered an operator request to check a data set for wallet details, Gmail credentials and site-registration history, ending, "The more detailed the analysis, the better. Please do not do it haphazardly." The report could not confirm that this particular request was submitted to an AI service.

The group did not stop at ready-made apps. On the same infrastructure, the firm found developer libraries including LLaMaSharp, Microsoft's Semantic Kernel and Microsoft.Agents.AI, components for building AI functions into custom C# and .NET software.

It also found OpenAI's Whisper speech-to-text files with a guide on extracting text from audio, and active traces of Cursor, an AI-powered coding editor. None of these tools is exotic. What is new is a nation-state espionage group assembling them on purpose to push AI deeper into its own attack workflow.

The activity extends a Kimsuky campaign Genians calls Operation GitPower, which abuses GitHub repositories as command channels in an LNK-to-PowerShell infection chain and has distributed encrypted AsyncRAT payloads disguised as image files

Fortinet separately documented the broader GitHub-C2 pattern in April in attacks targeting South Korean users. That report corroborates the surrounding technique family, not Genians' new local-AI artifacts; Reuters said the new findings could not be independently verified.

The newly observed offline stack (the local models, RAG database, and transcription tools) has not been shown running against a victim in the reporting to date, and no GitPower victim count has been disclosed. Set against the broader "AI attack tools" framing, that is a narrower near-term change than the label implies, with the groundwork for automating parts of the operation still being laid.

Genians ties the operation to Kimsuky using overlaps with earlier campaigns, infrastructure clues, and North Korean vocabulary recovered from operator logs. The U.S. Treasury, which sanctioned Kimsuky in 2023, describes it as subordinate to the Reconnaissance General Bureau and primarily focused on intelligence collection.

The step also fits a pattern Genians flagged in 2025, when it linked Kimsuky to a spear-phishing attack that used ChatGPT-generated images of South Korean military employee ID cards.

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

ShapeBlue Announces General Availability of ShapeBlue Migrate

ShapeBlue is pleased to announce the first general availability release of ShapeBlue Migrate – an automated migration tool designed to help organisations move large-scale VMware environments to Apache CloudStack quickly, securely and with minimal disruption.

ShapeBlue Migrate v0.4.0 is now available to all ShapeBlue customers. It brings the essential stages of a VMware migration into one place, giving cloud operators greater control and visibility throughout the process.

The platform automatically discovers and inventories VMware environments, helps organise workloads into manageable migration waves, orchestrates migrations using multiple supported mechanisms and enables planned cutovers aligned with each organisation’s technical and operational requirements.

 

Built from real-world VMware migration experience

Since the early stages of Broadcom’s acquisition of VMware, ShapeBlue has worked with organisations evaluating and implementing alternatives to VMware-based infrastructure.

These projects have given our teams direct insight into the practical challenges of large-scale migration. Cloud operators need to understand complex VMware estates, identify workload dependencies, select the right migration approach and carefully coordinate cutovers – all while maintaining service availability and controlling operational risk.

ShapeBlue developed ShapeBlue Migrate in response to these requirements. Migrate applies intelligent automation to the migration process, helping organisations move from VMware to open-source cloud infrastructure through a more structured, repeatable and visible workflow.

Download the Product Brief

A structured approach to VMware migration

ShapeBlue Migrate supports the major stages of the migration lifecycle:

• Automated discovery and inventory: Build a clear view of the existing VMware estate and the workloads that need to be migrated.
• Migration-wave planning: Group workloads into logical waves based on technical and operational requirements.
• Migration orchestration: Coordinate workload migrations through multiple migration mechanisms from a central platform.
• Planned cutovers: Schedule and execute cutovers in line with maintenance windows, service priorities and business requirements.
• Centralised visibility: Track migration activity and progress from one place, improving coordination across technical teams.

This approach helps cloud operators replace fragmented, highly manual migration processes with a consistent framework that can support complex and large-scale environments.

Reducing risk through intelligent automation

Migration projects involve more than transferring virtual machines between platforms. They require careful planning, accurate infrastructure data and coordinated execution.

ShapeBlue Migrate uses automation to reduce repetitive manual work and create a more predictable migration process. By improving visibility across the VMware estate and structuring workloads into controlled migration waves, the platform helps organisations:

• Minimise service downtime
• Reduce the risk of migration failures
• Improve planning and operational visibility
• Apply consistent processes across migration waves
• Identify and manage migration risks earlier

 

Increasing migration efficiency

Manual discovery, workload classification and migration coordination can require significant time and specialist resources. ShapeBlue Migrate automates these activities wherever possible, allowing technical teams to focus on validation, architecture and operational decision-making.

The platform helps organisations:

• Automate infrastructure discovery and migration execution
• Reduce manual effort and repetitive tasks
• Coordinate migrations across large VMware estates
• Accelerate migration timelines
• Manage the migration lifecycle through a single platform

Download the Product Brief

Enabling long-term strategic change

For many organisations, migrating from VMware is part of a broader strategy to regain control over infrastructure costs, technology choices and future cloud development. By simplifying the transition to Apache CloudStack, ShapeBlue Migrate helps organisations:

• Accelerate their journey towards vendor independence
• Reduce reliance on proprietary virtualisation platforms
• Control virtualisation and cloud infrastructure costs
• Adopt a proven open-source infrastructure platform
• Build a more flexible foundation for future cloud services

 

ShapeBlue Migrate v0.4.0 is now available

ShapeBlue Migrate v0.4.0 is available to ShapeBlue customers as the first general availability release of the platform.

Combined with ShapeBlue’s Apache CloudStack expertise and hands-on VMware migration experience, ShapeBlue Migrate provides organisations with the technology, automation and specialist support needed to approach complex migration projects with confidence.

Download the Product Brief

Contact ShapeBlue to learn more about ShapeBlue Migrate or to discuss your VMware-to-Apache CloudStack migration requirements at info@shapeblue.com!

The post ShapeBlue Announces General Availability of ShapeBlue Migrate appeared first on ShapeBlue.

from CloudStack Consultancy & CloudStack... https://ift.tt/SDcJpjE
via IFTTT

TrueConf Server Flaws Exploited to Replace Client Installers with PhantomCore

The threat actor known as Head Mare has been observed weaponizing security flaws in unpatched TrueConf servers once again in attacks targeting Russian companies spanning instrumentation, electronics, transport, energy, IT, and software development sectors.

Russian cybersecurity vendor Kaspersky said it detected the attacks in July 2026.

The activity involves exploiting a vulnerability chain in the TrueConf videoconferencing server to replace the original TrueConf client installers with poisoned versions that deliver the PhantomCore backdoor and remote access trojan (RAT) into susceptible systems.

The vulnerabilities, tracked as KLCERT-26-057 and KLCERT-26-058, enable arbitrary code execution with elevated privileges. The attack impacts TrueConf server versions 5.3.x up to 5.3.9, 5.4.x up to 5.4.9, 5.5.x up to 5.5.5, and earlier.

The attack chain is as follows -

• Attackers connect to the TrueConf server on TCP port 4307, which is open by default.
• Upon successful connection, the attackers exploit KLCERT-26-057 to run a malicious script on the server.
• The script launches within an isolated environment on the server, limiting its access to operating system functions.
• The attackers then exploit KLCERT-26-058 to break out of the isolated environment and run arbitrary commands on the underlying host.
• The attackers run arbitrary code on the server with NT AUTHORITY\SYSTEM privileges.
• The attackers replace the file "...\public\js\locale.php" with a web shell to facilitate persistent remote access to the compromised server.

The web shell, per Kaspersky, has been leveraged to collect data on the IT infrastructure, gain privileged access to the TrueConf database, and ultimately substitute the original TrueConf Client distribution with an infected version containing PhantomCore.

What's more, the web shell serves as a conduit for another backdoor codenamed PhantomGraph that shares some level of code overlap with PhantomCore and includes two DLL modules -

"SysExcSvc.dll," for receiving commands and exfiltrating their results back to Microsoft OneDrive cloud storage that's used as command-and-control (C2)

"SysReadSvc.dll," for parsing the commands received by the first module, executing it, and storing the results

"To establish a persistent presence in the system, the attackers execute a Base64-encoded PowerShell command that installs SysExcSvc.dll and SysReadSvc.dll as Windows services," Kaspersky said. "We believe the attackers deliberately split this malware into two components to make it harder for EDR tools to detect."

In addition, the threat actors have been found to launch an SSH reverse tunnel, take a memory dump of the "lsass.exe" process, and collect general system information using commands like hostname and whoami.

The vulnerabilities have since been patched by the vendor in the latest TrueConf Server versions 5.3.9, 5.4.9, and 5.5.5 released on June 18, 2026. Organizations using TrueConf are advised to download the latest versions for optimal protection.

This is not the first time Head Mare has targeted zero-day flaws in TrueConf to single out Russian entities. Earlier this April, Positive Technologies disclosed that three vulnerabilities in the software (BDU:2025-10114, BDU:2025-10115, and BDU-2025-10116) were abused by the group since September 2025 to deliver PHP web shells and malicious payloads for information theft and command execution.

Around the same time, Check Point also reported that another high-severity security flaw in the TrueConf client (CVE-2026-3502) was exploited in the wild as a zero-day as part of a campaign targeting government entities in Southeast Asia to deploy the Havoc C2 framework.

ViPNet Update Mechanism Hijacked to Deploy HelloInjector and HelloProxy

The development comes weeks after Kaspersky said it discovered a new advanced persistent threat (APT)-style attack that has been ongoing since at least May 2026 using previously unreported tooling, primarily by taking advantage of the update mechanism for the ViPNet product suite to target Russian government, energy, transport, education, and logistics sectors.

The HelloNet attack involves the execution of a malicious DLL ("wtsapi32.dll") that masquerades as a legitimate file associated with the ViPNet suite update system. The loader DLL, dubbed HelloInjector, is sideloaded by the ViPNet update binary "itcsrvup64.exe," resulting in the execution of the malicious payload from within "svchost.exe."

"After starting, the malware checks the process in the context of which it was launched," Kaspersky said. "If the name of the main process is not svchost.exe, the loader starts iterating through all processes running in the operating system. It looks for a process whose name contains the string svchost, and whose command line contains the string netsvcs."

"If such a process is found, the loader injects itself into the target process using the NtWriteVirtualMemory and NtCreateThreadEx functions."

Once restarted inside the new process, the loader checks the process name a second time for the presence of the string "svchost." If found, HelloInjector loads and executes the malicious payload that's stored in its body in plaintext. The payload is a hidden proxy and a loader for additional modules retrieved from a C2 server. It has been codenamed HelloProxy.

Besides taking steps to interfere with the normal functioning of security solutions operating in user mode for filtering network connections, it serves as a loader for two components -

• HelloExecutor, to execute commands on the infected system and launch an SSH tunnel to attacker infrastructure
• HelloCleaner, to clean ViPNet software log files and erase forensic trail

Also discovered in one of the infected systems is a Rust implant named HelloBackdoor that can enable file uploads and downloads to and from the C2 server. Commands that do not match a predefined format are interpreted as instructions to be executed via "cmd.exe."

At this stage, it's clear how the threat actors are delivering the rogue "wtsapi32.dll" DLL to target machines. The activities have been tied to an unknown Chinese-speaking APT with low confidence, citing a reference to the Chinese website sina[.]com and an open-source software download mirror ("mirrors.ustc.edu[.]cn") hosted by the University of Science and Technology of China.

With fake updates for ViPNet having been leveraged in prior attacks targeting Russia, the findings indicate how widely-used programs in the country are becoming lucrative vectors for advanced threat actors.

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

Architecting a Multi-Hypervisor and Multi-Tenant IaaS Cloud with Apache CloudStack

Table of Contents

1. Executive Summary
2. Key Takeaways for Architects and Decision-Makers
3. Defining Multi-Tenancy as a First-Class Architectural Concern
4. Multi-Hypervisor IaaS: Coexistence by Design
5. Multi-Hypervisor IaaS: Designed to Coexist
6. vCloud Director Exit and Greenfield IaaS Builds
7. CloudStack’s Role as an IaaS Control Plane
8. Reference Architecture Patterns

 

Executive Summary

Modern IaaS platforms are heterogeneous by default. Multiple hypervisors, infrastructure tiers, and tenancy models coexist in the same environment, driven by cost optimisation, workload specialisation, regulatory requirements, and risk management.

The primary architectural challenge is how to consistently govern, operate, and scale multi-tenant, multi-hypervisor environments without fragmenting governance or operational processes.

In this blog post, we show why a resilient IaaS control plane is essential for a strong cloud architecture. When governance, tenancy, and lifecycle logic are embedded in the execution layer, infrastructure evolution leads to duplicated workflows, inconsistent policies, and operational silos. A control-plane-centric architecture, by contrast, separates governance from execution. This allows infrastructure layers to evolve while preserving a consistent service model.

 

Figure 1 – IaaS Control Plane and Execution Layer Separation

“The dashed line illustrates the architectural boundary between governance and execution. Above it, CloudStack operates as a control plane responsible for tenancy, policy, and lifecycle intent. Below it, heterogeneous execution pools provide compute, network, and storage capabilities without embedding governance logic.”

In this model, the multi-tenancy is central. Rather than being an infrastructure-level isolation mechanism, tenancy is treated as a first-class control plane concept. Structural multi-tenancy enables consistent delegation, policy enforcement, quota management, and accountability across heterogeneous execution environments. This supports enterprise internal clouds as well as commercial CSP and MSP platforms.

In this architectural model, Apache CloudStack is the IaaS control plane designed for multi-hypervisor and multi-tenant environments by architecture, not by transition. CloudStack coordinates heterogeneous execution layers through a unified governance and lifecycle framework, without replacing hypervisors or enforcing lowest-common-denominator abstractions.

This paper presents reference architecture patterns that show how enterprises, CSPs, and MSPs can build resilient IaaS platforms, managing diverse infrastructure as a single, unified service rather than as separate, siloed stacks.

Key Takeaways for Architects and Decision-Makers

The main challenge in modern IaaS isn’t picking the ‘right’ hypervisor—it’s keeping governance, tenancy, and lifecycle management consistent as environments become more diverse. When governance logic is embedded in execution-layer tooling, each new platform introduces fragmentation and duplicated operational models.

1. Heterogeneity Is No Longer an Exception. It Is the Operating Baseline.

Enterprise, CSP and MSP IaaS environments are structurally heterogeneous by default. Multiple hypervisors, infrastructure tiers, regions, and compliance domains coexist not because of incomplete migrations, but because they serve distinct cost, performance, risk, and regulatory needs. Architectures that assume homogeneity inevitably accumulate operational debt as diversity grows.

2. A Durable IaaS Architecture Requires a Dedicated Control Plane

Separating the control plane from the execution layer is no longer optional at scale. A centralised control plane provides a stable system of record for tenancy, policy, and lifecycle intent, allowing infrastructure strategies to evolve without repeatedly redefining operating models, access boundaries, or service semantics.

3. Multi-Tenancy Must Be Treated as an Architectural Construct, Not an Infrastructure Feature

Effective multi-tenancy extends beyond network isolation or resource partitioning. Structural multi-tenancy defined at the control plane level enables consistent delegation, quota enforcement, accountability, and lifecycle ownership across heterogeneous execution environments. This model scales equally well for enterprise internal platforms, CSP and MSP commercial offerings.

4. Multi-Hypervisor Coexistence Should Be Designed, Not Tolerated

Multi-hypervisor environments are most successful when treated as a long-term operating state rather than a transitional phase. Cost tiering, workload optimisation, resilience, and vendor risk management all benefit from intentional coexistence—provided governance and lifecycle consistency are enforced centrally.

5. Lowest-Common-Denominator Abstraction Is an Architectural Anti-Pattern

Simplifying heterogeneous platforms by stripping away platform-specific capabilities undermines the value of execution diversity. A strategic control plane coordinates differences rather than erasing them, preserving execution-tier depth while standardising governance and service behaviour.

6. Platform Exit Initiatives Are Often Governance Corrections Rather Than Technology Failures

Many “exit” initiatives are not driven by dissatisfaction with a platform’s technical capabilities, but by the inability of platform-bound governance models to survive infrastructure evolution. Decoupling governance from execution reframes these discussions from replacement to architectural correction.

7. CloudStack Fits Where Governance Must Outlive Infrastructure Choices

Apache CloudStack’s architectural value lies in its role as a control plane rather than as an execution stack. By maintaining clear boundaries between governance and execution, it provides a stable foundation for multi-tenant, multi-hypervisor IaaS environments where infrastructure choices can evolve independently of the service model.

8. Enterprise, CSP and MSP Use Cases Converge at the Control Plane Layer

While enterprise internal clouds, CSP and MSP-operated platforms differ in commercial and operational objectives, their architectural requirements converge at the control plane: delegated tenancy, consistent policy enforcement, lifecycle predictability, and accountability across diverse execution pools.

9. Strategic Advantage Comes from Operating Model Stability, Not Feature Accumulation

In mature IaaS environments, long-term success is defined less by feature richness and more by architectural durability. A control-plane-centric model enables incremental infrastructure evolution, reduces organisational risk, and preserves a coherent service experience over time.

Read our blog post Building a Compliant IaaS with Apache CloudStack

Defining Multi-Tenancy as a First-Class Architectural Concern

In IaaS architecture, multi-tenancy must be elevated from a functional “add-on” to a first-class architectural concern. Rather than viewing tenancy as a simple tagging mechanism or a set of firewall rules, a modern control plane treats it as the primary logical framework.

Structural vs. Infrastructure-Level Multi-Tenancy

Architects must distinguish between physical resource sharing and the logical structures that govern access and ownership. Infrastructure-level tenancy focuses on physical or network-layer separation.   This is often enforced through hardware boundaries or network segmentation tied directly to the execution layer. While necessary, this approach alone does not address governance, delegation, or lifecycle ownership.

On the other hand, structural multi-tenancy is implemented at the control plane level. It defines:

• how organisations – internal or external – are represented within the platform
• how resources are delegated
• how authority is distributed

This model enables recursive delegation, allowing a primary tenant to partition and manage resources for sub-organisations or projects without direct involvement from global infrastructure administrators.

Tenant Isolation, Delegation, and Policy Boundaries

A mature control plane sets clear boundaries for each tenant. It keeps tenants isolated and prevents interference. Delegated authority enables self-service and independent lifecycle management. Policies are enforced consistently across cost, compliance, and operations. These controls must remain effective regardless of where workloads are executed.

 

Figure 2 – Control Plane-Driven Multi-Tenancy and Delegation Model

“Logical view of how governance, delegation, and consumption boundaries are defined at the control plane level, independent of execution infrastructure.”

Enterprise Internal vs. CSP vs. MSP External Tenancy

While the architectural foundations of multi-tenancy are consistent, its role differs by operating model.

• Enterprise internal platforms: tenancy structures internal departments, teams, or projects. The focus is on controlled autonomy, cost visibility, and consistent governance operated by a central platform team.
• CSP environments: tenancy is directly tied to commercial service delivery. Structural isolation, delegated administration, and clear accountability are mandatory, as the infrastructure itself represents a revenue-generating product.
• MSPs: combines both models. Their tenancy model must support dedicated managed environments alongside shared cloud services, without fragmenting governance or requiring separate platforms. Customers consume different service types under a single, coherent control plane.

Across all models, the conclusion is the same: multi-tenancy must be enforced at the control plane level. Importantly, structural multi-tenancy does not inherently require shared infrastructure and can govern both dedicated and shared execution environments under the same control plane. Only then can policy, lifecycle behaviour, and operational consistency remain stable as execution layers evolve.

Multi-Hypervisor IaaS: Coexistence by Design

In modern IaaS environments, multiple hypervisors are no longer a transitional condition but a deliberate and sustained operating model. Across enterprises, CSPs, and MSPs, execution heterogeneity is driven by cost tiering, workload specialisation, and risk management. Many organisations now plan to operate multiple virtualisation platforms as a long-term strategy rather than converging on a single execution stack.

Figure 3 – A centralised IaaS control plane enforcing consistent tenancy, governance, and policies across heterogeneous execution pools.

 

Drivers for Intentional Heterogeneity

Organisations adopt multi-hypervisor architectures to address key business requirements:

• Cost tiering: Not all workloads justify premium infrastructure. Heterogeneous platforms allow architects to align workload criticality with appropriate cost and performance tiers.
• Workload alignment and resilience: Different execution environments are better suited to specific workloads, while hypervisor diversity improves resilience by reducing systemic risk and limiting the impact of platform-specific failures.
• Disaster recovery: Hypervisor diversity can lower capital costs at secondary sites while maintaining recovery objectives.

 

Coexistence vs. Transition Models

Coexistence by design differs fundamentally from transition-based approaches. Migration models treat secondary hypervisors as temporary targets with consolidation as the objective, whereas coexistence architectures treat multiple hypervisors as complementary execution pools operating side by side over the long term. By avoiding tight coupling between governance logic and specific execution layers, coexistence models prioritise operating stability and allow infrastructure strategies to evolve without forcing disruptive changes to governance or operating models.

Consistent Governance over Uniform Execution

In multi-hypervisor environments, architectural success depends more on consistent governance and lifecycle behaviour than on uniform execution. A strategic control plane shifts the focus away from standardising execution layers and instead decouples tenancy, policy, and lifecycle management from individual hypervisor toolchains, ensuring operational consistency even as execution environments differ.

Figure 4 – Siloed execution stacks on shared infrastructure, each enforcing its own access control, network policies, and tenancy model, leading to fragmented governance.

Through consistent exposure of governance and lifecycle functions via UI and API, the control plane maintains a stable operational experience independent of underlying execution environment changes, enabling simplified operations and long-term infrastructure evolution.

Avoiding Lowest-Common-Denominator Abstractions

A common pitfall in multi-hypervisor design is the use of lowest-common-denominator abstractions to simplify management. While superficially attractive, this approach undermines the value of heterogeneity by obscuring platform-specific capabilities and limiting optimisation across execution tiers.

An effective IaaS control plane coordinates heterogeneous execution environments without erasing their differences. It preserves execution-tier depth while enforcing consistent governance and lifecycle behaviour, allowing new hypervisors to be introduced without reworking policy or tenancy models. By treating multi-hypervisor operation as a permanent architectural state, organisations establish a durable foundation for control-plane-centric IaaS architectures.

Multi-Hypervisor IaaS: Designed to Coexist

Modern IaaS platforms increasingly run on more than one hypervisor. This is no longer just a temporary migration phase. For many enterprises, cloud service providers (CSPs), and managed service providers (MSPs), using multiple virtualisation platforms is now a deliberate long-term strategy.

Organisations choose this model to balance cost, performance, and risk. Instead of trying to force all workloads onto a single platform, they match different workloads to the environments that suit them best.

Why Organisations Use Multiple Hypervisors

There are several practical reasons for adopting a multi-hypervisor approach:

• Cost control: Not every workload needs premium infrastructure. Different platforms allow teams to place critical workloads on high-performance systems and less demanding workloads on lower-cost tiers.
• Workload fit: Some platforms are better for specific use cases, such as virtual desktops or low-latency applications.
• Resilience and risk reduction: Relying on one hypervisor creates a single point of failure. Using multiple platforms reduces the impact of outages or vulnerabilities.
• Disaster recovery: Running recovery environments on different hypervisors can reduce costs while still meeting recovery goals.

Coexistence, Not Just Transition

Traditional migration models treat extra hypervisors as temporary, with the goal of eventually moving everything to one platform. A coexistence model is different: it assumes multiple hypervisors will run side by side for the long term.

This matters because coexistence focuses on stable operations, not just moving workloads. By keeping management and governance independent from any one hypervisor, organizations can adopt new platforms in the future without major disruption.

Consistent Governance Matters More Than Uniform Platforms

Success in a multi-hypervisor environment depends more on consistent governance than on making all platforms behave the same.

Instead of forcing standardisation at the execution layer, organisations should use a shared control plane that provides:

• Unified provisioning
• Central monitoring
• Cost visibility
• Lifecycle management

This ensures consistent operations even when the underlying platforms are different.

A common mistake is trying to simplify management by using “lowest-common-denominator” features that work everywhere. This approach removes the unique strengths of each platform and limits optimisation.

vCloud Director Exit and Greenfield IaaS Builds

 

Why vCloud Director Architectures Are Being Reassessed

In the evolution of multi-tenant IaaS, platforms such as vCloud Director established a widely understood reference model for tenant representation, isolation boundaries, delegated administration, and service delivery constructs. This model has become the operational baseline for “how multi-tenancy is done” at scale.

As the market matures, vCloud Director–based approaches are reassessed due to architectural reasons, rather than purely commercial. The core driver is the growing tension between platform-bound governance and the reality of heterogeneous infrastructure. Over time, organisations accumulate execution diversity:

• additional hypervisors
• specialized infrastructure tiers
• new compliance zones
• regional footprints
• integrations with third-party services

When tenancy, lifecycle, and governance logic remain tightly bound to a single platform’s execution assumptions and toolchain, operational complexity increases and governance becomes harder.

The result is a familiar pattern: governance becomes fragmented, platform teams lose leverage, and environments begin to drift into silos – each with its own processes, access model, and lifecycle semantics.

The Control Problem Behind “Exit” Conversations

Many organisations are trying to recover architectural control as their environments evolve beyond a single, tightly coupled operating model.

In practice, exit conversations often emerge when the control problem becomes visible in day-to-day operations:

• multiple platforms require duplicate onboarding, provisioning, and governance workflows
• tenant boundaries are difficult to keep consistent across execution tiers
• reporting, metering, and operational ownership diverge between platforms
• self-service and delegated administration behave differently across environments
• platform teams spend more time integrating tools than improving the service

This is the point where the decision shifts from “which platform do we prefer” to “how do we design governance that survives heterogeneity.”

Evolving Multi-Tenancy Expectations E

Multi-tenancy is no longer limited to isolation and access control within a single platform; it is increasingly expected to behave consistently across the entire infrastructure estate.

What drives this evolution:

• Tenancy independent of topology: Tenants must be able to span infrastructure boundaries (clusters, zones, regions) without redefining identity, access policies, or governance semantics each time the execution environment changes.
• Consistency across execution tiers: Whether a workload runs on VMware, KVM, or a specialised environment, the tenant should experience consistent lifecycle patterns, reporting, quota enforcement, and operational responsibilities.
• Unified governance surface: Enterprises, CSPs, and MSPs increasingly require a single governance contract for provisioning, lifecycle, visibility, and accountability, independent of the underlying execution layer.

As a result, multi-tenancy becomes a control-plane concern first, with infrastructure-level isolation acting as an enforcement mechanism rather than the defining construct.

Coexistence and Selective Retention of VMware Workloads

A key reality in most “exit” scenarios is that VMware does not disappear overnight. The mature outcome is often a coexistence architecture where VMware continues to serve specific workloads while other execution layers are introduced to meet cost, flexibility, or operational goals.

Common patterns include:

• Premium tier execution: VMware remains a high-SLA tier for performance-sensitive or tightly integrated enterprise workloads.
• Constraint-driven retention: Certain workloads remain due to vendor certification constraints, operational risk tolerance, or legacy dependencies.
• Controlled dual execution: VMware and alternative hypervisors operate side by side, with governance and tenancy handled consistently above them.

Figure 5 – Tiered Execution Pools with VMware Retained as a Premium Platform under a Central IaaS Control Plane

“The strategic point is not to remove VMware. The point is to avoid creating a second siloed platform that replicates the same coupling problem in a different stack.”

Learn more about VMware to Apache CloudStack migration.

Greenfield IaaS Builds as an Opportunity to Avoid Legacy Coupling

Greenfield builds are often where organisations can correct the architectural mistake of coupling governance to execution. Instead of replicating the same platform-bound model, modern designs increasingly prioritise a standalone control plane that is decoupled from hypervisor tooling, physical topology, and vendor roadmaps.

In a decoupled approach:

• tenancy constructs, delegation, and policy boundaries remain stable as execution tiers evolve
• lifecycle semantics and governance remain consistent across heterogeneous environments
• new infrastructure options can be introduced without re-architecting the service model
• platform teams can focus on operating the service, not stitching together toolchains

This is particularly relevant for organisations building new internal platforms (enterprise) or new service catalogues (CSP/MSP). Greenfield is not just “new infrastructure”. It is a chance to design the control plane and operating model as first-class elements from the start.

CloudStack’s Role as an IaaS Control Plane

 

CloudStack as a Control Plane, Not an Execution Stack

Apache CloudStack can be understood as a control plane implementation for IaaS environments where heterogeneity and multi-tenancy are structural requirements. Its primary architectural role is to provide a consistent governance and lifecycle surface above execution layers, rather than attempting to standardise or replace them.

CloudStack sits at the layer where organisations define how infrastructure is exposed as a service:

• who can consume it
• under what policies
• with what boundaries
• with what lifecycle semantics

The execution layer remains responsible for workload processing and platform-specific capabilities, while the control plane provides the system of record for identity, tenancy, allocation, and lifecycle intent.

This distinction is central to CloudStack’s ability to support heterogeneous environments without collapsing them into a lowest-common-denominator model. The objective is not to enforce a single execution platform, but to provide a governance layer capable of coordinating multiple execution tiers consistently.

A Clear Split Between Control and Execution

CloudStack embodies the separation of control logic from execution in a way that is operationally meaningful. The control plane owns the administrative state of the cloud: tenancy structure, allocation boundaries, service definitions, and lifecycle actions as an intent model. Execution environments implement those actions within their own constraints and strengths.

The architectural value of this separation is durability. When governance and lifecycle models are embedded in platform-bound tooling, architectural change becomes disruptive. New hypervisors, new regions, new compliance zones, or new infrastructure tiers require the governance model to be reworked. A dedicated control plane reduces this fragility by keeping governance stable while execution evolves.

This is the core point: CloudStack does not attempt to eliminate heterogeneity. It makes heterogeneity governable.

Native Multi-Tenancy as an Operating Model

Multi-tenancy is not an implementation detail. It is the operating model of an IaaS platform. CloudStack treats tenancy as a structural construct in the control plane. It enables consistent isolation boundaries, delegated administration, and policy enforcement independent of physical topology or hypervisor boundaries.

This tenancy model naturally extends into the broader enterprise ecosystem. Core governance functions such as identity and access management can integrate with external identity systems, including enterprise directories (LDAP/Active Directory) and federated identity providers based on standards such as SAML2. This allows individual Domains to align cloud access with their own organisational identity models, including cross-organisation federation, while remaining governed centrally by the control plane.

Figure 6 – Control-plane-based multi-tenancy where individual Domains align with external identity systems while maintaining centralised governance.

Beyond identity integration, the control plane is designed to operate within a broader infrastructure ecosystem rather than as a closed, monolithic platform. It can integrate with external systems for networking services, automation, billing, and operational tooling, while governance intent remains centralised and execution and supporting services evolve independently.

This matters because “multi-tenant” means more than separation. It includes:

• Delegation and responsibility boundaries: Platform teams define what tenants can do, what they cannot do, and where responsibilities shift between provider and consumer.
• Consistency of lifecycle semantics: Tenants expect the same operational experience across execution tiers: predictable provisioning patterns, quota boundaries, and lifecycle behaviours that do not change simply because workloads land on different infrastructure.
• Accountability and visibility: Enterprises require internal transparency and governance across business units, while CSPs and MSPs require commercial-grade accountability and consumption visibility. In both cases, the tenancy model is inseparable from the governance model.

The key architectural implication is that tenancy becomes a portable logical layer. A tenant’s identity and policy boundaries remain stable even when workloads span multiple execution environments.

10 Reasons Why to Choose Apache CloudStack as a VMware Alternative

Coordinating Multi-Hypervisor IaaS Without Oversimplification

CloudStack enables a long-term multi-hypervisor state by providing consistent governance and lifecycle coordination while allowing execution platforms to retain their depth.

The common failure mode in heterogeneous environments is over-abstraction: attempting to force all platforms into the same minimal set of behaviours to simplify management. This is precisely what undermines heterogeneity, because it prevents organisations from using execution tiers for what they are good at.

A strategic control plane must do something subtler:

• provide a unified lifecycle and governance surface
• preserve execution-tier differentiation
• allow intentional workload placement across tiers without creating operational silos

This is where CloudStack’s control plane role becomes distinct from “tool sprawl” approaches. Instead of requiring a separate management worldview for each execution stack, the control plane keeps tenancy, policy, and lifecycle consistent while execution remains heterogeneous by design.

Strategic Boundaries and What CloudStack Does Not Replace

To keep the architecture clean, it is important to define what CloudStack is not trying to subsume.

CloudStack is not an attempt to replace the execution layer. It does not attempt to become the hypervisor, nor does it aim to replicate platform-native tooling for deep platform-specific administration. Its role is to orchestrate execution environments through a consistent service model and governance framework.

This boundary is strategically important for two reasons:

1. Preservation of execution-layer value: Organisations can retain mature, enterprise-grade execution choices where they make sense, without sacrificing governance consistency.
2. Avoiding new forms of coupling: If a control plane becomes a monolithic platform that must be adopted end-to-end, it risks recreating the same coupling problem it was meant to solve. A control-plane-centric approach must remain integration-friendly and execution-agnostic.

This is also why CloudStack fits naturally into greenfield designs as previously discussed: it allows organisations to define the governance surface first and then attach execution tiers as needed, rather than committing governance to the assumptions of a single platform.

Why This Matters for Enterprise and CSP and MSP Strategy

The value of an IaaS platform is defined by how well it sustains a long-term operating model as infrastructure evolves.

For Enterprises, the challenge is governance durability. As internal platforms grow to span multiple execution tiers, regions, and compliance domains, coupling governance logic to infrastructure tooling quickly becomes a constraint.

By anchoring tenancy, policy, and lifecycle semantics in a stable control plane, enterprises enable platform teams to operate as internal service providers. Governance remains consistent while execution layers evolve. This reduces the friction between platform, security, and infrastructure teams and avoiding repeated redefinition of access models and operational processes.

For CSPs and MSPs, multi-tenancy is not an architectural option but the foundation of the commercial model. Isolation guarantees, delegated administration, consumption visibility, and lifecycle consistency are contractual requirements. A control plane tightly bound to a single execution stack limits the provider’s ability to introduce new service tiers, optimize costs, or evolve infrastructure without fragmenting the service portfolio.

A control-plane-centric architecture allows providers to evolve execution tiers independently of the customer-facing service model, preserving tenant identity, governance rules, and operational workflows while adapting pricing, performance, and infrastructure strategy over time.

Strategic outcome

For CSPs and MSPs, the benefit is architectural rather than feature-driven. A durable IaaS control plane acts as the system of record for governance, tenancy, and lifecycle intent, allowing heterogeneous execution environments to operate as interchangeable fulfillment layers under a consistant service model.

This makes it easier to evolve the platform over time, lowers operational risk, and keeps the service model consistent even as the underlying infrastructure changes.

Reference Architecture Patterns

The following reference architecture patterns illustrate how a control-plane-centric IaaS architecture applies consistently across enterprise, CSP, and MSP operating models, without changing the underlying governance principles.

These patterns are not industry-specific or deployment-size dependent. Instead, they describe repeatable architectural structures that emerge whenever multi-tenancy, governance consistency, and execution heterogeneity must coexist over time.

Enterprise Internal Cloud — Delegated Multi-Tenancy under a Central IaaS Control Plane

Delegated Multi-Tenancy under a Central IaaS Control Plane

Figure 7 – Enterprise Internal Cloud — Delegated Multi-Tenancy under a Central IaaS Control Plane

“This pattern illustrates how internal enterprise cloud consumption can be organised through structural multi-tenancy, delegated administration, and consistent lifecycle governance, independently of execution platforms.”

Key characteristics:

• A single CloudStack control plane governs tenancy, access, quotas, and lifecycle.
• Domains and accounts map to organisational structures such as departments, teams, or product units.
• Multiple execution tiers (different hypervisors, hardware profiles, or Zones) coexist under the same governance model.
• Development, staging, and production environments follow consistent policies regardless of workload placement.

Architectural intent:

Enable enterprise platform teams to operate IT-as-a-Service without creating hypervisor-specific silos or duplicating governance logic as infrastructure evolves.

CSP-Operated Multi-Tenant Public Cloud — Hierarchical Tenancy under a Central IaaS Control Plane

Hierarchical Tenancy under a Central IaaS Control Plane

 

Figure 8 – CSP Multi-Tenant Public Cloud with Hierarchical Tenancy under a Central IaaS Control Plane

“This pattern applies to Cloud Service Providers delivering public, multi-tenant IaaS services to external customers at scale.”

Key characteristics:

• Customer Domains are first-class tenants, isolated structurally rather than through custom tooling.
• Sub-tenancy supports customer teams, environments, and projects.
• Shared infrastructure pools are governed centrally while execution remains abstracted.
• Lifecycle consistency and policy enforcement are maintained across all tenants.

Architectural intent:

Support commercial-scale IaaS delivery with predictable service behaviour, strong tenant isolation, and the ability to evolve infrastructure platforms without impacting customer-facing contracts.

MSP-Delivered Managed Private and Hybrid Cloud

Customer-Centric Tenancy with Unified Governance

This pattern represents Managed Service Providers (MSPs) delivering managed private cloud environments alongside shared cloud services under a single, centralised IaaS control plane.

Rather than operating separate platforms for private and public offerings, the MSP exposes multiple execution Zones under the same governance model, each Zone reflecting a specific service contract or consumption intent.

Figure 9 – Dual-Mode MSP IaaS Architecture with Dedicated and Shared Execution Zones

“This architecture illustrates how an MSP can combine per-customer dedicated execution Zones and a shared public cloud Zone under a single CloudStack control plane, while preserving consistent tenancy, policy enforcement, and lifecycle governance across all service types.”

Key characteristics:

• A single CloudStack control plane governs all tenants, Zones, and policies.
• Each customer is represented as a first-class tenant (Domain) in the control plane.
• Dedicated execution Zones provide managed private cloud capacity per customer, supporting contract-specific SLAs and compliance requirements.
• A shared execution Zone operated by the MSP provides public cloud–style capacity under strict structural tenant isolation.
• Customers may consume resources from one or multiple Zones without redefining identity, access models, or lifecycle semantics.

Architectural intent:

Enable MSPs to deliver contract-driven managed private clouds alongside shared cloud services using a unified control plane, avoiding platform sprawl, duplicated governance models, and hypervisor-specific operational silos. This approach allows infrastructure tiers to evolve independently while preserving a stable, predictable service model for customers.

Contact Us

Ready to explore how Apache CloudStack can support your infrastructure strategy?

Get in touch with us to discuss your requirements and see how we can help.

Get In Touch

 

The post Architecting a Multi-Hypervisor and Multi-Tenant IaaS Cloud with Apache CloudStack appeared first on ShapeBlue.

from CloudStack Consultancy & CloudStack... https://ift.tt/pic6HK2
via IFTTT

Solidity Pro VS Code Extensions Steal Crypto Wallets, API Keys, and Credentials

Cybersecurity researchers have flagged a malicious Microsoft Visual Studio Code (VS Code) extension named Solidity Pro ("solidity-pro") that has been observed delivering a browser wallet and credential stealer.

The names of the extensions are below -

• helper-beeps.solidity-pro
• web3devtoolsx.solidity-pro

Although neither of the extensions is now available on Open VSX, the GitHub repository for "web3devtoolsx/solidity-pro" continues to remain accessible as of writing.

According to Yeeth Security, early iterations of the extensions – from 1.0.0 through v2.4.x – were found to beacon to Cloudflare Workers endpoints to retrieve an encrypted Python payload and execute it.

Subsequent versions starting with v3.0.0, on the other hand, have shifted to a full-blown information stealer that can collect browser profiles, crypto wallets, source-control tokens, API keys, SSH keys, and Telegram bot tokens. The captured data is then exfiltrated via a Telegram bot upload.

The list of data harvested by the stealer is as follows -

• GitHub ghp_ and github_pat_ tokens
• GitLab glpat- tokens
• AWS keys and session tokens
• Cloudflare cfat_ tokens
• OpenAI sk-, sk-proj-, and sk-ant- keys
• Telegram bot tokens
• Mnemonic and seed phrases
• MetaMask, Phantom, Rabby, Coinbase, Trust, Keplr wallet vaults
• Bitcoin WIF / xprv
• SSH private keys (PRIVATE KEY)
• URL credentials and 1Password MFA tokens

The malware family is also equipped to bypass marketplace review, static scanning, and casual sandboxing through heavy obfuscation, intermediate clean versions to build trust, and randomized delayed activation that causes the malicious code to run several hours or days after installation.

"By the time the malicious branch runs, the user has already decided the extension is useful, and automated scanners that only observe the package for minutes have moved on," Yeeth Security said. "The obfuscation is not decorative; it splits strings across IIFE tables, reassembles them at runtime, and switches method names between releases so signature-based detection must track a moving target."

The cybersecurity company said the activity shares the same high-level playbook as WhiteCobra, another threat cluster that was detected in September 2025 as distributing Lumma Stealer through malicious VS Code extensions.

This is not the first time threat actors have published bogus Solidity extensions across open-source ecosystems. In June 2026, Yeeth Security flagged another extension named "ethdevtools.solidity-language-support" that impersonated a Solidity language-support tool for Ethereum developers, but harbored a delayed-activation clipboard stealer to scrape BIP-39 seed phrases, Ethereum private keys, and wallet addresses.

"When a recognized crypto address is on the clipboard, it replaces the pasted value with an attacker-controlled address," it added. "The swap happens through vscode.env.clipboard.writeText, a first-party API call that requires no child_process, no network access, and no file writes. Static scanners that only look for dangerous Node imports will not see it."

The findings also coincide with the discovery of a number of rogue VS Code extensions and npm packages -

• An npm package called "ascii-fetcher," which embeds the malicious code in a dependency named "@jaymara/jsononifier" to decode an embedded command (in the observed case, "calc.exe") and run it via "child_process.exec" with "windowsHide"
• A set of 10 VS Code extensions that deliver a wide range of Windows-based BAT, JavaScript, and HTA droppers, with two of them bundling an npm dependency that uses a postinstall hook to fetch and execute a remote payload
• A VS Code extension named "DigitalBarberTrim.html-entity-codec" that drops a remote VSIX file in select versions after enumerating known VS Code forks like Cursor, Windsurf, Codium, and Positron, while serving a "nearly empty stub" in others to fly under the radar.

Users who have installed the extensions are advised to remove them, inspect dependency graphs, block known command-and-control (C2) domains, and alert on use of cscript, mshta, cmd, curl, and powershell commands.

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

OpenAI's Next AI Model Astra Shows Cyber Performance Strong Enough to Trigger Pause

OpenAI has announced that it's pausing some "internal activities" involving its upcoming artificial intelligence (AI) model Astra after an internal evaluation found it had made significant advancements in agentic coding and cybersecurity.

In response to the discovery, the AI upstart said it's implementing security controls for higher-capability models and associated activities, such as isolated testing environments, restricted network and tool access, enhanced model weight protections and encryption, additional monitoring and detection capabilities, and sandboxed execution.

"We are pausing internal activities involving Astra that do not yet meet these strengthened security control requirements," it said in a statement.

"We have implemented universal monitoring for risky actions and misalignment across all agentic applications of Astra, including training and evaluation. Monitors evaluate the model's Chain of Thought and trigger a security response to review and interrupt high risk activity."

OpenAI said it will also work with relevant government agencies and select AI safety organizations to test out the model's capabilities, as well as sharing recommended security controls to third-party testing partners to run higher-risk evaluations and workloads safely.

The company said it "cannot rule out" the model has "Critical" cyber capabilities under its Preparedness Framework, which defines the threshold as follows -

A tool-augmented model can identify and develop functional zero-day exploits of all severity levels in many hardened real-world critical systems without human intervention OR model can devise and execute end-to-end novel strategies for cyberattacks against hardened targets given only a high level desired goal.

In other words, the model can discover and develop functional zero-day exploits of all severity levels in many hardened real-world critical systems without human intervention, or can orchestrate and execute end-to-end novel strategies for cyberattacks against targets when prompted a high-level desired goal.

OpenAI pointed out its preliminary evaluations of Astra indicate "strong enough performance" that it cannot eliminate the possibility that the model doesn't possess a "Critical" capability level at this stage. It also emphasized that Astra was not involved in last month's incident aimed at Hugging Face. In a recent academic paper, OpenAI touted that the model solved 10 open problems in mathematics and theoretical computer science for around $2,000 at Sol API rates.

OpenAI said it was sharing this information because it believes "it's important to be transparent with the public and the safety and security communities about this potential shift in capabilities."

"We believe advanced cyber-capable models should help defenders identify and address vulnerabilities before attackers do," it added. "We're committed to working alongside governments, safety institutes, and civil society to ensure that the frontier capabilities of models like Astra, and those that follow, are deployed responsibly and broadly for the benefit of all humanity."

The development is the latest sign of rapidly advancing cyber capabilities from frontier models, even as it marks the first time an AI lab has publicly committed to slowing progress due to cybersecurity concerns.

Earlier last week, the U.K. AI Security Institute (AISI) disclosed that its own evaluation found that AI models with access to the internet reached out into the real world to target individuals and organizations autonomously across 10 of the total of 122 runs. Of 19 such actions recorded, 17 originated from Anthropic's Mythos 5 and the remaining two involved OpenAI's GPT-5.6-Sol with cyber classifiers.

"In the most serious case, an agent tried to insert malicious code into an open-source project," AISI said. "In an attempt to get the code approved, the agent engaged in social engineering – creating fake online identities and using them to pressure the project's maintainer to approve the code. A human maintainer caught and refused to approve the malicious code."

"These attempts were unsuccessful, and our investigations have not evidenced any resulting real-world harm. But this is the first time we have seen risks around autonomy and deception manifest this clearly, without specific prompting, in the real-world."

The disclosure also comes amid revelations that models from Meta and Chinese company Moonshot, namely, Muse Spark ​1.1 and Kimi K3, escaped contained and targeted real-world targets, amplifying concerns about developers' abilities to sandbox increasingly capable AI systems. In both cases, the models have been found to weaponize network misconfigurations as opposed to independently identifying and exploiting a previously unknown vulnerability to reach the internet.

As AI models are tested against widely accepted benchmarks to examine how they perform offensive and defensive cybersecurity tasks in isolated test environments, Frontier Security said Kimi K3 found a network egress leak that enabled it to reach out github[.]com, clone an official repository for the benchmark problem it was supposed to be solving, and access the solution rather than solving the challenge by itself.

"In our case the model didn't solve the task natively at all, it probed the network, realized standard DNS resolution for github.com was functional (most other websites were blocked by the sandbox), cloned the official benchmark repository, and read the solution directly off the disk," Frontier Security said.

The ⁠growing list of ⁠incidents in ​which AI agents from major developers escaped testing environments in different ways and ended up breaching real targets that were not part of the experiment has prompted the creation of a new website, aptly named Felony Bench, to track these cases.

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

The Zitron Bear Case: What's Right, What's Wrong?

SUMMARY: In this episode, Aaron and Brendan tackle the provocative critiques of AI by Ed Zitron, a vocal opponent in the tech industry. They delve into the bear case against AI, exploring both the merits and flaws of Zitron's views.

SHOW: 1052

SHOW TRANSCRIPT: The Enterprise AI Show #1052 Transcript

SHOW VIDEO: https://youtu.be/Fm3T5bT_8CQ

SHOW SPONSORS:

• Nasuni - Activate your data for AI and request a demo

 Topic: The Zitron Bear Case — What's Right, What's Wrong?

• Why now? Ed Zitron went on CNBC's Squawk on the Street to lay out his bear case against OpenAI and Anthropic, covering questionable finances, AI's lack of ROI, and framing the whole thing as a symptom of the tech industry running out of hypergrowth ideas. CNBCX
• Past: Every hype cycle gets its designated skeptic — dot-com had its shorts, cloud had its "just a fad" crowd, crypto had its own chorus. Zitron's been running this playbook since the early ZIRP-era "subprime AI crisis" pieces.
• Present: Zitron's specific claims — OpenAI's burn rate math, the "nobody's making money on inference" argument, the case that Anthropic and OpenAI shouldn't be allowed to IPO with the numbers they'd have to report — stack up against actual usage/revenue data Brian and Aaron are seeing in the market. YouTube
• Future: If Zitron's right about the economics, what's the unwind look like? If he's wrong, what is he missing about where value actually accrues (infra, tooling, harnesses vs. raw model access)?

FEEDBACK?

• Email: show @ the enterprise ai show dot come
• Bluesky: @TheEntAIShow.bsky.social
• Twitter/X: @TheEntAIShow
• Instagram: @TheEntAIShow

from The Cloudcast (.NET) https://ift.tt/2Ci9W7x
via IFTTT

New CSS Attacks Can Break Webmail Defenses to Steal Passwords and Tokens

New research shows content inside an email can escape its message boundary and interfere with the webmail interface.

Across attack chains spanning Outlook, Gmail, Fastmail, Proton Mail, Yahoo Mail, and AOL Mail, the techniques can capture passwords, take over third-party accounts, leak tokens, hijack trusted UI actions, and manipulate AI tools that read email.

PortSwigger researcher Gareth Heyes presented the work at Black Hat USA 2026. One Outlook/Firefox chain spoofs a Microsoft sign-in screen and captures the password a recipient types. A Yahoo/AOL paste race can expose a Medium email-login token and let an attacker sign in as the victim. A Gmail/Cowork chain can exfiltrate a Slack token after prompt injection and user interaction.

The paper presents proof-of-concept research and does not report malicious exploitation. Public PoCs remain available as of August 8. The researcher said Fastmail fixed two CSS mutation bugs and a Proton Mail proxy bypass stopped working when he retested it, while Outlook label-jacking and Gmail's image-set() bypass still worked when the research was published on August 6.

The paper does not state whether the full Outlook password-capture chain was fixed. For webmail providers, the paper recommends isolating HTML email in sandboxed iframes and tightly restricting CSS, custom attributes, select menus, and image requests.

The research follows two paths: abuse HTML and CSS that webmail already allows, or create a discrepancy between what a sanitizer approves and what the browser or application ultimately creates. Both can cross the boundary between an untrusted message and its trusted interface.

Outlook shows how the pieces can combine. Allowed label elements can trigger controls outside the message, while application JavaScript can turn sanitized custom attributes into new DOM nodes carrying CSS outside the sanitizer's allow list. A media-query parsing trick then gave the attacker arbitrary CSS.

The chain disguises a select element as a password field, and Firefox resets its roughly one-second option-selection timer when the select moves offscreen, making capture real-time.

Yahoo Mail and AOL Mail exposed a different route. In Firefox, pasted HTML could briefly retain active CSS before sanitization. In the Medium demonstration, the attacker initiates an email-login flow, the victim copies attacker-supplied CSS to the clipboard, and then pastes it into a Yahoo or AOL draft. The resulting requests reveal enough of the 12-character login token for the attacker's server to reconstruct it, which can then be used to sign in as the victim.

The paper also introduces a click-based exfiltration technique for cases where Content Security Policy (CSP) blocks external resources. Given style injection and a numeric token rendered as text in the email, CSS can determine which digits occur and how often, hide non-matching links, and leave the matching link across the page. A victim click sends the digits and their frequency to the attacker's server.

AI-connected email creates another route. Gmail's image-set() fallback could make an external request despite sanitization. Heyes and PortSwigger colleague Pete Hendy chained it to an indirect prompt-injection email processed by Anthropic's Claude Cowork through a connected Gmail connector.

In the demonstrated setup, after the attacker triggered a Slack token confirmation email and the victim asked Cowork to process the emails, the injected instructions caused it to retrieve the token and place it in an HTML draft; viewing the draft leaked it.

A Fastmail demonstration targeted OpenAI's Atlas AI browser. CSS pseudo-elements and opacity made the human see harmless text while the model read hidden instructions. When the user asked Atlas to translate the visible text, the hidden prompt caused it to open tabs and encode the victim's name in URL fragments. OpenAI is deprecating Atlas and says it is scheduled to stop working on August 9, 2026.

Other findings include Fastmail "CSS hotwiring," which can redirect clicks into unintended and multi-step UI actions. An escaped-backslash Fastmail image-proxy bypass relies on an allow-listed user.fm domain to reveal when an email is viewed.

Heyes separately demonstrated a Proton Mail vector that exposed the recipient's IP address. Proton's current tracker-protection documentation says the service is designed to hide a user's personal IP address and exact email-open time.

The accompanying public repository contains PoCs for the disclosed techniques. The defensive guidance starts with strict isolation, then character allow lists for CSS validation, checks for CSS gadgets before allowing custom attributes, blocking select menus and dangerous selectors, and preventing attacker-controlled image requests and allow-listed domains.

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

Progress Kemp LoadMaster Flaw Hits CISA KEV After 792 Reported Exploit Attempts

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) on Friday added a critical-severity security flaw impacting Progress Kemp LoadMaster to its Known Exploited Vulnerabilities (KEV) catalog, following reports of active exploitation in the wild.

The vulnerability, tracked as CVE-2026-8037 (CVSS score: 9.6), is a command injection flaw that could be weaponized to achieve arbitrary code execution on susceptible devices.

"Progress LoadMaster contains a command injection vulnerability that allows an un-authenticated attacker to execute arbitrary commands on the LoadMaster appliance by exploiting unsanitized input in multiple command endpoints," CISA said.

In an analysis published in June 2026, watchTowr Labs described the issue as present in a function named "escape_quotes()" within the load balancer application and that it stemmed from improper handling of user-supplied input, ultimately enabling command injection.

Successful exploitation of the flaw can allow an unauthenticated attacker to run arbitrary commands on the affected appliance without having to possess valid credentials.

The addition comes a little over a month after eSentire said it's seeing active exploitation efforts targeting the flaw, although it noted those efforts were largely unsuccessful.

The attacks originated from the following IP addresses, per the Canadian security vendor -

• 192.42.116[.]58
• 192.42.116[.]105
• 146.70.139[.]154

According to telemetry data captured by KEVIntel, a total of 792 exploitation attempts have been observed over the last 41 days from 65 unique IP addresses from 18 countries, including Australia, China, Indonesia, Japan, Poland, and the U.S. The last activity was recorded on August 4, 2026, when five exploitation attempts were detected.

In light of active exploitation, Federal Civilian Executive Branch (FCEB) agencies are recommended to apply the necessary patches by August 10, 2026, to secure their networks in accordance with Binding Operational Directive (BOD) 26-04.

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