Posts on Security, Cloud, DevOps, Citrix, VMware and others.
Words and views are my own and do not reflect on my companies views.
Disclaimer: some of the links on this site are affiliate links, if you click on them and make a purchase, I make a commission.
Cisco Talos’ Vulnerability Discovery & Research team recently disclosed eight vulnerabilities in TP-Link, and one each in Adobe Photoshop, OpenVPN, and Gen Digital's Norton VPN.
The vulnerabilities mentioned in this blog post have been patched by their respective vendors, in adherence to Cisco’s third-party vulnerability disclosure policy, except the Norton VPN vulnerability, which was discovered in-use before a patch was available.
For Snort coverage that can detect the exploitation of these vulnerabilities, download the latest rule sets from Snort.org, and our latest Vulnerability Advisories are always posted on Talos Intelligence’s website.
TP-Link vulnerabilities
Discovered by Lilith >_> of Cisco Talos.
The TP-Link Archer AX53 is a dual band gigabit Wi-Fi router. Talos has disclosed eight vulnerabilities, as follows:
TALOS-2025-2302 (CVE-2026-30814) is a stack-based buffer overflow vulnerability in the tmpServer opcode 0x436 functionality of Tp-Link AX53 v1.0 1.3.1 Build 20241120 rel.54901(5553). A specially crafted set of network packets can lead to arbitrary code execution. An attacker can send packets to trigger this vulnerability.
TALOS-2025-2303 (CVE-2026-30815) is an OS command injection vulnerability in the OpenVPN configuration restore script_security functionality of Tp-Link Archer AX53 v1.0 1.3.1 Build 20241120 rel.54901(5553). A specially crafted configuration value can lead to arbitrary command execution. An attacker can upload a malicious file to trigger this vulnerability.
TALOS-2025-2304 (CVE-2026-30816) is an external config control vulnerability in the OpenVPN configuration restore crt.sed functionality of Tp-Link Archer AX53 v1.0 1.3.1 Build 20241120 rel.54901(5553). A specially crafted configuration value can lead to arbitrary file reading. An attacker can upload a malicious file to trigger this vulnerability.
TALOS-2025-2305 (CVE-2026-30817) is an external config control vulnerability in the OpenVPN configuration restore route_up functionality of Tp-Link Archer AX53 v1.0 1.3.1 Build 20241120 rel.54901(5553). A specially crafted configuration value can lead to arbitrary file reading. An attacker can upload a malicious file to trigger this vulnerability.
TALOS-2025-2306 (CVE-2026-30818) is an OS command injection vulnerability exists in the dnsmasq configuration restore dhcpscript functionality of Tp-Link Archer AX53 v1.0 1.3.1 Build 20241120 rel.54901(5553). A specially crafted configuration value can lead to arbitrary command execution. An attacker can upload a malicious file to trigger this vulnerability.
TALOS-2025-2307,TALOS-2025-2308, andTALOS-2025-2309 are OS command injection vulnerabilities in the OpenVPN configuration restore client_disconnect, client_connect, and route_up functionalities of Tp-Link Archer AX53 v1.0 1.3.1 Build 20241120 rel.54901(5553). A specially crafted configuration value can lead to arbitrary command execution. An attacker can upload a malicious file to trigger this vulnerability.
Photoshop vulnerabilities
Discovered by KPC of Cisco Talos.
Adobe Photoshop is a popular digital photo manipulation and illustration program with a wide array of features for personal and business use cases.
TALOS-2025-2274 (CVE-2026-34632) is a privilege escalation vulnerability in the installation process of Adobe Photoshop via the Microsoft Store. The vulnerable version of the installer is Photoshop_Set-Up.exe 2.11.0.30. A low-privilege user can replace files during the installation process, which may result in elevation of privileges.
OpenVPN vulnerabilities
Discovered by Emma Reuter of Cisco ASIG.
OpenVPN is an open source SSL VPN with remote access, site-to-site VPNs, WiFi security, enterprise load balancing, failover, and granular access control features available.
TALOS-2026-2381 (CVE-2026-35058) is a reachable assertion vulnerability in the TLS Crypt v2 Client Key Extraction functionality of OpenVPN 2.6.x and 2.8_git. A specially crafted network packet can lead to a denial of service. An attacker can send a sequence of malicious packets to trigger this vulnerability.
Gen Digital Norton VPN vulnerabilities
Discovered by KPC of Cisco Talos.
Gen Digital's Norton VPN client is a proprietary tool for private proxy network information exchange.
TALOS-2025-2276 (CVE-2025-58074) is a privilege escalation vulnerability in the installation process of Norton VPN via the Microsoft Store. A low-privilege user can replace files during the installation process, which may result in deletion of arbitrary files, possibly leading to elevation of privileges.
from Cisco Talos Blog https://ift.tt/5TtqSQw
via IFTTT
Agentic AI is no longer theoretical. It’s already embedded across enterprises inside developer workflows, SaaS platforms, and operational pipelines. It is executing tasks, chaining actions, and interacting with critical systems at machine speed.
What makes this shift different from previous waves of automation is not just capability, it’s autonomy. These systems don’t wait for step-by-step human instruction. They interpret goals, break them into subtasks, and execute independently across tools, data, and environments. That autonomy is powerful, however it’s also introducing a new class of security challenges that traditional controls were never designed to handle.
Most organizations today lack visibility into where agents are running, what they can access, and what actions they’re taking. Even fewer have the ability to enforce policy or intervene in real time. As a result, agent adoption is accelerating faster than the security models required to govern it.
To adopt agentic AI safely, SentinelOne® is helping organizations rethink security from the ground up starting with how agents behave, what they can reach, and how their actions are controlled. The newly released Prompt for Agentic AI Security enables organizations to move from reactive oversight to proactive governance, meaning teams can deploy agents with confidence.
When AI Doesn’t Just Respond—It Acts
Agentic AI interactions have a technical distinction that fundamentally changes the security equation. Unlike traditional AI systems that generate outputs in response to prompts, agents are designed to execute. They receive a goal, decompose it into subtasks, and carry out actions across systems, often without per-step human approval. They hold credentials, make API calls, modify data, and interact with business-critical platforms in real time.
They can read files, execute code, send messages, and trigger workflows—all autonomously. This shift from “response” to “execution” introduces three distinct categories of risk.
1. Construction-Time Risk: How Agents Are Built
Many risks are introduced before an agent ever runs. Agents are often deployed with overly permissive IAM roles, granting access far beyond what their tasks require. They rely on third-party skills and plugins pulled from public repositories, creating a new supply chain surface with little verification. In many cases, API keys and secrets are hardcoded directly into configurations, making compromise trivial. At this stage, the issue is not behavior, it’s exposure.
2. Runtime Risk: What Happens When Agents Execute
Once deployed, agents introduce dynamic, real-time risks that traditional controls struggle to detect. Prompt injection attacks can manipulate agent behavior in ways that trigger real-world actions and not just incorrect outputs. A malicious instruction embedded in a document can become an execution command. Agents may also chain together individually authorized actions that, in sequence, produce unauthorized outcomes. Data exfiltration can occur through legitimate-looking API calls as part of “completing a task”. At runtime, the line between intended behavior and malicious activity becomes blurred.
3. Operational Risk: The Gaps Around the System
Even when risks are understood, most organizations lack the operational controls to respond effectively. There is often no kill switch to stop a misbehaving agent in seconds. No rollback capability to recover from corrupted data. No audit trail to reconstruct what an agent actually did. And no incident response playbook designed for machine-speed, autonomous actions. These gaps compound the risks introduced at every other stage.
From Blind Trust to Verified Control: The Evolution of Agent Security
As autonomous agents continue to move quickly from experimental tools to core infrastructure, security has lagged behind. Most frameworks still operate on implicit trust: trust in downloaded skills, trust in evolving prompts, and trust that agents will behave safely despite increasing autonomy. That assumption is already proving flawed.
Recent discoveries of hundreds of malicious agent skills circulating through public repositories highlight how easily these ecosystems can be exploited. Disguised as legitimate utilities, these components harvested credentials, secrets, and sensitive data at scale. This is a structural problem. Since agentic systems are dynamic by design, they pull external dependencies, adapt behavior over time, and execute across systems with minimal oversight. Traditional security models were not built for this.
Introducing Prompt for Agentic AI Security
Now, AI agents are already operating inside your organization—reading files, calling APIs, and chaining actions across critical systems without human approval at every step. They are non-human identities that reason, decide, and execute at machine speed.
Prompt for Agentic AI Security is SentinelOne’s agent security layer. This first phase provides real-time discovery and governance control plane designed specifically for this new reality as well as a full visibility Model Context Protocol (MCP) server across your environment, along with the ability to assess risk, enforce policy, and remediate automatically before unauthorized actions occur.
Unauthorized actions can be stopped at the moment they occur, not after damage is done. As agent adoption grows, organizations gain a centralized control plane to manage sprawl and maintain compliance. Most importantly, security becomes an enabler of speed rather than a barrier to it.
The following capabilities will be available as part of the first phase of this release. Starting with MCP, the protocol powering the rise of agentic AI.
MCP Discovery and Governance: surface every MCP server in your environment, sanctioned or shadow
Risk-Based Enforcement: assess and score each server’s threat profile before agents act
Runtime Prompt Injection Blocking: inspect tool calls and agent interactions in real time, stopping attacks at the moment of execution
Malicious Server Prevention: identify and block malicious MCP servers from operating in your environment
How to Adopt AI Agents Safely: A 90-Day Plan
Adopting agentic AI safely requires structure. A practical approach is to move in phases: first gaining visibility, then enforcing guardrails, and finally building operational capability.
Days 1–30: Discovery and Inventory
Start by understanding what exists. Audit browser extensions, analyze network traffic to known AI services, and review OAuth grants for third-party integrations. These steps provide an initial baseline, but they won’t capture everything.
Deploy Prompt for Agentic AI Security to automatically discover MCP activity, including shadow deployments, local processes, and embedded agents inside developer tools.
Map not just what agents exist, but what they’re connected to. Identify which systems they can access, what permissions they hold, and what actions they can take.
Prioritize agents based on risk—those with access to production systems or sensitive data should be investigated first.
The goal: A live, risk-scored inventory of every agent and its blast radius.
Days 31–60: Guardrails and Control
Next, enforce boundaries. Route agent interactions through controlled pathways like an MCP gateway to inspect and enforce policies in real time.
Configure allow/block rules based on user, agent, and action type to enforce least privilege.
Enable content inspection to prevent sensitive data from entering execution pipelines. At the same time, provide sanctioned tools and frameworks so teams have secure alternatives.
Establish a clear, simple acceptable use policy for agents—covering approved tools, prohibited data, and escalation paths.
The goal: Real-time enforcement and safe pathways for adoption.
Days 61–90: Operational Readiness
Finally, build the ability to respond. Integrate agent telemetry into SOC workflows and establish behavioral baselines.
Use enforcement controls as a kill switch to stop anomalous activity instantly.
Run tabletop exercises to test detection, containment, and recovery. Ensure teams can answer “what did this agent do?” in seconds—not days.
Document an AI-specific incident response playbook and establish continuous review of agent permissions using dynamic risk scoring.
The goal: Full operational capability to manage agent-related incidents.
Conclusion
Agentic AI is not slowing down. The organizations that succeed won’t be the ones that moved fastest or blocked adoption entirely—they’ll be the ones that built the visibility, control, and response capabilities to adopt it safely. The path forward is clear: See every agent, understand what it can reach, enforce what it’s allowed to do, and maintain a complete record of its actions. This is the governance layer agentic AI demands.
The new release of Prompt for Agentic AI Security brings it all together as an enterprise control plane by combining real-time discovery, dynamic risk scoring, policy enforcement, and full auditability at machine speed. Security isn’t the reason your organization can’t adopt agents, it’s how you adopt them with confidence.
All third-party product names, logos, and brands mentioned in this publication are the property of their respective owners and are for identification purposes only. Use of these names, logos, and brands does not imply affiliation, endorsement, sponsorship, or association with the third party.
This publication includes forward-looking statements, including, but not limited to, statements concerning the expected timing of product and feature availability, the benefits and capabilities of our current and future products and services, competition and our competitive position, our strategic plans and objectives, and general market trends. Forward-looking statements are subject to risks and uncertainties, including factors beyond our control, that could cause actual performance or results to differ materially from those expressed in or suggested by the forward-looking statements. These and other risk factors are described in the “Risk Factors” section of our most recent Annual Report on Form 10-K, subsequently quarterly reports filed on Form 10-Q, and other filings made with the U.S. Securities and Exchange Commission (SEC), which are available free of charge on our website at https://ift.tt/D9K71Om and on the SEC’s website at http://www.sec.gov.
You are cautioned not to place undue reliance on these forward-looking statements. Any future products, functionality and services may be abandoned or delayed, and as such, you should make decisions to purchase products and services based on features that are currently available.
Any forward-looking statements made in this publication are based on our beliefs and assumptions that we believe to be reasonable as of the date hereof. You should not rely upon forward-looking statements as predictions of future events. Except to the extent required by law, we undertake no obligation to update these forward-looking statements to reflect new information or future events.
Need to perform maintenance on your Veeam HA cluster without disrupting backup operations? Learn how to run rescans, perform switchovers between nodes, and safely disassemble the cluster when needed.
Veeam High Availability Cluster provides several maintenance operations that help keep the backup infrastructure available and protected. Once the HA cluster is configured, administrators may need to rescan the cluster, switch roles between the Primary and Secondary Nodes, or disassemble the cluster when it is no longer required.
In the previous parts of this series, we covered how to configure the Veeam High Availability Cluster and how failover works. This final part explains how to perform the main maintenance tasks: rescan the cluster, run a switchover to move the Primary Node role to the Secondary Node, and disassemble the HA cluster safely.
These operations are useful during planned maintenance, troubleshooting, or infrastructure changes. With the correct procedure, you can maintain the Veeam HA cluster without unnecessary service disruption and keep backup services protected.
Rescan
The rescan operation may be required if the Secondary Node has not synchronized with the Primary Node for an extended period. The system performs a rescan operation every 4 hours.
During a rescan, Veeam Backup & Replicationpulls Primary Node infrastructure data from the configuration database and synchronizes it with the Secondary Node.
To force synchronisation, right click the Primary Node and select Rescan.
The rescan operation is executed and completed successfully.
Switchover
The switchover operation is used when you need to perform tasks (hardware maintenance for example) that require the shutdown of the Primary Node. During the switchover, the role of the Primary Node is assigned to the Secondary Node. During the switchover procedure, all jobs and services are stopped as well as Instant Recovery sessions.
When maintenance is completed, you can revert to the Primary Node or leave it as Secondary.
To perform a switchover, right click the node you want to switch and select Switchover to another node.
Click Switchover to confirm.
The switchover is being executed. Note the servers that hold the Primary and Secondary roles.
During the procedure, the Veeam Console is restarted. Enter the cluster IP Address and click Connect.
Enter the veeamadmin credentials and click Sign in.
When the switchover operation is completed successfully, the Veeam appliances that are member of the HA cluster have switched their roles.
Disassemble
The disassemble operation is used to dismiss a Veeam High Availability Cluster when it is no longer required or to fix issues with the Secondary Node. When the disassemble task is launched, the Primary Node removes the configuration database from the Secondary Nodes and stops synchronizing.
The secondary node cannot be used as a standalone Backup Server after you disassemble an HA cluster.
To disassemble a Veeam High Availability Cluster, right click the Primary Node and select Disassemble HA cluster.
Click Disassemble to confirm.
The HA cluster disassemble operation is being performed.
When the operation is completed, the Veeam Console is restarted.
The HA cluster is disassembled and the Secondary Node removed.
Several tasks can be performed to maintain a Veeam High Availability Cluster to avoid service disruption and ensure the highest level of protection.
Veeam Backup & Replication is available to download as 30-day trial.
from StarWind Blog https://ift.tt/UA3I9Yp
via IFTTT
Drupal has issued an alert stating that it intends to release a "core security release" for all supported branches on May 20, 2026, from 5-9 p.m. UTC.
"The Drupal Security Team urges you to reserve time for core updates at that time because exploits might be developed within hours or days," the maintainers of the PHP-based content management system (CMS) said.
"Not all configurations are affected. Reserve time on May 20 during the release window to determine whether your sites are affected and in need of an immediate update. Mitigation information will be included in the advisory."
It's being advised to update to the latest supported patch for the site's version of Drupal before the deadline so that any outstanding upgrade issues can be addressed.
Patches are expected to be available for the following supported branches of Drupal core -
11.3.x
11.2.x
10.6.x
10.5.x
"Sites on one of these supported versions should update to the latest patch release for the given branch now in preparation for the security window," Drupal said.
The exact nature of the security issue being addressed is unknown at this stage, but it's expected to be severe given that Drupal is providing 11.1.x and 10.4.x releases for sites running end-of-life minor core versions. Ahead of the planned update window -
Sites on Drupal 11.1 or 11.0 should update to at least Drupal 11.1.9.
Sites on Drupal 10.4, 10.3, 10.2, 10.1, or 10.0 should update to at least Drupal 10.4.9.
The idea is that these sites should apply the security update as soon as it is released on May 20, and then upgrade to Drupal 11.3 or 10.6 in the near future.
For sites still on end-of-life major core versions, such as Drupal 8 and 9, patch files for Drupal 8.9 and 9.5 will need to be applied manually. However, Drupal has warned that there is no guarantee the fixes will work correctly, adding that they may introduce other issues or regressions.
"However, they may help mitigate the vulnerability for sites still on these old major versions until they upgrade to a supported release," Drupal said.
"We strongly recommend Drupal 8 or 9 sites update to at least Drupal 10.6 soon. Drupal 8 and 9 include numerous other, previously disclosed, security vulnerabilities that will not be addressed by either Drupal Steward or the best-effort patch files."
Drupal also noted that Drupal 7 is not affected by the issue. Sites on any version of Drupal 9 are advised to update to 9.5.11, and those on any version of Drupal 8 should update to Drupal 8.9.20.
from The Hacker News https://ift.tt/tWayJnG
via IFTTT
Cisco Talos has uncovered a BadIIS variant — identifiable by its embedded "demo.pdb" strings — that functions as commodity malware. This variant is likely sold or shared among multiple Chinese-speaking cybercrime groups that operate under a malware-as-a-service (MaaS) model for continuous monetization.
Analysis of program database (PDB) file paths reveals a sustained, multi-year development effort by an author operating under the alias “lwxat”, spanning from at least September 2021 through January 2026, with evidence of rapid iterative updates, feature branching, and reactive evasion tactics targeting specific security vendors such as Norton.
Talos recovered a dedicated builder tool that allows threat actors to generate configuration files, customize payloads, and inject parameters into BadIIS binaries — enabling capabilities including traffic redirection to illicit sites, reverse proxying for search engine crawler manipulation, content hijacking, and backlink injection for malicious search engine optimization (SEO) fraud.
Beyond BadIIS, the same author has developed a suite of auxiliary tools — including service-based installers, droppers, and persistence mechanisms that automate deployment, ensure survivability across IIS server restarts, and evade detection through custom Base64 encoding and obfuscation techniques.
Mystery BadIIS containing “demo.pdb”
Since 2024, Talos has investigated numerous attacks across the Asia-Pacific region (along with a few in South Africa, Europe and North America) that utilize a specific variant of BadIIS characterized by "demo.pdb" strings. While multiple security vendors are tracking the global spread of these variants, Talos' observed tactics, techniques, and procedures (TTPs) show notable divergences from those documented by other vendors like Trend Micro, Ahnlab, VNPT, and Elastic. Consequently, it is difficult to attribute these attacks to a single threat actor. However, we assess with moderate confidence that the "demo.pdb" BadIIS variant is a commodity tool utilized by multiple Chinese-speaking cybercrime groups.
Insights from embedded PDB strings
Although the core functionality of this BadIIS variant is largely limited to SEO fraud, content injection, and proxy‑based traffic manipulation, our investigation pivoted toward the malware’s embedded PDB strings. The consistent PDB path pattern offers much more intelligence value than the generic “demo.pdb” filename. The combination of a stable “Administrator\Desktop” build environment, Chinese-language folder names, and date-based versioning creates a highly reliable fingerprint for tracking and clustering this BadIIS version toolset. Beyond reinforcing our assessment that this is a commodity IIS malware family, the PDB paths enabled attribution to a possible customer name alias “x神” (“xshen”). Furthermore, the PDB artifacts reveal the existence of customized builds, some explicitly tailored to:
Bypass specific antivirus products, such as Norton
Perform site‑wide hijacking
Redirect users conditionally based on browser language or environment
Figure 1. “Custom site hijacking: redirect based on browser language” version.Figure 2. PDB with 过诺顿 (bypass Norton antivirus) version.
Prompted by these initial discoveries, Talos expanded our threat hunting efforts to identify similar PDB strings associated with this author with high confidence. The PDB paths extracted from these BadIIS variants reveal a sustained, multi-year development effort spanning from at least September 2021 to January 2026. By analyzing the developer's folder naming conventions, we can accurately map the malware's evolutionary trajectory, feature branching, and commercialization model.
Timeline and iterative maintenance
Talos observed that the earliest explicit timestamp in the PDB paths is Sept. 30, 2021, indicating that the development of this specific toolset began on or before this date. The naming conventions observed in folders such as “dll0217”, “dll0301”, and “dll0315” (likely representing February 17, March 1, and March 15) demonstrate periods of rapid, sprint-like updates. Additionally, the “dll-no503” directory is particularly notable; it likely represents a troubleshooting build designed to resolve an issue where the malware caused IIS to throw "503 Service Unavailable" errors, which would otherwise alert server administrators to the infection. Finally, the latest observed compilation date, “dll20260106” (Jan. 6, 2026), confirms that this toolset remains actively maintained and deployed in the wild as of early 2026.
Feature branching and evasion tactics
Talos also observed that the folder “兼容百度浏览器+劫持robots.txt” (“Compatible with Baidu browser + hijacking robots.txt”) explicitly confirms the malware's role in malicious SEO campaigns, specifically targeting the Chinese search engine ecosystem. Furthermore, the “2024-05-05-tcp" branch indicates a shift or enhancement in how the malware handles network traffic, potentially introducing custom proxying or SEO fraud communication protocols over raw TCP. Additionally, the inclusion of “过诺顿” (”bypass Norton”) in the build paths highlights a reactive development cycle, demonstrating that the author actively modifies the code to evade specific security vendor detections.
C:\Users\Administrator\Desktop\2025-11-21 (x神订制全站劫持按浏览器语言跳转)\dll\Release\demo.pdb (translation:“xshencustom site hijacking:redirect based on browser language)”
C:\Users\Administrator\Desktop\2025-11-21 (x神订制全站劫持按浏览器语言跳转)\dll\x64\Release\demo.pdb (translation:“xshencustom site hijacking:redirect based on browser language”)
During our research into these BadIIS campaigns, Talos discovered a builder tool specifically designed for this malware variant. The threat actor utilizes this utility to generate configuration files, JavaScript redirectors, and PHP backlink scripts, as well as to inject custom parameters directly into the BadIIS malware. Figure 3 shows a screenshot of the builder's interface.
Figure 3. Builder screenshot.
The observed builder is labeled as “version 1.0,” with an estimated original release year of 2021. However, the application header and compilation timestamp indicate that this specific artifact is an updated build compiled on August 22, 2022. The interface fields and configurable settings perfectly align with known BadIIS capabilities, which can be categorized into four primary functions:
Trafficredirection: The builder allows threat actors to input target URLs, typically JavaScript-based redirectors, designed to be injected into the victim's browser. This feature forcibly redirects legitimate user traffic to spam infrastructure, such as illegal gambling, adult content, or other malicious websites.
Reverse proxy: This feature manipulates how the compromised server interacts with search engine crawlers. When a crawler visits specific hidden URLs, the BadIIS malware acts as a reverse proxy, silently fetching illicit content from the threat actor's command-and-control (C2) backend and serving it to the crawler for indexing. Furthermore, the builder includes a toggle to enable this reverse proxy behavior globally, intercepting crawlers even if they do not visit the designated hidden URLs.
Contenthijacking: The builder includes a site hijacking function capable of replacing the compromised website's original content for both normal users and search engine crawlers. Threat actors can configure the hijacking rate (percentage of traffic affected), toggle whether the homepage is explicitly targeted, and supply a remote URL to dynamically fetch malicious title, description, and keyword (TDK) metadata.
Internalandbacklinks setting: The final component configures the injection of internal links and external backlinks. Internal links force search engines to discover and index the spam pages hosted directly on the compromised server. Meanwhile, external backlinks siphon the compromised server's Domain Authority, passing that high reputation onto external illicit websites to artificially inflate their search engine rankings.
Figure 4. Builder workflow.
Furthermore, operating this builder is not a simple, single-click process. Prior to generating the final payloads, the threat actor must stage unconfigured 32-bit and 64-bit BadIIS binaries within the same directory as the builder. Upon initiating the build process, the builder generates a “config.txt” file based on the threat actor’s configured parameters.
Figure 5. Configured parameters.
It then attempts to authenticate with the C2 server by checking for the specific response string "lwxat". Although the builder does not enforce this validation step — continuing the payload generation process regardless of whether the authentication succeeds or fails — this specific network behavior is highly valuable. Notably, this unique authentication mechanism serves as a critical pivot point, enabling us to identify and attribute other tools developed by the same author.
Figure 6. Unique authentication mechanism.
The final step of the build process involves obfuscating the C2 server address using a single-byte XOR operation with the key 0x3. Once encoded, the builder embeds these addresses, along with all other configured parameters, directly into the final BadIIS malware under the output folder. This configured and output files are illustrated in Figure 7.
Figure 7. Configuration embedded in a BadIIS sample. Figure 8. BadIIS output files and its original name.
Advancement of the builder architecture
Talos has been tracking multiple cybercrime groups, including those detailed in our previous reports on DragonRank and UAT-8099, that utilize various BadIIS variants to turn global web servers into compromised assets for search engine manipulation. The BadIIS variants deployed by those two groups primarily relied on hardcoded C2 infrastructure and statically compiled payloads to spread. However, the variant characterized by the "demo.pdb" strings represents a significant departure from these previous iterations.
Based on the recovered builder and PDB strings, Talos assesses with moderate confidence that this "demo.pdb" variant is commodity malware, likely sold privately or shared within underground markets. The architecture of this toolset suggests a modular, MaaS business model designed for continuous monetization. The malware developer can initially sell a basic version of BadIIS alongside the builder tool. If a threat actor later requiresan advanced, updated, or customized version (such as the “Norton bypass” or “custom site hijacking: redirect based on browser language” modules), they can request a bespoke payload from the developer and use their existing builder to inject the necessary configurations. Figure 9 shows the workflow Talos assessed.
Figure 9. Workflow assessed for commodity BadIIS.
Additional tools developed by same author
By pivoting on the previously identified PDB strings and the authentication mechanism, Talos discovered that this author has developed a suite of additional tools designed to facilitate the installation of BadIIS on target machines. The observed PDB strings are listed below, followed by a detailed analysis of the differences between these tools and their respective capabilities.
D:\vc\dll封装进exe\x64\Release\moduleinit.pdb (translation:“DLLpackaged into EXE”)
Talos identified an additional tool that we assess with high confidence is linked to the same author. Upon execution, the tool verifies that it is running as a Windows service named “Winlogin.” If this condition is met, it initiates a two-stage C2 communication process. First, it connects to a primary C2 server for authentication. During this phase, the malware validates the connection by checking if the server's response matches the specific string "lwxat".
Figure 10. First C2 server for authentication.
Once authenticated, it connects to a secondary C2 server to download and execute additional malicious payloads on the target machine. Furthermore, the malware uses double Base64 encoding to obfuscate the addresses of both C2 servers.
Figure 11. Second C2 to download payload.
Configuration‑driven service installer
Talos observed another service-based tool that dynamically locates and reads an external configuration file to deploy BadIIS onto target machines. This component serves the same operational purpose as the installation batch scripts traditionally observed in earlier BadIIS campaigns. Upon execution, the malware identifies its own absolute path and searches its current directory for a file named “config.txt”. This configuration file uses an XML-like syntax, employing custom tags such as “<globalModules>”, “<name>”, “<path>”, and “<cmd>”. The tool employs a custom parsing routine to segment the file based on these tags, extracting string arrays that dictate its subsequent actions. Using this extracted data, the malware dynamically assembles command-line instructions by iterating through the parsed modules and replacing placeholders like “{name}” and “{path}” with randomized DLL paths and command snippets.
Figure 12. Configuration tags.
During this assembly phase, the tool specifically prepares commands for both 32-bit and 64-bit BadIIS (e.g., appending “32.dll” /y and “64.dll” /y). These fully-formed commands are then executed, likely via cmd.exe /c, using a function designed to capture the command output.
Figure 13. Preparing commands for 32-bit BadIIS.
Authentication and configuration‑driven unified tool
The threat actor continues to update this tool, recently merging two distinct capabilities into a single binary. The malware still impersonates the Winlogin system service for registration and persistence, but it now utilizes a higher volume of command-line executions to successfully install the BadIIS payload. Notably, these command lines closely resemble the syntax used in earlier BadIIS batch scripts. To evade detection by security products, the tool obfuscates its command lines and parameters using a custom Base64 encoding algorithm. A list of the encoded strings and their decoded counterparts is provided below.
Based on the decoded strings and the tool's code structure, we can categorize the functionality of this upgraded tool into three primary areas. The first group of strings focuses on file discovery, searching for “module.txt”, “.dll”, and “.config” files. The “.config” and “.dll” searches serve the same purpose as in previous versions, targeting IIS configuration files and the BadIIS malware, respectively. The “module.txt” file likely acts as a staging file to temporarily store the IIS modules list before committing changes to the active configuration. Furthermore, this phase targets the “<globalModules>” and “<modules>” sections to register the malicious DLL at the server level. The second group handles payload registration; the tool utilizes specific XML nodes to inject its payloads into the IIS configuration, dynamically replacing placeholders (e.g., “{name32}” and “{path64}”) with actual values. Finally, the third group is responsible for locating the primary BadIIS DLL and establishing its backup location to ensure persistence. However, prior to executing its primary functions, the tool sends a request to the C2 server for authentication. The validation process remains identical to previous versions; the tool verifies the connection by checking if the server's response matches the specific string "lwxat".
Figure 14. Specific string "lwxat" for authentication.
Latest two‑stage installation toolset
Talos observed that the latest version of the service installation tool is now separated into two distinct files. The workflow is shown in Figure 15.
Figure 15. Installation workflow.
The first file acts as the primary installer and begins by authenticating with the C2 server. Following successful authentication, it searches for the BadIIS malware, copies the payloads to specific primary and backup directories, and registers them within the IIS server module list to ensure persistence. Subsequently, it drops a secondary malware component, installing it as a Windows service. During our research, Talos observed this secondary malware impersonating legitimate services such as FaxService or AudiosService. Additionally, we recovered customization parameters and execution logs associated with this installer, which provided deeper insights into its overall capabilities.
Figure 16. Customization parameters and execution logs file.
The commands and parameters embedded in the install are also encoded. Below is a list of the encoded strings and their decoded counterparts.
The secondary malware component functions similarly to the previously described service tool. However, recognizing that security operations centers (SOCs) or antivirus products can easily quarantine or delete the primary BadIIS malware, the author has implemented a robust persistence mechanism. The installer now copies the BadIIS malware not only to the active directory used for hooking IIS requests and responses but also to a hidden backup location. This ensures that the malicious BadIIS is automatically restored and launched every time the compromised IIS server is restarted. The table below provides a list of the encoded strings and their decoded counterparts.
Module initialization dropper
Alongside the service-based tools, Talos identified another utility that shares the same C2 authentication mechanism, custom Base64 encoding algorithm, and similar code structure. However, rather than operating as a persistent service, this tool functions primarily as a dropper designed to install the BadIIS malware onto the target IIS server. The embedded PDB string (“D:\vc\dll封装进exe\x64\Release\moduleinit.pdb”, which translates to "DLL packaged into EXE") explicitly confirms its purpose: packaging malicious DLL payloads within a standalone executable. The BadIIS are found in the resource and named as “IIS32” and “IIS64” (see Figure 17).
Figure 17. BadIIS malware in the resource.
The drop location for this BadIIS malware is identical to the one used by the installation script previously documented by Trend Micro.
Figure 18. BadIIS malware drop location.
"lwxat": BadIIS author identification
Through detailed analysis of numerous BadIIS samples, associated tools, and builder artifacts, Talos assesses with moderate-to-high confidence that the string "lwxat" is the author's alias or handle. This assessment is based on the following converging evidence:
Builderauthenticationmechanism: The BadIIS builder and service tool uses the string "lwxat" as a hardcoded match string within its authentication routine, suggesting the author embedded their identity into the tool's access control logic.
Configurationparameter: The string "lwxat" is used as the enable function parameter within the builder's “config.txt” file, further indicating authorship attribution embedded in the tool's operational configuration.
User-agent signature: Most notably, several BadIIS malware samples were observed using "lwxatisme" as a custom user-agent string during HTTP communications — a strong behavioral indicator that directly ties the malware to the "lwxat" persona.
Figure 19. The custom user-agent string “lwxatisme”.
Additionally, corroborating evidence was identified through PDB path strings found within certain samples. One PDB path contained the Chinese-language string:
Figure 20. A folder for x神’s requirements.
This suggests that the author created a dedicated development folder for a user or client named "xshen" (x神), indicating that this particular BadIIS variant was a customized build tailored specifically for “xshen's”requirements that a full-site traffic hijacking with redirection logic based on the victim's browser language settings.
Collectively, these findings presence of "lwxat" across the builder's authentication, configuration, and in-the-wild user-agent strings, combined with the PDB path referencing a customized build for “xshen” and provide converging evidence indicating that "lwxat" is the primary developer or operator behind the BadIIS malware family, potentially offering customization services to other threat actors.
Coverage
The following ClamAV signatures detect and block this threat:
Win.Malware.BadIIS-10059971-0
Win.Malware.BadIIS-10059977-0
Win.Malware.BadIIS-10059984-0
Win.Malware.BadIIS-10059985-0
The following SNORT® rules (SIDs) detect and block this threat:
Snort2: 1:66400, 1:66399, 1:66398
Snort3: 1:66400, 1:301491
Indicators of compromise (IOCs)
The IOCs can also be found in our GitHub repository here.
from Cisco Talos Blog https://ift.tt/pHBwO59
via IFTTT
Critical security vulnerabilities have been disclosed in SEPPMail Secure E-Mail Gateway, an enterprise-grade email security solution, that could be exploited to achieve remote code execution and enable an attacker to read arbitrary mails from the virtual appliance.
"These vulnerabilities could have been exploited to read all mail traffic or as an entry vector into the internal network," InfoGuard Labs researchers Dario Weiss, Manuel Feifel, and Olivier Becker said in a Monday report.
The list of identified flaws is as follows -
CVE-2026-2743 (CVSS score: 10.0) - A path traversal vulnerability in the SeppMail User Web Interface's large file transfer (LFT) feature that could enable arbitrary file write, resulting in remote code execution.
CVE-2026-7864 (CVSS score: 6.9) - An exposure of sensitive system information vulnerability that leaks server environment variables through an unauthenticated endpoint in the new GINA UI.
CVE-2026-44125 (CVSS score: 9.3) - A missing authorization check vulnerability for multiple endpoints in the new GINA UI that allows unauthenticated remote attackers to access functionality that would otherwise require a valid session.
CVE-2026-44126 (CVSS score: 9.2) - A deserialization of untrusted data vulnerability that allows unauthenticated remote attackers to execute code via a crafted serialized object.
CVE-2026-44127 (CVSS score: 8.8) - An unauthenticated path traversal vulnerability in "/api.app/attachment/preview" that allows remote attackers to read arbitrary local files and trigger deletion of files in the targeted directory with the privileges of the "api.app" process.
CVE-2026-44128 (CVSS score: 9.3) - An eval injection vulnerability that allows unauthenticated remote code execution by taking advantage of the fact that the /api.app/template feature directly passes user-supplied upldd parameter into a Perl eval() statement without any sanitization.
CVE-2026-44129 (CVSS score: 8.3) - An improper neutralization of special elements used in a template engine vulnerability that allows remote attackers to execute arbitrary template expressions and potentially achieve remote code execution depending on the enabled template plugins.
In a hypothetical attack scenario, a threat actor could exploit CVE-2026-2743 to overwrite the system's syslog configuration ("/etc/syslog.conf") by making use of the "nobody" user's write access to the file and ultimately obtain a Perl-based reverse shell. The end result is a complete takeover of the SEPPmail appliance, permitting the attacker to read all mail traffic and persist indefinitely on the gateway.
One significant hurdle that an attacker must overcome to achieve remote code execution is that syslogd re-reads the configuration only upon receiving the SIGHUP (aka "signal hang up") signal. Syslogd is a Linux system daemon responsible for writing system messages to log files or a user's terminal.
"The appliance uses newsyslog for log rotation (e.g., leading to logfile.0), which runs every 15 minutes via cron," the researchers explained. "newsyslog rotates files that exceed a size limit and then automatically sends a SIGHUP to syslogd. By bloating log files like SEPPMaillog, which has a 10,000 KB limit in this case, we can force a rotation and a subsequent config reload. These can be filled by just sending web requests."
While CVE-2026-44128 is said to have been fixed by version 15.0.2.1, CVE-2026-44126 was addressed with the release of version 15.0.3. The remaining vulnerabilities have been patched in version 15.0.4.
The disclosure comes weeks after SEPPmail shipped updates to resolve another critical flaw (CVE-2026-27441, CVSS score: 9.5) that could allow arbitrary operating system command execution.
from The Hacker News https://ift.tt/NI0ocJH
via IFTTT
Cybersecurity researchers have discovered four new npm packages containing information-stealing malware, one of which is a clone of the Shai-Hulud worm open-sourced by TeamPCP.
"One of the packages (chalk-tempalte) contains a direct clone of the Shai-Hulud source code that TeamPCP leaked last week, probably inspired as part of the supply chain attack competition that was published in BreachForums not long after," OX Security's Moshe Siman Tov Bustan said.
Interestingly, the malicious payloads embedded into the four npm packages are different, despite them being published by the same npm user, "deadcode09284814." As of writing, the four libraries are still available for download from npm.
An analysis of the packages has revealed that "axois-utils" is designed to deliver a Golang-based distributed denial-of-service (DDoS) botnet called Phantom Bot, with capabilities to flood a target website using HTTP, TCP, and UDP protocols. It also establishes persistence on both Windows and Linux machines by adding the payload to the Windows Startup folder and creating a scheduled task.
The remaining three drop a stealer payload on compromised systems. Of the three packages, the "chalk-tempalte" package contains a clone of the Shai-Hulud worm released by TeamPCP.
"The actor took the code, and almost without any change at all -- uploaded a working version with its own C2 server and private key into npm," OX Security said. "The stolen credentials are sent to the remote C2 server -- 87e0bbc636999b.lhr[.]life"
In addition, the data is exported to a new GitHub public repository using the stolen GitHub token via the API. The repository is given the description "A Mini Sha1-Hulud has Appeared."
The other two npm packages, "@deadcode09284814/axios-util" and "color-style-utils," carry a more straightforward functionality that siphons SSH keys, environment variables, cloud credentials, system information, IP address, and cryptocurrency wallet data to "80.200.28[.]28:2222" and "edcf8b03c84634.lhr[.]life," respectively.
"Threat actors are getting even more motivated to conduct supply chain and typo-squatting, as attacks become easier to perform with the Shai-Hulud code becoming open source," OX Security said. "We're now seeing a single actor with multiple techniques and infostealer types spreading malicious code onto npm, as it’s just the first phase of an upcoming wave of supply chain attacks coming."
Users who have downloaded the packages are uninstall them immediately, find and delete malicious configuration from IDEs and coding agents like Claude Code, rotate secrets, check for GitHub repositories containing the string "A Mini Sha1-Hulud has Appeared," and block network access to suspicious domains.
from The Hacker News https://ift.tt/TgD7UnV
via IFTTT
This year's Security Onion Conference is currently scheduled to be held in person in Augusta, GA on Friday, October 23, 2026. Registration will open August 7.
CFP
Want to speak at Security Onion Conference? We want to hear from you!
How are you...
...using Security Onion to find evil?
...handling lots of traffic and logs using Security Onion?
...integrating Security Onion with other technologies?
What happens when a phishing email looks clean enough to pass through security, but dangerous enough to expose the business after one click? That is the gap many SOCs still struggle with: the attacks that leave teams unsure what was exposed, who else was targeted, and how far the risk has spread.
Early phishing detection closes that gap. It helps teams move from uncertainty to evidence faster, reduce response delays, and stop one missed link from turning into account exposure, remote access, or operational disruption.
Why Phishing Creates Bigger Risk for Security Leaders Now
Phishing has become harder to manage because it no longer creates one clear, easy-to-contain event. A single click can turn into identity exposure, remote access, data access, or a wider investigation before the team has a clear picture.
What makes it a bigger concern now:
Puts identity at the center of the attack: Stolen credentials can expose email, SaaS apps, cloud platforms, and internal systems.
Weakens confidence in MFA: Some campaigns capture OTP codes, so “MFA is enabled” is not always enough.
Hides behind normal user behavior: CAPTCHA checks, login pages, invites, and trusted tools can make early signals look routine.
Slows business-level decisions: Teams may need time to confirm what was accessed, who was affected, and whether containment is needed.
Increases operational exposure: The longer phishing activity stays unclear, the greater the chance of account abuse, remote access, or business disruption.
The Fastest Way to Turn Phishing Signals into Action
When a phishing email gets through, speed depends on what the SOC does next. The strongest teams don’t investigate one suspicious link in isolation. They use it as the start of a connected process: validate the behavior, expand the intelligence, and check the environment for related exposure before the risk spreads.
Step 1: Confirm the Real Risk Behind the Phishing Links and Emails
The first thing SOC teams need is a safe place to check what a suspicious email or link actually does beyond the inbox. This is where interactive sandboxes become critical: they let teams open attachments, follow URLs, observe redirects, pass through phishing flows, and expose behavior that may not be visible from the original message alone.
A recent ANY.RUN investigation shows why this matters. Researchers found a dangerous phishing campaign targeting U.S. organizations, especially in high-exposure industries such as Education, Banking, Government, Technology, and Healthcare. The attack looked routine at first: a fake invitation, a CAPTCHA check, and an event-themed page. But behind that flow, the campaign could lead to credential theft, OTP capture, or delivery of legitimate RMM tools.
Expand your team’s phishing analysis capacity before the next threat becomes a serious incident.
Claim bonus seats and special pricing while the offer is available until May 31.
Inside ANY.RUN’s interactive sandbox, the full attack chain was exposed in just 40 seconds: redirects, fake pages, credential prompts, downloads, and signs of possible remote access. That is the speed security teams need when every minute of uncertainty can increase exposure.
38 seconds needed to analyze the full attack chain of complicated phishing attack inside ANY.RUN’s sandbox
After the sandbox exposes the full attack path, leadership gets what phishing investigations often lack: early proof of business exposure. Instead of waiting for signs of account abuse or endpoint compromise, the SOC can understand the risk while there is still time to contain it.
With that proof, teams can:
confirm whether the link creates real exposure
act before compromised accounts or endpoints become a wider problem
give leadership the evidence needed to approve fast containment
Step 2: Contextualize One Attack into Full Threat Landscape
Once the sandbox exposes the phishing behavior, the next step is to understand whether the threat is isolated or part of a wider campaign. This is where ANY.RUN’s threat intelligence solutions help teams move from one suspicious link to a broader view of the threat.
In the fake invitation campaign, the sandbox revealed repeatable patterns across phishing pages, including requests to /favicon.ico, /blocked.html, and resources stored under /Image/*.png. These details are valuable because they help connect related domains, pages, and infrastructure that may belong to the same campaign.
Relevant analysis sessions displayed with ANY.RUN’s Threat Intelligence for broader context and full behavior visibility
Once the threat context is expanded, teams are no longer reacting to one alert in isolation. They can understand how far the campaign may reach, which areas of the business are most exposed, and whether the response should stay limited or scale across users, departments, or clients.
That wider view helps CISOs:
prioritize response based on campaign scale, not a single phishing link
reduce blind spots across users, regions, and business units
make faster decisions on blocking, hunting, and escalation before more exposure builds up
Step 3: Keep Defenses Current for Early Risk Awareness
Once the threat is validated and enriched, the next step is to make that intelligence usable across the tools the SOC already depends on. The goal is not to keep findings inside one investigation, but to turn them into detection, blocking, enrichment, and response across the environment.
With ANY.RUN’s threat intelligence solutions, teams can use behavior-based IOCs and campaign context across SIEM, TIP, SOAR, NDR, firewalls, and other security tools. Built from real attack analysis across 15,000 organizations and 600,000 security professionals, this intelligence gives teams fresh context they can apply directly inside existing workflows.
ANY.RUN’s TI Feeds provides fresh, behavior-based IOCs across security stack
This helps teams move from “we analyzed one phishing link” to “we can now look for related exposure across the business.” The collected intelligence can surface related domains, repeated URL paths, suspicious requests, downloaded files, or signs of RMM activity connected to the same campaign.
For CISOs, this is where phishing intelligence becomes operational control. It helps teams:
use existing security investments to detect related activity faster
reduce blind spots across email, network, endpoint, identity, and cloud data
act before one phishing case turns into broader business exposure
This process closes the loop: the sandbox proves the behavior, threat intelligence expands the context, and the security stack helps teams find and stop related threats before they spread.
Get Special ANY.RUN Offers Before May 31
To celebrate its 10th anniversary, ANY.RUN is offering special conditions for teams that want to strengthen phishing analysis, threat intelligence, and SOC response workflows.
ANY.RUN special offers for stronger SOC and earlier threat visibility
Until May 31, teams can access anniversary offers across key ANY.RUN solutions:
Interactive Sandbox: Bonus seats and exclusive pricing for teams that need in-depth malware and phishing analysis.
Threat Intelligence solutions: Extra months to bring fresher intelligence into detection, investigation, and response.
For SOCs, this is a good moment to expand phishing visibility, bring fresh threat intelligence into existing workflows, and improve response readiness without slowing down operations.
Get a special offer now to strengthen phishing detection and help your SOC act before exposure spreads.
Turn Early Phishing Detection into Measurable SOC Impact
Early phishing detection matters because delay is where risk grows. When a suspicious link gets through, every extra minute can mean more uncertainty, more manual work, and more time before the team knows whether accounts, endpoints, or business systems are exposed.
Teams report 3x stronger SOC efficiency with ANY.RUN’s solutions
ANY.RUN helps close that gap between the first phishing signal and confident response. Teams can analyze the link safely, confirm what it does, enrich the findings with related threat context, and push that intelligence into their security stack to find and stop connected activity across the environment.
Teams using ANY.RUN report:
21 minutes faster MTTR per case to reduce the window between phishing detection and containment
94% faster triage reported by users to cut uncertainty around suspicious links
30% fewer Tier 1 to Tier 2 escalations to protect senior team capacity
Up to 20% lower Tier 1 workload to reduce alert fatigue and manual investigation effort
Up to 3x stronger SOC efficiency across validation, enrichment, and response workflows
Close phishing blind spots before they turn into business exposure. Get bonus seats and special pricing to expand SOC visibility while the offer is available.
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/guyX9w7
via IFTTT
