Silent Lynx Exploits WinRAR Flaw to Deploy Reverse Shell in CIS Government Attacks

The threat actor known as Silent Lynx has been attributed to a fresh set of attacks targeting government organizations across the Commonwealth of Independent States (CIS).

The activity, observed from June 2025 through August 2026, involves four different infection chains that make use of macro-enabled documents, PS2EXE downloaders, GitHub-hosted PowerShell, and crafted WinRAR archives exploiting CVE-2025-8088.

The attacks lead to the deployment of custom reverse shells like FoalShell, Chvost, Laplas, and PickleShell that facilitate interactive remote access to compromised hosts, according to Cisco Talos and Recorded Future Insikt Group, which are tracking the campaign under the monikers UAT-6275 and TAG-193.

"UAT-6275's targeting is concentrated in Central Asia, and the wider CIS region," security researcher Ashley Shen said. "Across the reviewed campaigns, observed victims and lure themes span nine countries: Kazakhstan, Kyrgyzstan, Tajikistan, Turkmenistan, Uzbekistan, Armenia, Azerbaijan, Russia, and Belarus."

Silent Lynx was first publicly documented by Seqrite Labs in early 2025, highlighting the threat actor's attacks on embassies, lawyers, government-backed banks, and think tanks across Kyrgyzstan and Turkmenistan.

It's assessed to be a Kazakhstan-nexus threat actor active since at least 2020, sharing overlaps with other clusters codenamed YoroTrooper (aka Comrade Saiga, ShadowSilk, and SturgeonPhisher), ShadowSilk, Cavalry Werewolf, and Tomiris.

It's suspected that both UAT-6275 and YoroTrooper are part of the same broader activity cluster, although no direct indicator or toolset overlap has been observed between the two.

Earlier this year, VMRay disclosed that a threat cluster it tracks as Hydra Saiga compromised at least 34 organizations across 8 countries since December 2024, with reconnaissance efforts extending to over 200 additional targets across the world.

It's worth noting that both Comrade Saiga and Hydra Saiga refer to the same threat actor. The "hydra" prefix in the tracking alias is a reference to the adversary's heavy focus on breaching infrastructure linked specifically to water resources in Central Asia using a mix of custom implants written in Rust, Go, and Python and Living-off-the-Land techniques.

Attack chains mounted by the threat actor involve the use of spear-phishing emails containing diplomatic relations, international trade, energy, and aviation-themed decoy documents. No less than eight campaigns have been identified across the region between January 2025 and May 2026.

The phishing emails are sent from compromised government accounts and make use of official-looking documents to lend the social engineering attack a veneer of credibility. "Identified lures included a diplomatic letter addressed to Armenia’s Ministry of Foreign Affairs, a Turkmenistan airspace application form, and a business proposal concerning Russia’s Orsk Oil Refinery," Recorded Future said.

What's more, three publicly accessible staging directories linked to the threat actor have been found to host Linux-compatible tooling and a publicly available proof-of-concept exploit for CVE-2025-25257, an SQL injection flaw in Fortinet FortiWeb, suggesting a possible expansion of the threat actor's operational capabilities.

Infection sequences have been found to employ four different pathways -

• June 2025 - Using macro-enabled Word documents to download and run a second-stage binary.
• July 2025 - Using downloaders built with PS2EXE, a tool that packages PowerShell scripts as Windows executables, to fetch reverse-shell payloads and create scheduled tasks for persistence.
• October 2025 - Using a malicious shortcut (LNK) within a RAR archive to launch PowerShell responsible for retrieving and executing a GitHub-hosted script that provides remote shell access. Subsequent iterations also download PickleShell and stage it in the Windows Startup folder so that it's automatically launched every time a user logs in to the system.
• April 2026 - Using a RAR archive that exploits a WinRAR flaw (CVE-2025-8088) to drop PickleShell in the Windows Startup folder.

The April 2026 infection chain marks the first time UAT-6275 has weaponized a security flaw as part of its malware delivery methods.

"UAT-6275's sustained activity and adoption of new delivery techniques suggest the group will continue pursuing access to government organizations across Central Asia and the CIS," Talos said. "Its interest in environmental agencies, economic ministries, and energy infrastructure reflects the intelligence value of regional diplomacy and resource management."

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

Help TDS Linked to Hotejka as 20,000+ Cloudflare Pages Domains Host Tech Support Scams

A long-running Traffic Distribution System (TDS) known as Help TDS to a Russian-language affiliate program called Hotejka, which appears to be a rebrand of a traffic monetization operation dubbed ROI777.

Help TDS is assessed to be active since at least 2017, offering PHP code templates to partners and affiliates that are installed into compromised websites with an aim to direct unsuspecting users to tech support scams. These scams make use of full-screen browser manipulation and exit prevention techniques to serve bogus Microsoft Windows security alert screens instructing victims to contact a Windows Support number to address the problem.

"Help TDS delivers tech support scams (TSSs) that direct users to call centers, where social engineering is used to convince them to install remote desktop tools," Infoblox said in a report shared with The Hacker News. "It's not simple credit card fraud: it's remote access, living-off-the-land malware operations. Once in, the threat actor can exploit the victim time and again."

Help TDS's evolution was documented by GoDaddy in August 2025, highlighting the threat actor's use of a malicious WordPress plugin named "woocommerce_inputs" on thousands of websites to steal WordPress user credentials and facilitate the malicious redirections by fetching the URLs from its command-and-control (C2) servers. The plugin, or alternatively a custom HTML block, is injected into the sites by Hotejka's affiliates.

Historical tracking of malicious redirect chains has also uncovered that Help TDS has routinely handed off traffic directly to VexTrio Viper, a cybercrime operator that runs an affiliate program to enable scams, riskware, spyware, adware, and pornographic content.

The latest findings connect the TDS to Hotejka, which, in turn, is suspected to be a successor to ROI777, an entity that was exposed by Guardicore Labs (now part of Akamai) in June 2018 in connection with a traffic manipulation and cryptocurrency mining campaign codenamed Operation Prowli.

The activity involved the compromise of vulnerable servers to deploy a malware named r2r2 and then leverage them to mine cryptocurrency. In tandem, WordPress sites and servers running other content management systems (CMS) were exploited for traffic monetization fraud.

"Traffic monetizers, such as ROI777, buy traffic from 'website operators' such as the Prowli attackers and redirect it to domains on demand," Guardicore Labs noted at the time. "Website 'operators' earn money per traffic sent through roi777. The destination domains frequently host different scams, such as fake services, malicious browser extensions and more."

The rebrand is believed to be driven by the leak of data obtained from ROI777's servers in March 2018, around when it was operating Disposable TDS, a precursor to Help TDS. The published details included Telegram identities of its users and details of multiple campaigns.

The connection between Hotejka and ROI77 doesn't end there, for GoDaddy also found that "roi777[.]com" is one of the historical C2 domains used between 2018 and 2020 to fetch the redirect domains.

"[Hotejka's] affiliates range from spam operators to website compromisers," Infoblox said. "Potential victims are redirected into the TDS from these affiliates via special URLs provided by Hotejka. The TDS then evaluates the user via browser fingerprinting and location to determine the course of action."

A TDS functions akin to a relay, intercepting internet traffic from compromised websites, malicious ads, social media posts, or SEO spam, analyzing the visitor, filter traffic based on predefined criteria (e.g., geographic location, device metadata, IP reputation, and headless browsers), and dynamically route them to scams, browser lockers, or malware drops.

"Help TDS and its precursors are the routing decision infrastructure for a small affiliate program," Infoblox explained. "Other threat actors, for example ones who have compromised websites, send potential victim traffic to the TDS through specially crafted URLs."

The TDS is believed to be implemented on Keitaro, an advertising performance tracking platform that's known to be abused by various threat actors. Some of the initial Help TDS lures prompt users of an impending Windows update, followed by a warning that the machine has been disabled by Microsoft, tells them not to restart the computer, and that a "computer lock" has been put in place to block illegal activity.

The scareware prompt is designed to persuade the victim to contact the Microsoft Technical Support team. Should the victim make the phone call, the threat actor on the other end instructs them to download and install a free remote desktop tool like Ultraviewer to gain complete control of the infected machine.

The fingerprinting step determines whether to route the user to either the tech support scam or to another affiliate marketing platform, which then evaluates the device again and resells the traffic. These pathways lead to scam landing pages with fake CAPTCHA checks to enroll the victim's browser to push-notification spam.

"Historical DNS records, loyal use of other affiliate advertising platforms over the years, and consistent command-and-control (C2) mechanisms give us a high degree of confidence that ROI777 and Hotejka are one and the same," Infoblox said.

Messages posted by Hotejka on their Telegram channel (@hotejka_hot) demonstrate their criminal intent by advertising forced browser extension installations and tech support landing pages that are "very difficult to exit." In one post dated July 17, the operator claimed a "small call center in Germany will handle 50-100 calls per day."

Since April 2026, the scams are run on free Cloudflare Pages sites (*.pages[.]dev), with the threat actor creating roughly 300 disposable pages per day. Over 20,000 such domains have been detected since then. In recent years, Hotejka has also been observed using different aliases on forums like CrackingX, seeking traffic from email spam and access to WordPress admin panels for prices starting at $100.

In all, about 20 different affiliates, including Balada Injector, Detour Dog, and DollyWay, send traffic to Help TDS. These operations are known to heavily target WordPress sites to redirect victims to scams and malware.

"Hotejka/ROI777 has been loyal to the two affiliate platforms since 2017, and we believe that loyalty has paid handsomely," Infoblox said. "Using DNS volumes observed over the past 8 years, our ability to use affiliate IDs to track traffic over time, and commonly cited payout figures for affiliate advertising in general, we suspect that the two European programs have paid them at least a few million dollars (USD)."

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

NGINX Fixes 5 Flaws, Including Possible RCE and a TLS Bug That May Skip Client-Cert Checks

NGINX released versions 1.30.6 and 1.31.7 on October 14 to fix five vulnerabilities, one of them present in every release since May 2005.

There are three memory bugs that F5, the company behind NGINX, says could crash a worker process or possibly let an attacker run code, and each requires a specific configuration to exploit.

A fourth lets an attacker forge a TLS session that could get past client-certificate checks, though F5 calls the forgery non-deterministic and beyond the attacker's control. The fifth lets an HTTP/3 client slip extra bytes into a request that NGINX passes on to a backend.

None of the five was in CISA's Known Exploited Vulnerabilities catalog as of October 15, and neither NGINX nor F5 reports attacks. NGINX rates all five medium. F5 scores the three memory bugs 9.2, Critical, on CVSS v4.0, the TLS flaw 8.3, and the HTTP/3 flaw 6.9.

Which Configurations Are Exposed

Every one of the five needs a directive you added: an alias with a rewrite, a regex map, AIO with SSI, a shared TLS session cache, or HTTP/3. NGINX's own documentation recommends the shared session cache and request buffering; the other condition for the HTTP/3 flaw is on by default.

The TLS flaw sits in the automatic rotation of session ticket keys. Session tickets let a client resume a TLS session without a full handshake, and since version 1.23.2, from October 2022, a shared session cache makes NGINX generate and rotate the ticket keys itself unless you load keys from a file.

Each worker process keeps a copy of three key slots. Rotation copied only two, so the third slot held whatever was in memory before, and a ticket naming that slot could be verified and decrypted with that uninitialized key material, "allowing a forged session," the fix commit says.

F5 says the forgery works "in a non-deterministic manner that is beyond the attacker's control," and that an attacker could use it to bypass verification of client certificates. The exposed setting, ssl_session_cache shared:SSL:10m, is the one NGINX's documentation uses in its example configuration. NGINX fixed a session-reuse flaw with the same consequence, CVE-2025-23419, in February 2025.

The conditions and workarounds below are NGINX's and F5's. The version ranges are from NGINX's advisories page.

Flaw	What it allows	Configuration that exposes you	Affected versions	If you cannot upgrade (F5)
CVE-2026-15176	Heap overflow in a worker process: crash, possibly code execution	A location with alias, a rewrite that changes the URI, and anything that reads $request_filename (return, set, if, add_header or the access-log format)	0.1.29 to 1.31.6	Do not use alias in that location. Do not use $request_filename.
CVE-2026-93479	Heap overflow in a worker process: crash, possibly code execution	A regex map whose captures are referenced by root or log_format before the map's output variable	1.30.0 to 1.30.5 and 1.31.2 to 1.31.6	Use named captures, and use them only inside the block with the regex match.
CVE-2026-97205	Use-after-free in a worker process: crash, memory corruption, possibly code execution	aio enabled and an SSI page with include virtual commands, in some configurations	0.8.11 to 1.31.6	Turn aio off, or do not serve SSI pages.
CVE-2026-95101	Extra bytes injected into a proxied request, or a body past client_max_body_size	HTTP/3 with proxy_request_buffering on , the default	1.25.0 to 1.31.6	Set proxy_request_buffering off.
CVE-2026-97629	A forged TLS session that could bypass client-certificate verification (non-deterministic and beyond the attacker's control, F5 says)	ssl_session_cache shared:... without ssl_session_ticket_key , which turns on automatic key rotation	1.23.2 to 1.31.6	Remove the shared cache directive, or load keys from a file with ssl_session_ticket_key. Servers with ssl_session_tickets off are not affected.

One Flaw Traces to July's Fix

The map flaw, CVE-2026-93479, is in the string-handling code that NGINX patched on July 15 for CVE-2026-42533, a heap overflow F5 scored 9.2 that is reached through a regex map's captures.

The new overflow became possible after a change in that July release, according to the fix commit. A July patch added protection against overrunning a buffer, but data could still spill into a reserved area, and a second July patch then sized the final string from that spilled length, so the string could outgrow its buffer.

The commit puts limits on it. The overflow is at most the size of the reserved area on the document-root path, and a single null byte on the access-log path.

F5's advisory and NGINX's advisories page list 1.30.0 and 1.31.2 as the earliest affected versions, which come before the July change. A server patched in July is inside the affected range either way.

F5's July workaround had already been questioned. Researcher Stan Shaw told The Hacker News in July that switching to named captures left a narrower path open, and that upgrading was "the only complete fix."

The fix commits for the alias, AIO and HTTP/3 flaws describe the other three bugs. The alias flaw opens in the moment after a rewrite changes a request's URI and before NGINX picks the next location. If anything reads $request_filename in that window, and the location's prefix is longer than the rewritten URI, mapping the URI to a file path overflows a buffer.

The AIO flaw is a counter. Each pending asynchronous operation on a request adds one to an 8-bit field with no check, so 256 pending operations wrap it to zero and the request can be freed while those operations still point at its memory. NGINX names SSI pages with include virtual commands, which can run their included requests in parallel, as the trigger.

The HTTP/3 flaw came from one parser field doing two jobs: holding the remaining length of an unknown frame being skipped, and the number of DATA bytes to pass on as request body. When an unknown frame was split across two reads, the leftover count was treated as body and sent to the backend, outside the client_max_body_size check.

What to Do

Upgrade to 1.30.6 on the stable branch or 1.31.7 on mainline. The stable release contains only fixes. NGINX publishes fixes for those two branches only, so older branches such as 1.28 stay inside the affected ranges, and a distribution package is fixed only if your distribution has backported the patches.

NGINX Plus customers, and users of F5's Ingress Controller, Gateway Fabric, Instance Manager and WAF products, should check F5's advisories, which list affected builds and, for several products, no fixed build as of October 15.

If you cannot upgrade yet, the table above has F5's workaround for each flaw. To see which paths your server has enabled, print the running configuration with nginx -T and search it for alias beside a rewrite, a regex map used by root or log_format, aio together with ssi, listen lines with quic, and ssl_session_cache shared without ssl_session_ticket_key.

The rewrite-module overflow NGINX patched in May, CVE-2026-42945, was being exploited within days of disclosure, VulnCheck found. This is NGINX's eighth security release of 2026.

F5 credits Matt Suiche of Tolmo and Mateusz Gierblinski with the map flaw, Hansol Lee of GOTROOT with the HTTP/3 flaw, PhiNode Labs with the TLS flaw, and a researcher it names as Cyberlanc3r with the AIO flaw.

F5 found the alias flaw itself. NGINX also released njs 1.0.2 the same day, fixing two medium-severity XML-handling flaws in its JavaScript module, CVE-2026-101025 and CVE-2026-101019.

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

Next.js Ships Out-of-Band Patch for Two Critical RCE Flaws in Caching and SVG Processing

Next.js released an out-of-band security update on October 14 that fixes two critical flaws allowing unauthenticated remote code execution, along with a high-severity denial-of-service flaw.

One code-execution flaw is in React Server Components, and the other in librsvg, the open-source library Next.js uses through the sharp package to handle SVG images.

The fixes are in Next.js 16.4.1 and 15.5.28, the current Active and Maintenance long-term support (LTS) releases.

What Was Fixed

The update covers three separate issues. Vercel, which develops Next.js, rated both code-execution flaws critical, each with a CVSS score of 9.5. The table lists the versions each issue affects and the version that fixes it.

Issue	Affected versions	Fixed in	Who is exposed
Code execution through use cache ( GHSA-673q-mjm6-r5xr )	16.0.0 through 16.4.0	16.4.1	App Router apps with Cache Components enabled, where a use cache function returns more than one typed array
Code execution through SVG images (CVE-2026-96889, GHSA-2464-fhr4-w9xw )	10.0.0 through 15.5.27, and 16.0.0 through 16.4.0	16.4.1, or 15.5.28 with sharp 0.35.5 or later	Apps that pass attacker-supplied SVG files to sharp on glibc-based Linux
Denial of service through Server Actions ( GHSA-p3m5-59mp-jv5r )	13.0.0 through 15.5.27, and 16.0.0 through 16.4.0	15.5.28, 16.4.1	App Router apps with at least one Server Action

Who Is Affected

The first code-execution flaw is in React Server Components, the React feature that runs user-interface components on the server. React's advisory covers three packages, react-server-dom-webpack, react-server-dom-parcel, and react-server-dom-turbopack, in versions 19.0.0 through 19.3.0. It describes the flaw as affecting "extremely rare cases where responses transport multiple typed arrays and an attacker-controlled value."

In a Next.js app, the trigger is a use cache function that returns more than one typed array, so only version 16 apps that enable Cache Components, the feature behind use cache, are exposed. Vercel says to upgrade even if your app has no such function.

The second flaw is a memory bug in librsvg, the library that renders SVG images, which Next.js reaches through the bundled sharp package. Code execution is possible when Next.js runs on glibc-based Linux, according to the advisory.

By default, Next.js does not optimize SVG files. Serving them through the image optimizer requires turning on a setting called dangerouslyAllowSVG. The same library also renders images for next/og, the feature that builds social-preview images, when that feature runs on the Node.js runtime.

The third flaw is a denial-of-service issue. In App Router apps that define at least one Server Action, crafted requests can push one server process to full CPU use and stop it from handling other requests. Apps on the Pages Router, or with no Server Actions, are not affected.

Exposure can differ by host. Netlify said its platform does not run the image-optimizer code path and that the flaws have limited impact on its setup, while still recommending the upgrade.

What to Do

Upgrade to Next.js 16.4.1 if you run version 16, or 15.5.28 if you run version 15, then rebuild and redeploy.

Vercel's advisory says upgrading Next.js makes package managers supply the fixed sharp automatically. On version 16 that holds, because 16.4.1 requires sharp 0.35.5.

On version 15 it may not. 15.5.28 still accepts the older, affected sharp 0.34.x, and upgrading over an existing install can leave that version in place. Check with npm ls sharp and update sharp to 0.35.5 or later if it is older.

If you cannot upgrade Next.js right away, the image flaw has an interim option: make sure sharp is 0.35.5 or later, or block SVG rendering in sharp with sharp.block({ operation: ["VipsForeignLoadSvg"] }), as the sharp advisory describes. The use cache and Server Actions flaws have no workaround, and only the upgrade closes them.

As of October 15, the use cache and Server Actions advisories had no CVE and did not appear in the npm advisory feed that npm audit uses, so dependency scanners may not warn you about them. The image flaw does surface, through sharp's own advisory.

Why the Image Flaw Keeps Returning

This is the third time since August that image processing in Next.js has produced a code-execution flaw. In August, a bug in libheif, reached through sharp, allowed code execution when the optimizer handled a crafted AVIF image. In September, a flaw in next/og let attacker-controlled text change the SVG it generated.

Next.js did not change its own image code this time. 16.4.1 ships the same optimizer as 16.4.0 and fixes the image flaw by raising the bundled sharp to 0.35.5, which carries a patched librsvg (2.63.2).

The librsvg bug, CVE-2026-96889, was made public on September 23 and fixed in sharp on September 27. Red Hat scored it 7.8 and said exploiting it needs user interaction, such as opening a malicious file. Vercel rated the Next.js exposure 9.5 and reachable over the network.

The researcher who reported the librsvg bug, Rafael B. Dias, says it is the weakness behind September's next/og flaw. A working exploit for that earlier flaw, built for one specific server setup, has since been published.

sharp's maintainer also warns that whether the flaw ends in code execution or only a crash can come down to the server's Node.js build, because the official Node.js binaries are not hardened against this kind of memory attack.

Not the Same as React2Shell

The React Server Components flaw sits in the same three packages as React2Shell, the maximum-severity flaw disclosed in December 2025 that attackers exploited at scale. This one is far narrower. React describes it as affecting "extremely rare cases where responses transport multiple typed arrays and an attacker-controlled value."

As of October 15, there are no public reports that any of the three flaws fixed on October 14 has been used in attacks.

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

Why AI Confidence Is Not Validation

AI is already part of digital forensics and incident response work, with or without a policy in place to govern it. The issue is that these tools are growing more confident in their own output faster than practitioners are developing reliable ways to verify it. Without governance models and validation standards in place, that gap compounds and rarely stays contained to a workstation: an unverified finding can end up in a forensic report, a deposition, or in court.

At SANS, we created two new AI frameworks this year to help address this challenge: the Digital Forensics & AI Investigations Framework, which we mapped to the trusted standards established by the Scientific Working Group on Digital Evidence (SWGDE), and the Incident Response & AI Investigations Framework, which we mapped to the NIST Cybersecurity Framework 2.0. Both frameworks rest on the same principle: AI can accelerate investigative work, but the human examiner remains the final authority at every phase.

Where Validation Cannot Be Delegated

In digital forensics, validating an AI finding starts at the source file. A tool that doesn't show its reasoning has already produced an unreliable result, regardless of the confidence score attached to it. A tool that cites the specific file it parsed — for example, a claim that browser history came from Chrome's own database — gives an examiner somewhere to start. The claim is plausible at face value, but it still has to be confirmed independently before anyone treats it as fact.

I think of a high-confidence AI output the way I'd think of a third grader insisting the homework is finished. Saying it's done isn't the same as it being done correctly, and no amount of confidence changes that. The only way to know is to verify it, the way a parent checks the homework instead of taking their child's word for it alone.

The mistake I see often in the field is treating AI as a single source of truth. Practitioner forums are full of the same exchange: Someone scans a file, a detector reports it as AI-generated, and that becomes the finding. The claim has no named source and no reasoning behind it, and an examiner without foundational skills has no way to catch that.

What the Record Has to Show

Documenting what produced a finding matters as much as checking it. Plenty of examiners say they don't use AI, while machine learning has been running skin detection, facial similarity, and image categorization inside their forensic tools for years, generating the confidence scores they rely on. Naming the tool is sufficient when AI is built into a forensic product, since opposing experts can research the integration themselves. For a general-purpose model, the exact version needs to be on record.

Version history matters more than practitioners expect because casework and AI capability move on different timelines. I worked a case where the tool that would have helped with the log files didn't exist at the time of collection. By the time I testified two years later, the technology had advanced well beyond what was available during the investigation, which is exactly the kind of gap opposing counsel can use against you without a clear record of what the technology could do at the time.

One Policy Cannot Govern Both Disciplines

Digital Forensics and Incident Response carry different risk tolerances, and a single AI policy written for one will fail the other. Incident response has more latitude by design, because responders aren't scrutinized on every single bit and byte, and the organization needs to know what happened quickly. AI genuinely helps there, in detection and in surfacing activity a human might not readily see. Forensic examiners operate under the opposite pressure, since every source file requires validation, which is why many expect AI to add work rather than remove it. Both instincts are correct for the job in front of them, which is why the two frameworks exist as separate documents instead of one shared policy.

AI capability is moving faster than human oversight can keep up with. Offensively, AI is excelling; defensively, security teams remain more cautious and slow. Closing that gap during a live incident depends on how much an organization trusts its own tooling. If a team built and validated the AI making containment or triage recommendations, then a human in the loop, monitoring and intervening rather than approving every step, is workable. Requiring sign-off on every individual action during an active incident overwhelms an analyst quickly, exactly when speed matters most.

The Real Variable Is the Practitioner

Every phase of both frameworks returns to one constraint. AI should never take an action that can't be undone. Evidence collection illustrates why: An investigator gets one opportunity at a sound acquisition, and a flawed one forecloses analysis entirely, no matter how skilled the analyst who comes after. Hash verification can be automated safely. Deciding how to pull cloud data, approach a scene, or deploy tools to capture lateral movement across other systems cannot be, because none of those decisions can be walked back. Legal authority follows the same logic. AI flagging that a subject has a linked cloud account is useful; AI collecting that data on its own crosses a boundary an examiner cannot undo, and some forensic tools can cross it on their own if configured to.

That's the real argument behind both frameworks' operational use cases and their course mappings by phase. Whether an investigation holds up depends on the practitioner running the AI. An examiner who understands the underlying discipline and uses AI on top of it becomes more valuable to their organization. An inexperienced person using AI is the landmine, and it's leadership's job to assess that risk honestly.

Building a Defensible AI Practice in DFIR

Frameworks like these are as dynamic as the technology they address, and they are only effective if practitioners have the most current information and the underlying skills to apply it, knowing where artifacts live before a tool tells you, understanding what a sound acquisition actually requires, and recognizing a wrong answer when a model produces one. SANS courses including FOR498: Digital Acquisition and Rapid Triage, FOR508: Advanced Incident Response, Threat Hunting, and Digital Forensics, and FOR608: Enterprise-Class Incident Response & Threat Hunting build that foundation across the phases both frameworks cover.

Join us at SANS Cyber Defense Initiative 2026 in December to attend FOR508: Advanced Incident Response, Threat Hunting, and Digital Forensics in person, taught by Carlos Cajigas.

Learn more about SANS’s DFIR training offerings here.

Note: This article has been expertly written and contributed by Heather Barnhart, SANS VP of Curriculum.

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

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

India Mandates Registered Caller Name Display on 4G and Newer Networks From November 1

The Indian government has directed telecom service providers (TSPs) in the country to mandatorily display callers' registered names along with their numbers for incoming calls starting November 1, 2026, in an effort to help people identify calls from unknown numbers and tackle spam or fraudulent calls.

To that end, the Department of Telecommunications has issued a circular urging service providers to implement the Calling Name Presentation (CNAP) service.

"At the time when a call is incoming, the calling name presentation service presents the calling name identity of the calling user on the user terminal of the called user," according to a circular issued by the Indian Ministry of Communications dated October 13, 2026.

"Calling name identity is the name of the calling user as recorded in subscriber data record of the originating telecommunication service provider and such identity is included in the calling line identification of such user."

The caller ID system is mainly targeted at wireless terrestrial networks established using 4G and higher generation technologies. The circular noted that a CNAP rollout for 2G and 3G networks, as well as public switched telephone networks (PSTNs), will be taken up separately after examination.

Under the new guidelines, every time a user receives a call, the first field will display the caller's number, as is the existing practice. The second field will contain the name of the calling user in the following order of preference -

• If the number is already saved in the callee's contacts, the corresponding name is displayed.
• If the number is not saved, the calling name identity as stored in the telecom operator's subscriber database will be displayed for domestic calls. The label "International Call" will be presented for calls originating from outside India.

To meet this requirement, every originating TSP is required to establish and maintain a database mapping subscribers' names to their numbers. The operator on the receiving end of the call will query this database to retrieve the calling name identity and present it to the user.

Telecom operators are also expected to provide a Calling Line Identification Restriction (CLIR) facility, as part of which users can choose to hide their caller identity when making calls.

Furthermore, the Ministry of Communications is urging TSPs to adopt a secure-by-design approach when implementing the system and ensure the security of communications by -

• Enforcing that the calling name identity is not retained upon completion of the incoming call
• Maintaining the quality of service in accordance with applicable laws
• Provisioning the necessary database, network, and connectivity infrastructure to support efficient processing of calling name identity queries

Users with business connections or bulk connections can opt for a "preferred name" that replaces the calling name identity. The preferred name has to be one of the following -

• A trade mark registered in the name of the user as per the records of the Trade Marks Registry under the Controller General of Patents, Designs and Trade Marks, Department for Promotion of Industry and Internal Trade, Ministry of Commerce and Industry
• A trade name of the user as registered on the Goods and Services Tax portal

"For new connections, the preferred name of the user shall be recorded in both the customer application form and subscriber data record and document(s) evidencing proof that the user is registered under such name shall be presented in original to the originating TSP and true copies thereof shall be attached to the customer application form by the originating TSP," according to the circular.

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

Introducing ShapeBlue Topology Studio – See It. Draw It.

Today we are happy to announce the release of ShapeBlue Topology Studio. ShapeBlue Topology Studio is an infrastructure visualisation and network design tool for Apache CloudStack, available to all ShapeBlue customers. Built on 15 years of ShapeBlue’s collective CloudStack knowledge, it offers two modes: Visualise, which provides a live, read-only map of your existing cloud infrastructure, and Design, which lets you create Guest Network designs that follow CloudStack’s rules and export them as Terraform or CloudMonkey scripts.

Through our work designing, deploying and supporting CloudStack environments, our teams have encountered two recurring problems that shaped the development of Topology Studio.

The first is seeing what you already have. CloudStack holds information about the whole deployment: Zones, Pods, Clusters, Hosts, Storage, Physical Networks and System VMs, plus the Guest Networks, Routers and VMs running on top of them. But you only get that information one screen or one API call at a time. To answer simple questions like “which Host runs this VM?” or “which Router serves this Network?”, you have to rebuild the picture in your head.

The second is designing what comes next. A new Guest Network usually starts as a sketch, which someone then turns into automation by hand. Generic diagram tools accept any shape you draw, but not every shape works in CloudStack, so mistakes may only become apparent at build time.

The ShapeBlue approach follows a simple principle: everything CloudStack knows, drawn for you; everything you want to build, drawn by you. Visualise connects the infrastructure into one view, from the Zone down to each Host and the VMs on it. Design brings CloudStack’s rules into the drawing process, helping operators turn a network sketch into a deployable configuration.

ShapeBlue’s shared knowledge shaped how these components work together: how CloudStack objects appear, how they fit inside each other, and how infrastructure and Guest Networks are presented. Through the team’s work on the concept, proof of concept and product development, we have translated that experience into a practical tool for cloud operators.

Today we’re releasing ShapeBlue Topology Studio v0.1.0, the newest tool on the ShapeBlue Appliance, to help cloud operators understand what they have and design what comes next. By bringing infrastructure and its relationships into one live view, it helps operators see where workloads run and how resources connect, spending less time piecing information together across multiple screens or API calls.

 

Visualise: see what you’re actually running

 

Visualise connects to a live CloudStack environment and draws a map you can drill into. It’s read-only by design: the code checks every CloudStack call against a list/query allowlist before sending it, so safety doesn’t depend on the permissions of the account you connect. It has two views that follow how CloudStack itself is organised:

• Infra view draws the physical architecture top down: Zones, Pods, Clusters, Hosts, Primary and Secondary Storage, Physical Networks, Traffic Types, VLAN IP Ranges and System VMs, with the virtual elements running on them.

• Network view shows each Zone’s Guest Networks: VPCs and Tiers, Isolated, Shared and L2 Networks, Routers, Public IPs with their Port Forwarding, Static NAT and Load Balancer Rules, VM Groups and Site-to-Site VPN.

 

Objects load when you expand them, so large deployments stay fast. Search jumps straight to a match, and right-click takes you between related objects, for example from a VM to its Network and on to its Router, or from a System VM to its Host. A side panel lists every CloudStack field for the selected object. The canvas starts locked, so you can’t rearrange a live map by accident.

 

Design: draw guest networks that follow CloudStack’s rules

 

Design is where a new Guest Network starts. The canvas checks CloudStack’s rules while you work: the palette only shows what’s valid at that point, and if you drop something in the wrong place, Topology Studio rejects it and tells you why. That way you catch mistakes while drawing instead of when you build.

You can design Networks and VPC Tiers, VMs and VM Groups, Public IPs with Load Balancing, Port Forwarding and Static NAT, Network ACLs, Firewall and Egress Rules, VPC Private Gateways with Static Routes, Affinity Groups, Site-to-Site VPN and AutoScale. Dropdowns are filled with real data from your CloudStack environment instead of raw IDs.

You don’t have to start from scratch. You can load an existing Network in three ways: live from CloudStack, from a Terraform file you exported earlier, or from a saved design.

 

Export: take it away as Terraform or CloudMonkey

Any Guest Network you design or import can be exported as:

• Terraform: a zip with tf, providers.tf, variables.tf and terraform.tfvars
• CloudMonkey: a single runnable .sh script

For resources that already exist, the Terraform output includes import {} blocks. Apply it against the same environment and Terraform adopts those resources instead of creating duplicates, so a Network built by hand can be brought under Terraform. Choose Exact copy to keep this environment’s values, or Template to leave them out so one design can be reused elsewhere.

Export only creates files, and Topology Studio never makes changes in CloudStack. Running the output is a separate step you take yourself.

 

 

What to know about this first release

• Design covers the Guest Network layer. It doesn’t author physical infrastructure.
• You can scope a design to an existing Project, but you can’t create new Domains, Accounts or Projects yet.
• Terraform export supports Project scoping only. CloudMonkey export supports Domain and Account scoping too.
• The CloudMonkey command for Internal Load Balancers is a best-effort placeholder in this release, flagged in both the script and the docs. Every other rule type has been tested against a real CloudStack lab.
• Light theme only. Undo and Redo use buttons and are limited to 100 steps.
• Tested with CloudStack 4.22.1.0. Topology Studio relies on documented API fields and the Terraform provider schema, not a fixed version check, so nearby versions should work. No supported version range has been set yet.

 

How to get started with ShapeBlue Topology Studio

Topology Studio is available to all ShapeBlue Customers. To see it on your own deployment, email us at info@shapeblue.com. We’d also like to hear how you use it and what you want in the next release.

The post Introducing ShapeBlue Topology Studio – See It. Draw It. appeared first on ShapeBlue.

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

Langflow's Critical Authenticated RCE Flaw Targeted in 1,423 Honeypot Exploit Attempts

Threat actors are exploiting a critical security flaw in Langflow, according to an alert from Previdian.

Langflow is an open-source platform that allows developers to build artificial intelligence (AI) applications and agentic workflows. In February 2025, DataStax, the parent company of Langflow, was acquired by IBM.

The vulnerability in question is CVE-2026-105740 (CVSS score: 9.9), a case of authenticated remote code execution impacting versions prior to 1.9.0.

"Any authenticated Langflow user can achieve Remote Code Execution (RCE) on the server by adding an MCP server with the 'stdio' transport," reads an advisory released last month.

"The user-supplied command field is passed directly to bash -c "exec {command}" with zero validation, no allowlisting, and no sandboxing. The command executes immediately when the server list is fetched. Additionally, the env field allows arbitrary environment variable injection (e.g., LD_PRELOAD, PATH override)."

The crux of the vulnerability is that Langflow accepts a user-provided command without restricting it to approved executables. This, in turn, can lead to shell execution.

In a hypothetical attack scenario, a bad actor can exploit the flaw in the following fashion -

• Login as a regular, non-admin user.
• Add a malicious MCP server by sending a crafted HTTP POST request to "/api/v2/mcp/servers/{server_name}" with a command field containing a malicious payload (e.g., a reverse shell).
• The server accepts and stores the attacker-supplied "command" without any validation.
• Trigger the flaw by fetching the MCP server list via an HTTP GET "/api/v2/mcp/servers?action_count=true" request, causing the command to execute.
• Achieve code execution.

"Any authenticated Langflow user (including non-admin accounts) can execute arbitrary OS commands on the server with the privileges of the Langflow process," Langflow warned.

Successful exploitation can result in full server compromise, environment variable injection, facilitate lateral movement, and the deployment of a persistent backdoor, as the malicious MCP server configuration persists and re-executes every time the server list is loaded.

"Unlike custom component code which is visible in the flow editor, MCP server configs are stored in project settings and are not visible during normal flow review," Langflow said.

Data from Previdian shows that 1,423 exploitation attempts have been recorded against its honeypot sensors since September 19, 2026, from 27 unique attacker IP addresses located in Belgium, China, Germany, Hong Kong, Japan, Nigeria, the Philippines, Russia, Seychelles, Singapore, South Korea, Taiwan, Tanzania, the U.S., and Vietnam.

The exploitation efforts ramped up starting October 11, 2026, when 333 attempts were registered. As of writing, 66 attempts have been observed on October 15, 2026.

Last month, Langflow also addressed another critical vulnerability (CVE-2026-105697, CVSS score: 9.9) that could also result in operating system command injection through MCP stdio server configuration.

If immediate patching is not an option, it's advised to set LANGFLOW_AUTO_LOGIN=false, avoid exposing Langflow directly to untrusted networks, and grant Langflow accounts to trusted users.

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

AhsayCBS Flaws Exploited to Deploy Web Shells Get New Fixes After Incomplete Patches

Singapore-based Ahsay Backup has released security updates to address two security flaws in AhsayCBS that have been exploited by bad actors to drop web shells and XMRig cryptocurrency miners.

The vulnerabilities in question are CVE-2026-105133 and CVE-2026-105134, which could be chained to sidestep authentication and execute arbitrary commands on affected systems.

In a report published earlier this month, Huntress said it observed threat actors combining the two flaws to achieve unauthenticated remote code execution and deploy web shells and cryptocurrency miners on exposed systems.

Although the vulnerabilities were initially assumed to be addressed in AhsayCBS versions 9.15.2.59 and 10.3.4.0 released in August 2026, the software company has now confirmed that the patches did not completely plug them.

The fixes are available in the following versions -

• AhsayCBS v10.3.4.45 hotfix
• AhsayCBS v9.15.2.70 hotfix

"Given the severity of these risks, we strongly urge you to take immediate action to secure your environment and protect your customer's data," Ahsay said. "After applying the hotfix, please reboot your server."

In an update, Huntress said it has "independently verified that the AhsayCBS 10.3.4.45 hotfix mitigates the initial entry point of this attack chain, which was still susceptible on previous v10 versions."

The active exploitation of the flaws has prompted the U.S. Cybersecurity and Infrastructure Security Agency (CISA) to add them to the Known Exploited Vulnerabilities (KEV) catalog, requiring federal agencies to apply the patches by October 17, 2026.

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

Break the silence: Kazakhstan-nexus UAT-6275 targets CIS government organizations

This research was conducted jointly with Julian-Ferdinand Vögele of Recorded Future’s Insikt Group. Details of the joint research and presentation are available here.

• Cisco Talos identified UAT-6275 (TAG-193 by Recorded Future) activity targeting government organizations across the Commonwealth of Independent States (CIS). Recovered artifacts show additional interest in water resources and energy. This focus is consistent with intelligence collection and may reflect the regional effects of the Russia–Ukraine war. 
• In activity observed from June 2025 through August 2026, Talos identified four infection-chain types that use macro-enabled documents, PS2EXE downloaders, GitHub-hosted PowerShell, and a crafted WinRAR archive exploiting CVE-2025-8088. The recovered payloads include several custom reverse shells that provide interactive remote access. 
• Three publicly accessible staging directories and GitHub repository history exposed payload builds, tool inventories, and changes to command-and-control (C2) infrastructure. These operational security lapses gave us direct visibility into the group's recent activity. 
• The files recovered from the exposed infrastructure suggest preparation for post-compromise operations and potential activity against Linux hosts and internet-facing appliances.  
• Talos assesses with medium confidence that UAT-6275 has a Kazakhstan nexus, based on infrastructure access, language artifacts, sample submissions, working hours analysis, and regional targeting interests.

---

Background 

Cisco Talos and Recorded Future Insikt Group jointly investigated UAT-6275 activity targeting government organizations across the Commonwealth of Independent States (CIS). The investigation uncovered three publicly accessible staging directories and a previously unreported GitHub repository used to host malicious scripts and payloads. These exposed assets provided visibility into the threat actor's malware development, infrastructure changes and preparations for additional intrusion activity. 

Talos tracks this activity as UAT-6275, while Recorded Future tracks it as TAG-193. It overlaps with Silent Lynx (first reported by Seqrite) and sits within a broader set of campaigns connected to YoroTrooper, which we first reported in 2023. Subsequent research on Tomiris (Kaspersky), ShadowSilk (Group-IB), Cavalry Werewolf (BI.ZONE), and Hydra Saiga (VMRay) identified overlapping indicators across these reported clusters. We assess that UAT-6275 and YoroTrooper likely belong to the same broader activity cluster. However, we continue to track them separately because we have not observed direct indicator or toolset overlap between the two.

This post summarizes our joint Virus Bulletin 2026 white paper, “Break the silence: tracking Silent Lynx through exposed infrastructure” which contains the full technical analysis and indicators of compromise (IOCs).

Victimology 

UAT-6275's targeting is concentrated in Central Asia and the wider CIS region. Across the reviewed campaigns, observed victims and lure themes span nine countries: Kazakhstan, Kyrgyzstan, Tajikistan, Turkmenistan, Uzbekistan, Armenia, Azerbaijan, Russia, and Belarus.

Figure 1. Regional targeting.

Government and diplomatic affairs 

UAT-6275 targets government institutions responsible for diplomacy, economic development, agriculture, and environmental management. These organizations hold information that can inform bilateral negotiations, economic planning, and regional security decisions.

Our network flow analysis identified activity involving a Tajik government entity shortly after treaty discussions with Kazakhstan in March 2026 and a Belarusian government entity ahead of a bilateral meeting in April. This timing may indicate an interest in regional diplomatic developments.

The decoy documents we recovered also suggest an interest in diplomatic relations, international trade, and aviation. Examples include a diplomatic letter addressed to Armenia’s Ministry of Foreign Affairs.

Figure 2. Lure document masquerading as a Russian diplomatic congratulatory letter to the Armenian Ministry of Foreign Affairs. 

Water security and resource management 

The group’s interest in regional resources spans environmental management and energy. Talos observed activity involving an Armenian government entity responsible for environmental matters and Uzbekistan’s Smart Forestry initiative, consistent with earlier reporting on Silent Lynx targeting water resource organizations across Central Asia. 

Energy-themed decoys included a cooperation proposal between Turkmenistan’s state oil company, Turkmennebit, and Russia’s Orsk Oil Refinery, used in an August 2025 sample. The refinery supplies petroleum products to Kazakhstan and later shut down after a Ukrainian drone strike in August 2026, with repairs expected to take up to six months. These ties suggest a possible intelligence interest in regional fuel supplies and the war’s implications for Kazakhstan’s energy security.

Figure 3. Decoy impersonating Turkmennebit and proposing cooperation with Orsk Oil Refinery management.

Campaign timeline 

Since Seqrite first reported Silent Lynx in January 2025, we have identified at least eight campaigns across the region through May 2026. These include malware delivery targeting Russia, Turkmenistan, and Uzbekistan; a credential-harvesting site impersonating Azerbaijan’s State Agency for Public Service; and lures referencing the China–Central Asia Summit and Russian energy infrastructure. In 2026, we also observed activity involving government entities in Tajikistan, Armenia, and Belarus, as well as Uzbekistan’s Smart Forestry initiative in May. 

Figure 4. Campaign timeline. 

Infrastructure and malware delivery 

Talos identified three publicly accessible staging directories containing malware and tools of UAT-6275. One sample led to the previously unreported GitHub repository, where the group hosted PowerShell scripts and payloads. Its commit history allowed us to track infrastructure changes and malware development.

The group relies on lightweight reverse shells, including Chvost, Laplas, and PickleShell, to issue commands on compromised systems.

We also recovered Linux-compatible tooling and a publicly available proof-of-concept exploit for FortiWeb CVE-2025-25257 from UAT-6275 infrastructure. These findings suggest interest in expanding the group’s operational capabilities. 

Four infection chains 

UAT-6275 used malicious documents, executable downloaders, and shortcuts to deliver malware, and later incorporated a WinRAR exploit. Talos categorized the recovered samples into four infection chains, A – D, based on how they retrieve and execute their payloads.

Figure 5. First observations of four UAT-6275 infection chains, June 2025 – April 2026.

The first Chain A samples, observed in June 2025, used macro-enabled Word documents to download and execute a second-stage binary. In July 2025, we observed Chain B downloaders built with PS2EXE, a tool that packages PowerShell scripts as standalone Windows executables. These downloaders retrieved reverse-shell payloads and created scheduled tasks for persistence. 

We first observed Chain C in October 2025. A malicious shortcut launches PowerShell to retrieve and execute a GitHub-hosted script that provides remote shell access. Later samples also downloaded PickleShell and placed it in the Windows Startup folder for persistence.

Figure 6. Chain C retrieves a GitHub-hosted PowerShell script; later samples also deploy PickleShell to the Startup folder.

In April 2026, we identified a RAR archive that exploited CVE-2025-8088 in WinRAR to place PickleShell in the Windows Startup folder (Chain D). The payload runs at the next user sign-in. This was the first vulnerability exploit we observed in UAT-6275’s malware delivery.

Figure 7. Chain D exploits CVE-2025-8088 to place PickleShell in the Windows Startup folder for execution at the next sign-in.

Kazakhstan nexus assessment 

Talos assesses with medium confidence that UAT-6275 has a Kazakhstan nexus. Supporting evidence includes Russian-language artifacts, apparent malware-testing submissions from Kazakhstan shortly after compilation, and operator activity consistent with UTC+5 working hours.

Figure 8. Timing of 77 GitHub commits in UTC+3 and UTC+5, with 09:00–18:00 local working hours shaded.

Looking ahead 

UAT-6275’s sustained activity and adoption of new delivery techniques suggest the group will continue pursuing access to government organizations across Central Asia and the CIS. Its interest in environmental agencies, economic ministries, and energy infrastructure reflects the intelligence value of regional diplomacy and resource management. 

Defenders in these sectors should monitor unexpected PowerShell activity and payload downloads from public services such as GitHub, alongside scheduled tasks and Startup-folder changes. Keeping archive utilities patched can help reduce exposure to the exploit-assisted delivery observed in this campaign. 

For further details on this research and our accompanying presentation, see “Break the Silence: Tracking Silent Lynx Through Exposed Infrastructure” on Virus Bulletin’s website, as well as Recorded Future’s related blog post.

Coverage 

The following ClamAV signatures detect and block this threat: 

• Win.Backdoor.PickleShell-10060602-0 
• Win.Backdoor.Chvost-10060603-0 
• Win.Malware.Generic-10060604-0 
• Win.Malware.LAPLAS-10060605-0 
• Win.Malware.LAPLAS-10060606-0 
• Win.Proxy.Generic-10060628-0 

The following Snort rules cover this threat: 

• Snort 2: 1:11192, 1:15306, 1:46983, 1:47398 
• Snort 3: 1:46983, 4:16 

IOCs

IOCs for this research can be found at our GitHub repository here. 

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

ShapeBlue Migrate v0.6.0: OVERLAY Migrations No Longer Require Powering Off the VMware VMs

ShapeBlue Migrate v0.6.0 is now available to all ShapeBlue customers who need to migrate from VMware to Apache CloudStack! The key improvement in the new version is that OVERLAY no longer needs the VMware VM powered off. The VM keeps running while the migration prepares, then waits for its cutover policy, the same way Changed Block Tracking (CBT) works. That gives Migrate two warm migration methods instead of one. OVERLAY can now also work from VMFS source storage, and it consolidates its disks automatically after the move.

 

Download the Product Brief

 

OVERLAY Is Now a Warm Migration Method

OVERLAY is the fastest of Migrate’s four transfer methods. It creates a qcow2 overlay on top of the source VMDK and converts in place, so no disk data crosses the network. Until now, the catch was that the source VM had to be powered off before the migration started, so downtime began at the start of the migration instead of at the cutover.

In v0.6.0 the source VM stays up. The migration prepares while the VM runs, then waits in Awaiting Cutover until its cutover policy fires. Downtime happens only at the cutover, and you get OVERLAY’s speed without shutting the workload down early.

That leaves two warm methods to choose from, per VM or per wave. CBT copies data over the network and re-syncs changes. OVERLAY skips the copy entirely when the storage layout allows it.

 

VMFS source storage, via Relocate

OVERLAY’s other limit was storage. It needs the source datastore to be an NFS export that is also mounted in CloudStack as primary storage, which ruled out VMFS.

v0.6.0 adds a relocation step. A VM on VMFS is moved with Storage vMotion, while it keeps running, to the NFS datastore set as the Relocate via target in its datastore mapping. If the migration fails or is cancelled, or once a completed migration has been consolidated, Relocate back returns the VM to its original datastores on request.

A pre-flight check reports every problem with the target, the vCenter privileges and CloudStack’s backing-file setting before anything moves, and a Storage vMotions in flight setting limits how many relocations run at once. vSAN and VVol are expected to work the same way but are not yet tested.

 

Automatic Disk Consolidation

After an OVERLAY import, the migrated volume is a qcow2 file backed by the source VMDK. Until that chain is collapsed, the source datastore stays in use and the source VM has to stay powered off and untouched.

v0.6.0 collapses the chain for you. The new OVERLAY chain consolidation setting runs whether the migrated VM is running or stopped in CloudStack, and a running VM takes no extra downtime for it. When it finishes, the source VM and its files are released.

Each finished OVERLAY migration also gets its own Consolidate button, and outstanding consolidations are flagged so they don’t get forgotten. A bandwidth cap limits the load on the NFS export while they run. Consolidations use their own lane on each worker, so they don’t take a migration slot or hold up a cutover.

 

Warm Migration Without VDDK

OVERLAY has never depended on VMware’s VDDK library. That mattered less while it required a powered-off VM, because an estate that couldn’t get VDDK was left with cold migrations only.

The last two releases changed that. v0.5.0 added a direct NFS read path for CBT, which removed VDDK from warm migrations on NFS source storage. v0.6.0 makes OVERLAY warm and extends it to VMFS. An estate without VDDK now has a warm migration route on either NFS or VMFS.

Getting VDDK has become harder for some estates, which we covered in a separate post on the Broadcom download pages.

 

Ceph RBD as a Migration Destination

CBT and VDDK migrations can now write directly to Ceph RBD primary storage. Migrate detects RBD support from CloudStack and writes converted disks straight to RBD images. Until support is detected, RBD pools are shown as disabled, along with the reason.

The target needs CloudStack 4.22.2 or later, and the workers need qemu’s RDB driver and the nbd kernel module. The worker installer adds both where it can. OVERLAY and OVF still write to NFS primary storage only.

 

Choosing How Guest IP Address are Handled

Until now, keeping a guest’s network identity meant injecting a static configuration into the guest. That works, but many estates don’t want addressing managed inside the guest.

v0.6.0 adds a Default IP Handling Mode, which you can override per wave and per VM. It has three options:

• Inject the static configuration into the guest, as before
• Have CloudStack assign the same IP and leave the guest on DHCP
• Keep the source MAC address and let DHCP hand back the same IP

If you run your own DHCP or IPAM, you no longer have to work around guest-level injection.

One thing to check after upgrading: guest IP and MAC preservation is now off by default. If your deployment relied on it, enable it in Settings and set a default temporary import network.

What This Means for a Migration Project

• The fastest method no longer means downtime up front
• VMFS estates can use OVERLAY, and the relocation can be reversed
• No manual clean-up after an OVERLAY wave
• Ceph RBD can be a target for CBT and VDDK
• IP handling that fits how your network already works

Download the Product Brief

 

Fixes from Real Migrations

v0.6.0 also includes fixes for issues found in customer deployments and in testing on real infrastructure. Two of them concern data integrity in CBT. A copy could miss recent writes if a VMware snapshot or an unconsolidated delta was in the disk chain during a direct NFS read, and a delta or final pass could keep data the guest had since zeroed.

Task handling is also more reliable. A worker that stalled briefly could have its task picked up by a second worker, which created a duplicate VM in CloudStack. A cutover’s final sync could also get stuck behind routine deltas from other VMs. All of these are fixed, and the full list is in the release notes.

 

Availability

ShapeBlue Migrate v0.6.0 is available now to all ShapeBlue customers. To learn more or to talk through your VMware to Apache CloudStack migration, contact us at info@shapeblue.com.

Download the Product Brief

 

FAQ about ShapeBlue Migrate v0.6.0

Does OVERLAY still need the source VM powered off?
No. A running VM stays up and waits in Awaiting Cutover until its cutover policy fires, the same as CBT. After the cutover, the source VM only has to stay powered off until its disk chain has been consolidated.

Can OVERLAY use VMFS datastores now?
Yes. The VM is moved with Storage vMotion, while still running, to the NFS datastore set as the Relocate via target. It can be moved back if the migration fails or is cancelled.

Do I still need to clean up OVERLAY disks by hand?
No. OVERLAY chain consolidation collapses the backing chain whether the migrated VM is running or stopped, with no extra downtime for a running VM. Anything outstanding can be handled with the per-VM Consolidate button.

Which methods can write to Ceph RBD?
CBT and VDDK. OVERLAY and OVF remain NFS-only, and the target needs CloudStack 4.22.2 or later.

What happened to the Unregister OVERLAY Source VM setting?
Consolidation replaces it and releases the source VM and its files completely. If you used that setting, configure OVERLAY chain consolidation after upgrading.

How do I get v0.6.0?
It’s available to all ShapeBlue customers and upgrades in place over v0.5.0.

The post ShapeBlue Migrate v0.6.0: OVERLAY Migrations No Longer Require Powering Off the VMware VMs appeared first on ShapeBlue.

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

CISA Urges Immediate Ivanti Connect Secure Updates as Honeypots Log 105 Exploit Attempts

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) on Tuesday urged organizations to take steps to immediately update their Ivanti Connect Secure (ICS) appliances and deployments to the latest version following the disclosure of an actively exploited vulnerability.

The security flaw, tracked as CVE-2026-104935 (CVSS score: 8.6), is a case of authentication bypass impacting ICS versions 25.1.1.1 and prior, 25.1.2.2 and prior, and 22.8R2.4 and prior that could allow a remote unauthenticated attacker to execute arbitrary commands.

"CISA is aware of cyber threat actors exploiting this zero-day authentication bypass vulnerability, which allows remote, unauthenticated execution of arbitrary commands, to conduct credential theft and data exfiltration," the agency said.

The agency has since added the flaw to its Known Exploited Vulnerabilities (KEV) catalog, requiring Federal Civilian Executive Branch (FCEB) agencies to apply the fixes by October 16, 2026.

CISA is also recommending that customers of affected ICS deployments review Ivanti's Connect Secure Upgrade and Migration Compatibility Guide for patching guidance, cautioning that version 22.8 reaches end-of-life on January 31, 2027.

"Organizations seeking to determine whether they were compromised will need to conduct network and memory forensics to identify evidence of exploitation," it added.

In the event a compromise is detected, CISA is advising organizations to implement the following actions -

• Create a backup of the appliance configuration.
• Conduct a factory reset and upgrade the appliance to the latest version.
• For cloud and virtual systems, rebuild the virtual instance and upgrade to the latest version.
• Restore the appliance configuration from the backup created in step 1.
• Reset passwords for all accounts, including domain, administrator, and local accounts. Revoke and reissue stored certificates; reset stored API keys and license server credentials.

The development comes as Previdian disclosed that it has observed 105 exploitation attempts targeting its honeypot sensors as of October 14, 2026. The attack attempts have originated from 50 unique IP addresses geolocated to Singapore and the U.S. Some of the observed IP addresses are listed below -

• 216.73.160[.]59
• 216.73.160[.]61
• 216.73.160[.]210
• 45.8.19[.]111

According to Previdian founder and CEO, Ryan Dewhurst, threat actors are using the X-DSCGI-PATH header to reach an internal CGI handler and upload Perl scripts dressed up as ZIP files. The scripts return unique markers that determine whether remote code execution has succeeded.

"We're seeing coordinated attempts to exploit this Ivanti vulnerability, but the payloads captured so far are primarily testing for code execution rather than deploying malware, or compromising the device," Dewhurst told The Hacker News. "However, full weaponized exploitation is likely to follow in the coming hours and days."

In a separate report, Volexity said it first observed the exploitation of CVE-2026-104935 on October 3, 2026, with a previously undocumented threat actor dubbed UTA0576 leveraging it in conjunction with a privilege escalation vulnerability to achieve unauthenticated root-level code execution. UTA0576 is assessed to be driven by criminal motives rather than espionage.

Following successful exploitation, the threat actor is said to have engaged in broad post-exploitation actions, including extracting credentials stored on the ICS VPN appliance, exfiltrating limited Active Directory metadata, deploying a Kerberos tool capable of Kerberoast attacks and credential testing, conducting host reconnaissance, LDAP packet capture, and dropping a Python LDAP tool to search for administrator passwords and BitLocker recovery keys.

"The recovered payloads demonstrate deliberate efforts to conceal malicious activity through selective log modification, removal of temporary execution artifacts, and restoration of altered system state," Volexity researchers Charlie Gardner, Sean Koessel, and Steven Adair said.

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