Hackers Exploited Cisco SD-WAN Flaw to Plant Malware Built to Steal Encryption Keys

Hackers exploited a critical Cisco Catalyst SD-WAN flaw, fixed in February, to plant custom malware inside the systems that control an organization's SD-WAN network.

The malware, called KeyDrift, is designed to copy the keys that encrypt traffic between sites and store them for later use, Cisco Talos said on October 28. Talos calls the attacks historical but does not specify when they occurred or whether any keys were sent.

The flaw is tracked as CVE-2026-20127 and has a CVSS score of 10.0. It allows an unauthenticated remote attacker to bypass authentication and gain administrative privileges on these control systems. On a Controller, the attacker can log in as a high-privileged internal account that is not root.

When Cisco disclosed the flaw in February, Talos tracked its exploitation as UAT-8616, a cluster of activity it said went back to at least 2023.

In Cisco's traditional key exchange, each SD-WAN router periodically generates an AES key for its traffic and sends it to the Catalyst SD-WAN Controller (formerly vSmart). The Controller passes the keys on to other routers. A process on the Controller called vdaemon runs the encrypted control connections that carry these keys.

On a compromised Controller, a KeyDrift component called LittleFilch hooks into vdaemon and reads control messages after they are decrypted. For a preset list of edge routers, it pulls out their IP addresses and a 32-byte field. Talos assesses that field as the AES-256 key material that the Controller passes between routers.

LittleFilch encrypts what it collects with RSA and writes it to a file. It can then send that data over UDP to an address listed in a settings file, which it deletes after reading. Talos could not recover that settings file.

The group behind KeyDrift, which Talos tracks as UAT-11473, has targeted space and satellite services, defense and aerospace technology, and policy research.

The group's infrastructure "overlaps considerably" with Silent Train, Talos assesses with high confidence. Silent Train is the name Lumen's Black Lotus Labs uses for a network of hacked small-office, home-office, IoT and business devices.

Lumen says Volt Typhoon used the network to hide its activity. CISA, the NSA and the FBI said in 2024 that Volt Typhoon is a Chinese state-sponsored cyber group.

Talos links UAT-11473 to Volt Typhoon only through the infrastructure overlap. It does not say the two are the same group, or how UAT-11473 relates to UAT-8616, the cluster it reported in February.

Separately, Lumen said on October 28 that Volt Typhoon was exploiting CVE-2026-20127 by late 2025 and continued to exploit it after Cisco disclosed the flaw in February. Lumen does not tie that activity to KeyDrift.

KeyDrift primarily starts via modified runit scripts that Cisco SD-WAN devices use to launch their services, according to Talos. In one version, the script for the SSH service starts a loader script, conf_sshd, before the real SSH server. The conf_sshd script writes vdaemon's process IDs to a file, and a tool called rsshd injects KeyDrift's main module, PolyFlame, into each of those processes.

PolyFlame runs in memory inside vdaemon. It can act as a TinyShell-like backdoor that runs commands and reads and writes files, or as a relay that forwards commands between its command server and other machines. It is built to accept commands within SD-WAN control traffic, and the analyzed samples contained no hardcoded server address.

On a compromised Validator, formerly vBond, a fake aaamgr service under /etc/sv/aaamgr/ runs a packed loader, aaamgrd, that decrypts and runs PolyFlame. Cisco's real aaamgr component is a Python package and does not normally run as a compiled service.

There are also signs of timestomping: commands the group ran copied the timestamps and permissions of existing files onto its own files.

Affected Releases and Fixes

CVE-2026-20127 affects the Catalyst SD-WAN Controller (formerly vSmart), Manager (formerly vManage), and Validator (formerly vBond), regardless of their configuration. On-premises systems are affected, as are Cisco's hosted SD-WAN cloud deployments, including the Cisco Managed and FedRAMP environments. Cisco added the Validator to its advisory on June 16.

Cisco says it is aware of limited exploitation of the flaw. There is no workaround, and the first fixed releases are:

Release train	First fixed release
Earlier than 20.9	Migrate to a fixed release
20.9	20.9.8.2
20.11	20.12.6.1
20.12	20.12.5.3 or 20.12.6.1
20.13	20.15.4.2
20.14	20.15.4.2
20.15	20.15.4.2
20.16	20.18.2.1
20.18	20.18.2.1

Releases earlier than 20.9 and the 20.11, 20.13, 20.14 and 20.16 trains have reached end of software maintenance.

Until they can upgrade, on-premises customers can limit access to ports 22 and 830 to the IP addresses of known controllers and other known systems. Cisco says this step worked in a test environment, but that customers should check how well it works in their own networks. Such guardrails are already in place for Cisco's hosted SD-WAN cloud deployments.

Blocking the ports does not remove malware already on a device.

Checking for KeyDrift

Talos advises organizations to install Cisco's fixes, follow Cisco's Catalyst SD-WAN hardening guide and watch for signs of post-compromise activity. Anyone who finds such signs should start incident response and can ask Cisco's Technical Assistance Center (TAC) for help.

That advice does not say whether upgrading removes KeyDrift from a device that was already compromised, or whether any keys should be replaced. Cisco's February remediation guide for this flaw warns that there could be "existing exploits which are still in place" from before an upgrade.

KeyDrift uses these files and locations, some given only by name:

• File: the run script under etc/sv/sshd/, modified to start conf_sshd
• Directory: /etc/sv/aaamgr/, a fake service on a compromised Validator
• File: aaamgrd, the packed loader
• File: conf_sshd, the loader script
• File: rsshd, the injector
• File: libdssl.so, PolyFlame
• File: libcommon.so, LittleFilch
• File: /tmp/system-vdaemon, the list of vdaemon process IDs
• File: /var/tmp/vdaemon.bin, LittleFilch's encrypted records
• File: /var/tmp/vdaemon.conf, LittleFilch's send settings, deleted after reading

Talos's report does not include a list of file hashes, IP addresses or domains for KeyDrift.

Talos released Snort rules on October 28 that look for inbound KeyDrift command-and-control connections: 67387 through 67416 for Snort 2, and 7:44 through 7:73 for Snort 3. Rules 65938 and 65958, already available, cover CVE-2026-20127 itself.

The October 28 rule update lists the Snort 2 rules as disabled by default, so users of the paid Snort Subscriber rule set must turn them on. The Snort 3 rules appear with no default state.

To check for exploitation of the flaw itself, Cisco says to look in /var/log/auth.log for Accepted publickey for vmanage-admin entries from unknown IP addresses. Before opening a TAC case, customers should run request admin-tech on each control component. The remediation guide also recommends rescanning those admin-tech files with the Check Bug Applicability feature on the Bug Search Tool page for bug CSCws52722.

For US federal civilian agencies, CISA's February 25 emergency directive sets out what to do if a root account compromise is found. They must report it to CISA, deploy fresh Manager, Controller and Validator instances from patched images, and move their edge routers to the new systems.

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/cE0nzhd
via IFTTT

pfSense at 20

Twenty years of pfSense software

Twenty years ago this month, pfSense® software version 1.0 shipped. It started as a small fork of m0n0wall, built by a handful of people who wanted a better firewall than anything they could buy.

Today pfSense software protects and connects hundreds of thousands of networks in: homes, schools, hospitals, ISPs, public and private Cloud and in some of the largest companies in the world. Netgate® has been the largest contributor to the pfSense project over its entire lifetime, but none of this happened because of us alone. It happened because of you: your interest, your support, and your help making pfSense software relevant and useful to everyone who needs to connect securely to the Internet.

So for the twentieth anniversary, we’re looking ahead to where pfSense software needs to go and giving something back to everyone who has made it part of their network security stack. This is the first of several things we’ll be celebrating and announcing through 2027.

One pfSense

Starting with release 26.10, there is one edition of pfSense software. The separate pfSense CE and pfSense Plus editions are now one. Splitting pfSense software was the right call for its time. It let new users get up to speed on firewalls, VPNs, routing and general networking principles with zero-cost, fully featured production-ready software. It also let us fund the kernel and system engineering that pfSense software needed, the backend infrastructure, testing, 24/7 assistance, etc. and this is how features like in-kernel PPPoE, IPsec multi-buffer, the pf L2 filtering we upstreamed to FreeBSD, and ZFS boot environments with rollback got built. But two editions also meant two codebases, two release tracks, and too many conversations about which you should be running.

With release 26.10, everyone runs the same pfSense software:

• The full feature set, free on any amd64 hardware. Every feature is included, from Snort 3 with Intel Hyperscan to ThreatGate with Zero Trust Egress (ZTE). It installs and reinstalls at no cost, with no account or registration required. On AWS, Azure and other public clouds, pfSense software remains available through our marketplace images.
• The new GUI and the full API, for everyone. If you’ve built automation on a third-party API package, the built-in API is now the supported path. The documentation is on GitHub.
• Security updates and bug fixes, free and online.
• The air-gapped installer is back, so you can install pfSense software on networks that never touch the Internet.

This isn’t a promotion or an introductory offer. This is how pfSense software works from now on: the full feature set, with free security fixes.

Netgate keeps you secure, for free

Every pfSense install gets security fixes at no cost, whether it runs on our hardware or yours, and whether or not you ever pay us anything.

This matters more now than it did even a year ago. AI tools are finding bugs in widely used open-source code faster than ever, which means more “patch it now” days for everyone, not fewer. When a critical fix lands in FreeBSD, OpenSSL, or anything else pfSense software is built from, we want it on your firewall as soon as it’s ready, not at the next release.

Moving the base system to packages in 26.10 is what makes this possible. We can ship a fix for just the component that needs it, and you install it like any other update. Security fixes go to the current release, and since moving to a new release is free, every pfSense install can always be on a release that’s getting them.

This is also why we’re retiring the PHP-based GUI. We’ll remove it, with notice, once the new GUI covers everything it does. Much of the security work on pfSense software in recent years has gone into fixing bugs in old PHP code, and keeping up will only get harder as these bugs are found faster. The new GUI and API are built to remove this whole class of problem, not just patch it.

What you can pay for is convenience and help: online upgrades to new versions, fleet management at scale, and support. We don’t charge for security.

If you run pfSense CE software today

You get everything Plus users have had, on the hardware you already own. Nothing about your existing install stops working, and your configuration comes with you.

This includes:

• OpenVPN® data channel offload (DCO) and Intel IPsec Multi-Buffer (IIMB) crypto, for much faster IPsec, OpenVPN and WireGuard® VPNs
• Intel QuickAssist (QAT) crypto acceleration, on hardware that has it
• ZFS boot environments, so you can roll back a bad upgrade or configuration change
• Unicast CARP, for high availability where multicast doesn't work, including many hypervisors and clouds
• Ethernet (layer 2) filtering rules
• 802.1X authentication bridging and VLAN 0 tagging on the WAN, so an ISP gateway that has to authenticate to the network can do so without sitting inline in your traffic. AT&T fiber is the common case.
• Native NetFlow and IPFIX export, straight from firewall states
• LDAP client certificates
• The AWS VPC wizard, IPsec profile wizard and OpenVPN client import packages

We're also publishing the updated PHP and the FreeBSD source for 26.10 to GitHub.

Upgrading from pfSense CE software 2.9 to release 26.10 is free, and it happens in place, the same way you upgrade today.

From release 26.10 on, security fixes keep arriving online, for free. To move to a new version, reinstall from the installer at no cost. It saves and restores your configuration for you. Or, if you’d rather skip the reinstall, upgrade online in one step with a subscription.

The most widely used packages, including HAProxy, FRR and ACME, continue to work on release 26.10. pfBlockerNG continues to work in the existing GUI until that GUI is retired, and ThreatGate, now built in, is its successor for DNS-based blocking.

If you run pfSense Plus software today

Your existing subscription carries over, whether it’s TAC Lite, TAC Pro or TAC Enterprise, and you keep online upgrades. You don’t need to do anything.

If you bought Netgate hardware, nothing changes either: online upgrades to every new version are included for the life of the appliance, with no subscription required.

For partners and MSPs, one product means one thing to deploy, one thing to support, and no more questions about which edition a customer should run.

When

pfSense software version 26.10 will be released before the end of November. We're announcing it now because October is the pfSense project's birthday, and this is the change we wanted to mark it with.

Release notes, online and air-gapped installer images, and upgrade instructions will be on netgate.com on release day.

Thank you

pfSense software exists because people tested releases, answered forum questions at 2 a.m., wrote packages, filed good bug reports and told their friends. Twenty years of this is why it’s still here.

We’ll keep doing our part. Our software engineers, TAC engineers and SREs bring decades of experience across hardware, software, firmware and systems deployment, and they’re the people who take on the hardest problems. Netgate is the third-largest sponsor of FreeBSD by commit volume over both the last five and the last ten years, with several FreeBSD committers on staff. Much of what we build for pfSense software goes upstream, so everyone who builds on FreeBSD benefits. This includes the igc driver for Intel’s 2.5G NICs; layer 2 filtering in pf, used by the pfSense captive portal; dummynet support in pf for traffic shaping; and, just this month, an iflib fix that makes packet forwarding on FreeBSD much faster.

Here’s to the next twenty years of keeping your network secure.

from Blog https://ift.tt/k4AOWN9
via IFTTT

Attackers Exploit PHP2Shell Flaws in Internet-Exposed Palo Alto Networks Management Interfaces

Palo Alto Networks on Wednesday warned that threat actors are exploiting the recently patched PHP2Shell vulnerabilities against publicly-accessible management interfaces.

"Active exploitation has been observed targeting the Palo Alto Networks management interface exposed to the internet," the network security company said in an update to its advisory.

The vulnerabilities, tracked as CVE-2026-109618 and CVE-2026-109619 (CVSS scores: 9.2), allow attackers to achieve unauthenticated remote code execution on systems running affected versions of PHP. The issues were patched upstream by the PHP Foundation on October 21, 2026, in versions 8.5.12, 8.4.27, 8.3.36, and 8.2.35.

The development comes days after Israeli cybersecurity company Dream said it observed a suspected China-nexus threat actor weaponizing the flaws in conjunction with a local privilege escalation bug in the Linux kernel, tracked as Fragnesia (CVE-2026-46300, CVSS score: 7.8), to root 25 servers across the U.S., Japan, Taiwan, and South Korea.

Among those were three systems belonging to a U.S. government-affiliated environment.

"The affected devices run specific versions of a large vendor's firewall software," Dream noted. "The attacker then launched attacks against Active Directory. The recovered artifacts confirm credential extraction and directory enumeration."

Although Dream did not disclose the name of the affected firewall vendor, the timing of the advisory, combined with the fact that other network security companies have not reported malicious exploitation against their products, suggests that these events may be related.

The Hacker News has contacted both Dream and Palo Alto Networks for comment, and we will update the story if we hear back.

The development has prompted the U.S. Cybersecurity and Infrastructure Security Agency (CISA) to add CVE-2026-46300 to its Known Exploited Vulnerabilities (KEV) catalog, requiring federal agencies to apply the fixes by October 31, 2026.

"This vulnerability can be chained with CVE-2026-109618 and CVE-2026-109619 to implant PHP web shells and run commands as root," CISA said.

Palo Alto Networks has also noted that no special configuration is required to be affected by this issue, adding the risk is highest on PAN-OS when access to the management interface is allowed from external IP addresses on the internet.

"This issue strictly affects the management web interface, which includes the HTTPS web UI and XML API service," it said. "It affects the dataplane interface only if a management profile is attached to it."

The following versions of PAN-OS are impacted by PHP2Shell -

• PAN-OS 12.2
  • < 12.2.4-h1 (Fixed in >= 12.2.4-h1)
• PAN-OS 12.1
  • < 12.1.4-h13 (Fixed in >= 12.1.4-h13) (ETA: 10/29)
  • < 12.1.7-h11 (Fixed in >= 12.1.7-h11)
  • < 12.1.10-h3 (Fixed in >= 12.1.10-h3) (ETA: 10/30)
• PAN-OS 11.2
  • < 11.2.4-h23 (Fixed in >= 11.2.4-h23) (ETA: 10/30)
  • < 11.2.7-h23 (Fixed in >= 11.2.7-h23)
  • < 11.2.10-h16 (Fixed in >= 11.2.10-h16)
  • < 11.2.13-h4 (Fixed in >= 11.2.13-h4)
  • < 11.2.16-h1 (Fixed in >= 11.2.16-h1)
• PAN-OS 11.1
  • < 11.1.4-h38 (Fixed in >= 11.1.4-h38)
  • < 11.1.6-h40 (Fixed in >= 11.1.6-h40)
  • < 11.1.7-h12 (Fixed in >= 11.1.7-h12) (ETA: 10/30)
  • < 11.1.10-h36 (Fixed in >= 11.1.10-h36)
  • < 11.1.13-h16 (Fixed in >= 11.1.13-h16)
  • < 11.1.16-h4 (Fixed in >= 11.1.16-h4)
• PAN-OS 10.2
  • < 10.2.7-h39 (Fixed in >= 10.2.7-h39) (ETA: 10/30)
  • < 10.2.10-h42 (Fixed in >= 10.2.10-h42) (ETA: 10/29)
  • < 10.2.13-h27 (Fixed in >= 10.2.13-h27)
  • < 10.2.16-h12 (Fixed in >= 10.2.16-h12)
  • < 10.2.18-h13 (Fixed in >= 10.2.18-h13)

For PAN-OS versions where fix versions are not yet available, Palo Alto Networks has recommended the following mitigations -

• Route incoming traffic for the MGT port through a DP port, e.g., enabling management profile on a DP interface for management access.
• Replace the Certificate for Inbound Traffic Management.
• Decrypt inbound traffic to the management interface so the firewall can inspect it.
• Enable threat prevention on the inbound traffic to management services.

"Customers with Frontier Virtual Patching (ATP Plus) on PAN-OS 12.2.4 and later versions received advance coverage, released via Threat ID 543004, which was released at 10:21 PM PT on October 20," it said.

"The security risk posed by this issue on PAN-OS and Panorama is minimized by restricting access to the management interface to only trusted internal IP addresses according to our recommended best practice deployment guidelines."

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

Inside KeyDrift: Analyzing historical UAT-11473 activity on Cisco SD-WAN

• Cisco Talos has identified UAT-11473, a highly sophisticated advanced persistent threat (APT) actor, who exploited CVE-2026-20127, an authentication bypass vulnerability in Cisco SD-WAN Catalyst Controller instances to bypass authentication and gain unauthorized access to affected systems.
• UAT-11473 then installed a custom malware framework we track as “KeyDrift” consisting of multiple components geared towards collecting sensitive keying information, acting as backdoors and intermediate command-and-control (C2) hosts.
• Observed targeting spans across space and satellite services, defense and aerospace technology, and policy research.

---

Talos assesses with high confidence that UAT-11473’s operating infrastructure overlaps considerably with Volt Typhoon’s “Silent Train” covert access network.

KeyDrift is a custom malware framework that is designed to operate in Cisco SD-WAN controller environments. Talos assesses with high confidence that the framework is designed to provide long-term persistent access and automated exfiltration of sensitive keying material. KeyDrift operates inside SD-WAN control-plane processes and is capable of intercepting decrypted control traffic, extracting control-session metadata and data-plane keying material, and staging or transmitting the collected material using encrypted records.

The framework's primary component is PolyFlame, a memory-resident module deployed through modified runit service paths. PolyFlame is injected into legitimate running vdaemon processes, and it can also masquerade as a packed “aaamgrd” loader variant. Once resident, PolyFlame interposes socket, DTLS, and runtime-linker behavior through functions such as recvfrom, sendto, getpeername, dlopen, dlsym, mprotect, and “/proc/%d/maps” parsing. This gives KeyDrift access to SD-WAN control-plane traffic from inside legitimate controller daemon execution rather than through a conventional endpoint beacon.

LittleFilch, another component of the KeyDrift framework, provides the collection and exfiltration capability identified in the framework. The module hooks “SSL_read” inside vdaemon, inspects decrypted control-plane buffers, extracts keying material for a list of predefined edge nodes, and stages the data locally in encrypted format for exfiltration.

Talos assesses with high confidence that KeyDrift's intended operational purpose is Cisco SD-WAN control-plane collection: persistent controller residence, in-band traffic access, key-material extraction from decrypted control messages, and encrypted staging or exfiltration of the recovered material. Observed variations of the KeyDrift modules and deployment mechanisms suggest active development of the framework’s capabilities.

KeyDrift analysis

KeyDrift uses Cisco SD-WAN runit service paths as its primary execution anchor. In the PolyFlame sshd deployment, the actor modifies the service run script, remounts /rootfs.rw executable, launches a malicious script “conf_sshd” in the background, and then starts the legitimate sshd service. The loader script enumerates running vdaemon PIDs, records them in “/tmp/system-vdaemon”, and invokes the injector component “rsshd” to inject PolyFlame (“libdssl.so”) into each process.

Recovered conf_sshd logic uses the same control flow across reviewed samples:

Figure 1. conf_sshd control flow logic.

Runit launchers

The observed sshd runit launcher preserves normal Cisco SD-WAN sshd startup logic while adding two malicious lines before service execution, which remount “/rootfs.rw” executable and background execution of conf_sshd, which then drives rsshd injection into vdaemon.

Figure 2. conf_sshd execution logic.

The recovered aaamgr runit launcher from an affected vBond appliance uses a parallel service-wrapper pattern, but it executes the packed aaamgrd PolyFlame loader directly. The deletion of the writable-overlay PAM configurations for sshd and login before remounting “/rootfs.rw” executable if part of the legitimate script, along with the invocation of the aaamgrd daemon via Python:

Figure 3. aamgrd daemon launch.

PolyFlame

PolyFlame is the primary operational module in the KeyDrift framework. PolyFlame operates at the socket and DTLS control-plane layer. PolyFlame serves two primary purposes:

• Command execution via a TinyShell-styled backdoor
• Intermediate C2 that can forward commands to and from the C2 to other peers

PolyFlame is primarily injected into the vdaemon process, providing operational obfuscation and access to all in-process state: DTLS session keys, vEdge topology, OMP routes, and policy tables. No hardcoded IPv4 addresses, binding ports, callback domains, URLs, host headers, or polling interval were recovered from the analyzed PolyFlame samples. PolyFlame is designed for in-band control or tasking over Cisco SD-WAN control-plane traffic rather than a conventional fixed external beacon.

This implant is meant to serve as a hook of the recvfrom() API call. The original recvfrom is replaced by a malicious subroutine in the vdaemon process. When recvfrom is called in the vdaemon process, the malicious subroutine will first execute the real/legitimate recvfrom() API to obtain the C2 IP address info for communicating with it in the future.

PolyFlame’s time check

The recvd data from the C2 consists of the MD5 value of a specific DATE. PolyFlame will calculate the local time on the device in format “%Y-%m-%d" and calculate its MD5 hash. If the MD5 calculated by the device does not match with the one sent by the C2, the implant will stop further execution. Otherwise, the implant then uses an “administrative code” from the C2 and performs an action.

PolyFlame’s tasking

PolyFlame contains an administrative mode that processes the admin code sent by the C2, that defines operations — it's one of the first flags checked in the backdoor:

• Code = 1: Generate random bytes and send to C2. This is likely a check-in beacon or heartbeat for the C2.
• Code = 2: Set implant type to backdoor (TinyShell) or intermediate C2.
• Code = 3: Set up the command handler for the intermediate C2.
• Any other code value: Check the implant type flag currently set. Based on the implant type flag, either send the accompanying data to TinyShell or the intermediate C2 component for processing.

PolyFlame’s command execution

PolyFlame contains a backdoor that matches the capabilities of TinyShell: file read, file write, and arbitrary command execution, but not interactive shell. This backdoor component’s implementation is quite similar to TinyShell, but the command codes differ. PolyFlame handles the following command codes:

• Code = 0x100: Execute command using “/bin/sh -c <command>”
• Code = 0x200: Write file to disk.
• Code = 0x300: Read file from disk and send to the C2.

PolyFlame as an intermediate C2 component

The intermediate C2 component is a one-to-many handler (somewhat like a one-to-many multiplexer) — meaning the implant can connect to only one C2 but can connect to many peers who can be served by the intermediate C2 component. Similar to the TinyShell-backdoor component, the intermediate C2 component also accepts and processes specific command codes from the C2:

• Code = 0x403: Create a thread to connect to the specified peer IP. Make a new connection and keep socket alive until specified.
• Code = 0x404: Send data recvd from the C2 to a connected peer.
• Code = 0x405: Remove a peer from the list of active connections.
• Code = 0x407: Send a response recvd from a peer, back to the C2.
• Code = 0x408: Set a specific value in memory.

PolyFlame variant: aaamgrd

 Talos has observed a distinct PolyFlame variant that masquerades as the aaamgr service. The legitimate Cisco aaamgr component is a Python package; it does not normally appear as a compiled ELF runit service. This PolyFlame variant is executed by a malicious runit service under “/etc/sv/aaamgr/” with aaamgrd and a modified run launcher.

aaamgrd is a statically linked ELF64 executable with no section headers, a single RWE loader segment, and an RC4-encrypted embedded ELF payload. The loader uses direct syscalls including ptrace, fork, wait4, kill, tgkill, mmap, and mprotect. It performs an anti-debug check by deobfuscating /proc/%d/status and TracerPid: and exits if a tracer is present.

The observed staging sequence was:

Figure 4. PolyFlame staging sequence.

Note that in addition to the implant execution staging, there are also indications of timestomping.

LittleFilch: libcommon.so TLS interception module

LittleFilch is a control-session interception module positioned to collect data-plane keying material from control sessions visible to the injected vSmart process.

LittleFilch installs an SSL_read hook inside vdaemon. The hook calls the original SSL_read, then processes returned buffers only when the returned size is greater than 0x18F, the first decrypted byte is 0x07, and three marker patterns are checked for presence. These marker bytes are followed by the actual artifacts that LittleFilch aims to record:

Marker bytes	Parsed field	Length	Notes
40 03 06	Public IP	4 bytes	vEdge public / transport IP
40 0C 04	Peer system-IP	4 bytes	vEdge OMP system-IP
05 01 0C 06 40	Binary key field	32 (0x20) bytes	Assessed OMP-distributed AES-256 IPsec data-plane key material

LittleFilch records the extracted keying material and RSA-encrypts it before writing the output to “/var/tmp/vdaemon.bin”. It can then send the encrypted content over UDP in a DTLS 1.2 application-data style record.

Figure 5. Keying material recording format used by LittleFilch.

LittleFilch expects its configuration file — located at “/var/tmp/vdaemon.conf” —  to contain two host port lines: one local bind IP/port and one remote destination IP/port. It deletes “/var/tmp/vdaemon.conf” after reading it. Talos has not been able to recover the “vdaemon.conf” file.

KeyDrift components

Component	Primary hook/surface	Observed scope	Confirmed function
PolyFlame libdssl.so	Socket / DTLS / runtime linker interposition inside vdaemon	Multiple affected controller roles	In-band control-plane interception and tasking; exact command format unresolved
rsshd	Ptrace injection	Multiple affected controller roles	Injects libdssl.so into vdaemon by PID
conf_sshd	Shell-based PID enumeration	Multiple affected controller roles	Locates vdaemon PIDs and records injection output
Trojanized run	Runit service launcher	Multiple affected controller roles	Remounts overlay executable and launches injector chain
Packed aaamgrd	Packed loader, direct syscalls, anti-debug	Affected vBond appliance evidence	Decrypts and runs embedded PolyFlame payload; tampers with PAM configs
LittleFilch libcommon.so	OpenSSL SSL_read hook	Affected vSmart process evidence	Extracts control-session identifiers and assessed data-plane key material from decrypted control traffic
vdaemon.bin	Encrypted staging file	Affected vSmart process evidence	Stores RSA-encrypted LittleFilch telemetry records
vdaemon.conf	Runtime endpoint config	Affected vSmart process evidence	Supplies local and remote UDP endpoint configuration; deleted after read

MITRE ATT&CK techniques 

Technique	ID	Notes
Process Injection: Ptrace System Calls	T1055.008	rsshd injects libdssl.so into vdaemon by PID
Hijack Execution Flow: Dynamic Linker Hijacking	T1574.006	PolyFlame uses dlsym(RTLD_NEXT, ...), dlopen, and runtime interposition
Boot or Logon Initialization Scripts	T1037	Modified runit service scripts launch KeyDrift components
Create or Modify System Process	T1543	Malicious service paths under etc/sv/sshd/ and etc/sv/aaamgr/
Masquerade Task or Service	T1036.004	sshd and aaamgr service-name masquerading
Unix Shell	T1059.004	conf_sshd and recovered operator staging commands
Software Packing	T1027.002	aaamgrd uses packed embedded ELF payload
System Checks	T1497.001	aaamgrd checks TracerPid before unpacking
Timestomp	T1070.006	touch --reference= and chmod --reference= staging commands copied reference file metadata
Network Sniffing	T1040	PolyFlame and LittleFilch intercept SD-WAN control-plane traffic
Encrypted Channel: Symmetric Cryptography	T1573.001	PolyFlame AES implementation; aaamgrd RC4 packer; LittleFilch RSA-encrypted records

Recommendations

Cisco has released patches for CVE-2026-20127 and published a hardening guide for Cisco Catalyst SD-WAN deployments available here. Organizations are strongly advised to prioritize the application of these patches and follow the guidance provided.

Following the identification of UAT-11473 activity, Talos strongly recommends that organizations monitor their systems for indicators of post-compromise activity. Should any signs of unauthorized activity be detected, organizations should immediately activate their incident response frameworks. Contact the Cisco Technical Assistance Center (TAC) for support by initiating a TAC request.

Coverage

Snort SIDs are already available for CVE-2026-20127: 65938, 65958.

Snort SIDs for the malicious artifacts illustrated in this blog:

• Snort v2: 67387 through 67416
• Snort v3: 7:44 through 7:73

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

Volt Typhoon Used Covert Silent Train Network in Four Zero-Day Exploitation Campaigns

The China-nexus cyber espionage group known as Volt Typhoon has been attributed to a now-disrupted covert access network dubbed Silent Train that has been put to use for zero-day exploitation and strategic access.

"First identified in late 2023, Silent Train uses rotating chains of compromised SOHO, IoT, and enterprise infrastructure," Lumen Technologies Black Lotus Labs said in a report shared with The Hacker News. "It employs anti-forensic techniques, compartmentalized operations, and post-operation cleanup to minimize detection and attribution."

Its main purpose is to facilitate critical attack phases like vulnerability exploitation, credential access, data exfiltration, and to maintain continued access to victim environments. The activity stands out for two main reasons -

• It singled out entities that could provide scalable access to downstream customers, sensitive networks, or strategic programs.
• It targeted endpoint management platforms, network management systems, SD-WAN orchestrators, and control plane technologies that play a crucial role within enterprise environments.

Hundreds of victims have been identified across telecommunications providers, government, defense contractors, satellite and mission-critical communication services, universities, IT firms, and critical infrastructure such as water, energy, transportation, maritime, rail, aviation, and emergency services.

Volt Typhoon (aka Bronze Silhouette, Insidious Taurus, UNC3236, Vanguard Panda, and Voltzite) is the moniker assigned to a China-linked state-sponsored group known for its targeting of critical infrastructure networks, particularly communications, energy, transportation, and water and wastewater systems sectors.

Known to be active since at least 2021, the threat actor was previously observed exploiting a file upload vulnerability in Versa Director as a zero-day (CVE-2024-39717) to deliver a bespoke web shell called VersaMem designed to harvest credentials and enable access to downstream customers.

The latest findings from Black Lotus Labs show that the security flaw was one among four confirmed zero-day campaigns the threat actor has conducted through Silent Train. The remaining three vulnerabilities are listed below -

• CVE-2025-8875 and CVE-2025-8876 - A set of insecure deserialization and command injection vulnerabilities in N-able N-central.
• CVE-2026-20127 - An authentication bypass vulnerability in Cisco Catalyst SD-WAN Controller
• CVE-2026-16812 - An operating system command injection vulnerability in Arista VeloCloud Orchestrator

Separately, Volt Typhoon is also suspected to have taken advantage of a likely zero-day vulnerability in Quest KACE before it was patched in October 2025. The campaign is estimated to have impacted more than 30 victims.

"Silent Train is built around rapidly rotating chains of compromised SOHO, IoT, and enterprise devices that are exploited on demand, used against carefully selected targets, cleaned up after each operation, and continuously refreshed," Black Lotus Labs said.

"This model has enabled Volt Typhoon to conduct exploitation and post-exploitation operations with exceptional operational security while minimizing opportunities for detection, attribution, and disruption."

A defining characteristic of these attacks is the repeated targeting of systems that can open the door to broad visibility, control, and access across large enterprise environments of strategic value to the U.S.

What's interesting is that the covert access capability began to take shape sometime around November 2023, just weeks before the first round of disruption targeting KV-botnet, an IoT botnet linked to multiple China-nexus state-sponsored threat actors, including Volt Typhoon.

Silent Train's operational activity is said to have surged in the wake of the botnet's second disruption in late January 2024, while simultaneously shifting to an ephemeral infrastructure comprising diverse device types and across geographies.

"Rather than continue using persistent infrastructure, Volt Typhoon shifted to a model using one-time-use chains of compromised devices that it could rebuild as needed," Black Lotus Labs said. "Volt Typhoon rapidly assembled and dismantled transient infrastructure, creating a resilient, secure, and compartmentalized framework that protected valuable access."

Described as a "layered, multi-hop framework," Silent Train is designed to let Volt Typhoon operators relay malicious traffic through several devices before it reaches the targets so as to obscure its origins from both victims and defenders. Each link in the chain serves a specific purpose -

• Virtual private servers (VPS) that function as a temporary staging area and allow threat actors to provision and discard them after each session. The sessions begin from VPS infrastructure located outside the U.S.
• Compromised non-U.S. SOHO and IoT devices located across different countries, providers, and hardware that conceal the starting point of the attack.
• U.S.-based compromised devices that function as an exit node before reaching the domestic victim and help evade geofencing and IP reputation blocklists.

No less than 27 device classes, ranging from SOHO and IoT devices (e.g., TP-Link, Intelbras, Ruckus Wireless, SATO, NETGEAR, Zyxel, and Cambium) to enterprise platforms (e.g., Fortinet, Cisco, PRTG, Mirth Connect, and CyberPanel), have been exploited and enrolled into the covert network.

"Silent Train stands out for its operational discipline, focusing on short-lived, selfmanaged sessions rather than persistent relays or C2 infrastructure," Black Lotus Labs said. "To construct these sessions, its operators exploit exposed web interfaces on SOHO, IoT, and other relay devices, then deploy only the tooling needed to enable chained SSH access through the compromised node."

"This included temporary SSH services, keys, configuration files, and 'live off the land' utilities. At the end of operational sessions, they removed every artifact and dismantled the operational chain in their wake. Silent Train sessions lasted about four hours on average, with some lasting only minutes."

Another notable aspect is the designation of certain device types to specific positions within Silent Train. For instance, Intelbras modems have been found to only appear as relay nodes, while Netgear Orbi and Fortinet FortiGate appliances served as U.S.-based intermediary and exit points responsible for interacting with the victim.

Put differently, the infrastructure points to deliberate compartmentalization across layers, confining some device types to certain roles that remain constant while the underlying infrastructure itself changes over time so as to complicate attribution efforts.

By early 2025, however, Silent Train is believed to have evolved from a completely ephemeral relay network to a hybrid architecture that retained enterprise-grade devices for an average of one to three months instead of changing them after each engagement.

Subsequent maturation of the platform introduced reverse-tunnel variants that used open-source proxies like Chisel and FRP to send traffic from infected devices to upstream infrastructure.

Within the U.S., Hawaii, California, and Texas have emerged as the focus areas of Silent Train operations, which boils down to the fact that these states host major military installations, telecommunications infrastructure, defense contractors, satellite communications providers, and critical logistics networks.

"Victimology indicates deliberate efforts to maintain access to critical ecosystems that support defense, logistics, communications, military and civilian operations, especially during heightened tensions or crises in the Indo-Pacific region," Black Lotus Labs said.

"The resulting picture is one of a highly structured framework built to acquire, protect, and sustain strategic access at scale. Through repeated targeting of centralized management platforms and control plane technologies, Silent Train shows how Volt Typhoon systematically pursues and preserves access to some of the most consequential networks in the United States."

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

The CISO’s evolving role: Protecting and defending in the agentic era

October is Cybersecurity Awareness Month, and it’s a good time to think about how much the world has changed for chief information security officers (CISOs) in the last 12 months.

A year ago, we thought we were already in the thick of AI and starting to understand it. Since then, agents have spread across the enterprise faster than most organizations anticipated. According to our Work Trend Index Annual Report, the number of active agents in the Microsoft 365 ecosystem grew 15-fold year over year and 18-fold in large enterprises. Employees are building and deploying AI systems that can access company data, interact with applications, and take actions on their behalf. These systems are built with good intentions, but even well-intentioned agents can introduce risk when access and behavior are not appropriately governed.

At the same time, more people inside our companies are building with AI. Many of them haven’t written code in years, if ever, and they aren’t necessarily thinking about security the way a security team would. That isn’t a criticism. It’s how quickly the technology has expanded who can build and what they can accomplish.

For CISOs, this creates two fundamental shifts. We have to protect an enterprise that increasingly operates through AI and agents. And we have to rethink how we defend that enterprise as attackers use AI to move faster and operate at greater scale. When I talk with CISOs, these are the two challenges I keep coming back to. We need to enable innovation without introducing unmanaged risk, and we need to modernize defense without losing the security fundamentals that still matter.

Get the 2026 Work Trend Index report

For builders: Build securely in the agentic era

Cybersecurity awareness has always been about people. This year, it has to include the people building agents. If you’re a developer, a builder, or someone who has just realized that AI can help you design and build things, this part is for you.

Give your agents their own identities. Where supported and appropriate, assign agents governed identities rather than personal or shared credentials. When something goes wrong, you need to know which agent did it and be able to shut it off.

Protect the data your agents touch. If an agent can reach information, assume it will use it. Make sure the right data protections are in place before you connect it. And remember that the agent will not think like you. It doesn’t share your judgment or your sense of what is appropriate. If you give it access to information or systems, it will act on that access, and that can quickly become a problem.

Your CISO wants you to build. They also need to know what’s being built, so they can help you do it safely. The best thing you can do for your security leader is to have the identity and data conversation early, before you build, not after.

For CISOs: Protect the enterprise as agent adoption grows

Your first job is to put guardrails in place so people can innovate carefully, without slowing them down. Good guardrails help teams move faster because they know where the lines are.

Start with observability, and make it deep. You need to know which agents exist, who owns them, what they can reach, and what they’re doing. You can’t protect what you can’t see. Deep observability also means knowing when an agent’s behavior changes, so your team can step in before a small issue becomes a big one.

Then hold people’s feet to the fire on identity and data. These are the two areas where I wouldn’t give any ground. Every agent needs a governed identity with only the access it needs, and the data it can reach needs to be classified and protected. When those two are in place, most other decisions get easier. Here’s how we’re approaching agent governance.

For CISOs: Defending differently

Your second job is to defend differently than you have historically done.

Attackers are using AI to move faster, and our latest Microsoft Digital Defense Report shows how much that is compressing the time defenders have to respond. But defending differently isn’t simply about adopting faster tools. It’s about changing how security teams turn information into action. The more integrated your environment is, the faster you’ll be able to see an attack and respond to it. An attack rarely shows up in just one place. Signals across identity, endpoints, applications, and cloud environments need to come together with threat intelligence and organizational context so defenders can understand what’s happening and respond before an incident escalates. When your tools work together, your team sees the full picture instead of pieces of it. It also requires a security approach built to continuously assess risk, make decisions, and act at the speed threats are developing.

You also need the right threat intelligence and the right partner. Threat intelligence helps organizations understand how threats are changing, which ones matter to their environment, and where to focus their defenses. Working with partners that have visibility across industries and organizations can provide broader context than an individual organization may have on its own. And you’re not going to operate at this speed without agents helping you. The same capabilities that make attacks faster can make defense faster, with agents working alongside your analysts to investigate and respond. That’s why we’re bringing integrated security operations and agentic defense together.

Two jobs, one goal

The pace of change over the last year has been significant, and it is likely to continue. None of this means slowing down. The CISOs I talk with want their companies to innovate. They need to protect the enterprise as it uses AI and the increasing speed of AI-enabled threats.

Prepare for an agent-driven workplace

Explore Work Trend Index insights on the changing role of agents at work and the trends shaping how organizations operate.

Explore the Work Trend Index

If you’re building with AI, bring your security team in early and have the identity and data conversation. If you’re a CISO, focus on those two jobs and make sure you have the right partners for both.

---

To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.

The post The CISO’s evolving role: Protecting and defending in the agentic era appeared first on Microsoft Security Blog.

from Microsoft Security Blog https://ift.tt/QXwzTYk
via IFTTT

American Organizations Under Attack: Skyw4lker Device Code Phishing Campaign Exposed

Modern phishing campaigns can compromise American businesses without relying on traditional credential theft. Attackers can abuse legitimate cloud services, authentication mechanisms, and trusted business workflows to gain access to corporate accounts while leaving fewer obvious signs behind.

ANY.RUN's analysis of Skyw4lker, a device code phishing campaign primarily targeting U.S. organizations, shows how this works in practice. The campaign has focused on manufacturing, technology, and healthcare, using business-themed documents, Google-hosted infrastructure, and Microsoft authentication flows to facilitate account compromise.

For security teams, the investigation goes beyond identifying the initial lure. It requires tracing the authentication flow and supporting infrastructure, extracting reliable indicators, and turning those findings into detections that can protect the wider organization.

Device Code Phishing: A Growing Challenge for U.S. Organizations

The scale of phishing in the United States provides an important backdrop. The FBI's Internet Crime Complaint Center recorded 193,407 phishing and spoofing complaints in 2024, making it one of the most frequently reported categories of internet crime. In 2025, the FBI recorded more than 1 million internet crime complaints and $20.9 billion in reported losses, with reported losses increasing by 26% compared with the previous year.

Attackers are also adapting to organizations that have invested heavily in identity security and MFA.

Device code phishing is one example. Rather than collecting credentials through a fake login page, an attacker can initiate a legitimate device authorization flow and convince the victim to complete it. The resulting authentication tokens can then provide access to resources available to the compromised account.

How Skyw4lker Uses Legitimate Authentication to Compromise Accounts

How the Skyw4lker Campaign Works

Skyw4lker starts with a lure designed to resemble normal business correspondence, as observed in ANY.RUN’s Interactive Sandbox analysis.

The Skyw4lker phishing kit identified in ANY.RUN’s Interactive Sandbox

Victims receive a password-protected document presented as a contract or service proposal. The scenario is credible in environments where employees routinely exchange vendor agreements, procurement documents, statements of work, and similar files.

From the document, the victim is directed toward a page hosted on sites[.]google[.]com, which eventually leads into a Microsoft authentication flow.

Skyw4lker redirecting the victims to a Microsoft365 authentication page

The attacker does not need to reproduce Microsoft's login experience perfectly. The authentication itself can be legitimate; the deception is in convincing the victim to complete an authentication request initiated by the attacker.

Once the process is completed, the attacker can obtain access to the resulting Microsoft 365 tokens.

That makes the attack difficult to evaluate through identity telemetry alone. An organization may see a valid authentication event without immediately seeing the malicious context that caused it. Establishing what happened requires the security team to connect the document, web activity, authentication flow, and associated infrastructure.

The Infrastructure Behind the Skyw4lker Phishing Page

The web infrastructure used by Skyw4lker provides additional evidence of the campaign's operation.

ANY.RUN’s analysis identified obfuscated JavaScript and a PHP backend used to create a victim session, collect information such as IP address and geolocation, and repeatedly poll the backend while waiting for the authentication process to complete.

Skyw4lker sample submissions in ANY.RUN’s Interactive Sandbox by country

A static inspection of the original document may reveal the starting URL, but it cannot fully explain what happens once the victim interacts with the page. The malicious behavior emerges through the combination of browser activity, JavaScript execution, backend communication, redirects, and authentication.

That makes behavioral analysis essential when the objective is to establish exactly what a phishing campaign is doing and which indicators can be trusted for follow-up detection.

View the Skyw4lker analysis in ANY.RUN’s Interactive Sandbox to see its complete attack chain and associated IOCs.

Reduce Tier 1 workload by up to 20% and give analysts more time to focus on critical threats.

Boost Your SOC Efficiency

Interactive Sandboxing Turns Suspicious Files and URLs into Actionable Evidence

An interactive sandbox lets security teams safely execute and interact with suspicious files, links, and documents, revealing behavior that static inspection can miss.

That matters in campaigns such as Skyw4lker, where the document is only the starting point. Analysts need to follow the attack through the browser, observe redirects and authentication activity, inspect network communication, and identify the infrastructure behind the phishing flow. All of this can be done in an isolated ANY.RUN Sandbox environment, with a result available in as little as 40 seconds.

The Tier 1 report for the observed Skyw4lker sample available in ANY.RUN’s sandbox

Instead of stopping at a malicious/benign verdict, the investigation can produce URLs, domains, IP addresses, network activity, screenshots, behavioral evidence, and other IOCs. These findings give security teams the context needed to validate an alert, scope-related activity, and create detections from evidence gathered during a single investigation.

As a result, SOC and MSSP teams can reach a confident verdict faster without manually reproducing the attack across multiple tools, while the resulting intelligence can support threat hunting and detection across the wider environment. Moreover, the same workflow makes it easier for MSSPs to investigate new campaigns and turn findings from one customer case into intelligence that can be searched across other environments.

Turning Threat Intel into Earlier Detection

The value of an IOC increases when it can be used to detect another attack.

ANY.RUN Threat Intelligence Feeds (TI Feeds) provide malicious IPs, domains, URLs, and contextual information derived from sandbox investigations. 99% of unique, high-confidence IOCs are added to TI Feeds after validation, helping security teams work with intelligence that has already been reviewed.

ANY.RUN TI Feeds provide live threat intelligence for real-time attack detection

ANY.RUN’s internal analysis found that up to 30% of unique malicious IOCs discovered in Interactive Sandbox sessions had already been observed by the company and were present in TI Feeds. When one of these indicators appears in customer telemetry, it can potentially be matched against existing intelligence before an analyst manually investigates the associated sample.

This creates a more efficient workflow: known malicious activity can be identified earlier, while sandbox analysis provides the behavioral evidence needed to investigate unfamiliar threats.

For internal SOCs, this can reduce time spent researching indicators that are already known to be malicious. For MSSPs, the same intelligence can help identify related activity across multiple customer environments. This is how the existing threat knowledge can be reused instead of reconstructed for every new alert.

Cut MTTR by 21 minutes and give your SOC more time to focus on critical threats.

Integrate TI Feeds

Threat Intelligence Provides Context Behind the Alert

An indicator becomes more useful when security teams can understand the activity surrounding it.

ANY.RUN’s Threat Intelligence Lookup (TI Lookup) allows analysts to investigate a suspicious domain, IP address, or URL and examine its history and associated activity. In a Skyw4lker-related investigation, this context can help determine whether an indicator is connected to the campaign, has appeared in other malicious activity, or requires further investigation.

In addition, ANY.RUN’s Threat Intelligence Reports (TI Reports) provide a broader perspective by connecting indicators with campaigns, infrastructure, techniques, and observed behavior. This can reveal relationships that are difficult to see from individual alerts, such as multiple incidents sharing the same infrastructure or a suspicious domain belonging to a wider phishing operation.

When it comes to organizations in U.S. healthcare, manufacturing, and technology, those connections can be especially important. A compromised Microsoft 365 account can expose sensitive communications, intellectual property, operational information, and regulated data, making early identification of related activity critical.

How to Make Each SOC and MSSP Investigation More Valuable

A successful investigation should improve an organization's ability to detect the next attack.

For an MSSP investigating a suspicious contract sent to one American manufacturing customer, indicators associated with Skyw4lker can be searched across other customer environments and incorporated into monitoring. The same approach works within an internal SOC environment, where an IOC found after one employee reports a phishing document can be compared against historical telemetry to identify other potentially affected users.

ANY.RUN supports these workflows through API/SDK, STIX/TAXII, SIEM, TIP, and XDR integrations, allowing intelligence from investigations to feed into existing detection and monitoring processes.

The result is broader protection from the same investigation: an incident affecting one user can generate intelligence that helps identify related activity across a SOC or MSSP's wider customer base.

Uncover up to 58% more threats and gain broader visibility into emerging attacks.

Boost Threat Detection

Conclusion

Skyw4lker shows why modern phishing defense requires visibility beyond the initial lure or login page. By combining interactive sandboxing, threat intelligence, and contextual investigation, security teams can move faster from suspicious artifact to actionable intelligence and broader detection.

For organizations in the U.S., that means faster investigations, less repetitive manual work, and a better ability to identify related activity before it becomes a larger incident. The goal is not only to understand one attack, but to turn every investigation into protection against the next one.

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/DK6ZIP7
via IFTTT

OpenNebula vs CloudStack: Which Virtualization Management Platform Should You Choose?

Apache CloudStack and OpenNebula are both well-known cloud and virtualisation management platforms for operating IT infrastructure and delivering Infrastructure as a Service (IaaS). Both support KVM virtualisation, multi-tenancy, isolated virtual networks and self-service provisioning. For infrastructure teams evaluating VMware alternatives following Broadcom’s licensing changes, both could be under consideration. Both sit in the same category: IaaS orchestrators, built to publish infrastructure to tenants who are not the operator. This article will give you a guided comparison between both and will help you make your choice if you are in evaluation.

By reading further you will get an understanding how each platform fits your infrastructure, your team and the services you need to deliver. Architecture, networking, automation, licensing and support all influence the work involved in deploying and operating a cloud. This CloudStack and OpenNebula comparison examines those differences and their practical implications for enterprises and service providers. Whether you are comparing both platforms for a new deployment or considering CloudStack as an OpenNebula alternative, it will help you identify what to assess before making a decision.

 

Comparing by Domain

Symbol	Description
●	Full, in the entry product with no extra purchase
$	Above baseline, needs a higher edition or a separate product
◐	Partial, there with a limitation that matters
○	Not covered.
ACS	Apache CloudStack
ONE	OpenNebula

Note: Assessed on Apache CloudStack 4.23.0.0 and OpenNebula 7.4 ‘Helix’ release notes.

 

Architecture

The clearest way to see the difference is to count what runs before you create your first virtual machine.

Capability	What it is	ACS	ONE
Control plane components	The services and appliances that must already be running before any tenant workload exists, and the memory and CPU they occupy at every site.	●	●
Control plane high availability model	Whether the management layer survives the loss of one of its own nodes without manual intervention, and by what mechanism.	●	●
Remote console architecture	How a tenant reaches the screen of a running instance, and whether that traffic passes through a dedicated appliance or the web layer.	●	●
Documented scale limits	Whether the vendor publishes a tested ceiling for hosts, instances and clusters per management domain.	◐	◐

A CloudStack Core Zone starts up with system virtual machines: a Secondary Storage VM for templates and snapshots, a Console Proxy VM for console sessions, and a Virtual Router per guest network for DHCP, DNS, NAT and firewalling. Each hypervisor host runs cloudstack-agent. An OpenNebula deployment starts with none of that: the oned daemon talks to hosts over SSH and drives libvirt directly, console access is proxied by FireEdge on the front end, and the only appliance it instantiates is a Virtual Router, and only when a network needs routing.

Neither approach is simply better. CloudStack’s system VMs isolate failure domains and let console and storage traffic scale independently of the management server, at the cost of components to patch and monitor. Edge Zones drop them entirely: a far-edge site runs a single KVM host with local storage, no secondary storage, no Secondary Storage VM and no Console Proxy VM. OpenNebula’s agentless model means fewer moving parts and a smaller footprint, at the cost of more load on the front end and a dependency on SSH reachability to every host.

The layering differs too. CloudStack models Region, Zone, Pod, Cluster and Host. OpenNebula has Cluster and Host, with Zone appearing only in federated deployments and no Pod at all.

Neither approach is simply better. CloudStack’s system VMs isolate failure domains and let console and storage traffic scale independently of the management server, at the cost of components to patch and monitor. Edge Zones drop them entirely: a far-edge site runs a single KVM host with local storage, no Secondary Storage, no Secondary Storage VM (SSVM) and no Console Proxy VM (CPVM). OpenNebula’s agentless model means fewer moving parts and a smaller footprint, at the cost of more load on the front end and a dependency on SSH reachability to every host.

The layering differs too. CloudStack models Region, Zone, Pod, Cluster and Host. OpenNebula has Cluster and Host, with Zone appearing only in federated deployments and no Pod at all.

 

Compute

 

Capability	What it is	ACS	ONE
Hypervisors supported as first-class drivers	Which hypervisors the platform manages directly, with full lifecycle control rather than one-way import.	●	◐
Bare metal provisioning through the platform	Whether physical machines can be provisioned as workloads through the platform, rather than only imaged as cluster nodes.	●	$
Containers managed alongside VMs	Whether Linux system containers run through the same objects, networks and storage as virtual machines.	◐	●
Live migration and live storage migration	Moving a running instance to another host, and moving its disks to other storage, without stopping it.	●	●
GPU passthrough and vGPU/MIG partitioning	Assigning a whole GPU to an instance, or partitioning one physical card so several instances share it.	◐	●
Importing / adopting pre-existing unmanaged VMs	Bringing a virtual machine already running outside the platform under its management, where it stands.	●	●
Instance sizing model	Whether instance shapes come from a catalogue the operator curates, or from values the tenant types in.	●	●

CloudStack manages KVM, VMware, XenServer and XCP-ng directly, with Hyper-V, Proxmox and MaaS arriving through the 4.23 extensions framework. OpenNebula 7.4 ships drivers for KVM and LXC; its vCenter driver was removed. Where CloudStack puts a service offering between the operator and the tenant, OpenNebula sets CPU and memory as template attributes, and has no disk offering at all.

Storage

Capability	What it is	ACS	ONE
Storage backends and protocols supported	Which storage systems and protocols can hold the disks of running instances.	●	●
Vendor array integration	Whether an array’s own features, including snapshots, replication and QoS, are driven by the platform or stop at the hypervisor.	●	$
Primary/secondary storage separation and cross-site snapshot copy	Whether running-disk storage is separated from image and snapshot storage, and whether a snapshot can be copied to another site.	●	●
Backup model	Whether backups capture only what changed since the last one, and whether a restore produces a running instance or a disk someone still has to assemble.	●	●
Tenant-facing object storage	Whether tenants get buckets they create and consume themselves, as distinct from the platform using object storage internally.	●	○
Disk QoS and whether it is delegable as a purchasable tier	Whether IOPS and throughput limits attach to something a tenant selects, rather than being set per machine by an administrator.	●	◐

CloudStack ships managed plugins for StorPool, Dell EMC PowerFlex, LINSTOR, NetApp ONTAP and SolidFire, Pure Storage FlashArray and HPE Primera. OpenNebula’s community edition covers Ceph, LVM, iSCSI and file datastores, with NetApp, PowerFlex and Pure Storage behind the subscription. Both throttle disk IOPS; the difference is that CloudStack puts the ceiling on an offering a tenant buys, while OpenNebula’s equivalent sits in the restricted-attribute list and stays an administrator’s control.

 

Networking

This is the domain where the two are furthest apart. Since 4.20 CloudStack can run isolated networks and VPCs in ROUTED mode, where the Virtual Router allocates an AS number and establishes BGP peering, giving tenants routable addressing instead of NAT. The trade is explicit: in ROUTED mode source NAT, static NAT, load balancing, port forwarding and VPN are unavailable. A CloudStack VNF template also declares the interfaces it expects and gets each wired to the right guest network on deployment, where OpenNebula’s marketplace VNF is an ordinary image with context variables. On hardware, CloudStack supports SR-IOV as PCI passthrough and OVS-DPDK; OpenNebula adds SR-IOV in switchdev mode and BlueField DPU offload.

Capability	What it is	ACS	ONE
Tenant network isolation	How one tenant’s network traffic is kept separate from another’s on shared physical infrastructure.	●	●
VPC / multi-tier networks with their own ACLs	Whether a tenant can build several connected networks under one routing domain, each carrying its own traffic rules.	●	○
Gateway services	Whether NAT, DHCP, DNS and firewalling are delivered to tenant networks, and by what.	●	●
Load balancing, including TLS/SSL offload	Whether the platform provides a load balancer, and whether TLS certificates terminate there instead of on every backend instance.	●	◐
VPN	Whether tenants get encrypted connectivity back to their own premises, and whether individual users can dial in.	●	○
Routed tenant networks / per-tenant BGP peering	Whether a tenant network can carry routable addresses advertised upstream, instead of sitting behind address translation.	●	○
IPv6 and dual-stack tenant networks	Whether tenant networks carry IPv6 alongside IPv4, and under what conditions.	●	●
SDN and external network provider integration	Whether an external network controller or physical device can be driven by the platform rather than configured beside it.	●	◐
Bandwidth QoS and whether it is delegable as a purchasable tier	Whether a bandwidth limit is part of something the tenant selects, rather than applied after the fact.	●	◐
Hardware-level networking	SR-IOV mode, DPU offload and user-space packet paths.	◐	●

 

 Multi-tenancy & Identity

 

Capability	What it is	ACS	ONE
Tenant hierarchy depth	How many levels of tenant the platform models, and whether a tenant can contain tenants of its own.	●	◐
Quota and resource limits	Whether consumption can be capped, and at which levels of the tenant structure.	●	●
Self-service portal for end tenants	Whether end tenants get an interface of their own, separate from the operator console.	●	●
Identity federation	Which external identity systems can authenticate users, and whether each tenant can point at its own.	●	◐
RBAC granularity and custom roles	How finely permissions divide, and whether roles beyond the built-in ones can be defined.	●	◐
API credential scoping, expiry, and two-factor authentication	What an API credential is allowed to do, for how long it stays valid, and what protects interactive login.	●	●

 

CloudStack has nested domains, accounts and projects; OpenNebula has flat groups, compensated by the Virtual Data Center, which binds clusters, datastores and networks to a group more cleanly than CloudStack’s explicit resource dedication. The identity models are inverted in an interesting way.

CloudStack scopes the provider to the tenant, so different tenants federate to different identity providers. OpenNebula keeps providers global and maps external groups onto its own, so membership flows from the provider rather than the tenant choosing one. Only CloudStack lets the tenant own that choice, and only CloudStack has HSM-backed key management.

 

Operations & Lifecycle

 

Capability	What it is	ACS	ONE
Upgrade model	Whether the management layer keeps serving requests while it is being upgraded.	●	◐
Maintenance mode and documented safe shutdown of the control plane	Whether there is a documented way to take the management layer out of service without risking in-flight work.	●	◐
Metrics and monitoring	What the platform exposes for monitoring, and whether dashboards ship with it.	●	●
Usage metering, accounting and showback/chargeback	Whether consumption is recorded per tenant in a form that billing can consume.	●	●
Workload placement and DRS-equivalent rebalancing	How instances are placed when created, and whether the platform rebalances the cluster afterwards.	●	●
Backup and disaster recovery of the control plane itself	Whether there is a documented way to back up and restore the management estate itself.	◐	●

Both rebalance, and the difference is what feeds it. CloudStack DRS computes cluster imbalance from the allocated metrics of the service offering; OneDRS optimises over observed usage with a linear programming solver. A cluster can look balanced by allocation while being badly balanced in practice. OpenNebula goes further with forecasting that nothing in CloudStack matches, predicting host and VM metrics five minutes and thirty days ahead and feeding those predictions back into OneDRS. On accounting, OpenNebula’s showback is built into oned, while CloudStack’s usage data comes from a separate Usage Server, which is more to run and is also what keeps that load off the management database at scale.

 

API and automation

Every CloudStack operation is an API command, the web console is just another client of that public API, and requests are signed with a key pair rather than carrying a session. The difference that shows up day to day is the job model: a long-running CloudStack operation returns a job ID the client polls, while OpenNebula returns no queryable identifier for most operations, so the client watches the object’s state through LCM_STATE. The first tells you whether your request succeeded; the second tells you what the object looks like now, which is a weaker thing to build a portal or a billing integration on.

Capability	What it is	ACS	ONE
Public API completeness	Whether the web interface calls the same API available to scripts, or a privileged internal one.	●	◐
API authentication model	How an API request proves who it is.	●	●
Asynchronous job model	Whether a long-running request returns an identifier the client can poll, or whether the client has to watch the object’s state instead.	●	◐
Infrastructure as code	Whether infrastructure-as-code tooling exists for the platform, and who maintains it.	●	●
Kubernetes	Whether the platform provisions Kubernetes clusters itself, and whether it plugs into the Cluster API standard.	●	●

 

Automation tooling is the one area where the two are close:

• Terraform: both projects maintain their own provider.
• Ansible: CloudStack through a community collection shipped in the Ansible distribution, OpenNebula through modules listed among its own integrations.
• Kubernetes Cluster API: CloudStack’s is maintained upstream under kubernetes-sigs, OpenNebula’s in its own organisation with a SUSE Ready certification for Rancher.
• CLI and reference: CloudStack has CloudMonkey for the command line, and the UI builds its own navigation from listApis, so what an operator sees is derived from the same API a script calls. OpenNebula has XML-RPC, a FireEdge REST layer and a gRPC API added in 7.2.

 

Extensibility

This is the area where the gap is widest, and it is the strongest argument in CloudStack’s favour today. This needs to be shorter and straight to the point. It is a word salad now. Please summarise in 2-3 paragraphs with some bullets.

Capability	What it is	ACS	ONE
Adding an unsupported hypervisor without modifying the platform’s source	Whether support for a runtime the platform has never heard of can be added without modifying its source.	●	●
Pluggable drivers for storage, network and authentication	Whether the storage, network and authentication subsystems accept drivers written outside the project.	●	●
Extensions as registered objects with their own RBAC and API surface	Whether an extension is a registered object with its own permissions and API surface, or a file placed on disk.	●	◐
Marketplace or curated template catalogue	Where the images and appliances tenants deploy come from, and who curates them.	●	●

 

Apache CloudStack: CloudStack 4.23 has an extensions framework with two extension types. An Orchestrator extension delegates VM lifecycle to an external system and is registered against a cluster. A NetworkOrchestrator extension handles guest network and VPC services and is registered against a physical network. An extension is an executable in any language: CloudStack passes it an action name and a JSON payload and reads JSON back. Proxmox, Hyper-V and MaaS ship as built-in examples. Administrators can define custom actions with typed parameters, validation and role-based access control, exposed through the UI and the API like any other operation.

The result is that a hypervisor CloudStack has never heard of can be added without touching its source. There is a working example of exactly that: an open source extension that manages Firecracker microVMs through CloudStack, with a host agent, pluggable storage backends, VLAN tagging over Linux bridges or OVS, mutual TLS and a VNC console bridge. Firecracker is a runtime CloudStack has no native support for, and adding it required no change to CloudStack itself.

OpenNebula: It is extensible too, but at a different layer. Every subsystem is a pluggable driver declared in oned.conf: VM_MAD for hypervisors, VN_MAD for networks, TM_MAD and DATASTORE_MAD for storage, AUTH_MAD for authentication, plus the market and hook drivers. The drivers themselves are scripts on disk that you can read, copy and replace. The scheduler is pluggable in the same way, and a 7.4 install ships three of them. For someone comfortable at that level, it is a clean and honest design.

What OpenNebula does not have is the management layer around it. There is no registered extension object, no UI for installing one, no custom actions surfaced through the API with their own permissions. Adding a driver means editing configuration on the front end and restarting the daemon. That is a different proposition from registering an extension and granting a role access to its actions.

Apache CloudStack Overview 

Strengths

• Manages vSphere, KVM, XenServer and XCP-ng together, with Hyper-V, Proxmox and bare metal through the Extensions Framework, so one control plane can span a VMware migration.
• Compute, disk and network offerings carry IOPS ceilings, bandwidth limits and GPU profiles, so an operator publishes a tier once and then delegates, meters and bills against it. Usage aggregation runs on its own server, which keeps that load off the management server and its database in large deployments.
• Multi-tier VPCs with ACLs, VPN, TLS-terminating load balancing, ROUTED networks with automatic BGP peering and a VNF template type are all platform objects a tenant can be given.
• Nested domains, accounts and projects model resellers under resellers; identity federates per domain; API keys are scoped and time-limited; key management integrates with an HSM.
• Maintenance mode, a documented safe shutdown and live patching of the Virtual Router make the control plane something you can operate under an SLA.
• One edition under Apache 2.0, with no capability reserved for a paid tier.

Weaknesses

• Slower to a first cloud than OpenNebula: hours for a test deployment, a project for a production Zone. That setup is the Zone and Pod structure that makes it operable at scale, and far simpler than OpenStack, but a small team feels it.
• System VMs and the hypervisor agent are extra components to patch, monitor and recover when they fail.
• Usage data comes from a separate Usage Server you deploy and maintain, so reaching chargeback takes more setup than OpenNebula’s built-in showback.
• The five-layer model is overhead for a single datacentre.
• DRS balances on allocated metrics rather than observed usage, and there is no forecasting.
• No gRPC API, and no VM memory encryption on the native KVM path. Neither is something an extension can add, because they are the API’s own protocol and the guest definition rather than orchestration.
• System containers and in-guest command execution are not shipped. Both are reachable through an Orchestrator extension and custom actions, but as something you build and maintain rather than a product feature.
• No NVIDIA NVLink or NVSwitch fabric management.

OpenNebula Overview

Strengths

• No agent on the hypervisor and no system VMs, so there is a smaller footprint, less to patch, and a front end with two nodes that comes up in an afternoon.
• The Virtual Data Center binds clusters, datastores and networks to a group cleanly, where CloudStack needs explicit resource dedication.
• Accounting and showback are built into oned, available out of the box.
• Forecasting of host and VM metrics over five-minute and thirty-day horizons, feeding OneDRS, which optimises on observed usage.
• Strong AI and GPU position: NVIDIA Fabric Manager for NVLink and NVSwitch, an integration with NVIDIA’s infrastructure controller, a Slurm appliance, and VM memory encryption.
• Ahead on hardware networking: SR-IOV in switchdev mode, BlueField DPUs and DPDK.
• LXC system containers, a gRPC API, in-guest command execution, automated hyperconverged Ceph, and OneFlow for multi-VM services with dependencies.

Weaknesses

• KVM and LXC only. The vCenter driver was removed and Firecracker support from 6.x is gone.
• Detects unmanaged guests but provides no import path in 7.4.
• No offering object between template and tenant. QoS controls sit in the restricted-attribute list, which makes them administrator settings rather than tenant-selectable tiers.
• No VPC object, no built-in VPN, no SSL offload, no platform-managed per-tenant BGP.
• Flat groups rather than nested domains, and no OAuth or OIDC driver.
• No tenant-facing object storage; S3 is a backup destination.
• NetApp, PowerFlex, Pure Storage and Veeam drivers are enterprise integrations outside the community edition.

 

CloudStack vs. OpenNebula: How to make your final choice?

Both platforms have clear strengths. OpenNebula offers a smaller management footprint, built-in showback, workload forecasting and specialist capabilities for AI infrastructure and hardware networking. CloudStack’s advantage is how it brings infrastructure management, tenant services and service delivery together.

For service providers and enterprises, that translates into several practical benefits:

• A staged path beyond VMware. Manage multiple hypervisors through one control plane while moving workloads at a pace that suits the organisation.
• Consistent services tenants can select. Publish compute, storage, network and GPU tiers with defined limits and permissions, supported by usage metering for billing.
• Integrated networking and tenant management. Deliver services such as VPCs, VPNs and routed networks, with nested tenant structures suited to customers, business units and resellers.
• Control across multiple sites. Use a common infrastructure hierarchy, API and operational model as the cloud expands.
• Access to the full platform. Apache 2.0 licensing makes commercial support a separate choice, with no paid edition required to unlock capabilities.

Choose CloudStack to build a cloud or manage a virtualization that grows with your business and keeps you in control.

The post OpenNebula vs CloudStack: Which Virtualization Management Platform Should You Choose? appeared first on ShapeBlue.

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