No Manners Here: The Ruthless Rise of The Gentlemen Ransomware

Executive Summary

The Gentlemen (aka Storm-2697) is a Ransomware-as-a-Service (RaaS) program active since at least July 2025. Public reporting indicates that the operators were likely active months earlier as an affiliate (known as ArmCorp) of Qilin RaaS, which Unit 42 tracks as Spikey Scorpius. Their ransomware variants are written in both C and Go programming languages, enabling the threat actors to spread their encryptors across different operating systems and virtual infrastructure. Figure 1 below illustrates the desktop wallpaper used by the ransomware after deployment.

Figure 1. Image of The Gentlemen ransomware’s wallpaper. Source: Krebs on Security.

Additional public reporting revealed that the operators (roughly 20 of them) likely morphed from a private entity into a RaaS model on or about September 2025. While traditional RaaS models typically offer affiliates a 70% to 80% cut of paid ransoms, The Gentlemen offer an unprecedented 90% payout.

Background

Unit 42 and other security researchers have observed The Gentlemen’s usage of a wide variety of initial access techniques similar to other RaaS operators since their inception, including the exploitation of vulnerabilities in edge devices (firewalls, VPNs), brute force attacks, obtaining leaked and/or stolen credentials and collaborating with initial access brokers (IABs).

More recently, researchers have identified The Gentlemen’s usage of a custom Go-based backdoor, an EDR killer framework dubbed “GentleKiller” and the suspected usage of an unspecified zero-day vulnerability exploit to amplify their defense evasion capabilities.

In May 2026, The Gentlemen announced a partnership with HasanBroker's BreachForums as a means to recruit affiliates, penetration testers and IABs. Figure 2 illustrates this announcement.

Figure 2. Image of partnership announcement between BreachForums and The Gentlemen. Source: Gurucul.

Additional information about The Gentlemen and their operational structure has emerged in recent months, following the leak of an internal database by an alleged insider in May 2026.

Data Leak Site Insights

One of the most alarming trends observed thus far in 2026 by Unit 42 and other security researchers is the sheer increase in volume of total victims claimed by The Gentlemen in comparison to 2025. Through July 7, one reputable source had counted a total of 580 victims claimed by The Gentlemen across 77 countries since their inception. Of those 580 victims, 103 operated within the manufacturing industry, a commonly targeted sector given the need for organizations to maintain operational uptime.

Figure 3 below represents the total number of victims claimed by The Gentlemen in 2025 compared to both Qilin and Akira, tracked by Unit 42 as Howling Scorpius, which led all RaaS programs in victims claimed last year.

Figure 3. Chart depicting total victims claimed by prominent RaaS programs in 2025. Source: Unit 42.

In comparison to the above statistics, Figure 4 below represents the total number of victims claimed by The Gentlemen thus far in 2026 (through July 3) compared to both Qilin and Akira.

Figure 4. Chart depicting total victims claimed by prominent RaaS programs in 2026. Source: Unit 42.

When comparing the last six months of 2025 to the first six months of 2026, the number of victims claimed by The Gentlemen increased by slightly more than 6x. What makes this even more concerning is that these threat actors were only active for the last four months of 2025.

Figure 5 below further illustrates the victims claimed by The Gentlemen per month since August 2025, one month prior to the official launch of their RaaS model. June 2026 represented their highest number of claimed victims to date with 117, just shy of a 4x increase from January 2026.

Figure 5. Chart depicting victims claimed by The Gentlemen per month since August 2025. Source: Ransomware.live.

Conclusion

While legacy big-game hunting RaaS programs like Qilin and Akira continue to drive high volumes of victims by sticking to their established playbooks, The Gentlemen has solidified itself as the second most active RaaS program of 2026 in terms of victims. The combination of a lucrative affiliate payout structure to recruit affiliates, alongside the use of custom tooling across different phases of their attack lifecycle, make The Gentlemen a formidable threat for enterprise organizations to reckon with in the near and mid term future.

Recommendations

Initial Access:

• Immediately scope for and patch the following vulnerabilities known to be exploited:
• Establish and maintain robust visibility into internet-facing systems and applications such as firewalls, VPNs and remote access gateways
• Audit for indicators of prior exploitation of edge devices and internet-facing RDP endpoints
• Establish strong security requirements for third-party dependencies and vendors, and monitor for breaches of any third-party tools or platforms

Execution:

• Create immediate, high-severity SIEM alerts for the creation, deletion or execution of any scheduled task matching the string gentlemen*

Privilege Escalation:

• Immediately scope for and patch the following vulnerabilities known to be exploited:
  • CVE-2025-7771 (ThrottleStop.sys driver)

Defense Impairment:

• Enable EDR Tamper Protection and monitor for the unexpected loading of unsigned or known vulnerable drivers
• Implement behavioral alerts for systems executing wevtutil to clear Security/System logs

Credential Access:

• Deploy phishing-resistance multi-factor authentication (MFA) on all systems
• Regularly audit and rotate credentials

Discovery:

• Monitor for internal usage of tools such as Advanced IP Scanner, which the threat actors frequently use for internal network reconnaissance and mapping

Lateral Movement:

• Enforce strict SMB signing, disable SMBv1 completely, and restrict lateral network movement between internal segments to contain the self-propagation mechanism
• Ensure SSH is turned off on ESXi hosts by default and only enabled temporarily for explicit maintenance windows
• Treat your virtualized environment as tier-0 infrastructure and restrict ESXi management interfaces to a dedicated, isolated management VLAN

Command and Control:

• Monitor for anomalous outbound traffic over non-standard ports or traffic matching known SystemBC communication signatures

Impact:

• Maintain and validate offline backup and recovery capabilities
• Implement behavioral alerts for systems using vssadmin and wmic to delete Volume Shadow Copies

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

URGENT - Progress Tells ShareFile Customers to Shut Down Storage Zone Controllers Over Security Threat

Progress Software has told ShareFile customers to shut down the Windows servers running their Storage Zone Controllers, confirming to The Hacker News that it is responding to a "credible external security threat."

The company has temporarily disabled access to the affected accounts, a step it says it took "out of an abundance of caution" while it works with internal and external security experts. It says it has no indication of unauthorized access to any ShareFile accounts or data, and that it notified customers after learning of the threat.

What Progress has not said is what the threat is, who is behind it, or whether any controller has been broken into.

The order became public when a customer posted the company's email to Reddit's r/sysadmin a few hours ago. Progress confirmed the disruption on its status page, listing Storage Zone Controller customers as "not operational" and the incident as under investigation as of a 12:12 p.m. EDT update.

Only the Storage Zone Controller is affected, not standard cloud-only ShareFile accounts. The controller is a server that a company runs itself, so files can stay on its own storage while it still uses ShareFile's cloud to share and manage them.

It usually sits at the network's edge, reachable from the internet. That exposure makes the controller both useful and a target. Ordering customers to take it fully offline, rather than just patch it, is a notable step.

What to do now

1. Follow the shutdown order first. Keep the affected controllers offline until Progress says what the threat is and when it is safe to restart.
2. Separately, confirm your version is current: 5.12.4 or later on the 5.x line, or a 6.x release. That closes the flaws fixed earlier this year, but Progress has not said it clears the current threat, so do not treat it as permission to restart.
3. If a controller is reachable from the internet, handle it as a possible incident. Preserve the logs and start your incident-response process, then check for unfamiliar .aspx files in the web folders and storage paths you did not set. A clean-looking server is not proof it is clean.

ShareFile has faced this before. In 2023, while the product still belonged to Citrix, attackers exploited an unauthenticated flaw in the same Storage Zones Controller (CVE-2023-24489).

CISA flagged it as actively exploited, and Citrix cut unpatched controllers off from the ShareFile cloud, the same access block Progress has now imposed.

Progress, which acquired ShareFile in 2024, had already weathered a mass file-transfer attack of its own: MOVEit, whose 2023 zero-day was exploited by the Clop group and hit more than 2,700 organizations.

The Storage Zones Controller also had two critical flaws that watchTowr disclosed in April and Progress patched in March, though the company has not connected the current threat to them, and neither has been reported as exploited.

The central question is still unanswered: Progress has pulled these systems offline and called in outside experts, but has not said what the threat is or when customers can safely bring them back online.

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

Six New U-Boot Flaws Could Let Malicious Images Crash Devices or Run Code at Boot

Researchers at firmware security firm Binarly have found six new flaws in U-Boot, the small program that starts up hardware as varied as home routers, smart cameras, and the management chips inside data-center servers.

Four of the bugs can crash a device. The other two could let an attacker who slips a malicious image in front of the bootloader run their own code, before the device has confirmed that the software is genuine.

That last part is the point. A bootloader runs before the operating system, so a flaw here can undermine everything that loads after it. All six bugs are reached while U-Boot is still reading an untrusted image, before it has checked the signature.

What Binarly found

U-Boot can bundle a kernel, device tree, ramdisk, and other boot components into one package, a FIT (Flattened Image Tree), and it checks that package's digital signature before handing over control.

Binarly went looking for weak spots in that check and found six. Most of the vulnerable code has been in U-Boot since v2013.07, Binarly says, across more than 50 stable releases, and it also lives in the many vendor firmwares built on top of U-Boot.

The bugs are tracked as Binarly advisories BRLY-2026-037 through BRLY-2026-042. No CVE identifiers have been assigned yet. They fall into two groups: two that could run code, and four that only crash.

The two are BRLY-2026-037 and BRLY-2026-038, and both trace to one unchecked value. U-Boot calls fdt_get_name, a lookup in the device-tree parsing library it borrows, and on a malformed image, that lookup returns a null pointer and a negative length. U-Boot uses both without checking either.

One bug follows the null pointer into a memory copy that, on devices where address zero is mapped, becomes a stack buffer overflow. The other feeds the negative length into pointer arithmetic that walks backward until it overwrites a saved return address. In the right memory layout, either one can hand control to code the attacker-supplied.

The other four only crash the bootloader. BRLY-2026-039 and BRLY-2026-041 read past the end of the image by trusting a size or offset that the attacker controls. BRLY-2026-040 dereferences a null pointer that an older image format hands back unchecked. BRLY-2026-042 exhausts the stack, set off by a deeply nested image that drives an early validation step to call itself until it runs out.

Binarly published a proof-of-concept image and reproduction steps for each flaw and demonstrated them against standard U-Boot builds. No exploitation in real attacks has been reported.

Of the six, the two memory-corruption bugs are the ones to prioritize: a crash can knock a device offline, but code execution at boot could subvert its entire chain of trust.

How bad it gets

In the worst case, recovering a device that will not boot means physical access and reflashing its memory chip with a clean image. Code execution is worse. Code that runs this early sits below the operating system, where ordinary security tools may not see it.

The catch for an attacker is delivery: these bugs only bite once a malicious image reaches the boot path, which usually takes physical access or a privileged foothold. That foothold is not always local.

In earlier work on Supermicro's server management controllers, the same Binarly researcher showed that an attacker with remote access to the management interface could abuse the device's own update process to flash a malicious image, without touching the hardware.

What to do

There is no stable release with the fix yet, so vendors and maintainers of U-Boot-based products should not wait: pull the upstream fixes now, following the commit links in each Binarly advisory, and track them by advisory ID, since no CVEs exist.

U-Boot merged the six patches in June, but the July release (v2026.07) had already frozen in April, so it shipped without them; the next release, v2026.10, is not due until October.

Everyone else runs a device someone else built on U-Boot. For them, the fix has to arrive as a firmware update from the product vendor. That is what to watch for.

This exact check has failed before. The same signature logic was hit months earlier by CVE-2026-33243, which U-Boot patched in April; the related barebox bootloader, which uses the same image tooling, was hit too.

In that bug, a property meant only to list what the signature covers was not itself signed, so a tampered image could swap in parts that were never verified. The helper behind the two worst bugs here, fdt_get_name, comes from libfdt, the flattened-device-tree library U-Boot shares with the Linux kernel, barebox, and others. The same unchecked-return mistake can surface anywhere that code is used.

LogoFAIL, which THN covered in 2023, was a set of image-parsing bugs in PC firmware that let attacker code run during boot, before Secure Boot could check anything, across nearly every major PC brand. The signature gets all the attention; the bugs keep landing in the plumbing that runs before it.

And as BootHole showed in 2020, when one bootloader flaw broke Secure Boot across the ecosystem, writing the patch is the easy part. The slow part is getting it onto the millions of devices running someone else's copy of U-Boot.

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

Building a workgroup cluster in Windows Server 2025

Windows Server 2025 lets you build a fully functional failover cluster without Active Directory. That’s a big deal for remote office/branch office (ROBO), edge, and infrastructure-light environments where standing up and maintaining AD introduces infrastructure, licensing, and operational overhead that’s hard to justify for a small two-node HA deployment.

For most of the history of Windows failover clustering, the first step was always the same: set up Active Directory, join your nodes to the domain, configure DNS and Kerberos, then start thinking about the cluster. That workflow still makes sense for large enterprise environments. But edge deployments, branch offices, and lightweight HA scenarios are now common in production, and spinning up a full AD infrastructure just to protect two Hyper-V hosts is overkill.

Windows Server 2025 supports workgroup clusters – you can build a failover cluster with no Active Directory at all. I’ve deployed several of these now, both in labs and in production ROBO scenarios. What follows is every step, with the common failure points called out along the way.

What is a Windows Server workgroup cluster?

A workgroup cluster is a Windows Failover Cluster whose nodes aren’t joined to Active Directory. Instead of domain services for authentication and identity management, the cluster relies on local accounts, certificates, and manually configured trust relationships between nodes. No Kerberos. No domain computer accounts.

What the cluster uses instead:

• Identical local administrator accounts on each node
• Certificate-based authentication for node-to-node trust
• DNS-based cluster access points instead of AD-backed cluster name objects

DNS in a workgroup cluster doesn’t need to come from Active Directory. Any DNS server the nodes can reach works – your existing infrastructure DNS, a router or firewall’s built-in DNS, or even static entries in each node’s hosts file for small deployments. The cluster just needs its name to resolve consistently to the cluster’s IP address from every node and client.

That sounds like a small difference from a traditional domain cluster, but it changes how you configure and maintain the cluster. There’s no automatic authentication between nodes. No centralized identity store. Every trust relationship has to be built explicitly using certificates and matching local credentials.

Here’s the thing: removing Active Directory doesn’t simplify the cluster’s requirements in absolute terms – it changes them. What you gain is independence from domain controllers, which is exactly what matters in edge and ROBO scenarios.

Domain cluster vs workgroup cluster

The table below summarizes the practical differences between a traditional domain-joined cluster and a workgroup cluster, so you can quickly see what changes when Active Directory is removed from the picture.

 

Feature	Domain Cluster	Workgroup Cluster
Authentication	Kerberos	NTLM / Certificates
Identity Management	Active Directory	Local Users
Deployment Complexity	Moderate	More Manual
DNS Registration	Automatic	Manual
Management Style	Centralized	Per-Node
AD Dependency	Required	None
Workload Support	Full	Limited
Best Fit	Enterprise	ROBO / Edge / Small HA

 

The decision comes down to infrastructure requirements. If Active Directory is already part of the environment and supports other business-critical services, a traditional domain cluster is the most straightforward option. In edge, ROBO, or isolated deployments where domain services provide little operational value, a workgroup cluster delivers the same high-availability capabilities with fewer dependencies.

When a workgroup cluster makes sense

Based on field experience, workgroup clusters are the right fit for ROBO environments where deploying domain controllers isn’t practical or cost-effective – think small retail locations, factory floors, or distributed sites with minimal IT presence. They’re also the right call for isolated environments that need HA but must remain air-gapped or separated from the main domain, small Hyper-V clusters protecting two or three VMs where AD overhead is disproportionate, and disaster recovery environments where you can’t guarantee domain controller availability during a failover event.

The core question is simple: does your HA environment actually need Active Directory, or has it just been assumed? In many edge and ROBO scenarios, the answer is no.

What you need before you start

Before running a single PowerShell command, make sure the following prerequisites are in place on all nodes. Skipping any of these is one of the most common reasons for cluster validation failures later. This checklist covers the baseline requirements for any workgroup cluster, with workgroup-specific adjustments highlighted where they apply. For the full official reference, see Microsoft’s Create a workgroup cluster documentation.

Shared storage is required for most clustered roles, but it doesn’t have to come from a dedicated hardware SAN. A software-defined storage solution – StarWind Virtual SAN is one option, covered later in this guide – can provide the required shared storage using the local disks in each node.

Hardware and OS requirements

• Windows Server 2025 installed on all nodes (Standard or Datacenter edition)
• At least 2 nodes; a quorum witness is strongly recommended for production
• Static IP addresses configured on all network adapters
• Proper hostname resolution between nodes (hosts file or DNS)
• Network connectivity tested on all paths, including the heartbeat network the nodes use for cluster communication and any dedicated storage network
• At least two network adapters per node: one for client/management traffic and one dedicated to cluster heartbeat and storage replication traffic. Additional NICs can separate heartbeat, storage, and client traffic further, but two is the practical minimum for production.

Lab environment for this guide

Throughout this walkthrough, the environment is configured as follows:

Node1 – 192.168.10.11 (Windows Server 2025)

Node2 – 192.168.10.12 (Windows Server 2025)

Cluster: WGCluster (DNS-based access point – the cluster name and IP are registered directly in DNS instead of an AD computer object)

Local admin account: clusteradmin

Workgroup name: WORKGROUP (default)

This lab uses StarWind Virtual SAN to provide the shared storage required by the cluster. Both nodes have identical local disks available for replication. Step 8 covers the storage setup in detail.

The diagram below shows the overall architecture. For readability, it shows a single NIC per node, but in production you should plan for at least two network adapters per node as described above.

Note: BackupUser is shown as an example of an additional local account you might create for backup software requiring local, non-administrative access. It’s not created as part of this walkthrough and can be omitted if you don’t need it.

 

Figure 1. High-level architecture of a two-node Windows Server 2025 workgroup cluster using certificate-based authentication and StarWind VSAN for synchronously replicated shared storage.

Step 1: Configure matching local administrator accounts

This is the basis of authentication between cluster nodes. Without Active Directory, there’s no centralized mechanism for managing computer and user accounts, so each node must have identical local credentials. The username, password, and group membership have to match exactly.

Run these commands on every node that will be part of the cluster:

# Create the cluster admin account

net user clusteradmin StrongPassword123! /add

# Add to the local Administrators group

net localgroup administrators clusteradmin /add

If the passwords don’t match exactly between nodes, authentication fails silently during cluster validation. This is one of the most frustrating debugging scenarios in the workgroup cluster setup – double-check this before moving on.

Verify the account exists and has the correct group membership:

# Confirm account exists

net user clusteradmin

# Confirm administrator group membership

net localgroup administrators

Step 2: Configure WinRM and Trusted Hosts

Windows Remote Management (WinRM) enables remote administration and PowerShell remoting between cluster nodes. By default, it accepts connections only from trusted sources. Since workgroup clusters do not rely on Active Directory, each node must be configured manually to trust the other cluster members.

Enable PowerShell remoting on all nodes:

# Enable WinRM and PS remoting

Enable-PSRemoting -Force

Configure TrustedHosts. This setting defines which remote hosts can establish WinRM connections without Active Directory trust:

# Add both nodes to TrustedHosts

Set-Item WSMan:\localhost\Client\TrustedHosts -Value "Node1,Node2"

# Verify the setting was applied

Get-Item WSMan:\localhost\Client\TrustedHosts

Do this on every node. If you skip one, that node won’t be able to initiate remote WinRM connections to its peers, and cluster creation will fail.

 

Figure 2. Verifying the TrustedHosts configuration for WinRM.

Step 3: Install the required Windows features

The Failover Clustering feature isn’t installed by default in Windows Server 2025. For Hyper-V deployments, install both Failover Clustering and the Hyper-V role, including their management tools, on every cluster node:

# Install Failover Clustering and Hyper-V with management tools

Install-WindowsFeature Failover-Clustering, Hyper-V -IncludeManagementTools

# Reboot after installation completes

Restart-Computer -Force

Restart each node after installation. Hyper-V requires a reboot to activate the hypervisor, and cluster validation can report misleading errors if the restart is still pending.

The Failover Clustering feature is required on all cluster nodes. Install the Hyper-V role only if the cluster will host VMs or provide Hyper-V high availability.

Step 4: Create and exchange self-signed certificates

This is the step that catches most people off guard when they first build a workgroup cluster. In a domain environment, Kerberos handles all node-to-node authentication automatically. In a workgroup cluster, you have to build that trust manually using certificates.

Each node generates its own certificate and imports the other node’s certificate into its Trusted Root store. This creates mutual trust between the nodes without requiring an external certificate authority.

Figure 3. Certificate exchange process between workgroup cluster nodes.

Generate certificates on each node. Run this on Node1:

# Generate a self-signed certificate for Node1

New-SelfSignedCertificate `

-DnsName "Node1" `

-CertStoreLocation "Cert:\LocalMachine\My" `

-KeyLength 2048 `

-FriendlyName "WGClusterCert-Node1"

Run this on Node2:

# Generate a self-signed certificate for Node2

New-SelfSignedCertificate `

-DnsName "Node2" `

-CertStoreLocation "Cert:\LocalMachine\My" `

-KeyLength 2048 `

-FriendlyName "WGClusterCert-Node2"

Export the certificates:

$cert = Get-ChildItem -Path cert:\LocalMachine\My | Where-Object {$_.Subject -like "Node*"}

Export-PfxCertificate -Cert $cert -FilePath "C:\ClusterCert.pfx" -Password (ConvertTo-SecureString "StrongPassword123" -AsPlainText -Force)

Import each node’s certificate on the other node:

# On Node2: import Node1's certificate into Trusted Root
Import-PfxCertificate -FilePath "C:\ClusterCert.pfx" -CertStoreLocation "cert:\LocalMachine\Root" -Password (ConvertTo-SecureString "StrongPassword123" -AsPlainText -Force)

# On Node1: import Node2's certificate into Trusted Root
Import-PfxCertificate -FilePath "C:\ClusterCert.pfx" -CertStoreLocation "cert:\LocalMachine\Root" -Password (ConvertTo-SecureString "StrongPassword123" -AsPlainText -Force)

Step 5: Configure the WinRM HTTPS Listener

Once the certificates are in place, configure WinRM to use HTTPS for secure communication. This uses the certificate you generated in the previous step. You will need the certificate thumbprint, which you can get from the certificate store.

# Get your certificate thumbprint

Get-ChildItem Cert:\LocalMachine\My | Where-Object {$_.FriendlyName -like " ClusterCert *"}

# Create the HTTPS WinRM listener (replace CERT_THUMBPRINT with actual value)

winrm create winrm/config/Listener?Address=*+Transport=HTTPS `

"@{Hostname='Node1';CertificateThumbprint='CERT_THUMBPRINT'}"

# Verify the listener was created

winrm enumerate winrm/config/listener

Run the equivalent commands on Node2, substituting Node2′s hostname and thumbprint. When done, verify you can reach each node over HTTPS by testing the WinRM connection from the opposite node.

Troubleshooting tip: If the HTTPS listener fails to create, the most common cause is that the certificate Subject name does not match the hostname. The -DnsName value used in Step 4 must exactly match the node’s actual hostname.

Step 6: Validate the cluster before creating it

Don’t skip this. Cluster validation is especially important for workgroup clusters because authentication issues surface here first, not after creation. Many administrators treat validation as a formality – for domain clusters that’s occasionally forgivable. For workgroup clusters, it isn’t.

# Run full cluster validation against both nodes

Test-Cluster -Node Node1,Node2

# Or run validation with a specific report path

Test-Cluster -Node Node1,Node2 -ReportName C:\ClusterValidation\Report

The validation report covers network configuration and connectivity between nodes, storage visibility and access, system configuration consistency, and failover clustering prerequisites.

You don’t need to pass every test to create a workgroup cluster. Storage tests may show warnings if you haven’t configured shared storage yet. What matters is that the network and system tests complete successfully.

Figure 4. Results of the Test-Cluster validation wizard showing successful validation of the cluster configuration before cluster creation.

 

Step 7: Create the workgroup cluster

With validation complete, you’re ready to create the cluster. The critical difference from a domain cluster is the -AdministrativeAccessPoint parameter. For workgroup clusters, this must be set to DNS rather than the default, which creates an AD computer object.

# Create the workgroup cluster with DNS access point

New-Cluster `

-Name WGCluster `

-Node Node1,Node2 `

-AdministrativeAccessPoint DNS

# If you have a specific IP for the cluster, add it:

New-Cluster `

-Name WGCluster `

-Node Node1,Node2 `

-StaticAddress 192.168.10.20 `

-AdministrativeAccessPoint DNS

A DNS access point means the cluster name is registered in DNS like any other hostname, instead of being backed by an Active Directory computer object. The cluster can function without a domain controller.

Once the cluster is created, Server Manager gives you a quick health check across both nodes, confirming that clustering, StarWind Virtual SAN, and networking are all reporting normally:

 

Figure 5. Server Manager displaying the completed two-node workgroup cluster with both servers, cluster services, and StarWind Virtual SAN configured and operating normally.

 

Step 8: Configure storage with StarWind Virtual SAN

Here’s where many workgroup cluster guides stop: they assume you already have shared storage, or they wave their hands and say “use a SAN or NAS.” That’s not helpful for ROBO and edge scenarios, which are precisely the environments where workgroup clusters make the most sense.

The whole point of a workgroup cluster is to reduce infrastructure dependencies. Removing the AD dependency and then replacing it with a requirement for a dedicated SAN, Fibre Channel infrastructure, or expensive external arrays doesn’t make sense.

This is where software-defined storage fits the workgroup cluster story. StarWind Virtual SAN is one option that works well here. Instead of relying on an external storage array, it uses the local storage in each cluster node and synchronously replicates data between them to provide the shared storage required for failover clustering.

What StarWind Virtual SAN does?

StarWind VSAN runs as a service on each cluster node. It takes local storage – HDD, SSD, or NVMe – on each node, creates virtual shared disks backed by that local storage, replicates writes synchronously between nodes so both copies stay identical, and presents those replicated virtual disks to the cluster nodes as Cluster Shared Volumes.

The result is highly available shared storage without dedicated external hardware. If one node fails, the other continues operating with no data loss because it already has a full, up-to-date copy of everything. For a full walkthrough of configuring StarWind Virtual SAN in a two-node, compute-and-storage-separated Hyper-V scenario, see StarWind’s official technical guide.

Why is SDS important for workgroup clusters?

Using SDS with a workgroup cluster eliminates multiple infrastructure dependencies at once: no AD, no SAN hardware, no Fibre Channel, no dedicated iSCSI target hardware, no external NAS. Two standard servers with local disks, StarWind VSAN installed on each, and the workgroup cluster configuration from this guide are all you need for a production HA environment. Other SDS solutions like Storage Spaces Direct can fill this role too – StarWind is what this guide covers.

 

Figure 6. Failover Cluster Manager showing the replicated StarWind Virtual SAN disks added to the cluster, including Cluster Shared Volumes (CSVs) and the quorum witness disk.

 

Configuring the quorum witness

A two-node cluster should have a quorum witness to provide an additional vote during node or network failures. Failover Clustering uses a majority-based quorum model, so a two-node cluster without a witness has only two votes. If communication between the nodes is lost, neither node can maintain a majority, and clustered resources go offline.

Workgroup clusters support three quorum witness types. A file share witness uses a shared folder on a separate server or NAS device – it’s the simplest option when you already have a third machine on the network. A cloud witness uses Azure Blob Storage and works well when nodes have Internet access but there’s no convenient third site for a file share. A disk witness is a small shared disk dedicated to quorum – StarWind Virtual SAN can provide this disk in the same way it provides the cluster’s main shared storage.

Configure a File Share Witness:

# Configure a File Share Witness
Set-ClusterQuorum -FileShareWitness \\witnessserver\ClusterWitness

Configure a Cloud Witness (Azure):

# Configure a Cloud Witness (Azure)
Set-ClusterQuorum -CloudWitness `
-AccountName "yourstorageaccount" `
-AccessKey "youraccesskey"

For a disk witness with StarWind, the linked StarWind guide walks through selecting the quorum witness option during setup.

Step 9: Post-creation verification

Once the cluster is running and storage has been configured, perform a set of checks to confirm everything is healthy before you start deploying workloads.

Check cluster health:

# Check overall cluster status

Get-Cluster

# Check all cluster nodes

Get-ClusterNode

# Check all cluster resources

Get-ClusterResource

# Check network adapters used by the cluster

Get-ClusterNetwork

Verify storage is online:

# List Cluster Shared Volumes

Get-ClusterSharedVolume

# Check CSV health and state

Get-ClusterSharedVolume | Select-Object Name, State, Node

Test a manual failover.

Always test failover before putting the cluster into production. Move the cluster group from one node to the other and verify the workload remains online throughout the operation:

# Move all cluster groups from Node1 to Node2

Move-ClusterGroup -Node Node2

 

# Move a specific role

Move-ClusterGroup -Name “Virtual Machine Role Name” -Node Node2

Common challenges and how to handle them

Being honest about the hard parts is more useful than pretending deployment always goes smoothly. Here are the issues that come up most often.

Certificate mismatches

Symptom: Cluster validation succeeds, but nodes can’t communicate properly after creation.

Cause: The -DnsName value used when creating the certificate doesn’t exactly match the node hostname, or the certificate wasn’t imported into the correct store. It must go into Trusted Root, not Personal.

Fix: Use certlm.msc to verify the certificate is in the Trusted Root Certification Authorities store, and confirm the Subject name matches the node hostname.

Get-ChildItem Cert:\LocalMachine\Root

Remote management issues

Symptom: You can’t connect to nodes remotely using Failover Cluster Manager or Enter-PSSession.

Cause: TrustedHosts hasn’t been configured correctly, or the clusteradmin credentials were entered incorrectly.

Fix: Verify that TrustedHosts contains the names of all cluster nodes. When connecting remotely, always specify credentials explicitly using -Credential (Get-Credential).

Authentication failures during cluster creation

Symptom: New-Cluster fails with “Access Denied” errors.

Cause: Password mismatch between the clusteradmin accounts on different nodes, or the account isn’t in the local Administrators group on all nodes.

Fix: Reset the password on all nodes to the same value simultaneously, then retest.

Workload limitations

Some workloads don’t support workgroup clusters. SQL Server Availability Groups, for example, require domain accounts and Kerberos by default, though workarounds exist. Any clustered role that depends on Active Directory integration won’t function in a workgroup cluster.

For Hyper-V VMs and Scale-Out File Server workloads, workgroup clusters work well. Verify your specific workload requirements before committing to this architecture.

For the official reference on workgroup cluster requirements and supported scenarios, see Microsoft’s Create a workgroup cluster documentation.

Final thoughts

Workgroup clusters in Windows Server 2025 are genuinely production-ready for the right scenarios. I’ve deployed them in branch offices where spinning up domain controllers would have been operationally impractical, and in edge environments where the entire point was minimizing footprint.

They’re not easier than domain clusters in absolute terms. You trade the complexity of maintaining Active Directory for the complexity of managing certificates and local accounts manually. What you gain is independence from domain controllers – no risk of cluster failure because a DC was unreachable.

Combined with StarWind Virtual SAN or another SDS solution, a workgroup cluster can deliver both compute and storage high availability without dedicated storage hardware or domain services. As outlined in Step 8, this architecture eliminates AD, SAN hardware, Fibre Channel, iSCSI, and NAS dependencies. Two standard servers with local storage get you a full HA environment. That’s a practical fit for ROBO and edge deployments where every piece of infrastructure you don’t have to maintain is a win.

If you’re evaluating this architecture, the StarWind Virtual SAN free version works for lab validation. You can verify the full workgroup cluster plus replicated storage setup before deploying to production.

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

The Good, the Bad and the Ugly in Cybersecurity – Week 28

The Good | Authorities Apprehend Pro-Russian Hacktivist & Dismantle Global Fraud Networks

Spanish authorities, acting on intelligence provided by the FBI, have apprehended a suspected core member of the pro-Russian hacktivist syndicates CyberArmy of Russia Reborn (CARR) and Z-Pentest.

While masquerading as ideologically motivated collectives, these groups have actively executed disruptive cyberattacks against critical infrastructure, including food processing and water facilities across the United States and Europe. Investigators allege the arrested individual, residing in Palencia, provided extensive operational and logistical support to a Ukrainian hacker working for CARR, even attempting to facilitate their escape to Russia.

The individual is also suspected of coordinating cyber operations for the NoName057(16) group using encrypted messaging platforms. In a March 2026 raid, law enforcement officers seized multiple computers and successfully froze cryptocurrency wallets utilized to launder illicit proceeds generated from stolen data sales. The suspect currently faces ongoing criminal investigations for alleged collaboration with a recognized terrorist organization and severe computer damage.

In a massive global crackdown on social engineering and financial fraud, international law enforcement agencies have arrested 5,811 suspects and seized approximately $293 million in illicit assets. Codenamed “Operation First Light 2026”, the coordinated initiative spanned 97 countries and specifically targeted business email compromise (BEC), investment scams, and money laundering syndicates operating between January and April. Interpol actively coordinated the extensive joint action, collaborating directly with regional policing bodies like ASEANAPOL, GCCPOL, and Europol to swiftly block over 31,000 fraudulent bank accounts and virtual wallets.

Eswatini police seized electronic devices, foreign currency, and realistic replicas of Brazilian police uniforms, signage, and equipment (Source: Interpol)

Investigators identified more than 142,000 victims worldwide and pinpointed an additional 15,600 suspects for future prosecution. This success builds upon recent international efforts, including Operation Synergia II, to dismantle the sprawling infrastructure supporting transnational cybercrime. Officials emphasize that robust, cross-border law enforcement cooperation remains essential to combat the escalating threat of organized cyber-enabled financial crimes globally.

The Bad | Threat Actors Deploy Forg365 PhaaS to Hijack Microsoft Accounts

Cyber researchers have identified a new phishing-as-a-service (PhaaS) operation dubbed Forg365, which targets Microsoft 365 enterprise accounts. Blending adversary-in-the-middle (AiTM) techniques with device-code phishing, the platform provides an integrated dashboard to manage post-compromise activities.

Forg365 works by incorporating AI to assist in generating customized phishing lures. By integrating AI directly into the control panel, Forg365 developers significantly lowered the financial cost needed to launch targeted campaigns. To remain undetected, its operators route messages through legitimate Amazon SES infrastructure while hosting their landing pages on Cloudflare.

The Forg365 panel (Source: ZeroBec)

The operation leverages the OAuth 2.0 device code authentication flow, originally designed for input-constrained devices. Attackers present victims with a deceptive verification page, tricking them into authorizing an attacker-controlled gadget rather than stealing their password directly.

Once initial access is achieved, the platform ensures persistence through a specialized browser extension called ForgCookie. Compatible with Microsoft Edge, Google Chrome, and Brave, this extension operates silently to request account data, clear session cookies, and trigger a hidden OAuth flow to capture fresh tokens. Doing so grants attackers continuous access to the victim’s Microsoft services without requiring them to ever re-authenticate.

To protect its administration panel from being accessed by security defenders, Forg365 integrates robust anti-analysis features. The platform utilizes debugger traps, polymorphic code, and dynamic sandbox checks to evade detection, redirecting connections to innocuous websites whenever a VPN is detected.

Administrators can defend against these hijacking techniques by monitoring Microsoft Entra logs for unexpected device-code authentication events. Organizations can also restrict or entirely disable device-code flows unless absolutely necessary. In the event of a suspected compromise, security teams should revoke all OAuth grants and refresh session tokens to sever access.

The Ugly | Rival Espionage Actors Breach & Spy On Pakistani Law Enforcement Networks

Between February 2024 and April 2026, suspected state-sponsored threat actors based in China and India separately converged on several Pakistani law enforcement organizations in unrelated cyberespionage campaigns.

According to SentinelLABS, operators heavily targeted the Balochistan Police, compromising critical network appliances and web servers. By infiltrating these critical systems, both nations actively sought independent visibility into Pakistan’s internal security posture and ongoing counter-militancy operations.

The China-nexus intrusions, leveraging PlugX, ShadowPad, and Cobalt Strike malware, were likely driven by Beijing’s concerns over the safety of Chinese nationals working on regional infrastructure projects within the China-Pakistan Economic Corridor (CPEC). Ongoing terrorist attacks have left the Chinese government dissatisfied with Pakistani protection and data from Balochistan Police would give the PRC direct insights.

Conversely, the India-nexus activity utilized Remcos backdoors to gather intelligence on the restive Balochistan province, a recurring flashpoint in the adversarial relationship between the two countries. Control over Balochistan Police networks means having invaluable visibility on how Pakistan manages their security posture as well as persistent access to civilian data.

Timeline of C2 traffic to Pakistani law enforcement organizations (Source: SentinelLABS)

One China-aligned threat actor specifically compromised the Balochistan Police Force’s Complaint Management System (CMS), a web application that actively serves both law enforcement personnel and Pakistani civilian users. The attackers uploaded custom malware implants disguised as routine portal updates, effectively weaponizing the digitalization of public policing services.

One payload masqueraded as a legitimate component of endpoint security software to evade initial detection and deploy an AsyncRAT client in order to establish persistent footholds into internal police networks while simultaneously surveilling citizens utilizing the platform.

This multi-actor convergence highlights how modernized policing infrastructure can serve as a high-value intelligence target for rival nations seeking comprehensive regional data.

from SentinelOne https://ift.tt/XPjGWK9
via IFTTT

Securing our future: July 2026 progress report on Microsoft’s Secure Future Initiative

Security is never finished. That conviction is where the Secure Future Initiative (SFI) started two years ago and continues to guide us today. AI is reshaping cybersecurity. Cyberattackers can discover vulnerabilities, chain attack paths, and scale exploitation faster than manual approaches allow. Defenders can use the same advances to identify risk, strengthen protections, and accelerate response. As the threat landscape evolves, security must evolve with it.

This latest SFI progress report shows how Microsoft is adapting to that reality: strengthening security foundations for an AI-accelerated cyberthreat landscape, applying AI to improve security outcomes at scale, and preparing for future challenges such as scalable quantum computing.

Read the full July 2026 SFI progress report

This report organizes our progress into three outcome-driven themes—secure foundations, proactive defense, and future-ready security—and shares lessons learned, practical guidance, and deeper insights across the culture, governance, principles, and engineering pillars that underpin security at Microsoft.

Secure foundations

The most consequential security failures rarely come from a single missing control. They come from environments where identity gaps, unmanaged assets, and inconsistent configurations sit side by side, creating composite attack paths that determined threat actors can chain together. SFI addresses this systemically, strengthening security across our environment. The results show the progress:

• Phishing-resistant multifactor authentication now protects 99.97% of user/device pairs at Microsoft.
• More than 732,000 resources have had public access revoked, with network isolation scaling across 1 million resources.
• 1.4 million unused apps were decommissioned and cross-boundary credential isolation reached 98.7%.
• Engineering defaults now prevent 83% of pipelines from accessing unapproved package endpoints.

These controls form reinforcing layers: identity feeds access governance, access governance feeds segmentation, segmentation contains blast radius, and engineering defaults reduce what enters production in the first place. One of the lessons we have learned is that foundations are durable only when they’re continuously validated, not periodically audited.

Proactive defense

Secure foundations reduce the attack surface. Proactive defense builds on that foundation to find and fix weaknesses quickly. Traditional practices like code review and penetration testing remain essential. The difference now is that frontier AI can discover vulnerabilities and chain exploit paths faster than manual review can keep up. That’s a threat and, when used well, an advantage. We’ve leaned into that advantage to find real risk earlier and close it before a cyberattacker can act.

• We built a multi-agent AI system that delivers proactive assessment of a cloud service’s source code, identity configurations, network topology, and runtime state to surface composite vulnerabilities that a single-layer review could not catch. More than 90% of findings confirmed by our security engineers, enabling proactive actions to improve security posture.
• This system builds on other tools in our security portfolio—such as the Microsoft Security multi-model agentic scanning system (codename MDASH), which scans source code to identify, validate, and prioritize vulnerabilities at scale—and adds configuration, identity, network, and runtime context to comprehensively assess the service.
• More than 100 new detections were added this year (more than 350 total), shifting from signature-based to behavior- and baseline-driven detection.
• More than 550,000 critical and high-risk open-source vulnerabilities were remediated, with about 3 million container vulnerabilities patched per month through automation.

Future-ready security

Some risks have not fully arrived yet, but waiting for them is not an option. The most urgent example is the transition to post-quantum cryptography. The threat is already here in the form of “harvest now, decrypt later”: data encrypted today could be captured and decrypted once quantum capability matures.

• We are accelerating the Microsoft Quantum Safe Program (QSP) timeline, with the goal of transitioning to post-quantum cryptography (PQC) in critical products and services by 2029.          
• PQC is now an SFI-measured engineering requirement, with workstreams advancing across network traffic, data-at-rest protection, and trust chain modernization.
• Quantum-safe algorithms (ML-KEM, ML-DSA) are available today across major platforms.
• Read more in the recent blog: Accelerating quantum-safe readiness.

Governance, culture, and principles

Foundational progress like this is only possible because of the people committed to making it possible. Security is a core responsibility for every employee at Microsoft: mandatory Trust Code training was completed by more than 99% of full-time employees. Governance is what makes it scale, with accountability driven through our Deputy Chief Information Security Officer (CISO) structure and a centralized risk register. And our principles—secure by design, secure by default, secure in operations—are what turn intent into product, like Microsoft 365 Baseline Security Mode. Tools alone don’t create durable security; culture, accountability, and secure defaults do.

What you can do today

Throughout the report, we share actionable guidance for organizations at any stage of their security journey. A few starting points:

• Enforce phishing-resistant multifactor authentication and eliminate legacy authentication protocols.
• Inventory every tenant and classify it. Apply secure-by-default provisioning with drift detection.
• Evaluate how identity, code, configuration, and network relationships interact in production. Prioritize composite attack paths over isolated findings.
• Inventory your cryptographic dependencies now and establish transition plans for post-quantum readiness.
• Enable Baseline Security Mode in Microsoft 365 for secure-by-default configuration at no additional cost.

Read the full SFI report, including detailed pillar-level progress and additional customer guidance.

Each hardening action changes the cyberattacker’s approach. The compounding effect of SFI is that attackers face a shrinking set of viable paths, while defenders gain better telemetry, stronger defaults, and sharper prioritization for the paths that remain.

Security is a team sport. We are grateful for the partnership of our customers, security researchers, and the broader industry as we work together to make the world a safer place for all.

Read the July 2026 SFI progress report

Learn more

• Defending the cloud at AI speed.
• Beyond the benchmark: Advancing security at AI speed.

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 Securing our future: July 2026 progress report on Microsoft’s Secure Future Initiative appeared first on Microsoft Security Blog.

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

Ransomware Negotiator Gets 70 Months in Prison for Aiding BlackCat Attacks

A 41-year-old former ransomware negotiator has been sentenced to nearly six years (i.e., 70 months) in prison in the U.S. for their role in conspiring with the now-defunct BlackCat ransomware operators to extort multiple victims and working with two other cybersecurity professionals to target additional victims in 2023.

In a sentencing memorandum, federal prosecutors described Martino as a "double agent working to maximize the harm to his clients and the financial gain to cybercriminals who paid him a part of the ransom."

Angelo Martino, 41, of Land O'Lakes, Florida, pleaded guilty to one-count information charging him with conspiring to interfere with interstate commerce through extortion back in April. The defendant worked as a negotiator on behalf of five different ransomware victims, while providing BlackCat attackers with confidential information regarding their negotiating position and strategy without their knowledge or permission.

This information included details about the victims' insurance policy limits and internal negotiation positions, allowing the operators to maximize the ransom amounts they were required to pay.

"Angelo Martino's victims shared heartbreaking accounts of how their businesses were nearly destroyed, while the people they hired to help them instead betrayed them to ransomware gangs," said Assistant Attorney General A. Tysen Duva of the U.S. Justice Department's Criminal Division.

In addition, Martino was also accused of colluding with Ryan Goldberg, 41, of Georgia, and Kevin Martin, 36, of Texas, to successfully deploy BlackCat ransomware between April 2023 and November 2023 against multiple victims located throughout the U.S. Martino and Martin were employed at DigitalMint, while Goldberg was working as an incident response manager for cybersecurity company Sygnia.

Both Goldberg and Martin were sentenced to four years each in prison back in May 2026 for carrying out the attacks after pleading guilty to their crimes last December.

"He was hired to help victims in a moment of crisis," said U.S. Attorney Jason A. Reding Quiñones for the Southern District of Florida.

"Instead, Martino betrayed them, fed their confidential negotiating positions to ransomware criminals, and helped squeeze them for more money. This case sends a clear message: we will pursue the hackers who deploy ransomware, the insiders who enable them, and the money they steal from American victims."

The Justice Department said law enforcement has seized $10 million of assets from Martino to date, including digital currency, vehicles, a food truck, and a luxury fishing boat that he purchased from the illicit proceeds. Martino is expected to appear in court on September 17, 2026, to determine the exact amount of restitution to be ordered against him.

"Angelo Martino sold out the very victims he was hired to represent, handing their confidential negotiating positions to BlackCat actors to drive up ransoms and enrich himself," said Assistant Director Brett Leatherman of the FBI Cyber Division.

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

WolfSSL, GeoVision, VTK vulnerabilities

Cisco Talos’ Vulnerability Discovery & Research team recently disclosed three vulnerabilities in WolfSSF, fourteen in GeoVision, and one vulnerability in VTK-DICOM.

The vulnerabilities mentioned in this blog post have been patched by their respective vendors, in adherence to Cisco’s third-party vulnerability disclosure policy. 

For Snort coverage that can detect the exploitation of these vulnerabilities, download the latest rule sets from Snort.org, and our latest Vulnerability Advisories are always posted on Talos Intelligence’s website.

WolfSSL vulnerabilities

Discovered by Ankur Tyagi of Cisco Talos.

WolfSSL aims to provide "lightweight and embedded security solutions" for both individual and business needs. WolfSSL is an open-source product to provide secure data transfer.

Talos discovered two improper input validation vulnerabilities (TALOS-2026-2409 (CVE-2026-28739) and TALOS-2026-2410 (CVE-2026-25106)) and one integer underflow vulnerability (TALOS-2026-2408 (CVE-2026-33091)) in WolfSSL.

GeoVision vulnerabilities

Discovered by Philippe Laulheret of Cisco Talos.

GeoVision specializes in security technologies, including cameras and monitoring solutions, access control, and machine-identification.

Talos released 14 advisories for GeoVision vulnerabilities, covering 37 CVEs:

• TALOS-2026-2411 (CVE-2026-12488) memory corruption vulnerabilities
• TALOS-2026-2379 (CVE-2026-12486, CVE-2026-12849, CVE-2026-12850, CVE-2026-12851) OS command injection vulnerabilities
• TALOS-2026-2377 (CVE-2026-12485, CVE-2026-12846, CVE-2026-12847, CVE-2026-12848) buffer overflow vulnerabilities
• TALOS-2026-2369 (CVE-2026-42370) stack overflow vulnerability
• TALOS-2026-2333 (CVE-2026-7372, CVE-2026-42369) stack overflow vulnerabilities
• TALOS-2026-2329 (CVE-2026-42368) privilege escalation vulnerability
• TALOS-2026-2328 (CVE-2026-42367) privilege escalation vulnerability
• TALOS-2026-2327 (CVE-2026-7371, CVE-2026-42366) reflected cross-site scripting (XSS) vulnerabilities
• TALOS-2025-2326 (CVE-2026-42364) OS command injection vulnerability
• TALOS-2025-2332 (CVE-2026-42365) guessable session cookie vulnerability
• TALOS-2025-2322 (CVE-2026-7161) insufficient encryption vulnerability
• TALOS-2026-2375 (CVE-2026-57273, CVE-2026-57274, CVE-2026-57275, CVE-2026-57276, CVE-2026-57277, CVE-2026-57278) stack-based buffer overflow vulnerabilities
• TALOS-2026-2373 (CVE-2026-13131, CVE-2026-13132, CVE-2026-57264, CVE-2026-57265, CVE-2026-57266, CVE-2026-57267, CVE-2026-57268, CVE-2026-57269, CVE-2026-57270, CVE-2026-57271, CVE-2026-57272) out-of-bounds read vulnerabilities
• TALOS-2026-2370 (CVE-2026-13125) lack of authentication vulnerability

VTK-DICOM vulnerability

Discovered by Emmanuel Tacheau of Cisco Talos.

The Virtualization Toolkit (VTK) is an open source software solution for handling scientific data, for use in tools for 3D rendering. The VTK-DICOM API is specifically to allow VTK users to parse Digital Imaging and Communications in Medicine (DICOM) medical data.

Talos found one vulnerability in VTK-DICOM, TALOS-2026-2366 (CVE-2026-22879), which is a heap-based buffer overflow vulnerability.

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

When the systems are up but the business is down

The defining risk to resilience today is not the outage. It is the ad hoc response that follows when partial failure has not been planned for.

On July 19, 2024, a single misconfigured file in a routine software update disabled 8.5 million Windows devices worldwide. Across sectors, the disruption grounded flights, diverted hospital patients, and took financial institutions offline. The fix itself took only 80 minutes. Recovery took days, because every affected device required manual remediation.

The organizations that recovered most quickly did so not because of their superior IT capability, but because a virtual workspace architecture allowed employees to continue working independent of the state of the underlying device. Organizations without that capability spent the first day simply establishing the scope of impact.

That interval, between systems being restored and the business resuming operation, is where resilience is now determined.

The cost of disruption is material

Many large enterprises surveyed reported revenue losses attributable to an outage within the past twelve months and more than half experience a disruption at least weekly. The average high impact outage now costs $1.9 million per hour, and the average data breach costs $4.88 million, with ransomware present in nearly half of all cases. These figures are unlikely to surprise senior IT leadership. What is less widely recognized is that most continuity plans were designed around total outage followed by clean restoration, a failure mode that occurs infrequently today.

Today’s disruptions are typically more limited in scope. An identity provider experiences latency, a cloud region degrades, or a SaaS platform throttles under load, often without triggering any alert, even as employees find themselves unable to work. By the time the pattern is recognized, workarounds are already underway, including shadow applications, expanded access privileges, and bypassed controls intended to preserve productivity. That ad hoc response, not the outage itself, constitutes the primary exposure.

This loss of control compounds into a secondary crisis, as access exceptions remain open and audit trails become incomplete. Regulatory bodies have responded accordingly, with DORA, the UK PRA, and FFIEC each shifting the standard of evidence from demonstrating that a plan exists to demonstrating that it withstood real disruption.

What prepared organizations do differently

They establish service tiers in advance of disruption, determining beforehand what is non-negotiable, what may degrade, and who holds decision authority, rather than negotiating these questions during the first hour of an incident, which remains standard practice elsewhere.

They map dependencies by workflow rather than by organizational structure, enabling precise understanding of the downstream effect of an identity outage or third-party API failure.

Most significantly, they design continuity protocols to tighten controls under pressure rather than relax them, even though the prevailing instinct during a crisis is to ease governance to preserve operational momentum. The organizations that perform best take the opposite approach, predetermining access restrictions and exception authority so that execution follows an established plan rather than an ad hoc response.

These organizations also rehearse their response through tabletop exercises and rollback drills conducted on a recurring basis, and those that sustain this discipline report fewer severe incidents and faster recovery as a direct result. The differentiating factor is preparation, not circumstance.

Where Citrix fits

This goes beyond a list of capabilities. It is the operational foundation that holds when other systems do not. The Citrix platform sustains employee access independent of underlying device or infrastructure failure, and reroutes workloads automatically when services degrade, eliminating reliance on manual intervention when it matters most. It also enforces access governance at the application layer rather than the network layer, ensuring that an operational incident does not become a compliance incident as well. At the same time, it reduces the time between detection and diagnosis, and replaces ad hoc recovery with a structured return to a known-good state.

The result is measurable across industries, with a European rail operator, a major U.S. hospital system, and a global accounting firm each having documented reduced downtime, fewer unresolved access exceptions, and faster recovery using this approach.

Considerations for the next disruption

Leadership should be able to answer the following questions before disruption occurs, not after. Are your Tier 0 services clearly identified, with defined limits for permissible downtime? Has your organization tested operation without its primary identity or cloud provider, using an actual runbook rather than a theoretical exercise? Organizations that can answer these with confidence are the ones that will weather the next incident, not merely survive it.

Your next disruption is already on the calendar. You just don’t know the date yet.

from Citrix Blogs https://ift.tt/alftz1W
via IFTTT

New GigaWiper Windows Backdoor Bundles Disk Wiping, Fake Ransomware, and Spyware

Microsoft has taken apart a destructive Windows backdoor it calls GigaWiper. What stands out is how it is built: not one tool but three older destructive programs bolted into one, offered as commands the operator can choose from.

Each is a different way to break a machine: wipe the whole disk, overwrite the Windows drive, or run fake "ransomware" that scrambles files with a key it never saves.

Because this is malware and not a single flaw, there is no patch to chase; GigaWiper is what an attacker runs after they are already inside, which makes early detection and clean, offline backups the real defense.

The same malicious files show up in a second report under another name: BLUERABBIT, a backdoor Binary Defense flagged last month.

Microsoft lists four hashes for the GigaWiper backdoor; Binary Defense lists the same four for BLUERABBIT, and both command servers match. Binary Defense, citing Google's Threat Intelligence Group, ties the malware to a likely Iran-nexus group aimed at Israeli organizations. Microsoft names no country.

Three ways to destroy a machine

GigaWiper is written in Go (also called Golang) and runs on Windows. It takes orders as numbered commands, and three of them destroy the machine, each in a different way:

• A raw disk wiper that overwrites the physical drive and wipes the partition table (the map of how the disk is laid out) before rebooting. There is no file-by-file deletion to reverse; it destroys the disk contents directly.
• Fake ransomware built on older code called Crucio. It encrypts files, adds a .candy extension, and changes the desktop wallpaper to an alarming warning image. There is no ransom note and no saved key, so there is nothing to pay and nothing to decrypt. This is destruction wearing a ransomware costume.
• The last targets the Windows drive, overwriting it several times with different data patterns. Microsoft says it is a Go rewrite of a wiper it tracks as FlockWiper.

None of these leaves a way back: encrypted files cannot be unlocked because the key is gone, and wiped drives can only be rebuilt from clean backups. The goal is a dead machine, not a payout.

It spies, too

Destruction is only half of it. The same backdoor can quietly watch and control an infected PC. It takes screenshots of every monitor, records the screen while someone is working, and can open a hidden VNC session that streams the display and lets the attacker type and move the mouse.

It also collects system details, manages running programs and services, edits the registry, and can wipe Windows event logs to cover its tracks. Microsoft found more commands sitting dormant in the samples it examined, including stubs for a keylogger and additional wipers.

To stay out of sight, GigaWiper pretends to be OneDrive. It creates a scheduled task named OneDrive Update that runs every minute and tracks itself in a registry key under HKCU\SOFTWARE\OneDrive\Environment. When it opens its remote-control channel, it hides behind a firewall rule named after a real Windows component, Microsoft.Windows.CloudExperienceHost.

For its command traffic, it skips ordinary web requests and rides on real business services instead: RabbitMQ for tasking, Redis for results, and MinIO for exfiltration. Because those are legitimate tools rather than a custom malware channel, the traffic looks ordinary on networks that already run them.

Where GigaWiper came from

Microsoft traces GigaWiper's fake-ransomware code back to Crucio and its multi-pass wiper back to FlockWiper, and assesses that the same developer built all three. It names no country. But Crucio is not anonymous. Its code was listed as suspected ransomware in a December 2023 CISA advisory on CyberAv3ngers, a group linked to Iran's Islamic Revolutionary Guard Corps.

That is the same crew, THN reported, that broke into water and energy sites across the US, Israel, the UK, and Ireland in 2023, logging into internet-exposed industrial controllers. In one case, they took control of a booster station at a Pennsylvania water authority. The Crucio sample Microsoft cites carries the same fingerprint listed in that advisory.

Microsoft also found a recurring tag, "GRAT", in both FlockWiper's debug paths and GigaWiper's own function names, tying the two tools together and hinting at a further component that has not surfaced yet. The timing differs by source: Microsoft dates the destructive activity to October 2025, while Binary Defense first saw the same files as BLUERABBIT in March 2026.

Part of a bigger wave

Iran-linked wiper activity against Israel has drawn repeated warnings through 2025 and 2026. Palo Alto Networks' Unit 42 has tracked a parallel surge, much of it from a separate group, Handala Hack, and in March 2026 Israel's National Cyber Directorate warned of Iranian wiper attacks on local organizations.

The tactic GigaWiper uses is old: NotPetya in 2017 also posed as ransomware while quietly destroying data. The disguise buys the attacker time: a wrecked machine first looks like a ransomware case someone might recover from, not the total loss it is.

Microsoft frames GigaWiper as operators folding separate tools into one flexible platform. For defenders, the consequence is concrete: when a single implant can watch, steal, or destroy, the tool no longer reveals the goal. You used to read intent from the malware you found; here, the operator decides after they are already inside.

One platform, two vendor names, and dormant command stubs still in the code point to a tool still being built out.

What defenders should do

Spotting it fast comes down to a few specific signals:

• A OneDrive Update scheduled task that repeats every minute.
• RabbitMQ or Redis traffic from ordinary desktops rather than servers.
• Processes using takeown and icacls to take ownership of Windows boot files like bootmgr and ntoskrnl.exe outside maintenance windows.

On the product side, Microsoft recommends turning on tamper protection so attackers cannot switch off your antivirus, blocking the two known command servers (185.182.193[.]21 and 212.8.248[.]104), running endpoint detection in block mode, and enabling cloud-delivered protection and automatic remediation. The full list of file hashes, server addresses, and detection names is in Microsoft's report.

The Hacker News has reached out to Microsoft and to Binary Defense for confirmation that GigaWiper and BLUERABBIT are the same malware, and for details on victim scope and attribution, and will update this story with any response.

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