Author: Mark

  • React2Shell Exploitation Escalates into Large-Scale Global Attacks, Forcing Emergency Mitigation

    React2Shell Exploitation Escalates into Large-Scale Global Attacks, Forcing Emergency Mitigation

    Dec 12, 2025Ravie LakshmananVulnerability / Threat Intelligence

    The U.S. Cybersecurity and Infrastructure Security Agency (CISA) has urged federal agencies to patch the recent React2Shell vulnerability by December 12, 2025, amid reports of widespread exploitation.

    The critical vulnerability, tracked as CVE-2025-55182 (CVSS score: 10.0), affects the React Server Components (RSC) Flight protocol. The underlying cause of the issue is an unsafe deserialization that allows an attacker to inject malicious logic that the server executes in a privileged context. It also affects other frameworks, including Next.js, Waku, Vite, React Router, and RedwoodSDK.

    “A single, specially crafted HTTP request is sufficient; there is no authentication requirement, user interaction, or elevated permissions involved,” Cloudforce One, Cloudflare’s threat intelligence team, said. “Once successful, the attacker can execute arbitrary, privileged JavaScript on the affected server.”

    Since its public disclosure on December 3, 2025, the shortcoming has been exploited by multiple threat actors in various campaigns to engage in reconnaissance efforts and deliver a wide range of malware families.

    Cybersecurity

    The development prompted CISA to add it to its Known Exploited Vulnerabilities catalog last Friday, giving federal agencies until December 26 to apply the fixes. The deadline has since been revised to December 12, 2025, an indication of the severity of the incident.

    Cloud security company Wiz said it has observed a “rapid wave of opportunistic exploitation” of the flaw, with a vast majority of the attacks targeting internet-facing Next.js applications and other containerized workloads running in Kubernetes and managed cloud services.

    Image Source: Cloudflare

    Cloudflare, which is also tracking ongoing exploitation activity, said threat actors have conducted searches using internet-wide scanning and asset discovery platforms to find exposed systems running React and Next.js applications. Notably, some of the reconnaissance efforts have excluded Chinese IP address spaces from their searches.

    “Their highest-density probing occurred against networks in Taiwan, Xinjiang Uyghur, Vietnam, Japan, and New Zealand – regions frequently associated with geopolitical intelligence collection priorities,” the web infrastructure company said.

    The observed activity is also said to have targeted, albeit more selectively, government (.gov) websites, academic research institutions, and critical‑infrastructure operators. This included a national authority responsible for the import and export of uranium, rare metals, and nuclear fuel.

    Some of the other notable findings are listed below –

    • Prioritizing high‑sensitivity technology targets such as enterprise password managers and secure‑vault services, likely with the goal of perpetrating supply chain attacks
    • Targeting edge‑facing SSL VPN appliances whose administrative interfaces may incorporate React-based components
    • Early scanning and exploitation attempts originated from IP addresses previously associated with Asia-affiliated threat clusters

    In its own analysis of honeypot data, Kaspersky said it recorded over 35,000 exploitation attempts on a single day on December 10, 2025, with the attackers first probing the system by running commands like whoami, before dropping cryptocurrency miners or botnet malware families like Mirai/Gafgyt variants and RondoDox.

    Security researcher Rakesh Krishnan has also discovered an open directory hosted on “154.61.77[.]105:8082” that includes a proof-of-concept (PoC) exploit script for CVE-2025–55182 along with two other files –

    • “domains.txt,” which contains a list of 35,423 domains
    • “next_target.txt,” which contains a list of 596 URLs, including companies like Dia Browser, Starbucks, Porsche, and Lululemon
    Cybersecurity

    It has been assessed that the unidentified threat actor is actively scanning the internet based on targets added to the second file, infecting hundreds of pages in the process.

    According to the latest data from The Shadowserver Foundation, there are more than 137,200 internet-exposed IP addresses running vulnerable code as of December 11, 2025. Of these, over 88,900 instances are located in the U.S., followed by Germany (10,900), France (5,500), and India (3,600).


    Source: thehackernews.com…

  • CISA Flags Actively Exploited GeoServer XXE Flaw in Updated KEV Catalog

    CISA Flags Actively Exploited GeoServer XXE Flaw in Updated KEV Catalog

    Dec 12, 2025Ravie LakshmananVulnerability / Server Security

    The U.S. Cybersecurity and Infrastructure Security Agency (CISA) on Thursday added a high-severity security flaw impacting OSGeo GeoServer to its Known Exploited Vulnerabilities (KEV) catalog, based on evidence of active exploitation in the wild.

    The vulnerability in question is CVE-2025-58360 (CVSS score: 8.2), an unauthenticated XML External Entity (XXE) flaw that affects all versions prior to and including 2.25.5, and from versions 2.26.0 through 2.26.1. It has been patched in versions 2.25.6, 2.26.2, 2.27.0, 2.28.0, and 2.28.1. Artificial intelligence (AI)-powered vulnerability discovery platform XBOW has been acknowledged for reporting the issue.

    “OSGeo GeoServer contains an improper restriction of XML external entity reference vulnerability that occurs when the application accepts XML input through a specific endpoint /geoserver/wms operation GetMap and could allow an attacker to define external entities within the XML request,” CISA said.

    Cybersecurity

    The following packages are affected by the flaw –

    • docker.osgeo.org/geoserver
    • org.geoserver.web:gs-web-app (Maven)
    • org.geoserver:gs-wms (Maven)

    Successful exploitation of the vulnerability could allow an attacker to access arbitrary files from the server’s file system, conduct Server-Side Request Forgery (SSRF) to interact with internal systems, or launch a denial-of-service (DoS) attack by exhausting resources, the maintainers of the open-source software said in an alert published late last month.

    There are currently no details available on how the security defect is being abused in real-world attacks. However, a bulletin from the Canadian Centre for Cyber Security on November 28, 2025, said “an exploit for CVE-2025-58360 exists in the wild.”

    It’s worth noting that another critical flaw in the same software (CVE-2024-36401, CVSS score: 9.8) has been exploited by multiple threat actors over the past year. Federal Civilian Executive Branch (FCEB) agencies are advised to apply the required fixes by January 1, 2026, to secure their networks.


    Source: thehackernews.com…

  • Securing GenAI in the Browser: Policy, Isolation, and Data Controls That Actually Work

    Securing GenAI in the Browser: Policy, Isolation, and Data Controls That Actually Work

    Securing GenAI in the Browser

    The browser has become the main interface to GenAI for most enterprises: from web-based LLMs and copilots, to GenAI‑powered extensions and agentic browsers like ChatGPT Atlas. Employees are leveraging the power of GenAI to draft emails, summarize documents, work on code, and analyze data, often by copying/pasting sensitive information directly into prompts or uploading files.

    Traditional security controls were not designed to understand this new prompt‑driven interaction pattern, leaving a critical blind spot where risk is highest. Security teams are simultaneously under pressure to enable more GenAI platforms because they clearly boost productivity.

    Simply blocking AI is unrealistic. The more sustainable approach is to secure GenAI platforms where they are accessed by users: inside the browser session.

    The GenAI browser threat model

    The GenAI‑in‑the‑browser threat model must be approached differently from traditional web browsing due to several key factors.

    1. Users routinely paste entire documents, code, customer records, or sensitive financial information into prompt windows. This can lead to data exposure or long‑term retention in the LLM system.
    2. File uploads create similar risks when documents are processed outside of approved data‑handling pipelines or regional boundaries, putting organizations in jeopardy of violating regulations.
    3. GenAI browser extensions and assistants often require broad permissions to read and modify page content. This includes data from internal web apps that users never intended to share with external services.
    4. Mixed use of personal and corporate accounts in the same browser profile complicates attribution and governance.

    All of these behaviors put together create a risk surface that is invisible to many legacy controls.

    Policy: defining safe use in the browser

    A workable GenAI security strategy in the browser is a clear, enforceable policy that defines what “safe use” means.

    CISOs should categorize GenAI tools into sanctioned services and allow/disallow public tools and applications with different risk treatments and monitoring levels. After setting clear boundaries, enterprises can then align browser‑level enforcement so that the user experience matches the policy intent.

    A strong policy consists of specifications around which data types are never allowed in GenAI prompts or uploads. Common restricted categories can include regulated personal data, financial details, legal information, trade secrets, and source code. The policy language should also be concrete and consistently enforced by technical controls rather than relying on user judgment.

    Behavioral guardrails that users can live with

    Beyond allowing or disallowing applications, enterprises need guardrails that define how employees should access and use GenAI in the browser. Requiring single sign‑on and corporate identities for all sanctioned GenAI services can improve visibility and control while reducing the likelihood that data ends up in unmanaged accounts.

    Exception handling is equally important, as teams such as research or marketing may require more permissive GenAI access. Others, like finance or legal, may need stricter guardrails. A formal process for requesting policy exceptions, time‑based approvals, and review cycles allows flexibility. These behavioral elements make technical controls more predictable and acceptable to end users.

    Isolation: containing risk without harming productivity

    Isolation is the second major pillar of securing browser-based GenAI use. Instead of a binary model, organizations can use specific approaches to reduce risk when GenAI is being accessed. Dedicated browser profiles, for example, create boundaries between sensitive internal apps and GenAI‑heavy workflows.

    Per‑site and per‑session controls provide another layer of defense. For example, a security team may allow GenAI access to designated “safe” domains while restricting the ability of AI tools and extensions to read content from high‑sensitivity applications like ERP or HR systems.

    This approach enables employees to continue using GenAI for generic tasks while reducing the likelihood that confidential data is being shared with third‑party tools accessed inside the browser.

    Data controls: precision DLP for prompts and pages

    Policy defines the intent, and isolation limits exposure. Data controls provide the precise enforcement mechanism at the browser edge. Inspecting user actions like copy/paste, drag‑and‑drop, and file uploads at the point where they leave trusted apps and enter GenAI interfaces is critical.

    Effective implementations should support multiple enforcement modes: monitor‑only, user warnings, in‑time education, and hard blocks for clearly prohibited data types. This tiered approach helps reduce user friction while preventing serious leaks.

    Managing GenAI browser extensions

    GenAI‑powered browser extensions and side panels are a tricky risk category. Many offers convenient features like page summarizations, creating replies, or data extraction. But doing so often requires extensive permissions to read and modify page content, keystrokes, and clipboard data. Without oversight, these extensions can become an exfiltration channel for sensitive information.

    CISOs must be aware of the AI‑powered extensions in use at their enterprise, classify them by risk level, and enforce a default‑deny or allowed with restrictions list. Using a Secure Enterprise Browser (SEB) for continuous monitoring of newly installed or updated extensions helps identify changes in permissions that may introduce new risks over time.

    Identity, accounts, and session hygiene

    Identity and session handling are central to GenAI browser security because they determine which data belongs to which account. Enforcing SSO for sanctioned GenAI platforms and tying usage back to enterprise identities will simplify logging and incident response. Browser‑level controls can help prevent cross‑access between work and personal contexts. For example, organizations can block copying content from corporate apps into GenAI applications when the user has not been authenticated into a corporate account.

    Visibility, telemetry, and analytics

    Ultimately, a working GenAI security program relies on accurate visibility into how employees are using browser-based GenAI tools. Tacking which domains and apps are accessed, the contents being entered into prompts, and how often policies trigger warnings or blocks are all necessary. Aggregating this telemetry into existing logging and SIEM infrastructure allows security teams to identify patterns, outliers, and incidents.

    Analytics built on this data can help highlight genuine risk. For example, enterprises can make a clear determination between non‑sensitive vs proprietary source code being entered into prompts. Using this information, SOC teams can refine rules, adjust isolation levels, and target training where it will provide the greatest impact.

    Change management and user education

    CISOs with successful GenAI security programs invest in the time to explain the “why” behind restrictions. By sharing concrete scenarios that resonate with different roles, you can reduce the chances of your program failing – developers need examples related to IP, while sales and support staff benefit from stories about customer trust and contract details. Sharing scenario‑based content with relevant parties will reinforce good habits in the right moments.

    When employees understand that guardrails are designed to preserve their ability to use GenAI at scale, not hinder them, they are more likely to follow the guidelines. Aligning communications with broader AI governance initiatives helps position browser‑level controls as part of a cohesive strategy rather than an isolated one.

    A practical 30‑day rollout approach

    Many organizations are looking for a pragmatic path to move from ad‑hoc browser-based GenAI usage to a structured, policy‑driven model.

    One effective way of doing so is utilizing a Secure Enterprise Browsing (SEB) platform that can provide you with the visibility and reach needed. With the right SEB you can map the current GenAI tools used within your enterprise, so you can create policy decisions like monitoring‑only or warn‑and‑educate modes for clearly risky behaviors. Over the following weeks, enforcement can be expanded to more users and higher‑risk data types, FAQs, and training.

    By the end of a 30‑day period, many organizations can formalize their GenAI browser policy, integrate alerts into SOC workflows, and establish a cadence for adjusting controls as usage evolves.

    Turning the browser into the GenAI control plane

    As GenAI continues to spread across SaaS apps and web pages, the browser remains the central interface through which most employees access them. The best GenAI protections simply cannot be worked into legacy perimeter controls. Enterprises can achieve the best results by treating the browser as the primary control plane. This approach enables security teams with meaningful ways to reduce data leakage and compliance risk while simultaneously preserving the productivity benefits that make GenAI so powerful.

    With well‑designed policies, measured isolation strategies, and browser‑native data protections, CISOs can move from reactive blocking to confident, large‑scale enablement of GenAI across their entire workforce.

    To learn more about Secure Enterprise Browsers (SEB) and how they can secure GenAI use at your organization, speak to a Seraphic expert.

    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.


    Source: thehackernews.com…

  • New React RSC Vulnerabilities Enable DoS and Source Code Exposure

    New React RSC Vulnerabilities Enable DoS and Source Code Exposure

    Dec 12, 2025Ravie LakshmananSoftware Security / Vulnerability

    The React team has released fixes for two new types of flaws in React Server Components (RSC) that, if successfully exploited, could result in denial-of-service (DoS) or source code exposure.

    The team said the issues were found by the security community while attempting to exploit the patches released for CVE-2025-55182 (CVSS score: 10.0), a critical bug in RSC that has since been weaponized in the wild.

    The three vulnerabilities are listed below –

    • CVE-2025-55184 (CVSS score: 7.5) – A pre-authentication denial of service vulnerability arising from unsafe deserialization of payloads from HTTP requests to Server Function endpoints, triggering an infinite loop that hangs the server process and may prevent future HTTP requests from being served
    • CVE-2025-67779 (CVSS score: 7.5) – An incomplete fix for CVE-2025-55184 that has the same impact
    • CVE-2025-55183 (CVSS score: 5.3) – An information leak vulnerability that may cause a specifically crafted HTTP request sent to a vulnerable Server Function to return the source code of any Server Function

    However, successful exploitation of CVE-2025-55183 requires the existence of a Server Function that explicitly or implicitly exposes an argument that has been converted into a string format.

    Cybersecurity

    The flaws affecting the following versions of react-server-dom-parcel, react-server-dom-turbopack, and react-server-dom-webpack –

    • CVE-2025-55184 and CVE-2025-55183 – 19.0.0, 19.0.1 19.1.0, 19.1.1, 19.1.2, 19.2.0 and 19.2.1
    • CVE-2025-67779 – 19.0.2, 19.1.3 and 19.2.2

    Security researcher RyotaK and Shinsaku Nomura have been credited with reporting the two DoS bugs to the Meta Bug Bounty program, while Andrew MacPherson has been acknowledged for reporting the information leak flaw.

    Users are advised to update to versions 19.0.3, 19.1.4, and 19.2.3 as soon as possible, particularly in light of active exploration of CVE-2025-55182.

    “When a critical vulnerability is disclosed, researchers scrutinize adjacent code paths looking for variant exploit techniques to test whether the initial mitigation can be bypassed,” the React team said. “This pattern shows up across the industry, not just in JavaScript. Additional disclosures can be frustrating, but they are generally a sign of a healthy response cycle.”


    Source: thehackernews.com…

  • WIRTE Leverages AshenLoader Sideloading to Install the AshTag Espionage Backdoor

    WIRTE Leverages AshenLoader Sideloading to Install the AshTag Espionage Backdoor

    Dec 11, 2025Ravie LakshmananCyberwarfare / Threat Intelligence

    An advanced persistent threat (APT) known as WIRTE has been attributed to attacks targeting government and diplomatic entities across the Middle East with a previously undocumented malware suite dubbed AshTag since 2020.

    Palo Alto Networks Unit 42 is tracking the activity cluster under the name Ashen Lepus. Artifacts uploaded to the VirusTotal platform show that the threat actor has trained its sights on Oman and Morocco, indicating an expansion in operational scope beyond the Palestinian Authority, Jordan, Iraq, Saudi Arabia, and Egypt.

    The company told The Hacker News said it has observed “scores of unique lures” disseminated across the Middle East, indicating a “persistent and wide-reaching campaign” confined to government and diplomatic entities in the region. More than a dozen entities are estimated to have been targeted, although it’s suspected that the real number could be higher.

    “Ashen Lepus remained persistently active throughout the Israel-Hamas conflict, distinguishing it from other affiliated groups whose activities decreased over the same period,” the cybersecurity company said in a report shared with The Hacker News. “Ashen Lepus continued with its campaign even after the October 2025 Gaza ceasefire, deploying newly developed malware variants and engaging in hands-on activity within victim environments.”

    Cybersecurity

    WIRTE, which overlaps with an Arabic-speaking, politically motivated cluster known as Gaza Cyber Gang (aka Blackstem, Extreme Jackal, Molerats, or TA402), is assessed to be active since at least 2018. According to a report from Cybereason, both Molerats and APT-C-23 (aka Arid Viper, Desert Varnish, or Renegade Jackal) are two main sub-groups of the Hamas cyberwarfare division.

    It’s primarily driven by espionage and intelligence collection, targeting government entities in the Middle East to meet its strategic objectives.

    “Specifically, the connection between WIRTE (Ashen Lepus) to the broader Gaza Cyber Gang is primarily evidenced by code overlaps and similarities,” Unit 42 researchers said. “This suggests that while they operate independently, the tools were developed by close entities and they likely share development resources. We have also seen overlap in other groups’ victimology.”

    In a report published in November 2024, Check Point attributed the hacking crew to destructive attacks exclusively aimed at Israeli entities to infect them with a custom wiper malware referred to as SameCoin, highlighting their ability to adapt and carry out both espionage and sabotage.

    The long-running, elusive campaign detailed by Unit 42, going all the way back to 2018, has been found to leverage phishing emails with lures related to geopolitical affairs in the region. A recent increase in lures related to Turkey – e.g., “Partnership agreement between Morocco and Turkey” or “Draft resolutions concerning the State of Palestine” – suggests that entities in the country may be a new area of focus.

    The attack chains commence with a harmless PDF decoy that tricks recipients into downloading a RAR archive from a file-sharing service. Opening the archive triggers a chain of events that results in the deployment of AshTag.

    This involves using a renamed benign binary to sideload a malicious DLL dubbed AshenLoader that, in addition to opening a decoy PDF file to keep up the ruse, contacts an external server to drop two more components, a legitimate executable and a DLL payload called AshenStager (aka stagerx64) that’s again sideloaded to launch the malware suite in memory to minimize forensic artifacts.

    AshTag is a modular .NET backdoor that’s designed to facilitate persistence and remote command execution, while masquerading as a legitimate VisualServer utility to fly under the radar. Internally, its features are realized by means of an AshenOrchestrator to enable communications and to run additional payloads in memory.

    Cybersecurity

    These payloads serve different purposes –

    • Persistence and process management
    • Update and removal
    • Screen capture
    • File explorer and management
    • System fingerprinting

    In one case, Unit 42 said it observed the threat actor accessing a compromised machine to conduct hands-on data theft by staging documents of interest in the C:UsersPublic folder. These files are said to have been downloaded from a victim’s email inbox, their end goal being the theft of diplomacy-related documents. The documents were then exfiltrated to an attacker-controlled server using the Rclone utility.

    It’s assessed that data theft has likely occurred across the broader victim population, particularly in environments where advanced detection capabilities are absent.

    “Ashen Lepus remains a persistent espionage actor, demonstrating a clear intent to continue its operations throughout the recent regional conflict — unlike other affiliated threat groups, whose activity significantly decreased,” the company concluded. “The threat actors’ activities throughout the last two years in particular highlight their commitment to constant intelligence collection.”


    Source: thehackernews.com…

  • The Impact of Robotic Process Automation (RPA) on Identity and Access Management

    The Impact of Robotic Process Automation (RPA) on Identity and Access Management

    Dec 11, 2025The Hacker NewsAutomation / Compliance

    As enterprises refine their strategies for handling Non-Human Identities (NHIs), Robotic Process Automation (RPA) has become a powerful tool for streamlining operations and enhancing security. However, since RPA bots have varying levels of access to sensitive information, enterprises must be prepared to mitigate a variety of challenges. In large organizations, bots are starting to outnumber human employees, and without proper identity lifecycle management, these bots increase security risks. RPA impacts Identity and Access Management (IAM) by managing bot identities, enforcing least-privilege access and ensuring auditability across all accounts.

    Continue reading to learn more about RPA, its challenges with IAM and best practices organizations should follow to secure RPA within IAM.

    What is Robotic Process Automation (RPA)?

    Robotic Process Automation (RPA) uses bots to automate repetitive tasks that are traditionally performed by human users. In the context of IAM, RPA plays an essential role in streamlining the user lifecycle, including provisioning, deprovisioning and secure access to credentials. These RPA bots act as NHIs and require governance just as human users do for authentication, access controls and privileged session monitoring. As RPA adoption grows, IAM systems must consistently manage both human identities and NHIs within a unified security framework. Here are the key benefits of RPA:

    • Improved efficiency and speed: RPA automates time-consuming, repetitive tasks like provisioning and deprovisioning, enabling IT teams to focus on higher-priority tasks.
    • Better accuracy: RPA minimizes human error and reduces the risk of misconfigurations by following pre-defined scripts. Bots also automate credential handling and eliminate common issues like password reuse.
    • Enhanced security: RPA strengthens IAM by triggering immediate deprovisioning once an employee leaves an organization. Automated bots can also detect and respond to behavioral anomalies in real time, limiting the impact of unauthorized access.
    • Stronger compliance: RPA supports regulatory compliance mandates by automatically logging every bot action and enforcing access policies. Combined with zero-trust security principles, RPA enables continuous verification of all identities — human or machine.

    Challenges RPA introduces into IAM

    As organizations scale their use of RPA, several challenges emerge that can weaken the efficiency of existing IAM strategies, including bot management, larger attack surfaces and integration difficulties.

    Managing bots

    RPA bots are taking on more critical tasks across enterprises, and managing their identities and access becomes a top priority. Unlike human users, bots work silently in the background but still require authentication and authorization. Without appropriate identity governance, improperly monitored bots can create security gaps within an organization’s IAM. A common problem is how bots store credentials, often embedding hardcoded passwords or API keys in scripts or configuration files.

    Increased attack surface

    Each RPA bot has a new NHI, and each NHI introduces a potential attack vector for cybercriminals to exploit. Without strictly enforcing the Principle of Least Privilege (PoLP), bots may be overprovisioned with access that exceeds their needs for repetitive tasks. If compromised, bots can be used to move laterally within a network or exfiltrate sensitive data. Securing bots’ privileged access and managing their credentials with Just-in-Time (JIT) access is crucial to maintaining zero-trust security.

    Integration difficulties

    Many legacy IAM systems were not built with modern RPA integrations in mind, making it challenging for enterprises to enforce consistent access policies across both human users and NHIs. Integration gaps can result in unmanaged credentials, insufficient audit trails and inconsistent enforcement of access controls. Without alignment between RPA and IAM, organizations risk having less visibility and inconsistencies across automated processes.

    Best practices for securing RPA within IAM

    Securing RPA within IAM requires more than just granting bots access; organizations must treat automated processes with the same attention to detail as they do for human users. Here are some best practices to ensure RPA deployments remain secure and aligned with zero-trust security principles.

    1. Prioritize bot identities

    Treating RPA bots as first-class identities is crucial to maintaining strong IAM. Since bots interact with core systems and often operate with elevated privileges, it’s important to ensure each bot has only the minimum level of access required for its specific task. Each bot should be assigned an identity with its own unique credentials so they are never shared or reused across other bots or services. This approach to bot management allows security teams to grant or revoke access without disrupting broader workflows and to better track each bot’s activities.

    2. Use a secrets manager

    RPA bots typically interact with critical systems and APIs, relying on credentials or SSH keys to function. Storing these secrets in plaintext configuration files or scripts makes them easy targets for cybercriminals and difficult to securely rotate. A dedicated secrets management tool like Keeper® ensures that all credentials are encrypted and centrally managed in a zero-knowledge vault. Secrets can be retrieved at runtime, so they never reside in memory or on a device.

    3. Implement PAM

    Bots that perform repetitive, administrative tasks often require privileged access, making Privileged Access Management (PAM) essential. PAM solutions should enforce JIT access, ensuring bots receive privileged access only when needed and for a limited time. With session monitoring and recording to maintain transparency and detect unusual bot activity, implementing PAM eliminates standing access and helps prevent privilege escalation.

    4. Strengthen authentication with MFA

    Human users managing RPA bots must be required to authenticate using Multi-Factor Authentication (MFA). Since MFA is not practical for bot accounts themselves, having an extra layer of protection for the users managing them helps prevent unauthorized access to critical systems, sensitive data and privileged credentials. In addition, organizations should adopt Zero-Trust Network Access (ZTNA) principles by continuously verifying bot identities and context, not only at login but throughout each privileged session.

    Secure the future of automation with IAM

    Automation continues to transform how enterprises operate, largely driven by the rise of NHIs like RPA bots. To keep up with this technological evolution, organizations must adjust their IAM strategies to accommodate and secure both human users and automated bots. KeeperPAM® helps enterprises close potential security gaps, such as credential theft and privilege misuse, by providing a unified platform for managing credentials, enforcing PoLP, monitoring privileged sessions and managing the full identity lifecycle of every identity — human or not.

    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.


    Source: thehackernews.com…

  • NANOREMOTE Malware Uses Google Drive API for Hidden Control on Windows Systems

    NANOREMOTE Malware Uses Google Drive API for Hidden Control on Windows Systems

    Dec 11, 2025Ravie LakshmananCyber Espionage / Windows Security

    Cybersecurity researchers have disclosed details of a new fully-featured Windows backdoor called NANOREMOTE that uses the Google Drive API for command-and-control (C2) purposes.

    According to a report from Elastic Security Labs, the malware shares code similarities with another implant codenamed FINALDRAFT (aka Squidoor) that employs Microsoft Graph API for C2. FINALDRAFT is attributed to a threat cluster known as REF7707 (aka CL-STA-0049, Earth Alux, and Jewelbug).

    “One of the malware’s primary features is centered around shipping data back and forth from the victim endpoint using the Google Drive API,” Daniel Stepanic, principal security researcher at Elastic Security Labs, said.

    Cybersecurity

    “This feature ends up providing a channel for data theft and payload staging that is difficult for detection. The malware includes a task management system used for file transfer capabilities that include queuing download/upload tasks, pausing/resuming file transfers, canceling file transfers, and generating refresh tokens.”

    REF7707 is believed to be a suspected Chinese activity cluster that has targeted governments, defense, telecommunication, education, and aviation sectors in Southeast Asia and South America as far back as March 2023, per Palo Alto Networks Unit 42. In October 2025, Broadcom-owned Symantec attributed the hacking group to a five-month-long intrusion targeting a Russian IT service provider.

    The exact initial access vector used to deliver NANOREMOTE is currently not known. However, the observed attack chain includes a loader named WMLOADER that mimics a Bitdefender’s crash handling component (“BDReinit.exe”) and decrypts shellcode responsible for launching the backdoor.

    Written in C++, NANOREMOTE is equipped to perform reconnaissance, execute files and commands, and transfer files to and from victim environments using the Google Drive API. It’s also preconfigured to communicate with a hard-coded, non-routable IP address over HTTP to process requests sent by the operator and send the response back.

    “These requests occur over HTTP where the JSON data is submitted through POST requests that are Zlib compressed and encrypted with AES-CBC using a 16-byte key (558bec83ec40535657833d7440001c00),” Elastic said. “The URI for all requests use /api/client with User-Agent (NanoRemote/1.0).”

    Cybersecurity

    Its primary functionality is realized through a set of 22 command handlers that allow it to collect host information, carry out file and directory operations, run portable executable (PE) files already present on disk, clear cache, download/upload files to Google Drive, pause/resume/cancel data transfers, and terminate itself.

    Elastic said it identified an artifact (“wmsetup.log“) uploaded to VirusTotal from the Philippines on October 3, 2025, that’s capable of being decrypted by WMLOADER with the same 16-byte key to reveal a FINALDRAFT implant, indicating that the two malware families are likely the work of the same threat actor. It’s unclear as to why the same hard-coded key is being used across both of them.

    “Our hypothesis is that WMLOADER uses the same hard-coded key due to being part of the same build/development process that allows it to work with various payloads,” Stepanic said. “This appears to be another strong signal suggesting a shared codebase and development environment between FINALDRAFT and NANOREMOTE.”


    Source: thehackernews.com…

  • ThreatsDay Bulletin: Spyware Alerts, Mirai Strikes, Docker Leaks, ValleyRAT Rootkit — and 20 More Stories

    ThreatsDay Bulletin: Spyware Alerts, Mirai Strikes, Docker Leaks, ValleyRAT Rootkit — and 20 More Stories

    Dec 11, 2025Ravie Lakshmanan

    This week’s cyber stories show how fast the online world can turn risky. Hackers are sneaking malware into movie downloads, browser add-ons, and even software updates people trust. Tech giants and governments are racing to plug new holes while arguing over privacy and control. And researchers keep uncovering just how much of our digital life is still wide open.

    The new Threatsday Bulletin brings it all together—big hacks, quiet exploits, bold arrests, and smart discoveries that explain where cyber threats are headed next.

    It’s your quick, plain-spoken look at the week’s biggest security moves before they become tomorrow’s headlines.

    1. Maritime IoT under siege

      A new Mirai botnet variant dubbed Broadside has been exploiting a critical-severity vulnerability in TBK DVR (CVE-2024-3721) in attacks targeting the maritime logistics sector. “Unlike previous Mirai variants, Broadside employs a custom C2 protocol, a unique ‘Magic Header; signature, and an advanced ‘Judge, Jury, and Executioner’ module for exclusivity,” Cydome said. “Technically, it diverges from standard Mirai by utilizing Netlink kernel sockets for stealthy, event-driven process monitoring (replacing noisy filesystem polling), and employing payload polymorphism to evade static defenses.” Specifically, it tries to maintain exclusive control over the host by terminating other processes that match specific path patterns, fail internal checks, or have already been classified as hostile. Broadside extends beyond denial-of-service attacks, as it attempts to harvest system credential files (/etc/passwd and /etc/shadow) with an aim to establish a strategic foothold into compromised devices. Mirai is a formidable botnet that has spawned several variants since its source code was leaked in 2016.

    Cybersecurity isn’t just a tech issue anymore—it’s part of daily life. The same tools that make work and communication easier are the ones attackers now use to slip in unnoticed. Every alert, patch, or policy shift connects to a bigger story about how fragile digital trust has become.

    As threats keep evolving, staying aware is the only real defense. The Threatsday Bulletin exists for that reason—to cut through the noise and show what actually matters in cybersecurity right now. Read on for this week’s full rundown of breaches, discoveries, and decisions shaping the digital world.


    Source: thehackernews.com…

  • Active Attacks Exploit Gladinet's Hard-Coded Keys for Unauthorized Access and Code Execution

    Active Attacks Exploit Gladinet's Hard-Coded Keys for Unauthorized Access and Code Execution

    Dec 11, 2025Ravie LakshmananVulnerability / Encryption

    Huntress is warning of a new actively exploited vulnerability in Gladinet’s CentreStack and Triofox products stemming from the use of hard-coded cryptographic keys that have affected nine organizations so far.

    “Threat actors can potentially abuse this as a way to access the web.config file, opening the door for deserialization and remote code execution,” security researcher Bryan Masters said.

    The use of hard-coded cryptographic keys could allow threat actors to decrypt or forge access tickets, enabling them to access sensitive files like web.config that can be exploited to achieve ViewState deserialization and remote code execution, the cybersecurity company added.

    At its core, the issue is rooted in a function named “GenerateSecKey()” present in “GladCtrl64.dll” that’s used to generate the cryptographic keys necessary to encrypt access tickets containing authorization data (i.e., Username and Password) and enable access to the file system as a user, assuming the credentials are valid.

    Cybersecurity

    Because the GenerateSecKey() function returns the same 100-byte text strings and these strings are used to derive the cryptographic keys, the keys never change and can be weaponized to decrypt any ticket generated by the server or even encrypt one of the attacker’s choosing.

    This, in turn, opens the door to a scenario where it can be exploited to access files containing valuable data, such as the web.config file, and obtain the machine key required to perform remote code execution via ViewState deserialization.

    The attacks, according to Huntress, take the form of specially crafted URL requests to the “/storage/filesvr.dn” endpoint, such as below –

    /storage/filesvr.dn t=vghpI7EToZUDIZDdprSubL3mTZ2:aCLI:8Zra5AOPvX4TEEXlZiueqNysfRx7Dsd3P5l6eiYyDiG8Lvm0o41m:ZDplEYEsO5ksZajiXcsumkDyUgpV5VLxL%7C372varAu

    The attack efforts have been found to leave the Username and Password fields blank, causing the application to fall back to the IIS Application Pool Identity. What’s more, the timestamp field in the access ticket, which refers to the creation time of the ticket, is set to 9999, effectively creating a ticket that never expires, allowing the threat actors to reuse the URL indefinitely and download the server configuration.

    As of December 10, as many as nine organizations have been affected by the newly disclosed flaw. These organizations belong to a wide range of sectors, such as healthcare and technology. The attacks originate from the IP address 147.124.216[.]205 and attempt to chain together a previously disclosed flaw in the same applications (CVE-2025-11371) with the new exploit to access the machine key from the web.config file.

    “Once the attacker was able to obtain the keys, they performed a viewstate deserialization attack and then attempted to retrieve the output of the execution, which failed,” Huntress said.

    In light of active exploitation, organizations that are using CentreStack and Triofox should update to the latest version, 16.12.10420.56791, released on December 8, 2025. Additionally, it’s advised to scan logs for the presence of the string “vghpI7EToZUDIZDdprSubL3mTZ2,” which is the encrypted representation of the web.config file path.

    Cybersecurity

    In the event indicators or compromise (IoCs) are detected, it’s imperative that the machine key is rotated by following the steps below –

    • On Centrestack server, go to Centrestack installation folder C:Program Files (x86)Gladinet Cloud Enterpriseroot
    • Make a backup of web.config
    • Open IIS Manager
    • Navigate to Sites -> Default Web Site
    • In the ASP.NET section, double click Machine Key
    • Click ‘Generate Keys’ on the right pane
    • Click Apply to save it to rootweb.config
    • Restart IIS after repeating the same step for all worker nodes


    Source: thehackernews.com…

  • Unpatched Gogs Zero-Day Exploited Across 700+ Instances Amid Active Attacks

    Unpatched Gogs Zero-Day Exploited Across 700+ Instances Amid Active Attacks

    Dec 11, 2025Ravie LakshmananVulnerability / Cloud Security

    A high-severity unpatched security vulnerability in Gogs has come under active exploitation, with more than 700 compromised instances accessible over the internet, according to new findings from Wiz.

    The flaw, tracked as CVE-2025-8110 (CVSS score: 8.7), is a case of file overwrite in the file update API of the Go-based self-hosted Git service. A fix for the issue is said to be currently in the works. The company said it accidentally discovered the zero-day flaw in July 2025 while investigating a malware infection on a customer’s machine.

    “Improper symbolic link handling in the PutContents API in Gogs allows local execution of code,” according to a description of the vulnerability in CVE.org.

    The cloud security company said CVE-2025-8110 is a bypass for a previously patched remote code execution flaw (CVE-2024-55947, CVSS score: 8.7) that allows an attacker to write a file to an arbitrary path on the server and gain SSH access to the server. CVE-2024-55947 was addressed by the painters in December 2024.

    Cybersecurity

    Wiz said the fix put in place by Gogs to resolve CVE-2024-55947 could be circumvented by taking advantage of the fact that Git (and therefore, Gogs) allows symbolic links to be used in git repositories, and those symlinks can point to files or directories outside the repository. Additionally, the Gogs API allows file modification outside of the regular Git protocol.

    As a result, this failure to account for symlinks could be exploited by an attacker to achieve arbitrary code execution through a four-step process –

    • Create a standard git repository
    • Commit a single symbolic link pointing to a sensitive target
    • Use the PutContents API to write data to the symlink, causing the system to follow the link and overwrite the target file outside the repository
    • Overwrite “.git/config” (specifically the sshCommand) to execute arbitrary commands

    As for the malware deployed in the activity, it’s assessed to be a payload based on Supershell, an open-source command-and-control (C2) framework often used by Chinese hacking groups that can establish a reverse SSH shell to an attacker-controlled server (“119.45.176[.]196”).

    Wiz said that the attackers behind the exploitation of CVE-2025-8110 left behind the created repositories (e.g., “IV79VAew / Km4zoh4s”) on the customer’s cloud workload when they could have taken steps to delete or mark them as private following the infection. This carelessness points to a “smash-and-grab” style campaign, it added.

    In all, there are about 1,400 exposed Gogs instances, out of which more than 700 have exhibited signs of compromise, particularly the presence of 8-character random owner/repository names. All the identified repositories were created around July 10, 2025.

    “This suggests that a single actor, or perhaps a group of actors all using the same tooling, are responsible for all infections,” researchers Gili Tikochinski and Yaara Shriki said.

    Cybersecurity

    Given that the vulnerability does not have a fix, it’s essential that users disable open-registration, limit exposure to the internet, and scan instances for repositories with random 8-character names.

    The disclosure comes as Wiz also warned that threat actors are targeting leaked GitHub Personal Access Tokens (PAT) as high-value entry points to obtain initial access to victim cloud environments and even leverage them for cross-cloud lateral movement from GitHub to Cloud Service Provider (CSP) control plane.

    The issue at hand is that a threat actor with basic read permissions via a PAT can use GitHub’s API code search to discover secret names embedded directly in a workflow’s YAML code. To complicate matters further, if the exploited PAT has write permissions, attackers can execute malicious code and remove traces of their malicious activity.

    “Attackers leveraged compromised PATs to discover GitHub Action Secrets names in the codebase, and used them in newly created malicious workflows to execute code and obtain CSP secrets,” researcher Shira Ayal said. “Threat actors have also been observed exfiltrating secrets to a webhook endpoint they control, completely bypassing Action logs.”


    Source: thehackernews.com…