Below the Harness: Governing a Multi-Model, Multi-Harness World

We believe the future is a multi-model, multi-harness world. And we think it needs a new trust model.

In 1988, Norm Hardy described a problem that had been quietly breaking systems for years: the confused deputy. A program that takes action using its permissions instead of yours.

Today, every AI agent is that deputy. It inherits your authority: Your credentials, your repo access, your ability to call APIs. But its behavior is probabilistic. It might be acting on an instruction found in its environment, on a step it invented, or on a confident wrong answer. 

The industry didn’t fix the confused deputy problem by making the deputy itself more careful. They fixed it by moving its authority a layer away. Forty years on, that’s still the answer.

Everyone is converging on the same future

Three facts are pushing the industry toward the same conclusion.

1. Agents are expensive loops. An agent takes many steps, and you pay for every token of every one. We all can agree that it makes no economic sense to call the latest frontier model for simple tasks. 
2. The leader of frontier capability changes often. We’re all aware that the top model of the day (and its vendor) changes every couple of months.
3. Your workflows may need custom models. Many teams are recognizing that intelligence is commodifying and the differentiator is custom models, derived from custom context.

As a result, all of us are quickly ending up with a portfolio of multiple models across multiple harnesses. 

A similar convergence is happening one layer up. Developers pick certain tools for the right task, the way they always have. For example, perhaps Claude Code for long refactors, Codex for daily work, Hermes for quick scripts. 

It’s reasonable to expect the future of work to be multi-model and multi-harness.

Which makes trust the defining question

A lot of agents work the same way. 

They read material that is often out of our control: support tickets, web pages, documentation, and code written by strangers. But they act with authority you granted: your credentials, repo access, production APIs, and the open internet. And they usually do both from a developer’s laptop, outside typical security guardrails like VPCs and IAM.

Private data and the ability to act autonomously, together, is what makes an agent worth deploying. Your deputy needs the ability to execute in order to be useful. Which means the interesting question is no longer which model is best. It’s what happens when one of these deputies is wrong, or manipulated.

Per-harness guardrails break down

The obvious answer is that each harness ships its own guardrails. Many do. But relied on as your security boundary, they fail in three ways.

1. The agent talks past them. Guardrails inside the harness are enforced in the same loop the agent is running. Deny it a git push and it reaches for the API. Deny the API and it opens a gist. Deny the gist and it tucks the data into a channel you trust and never inspect. Researchers showed last year that a single malicious issue filed in a public GitHub repo could steer a coding agent into reading a company’s private repositories and publishing the contents in a pull request the agent opened itself. Nothing was hacked since every step used the agent’s own legitimate access, through a channel everyone trusts. A boundary the agent can negotiate with is not a boundary.
   
2. The rails move without you. Most harness’s isolation models are closed source and ship on their vendor’s schedule. The major coding agents have each revised their default sandbox and approval behavior several times in the past year alone. Updates to sandboxing models should be treated as a security event. Multiply this by ten harnesses and your security posture is, at any moment, whatever is the patchwork of your half dozen vendors’ measures.
   
3. The rails don’t cover the fleet. The custom agent your platform team built has exactly the guardrails your platform team wrote. The agent inside your support SaaS has whatever its vendor chose, and most expose no isolation controls to you at all. Every new harness means building or auditing governance again, from scratch, differently. You end up with a dozen implementations that drift apart, each blind to the others’ traffic, with no single place to set a rule and no single record to understand why something went wrong.

Safety cannot depend on the agent making the right decision, or on someone else’s release schedule.

A layer below

So here is what we believe. The future is multi-model and multi-agent. And given that future, we believe every organization will need a layer below: a runtime layer, below the harness, that all of them run on top of.

The reasoning is straightforward. Strip away the model, the vendor, and the framework, and an agent has two ways to affect anything. It runs code, which touches files and opens network connections. Or it calls a tool, which acts on a system. Everything an agent does travels one of those paths. And both paths cross the same surface: the runtime, where processes execute, credentials get used, and requests leave the machine. Every agent passes through it, no matter which model powers it, which vendor shipped it, or whether you built it yourself. That makes it the one place where rules you define can be enforced across all your agents. It is also the same fix as 1988, applied to today’s deputy: the authority sits a layer away.

Put enforcement there and each of the three failure scenarios we spoke about flips around.

Your agents can’t talk past themselves. The boundary for an agent sits outside the loop the agent is running, so it holds steady no matter if the model is with you, hallucinating, or compromised. A hard neutral boundary at the runtime is more effective than a prompt-level boundary the agent creates for itself.

The rails stop moving randomly. Policy is yours, written once, covering execution, tool calls, credentials, and spend. Now, a model or agent vendor making an update won’t randomly change your security posture.

The rails cover your whole fleet. A policy you write up will apply to every harness. And every action, by all your agents, lands in one record: what ran, what it touched, which rule decided. 

This is what lets you be nuanced about agents. Without a boundary below your harnesses, you have three bad options: block agents completely, allow all of them and hope for the best, or wedge a manual approval into every step and give up the productivity you wanted.

A boundary at the runtime gives you a fourth option. When consequences are bounded even if an agent goes off the rails, you can start granting it true autonomy, which is the goal.

We expect models to keep changing and new harnesses to land in all of our toolkits. That part is healthy. The boundary underneath them is the part that should hold steady.

At We Are Developers in San Jose, Tushar Jain, Docker’s CTO, will talk more about this world: multiple models, multiple harnesses, and a single runtime under it all.

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

How to keep Manufacturing IT failures from stopping production

Every plant wants the same simple thing: keep the line moving, all the time, without surprises. That’s easier said than done, because there are two very different ways production can grind to a halt. Sometimes it’s mechanical – a tool breaks, a conveyor jams, a part wears out past what it can handle. But just as often, it’s not the machine at all. It’s the systems running behind it: a Manufacturing Execution System (MES) instruction that never shows up, a historian that quietly stops logging, or a login screen that won’t let a reviewer sign off on a batch. Either way, the line stops, and money starts slipping away the moment it does.

The second kind of problem, on the IT and control-system side, needs a different fix. A failed server, network link, or storage system shouldn’t be able to bring production to a standstill. And when a failure does happen, the plant needs to recover fast enough that operators aren’t left waiting on an infrastructure rebuild.

First step: figure out which parts of the IT infrastructure the production workflow actually depends on.

Manufacturing IT infrastructure starts with the production workflow

Manufacturing IT infrastructure is the technology chain connecting business systems, plant applications, operators, and the equipment making product. An order enters through the Enterprise Resource Planning (ERP) system, a recipe or work instruction reaches MES, an operator confirms a step through a Human-Machine Interface (HMI), and a Supervisory Control and Data Acquisition (SCADA) system coordinates the equipment carrying it out. Each handoff depends on the previous one.

Downtime anywhere in that chain touches more than the immediate step. A stalled MES instruction delays the order behind it. A historian outage breaks the process record a quality reviewer needs later. An identity or network failure can block a quality release even when the physical batch is sitting there, finished and fine, waiting for a signature that a broken login screen won’t let anyone give.

This is why a service can look online while the production workflow it supports stays unusable. The MES web page may load, while the database behind it can’t be reached. The interface between MES and the historian may be down, leaving the two systems with different views of the batch state. None of that shows up as a single alarm. It shows up as a line that won’t move and an operator who isn’t sure why.

That dependency chain is what you need to protect when you design manufacturing IT infrastructure. Looking at individual servers or applications in isolation isn’t enough.

Important infrastructure layers

Industrial IT infrastructure is built from the same layers as any data center: compute, storage, virtualization, networking, identity, monitoring, and backup, plus whatever runs in the cloud or at the edge. What’s different is the plant conditions around those layers, and how directly each one maps to something that stops production.

Compute and virtualization host MES, SCADA supervisory components, historians, and plant databases. Storage holds process data, batch records, and recipes, usually with a local replica for failover and a separate copy for recovery. The plant network carries traffic between controllers, HMIs, and servers, and it needs to stay separate from the enterprise network that carries email, file shares, and other business traffic. Identity decides who can log in to MES, approve a quality release, or push a configuration change to a controller. Monitoring and backup tell you a failure happened and let you recover from it.

The boundary between Information Technology (IT) and Operational Technology (OT) sits inside this stack, and it matters because the two sides have different tolerances. IT can usually accept a reboot and a five-minute wait. OT often can’t.

IT/OT convergence changes how these systems are connected, but it doesn’t remove that tolerance gap.

Plant conditions make infrastructure management harder as well. Equipment may have to operate in cramped cabinets, heat and dust can shorten hardware life, power quality may be inconsistent, and legacy protocols may assume a flat and trusted network. Maintenance windows are often short, and many plants have little or no local IT staff available when something fails overnight.

For that reason, tie each infrastructure layer to a specific production dependency. A storage array may hold the batch record a quality review needs. A switch may be the only path between an HMI and the controller it’s trying to reach. That perspective makes it easier to spot which failures demand immediate failover and which can wait for standard recovery.

Which plant workloads can’t wait for the cloud?

Some applications need to keep running even when the connection to a central data center or the cloud is down. MES, SCADA, HMI, historians, plant databases, identity services for plant logins, machine-vision inspection, and parts of Quality Management System (QMS) or Laboratory Information Management System (LIMS) functionality typically fall into this group. They sit close to the physical process, and a Wide Area Network (WAN) outage can’t be allowed to stop them.

Other systems can tolerate delayed connectivity. ERP, Product Lifecycle Management (PLM), fleet-wide analytics, AI model training, reporting, and long-term archives generally don’t need millisecond response times. They can usually queue updates until connectivity returns.

The placement decision should be made workload by workload. Ask a few practical questions:

• How much latency can the application tolerate?
• Can it operate at all during a WAN outage, and for how long?
• How much data does it generate, and does that data need to stay local for volume or regulatory reasons?
• What Recovery Time Objective (RTO) and Recovery Point Objective (RPO) does the workflow behind it actually require?
• Does the application vendor support running the way you want to deploy it?

Once you’ve answered these for each workload, the local-versus-central split becomes much clearer.

Where should manufacturing workloads run?

On-premises, cloud, and hybrid designs each place workloads in different failure domains. The goal is to pick a model that matches what each production workflow actually needs.

On-premises keeps machine-facing services close to the equipment and reduces how much depends on the WAN. This matters for workloads that can’t pause during a connectivity outage.

Cloud platforms cut the amount of local hardware the plant needs to operate. At the same time, connectivity, identity services, provider availability, and data-location requirements all become part of the failure model. For some industries, where the production data sits and how it’s handled also bring in extra regulatory considerations.

Hybrid designs are the common middle ground in manufacturing: plant-critical systems stay local, and everything that can tolerate delayed synchronization runs centrally or in the cloud instead.

None of these models is automatically the right answer for every site. A plant with a reliable, well-provisioned WAN link can lean more on centralized or cloud services than a remote site on a single unreliable connection. The decision should follow what each workload actually needs, not a default architecture applied everywhere.

When you review a manufacturing environment, start with the production workflow, map its dependencies, and then decide where each component should run. That gives you a much clearer basis for designing high availability, backup, and disaster recovery in the next stages of the infrastructure plan.

Why different manufacturing sectors need different infrastructure

The same uptime target produces very different infrastructure priorities depending on what’s being made. A stalled line hits a discrete parts manufacturer differently than a pharmaceutical batch process, even when both call it “an hour of downtime.”

The difference becomes clearer when you look at the workflow behind the production line. Some environments depend on continuous process control, while others rely on tightly synchronized assembly, batch records, or high-volume data collection. Infrastructure resilience has to account for those differences.

 

Sector	Typical workload	Downtime impact	Infrastructure priority
Automotive	Synchronized assembly, just-in-time sequencing, robotics control	A line stop can cascade to downstream stations within minutes	Low-latency MES/SCADA, fast local failover, redundant plant network
Food & beverage	Batch and recipe management, cold-chain monitoring, clean-in-place cycles	Product loss, batch rejection, food-safety non-conformance	Reliable local historian, accurate batch records, deterministic recovery
Pharmaceutical & life sciences	Batch execution, electronic batch records, environmental monitoring	Batch may be scrapped or quarantined pending investigation	Validated, auditable failover; recovery that preserves record state
Electronics & semiconductor	Fab tool control, yield and metrology systems, cleanroom environmental control	Wafer scrap, tool requalification, yield excursions	Very low latency, high-IOPS storage, tight tool-to-MES integration
Chemical & process	Continuous process control, distributed control systems, safety instrumented systems	Unsafe shutdown or restart, environmental exposure	Segregated OT network, isolated safety systems, reliable historian
Industrial equipment	Discrete manufacturing, ERP-driven work orders, quality inspection	Missed order commitments, rework	Balanced local/central split, moderate RTO tolerance
Aerospace & defense	Traceability-heavy discrete manufacturing, configuration control, supplier quality data	Non-conformance findings, audit exposure, program delay	Long-term data retention, strict access control, traceable recovery

 

The pattern behind the table matters more than any single row. Recovering the server is only step one. In an automotive plant, MES can come back online in minutes while the historian reconnects on its own schedule, and until it does, you’re running the line without the process data quality needs to release the shift’s output. It’s a different problem entirely in pharma: a server can be back up in ten minutes while the batch record shows a gap that triggers a full investigation before that batch can ship. The workflow recovery target isn’t the same as the server recovery target, and sector context is what tells you which one to design around.

How production IT fails

Most production outages aren’t caused by exotic infrastructure failures. Servers fail, storage paths drop, WAN links go down, power problems can take cooling systems offline with them. Databases run out of capacity. A routine update introduces a regression that never showed up in testing.

The less obvious dependencies are usually the ones that bite you. DNS, directory services, license managers, certificate services, and vendor remote-access tools often sit outside the main production application inventory, which means nobody notices them until something breaks. When one of them fails, the apps that depend on it stop working even though their own servers are perfectly healthy.

A DNS failure can knock several otherwise-healthy applications offline at once. An expired certificate can prevent a supervisory application from starting after a routine reboot, and you don’t find out until the next shift tries to log in.

Another scenario that comes up more than you’d think: a license server becomes unavailable during production. A scheduled Windows update reboots the standalone server during a shift, and the server is offline for only a short period, so the event may not trigger an obvious alert. Later, an operator’s MES session fails to authenticate or acquire a required license, and production stops while the team works backward through the dependency chain to find the cause.

These failures affect production in different ways, which is why treating every incident as a generic “server down” scenario leaves gaps in the recovery plan. Failing over a failed host can restore the VM and its storage. It can’t repair a missing DNS record, restore a license service that’s still offline, or fix an expired certificate. When you build the failure model, include the dependencies around the workload.

Designing resilient plant networks without blurring IT and OT

Network resilience starts with redundant paths. Depending on the site, you might add redundant plant switches, dual uplinks, diverse WAN connections, and a cellular backup link for critical locations.

SD-WAN shows up in most multi-site manufacturing rollouts because it can steer traffic across available links and keep connectivity alive when the primary path drops. If the WAN is unavailable, plant systems should still run locally where the workflow allows, with non-critical data queued for sync once connectivity comes back. That’s not optional; it’s how you keep a plant moving when the carrier’s fiber is cut somewhere between you and HQ.

None of that redundancy works if plant and enterprise traffic aren’t properly separated. An industrial DMZ sits between the OT and IT networks and controls what can cross that boundary, and IT/OT segmentation limits how far a problem on one side can spread to the other. Access control and Quality of Service (QoS) settings keep a large file transfer or a security scan on the enterprise side from starving MES or SCADA traffic on the plant side.

The same principle applies inside the plant. Storage replication, cluster management, backup traffic, and production traffic should have appropriately separated paths or controls. If they share a constrained link, a large backup or storage resync can compete with the traffic you need to keep the production workflow running, and you’ll feel it first in latency-sensitive workloads before you ever see an alert.

A dual-WAN, SD-WAN-backed design protects the plant from a connectivity failure. It doesn’t protect a local MES server from a hardware failure, and it doesn’t make the local storage highly available. Those need a different layer of the architecture.

HA, backup, and DR are three different jobs

High availability, synchronous replication, backup, and disaster recovery address different failure scenarios.

High availability keeps a workload available when a host, storage component, or local infrastructure path fails. With synchronous replication, the current data state is maintained on another node so the workload can restart there without waiting for a traditional restore. That’s the goal: minimize the gap between failure and resume.

There’s a catch that bites people who haven’t lived through it. Replication preserves the current state, including the bad changes. An accidental deletion, a corrupted write, a ransomware-encrypted file – any of those get replicated to the second node almost immediately, which means your two synchronized copies aren’t two independent recovery points. They’re the same current data in two locations, and you can lose the same way twice.

Backup covers a different class of failure. Manufacturing environments need recovery copies that sit apart from the production environment and stay clear of the credentials used to administer the HA cluster. If the same admin account that’s compromised in the cluster is also the one that runs the backups, the backups are toast too. Depending on the requirements, this can mean immutable, offline, or otherwise isolated copies.

Backup planning needs realistic RPOs and RTOs. More importantly, those targets need to be measured against the actual production workflow. A successful nightly backup confirms the data was copied. It doesn’t prove that the application will start cleanly after a restore, that its dependencies will be available, or that the full workflow can return to operation inside the required RTO. You only establish that through recovery testing.

Disaster recovery covers failures that exceed the local HA domain. A prolonged power outage, fire, flood, major network failure, or other site-level event can take both nodes in a two-node cluster offline at the same time. Site-level recovery has to be planned separately from host-level HA, because a cluster can deliver excellent local availability and still offer zero protection against the loss of the building that contains both nodes.

The recovery strategy should account for three different questions:

1. Can the workload survive a local infrastructure failure? HA addresses this.
2. Can we recover an earlier, known-good state? Backup addresses this.
3. Can production continue or be restored after the site itself is unavailable? Disaster recovery addresses this.

Exact requirements depend on the manufacturing sector, geography, and regulatory environment. NIST guidance, ISA/IEC 62443, NIS2, FDA requirements, and other frameworks may apply depending on the organization and the systems involved. Where regulatory requirements apply, documented procedures and tested recovery evidence are generally as important as the redundant infrastructure itself.

A two-node cluster is one layer of the recovery strategy, not the whole thing. The next step is to connect that architecture to the specific infrastructure components that determine whether a plant can actually fail over and recover under production load.

What happens when a production host fails?

Picture two servers, each hosting a share of the plant’s critical VMs, synchronously replicating committed storage writes between them. When one server fails, the cluster has to notice quickly, decide which node is authoritative, and bring the affected VMs back up on the surviving node using the storage copy it already has.

Failure detection relies on heartbeat paths between the nodes, so the surviving node can tell a genuine failure from a temporary blip. Health checks should verify more than whether a server answers a ping. The real question is whether the services supporting production are actually available. Once the failure is confirmed, ownership of the affected storage moves to the surviving node and the VMs restart there.

That surviving node needs to be sized to carry the priority workload on its own. A second server sitting idle isn’t enough. It has to provide enough CPU, memory, storage performance, and network capacity to keep the production workflow inside its required performance limits.

HA doesn’t mean zero disruption. VMs need time to restart, applications need to reconnect, and some services may require additional recovery steps. A well-designed cluster can cut the interruption to seconds or minutes, but the exact recovery time depends on the workload and the failure scenario.

The architecture is built for a specific class of failures: a host, storage component, or local infrastructure path becoming unavailable while the other node stays operational. It doesn’t provide universal zero-RPO or zero-RTO protection, and it can’t cover every type of failure. StarWind Virtual SAN and StarWind HCI Appliance both implement this two-node model. The sizing, quorum, network, and recovery principles below apply to either approach.

What makes failover work under plant conditions

Whether HA holds up during an actual incident depends on details that are easy to overlook during normal operation. A cluster can look perfectly healthy in a dashboard and still have a serious weakness that surfaces only when a network path, power source, or storage component partially fails.

The failure-domain design is where this matters.

When cluster nodes lose contact

What happens when a cluster node is fine, but its connection to its partner drops? A pulled cable or a bad switch port can leave two nodes running blind. If both decide they’re the lone survivor, they both continue writing data independently. The storage splits, and you end up with two competing versions of the truth. Preventing this “split-brain” condition is the hardest job of any HA architecture.

To stop it, most platforms require an external tiebreaker. Solutions like VMware vSAN and Nutanix use a witness VM to cast the deciding vote. In a perfect design, this witness sits in a separate failure domain. In reality, plant IT teams often try to save a rack unit by parking the witness next to one of the primary nodes, or plugging it into the same UPS. When that UPS fails, the cluster loses the primary node and the witness at the same second. The surviving node is left without a quorum, and production stops.

Some implementations take a different approach. StarWind, for example, uses a dedicated heartbeat connection between the nodes rather than requiring a separate witness appliance or VM. The trade-off and the underlying requirement are the same: two nodes must never be allowed to believe that they independently own and can modify the same storage at the same time.

When you review a two-node design, look at the complete failure path. Ask what happens if the replication link fails, if the management network fails, if a switch disappears, or if one power circuit goes down. A cluster should have a deterministic answer for each scenario.

Resynchronization without overwhelming production I/O

Synchronous replication has a built-in trade-off. Every write waits for both nodes to confirm it before it’s acknowledged, which adds latency compared to writing locally and moving on. That trade-off buys you a current copy on both sides at the cost of a small delay on every write.

The heavier load shows up after a repaired node rejoins the cluster and needs to resynchronize, copying everything it missed while it was down. That traffic competes with normal production I/O, any failover activity still settling out, and scheduled backup windows, all potentially at the same time. Most platforms, StarWind included, let you throttle or schedule resync traffic so it doesn’t flatten production I/O during the day, but that only helps if someone actually configures it.

Left at defaults, a node that’s been offline for several hours may have a substantial amount of data to synchronize. If the cluster was sized only for average daytime utilization, the additional resynchronization load can expose a capacity problem precisely when the environment is already operating in a degraded state.

For that reason, test the rebuilding state as part of HA validation. Don’t measure only normal production performance and failover time. Measure what happens when a node returns and the cluster is rebuilding its replica while production remains active. (This is the part teams usually skip, and the rebuild runs straight into the next business day.)

Removing shared network and power failure points

Redundancy only protects against a failure if the redundant components are actually independent. Two NICs connected to the same switch don’t give the same protection as two NICs connected to independent switches. Two power supplies connected to the same circuit don’t give the same protection as supplies connected to separate power paths.

The same principle applies to the infrastructure between the servers and their external dependencies.

A cluster can have redundant NICs, switches, UPS units, and power circuits. It’s still vulnerable if both paths eventually converge on the same switch, distribution panel, power circuit, or cable route.

When you’re reviewing a plant cluster, trace each network and power path back to its source. Where do the paths converge? What’s the single failure that could take both sides offline? The exercise often surfaces dependencies that don’t appear in the cluster configuration itself – shared PDUs on the same phase, two fiber runs through the same conduit, that kind of thing.

Sizing the plant edge for machine vision and AI

Manufacturing edge computing moves data processing into or close to the plant instead of sending every operation to a remote data center and waiting for a response.

Machine vision inspection, predictive maintenance, sensor anomaly detection, telemetry aggregation, digital work instructions, and operator-support applications are the workloads pushing up demand for local compute.

These workloads add a sizing layer on top of what MES and SCADA need.

Machine vision and AI inference can eat substantial CPU and memory. Image plus sensor data creates real storage pressure. Your network has to absorb the movement of that data without it stepping on production traffic. Depending on the workload, a GPU or other accelerator may be required.

Power and cooling need to be in the design from day one. Extra compute at the edge pushes both requirements up, especially in plants where the existing equipment room is already running close to its environmental limits.

Software lifecycle matters too. AI models need to be updated, tested, and deployed without disrupting production.

The deployment process should be designed so model updates can be staged and rolled back without taking equipment offline – usually meaning a parallel environment that mirrors production closely enough to catch regressions before they hit the line, and a rollback path that’s been tested under load rather than on paper.

Data retention is the other sizing variable you can’t ignore.

How long do inspection images, sensor telemetry, and the rest of the edge-generated data need to stay available before they’re archived or dropped?

Holding more history costs storage, but it gives you material for investigating quality issues or retraining models later.

How to choose infrastructure for a manufacturing site

Start with the production workflows that need to stay available.

For each critical workflow, define the RTO and RPO the business can tolerate.

Then weigh the factors that shape the design:

• WAN reliability at the site
• Number of plants and locations to deploy
• Existing server and storage hardware
• Internal infrastructure expertise
• Application vendor support for the proposed deployment model
• Production data growth
• Backup and recovery requirements
• Remote management and support requirements
• Expected machine vision and AI workloads over the next one to two years.

That same evaluation tells you whether existing hardware should be reused or replaced.

Existing servers paired with software-defined storage, such as the StarWind Virtual SAN approach described above, make sense when you’ve already got capable hardware and the in-house expertise to run it. That’s most practical for a single plant or a small footprint.

A pre-integrated platform such as StarWind HCI Appliance fits better when standardization across multiple sites matters, when there’s no existing hardware worth reusing, or when a single vendor relationship for infrastructure and support simplifies operations.

Your choice should reflect how the plant is actually operated. Hardware flexibility pays off at one site. Standardized deployment and centralized support often matter more across dozens of locations.

Plan around the process, not the server

Every section above comes back to the same point: plan around the production process that has to keep running, and let the server, network, storage, and WAN design follow from that.

A cluster that protects the wrong workload, or protects the right one without accounting for what happens during resynchronization, doesn’t actually solve the problem it was built for.

HA, backup, and disaster recovery each cover a different failure. A design that treats them as interchangeable leaves gaps you don’t notice until the wrong one fires.

FAQ

Can a plant continue operating during a WAN outage?

Yes, as long as critical workloads – MES, SCADA, HMI, historian, and plant identity services – run locally. Systems like ERP and analytics can queue updates until connectivity comes back.

Can MES and SCADA run on a two-node virtualized cluster?

Yes. A two-node HA cluster with synchronous replication protects MES and SCADA from a single server or storage failure. The surviving node has to be sized to carry the priority workload alone, with replication, management, and production traffic properly separated.

Does synchronous replication replace backup?

No. Replication also copies deletions, corruption, and ransomware to the second node – that’s the part people miss when they decide synchronous replication is good enough and skip the backup tier entirely. Backup gives you separate recovery points and should use isolated, immutable, or offline copies. Test recovery by restoring the application and its dependencies, not by checking that the backup job completed.

from StarWind Blog https://ift.tt/Dlgwe9n
via IFTTT

How to Secure Enterprise AI: From Adoption to Incident Readiness

The debate about whether AI delivers business value is over. The challenge now is implementing it at scale and securely across every function while meeting board-level pressure to move fast. Organizations must focus on adopting AI at business speed without losing control of cyber risk. Download the full eBook here.

The Business Reality

In Sygnia’s 2026 CISO Survey Report, which surveyed 600 senior IT and security leaders worldwide, nearly one-third already report extensive AI use across threat detection and IR, with 63% expecting it to be fully embedded in their organization by 2027.¹ Yet 73% of IT security decision makers say their organization would not be fully ready if a significant cyberattack occurred tomorrow.¹

Security teams feel they do not have adequate time to adapt. The tools are being deployed. The governance, controls, and incident readiness to support them are not. Security leaders are now tasked with enabling AI adoption while reducing the inheritance of unmanaged risk.

The AI Security Gap

AI is already inside the enterprise, but does not always enter through the front door. It comes through approved platforms, employee workarounds, SaaS plugins, vendor tools, internal experiments, and development teams trying to move faster. How deeply and quickly AI should be embedded depends heavily on which type of AI is used – Generative AI or Agentic AI. The more AI moves from fully- or semi-autonomously assisting people to acting across systems, the less it can be treated as a productivity tool alone. It significantly expands the enterprise attack surface and introduces new security risks.

The rapid adoption of enterprise AI is being driven from both the top down and the bottom up. Leadership typically recognizes the need for oversight, but does not have a proven playbook to swear by, and employees are rarely equipped to assess the security implications of the tools they adopt on their own. As organizations prioritize speed, security reviews, vendor assessments, and data governance often become secondary concerns, creating an environment where AI adoption outpaces control.

With only 38% of organizations reporting a comprehensive AI policy², adoption is outpacing oversight, leaving security teams to manage the consequences after the fact. The result is a rapidly expanding attack surface fueled by widespread shadow AI and AI-powered threats that lower the barrier to sophisticated attacks while enabling adversaries to identify and exploit vulnerabilities faster and at greater scale.

The Hidden AI Risks

The assumption has taken hold that limited AI usage means manageable AI risk and that because the program is early, the exposure is minimal. It isn't. The AI attack surface is not a fixed perimeter. It expands wherever AI is adopted, integrated, or built. 67% of executives believe their organization has already suffered a breach as a result of unapproved AI tools.³

The entry points multiplying fastest are rarely the ones under active security review, which leaves room for more and faster exploitation: (1) ungoverned AI (including shadow AI), (2) ad hoc integrations, and (3) AI agents with excessive permissions.

And on the attacker side, the threat landscape has shifted in ways that make this exposure increasingly beneficial for them and in turn consequential for their enterprise victims. Their underlying tactics and techniques often remain the same, but AI enables attackers to execute them faster, at greater scale, and with higher levels of automation, ultimately increasing their effectiveness against existing weaknesses within an enterprise environment – as seen in a recent AI-enabled attack investigated and remediated by Sygnia incident responders.

The Need for a Lifecycle Approach

AI security needs to be addressed across each tool’s complete lifecycle. The control requirements change at each stage, but the priorities stay consistent: identify usage, classify risk, assign ownership, limit access, validate controls, and prepare for incident scenarios before AI is deployed and becomes embedded into critical workflows.

It’s imperative to prepare for the different lifecycle stages and understand their associated security challenges.

Strategy and Use Case Definition

Organizations need clearly defined ownership, decision rights, oversight, and escalation across business, technology, security, legal, privacy, compliance, and risk functions. This ensures AI use remains aligned with organizational objectives, policies, risk appetite, and regulatory obligations before the business becomes dependent on these tools.

Common challenge: Organizations often adopt AI without defining who owns the use case, who is authorized to approve it, who oversees its continued operation, and who is accountable when its use produces business consequences.

Design and Development

AI adds design questions that are easy to miss: how prompts are handled, what data is retrieved, how embeddings are stored, how vector databases are protected, how model outputs are validated, and what happens if the system is manipulated. AI-specific security requirements need to be defined before the system is built.

Common challenge: AI applications regularly reach production without security requirements being defined, tested, or validated at any stage of development.

Adoption and Vendor Selection

Whether evaluating a SaaS AI platform, integrating a third-party model, or building on a foundation model via API, the security implications of that choice need to be assessed before the contract is signed. Evaluate whether to build, buy, or integrate and treat it as a security decision, not just a capability and cost question.

Common challenge: Organizations typically adopt AI capabilities without performing adequate security and risk assessments. Speed of procurement consistently outpaces due diligence.

Deployment and Integration

An application that passed security review at design can still be deployed insecurely. The most consistent failure at this stage is excessive permissions: where AI systems are connected to sensitive data with access that reflects what was convenient rather than what the function requires.

Common challenge: AI systems routinely go into production with access that was never formally reviewed and rarely gets revisited.

Operations, Monitoring, and Scaling

AI systems evolve after deployment as models are updated, integrations are added, and use cases expand, potentially changing the risk profile without a deliberate decision to do so. Maintain a current inventory of AI applications, services, and integrations, and periodically reassess use cases and risk classifications as capabilities and usage patterns change.

Common challenge: AI adoption scales faster than the governance and monitoring capabilities designed to manage it.

Incident Response and Recovery

Most organizations have incident response plans, but they are not built for AI. Prompt injection, agent compromise, and third-party model failures require different forensic capabilities, containment strategies, and stakeholder coordination than conventional attacks. Add AI-specific response procedures to existing IR playbooks and integrate AI incidents into broader cyber crisis management processes.

Common challenge: Incident response plans are written for the threats organizations faced when they were last updated. AI-specific scenarios are absent from most plans.

Operationalizing an AI Plan with Security in Mind

Understanding where AI risk lives is one thing. Building the organizational structures, controls, and processes to manage it is another. Most organizations lack an actionable program that connects the dots. There are six components to consider when operationalizing a best practice AI plan.

Establish Executive Alignment and Business Objectives

89% of security leaders cite limited executive or board involvement in IR readiness and decision-making as a key challenge.⁴ The only thing that resolves this is executive ownership - and not in the sense of awareness, but in the sense of defined accountability, formal sponsorship, and a clear organizational mandate that AI security is a business requirement.

Recommendations:

• Define the business drivers for AI adoption
• Align AI initiatives with business goals and risk appetite
• Identify stakeholders across Security, IT, Legal, Compliance, Privacy, and business teams
• Establish executive sponsorship and accountability

Build an AI Governance Program

75% of security leaders agree that delays and uncertainty around legal and communications involvement slow down decision-making during incidents.⁵ When an incident occurs and the organization needs to know who owns a given AI system, what data it has access to, and who has the authority to take it offline, governance is what makes those questions answerable in minutes rather than hours.

Recommendations:

• Define acceptable AI use policies and standards
• Establish decision-making and approval processes
• Define ownership and accountability for AI systems and risks
• Align governance with regulatory and compliance requirements
• Develop an AI risk management framework

Implement Enforceable Security and Operational Guardrails

Effective AI governance must be translated into enforceable security and operational controls. Otherwise, policies become guidance that teams interpret and apply differently. These guardrails should apply across the main ways AI enters the organization: public GenAI use, copilots, SaaS AI features, internal applications, retrieval-augmented generation (RAG) systems, autonomous agents, cloud AI services, and vendor-managed platforms.

Recommendations:

• Define identity and access management requirements
• Define data protection, privacy, and information handling controls
• Define monitoring, logging, audit, and record retention needs
• Define standards for AI development, procurement, integration, and deployment
• Define controls for third-party AI services, models, platforms, and vendors

Foster Workforce Awareness and Preparedness

Technical controls address what systems can and can't do. Workforce preparedness addresses what people will and won't do - which is a different problem requiring a different approach. Effective AI awareness programs must go beyond annual, generic compliance training and provide practical, role-specific guidance; giving people the knowledge they need to make better decisions in the normal course of their work.

Recommendations:

• Train employees on responsible, approved, and prohibited AI usage
• Educate developers on secure AI design and development practices
• Raise awareness of data handling, privacy, output, and security risks
• Provide role-specific guidance on AI governance expectations
• Communicate clear avenues for exception requests and reporting suspected AI misuse

Validate Security Before Adoption and Across the Lifecycle

Validation should happen before deployment and continue throughout the lifecycle as usage expands. AI systems change through new features, new integrations, data sources, vendor updates, model changes, expanded permissions, and broader business reliance. A review performed at launch may not reflect the system’s risk profile six months later.

Recommendations:

• Conduct AI security posture assessments before approval
• Perform AI application penetration testing and adversarial testing
• Assess third-party AI solutions, models, integrations, and supply chains
• Validate access controls, data flows, monitoring, and human oversight
• Continuously evaluate AI deployments as capabilities evolve

Prepare for AI Security Incidents

Existing incident response (IR) plans may not address the scenarios that AI introduces, including prompt abuse, agent compromise, data leakage, unsafe outputs, third-party AI exposure, unauthorized model use, or incidents where AI-generated activity becomes part of the evidence trail. The implementation of AI-specific incident response procedures and decision criteria into an existing IR plan is critical.

Recommendations:

• Update your IR plan to include the following components:
• How security, privacy, legal, technology, business owners, model providers, and other third parties should coordinate during an incident
• Define AI-related ownership, escalation paths, and responsibilities
• Conduct AI-focused tabletop exercises and operational readiness assessments
• Train staff on AI-driven logging, monitoring, and forensic capabilities
• Practice AI-themed scenarios across the wider incident response and crisis management program

ACTION: Proactively Secure Your AI Solutions

Organizations that wait for a threat to expose their AI security posture are already behind. 65% of organizations say they are likely to switch IR providers at the end of their contract - the top driver being the need for more proactive readiness support.⁶

The demand is clear. What's less clear, for most organizations, is what a proactive AI security approach looks like when it's properly executed.

There are three areas of primary focus in a proactive security approach that can be performed in any order and should continue across the AI lifecycle:

(1) Assess the organization’s AI cyber posture across infrastructure, applications, data flows, and prompt behavior.

(2) Establish a comprehensive AI governance and usage framework or evaluate the organization's existing one.

(3) Test the security and functionality of internally developed and externally adopted AI applications against real-world adversarial behaviors.

Closing

Organizations must not only capture the business value of AI adoption but also prioritize how to mitigate the introduction of unmanaged cyber risk. To do this, a solid lifecycle approach is required that integrates security, governance, and risk management across AI strategy, development, vendor selection, deployment, monitoring, and incident response - particularly when systems access sensitive data, connect to enterprise environments, or support critical workflows.

Because AI threats and security frameworks are still evolving, organizations must regularly assess their posture, governance, controls, and preparedness. Those that secure AI proactively will reduce exposure across an expanding attack surface while gaining the ownership, visibility, and confidence needed to adopt it safely at scale.

Work with Sygnia

Sygnia understands firsthand how adversaries are using AI attack surfaces to accelerate their exploitation capabilities and what cyber defenders must do to get in front of this growing security risk. Learn more about Sygnia’s AI Cybersecurity Services.

Citations:

[1] Sygnia CISO Survey, 2026

[2] ISACA AI Pulse Poll, 2026

[3] Writer Enterprise AI Adoption Report, 2026

[4] Sygnia CISO Survey, 2026

[5] Sygnia CISO Survey, 2026

[6] Sygnia CISO Survey, 2026

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

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

Attackers Exploit Two SonicWall SMA 1000 Zero-Days That May Form an Attack Chain

SonicWall has released security updates to address two security flaws impacting its Secure Mobile Access (SMA) 1000 series VPN appliances that have been exploited in zero-day attacks.

The vulnerabilities, discovered internally by SonicWall's William Perry and Adam Babis, are listed below -

• CVE-2026-83548 (CVSS score: 10.0) - A pre-authentication SSRF vulnerability in the Appliance Work Place interface that could allow a remote unauthenticated attacker to gain unauthorized access to sensitive functionality and perform unauthorized operations.
• CVE-2026-83549 (CVSS score: 7.8) - A post-authentication operating system command injection vulnerability in the Appliance Management Console (AMC) that could allow a remote authenticated attacker as administrator to execute arbitrary commands under specific conditions, leading to remote code execution.

SonicWall said it has "investigated a case indicating the active exploitation of the vulnerabilities," suggesting that threat actors are chaining together both the bugs to execute arbitrary code on susceptible devices.

The flaws impact the SMA 1000 models 6210, 7210, and 8200v in the following versions -

• 12.4.3-03453 (platform-hotfix) and older versions
• 12.5.0-02835 (platform-hotfix) and older versions

Fixes have been released in versions 12.4.3-03526 (platform-hotfix) and 12.5.0-02952 (platform-hotfix). SonicWall is recommending that customers perform the actions outlined below -

• Upgrade to the latest hotfix version
• Review the system for indicators of compromise (IoCs)
• If IoCs are found, re-image or re-deploy the appliances, change all user and administrator passwords, and reset Time-based One-Time Password (TOTP)

SonicWall has not shared any specifics about the nature of the exploitation activity or who is behind it. The development comes more than a month after it shipped fixes to address two other flaws in the same product – CVE-2026-15409 (CVSS score: 10.0) and CVE-2026-15410 (CVSS score: 7.2) – that were exploited by a threat actor dubbed UTA0533 to deploy KNUCKLEBALL malware.

Found this article interesting? Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.

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

An AI-Assisted Cyber Attack: Inside a Unit 42 Investigation

Unit 42 responded to an incident where a human attacker used frontier AI to breach an enterprise network autonomously as part of a ransomware attack. The agents breached the company's security layers in a methodical manner, each targeting a different layer of defense to achieve a shared goal. The impact was at the scale of a coordinated effort from multiple red teams, which would normally take human operators around two weeks.

The threat actor told us in negotiations that they leveraged frontier AI models and attack-specific agentic AI frameworks. By shifting execution to an automated loop, the attacker compressed weeks of methodical intrusion tradecraft (using more than 50 MITRE ATT&CK techniques) into less than 10 hours.

After they gained initial access, the attacker used agents to map the internal architecture, raid source repositories and seize root credentials. The agents also triggered unauthorized continuous integration/continuous delivery (CI/CD) builds and claimed master keys to the victim's cloud AI infrastructure.

What made the attack stand out was AI-assisted operational efficiency, without the need for a novel zero-day or super elite tradecraft. The attacker left tactical execution to AI agents that monitored, evaluated, acted and re-planned in real time, increasing speed throughout the attack chain.

The attacker also directed the agent to leave behind a “report” on the organization’s security posture: an 80-page, technical audit detailing dozens of exploited findings.

Inside the Machine-Speed Attack Chain

The adversary ran their operation using current AI-enabled software development processes. We observed multiple indicators consistent with AI usage:

• LLM calls to multiple frontier AI agents in parallel
• Structured Markdown files passing information between agents and sessions
• Custom scripts (assessed with high confidence to be AI-generated due to UI elements) managing dynamic operations

The 10-hour operational timeline included the following:

• Infiltration and mapping: The actor breached a public API endpoint to tunnel into the network, deploying an automated recon agent to map internal microservices.
• Secrets harvesting: Sub-agents combed enterprise code repositories, extracting hard-coded tokens and service passwords.
• Privilege takeover: Using exposed tokens, the actor infiltrated the secrets management system, harvesting master administrative credentials to seize control of root system access.
• Pipeline exploitation: The actor hijacked an enterprise code application via custom workflows to exfiltrate cloud access keys. They attempted to plant backdoors in Terraform configurations, but hard branch-protection controls stopped this.
• AI infrastructure hijacking: Using stolen cloud keys, the actor turned the victim’s AI endpoints into post-compromise infrastructure — using the company’s compute power to perpetrate future moves.

Figure 1 maps the AI-orchestrated workflow.

Figure 1. AI-orchestrated intrusion workflow. The actor sets objectives and makes consequential decisions. Specialized agents execute, share results and adapt in real time.

Unified Threat Framework Mapping

For illustration, Table 1 below maps some of the techniques used against the MITRE ATT&CK and ATLAS frameworks:

Intrusion Stage	Threat Actor Action	MITRE ATT&CK® Mapping	MITRE ATLAS™ (AI-Specific) Mapping
Initial Access and Recon	API breach; automated service mapping via service discovery tool	T1190: Exploit Public-Facing Application T1046: Network Service Discovery	AML.T0000: Initial Access AML.T0002: AI-Automated Reconnaissance
Credential Access	Code scraping for secrets across code repos	T1552.001: Credentials In Files	AML.T0014: Credentials Harvesting
Privilege Escalation	Infiltrating secrets manager to harvest admin system secrets	T1555: Credentials from Password Stores	AML.T0016: Privilege Escalation via Automated Pivot
Pipeline Abuse	Executing CI/CD actions; attempting cloud provisioning tool edits	T1578: Modify Cloud Compute Infrastructure	AML.T0010: ML/DevOps Pipeline Interception
AI Infrastructure Abuse	Invoking cloud AI models via stolen keys	T1078: Valid Accounts	AML.T0043: LLM Invocations via Stolen API Keys

Table 1. Major MITRE ATT&CK and MITRE ATLAS techniques used by the attacker.

Key Lessons: Addressing Agentic Attacks

This incident exposes how an attacker who understands how to deploy frontier AI agents effectively can dramatically speed up the pace of their attack. We assess that attackers will increasingly add AI agents to their tool sets. Organizations should take note of the following to address agentic attacks:

• AI agents reduce the time between steps in the attack flow: AI agents in this attack were designed to parse raw tool output and quickly take next steps, speeding up the overall attack flow.
• AI agents leave recognizable indicators: Defenders can identify agentic attacks by watching for indicators such as the use of structured Markdown, Python caches and paired asset folders.
• Attackers can use AI to establish redundant persistence across the environment: In this incident, the attacker used AI agents to efficiently establish overlapping persistence across SSH keys, serverless functions, container restart policies, cloud identities and CI/CD pipelines. Using AI agents can make it easier for an attacker to maintain and test this entire portfolio in parallel.
• Attackers can use an organization’s AI tools as post-compromise infrastructure: Attackers can hijack enterprise AI services to assist in their attacks. This allows threat actors to hide orchestration traffic among expected traffic, and offload the financial cost onto the victim.

Defending Against Machine-Speed Attacks

Defending against automated agent loops requires matching the speed and adaptability of AI-driven attacks:

• Execute synchronized containment: Deploy automated playbooks that simultaneously revoke credentials, terminate OAuth sessions, freeze CI/CD pipelines and isolate cloud accounts across all operational planes.
• Govern AI as core infrastructure: Inventory every model endpoint, API key, Model Context Protocol (MCP) gateway and AI tool integration. Apply strict rate limits, least-privilege policies and diagnostic logging.
• Detect behavioral loops: Hunt for operational loops including bursty API requests, rapid 401/200 HTTP state shifts, parallel authentications and sudden model usage from unexpected identities.
• Lock down DevOps pipelines: Enforce mandatory, multi-party code reviews and immutable branch protection on all infrastructure-as-code repos to block automated backdoor injection.

Learn more about how Unit 42 can help defend against AI-driven threats through Unit 42 Frontier AI Defense.

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

Extradited Russian Hacker Faces Charges Over Excel Malware Campaign That Infected Thousands

The U.S. Department of Justice (DoJ) has charged a Russian national, extradited from Cyprus on August 28, with using roughly 255 fake accounts on a freelance platform to send malware-laced Excel attachments to about 80,000 of its users in 2016 and 2017.

Searzhudin Tamirlanovich Aktulaev, 40, was arrested in Cyprus in May 2025, the U.S. Attorney's Office for the Northern District of California said in a press release. He made his initial appearance in federal court in San Francisco on August 31 and was remanded to federal custody.

The indictment, filed on June 1, 2021, and unsealed the same day as his appearance, describes the platform only as "a well-known freelance employment technology company" based in the Northern District of California.

Thousands of computers infected with TVRAT, one of two malware types named in the indictment, were calling back to a command-and-control (C2) domain hosted in the U.S., with approximately half of the victims located in the country, many of them in the district.

A shared document in the email account used in the scheme contained e-commerce login credentials and personally identifiable information (PII) for hundreds of victims.

Aktulaev is charged with conspiracy to commit wire fraud; transmission of a program, information, code, or command to cause damage to protected computers; conspiracy to commit computer fraud; unauthorized access to a protected computer to obtain information for financial gain and to obtain value; and aggravated identity theft.

The indictment alleges that from at least June 2016 through November 2017, the messages carried Excel attachments that prompted recipients to run a macro. The macro then downloaded malware from the internet.

The malware came in two types:

• a variant of TVRAT, a TeamViewer remote access trojan (RAT) also known as TVSPY or TeamSpy, and
• DarkVNC, both of which gave the operators remote control of the infected computer.

Both sent stolen data to the C2 server, from which it was collected and used by Aktulaev and his co-conspirators to commit fraud or other criminal activity, the DoJ said.

The DoJ's release says TVRAT exploits a vulnerability in TeamViewer. Russian cybersecurity vendor Kaspersky used the same term in its March 2013 report on TeamSpy, stating that the malicious module "uses a vulnerability in TeamViewer v6 known as Dll-hijacking."

"We have no evidence to assume a vulnerability of our software," a TeamViewer spokesman told Security Affairs in February 2017.

Avast, which analyzed a TeamSpy sample spread via Excel macros in April 2017, said the macro fetched a password-protected installer that bundles legitimate, digitally signed TeamViewer binaries with a malicious msimg32.dll.

The library is loaded in place of the genuine Windows dynamic-link library (DLL) via DLL search order hijacking, which Avast said is "a clever technique" because checking the main executable's signature reveals nothing suspicious.

Once loaded, the library hooks nearly 50 Windows Application Programming Interfaces (APIs) to prevent the TeamViewer window and its dialogs from being displayed to the victim. The infected machine then reports its TeamViewer ID to a C2 server. That ID, together with a preset password, is enough for the operators to connect to the computer remotely, Avast said.

DarkVNC, for its part, is a hidden virtual network computing (hVNC) utility that was first advertised on the Exploit forum on November 24, 2016, eSentire said in a February 2024 analysis.

The tool creates a concealed desktop on the infected machine for the operator to control. Microsoft has blocked Visual Basic for Applications (VBA) macros by default since 2022 in Office files obtained from the internet on Windows devices, the delivery step this campaign relied on.

Aktulaev has denied guilt and said he was unaware of the U.S. charges, according to statements from the Russian Embassy in Nicosia, as reported by RIA Novosti and TASS earlier this year.

The DoJ noted that the indictment contains allegations only and that Aktulaev is presumed innocent unless and until proven guilty.

The development comes as job-hunting and freelancing sites remain a recurring lure for state-sponsored actors, with ESET saying in February 2025 that North Korean hackers were using the same freelance-platform lure against software developers.

Last month, fake-recruiter campaigns were documented by Check Point Research, which said a Lazarus Group wave paired fake job offers with a remote-access backdoor, and by the Computer Emergency Response Team of Ukraine (CERT-UA), which said a Sandworm-linked cluster was contacting candidates through job-site chat before pushing a virtual private network (VPN) client that can run commands.

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

Attackers Exploit Critical JFrog Artifactory Flaw to Mint Admin Tokens Days After Disclosure

Threat actors are exploiting a newly patched critical security flaw impacting JFrog Artifactory merely days after public disclosure, according to watchTowr.

The vulnerability in question is CVE-2026-82329 (CVSS score: 9.8), a case of authentication bypass that could lead to administrative access in Artifactory.

"JFrog Artifactory contains an authentication weakness that, under default configuration, may allow an unauthenticated attacker with network access to obtain administrative privileges," according to a description of the flaw on CVE.org.

The vulnerability was patched by JFrog with Artifactory version 7.161.20 released on August 28, 2026. It affects the following versions -

• 7.161.0 > 7.161.19
• 7.146.0 > 7.146.36
• 7.133.0 > 7.133.28
• 7.125.0 > 7.125.19
• 7.117.0 > 7.117.27
• 7.111.4 > 7.111.21

"It affects default configs, requires no auth, no user interaction," Vercel CEO Guillermo Rauch said in a post on LinkedIn. "It's an RCE bomb because Artifactory hosts binaries, so you can basically poison everything, but an admin escalation can cause damage even beyond that."

The issue resides in JFrog Access, which is designed to issue and validate credentials. "Instances without an additional join key configured receive a 'phantom' join key that attackers can abuse to forge access and mint administrator-level credentials," Yordan Ganchev, principal threat intelligence specialist at watchTowr, said in a statement shared with The Hacker News.

Ganchev also pointed out that threat actors have begun to weaponize the flaw as of September 1, 2026, to generate admin tokens and enumerate users, groups, credential sets and federated access topologies.

"This moved from disclosure to real-world exploitation with uncomfortable efficiency," Ganchev added. "Anyone following along knows what comes next: things will get worse."

"When attackers gain admin level access to a central software supply chain system, they can do what every engineering team does best – build, ship and distribute software fast. From there, they could tamper with build pipelines, move laterally into production systems and potentially push malicious changes downstream to customers."

Organizations that are running self-managed versions of JFrog Artifactory are recommended to apply patches to internet-exposed systems with immediate effect, as well as inspect audit logs, rotate exposed credentials, and review connected systems for malicious changes or backdoor access.

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

Breeze Comet Executes Hundreds of Fraudulent Transactions via Brazilian Payment Systems

Brazilian financial services, retail, and e-commerce organizations have become the target of a financially motivated threat actor dubbed Breeze Comet (formerly UNC5669) since 2024.

Google Threat Intelligence Group (GTIG) and Mandiant teams described the threat actor as "specializing in manipulating payment systems and banking software in Brazil to conduct fraudulent transfers." The adversary is said to have successfully carried out at least one heist of assets worth tens of thousands of U.S. dollars.

The activity overlaps with threat activity clusters tracked by CrowdStrike and Trend Micro under the monikers Plump Spider and SHADOW-AETHER-064. According to CrowdStrike, the e-crime group is operating out of Brazil and has been active since September 2023, monetizing their intrusions by gaining unauthorized access to internal payment systems and carrying out fraudulent transactions.

Initial access to financial entities and companies offering financial services is accomplished via password spraying and voice calls impersonating IT support teams to persuade targets to install Remote Monitoring and Management (RMM) tools such as AnyDesk. In one case highlighted by Axur in November 2025, the threat actors masqueraded as IT support personnel over a WhatsApp conversation and guided the victim to install a PowerShell reconnaissance script under the pretext of updating a corporate application.

Alternatively, the group has targeted vulnerable JBoss AS servers to deploy web shells, which are then used to deliver additional tooling, including Chisel and other proxy utilities, for follow-on exploitation.

The threat actor's primary targets are organizations with permission to conduct transactions through banking software, APIs, and payment systems such as Pix, STR, and Boleto. This covers a wide range of entities like banks, payment processors, retailers, and exchanges, not to mention fintech and banking software providers.

"Breeze Comet tactics have evolved over time to leverage a customized malware suite and compromised, trusted websites to facilitate initial access, command-and-control (C2), and to interact with financial software and payment APIs," Google said. "Breeze Comet's operational infrastructure may also indicate intent to expand their infrastructure footprint to other countries in Latin America and Africa."

To achieve its goals, however, it must meet four requirements: have access to the National Financial System Network (RSFN) through an entity that already has this access; access to mTLS credentials that allow sending authenticated payloads with transactional orders to Pix or STR; access to several accounts in the targeted organizations' Active Directory and cloud environments; and possess an understanding of an organization's transfer processing procedures, network controls, fintech integrations, and anti-fraud systems.

Some of the other notable tactics are listed below -

• Using compromised Brazilian small government websites to stage RMM tools, infostealers dressed up as legitimate tax or receipt documents, and backdoors like XWorm, as well as using them as C2 endpoints to bypass reputation filters and avoid detection. A similar modus operandi has been replicated across Nigeria, Paraguay, Ghana, and Venezuela, indicating a growing targeting focus.
• Connecting rogue hardware devices directly into retail store networks as a means to establish direct footholds and then move laterally to internal systems, followed by downloading the Netcat utility and custom scripts to retrieve post-exploitation frameworks.
• Using Impacket, ADRecon, and ADVipscan, and the custom LDAP brute-forcing utility REALBREEZE to conduct internal reconnaissance and escalate privileges by targeting development and cloud environments.
• Moving laterally by initiating unauthorized Remote Desktop Protocol (RDP) sessions and executing commands via SMB network file shares. This step also involves the deployment of COBALTSPIN, a Rust-based routing malware that operates as a network tunneler to communicate with and maintain persistent network access to financial API infrastructure.

"By establishing a reverse SOCKS5 proxy over a WebSocket connection, COBALTSPIN routes network traffic securely back and forth between the C2 and internal targets, enabling lateral movement directly through boundary firewalls without requiring built-in persistence mechanisms that might trigger detection," Google said.

Breeze Comet's persistence mechanisms have evolved from dropping commercial RMM tools in 2024 to deploying malicious Kubernetes pods a year later and stealing cloud secrets by exfiltrating them to public-facing notepad websites like "dontpad[.]com." Since then, the threat actor has also been observed making use of multiple custom backdoors as a redundant access method and expanding their foothold -

• LIGHTPAINT, a Java-based backdoor that's used to install the legitimate SoftEther VPN and configure it for automated persistence
• MILDFROST, a passive Java JAR backdoor that's used to establish covert DNS tunnels
• KICKPLATE, a Nim-based backdoor that impersonates Windows Update Health Tools and is used to deliver secondary payloads and runs commands to control SOCKS5 tunnelers
• BOATBEAM, a Golang-based backdoor that initiates a fake IIS HTTPS server on port 443

To make sure these persistence mechanisms are not detected and removed, the threat actor executes PowerShell commands to disable Windows Defender's real-time monitoring on the compromised hosts.

In the final stage, COBALTSPIN and compromised privileged accounts are used to access core financial applications and execute hundreds of fraudulent transactions. Once complete, event logs are cleared to minimize the forensic footprint and conceal any API interactions with financial software and payment systems. Any directory created during the course of the intrusion is also deleted.

The presence of verbose explanatory comments and standardized execution headers indicates the use of a large language model (LLM) to compress the malware development lifecycle. A previous analysis from Trend Micro in May 2026 also found some scripts to include "descriptions of self-reasoning and autonomous decision-making processes."

"While the Latin American cybercrime ecosystem has historically been defined by client-side, high-volume retail fraud, Breeze Comet's campaigns represent a notable shift that may serve as a model for future financially motivated threats against organizations in this region," Google said.

"This transition from opportunistic retail banking fraud to direct intrusions into the core financial switch and instant payment infrastructure is notable not just for this shift in targeting, but also the capabilities of the threat actor. As threat groups increasingly leverage LLMs to streamline routine tradecraft, defenders must anticipate shorter adversary turnaround times and heightened pressure on interconnected financial ecosystems."

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

How to Deploy Omnissa App Packages via In-Guest VHD: Part 4

 

Part 1 installed App Volumes Manager and prepared the SQL database and SMB share. Part 2 configured Active Directory, VHD In-Guest Services, and storage templates, and Part 3 created and verified a Writable Volume.

This final guide packages Notepad++ on a clean capture VM, stores the application as a VHD on the configured SMB share, assigns the current package version to an Active Directory group, and verifies delivery inside a Horizon desktop. The workflow uses VHD In-Guest Services, so the endpoint mounts the package from SMB without a vCenter-managed disk attachment.

Prerequisites

Before creating the package, confirm that the following components and access requirements are in place:

• App Volumes Manager – Installed and configured with VHD In-Guest Services, Directory Services, and a storage location.
• SMB 3 file share – Reachable by App Volumes Manager, the packaging VM, and the target desktops. The share was created in Part 1 and registered as storage in Part 2.
• Correct permissions:
  • The target desktops’ computer accounts or entitled user accounts can read the SMB share, according to the access model used in your environment.
  • The storage credentials registered in App Volumes Manager can create and update package files on the share.
• Application installer – The software to capture. This guide uses Notepad++ as the example application.

 

 

• Packaging VM – A clean Windows VM with the App Volumes Agent installed. Match the target desktop OS version and patch level, omit the Horizon Agent and Dynamic Environment Manager FlexEngine, and take a clean snapshot so the VM can be reverted after each capture. These points follow Omnissa’s packaging recommendations.

Create an Omnissa App Package with In-Guest VHD

Open App Volumes Manager, enter your administrative credentials, and click Login.

 

 

Go to Inventory > Applications and click Create.

 

 

Enter a Name and, optionally, a Description for the application. Click Create.

 

 

Click Create again to confirm the application.

 

 

On the Packages tab, enter a package Name, select the SMB share under Storage location, and add an optional Description. Click Create.

 

 

Leave Perform in the background selected unless you need to wait for completion in the current session, then click Create.

 

 

The new package appears on the Packages tab with the Unpackaged status. Expand the package and click Package to select a provisioning computer.

 

 

In Find Packaging Computer, enter the name of the dedicated packaging VM and click Search. The VM must be powered on, joined to the Active Directory domain, and running the App Volumes Agent. Select the correct result and click Package.

 

 

Click Start Packaging.

 

 

App Volumes prompts you to restart the packaging VM. Reboot it to begin the capture workflow.

 

 

After the VM restarts, sign in through RDP. A notification confirms that the packaging disk has been attached. Click OK.

 

 

Copy the previously downloaded installer to the desktop before capture begins, then click Yes to start capturing changes.

 

 

Install the application as you normally would. The App Volumes packaging process records the installation changes in the background.

 

 

Complete the application’s installation wizard.

 

 

When installation is complete, return to the App Volumes Packaging dialog and click OK.

 

 

If the application installed successfully, click Yes.

 

 

Review the package information, then click Finalize.

 

 

Click OK to restart the packaging VM and complete the workflow.

 

 

After the VM restarts, sign in once more so App Volumes can finalize the package.

 

 

When App Volumes reports that packaging completed successfully, click OK. Revert the packaging VM to its clean snapshot before capturing another application.

 

 

Set the current package version

An application can contain several package versions. The Current marker identifies the version delivered by assignments that use the marker. On the Packages tab, select the package version you want to publish and click Set Current.

 

 

Click Set Current again to confirm.

 

 

The selected package is now marked Current and is ready for assignment.

 

 

Assign the package to users

Open the Applications tab, expand the application, and click Assign.

 

 

In Search Directory Service, select the configured Active Directory domain, enter the target group name, and click Search. Select the group, such as G_HorizonUsers in this example, and set Assignment Type to Marker. With a marker assignment, users receive whichever package version is marked Current. Click Assign.

 

 

Review the assignment details and click Assign to confirm.

 

 

Open the Assignments tab and confirm that the application and Active Directory group are listed.

 

 

Test the assigned package

Connect to the Horizon environment and sign in with a test user who belongs to the assigned Active Directory group. Click Login.

 

 

Launch the assigned VDI desktop. An In-Guest VHD package does not appear as a separate published application in the Horizon portal; App Volumes attaches it inside the Windows desktop session.

 

 

Inside the VDI, locate the Notepad++ shortcut and open the application.

 

 

Confirm that the application starts and its basic functions work as expected.

 

 

For an administrative check, return to App Volumes Manager and open the Attachments tab. Confirm that the expected package is attached to the test desktop and user session.

 

Conclusion

The Notepad++ installer is now captured in a VHD package, marked as the current version, assigned to an Active Directory group, and verified from both the user desktop and App Volumes Manager. This completes the series: the same App Volumes environment now provides persistent user data through Writable Volumes and centrally managed applications through packages stored on SMB.

FAQ

What is an Omnissa App Volumes package?

It is a read-only virtual disk that contains one version of an application. With VHD In-Guest Services, the package is stored as a VHD file on an SMB share and mounted inside an entitled endpoint by the App Volumes Agent.

Why should the packaging VM be clean?

A clean VM limits captured changes to the application itself. Match it to the target desktop’s OS and patch level, take a snapshot before packaging, and revert to that snapshot before capturing the next application.

What does the Current marker do?

It identifies the package version used by assignments configured with the Marker assignment type. Moving the Current marker to a newer tested package updates which version those assignments deliver.

Does the target desktop need access to the SMB share?

Yes. The endpoint must be able to reach the SMB 3 share and read the assigned VHD package. App Volumes Manager’s registered storage credentials need sufficient rights to create and update package files.

How can I verify that the package was delivered?

Sign in as an entitled test user, launch the VDI desktop, and open the packaged application. Then check the Attachments tab in App Volumes Manager to confirm that the expected package is attached to that session.

from StarWind Blog https://bit.ly/45ZoGjG
via IFTTT