Building resiliency into Boundary session recording

In modern enterprise security, privileged access management (PAM) is a core compliance and cybersecurity mandate. At its center lies session recording — the continuous ingestion of an immutable, cryptographically verifiable ledger of privileged activity. This record serves as the definitive source of truth, eliminating forensic blind spots. In an era of heightened scrutiny, a resilient recording architecture is a must to mitigate liability and accelerate threat management. 

Boundary session recording  

HashiCorp Boundary session recording, introduced for SSH in Boundary 0.13 and RDP in Boundary 1.0, employs high-fidelity protocol capture. Rather than screen scraping, Boundary records the exact byte stream of a terminal session, including commands and responses. Session recordings are stored in BSR format, and are enriched with structured metadata, identifying the user, target etc. This metadata, combined with granular per-target policies, allows organizations to selectively audit high-risk production systems, effectively balancing audit fidelity, operational overhead, and storage cost. Initially stored on the local disk, recordings are automatically synchronized to a customer-owned S3-compatible storage upon session termination. To secure the chain of custody, each BSR file is cryptographically signed, with encryption keys protected by a customer-managed KMS. Auditors can review activity via Boundary's integrated web player or export data to the asciicast format for offline analysis, accelerating forensic investigations.  

Building a resilient system for session recording infrastructure 

While this framework provides visibility, enterprise environments are rarely perfect. Network partitions, disk exhaustion, and service failures are inevitable. In security, a recording failure is more than a technical glitch; it is a compliance gap. The data integrity and completeness are as vital as the recording process itself. The infrastructure challenge is why resiliency needs to be a core pillar for a session recording architecture. Technically, resiliency is the ability of a system to maintain an acceptable service level despite faults and challenges to normal operation to ensure operational continuity. It is the mechanism for handling the "unhappy path" caused by storage failures, hardware disruptions, and crashes, allowing autonomous recovery to a known good state. Boundary session recording resiliency enables data integrity that ensures complete and accurate capture of user activity throughout the session recording lifecycle, from session initiation to auditor playback. Non-resilient session recording capability can create missing or incomplete recordings, resulting in compliance and audit risks.

The triple threat: why an audit gap is more than a glitch  

The absence of a resilient recording system creates an impact across an organization's security, operations, and business. 

The security context: forensic blindness and accountability  

From a security perspective, resilience is about maintaining an unbroken chain of custody. If a security breach occurs and the recording service fails during the attack, the security team is left with forensic blindness, loss of visibility on instances of high-privileged activity. Without data on user's movements, an organization is forced to report a "worst case ccenario" breach to the public because it cannot prove otherwise, which leads to a loss of accountability. If a disgruntled employee denies running a destructive command, and the recording is unverified or missing signatures, the security team is left without legally defensible proof. Moreover, if a system can be bypassed by crashing a service or exhausting a local disk, it becomes a target for attack. 

The operational context: the cost of manual recovery  

Security engineers review recordings to monitor sessions, reconstruct event timelines, identify the root cause, and assess the blast radius. In a non-resilient environment, security engineers are consumed by an "invisible workload” and manual cleanup. When a system lacks automatic recovery, team members must log into servers to locate "stuck" files, attempt to repair corrupted data, and prepare reports about missing records. This contributes to a high ‘mean time to resolution’ (MTTR). When a critical incident occurs, teams rely on recordings to understand the problem. If that “digital evidence” is missing due to a simple disk error, a 10-minute investigation can spiral into 10 hours, resulting in longer downtime and lost revenue. Furthermore, systemic instability results when a system fails to handle resource limits. If a storage disk fills up and the system lacks the intelligence to stop routing sessions through the affected service, connections drop, creating a poor UX and preventing work from getting done. 

The business context: non-compliance and reputational damage  

For regulated industries such as finance, healthcare, or government, a missing recording escalates from a technical error to a compliance violation. The failure to meet compliance regulations like SOC2, PCI DSS, or HIPAA can result in failed audits, heavy fines, and even the loss of business. Beyond regulatory bodies, business leaders prioritize trust. When an auditor or customer requests proof of who accessed their data, explaining that the record was “lost due to a disk error” signals a weak security posture, leading to erosion of brand trust and loss of high-value contracts. Finally, money and time spent manually recovering data is money not spent on innovation, making an organization less competitive by accelerating technical debt. 

Boundary's resiliency framework: zero-gap security in action  

To counter the realities of network outages, disk limits and system restarts, Boundary leverages a framework that strives toward a rear zero-gap audit trail to ensure availability of privileged activity records. Boundary addresses these risks by targeting three primary vectors. 

Disk space exhaustion 

Session data is captured locally before being transferred to permanent remote storage. If the local disk fills up during an active session, the recording process halts abruptly, often resulting in file corruption and an unreadable recording. Boundary addresses this challenge with proactive and preventative measures: 

• Health filtering: Boundary continuously monitors the local storage state.’ If it reaches a predefined “low disk” threshold, the system stops routing new sessions to it.  

• SyncingFile buffer: For sessions already in progress, Boundary reserves a small buffer of disk space at the start. This critical reserve ensures that even if the disk fills up, there is always enough space available to write the final signatures and safely close the file, preventing corruption and preserving the integrity of the captured data.  

• Sync-and-purge: When a session concludes, the BSR file is automatically uploaded to the remote bucket. Upon successful receipt, the local copy is deleted to free up space. 

• Policies: Boundary supports policies that govern file retention and deletion lifecycle, ensuring automated file management across global and project scopes.  

 Remote storage failures 

A perfectly captured recording is useless if it cannot be moved to permanent storage. Expired credentials or network disruptions can leave data “stuck” on local storage, and if the session recording service (worker) is decommissioned before the connection is fixed, the audit trail is permanently lost. Boundary prevents this by:  

• Remote storage monitoring: Boundary actively tracks the health of the connection to the storage buckets. If the recording service loses its connection to the remote storage, it is flagged and bypassed for future recordings until the connection is restored.

Errors 

Processes and servers can crash and restart. When a session recording service restarts after a failure, a recording that was active at the time can be stuck in an unverified state and may not get transferred to storage. Boundary supports a self-healing mechanism:  

• Recovery workflow: Upon restart, the session recording service automatically triggers a recovery workflow that scans the local file system for any “unfinished” recordings, verifies the integrity of the data, and uploads the files to the storage bucket, completing the transfer without requiring any manual intervention from an operations team. 

• Recording status: Boundary provides visibility into the recording status, whether it is playable or not, with error details enabling “call to action” in the admin UI that enables administrators to identify and resolve issues. 

The future: protocol-aware audit for privileged sessions 

Engineered for resilience, Boundary session recording eliminates the systemic audit gaps that plague legacy PAM solutions. Its future roadmap extends beyond SSH and RDP to Kubernetes, databases and HTTP/HTTPS, with advanced features like searchable command indexing. By transforming raw session logs into cryptographically verifiable forensic assets, Boundary elevates passive streams into active intelligence, empowering security teams to audit privileged activity with precision and maintain continuous compliance. 

Next steps: Enable your targets for auditability 

To learn about Boundary session recording, try it yourself: 

• Get started for free: Sign up for HCP today to experience identity-based privileged access. 

• Upgrade for advanced auditing: Upgrade to the HCP Boundary Standard tier to unlock session recording features. 

• Enable session recording: Use the step-by-step configuration guide to configure session recording for SSH targets. 

• Watch demo video: Watch a demo of SSH session recording along with configuration steps. 

from HashiCorp Blog https://ift.tt/p20bPgE
via IFTTT

New MemGhost Attack Plants Persistent False Memories in AI Agents Through One Email

Give an AI assistant a memory and access to your inbox, and you hand an attacker a way to rewrite what it thinks it knows about you. A single email can trick that agent into saving a false "fact" about the user, hide the change, and quietly steer its answers in later sessions.

When it works, the person reads an ordinary-looking reply and never learns their assistant was tampered with.

The researchers named the attack stealth memory injection and built a tool that writes the emails automatically. The paper, "When Claws Remember but Do Not Tell," landed on arXiv on 6 July 2026.

First, what these assistants do

A personal agent is an AI assistant that sticks around. Instead of forgetting everything when a chat ends, it keeps notes about you in files: your preferences, your contacts, and what you asked it to do. It reads those notes at the start of every new session, which is why it feels like it knows you.

Many of these agents can also act for you, reading your email, checking your calendar, and running small jobs on a schedule while you are away.

OpenClaw, the open-source agent used as the study's primary target, keeps this state in plain text files: some hold its standing instructions (AGENTS.md), some hold what it has learned about you (MEMORY.md). It pulls the core ones into the model's context at the start of every session.

Those notes are the whole point of the product. They are also the target.

The one-email attack

The attacker does not need your password or your account. They send an email to someone whose agent is set up to check their inbox, which, for these assistants, is a routine job. Buried in that email is text aimed at the assistant, not you.

If the agent's email skill takes the bait, three things happen in a row. The agent uses its own file tools to write the attacker's false note into its persistent memory. Its visible reply says nothing about having done so. And later, in a fresh conversation, that false note changes what it tells you or does for you.

In one of the study's test cases, the planted lie was that the user's Zelle daily sending limit had been raised to $10,000.

You do not catch the change for a few reasons. The assistant hides its behind-the-scenes steps by design, so the moment it edits a file never shows up in the chat. Few users ever open the raw memory files to read them. And when the agent runs on a schedule in the background, it often sends no message at all, so there is nothing to notice.

To make the poison stick, the tool aims it at the core files that load every session, so a single write is loaded into every later session instead of waiting to be pulled from a separate memory store.

The attack is generated by a tool the researchers call MemGhost. Its makers trained an attacker model offline against a shadow copy of a personal agent, rewarding emails that got the memory saved while keeping the reply quiet. At attack time, it writes the finished email in one shot, with no back-and-forth with the victim.

Across 56 fresh test cases, MemGhost pulled off the full attack, planting a false memory, hiding it, then swaying the agent's answers in a later session. It worked in 87.5% of background-mode runs against OpenClaw on GPT-5.4, and 71.4% against a Claude Code SDK agent on Sonnet 4.6.

These were isolated benchmark runs, and they begin only after the email has already reached an inbox that the agent reads, so nothing here tests whether a real payload clears spam filtering or sender authentication first.

Success was generally lower in foreground-mode tests, where the user can see the reply. In background mode, it stayed above 80% on each of two other agent frameworks and on a vector-based memory store in place of the plain files. The team also built WhisperBench, a 108-case benchmark spanning risks from bad medical advice to money loss to security sabotage.

Overview of the WhisperBench framework

Crude versions of the trick mostly fail. A blunt "save this quietly and say nothing" was caught or ignored by the strongest models almost every time; the trained generator is what pushed the numbers up. It also slipped past the defenses meant to stop this kind of attack.

An input filter built to catch poisoned emails missed MemGhost's message more than nine times in ten, and a model specially hardened to ignore instructions that arrive by email still followed the planted one about half the time. Even when the owner was made to ask outright, "tell me what you checked and what you did," the attack stayed hidden about a quarter of the time on one model.

There is no quick patch to wait for. OpenClaw's own security policy treats prompt injection on its own as out of scope for a fix, unless it also crosses an authorization, tool-policy, approval, or sandbox boundary. MemGhost crosses none of those, since it works through the agent's own memory-write tool, and researchers keep demonstrating exactly this kind of injection against the framework.

The study's authors argue the real fix has to live inside the agent: tagging where a piece of information came from, asking the user before anything reaches durable memory, and logging every write. Until those lands, the exposed setup is any agent that both reads untrusted mail and can write its own memory without asking.

The blunt fix is to keep those two jobs apart. Failing that, limit what an email-triggered run can change, and check the memory files after anything suspicious arrives.

OpenClaw confirmed that position to The Hacker News and pushed back on how the paper set up its agent. Its security guidance tells operators to route untrusted email through a separate reader agent stripped of memory, file, and shell tools, passing only a summary to the main agent, which the paper did not test.

It also argues model tier matters: the OpenClaw runs used GPT-5.4, a current frontier model, but the authors skipped Claude Opus 4.6 on cost, and OpenClaw pointed to HackMyClaw, a public challenge where thousands of injection emails failed to pry a secret from an Opus 4.6 agent. That test targeted data theft, not memory poisoning, so it does not directly answer the paper.

OpenClaw said it is weighing memory-write controls for external content, including provenance, audit logs, and confirmation prompts, in the same direction the paper recommends. The Hacker News has also reached out to the paper's authors and will update this story with any response.

The manual version came first

In 2024, researcher Johann Rehberger showed the same move by hand against ChatGPT, planting instructions in its long-term memory through poisoned web content so it would keep leaking a user's data across future chats. He called it SpAIware. OpenAI closed the data-leak path, but the ability to write memory from untrusted content stayed.

A year later, it reached a shipping product. EchoLeak (CVE-2025-32711), disclosed by Aim Security in June 2025, used one hidden-text email to make Microsoft 365 Copilot hand over internal company data when the user later asked it a normal question. Microsoft rated it critical and patched it, and no real-world abuse was reported.

A later case study laid out how it slipped past Copilot's filters. Both showed that the content an AI reads can carry commands, delivered by an email anyone can send.

What MemGhost adds is persistence: Rehberger's version had to be planted by hand, and EchoLeak leaked data only in the moment it was asked, but here an automated payload turns one email into a false memory that stays put and steers sessions long after the message is gone.

This is a lab result, not a break-in in progress. The researchers ran everything in sealed test environments with fake inboxes and fake users, and the paper documents lab testing only, not use against real people; they say they plan to disclose their findings, attack patterns, and the benchmark to the makers of the affected agents and models.

Stealth is held in the study partly because capable agents are built to keep their tool activity out of the chat. The one model that gave itself away did so by printing its intermediate steps in the reply, and the researchers expect detection to get harder as agents get better at working quietly.

The real problem is plainer: a message from outside became a durable, trusted context inside the agent, with no visible moment where anyone approved it.

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

Forg365 PhaaS Targets Microsoft 365 with Device Code and AitM Session Theft

A new phishing-as-a-service (PhaaS) operation called Forg365 is using a combination of device code phishing, adversary-in-the-middle (AitM) tactics, antibot evasion, artificial intelligence (AI)-assisted lure creation, and post-compromise mailbox operations targeting Microsoft 365 accounts.

Distributed via Telegram and costing $400 a month (or $3,800 per year), attack chains leverage phishing lures that make use of legitimate email delivery infrastructure, such as Amazon Simple Email Service (Amazon SES) and Twilio SendGrid, to imitate a redirection chain that blends into regular email traffic before it ends in Forg365-controlled domains.

"The panel exposes a mature operator workflow: accounts, links, invitations, OAuth app configuration, redirect links, SVG generation, campaign sending, SMTP profiles, SMTP rotation, AI email generation, token vaulting, account intelligence, keyword alerts, viewer links, and browser-extension support," ZeroBAC said.

The email security company said the PhaaS kit is best understood as similar to the Kali365 (aka Octopi365 and Freedom365) and Sneaky 2FA ecosystem, reflecting the industrialization of the business model, which is now combining bringing together lure creation, delivery, evasion, token/session handling, and post-compromise operations under a subscription-based setup that allows even threat actors with little-to-no technical expertise to orchestrate phishing campaigns with minimal effort and at scale.

Attack chains using Forg365 have been observed using business document-themed or remittance approval lures to trick recipients into clicking on malicious links. The sender domain uses Amazon SES for delivery, while the message body contains SendGrid-hosted images or tracking resources.

Customers who successfully complete Telegram registration utilize an operator panel accessible over the clearnet ("logfriend[.]com/login"), from where they can generate lures, set up campaigns, and manage captured tokens.

"Forg365 includes a device-auth phishing branch that presents a Microsoft-styled verification code page and pushes the victim into a legitimate Microsoft Authentication Broker sign-in flow," ZeroBAC explained. "The victim sees real Microsoft authentication surfaces, but the code authorizes an attacker-controlled session."

For AitM phishing, the platform employs route tokens, session cookies, and traffic classification to determine whether to serve phishing content or a benign decoy. If a VPN connection is detected, the kit redirects to innocuous decoy content instead of exposing the phishing pages.

A notable aspect of the Forg365 platform is that it offers an extension named ForgCookie for Chromium-based browsers like Google Chrome, Microsoft Edge, and Brave that is designed for continued access to the compromised accounts. Described as an "automatic SSO cookie refresh for Microsoft services," the add-on acts as an intermediary between the token acquisition and browser access by cycling through the steps listed below -

• Requests account data from the Forg365 backend
• Calls the cookie-generation endpoint for a selected account
• Clears Microsoft session cookies
• Injects the generated refresh-token credential cookie into the Microsoft login domain
• Triggers a silent OAuth flow
• Captures resulting Microsoft cookies across Microsoft domains

Forg365's extends beyond simple credential and token harvesting to facilitate a wide array of post-compromise actions, including monitoring for specific keywords in compromised email accounts and drafting a message response to a particular email thread using assistance from AI.

"The result is a platform that lowers the skill threshold while increasing operational consistency. Less experienced affiliates can use prebuilt templates, while more capable operators can customize landing pages, rotate infrastructure, manage tokens, generate cookie material, and monitor compromised accounts," ZeroBAC said.

The disclosure coincides with the discovery of various campaigns that have been found to employ phishing kits for credential theft -

• Sending fake Microsoft account activity alerts from a legitimate-but-compromised third-party SaaS sender account to direct users to Sneaky 2FA-style phishing pages to launch a redirection chain that leads to the final phishing host, but not before performing checks to decide whether the visitor is a real user.
• Using phishing emails that direct recipients to a website hosted on Canva, which then triggers the device code phishing flow to hijack Microsoft accounts using the Kali65 phishing kit. The kit supports over 33 different lures, a payout pipeline, and a desktop application called OctoLink Live (aka Kali365 Live) that abuses the stolen token to launch a Chromium browser session and open the victim's mailbox in OWA, OneDrive, SharePoint, or admin.microsoft.com. The platform also offers a tool known as OctoLink Sender to mass-send phishing emails from the breached account to other contacts, a technique called lateral phishing.
• Phishing campaigns using Kali365 have also distributed phishing pages impersonating Russia's MAX messenger, indicating an attempt to single out users in Russia. "A phishing operator who can convert MAX account takeovers into propagation has access to one of the largest installed messaging bases in the Russian-speaking world," Arctic Wolf said.
• Sending emails mimicking the IRS and Social Security Administration, alongside Adobe, Microsoft, DocuSign, and Dropbox, to deliver legitimate remote access software like ConnectWise ScreenConnect as part of phishing campaigns using a PhaaS kit called The Quarry that's developed, maintained, and sold by a lone operator named RockyBelling. The price of the kit ranges anywhere between $500 and $3,000. This includes tools like Rocky Gmail Sender (a bulk email tool), Rocky Email Sorter (to sort email addresses by domain across Gmail, Yahoo, Hotmail, and AOL), and VioletRAT.
• Sending SMS messages impersonating the U.S. Postal Service (USPS) and UPS to trick victims into visiting a phishing page that prompts users to enter their personal and financial information under the pretext of a failed package delivery and scheduling a new delivery. "Underneath the deception, the kit captures data in real time," Censys said. "It opens a WebSocket back to its origin and streams the victim’s card data keystroke-by-keystroke, runs a server-side BIN lookup on the card number, and pushes routing decisions (retry, PIN prompt, OTP prompt, kill-switch) back into the victim's browser while they type."
• Using fake bid proposal workflows to take over Google accounts using a framework called Nyasher. The redirection chain incorporates a "press-and-hold" verification page to filter out automated scanners and bots, before navigating to a blob URL. "The final page displayed a Google sign-in interface but was not reachable as a normal hosted HTML document," ZeroBAC said. "It existed as a browser-created object URL."
• Using bogus Google Partners and Google Premier Partner enrollment workflows in phishing emails to redirect recipients to a fake Google sign-in page designed to capture credentials in real time as part of a campaign codenamed GPPStorm.
• Using a legacy email alias to target a user's inbox and launch a device code phishing flow that uses the EvilTokens kit. "The kit was reached through a Mailjet tracking link, then a compromised WordPress site, then a CAPTCHA interstitial, then the Cloudflare Workers host," ZeroBAC said. "Three live infrastructure hops between the email body and the kit, none of which is the kit itself."

To counter these threats, it's recommended to block device code authentication unless it's required, review mailbox artifacts after device code events for any signs of unusual activity, audit mail-flow rules, and decommission legacy aliases that no longer correspond to active employees.

"The campaign succeeded in reaching the inbox because the recipient organization still maintained an active forwarding relationship from a pre-acquisition namespace into a current mailbox," ZeroBAC noted.

"The attacker used a still-resolvable historical identity to deliver mail that, from the SEG's point of view, looked like normal forwarded correspondence. From the user's point of view, the message landed in their working inbox with no visible cue that it had taken an indirect path."

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

Attacker Uses Suspected AI-Generated PowerShell Script to Map Active Directory

Cybersecurity researchers have flagged an intrusion in which an unknown threat actor leveraged a vibe-coded PowerShell script for Active Directory (AD) enumeration.

"The script looked for the Domain Controller (DC) and mapped users, computers, and domains, before creating a directory and exporting out a number of files, and finally creating AD_Report.html to measure the success of the enumeration attempt," Huntress researchers Jevon Ang and Dray Agha said.

The attack chain involved the threat actor establishing Remote Desktop Protocol (RDP) access onto a domain-joined Windows Server with a set of pre-compromised credentials, followed by staging the tools in the "C:\ProgramData\" folder. The incident took place in early June 2026.

This included an artificial intelligence (AI)-generated payload to map the Active Directory environment. The assessment is based on various telltale signs, such as the prompt iteration title, placeholder strings, over-engineered code that features multiple methods to find a Domain Controller, and beautified console output using cyan, green, red, and yellow.

Huntress described the bespoke PowerShell script as "highly aggressive" and "noisy," making use of a "five-step cascading fallback mechanism" to enable reconnaissance and discovery. It's titled "100% Working AD Information Gathering Script - FULLY FIXED," suggesting a back-and-forth with a large language model (LLM).

Once the primary Domain Controller is located, it initiates a data collection routine to systematically harvest AD users, computers, groups, organizational units (OUs), and trusts, and store the details in a staging directory.

About 30 minutes later, the attacker moved to deploy a s5cmd, a legitimate tool used for bulk file operations, along with SharpShares, a C#-based network shares enumeration utility, to look for user-accessible data repositories.

In the final stage, the data is said into CSV files, archived, and exfiltrated to a remote server, but not before creating an HTML file summarizing the data theft in the form of an Active Directory Inventory Report.

"It's likely a 'helpful' inject from the LLM that the attacker simply went along with, rather than being intentionally authored into the script," the researchers explained.

The development is yet another sign that threat actors are augmenting their arsenal with vibe-coded malware generated with assistance from AI models, even if the technology isn't being abused in ways not seen before. What it does change is that it lowers the barrier to entry for cybercrime, permitting less-skilled actors to come up with highly capable, evasive tooling with minimal effort.

"The underlying attack chain still resembles the tried-and-tested smash-and-grab playbook we've seen for years," Huntress said. "This core methodology has remained consistent, but it is now being selectively augmented by AI. This hybrid approach prioritises aggression and speed over stealth, allowing threat actors to execute highly damaging campaigns faster than ever."

AI as a Force Multiplier

In a report published last week, Sygnia revealed that AI-enabled attackers do not necessarily need novel malware or zero-days, but that the real shift lies in the fact that cyber intrusions can be orchestrated at a speed and scale faster and bigger than defenders can contain them.

The incident response company said it observed an AI-assisted cloud attack that progressed from initial access to broad compromise within a span of about 72 hours against a large Amazon Web Services (AWS)-based environment. The end goal of the activity is assessed to be financially motivated, with the attacker using the access to the victim's cloud infrastructure for use as leverage for extortion.

"The threat actor repeatedly leveraged newly acquired credentials to restart discovery, secrets harvesting, persistence, and impact activities," it said. "The attack relied on familiar cloud techniques rather than novel malware or zero-days."

"The threat actor was not exploiting a single misconfiguration; they were chaining weaknesses across application services, AWS resources, source-control repositories, CI/CD workflows, runtime components, and data stores, while rapidly executing credential discovery, secrets harvesting, cloud enumeration, deployment-pipeline abuse, runtime modification, database access, and operational disruption."

The attacker, per Sygnia, entailed repeated attempts to establish persistence on the compromised hosts, obtaining the access key to one of the AWS accounts through shortcomings in an internet-facing application. Each new access was followed by renewed enumeration, additional secret collection, persistence attempts by creating access keys and IAM users, and data exfiltration. At the same time, several attacker-created artifacts were masked as a pentest or a red teaming exercise.

To further exert pressure on victims, the attacker performed a series of actions -

• Denying access to S3 buckets
• Limiting ECS services or containers to a maximum capacity of zero
• Creating ACL rules to block network access
• Purging SQS queues

"The significance was not that AI introduced new attack techniques, as every observed action mapped to long-established adversary behaviors, but that it reduced the time and effort required to operationalize those techniques across a complex environment," Sygnia pointed out.

"The threat actor repeatedly converted newly obtained access into tailored action. For each new access key, the actor appeared to quickly determine the associated permissions, reachable resources, and most valuable next steps."

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

Misconfigured Server Reveals Three Evilginx Phishing Operations Targeting Microsoft 365

An attacker running a live Microsoft 365 phishing operation left a Python web server listening on a public port with directory listing switched on. The command that did it: python3 -m http.server 8080, was still sitting in the readable .bash_history.

From that one lapse, French security firm Lexfo lifted the operator's entire toolkit and pivoted through it to two more phishing operators, three campaigns in all. Each ran a custom fork of the open-source Evilginx proxy, cloned from public GitHub.

The largest of the three had been running for more than a year, its victims overwhelmingly corporate mailboxes.

The three got past MFA in two mechanically different ways, one by proxying the live login, one by abusing a legitimate Microsoft sign-in flow. The two need different defenses, which is the part that matters most if you run Microsoft 365.

Directory listing on a working attack server is close to a full confession. The listing exposed phishing configs, credential-harvesting logs, RMM installers, combolists, backup archives, and the operator's own Telegram session files.

Behind it ran an Evilginx adversary-in-the-middle proxy and a SimpleHelp remote console on the same host, at 185.163.204[.]7 in Budapest, cataloged in late April 2026 during a routine internet scan.

The bash history and a set of public repos pointed straight at the operator: an Egyptian actor the firm tracks as codemado, active in VoIP and hacking forums since 2018, now running a Microsoft 365 AiTM platform on picis[.]net and monetizing access through a bulk mailer he wrote called MaDoO Blaster.

His campaign went live on April 20 and kept running past the day the directory was found on April 30, with fresh subdomains and a renewed wildcard certificate turning up weeks later. His own bot logged captures against two corporate M365 accounts, one French, one North American.

The repeated captures of the same accounts from different IPs are consistent, the firm says, with the operator refreshing stolen tokens as they aged out.

Where the kits came from

codemado did not build the framework he runs. He cloned it, and his bash history shows him comparing kits side by side. The server held four Evilginx variants pulled from two other GitHub developers, and both turned out to be active operators in their own right.

The first, red-queen, comes from a Nigerian operator the report calls mail-argenta, and it shows how much polish gets bolted onto a public framework. His fork renames the crossorigin and integrity HTML attributes to defeat Subresource Integrity checks and adds a URL-rewriting engine to http_proxy.go to dodge path-based detection. It pre-fills the victim's email address to cut abandonment.

It also sets a one-year TTL, 31,536,000 seconds, on the captured Microsoft session cookies. The report says an intercepted login can then outlast a password reset and, without a CAE-capable Conditional Access policy, stay usable for months.

A pre-compiled evilginx2.exe is committed to the repo, so a buyer never has to build anything. One captured M365 cookie sitting in the repo carried an expiration date of June 30, 2027.

mail-argenta got caught the way his own victims do. The firm found his email and a password in infostealer logs, the kind of harvested-credential data his phishing panels exist to produce. That leaked password matched the one hardcoded as the MySQL password in his Kraken panel and reused across his accounts.

The quiet one

The third fork, black-queen, logged far more captures than the other two, and it never touches a password. Its author, whom the researchers could not identify past the handle saroula01, built it around Microsoft's OAuth device code flow, a legitimate sign-in path meant for input-constrained devices.

The attack generates a real device code, wraps it in an Authenticator-themed lure page, and tells the target to enter it at the genuine microsoft.com/devicelogin. The victim signs in on a real Microsoft page and clears MFA themselves. saroula01's backend polls the token endpoint and takes the token the moment they do.

Calling this "MFA bypass" misses how it works: nothing gets bypassed. The lure page is Authenticator-themed and attacker-built, but the device code and the Microsoft page where the victim finishes are genuine, so the MFA prompt the victim satisfies is real.

A passkey or FIDO2 key does not help either, because the victim clears it on genuine Microsoft infrastructure while authorizing the attacker's session; the origin binding that stops Evilginx passes cleanly when the origin really is Microsoft.

Microsoft documented the technique in February 2025, in a campaign it assessed with medium confidence as Russia-aligned. It has since spread well past state-backed use, into campaigns hitting hundreds of Microsoft 365 organizations.

saroula01's version ran quietly for over a year. The firm counted 218 distinct captured accounts in the campaign's Telegram bot logs across a dozen countries between June 2025 and July 2026, around 94 percent of them corporate mailboxes. Those are logged captures, not scan targets.

A token file briefly committed to the repo and then deleted, still readable in the git history, held 97 live Microsoft tokens tied to three of those victims, every one set to autoRefresh and some refreshed as many as 25 times. The framework was keeping the sessions alive on its own.

Both phishing domains, picis[.]net and romnor[.]ca, were offline when The Hacker News checked ahead of publication, though the report's timeline shows picis[.]net still provisioning new subdomains as late as May 2026. The Lexfo CTI team told THN that the domains had already gone offline before it took any action, and reads that as the operators rotating infrastructure or pulling back rather than a coordinated takedown, though it cannot confirm which.

The three connect, loosely, to something larger. In June 2026, SOCRadar documented a phishing-as-a-service ecosystem it named The Quarry, run by a developer it calls RockyBelling and, by its count, sold to close to 200 operators.

MaDoO Blaster shows up promoted inside The Quarry's Telegram channel as a third-party tool, flagged independently in both writeups, which the report frames as a supplier relationship, not membership in it. Whether mail-argenta or saroula01 has any direct tie cannot be shown from the artifacts. Their kits sat on public GitHub, and anyone could have taken them.

Built with help

The report found signs of AI-assisted development across all three operations, though they vary in strength. saroula01 left two git commits co-authored by Claude models. mail-argenta committed an instructions.txt that is a verbatim save of an AI coding session, references to earlier prompts and all, documenting how the URL-rewriting feature got built.

codemado's is thinner: one of his scripts credits CyberNeurova, a paid "uncensored" code-generation API, the report says, which advertises itself with the prompt "Build me a keylogger in Python." Two of the three put a model directly in the code; the third is a credit line, and none of them shows how much of each build the model did.

It is not confined to these three either. Microsoft has separately documented device-code phishing built on AI-driven backend automation and generative-AI lures.

The Hacker News asked the report's authors how much of the tooling AI actually produced across the three operations. The Lexfo CTI team said the Evilginx forks carried only minor changes to the core, and that the clearer signs of AI use sat in the glue code around them, the scripts and phishlets, several of which read as direct model output. It was less the framework itself, the team said, than the code built around it.

What defenders can actually do

The two techniques do not share a fix. Phishing-resistant MFA, FIDO2, or passkeys still shut down the Evilginx side by binding the sign-in to the real domain. It does not stop device code abuse. For that, the lever is Conditional Access.

Microsoft's own line is to block device code flow wherever possible. A handful of setups genuinely need it, mostly input-constrained hardware like Teams room devices and some command-line tools. Inventory that uses the sign-in logs, blocks the flow everywhere else, and tests the policy in report-only mode before enforcing.

Layer IP-based Conditional Access location policies and Continuous Access Evaluation on top, so that on supported Microsoft 365 workloads, a stolen token seen from outside your allowed ranges gets reevaluated instead of riding out its lifetime.

For detection, the report flags refresh-token grants from the Microsoft Office client ID d3590ed6-52b3-4102-aeff-aad2292ab01c in Entra sign-in logs as worth watching, where that desktop client is not in normal use; cross-check them against unfamiliar source IPs.

The same Microsoft guidance flags a catch: a session that started with device code flow stays tagged on later refreshes even when the current event no longer shows it, so hunt on the sign-in's Original transfer method field, not just the live authentication protocol.

On endpoints, hunt for the RMM tooling these operators drop for persistence; codemado's kit reaches for XEOX, so start with the agent at C:\Program Files (x86)\XEOX\xeox-agent_x64.exe and scheduled tasks matching *XEOX*Agent*Watchdog*. The domains and IPs are in the report, but that infrastructure rotates, so treat it as containment, not a fix.

The Hacker News also asked Microsoft about the abuse of its device code flow, and had received no response by the time of publication. This story will be updated with any reply.

None of this took much: three operators, none of whom built the frameworks they ran, stood up working campaigns off public repositories, kits that sell for a few hundred dollars, and a model helping with the custom parts.

The report reads that the barrier to a working campaign has fallen to near zero, and the Lexfo CTI team expects this class of attack to become significantly more common over the coming months.

One cheap ecosystem now supplies two ways around MFA, and that is the part that outlasts any single campaign here: a shop hardened against reverse-proxy phishing is still open to device-code abuse. Blocking that second path is one Conditional Access policy, no passkey rollout adds for you, and it exists only once someone writes it.

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

iCagenda and Balbooa Forms Joomla Flaws Reportedly Exploited as Zero-Days

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) has added two maximum-severity security flaws impacting iCagenda and Balbooa extensions for Joomla to its Known Exploited Vulnerabilities (KEV) catalog, following reports of zero-day exploitation in the wild.

The vulnerabilities, both rated 10.0 on the CVSS scoring system, are below -

• CVE-2026-48939 - A vulnerability in the iCagenda extension for Joomla that allows the upload of arbitrary files via the file attachment feature, leading to PHP code upload and execution.
• CVE-2026-56291 - A vulnerability in the Balbooa Forms extension for Joomla that allows the upload of arbitrary files, leading to remote code execution.

According to mySites.guru, a cloud-based dashboard service for managing WordPress and Joomla websites, CVE-2026-48939 is said to have been exploited as a zero-day since June 15, 2026, in automated attacks aimed at Joomla sites on which iCagenda is installed. It resides in the "Submit an Event" form functionality, which lets users propose events for the calendar.

"We first saw it in a client's access log: an automated scanner identifying itself as 'icagenda-batch/1.0' grabbed a token, posted a malicious upload to the submit endpoint, then fetched the planted shell at the exact path the component writes attachments to," mySites.guru said.

The flaw impacts the following versions -

• 4.x versions up to and including 4.0.7
• Legacy 3.x versions from 3.2.1 up to and including 3.9.14

JoomliC has since released updates to address the issue in iCagenda versions 4.0.8 and 3.9.15. Site owners are advised to check for suspicious PHP files in the "images/icagenda/frontend/attachments/" folder and remove them.

MySites.guru said it also observed zero-day exploitation of CVE-2026-56291, which affects Balbooa Forms versions up to and including 2.4.0. It has been patched in version 2.4.1.

"Up to and including version 2.4.0, its frontend attachment upload had a serious flaw: it accepted a file from any anonymous visitor, with no login, no CSRF token, and no check on the file type," it said. "An attacker could upload a PHP file into a public folder and then run it, which is unauthenticated remote code execution, the worst outcome a web flaw can have."

The vulnerability was discovered by mySites.guru on July 8, 2026, following a live attack on one of its customers. It has shared the following indicators of compromise -

• Look in the Balbooa Forms upload folder (by default "images/baforms/uploads") for any file that is not an image or document, especially anything ending in PHP
• Check the Joomla user list for suspicious administrator accounts
• Audit the set for recently modified or unfamiliar PHP files across the site

In light of active exploitation, Federal Civilian Executive Branch (FCEB) agencies have until July 13, 2026, to implement the fixes in their networks.

Australia Warns of Global Campaign Targeting Vulnerable CMS Systems

The disclosure comes as the Australian Cyber Security Centre (ACSC) issued an alert warning of a global exploitation campaign targeting various vulnerabilities in content management systems (CMS) and plugins.

"As part of this campaign, malicious cyber actors are actively scanning websites for opportunities to deploy web shells, leveraging various vulnerabilities affecting CMS software and plugins," the agency said. "These vulnerabilities primarily allow unauthenticated file upload, remote code execution, server side request forgery or deserialization."

Once deployed, the web shells serve as conduits for remote access and control of the targeted web servers. Some of the identified security vulnerabilities are listed below -

• Sneeit Framework (CVE-2025-6389)
• WPBookit (WordPress) (CVE-2025-7852)
• Gravity Forms (WordPress) (CVE-2025-12352)
• Craft CMS (CVE-2025-32432)
• Ninja Forms (WordPress) (CVE-2026-0740)
• MaxSite CMS (CVE-2026-3395)
• Breeze Cache (WordPress) (CVE-2026-3844)
• WavePlayer (WordPress) (CVE-2025-12057)
• MetInfo CMS (CVE-2026-29014)
• Joomla JCE (CVE-2026-48907)

"This highly scaled global exploitation campaign demonstrates the rapidly evolving cyber risk facing organisations," ACSC said, adding "advances in AI are accelerating the speed and scale of cyber operations, reducing the time between vulnerability disclosure and exploitation."

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

Buy, Build or Rent your AI?

SUMMARY: Aaron and Brian explore how recent news and macro trends are causing more companies to explore whether they should Buy, Build or Rent their AI future. 

SHOW: 1044

SHOW TRANSCRIPT: The Enterprise AI Show #1044 Transcript

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

SHOW SPONSORS:

• ShareGate - ShareGate Protect. Microsoft 365 Governance, we got this!
• Nasuni - Activate your data for AI and request a demo

SHOW NOTES:

Topic: Own AI or Rent AI?

• Why now? Fable 5 and GPT 5.6 get restricted in the US
• Past: Private Cloud (on-prem/server huggers) vs. Public cloud vs. *gasp* hybrid cloud
• Present: OSS Models vs. Big API models
• Future: What happens when the subsidies go away, and rational business practices hit the industry??

FEEDBACK?

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

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

Hackers Weaponize Balochistan Police Portal in Multi-Group Espionage Campaigns

Cybersecurity researchers have disclosed details of sustained cyber espionage activity against several Pakistani law enforcement organizations undertaken by suspected China- and India-aligned threat actors between February 2024 and April 2026.

"At Balochistan Police, the compromised assets included servers hosting web applications that manage police and citizen data, such as criminal and biometric records," Aleksandar Milenkoski, principal threat researcher at SentinelOne SentinelLABS, said in a report published this week.

The activity targeted network appliances and servers hosting web applications that manage biometric records, hotel and tenant registrations linked to national identity records, criminal case files, and personnel records.

The China-nexus threat actor is also said to have compromised one of these web applications to deploy a custom implant masquerading as a portal update. The application in question, named Complaint Management System (CMS), serves police staff and citizens, thereby putting both categories of users within the attacker's orbit.

SentinelOne said it detected compromised infrastructure associated with several other Pakistani law enforcement organizations, including the Khyber Pakhtunkhwa Police, the Islamabad Police, and the Punjab Safe Cities Authority (PSCA).

Four different threat clusters have been flagged, each deploying a unique malware family: PlugX, ShadowPad, Cobalt Strike, and Remcos RAT. The use of Remcos RAT has been linked to an India-nexus threat actor, while the PlugX, ShadowPad, and Cobalt Strike clusters are built on shared or commodity tooling and may each involve more than one operator.

That having said, the deployment of both PlugX and ShadowPad, the latter of which is considered a successor to PlugX, is traditionally associated with Chinese nation-state hacking groups.

"The victimology we observed for PlugX (between 27 February and 28 September 2024) and ShadowPad (between 3 August and 1 December 2024) reinforces this assessment," the cybersecurity company said.

"Beyond Pakistani law enforcement, victimology for PlugX and ShadowPad includes government, foreign affairs, defense, nongovernmental, and research entities across South, Southeast, Central, and East Asia, the Arabian Peninsula, and Southeast Europe, consistent with China-aligned collection."

The Remcos-related intrusion set is assessed to share infrastructure and tactical overlaps with a hacking group known as Mysterious Elephant (aka APT-C-08, APT-K-47, and TAG-179), which, in turn, has commonalities with India-nexus adversaries such as SideWinder, Confucius, and Bitter.

Attack chains have been found to employ lures related to Pakistani law enforcement, displaying a decoy document that purports to contain an operational plan for the repatriation of illegal foreigners, including Afghan Citizen Card (ACC) holders.

The Cobalt Strike activity cluster's ties to China-nexus threat actors is based on the fact that traffic to the attacker-controlled command-and-control (C2) server ("142.171.183[.]8") extends beyond Pakistani law enforcement to government, academic, telecommunications, and non-governmental entities across South, East, and Southeast Asia, the Middle East, and South America – a victimology profile consistent with China-aligned hackers.

Among those targeted are Tibetan Buddhist organizations in Taiwan, which have long been targeted by China for cyber espionage.

Further examination of the activity aimed at Balochistan Police has uncovered the compromise of the following assets that took place between June 2, 2024, and April 9, 2026 -

• Two network appliances
• Web servers hosting several Balochistan Police web applications associated with the Smart Police Station digitalization initiative
• A Fortinet FortiMail appliance that had served as the agency's primary inbound email gateway

One of the infected applications is the Complaint Management System ("cms.balochistanpolice.gov[.]pk"), which is used for registering, tracking, and resolving citizen complaints. Two distinct variants of an implant called "cms_plugin.exe" have been uploaded to the site in connection with the operation -

• A Rust stager that's designed to download an additional payload from "193.42.25[.]65" and execute it. The exact nature of the next stage is unknown, but the samples display a message "Update Complete! Please refresh the page" upon execution, mimicking a CMS portal update.
• A .NET executable that masquerades as "360Safe.exe," a legitimate binary used by Qihoo 360 Total Security, to reflectively load an assembly implementing an AsyncRAT client.

The activity is notable because it has drawn both a "partner and an adversary of Pakistan" to the same victim for intelligence gathering, likely fueled by geopolitical motives.

"When multiple cyberespionage actors operate against law enforcement institutions of a single state, the convergence itself is a signal of target value," Milenkoski explained. "What draws them is a particular kind of institution: one that holds the government’s internal security picture, what it knows about the threats inside its borders, and how it acts against them."

"The compromise of the Complaint Management System web application adds a second dimension to the activity against Balochistan Police, extending the threat actor's reach beyond the initially compromised environment. By hosting implants in a portal used by both citizens and law enforcement personnel, the threat actor turned a tool built to make policing in Pakistan more accessible and accountable to the public into a malware delivery mechanism."

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

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