Tuesday, July 7, 2026

DEBULL Tooling Abuses Microsoft Device-Code Flow to Target M365 Accounts

A Microsoft 365 device code phishing campaign has been observed leveraging collaboration-themed lures to take control of victim accounts between the last week of June 2026 and into early July, per findings from ZeroBEC.

"The campaign did not depend on a fake Microsoft password page. It used a malicious collaboration-style lure to push users into the legitimate Microsoft device login experience, while a backend broker generated and polled Microsoft Authentication Broker device-code tokens," the email security company said in a report shared with The Hacker News.

The activity is assessed to share "strong" overlaps with a campaign documented by Microsoft in February 2025 under the moniker Storm-2372, including the use of messaging or Teams-style lures to trick unsuspecting victims into entering an attacker-provided device code, along with their credentials, effectively allowing the threat actor to recover the token and hijack their account.

Despite these similarities, it's assessed that the threat actors are employing Storm-2372-style tradecraft through what has been described as a reusable tooling layer called DEBULL.

Device code phishing refers to an identity theft technique where attackers exploit a legitimate OAuth 2.0 authentication mechanism, specifically the Device Authorization Grant flow, to bypass multi-factor authentication (MFA) and gain persistent account access without having to steal user passwords.

Unlike traditional phishing attacks that require the operators to set up bogus adversary-in-the-middle (AitM) login pages, device code phishing relies on manipulating a user into completing a real, trusted authentication prompt.

Device code authentication, per Microsoft, is a legitimate OAuth flow designed for devices with limited interfaces, such as smart TVs or printers, that cannot support a traditional interactive login. In this scenario, a user is presented with a short code on the device they are trying to sign in from and is prompted to input that code into a web browser on a separate device to complete the authentication.

Threat actors have abused this separation to insert themselves and initiate the authentication flow. Then, they share that code with the target through a phishing lure. Thus, when the user enters the code, they authorize the threat actor's session without their knowledge, granting them access to the account.

"Device code phishing doesn't hack its way in," Huntress notes. "It uses a legitimate authentication flow to walk right through the front door, with no password required, MFA bypassed, and session tokens handed straight to the attacker."

Successful device code phishing attacks can facilitate full account takeover, theft of valuable information, fraud, business email compromise (BEC), lateral movement within a compromised environment, and even disruptive attacks like ransomware.

"In most current device code phishing attacks, the code is generated dynamically when a user clicks on the initial phishing link. This seemingly small change allows the user to view the email at any time to kickstart the attack chain," Proofpoint said in an analysis published in May 2026. "These new implementations of the device code attack chains can be purchased via phishing-as-a-service (PhaaS) offerings, like EvilTokens or Tycoon, or created and owned by the threat actor conducting the campaigns. "

These campaigns are also known to leverage account takeover (ATO) jumping, a technique where an attacker compromises an initial email account and then abuses it to send phishing links to a broader set of contacts in the form of a button, hyperlinked text, embedded within a document, or a QR code. The links, when visited by the recipient, initiate an attack sequence that employs the Microsoft device authorization process.

ZeroBEC said the campaign it observed involves using payment and shared-folder pretexts in phishing emails to deceive victims into clicking on a URL that takes them to a legitimate-but-compromised Croatian rental website, which, in turn, acts as a device code orchestrator used to initiate the Microsoft device code challenge chain.

The workflow is characterized by the presence of Turkish-language developer markers, although the clues aren't enough to definitively attribute the campaign's provenance. Further analysis of the infrastructure has revealed that DEBULL is likely a phishing-as-a-service (PhaaS) platform that uses GraphSpy or a GraphSpy-derived workflow for Microsoft 365 and Entra post-exploitation.

"Operators can define a page name and slug, edit HTML, CSS, and JavaScript directly, then choose how the lure is published," ZeroBEC said. "The embedded templates included a Microsoft 365 device-code authentication page, an OAuth callback page, and a modern landing page. The Microsoft 365 template is especially important because it exposes the exact building block used by the campaign: a user-code display, copy-code behavior, and a link to Microsoft device login."

"The more useful conclusion is that Storm-2372-style identity tradecraft is now being packaged into reusable broker infrastructure. DEBULL provides the campaign-facing and operator-facing layer. GraphSpy or GraphSpy-derived code likely handles the post-authentication layer. The lure can be changed without changing the backend identity stack."

The disclosure comes as Cisco Talos said it identified a fully-featured PhaaS operator panel branded ARToken that shares infrastructure, API contracts, and operational patterns with the EvilTokens device code phishing platform and is made available to affiliates.

"The ARToken panel exposes 80+ API endpoints for device code phishing, Primary Refresh Token (PRT) persistence, email access, business email compromise (BEC) operations, and SharePoint exfiltration - all accessible to operators through a React-based dashboard," Talos said.

EvilTokens, like DEBULL, enable attackers to weaponise harvested tokens to exfiltrate emails, files, and other sensitive data from compromised Microsoft accounts, carry out reconnaissance via Microsoft Graph API, and establish persistence access. In addition, it incorporates artificial intelligence (AI)-powered features to automate and scale BEC workflows, such as sifting through thousands of harvested emails, identifying finance-related email threads, and drafting BEC emails.

ARToken functions as a complete post-compromise toolkit that allows operators to leverage the captured access token recovered following successful device code authentication to maintain access, perform email operations, access OneDrive and SharePoint, and browse victim Microsoft 365 sessions outside the panel using a dedicated tool known as ARTBrowser.

"These features indicate the platform is more mature than a simple device code phishing kit - it is a complete BEC operations environment," Talos researcher Michael Kelley said.

The surge in device code phishing attacks has also led to other PhaaS kits like Tycoon 2FA to adopt the technique to hijack Microsoft 365 accounts in its rebound following a law enforcement operation, signaling a broader shift within the threat landscape.

"Tycoon 2FA operators have repurposed their existing PhaaS kit as the delivery framework for OAuth device code grant phishing," eSentire noted in May 2026. "The attack begins when a victim clicks a Trustifi click-tracking URL in a lure email and culminates in the victim unknowingly granting OAuth tokens to an attacker-controlled device through Microsoft's legitimate device-login flow at microsoft.com/devicelogin."



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

CERT/CC Warns of Hidden Admin Backdoor in Tenda Router Firmware

Several versions of firmware released by Chinese network device manufacturer Tenda have been found to embed an undocumented authentication backdoor that enables administrative access to the devices' web management interfaces, the CERT Coordination Center (CERT/CC) warned Monday.

"An attacker can exploit this vulnerability, tracked as CVE-2026-11405, to bypass the password verification process and obtain full administrative control without valid credentials," the CERT/CC said in an alert.

The vulnerability impacts multiple versions of the firmware -

  • US_FH1201V1.0BR_V1.2.0.14(408)_EN_TD
  • US_W15EV1.0br_V15.11.0.5(1068_1567_841)_EN_TDE
  • US_AC10V1.0re_V15.03.06.46_multi_TDE01
  • US_AC5V1.0RTL_V15.03.06.48_multi_TDE01
  • US_AC6V2.0RTL_V15.03.06.51_multi_T

The backdoor functionality is present within the "login()" function of the "/bin/httpd" web server binary. While the method initially follows a normal authentication path using MD5-based password verification, it activates an alternate code path if the authentication fails.

Specifically, this involves calling "GetValue("sys.rzadmin.password")" to fetch an alternate password value from the device configuration, and performing a direct plaintext comparison between the user-supplied password and the configuration-stored value. Should these values match, the application grants admin-level access (role=2) and creates a valid session with elevated privileges.

"The associated ["rzadmin"] username is not validated, so any provided username will succeed when paired with the backdoor password," the CERT/CC said. "This backdoor authentication mechanism is not documented or visible through any administrative interface."

Successful exploitation of this standard username validation override allows full administrative access to the device's web interface regardless of the administrator account credentials. It can permit an attacker to make unauthorized remote modification of settings, disable security features, or reconfigure the device, potentially leading to a complete device takeover.

The vulnerability, reported by an anonymous researcher, remains unpatched as of writing. The Hacker News has contacted Tenda for comment, and we will update the story if we hear back.

In the interim, users are advised to disable remote management on the device and change the default LAN IP address to prevent bad actors from reaching it and reduce opportunistic discovery by automated scanners that target known default IP ranges.



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

BeyondTrust Patches Critical Auth Bypass Flaws in Remote Support and PRA

BeyondTrust has released updates to address two critical security flaws affecting Remote Support (RS) and Privileged Remote Access (PRA) products that, if successfully exploited, could allow unauthenticated attackers to take control of susceptible devices.

The vulnerabilities are listed below -

  • CVE-2026-40138 (CVSS score: 9.2) - A pre-authentication vulnerability exists in the authentication subsystem of BeyondTrust Remote Support and Privileged Remote Access stemming from improper validation of authentication data that could allow a network-positioned attacker to bypass access controls and gain unauthorized access to the appliance, including accounts with elevated privileges.
  • CVE-2026-40139 (CVSS score: 9.2) - A pre-authentication vulnerability exists in the authentication subsystem of BeyondTrust Remote Support stemming from improper processing of authentication requests that could allow an unauthenticated remote attacker to bypass access controls and gain unauthorized access to the appliance, including accounts with elevated privileges.
  • CVE-2026-40140 (CVSS score: 8.7) - A pre-authentication vulnerability in the network communication subsystem stemming from insufficient validation of client-supplied input that could allow an unauthenticated remote attacker to trigger a denial-of-service condition, affecting appliance availability.
  • CVE-2026-40141 (CVSS score: 8.5) - A vulnerability exists in a web application component of BeyondTrust Remote Support and Privileged Remote Access stemming from insufficient validation of user-supplied input that could allow an authenticated attacker with limited privileges to access unintended resources or data beyond their authorization scope.

It's worth noting that the successful exploitation of CVE-2026-40138 and CVE-2026-40139 hinges on a specific authentication configuration being enabled. In the case of CVE-2026-40141, exploitation, should it occur, is restricted to accounts with specific permissions.

BeyondTrust said all the identified internally as part of ongoing security assessments, with assistance using publicly available artificial intelligence (AI) models like Anthropic Claude Opus 4.8 and its own proprietary research tooling.

"The most severe vulnerabilities may allow an unauthenticated remote attacker to bypass access controls and gain unauthorized access to the appliance under specific configurations," it said. "Additional vulnerabilities may allow service disruption, unintended data access, and, under distinct configurations, elevated access by an authenticated user that may impact system integrity."

The issues have been addressed in the following versions -

  • Remote Support RS 25.3.2 or lower (Fixed in RS 25.3.3 and above)
  • Privileged Remote Access PRA 25.3.2 or lower (Fixed in PRA 25.3.3 and above)

BeyondTrust makes no mention of the vulnerabilities being exploited in the wild. However, security flaws in RS and PRA products (CVE-2024-12356 and CVE-2026-1731) have come under repeated exploitation in the past to deploy web shells and backdoors, making it essential that users move quickly to apply the fixes.



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

Monday, July 6, 2026

Possible Software RAID Issue With Recent mdadm Package

We identified an issue with mdadm version "mdadm - v4.4 - 2024-11-07 - 4" that can cause software RAID issues after a reboot. We have removed this version and pushed a downgraded version "mdadm - v4.4 - 2024-11-07 - 2" to the Security Onion repo.


If you are not running software RAID, then you should not be affected at all.


If you are running software RAID, then you should check to see what version of the mdadm package is installed on all of your grid members to see if they need to be downgraded.


Please note that the following instructions assume that you installed using our official Security Onion ISO image. If you are using some other unsupported installation method, then your mileage may vary.


Check the existing mdadm version on all grid nodes:

sudo salt \* cmd.run 'mdadm --version'


If all grid nodes show version "mdadm - v4.4 - 2024-11-07 - 2", then you are running the correct version.


If one or more grid nodes have version "mdadm - v4.4 - 2024-11-07 - 4" then you need to downgrade mdadm:

sudo salt \* cmd.run 'echo y | dnf downgrade mdadm'


Once that completes, then verify the downgraded version on all nodes:

sudo salt \* cmd.run 'mdadm --version'




from Security Onion https://ift.tt/Oy4Yxk9
via IFTTT

Iran-Linked Hackers Use New Cavern C2 Framework to Target Israeli Organizations

An Iranian hacking group affiliated with Iran's Ministry of Intelligence and Security (MOIS) has been wielding a previously undocumented modular command-and-control (C2) framework dubbed Cavern (aka Cav3rn) targeting Israeli organizations.

The activity, which has primarily singled out IT providers and government sectors, has been attributed to a threat cluster tracked by Check Point Research under the moniker Cavern Manticore, which it said shares some level of tactical overlaps with MuddyWater and Lyceum, the latter of which is assessed to be a subgroup within OilRig.

"The framework reflects a mature and adaptable toolset built around a shared .NET foundation, while using multiple compilation formats across different components, including .NET Framework, .NET Mixed-Mode C++/CLI, and .NET Native AOT," the cybersecurity company said.

"The compilation format itself becomes the anti-analysis layer that forces reverse engineers into multiple toolsets and metadata-reconstruction workflows."

The components of the C2 framework are used as Cavern Agent and Cavern modules, demonstrating a clear division of responsibilities between core communication capabilities and mission-specific post-exploitation functionality. This architecture has inherent advantages as it allows the operators to tailor deployments based on the victim profile, reduce forensic visibility, and ensure persistent access through bespoke modules for reconnaissance, data theft, tunneling, and lateral movement.

The attack chain documented by Check Point Research commences with SysAid's software update feature, which is leveraged by the adversary to initiate a DLL side-loading chain that leads to the execution of a trojanized DLL ("uxtheme.dll") containing the Cavern Agent. The agent, for its part, loads a standalone communication DLL module ("n-HTCommp.dll") to contact the C2 server ("hospitalinstallation[.]com") and fetch additional post-exploitation modules on the fly over HTTPS or WebSocket.

As many as five DLL modules have been uncovered -

  • mhm.dll, for file operations, enumeration, recursive file search, archive handling, and bidirectional file transfer
  • db.dll, for SQL database enumeration, query, export, and manipulation
  • ode.dll, for Active Directory reconnaissance, user/group enumeration, and LDAP brute-force attempts
  • n-ten.dll, for network reconnaissance, port scanning, share enumeration, and SMB brute-force attempts
  • n-sws.dll, for SOCKS5 proxy and WebSocket tunneling

A defining trait of the framework is its use of three different .NET compilation targets spanning its components: while mhm.dll, db.dll, and ode.dll are pure .NET Framework modules, n-HTCommp.dll, n-ten.dll, and n-sws.dll make use of Native AOT (Ahead-of-Time) compilation. The main agent, uxtheme.dll, combines managed .NET code with native C++ in a single portable executable.

Embedded within the agent is a unified module dispatcher that treats components whose names start with n- as native DLLs and loaded via the LoadLibraryA Windows API, while the rest is interpreted as managed .NET assemblies and loaded through a mechanism known as AppDomain isolation.

"The framework's anti-analysis posture relies on uncommon .NET compilation formats (Mixed-Mode C++/CLI and Native AOT) that force reverse engineers into multiple toolsets and metadata-reconstruction workflows, together with per-module AppDomain isolation as an anti-forensics measure," Check Point explained.

Attacks orchestrated by Cavern Manticore have involved the threat actor moving from an initial compromised IT provider to a second-hop provider before ultimately reaching the intended target organization, indicating their ability to weaponize trusted relationships in the software supply chain to their advantage.

"This activity highlights the operational value of trusted service-provider relationships, particularly where Remote Monitoring and Management (RMM) solutions are deployed," the company noted.

"By abusing these tools, the actor can move laterally between victims and deliver malicious software disguised as legitimate updates. The actor also appears to leverage browser-based remote desktop technologies to access targets of interest and, in some cases, abuse built-in features such as remote printing to exfiltrate data when clipboard-based copy-paste or file-transfer capabilities are restricted."

The development unfolds against the backdrop of the ongoing joint military operation launched by Israel and the U.S. against Iran. In recent months, the Iranian state-sponsored threat actor tracked as MuddyWater has been observed conducting a broad reconnaissance campaign across more than 12,000 internet-exposed systems by exploiting known security flaws in internet-exposed SmarterMail, n8n, N-central, Langflow, and Laravel Livewire systems.

The list of exploited vulnerabilities is as follows -

The operation is said to have pivoted from broad reconnaissance to targeted credential harvesting and data exfiltration attacks against aviation, energy, and government sectors in the Middle East, including aviation, energy, and public sector entities in Egypt, Israel, and the United Arab Emirates.

"The operation leveraged a combination of vulnerability exploitation, Outlook Web Access (OWA) brute-force attacks, and newly identified command-and-control (C2) controllers supporting multi-protocol communication," Oasis Security said. "The activity progressed beyond reconnaissance and access attempts, resulting in confirmed exfiltration of sensitive data from compromised environments."



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

16-Year-Old Linux KVM Flaw Lets Guest VMs Escape to Host on Intel and AMD x86 Systems

A use-after-free bug in Linux's KVM hypervisor can be triggered from a guest virtual machine to corrupt the shadow-page state of the host kernel that runs it.

Dubbed 'Januscape' and tracked as CVE-2026-53359, the flaw sits in the shadow MMU code that KVM shares across both Intel and AMD. The public proof-of-concept panics the host; the researcher claims that a separate, unreleased exploit turns the same bug into full host code execution.

Security researcher Hyunwoo Kim (@v4bel) found and reported the bug. He described Januscape as the first guest-to-host exploit triggerable on both Intel and AMD, to the best of public knowledge. The flaw went unnoticed for roughly 16 years.

According to Kim, the exploit was used as a zero-day submission in Google's kvmCTF, the controlled KVM vulnerability reward program that offers up to $250,000 for full guest-to-host escapes.

How It Works

To run a virtual machine, KVM keeps its own private set of page tables that mirror the guest's memory layout. When it needs one of these tracking pages, it looks for an existing one to reuse.

The problem: it matched them by memory address alone and ignored what type of tracking page it was grabbing. Two different types can share the same address but do completely different jobs, so KVM would sometimes reuse the wrong kind.

That mix-up scrambles KVM's internal records of which page belongs where, and once those records are wrong, something has to give.

Most of the time, the kernel notices the mess and shuts itself down on the spot to avoid doing damage. That crash is what the public demonstration triggers: a guest can knock over the whole host, taking every other VM on that machine down with it.

The rarer, worse case happens when the freed tracking page gets handed out for another use before the kernel cleans up. The cleanup then scribbles a value into memory it no longer owns. An attacker only controls where that write lands, not what gets written, but even that limited foothold can be worked up into running code on the host.

The flaw behaves the same on Intel and AMD chips; only the final, hardest step of turning it into full control takes different work on each.

Who Is Affected

The vulnerable code has been present since commit 2032a93d66fa in August 2010 (kernel 2.6.36 era) and was fixed by commit 81ccda30b4e8, merged into mainline on June 19, 2026.

The attack requires two things from the guest side: root inside the VM, a common condition on rented cloud instances, and nested virtualization exposed by the host. Even on hosts that run hardware EPT or NPT by default, nested virtualization forces KVM back through the legacy shadow MMU, which is where the bug sits.

The exploit needs no cooperation from QEMU or any userspace VMM. It is purely an in-kernel KVM bug.

The practical concern is any x86 environment that hosts untrusted guests with nested virtualization enabled. An attacker who rents a single such instance can panic the host, taking down every other tenant VM on the same physical machine.

Kim said the withheld full exploit runs code as root on the host, which would expose other guests on the same machine to that root access. On distributions like RHEL, where /dev/kvm is world-writable (0666), Kim noted the same bug could also serve as a local privilege escalation to root, though the guest-to-host path is the higher-impact use.

A Busy Few Months for One Researcher

Januscape is Kim's third Linux kernel exploit disclosure in roughly two months. In May 2026, he disclosed Dirty Frag (CVE-2026-43284 / CVE-2026-43500), a page-cache write vulnerability chain that delivers deterministic root on most major distributions, extending the same bug class as Dirty Pipe and Copy Fail.

In June, he published ITScape (CVE-2026-46316), the first publicly demonstrated guest-to-host escape on KVM/arm64, exploiting a race condition in the virtual interrupt controller. Januscape now adds the x86 side; the same trigger fires on both Intel and AMD, with the PoC carrying a separate code path for each vendor.

Google launched kvmCTF in 2024 specifically because KVM underpins both Android and Google Cloud. A separate KVM x86 shadow paging use-after-free (CVE-2026-46113) involving a related but distinct rmap mismatch was fixed in May 2026.

That makes two shadow MMU use-after-frees in the same legacy code path within two months.

What to Do

The fix is a one-line addition to kvm_mmu_get_child_sp(): the reuse condition now checks role.word alongside the gfn, so a shadow page is only reused when both the frame number and the role match. KVM maintainer Paolo Bonzini wrote the patch.

Fixed stable versions shipped on July 4, 2026: 7.1.3, 6.18.38, 6.12.95, 6.6.144, 6.1.177, 5.15.211, and 5.10.260. NVD has not yet assigned a CVSS score; do not wait for one.

If you operate an x86 KVM host that accepts multi-tenant guests with nested virtualization, confirm that your kernel includes commit 81ccda30b4e8. Distribution backports may carry the fix under a different version number, so check the package changelog rather than relying on uname -r alone.

If you cannot patch immediately, disabling nested virtualization (kvm_intel.nested=0 or kvm_amd.nested=0) removes the attack path for untrusted guests. ARM64 hosts are not affected by Januscape; ITScape (CVE-2026-46316) is a separate KVM/arm64 issue.

The public PoC demonstrates a reliable host panic from a guest with a loadable kernel module and seconds to minutes of racing. Treat exposed x86 KVM hosts with nested virtualization as high-priority patch targets.



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

5 insights from Frost & Sullivan’s 2025 Frost Radar™ for Cloud Security Posture Management

Cloud security posture management (CSPM) is being redefined as two forces collide: Cloud environments are becoming more interconnected—spanning workloads, identities, data, APIs, and development pipelines—while security teams must reduce risk faster with fewer tools and less time.

Frost & Sullivan’s 2025 Frost Radar™ for Cloud Security Posture Management points to a structural shift: CSPM is no longer a periodic compliance exercise. It’s a continuous, risk‑based governance layer inside modern cloud native application protection platforms (CNAPPs). Frost & Sullivan projects the CSPM market will grow from $2.82 billion in 2025 to $6.96 billion by 2030 at a 19.8% compound annual growth rate (CAGR)—reflecting the growing shift from standalone posture tools to integrated, platform‑based approaches.

A cloud native application protection platform (CNAPP) brings together posture, workload protection, identity and entitlement management, and related controls to secure applications across the full lifecycle—from development through runtime operations.

Frost & Sullivan’s analysis also reinforces Microsoft’s position among leading CSPM providers, with strong performance across innovation and growth. This reflects Microsoft’s approach to unifying posture management with workload protection, identity, and data security as part of a broader CNAPP platform—aligning directly with how CSPM is evolving from point-in-time compliance to continuous risk management.

Below are five key insights from the Frost Radar and what they mean for security leaders navigating today’s cloud threat landscape.

1. CSPM is becoming the governance layer for CNAPP 

Frost & Sullivan research suggests CSPM is evolving beyond a standalone tool focused on configuration hygiene. Instead, it increasingly serves as the entry point and governance backbone for CNAPP—integrating posture signals with workload protection, identity, data security, and security operations center (SOC) workflows.

Modern CSPM solutions are expected to:

  • Provide continuous visibility across infrastructure as a service (IaaS), platform as a service (PaaS), and software as a service (SaaS).
  • Correlate misconfigurations, identities, vulnerabilities, and data exposure.
  • Feed high‑fidelity posture context into runtime protection and incident response workflows.

What to look for

Unified visibility that connects posture findings with workload, identity, and data signals—so investigations don’t begin from scratch when posture risk turns into an incident.

Frost notes that by 2030, CSPM is expected to become less a standalone market and more a foundational governance layer inside CNAPP platforms—unifying code‑to‑cloud policy and feeding posture context into runtime and SOC workflows

2. The market is moving beyond compliance to riskbased prioritization

Compliance coverage is now table stakes. Frost highlights that for organizations to differentiate they need solutions that continuously assess risk, reduce noise, and guide remediation—helping teams focus on the “toxic combinations” that create real exposure.

Leading solutions need to:

  • Continuously assess risk rather than rely on point‑in‑time scans.
  • Reduce alert fatigue through contextual correlation.
  • Prioritize remediation based on exploitability and business impact.

Organizations are increasingly using CSPM to drive ongoing risk reduction—with compliance reporting treated as an outcome of stronger controls.

What to look for

Prioritization that highlights likely cyberattack paths—not just severity scores—so teams can fix what’s exploitable first and minimize false positives.

Security leaders are adjusting how they evaluate CSPM vendors in response to these shifts. Rather than asking how many compliance frameworks a solution supports, they’re looking at whether posture insights can be correlated with identity, workload, and runtime signals to expose exploitable attack paths and guide remediation across developer and SOC workflows. Frost & Sullivan’s evaluation framework reflects this transition—placing greater emphasis on integrated, code to cloud risk management capabilities inside broader CNAPP platforms.

3. Codetocloud visibility is now required

Another major theme in the Frost Radar report is how organizations can embed posture management earlier in the application lifecycle to prevent misconfigurations before deployment—and continuously detect drift as environments change.

The report emphasizes:

  • Infrastructure‑as‑code (IaC) scanning and policy‑as‑code enforcement
  • Continuous integration and continuous delivery (CI/CD) pipeline integration
  • Ownership mapping so issues are routed to the right developer or team

By extending posture management into DevSecOps workflows, organizations can reduce remediation costs and prevent risk from reaching production.

What to look for

Security guardrails embedded in CI/CD pipelines—with clear ownership routing—so remediation happens earlier and doesn’t bounce between teams.

4. Multicloud complexity is driving platform consolidation

Fragmented tools and siloed data continue to create blind spots across posture, identity, and workload risk—overwhelming SOC teams and reducing operational effectiveness.

As a result, buyers are consolidating point products into integrated CNAPP platforms that correlate posture, workload, identity, and runtime signals.

Platform convergence is reshaping CSPM investment and deployment models:

  • A growing share of CSPM capability is delivered as part of a broader platform.
  • Shared dashboards improve visibility across hybrid and multicloud environments.

Consolidation reduces tool sprawl and improves SecOps efficiency.

What to look for

A platform approach that standardizes policies across clouds and carries posture insights into security operations (SecOps) workflows—improving both signal quality and remediation speed.

5. AI is reshaping CSPM—from operations to new workloads

Frost highlights AI as both an operational enabler and a new security domain for CSPM.

AI is being used to:

  • Reduce alert fatigue through contextual prioritization.
  • Generate compliance evidence.
  • Deliver guided remediation for developers and security teams.

At the same time, CSPM capabilities are expanding into AI workload posture management—covering models, pipelines, and related infrastructure.

What to look for

AI assisted prioritization and guided remediation—plus posture coverage for AI workloads—so emerging risks such as prompt injection or data leakage are managed alongside traditional cloud risk.

What this means for security leaders

Frost & Sullivan’s analysis underscores that CSPM is no longer about checking compliance boxes—it’s becoming a strategic control layer for managing cloud risk across the entire application lifecycle.

If you’re evaluating CSPM capabilities in 2025–2026, ask:

  • Can posture findings be correlated with identity, workload, and data context to expose exploitable cyberattack paths?
  • Can security guardrails be embedded earlier in CI/CD pipelines through IaC and policy‑as‑code?
  • Can posture insights flow into SOC workflows for faster investigation and response?
  • Can risk be continuously prioritized across multicloud environments—not just reported periodically?

How Microsoft aligns with CSPM’s next phase

Frost & Sullivan attributes Microsoft’s leadership in CSPM to its ability to operationalize posture management as part of a broader cloud security platform—aligning with the report’s emphasis on integrating posture with runtime protection, identity, data security, and SecOps workflows across the application lifecycle. These capabilities align with the same governance, prioritization, DevSecOps integration, and lifecycle visibility themes highlighted across the Frost Radar insights above.

Rather than operating as a standalone compliance layer, Microsoft correlates posture data with runtime telemetry and identity signals—integrating findings into developer pipelines and SOC workflows through GitHub, Azure DevOps, and Microsoft Defender XDR. Frost highlights Microsoft’s multicloud visibility across Microsoft Azure, Amazon Web Services (AWS), and Google Cloud Platform (GCP); policy‑as‑code enforcement and CI/CD integration to strengthen shift‑left security; and unified dashboards that carry posture context into investigations and response.

The Frost report also notes Microsoft’s expansion into emerging posture domains—including AI and API posture management—to continuously manage cloud and AI workload risk across the application lifecycle.

Learn more

  • Explore Microsoft cloud security solutions to see how unified posture management, risk prioritization, and protection across the application lifecycle can help reduce cloud risk.

To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.

The post 5 insights from Frost & Sullivan’s 2025 Frost Radar™ for Cloud Security Posture Management appeared first on Microsoft Security Blog.



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

Open banking opened the door. Here’s how you control who walks through it—with NetScaler.

Open banking has steadily increased competition, accelerated innovation, and given consumers more control over their financial data. But for most banks and financial institutions, the reason to participate isn’t the regulation — it’s the customer. People now expect account aggregation dashboards that pull every account into one view, the ability to pay directly from their bank, loan decisions in minutes instead of days, and savings tools that move money on autopilot. The institutions that can’t deliver these experiences lose customers to the ones that can.

For risk and technology executives, that customer mandate creates a tension that doesn’t resolve itself: delivering these experiences means opening your most sensitive systems to a growing ecosystem of third parties (such as fintechs, aggregators, payment processors, and developers); and the more connected your institution becomes, the more exposure you carry. The regulatory environment only intensifies the pressure created by rising customer expectations. In the EU, PSD2 has formalized open banking as a compliance requirement. In the US, the CFPB’s Section 1033 rule was intended to create a similar federal framework for consumer-permissioned data sharing, including recognition of Financial Data Exchange (FDX) as a standard-setting body. But that framework is now effectively on hold: the rule is enjoined and under reconsideration, leaving institutions to advance open banking programs without a settled federal compliance baseline. What hasn’t paused is the threat landscape: API attack vectors keep evolving, and adversaries are increasingly using AI to find and exploit them faster than defenders can close the gaps.

In mature markets, this isn’t a new problem. First-generation deployments were often stitched together under time pressure, and years later they’ve hardened into fragmented, costly estates: multiple point products, per-instance licensing that penalizes broad coverage, and forced upgrade cycles that keep the bill climbing. The opportunity now is to reassess that approach and the cost that came with it.

That API security gap, between what open banking requires you to expose and what you can actually defend, is where institutions are most vulnerable, and where the decisions you make about infrastructure matter most.

The attack surface you’re required to have

In traditional application security, reducing the attack surface is a primary objective. In open banking, you cannot reduce it; you can only manage it. PSD2 mandates that qualifying Third-Party Providers (TPPs) be granted API access to customer account data. FDX defines how those APIs should be structured. Neither tells you how to prevent that access from being exploited.

The most common exploit patterns in open finance APIs are instructive. Broken Object Level Authorization (BOLA)—where an authenticated but unauthorized party manipulates an API request to access data belonging to another account holder—is consistently ranked as the top API security risk by OWASP. It is particularly dangerous in open banking because the APIs are purpose-built to return sensitive financial data. The question is not whether an attacker can reach the API. They can, and in many cases, they are supposed to be able to. The question is whether your infrastructure can tell the difference between a legitimate TPP request and a malicious one.

Injection attacks, improper authentication, and over-permissioned TPP access round out the top risk categories. That last one deserves particular attention. Institutions frequently grant third-party developers broader access than their use case requires. That is because scoping access is operationally difficult, onboarding timelines are compressed, or the initial integration was designed before the full risk implications were understood. That over-permissioning compounds across dozens or hundreds of TPP relationships, creating an exposure profile that grows quietly alongside your open banking program — especially as deprecated zombie APIs and undocumented shadow APIs accumulate outside the company’s known and governed API estate.

Why infrastructure is the right place to solve this

Open banking security is sometimes framed as an API governance problem, or a vendor management problem, or a compliance program problem. It is all of those things. But at the transaction level—where an API call is made, authenticated, routed, and responded to—the control point is infrastructure.

The institutions that manage open banking risk most effectively are not the ones with the most security tools. They are the ones that have consolidated security enforcement into the layer where traffic actually flows. That starts with API discovery that surfaces every endpoint actually receiving traffic—including the undocumented shadow and zombie APIs—so nothing operates unseen. From there: WAF and injection protection at the API layer. OAuth 2.0 and mutual TLS (mTLS) enforcement at the authentication boundary. Rate limiting to detect and contain abuse before it escalates. And granular access controls that allow institutions to define, enforce, and audit exactly what each TPP integration is permitted to access without relying on the TPP to self-limit.

When these controls are distributed across multiple point products, they create seams. Policies defined in one tool don’t automatically apply in another. Visibility is fragmented. Audit trails are incomplete. In a regulatory environment where you may be asked to demonstrate exactly what data was accessed, by whom, and under what authorization, fragmented visibility is a compliance liability, not just an operational inconvenience.

The case for a unified control plane

Citrix NetScaler’s position in open banking security starts with the same architecture that has made it the application delivery infrastructure of choice for major financial institutions for decades: a single platform, a single codebase, and a single control plane that spans on-premises data centers and multi-cloud environments.

For open banking specifically, this means that WAF, API protection, OAuth 2.0/mTLS enforcement, rate limiting, and access control policies are all defined once and enforced consistently across every API endpoint, in every environment, for every TPP integration. There is no synchronization problem between security tools because there is only one security layer. There is no visibility gap between environments because observability runs through a single control plane.

The operational implications are significant. As open banking API estates grow—more TPP integrations, more endpoints, more environments—the complexity of managing security across a fragmented toolset grows with it. A unified platform scales without adding operational overhead proportionally.

Unlike per-instance or per-application licensing models that make comprehensive coverage progressively more expensive, NetScaler’s enterprise licensing carries no per-instance limits, so institutions can extend consistent security across their full estate without the cost structure that typically discourages thorough deployment or the forced upgrade cycles that turn a security requirement into a recurring negotiation.

There is also a performance dimension that risk executives sometimes underestimate. Security controls that introduce latency into API transactions create pressure to reduce coverage (fewer inspection rules, lighter enforcement) in the interest of maintaining the transaction speeds that open banking users expect. NetScaler’s one-pass architecture processes security and delivery functions simultaneously, minimizing the latency impact of comprehensive API protection. You do not have to choose between thorough security, acceptable performance, and the operations cost of scaling both.

What governance actually requires

The JPMorganChase CISO’s public letter to third-party suppliers—calling on vendors to treat security as equal to or above launching new products—reflects a shift that is underway across the industry. Major institutions are raising their expectations for TPP security posture, and regulators are raising theirs for the institutions themselves.

Meeting those expectations requires more than policy. It requires infrastructure that enforces policy consistently, generates audit-ready records automatically, and gives security and compliance teams a single place to review, adjust, and demonstrate their controls. The institutions that will manage open banking risk most effectively over the next several years are those that treat their API security infrastructure as a strategic asset—not a collection of point solutions assembled to meet last year’s requirements.

Open banking opened the door. The question is not whether to let people through it. The question is whether you can see everyone who’s walking through, verify they are who they say they are, and make sure they only go where they’re supposed to go.

That is an infrastructure problem. And it has an infrastructure answer.

Learn more about how NetScaler secures financial services application delivery and open banking API infrastructure here.



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

Suspected China-Nexus Hackers Use Fake Indian Tax Filing Utility to Deploy DcRAT

A suspected China-nexus threat activity cluster has been observed targeting Indian taxpayers, tax professionals, and corporate finance teams to deliver a remote access trojan designed to steal sensitive data from compromised hosts.

The multi-stage campaign, codenamed Operation DragonReturn by Seqrite Labs, involves sending spear-phishing emails impersonating the Income Tax Department of India. It was first observed on May 18, 2026. The activity, per the cybersecurity company, coincides with the annual income tax filing season in the country.

"It is not opportunistic – the precision of the lure document, the use of real legal citations, bilingual content, and active payload rotation indicate a deliberate, resourced, and sustained threat operation focused exclusively on the Indian taxpayer ecosystem," security researchers Dixit Panchal and Soumen Burma said.

The end goal of the campaign is assessed to be the deployment of malware for financial gain or sensitive data theft.

The attack chains begin with phishing messages masquerading as India's income tax department, using tax violations and penalty lures to induce a false sense of urgency and trick users into clicking on a malicious link ("govtop[.]one/incometax") embedded within PDF attachments.

The bogus landing page, for its part, instructs users to download a ZIP archive containing what appears to be a common offline utility provided by the department to file tax returns, but, in reality, is engineered to sideload a malicious DLL ("nvdaHelperRemote.dll"), which, in turn, injects another payload into memory.

This payload ensures it's running with administrative privileges, and if not, triggers a User Account Control (UAC) prompt to get the user to run it with elevated permissions. Once launched, it performs checks to avoid executing within analysis and sandboxed environments, and then retrieves a JPG image ("lllyd.jpg") from a hard-coded server ("204.194.48[.]250") and stores it as "C:\Windows\background.jpg."

"This image file is used as a container for a secondary payload, from which a 504 KB DLL is extracted and written to 'C:\Program Files\Windows Media Player\nvdaHelperRemote.dll,'" Seqrite Labs explained. "After extracting the payload, the malware copies itself as 'Mixed Reality.exe' and establishes persistence by creating a Windows service named MixedSvc, configured to start automatically on system boot."

"This behaviour confirms that the sample functions as a downloader and installer, using image-based payload concealment and Windows service persistence to maintain long-term access to the infected system."

The "Mixed Reality.exe" binary is responsible for deploying two different payloads, one of which is a .NET malware loader that carries out anti-analysis checks, establishes persistence, disables Windows AMSI scanning, and decrypts and loads DCRat on the infected machine. The second payload features capabilities to take screenshots and exfiltrate data to a remote server ("kkxqbh[.]top").

Exactly who is behind the activity is unclear, but infrastructure analysis indicates the use of IP addresses belonging to ChinaNet, as well as a Chinese-language web management panel exposed by the DCRat command-and-control (C2) server ("223.26.63[.]40"). In addition, Seqrite said it identified infrastructure and tactical overlaps with Silver Fox, a Chinese cybercrime group previously attributed to tax-themed phishing campaigns that deliver ValleyRAT.

Based on these similarities, it's suspected that the campaign is the work of a China-aligned threat actor conducted with an aim to establish covert access for intelligence collection, credential theft, and systematic data exfiltration, Seqrite concluded.

The disclosure comes as LevelBlue said it detected two distinct campaigns that employ fake installers for LINE and phishing emails with salary adjustment lures to distribute ValleyRAT targeting Chinese- and Japanese-speaking users.

The email-driven campaign begins with a malicious email containing a URL link that, when accessed by the recipient, triggers the download of a ZIP archive. The archive acts as a foundation for a DLL side-loading chain, with the DLL ultimately downloading and executing ValleyRAT, a remote access trojan that allows operators to seize control of an infected system.

The fake installer attack chain, in contrast, employs bogus installers for popular software to deliver the malware using techniques like PoolParty Variant 7, while simultaneously focusing on anti-analysis and detection evasion, per Cybereason.

Interestingly, the use of PoolParty Variant 7 to inject shellcode into "explorer.exe" has been previously observed in connection with a custom malware loader dubbed SADBRIDGE, which is designed to deploy a Golang-based reimplementation of Quasar RAT known as GOSAR. The intrusion set, which targeted Chinese-speaking regions with malicious installers for Telegram and Opera, was attributed by Elastic Security Labs to REF3864.

"While we don't have conclusive proof, these commonalities suggest they may have been created by the same threat actor," Cybereason researcher Hajime Takai noted back in February 2026.



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

New Java-Based QuimaRAT MaaS Built to Run on Windows, Linux, and macOS

Cybersecurity researchers have flagged a novel Java-based remote access trojan (RAT) called QuimaRAT that's capable of targeting Windows, Linux, and macOS environments.

According to LevelBlue, the cross-platform malware is advertised under a malware-as-a-service (MaaS) model, costing anywhere between $150 for one month to $1,200 for lifetime access. Other subscription tiers include $300 for three months, $500 for six months, and $700 for twelve months.

"Built around a modular architecture, the RAT supports dynamic capability expansion through encrypted plugins that can be delivered, loaded, unloaded, and updated directly from its command-and-control (C2) infrastructure," the cybersecurity company said in an analysis of the malware.

The malware author also advertises a builder capable of generating multiple output formats, including JAR, EXE, APP, SH, BAT, and VBS, indicating an attempt to help prospective customers package the client tailored for different environments and delivery scenarios.

The seller's post guarantees complete stealth on Windows and Linux, noting there are no visible user interface elements or desktop entries. On macOS, however, the threat actor includes a caveat that certain features like screen capture and input control require "user-granted admin permissions."

Visiting their website, users are greeted by a pop-up message that states the platform "provides offensive security tooling intended exclusively for professional security research, authorized penetration testing, and controlled educational environments," warning them against using it for "malicious, unauthorized, or illegal purposes."

In all, the threat actor offers four tools -

  • Quima Control (aka QuimaRAT), a remote administration tool with 74 Windows and 46 macOS and Linux modules
  • Quima Builder, a modular builder and launcher toolkit with support for XLL, LNK, VBS, JS, BAT, DOCM, XLSM, MSC, CPL, and CHM file formats
  • Quima Loader, a browser-cache payload delivery service to stage and deliver the malware payload
  • Quima Dropper, an HTML/SVG payload generator

Quima Loader, particularly, is noteworthy, as it allows an operator to upload an EXE file through a dedicated panel and select a delivery format (e.g., HTA or LNK) and a landing page template (e.g., fake CAPTCHA check or software update alerts), after which the tool generates a stager link that, when opened by the victim in the browser, initiates the following sequence of actions, per the malware developer -

  • The landing page is loaded, and the payload is fetched and held in the browser cache.
  • A Download button appears on the page.
  • Clicking it saves a "small, clean loader file" that's trusted by the browser.
  • Target runs the loader, which reads the cached payload.
  • The main payload gets executed on the system, while bypassing SmartScreen protections on Windows.

"A RAT, a builder suite, a web loader, and an HTML dropper — each built around what Windows already trusts," the author behind the Quima suite claims on their website. "Native execution paths, system-owned resources, clean outputs. AV [antivirus] sees nothing unusual. Neither does the user."

LevelBlue's analysis suggests that QuimaRAT is organized as a modular Java project built using Apache Maven, while containing embedded Java Native Access (JNA) native libraries for Windows, Linux, and macOS across various architectures. It also decodes and parses an internal configuration file necessary for environment validation, persistence installation, and C2 initialisation.

"These native components allow the RAT to interact directly with low-level operating system APIs through C/C++ code, indicating intentional support for broad multi-platform deployment," researchers Chen Aviani and Nikita Kazymirskyi said.

Before execution, the malware ensures only one instance of the trojan is running on the infected machine at any given point in time. It achieves this by creating a lock file within the operating system's temporary directory and preventing other processes from using it simultaneously. If it detects that another RAT instance is already holding the lock to the file, it terminates execution.

QuimaRAT is designed to determine the current operating system name, using it to dictate the next course of action, including evading sandboxed and virtual environments, establishing persistence, and serving the main payload. Furthermore, it supports the ability to execute an additional embedded payload or decoy application along with the main RAT process if the functionality, named Binder, is enabled through the configuration.

The malware sets up persistence using a variety of operating system-specific methods: Registry Run keys, Scheduled tasks, and the Startup folder for Windows, .desktop autostart entries and crontab reboot tasks for Linux, and a LaunchAgent plist file for macOS.

What's more, the Trojan incorporates an optional Pastebin-based C2 host update mechanism that is controlled via the configuration. This approach allows the operator to dynamically rotate or replace the C2 infrastructure without having to rebuild and redistribute the payload.

The end goal of the QuimaRAT is to establish communication with the C2 server over TCP (or alternately via WebSocket, TLS, and HTTPS) to receive and execute commands. A watchdog component built into the malware ensures that the channel remains active and reconnects to it, if contact is lost with the C2 server.

"QuimaRAT maintains an internal shutdown state flag used to control whether the RAT should continue performing networking, reconnect, watchdog, and recovery operations," the researchers said. "This mechanism allows QuimaRAT to stop reconnecting, watchdog, and communication recovery operations after shutdown mode is activated."

The malware supports a wide range of capabilities, including remote command execution, remote payload and plugin delivery, credential theft, persistence, file transfer, clipboard manipulation, and webcam surveillance, granting the attacker comprehensive control over an infected system.

Besides these conventional features present in most RAT malware, QuimaRAT facilitates fileless shellcode execution on Windows hosts and a resilient communication framework that enables persistent access to compromised hosts.

"QuimaRAT should be viewed as a modular Java RAT platform rather than a single static implant," LevelBlue said. "ProGuard-class obfuscation indicators, Maven Shade relocation, preserved runtime symbols, and synthetic string decryptors further support the assessment that QuimaRAT is designed to rotate static fingerprints without changing its core behavior."



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

Opera GX Flaw Let Malicious Sites Auto-Install Mods to Steal Data From Visited Pages

Researchers found a flaw in Opera GX, the gaming-focused version of the Opera browser, that let a malicious website silently install a browser add-on and use it to lift specific data from the pages a victim visits.

In a proof of concept, they reconstructed a signed-in user's full Gmail address from a single visit, with no click. Opera has patched the flaw and says it found no evidence that it was ever used in the wild.

The fix shipped in Opera GX version 130.0.5847.89, so anyone on a current build is already covered; you can confirm yours at opera://about. There is no CVE.

Because the attack needed no clicks or approvals, there was no workaround short of the patch. Opera's bug bounty team rated the issue P1, its top severity, and paid the maximum $5,000 award for a critical bug.

How the attack works

GX Mods let you reskin Opera GX with custom sounds, themes, wallpapers, and CSS that restyles the sites you visit. They ship as .crx files, like browser extensions, but they cannot run JavaScript and hold no permissions.

The weakness is in how they install: Opera's mod pipeline downloads and enables a mod automatically, with no approval prompt. So a malicious page can install one silently, for instance by loading a hidden iframe pointed at a .crx file.

The only sign is a notification bar below the address bar telling you a mod was added, with a Remove button.

This auto-install behavior is not new. The researcher Renwa identified it back in 2023 and, by escalating an installed mod into a full extension, used it to spoof the browser's address bar. Opera patched that specific attack in March 2023 but left the underlying auto-install in place, which is what this new research builds on.

A silent look-and-feel mod sounds harmless on its own. But a mod's CSS is applied to every page you visit, not just one. Ordinary CSS injection is confined to the page it lands on; here, the attacker's styling reaches every site the browser opens, a technique the researchers call a universal CSS injection.

CSS cannot read a page and send it off on its own. But it can be coaxed into leaking a value one piece at a time. The trick relies on attribute selectors: a rule can test whether an element's attribute value, like an email tucked into a hidden field, begins with a given letter, and fetch a background image from the attacker's server only when it does. Fire enough of these, and you learn the value character by character.

Researchers call this an XS-Leak, short for cross-site leak. To pull a Gmail address, the researchers aimed this at a Google account page, myaccount.google.com/contactemail, that carries the address inside three of its HTML attributes.

They packed a mod with roughly 150,000 CSS rules, one set for every possible three-letter piece of the address, and let a reconstruction script stitch the matches back together. They first tried four-letter pieces, which needed 5.6 million rules and about 880 MB of CSS. The browser choked, so they scaled down to three-letter chunks that overlap just enough to reassemble.

Chaining it together took only a nudge. The victim lands on the attacker's page, the mod installs within seconds, and a few lines of JavaScript then redirect the browser to the Google account page. The mod's CSS is already loaded there, so it fires the requests and leaks the address as the page renders, before the victim can reach the notice's Remove button.

The Gmail address was just the proof of concept; the same approach can lift other values a page exposes in its markup, like a username.

The same auto-install path has a second, cruder use the researchers documented: loading a .crx while in private (Incognito) mode crashes the browser and dumps every open tab. This one hits regular Opera too, not just Opera GX, since any .crx trips the extension-install pipeline, whatever it contains. Opera's advisory addresses the data-theft fix and does not mention the crash.

Severity and the bigger picture

The report almost did not get its due. Opera runs its bounty program on Bugcrowd, and the triage analysts struggled to grasp what the bug did, first rating it a middling P3.

The researchers made their case in an unusually direct way: while an analyst was reproducing the attack, they caught the analyst's own trigrams, rebuilt the analyst's Gmail address, and pasted it into the report. Opera's team then raised the severity to P1 and paid the $5,000 critical-tier maximum.

Opera's own account is more measured. In its advisory, the company says it is "quite confident" the flaw was never exploited in the wild, and frames the attack as complicated to pull off: the victim had to land on a malicious site, end up with a fresh mod, and ignore the removal notice long enough for the redirect to fire.

The researchers' demo is the counterweight. Their redirect runs in the seconds before a user can even read the notice, let alone click Remove. It was a narrow, fiddly attack that Opera found no trace of in the wild, and it still worked with zero clicks once it was set up.

The risk here was never the cosmetic feature by itself. It was reach. Once a mod's CSS could follow you from one site to the next, "just styling" turned out to be plenty.

That is the twist on a familiar idea: CSS-only theft usually stays trapped on the page where it is injected, as in PortSwigger's Blind CSS Exfiltration research, but here it rode along on every site the victim opened.

It is also not the first Opera feature turned against its users; The Hacker News covered the 2024 MyFlaw bug in Opera's My Flow, and Opera had been warned about this very auto-install behavior since 2023.



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

SkillCloak Lets Malicious AI Agent Skills Evade Static Scanners with Self-Extracting Packing

Scanners meant to catch malicious add-on "skills" for AI coding agents can be fooled by a few simple changes that leave the malware working, according to a new study from researchers at the Hong Kong University of Science and Technology.

Their strongest trick slipped past every scanner tested more than 90% of the time, and the same team built a runtime checker that catches most of the disguised skills the scanners miss.

Skills are small packages, usually a Markdown instruction file plus a few scripts, that agents such as Claude Code, OpenAI Codex, and OpenClaw load to pick up a new capability. Because a skill is just a bundle of files, the same one can run across different agents. And it runs with the agent's own access: your files, your terminal, your saved passwords.

A bad one can steal credentials, copy source code, or install a backdoor. Most of what a public marketplace lists is uploaded by strangers with little vetting.

The main defense so far has been the skill scanner, which reads a skill's files before you install it and blocks anything that looks dangerous. The paper, titled "Cloak and Detonate," tests whether that actually holds up. It does not. Beating scanners isn't new, though.

The Hacker News has covered researchers pushing a fake skill past every scanner it faced, which by the firm's own count reached tens of thousands of agents. What this paper adds is a way to do it systematically, at scale, and a defense that still works when it does.

How the disguised skills get through

The researchers' tool, SKILLCLOAK, rewrites a malicious skill to look clean while behaving exactly the same. It works two ways.

The lighter one rewrites the give-away bytes a scanner keys on, using the paper's own operators: swap a character for a look-alike from another alphabet, or split a flagged command across a newline, so the scanner's pattern no longer matches but the command still runs.

The heavier one, self-extracting packing, moves the whole payload into a directory the scanner skips, like .git/, behind a harmless-looking decoder that rebuilds the skill only when the agent runs it. Scanners skip such directories to save time and cut false alarms, which is exactly the blind spot the trick exploits.

Across eight scanners and 1,613 real malicious skills pulled from ClawHub, a public marketplace, the packing trick got past each of the eight more than 90% of the time, and past most of them more than 99%.

The lighter rewriting cleared more than 80% on most scanners and 96% on one. And the disguise costs the attacker almost nothing: on Claude Code and OpenAI Codex, the cloaked skills worked just as well as the originals.

Watching what a skill does, not how it looks

Since appearance can be faked, the researchers propose checking behavior instead, in a tool they call SKILLDETONATE. It runs the skill in a sandbox and watches what it does at the operating-system level: what it reads, what it writes, where it sends data.

Two ideas make it work for agents. It tracks sensitive data by where it flows rather than what it looks like, so base64 or encryption doesn't throw it off. And it runs the instructions a skill builds only at runtime, which is exactly where the packing trick hides its payload.

In a controlled test, the checker caught 97% of attacks while wrongly flagging 2% of safe skills, a lower false-alarm rate than the scanners it beats, and it held steady when the skills were cloaked. On real-world malicious skills, it caught 87%.

Cisco's scanner, the strongest tested, went the other way: it caught 99% of the real-world skills before cloaking and about 10% after.

The catch is speed, a couple of minutes per skill against a scanner's few seconds, though it runs once, before a skill goes live. The work is a preprint and hasn't yet been peer-reviewed; the researchers have released their code.

Already happening in the wild

None of this is hypothetical. Public marketplaces are already full of malicious skills that scanners are not stopping: Bitdefender found roughly 17% of the skills it checked on one marketplace carried hidden malicious code, and Koi Security counted 341 in a single campaign it called ClawHavoc, as THN reported, later 824 as the marketplace grew.

Some use the paper's exact tricks. Of five evasive skills Unit 42 found still live on ClawHub despite its built-in scanning, one, omnicogg, padded its README with 22 MB of junk to slip past the scanner's size cap, the same size-padding operator the paper tests. Two more delivered Mac password-stealers, and two hijacked the agent's financial advice to push affiliate links and rig meme-coin launches.

The runtime gap shows up outside skill marketplaces, too. A clean-looking GitHub repository recently led Claude Code to open a reverse shell on the developer's own machine, handing the attacker remote control. The malicious code was never in the repo; the setup script fetched it at runtime from a DNS record, so a static scan had nothing to catch. Mozilla's 0DIN team traced the chain.

A related failure hits the tool descriptions that agents read through the Model Context Protocol. Microsoft warned that a poisoned description, changed after the tool was approved, quietly pushed a finance agent into leaking unpaid invoices. The mechanism is different, but the broken assumption is the same: that what passed review is what runs.

A few limits are worth stating plainly. No one has yet caught attackers using these exact packing tricks at scale; the real-world cases here are adjacent evasions, not SKILLCLOAK itself. The runtime checker is a research prototype, strong in the lab but untested on a live marketplace or under an attacker actively trying to evade it. And every performance number is the authors' own, from a paper that has not been peer-reviewed. The direction is well-evidenced; the specific figures deserve the usual caution owed to a single group's early work.

That is the real lesson, and it is where a growing line of work is converging. A scanner judges a skill by how it looks when it is submitted, but the malicious behavior only shows up once the skill runs, after the scan has passed. So the trust decision has to move from the marketplace gate to the machine where the skill executes.

What to hunt for? The paper's evasions leave signs a defender can look for, even on a skill that passed a scan:

  • Large or high-entropy files tucked in directories a scanner tends to skip, such as .git/ or build/.
  • Skills that unpack or assemble code only when they run, rather than shipping it in plain sight.
  • Files padded well past a sensible size, the trick that slips a skill under a scanner's size cap.

None of these is proof on its own. They are cheap first flags, not a verdict.

For teams using coding agents, that makes a "passed the scan" badge a starting point, not a guarantee. Keep static scanning as cheap hygiene, but watch what a skill does when it runs: the files it touches, the commands it runs, and where it sends data.

The paper offers concrete stopgaps too, like hashing a skill when it is scanned and re-checking before each run to catch payloads that unpack later, and flagging skills that ship opaque blobs in ignored folders or pad files past a size cap. None of those close the gap on their own, which is the point: the durable defense is watching behavior at runtime.

Beyond that, install only from a vetted source, give agents the least access they need, and don't run them on machines that hold the secrets worth stealing.



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

Sunday, July 5, 2026

Are companies giving away their secrets to AI?

SUMMARY: Are CEO's frustrated with the lack of control, costs and sovereignty of their AI environments? 

SHOW: 1042

SHOW TRANSCRIPT: The Enterprise AI Show #1042 Transcript

SHOW VIDEO: https://youtu.be/xgQv8WP-DNI

SHOW SPONSORS:

SHOW NOTES:


  1. There’s a level of unhappiness and distrust of the frontier labs from CEOs
  2. There needs to be an application layer on top of LLMs (e.g. “harness”, Palantir Ontology)
  3. This application layer prevents the LLMs from learning your business from your data
  4. “Alpha” is business differentiation (ability to outperform the market)
  5. He questions why the frontier model labs are charging by tokens and not outcomes (questions the entire AI business model)
  6. He questions “the true cost” of AI outputs 
  7. He claims that CEOs are now concerned about frontier labs entering the business of the customers - brings up an interesting misunderstanding of how interacting with LLMs works (“we’re safe, it’s deployed in our VPC”)

FEEDBACK?



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

Saturday, July 4, 2026

U.S. Government Entity Paid Kairos $1 Million in Data-Theft Extortion Case

A U.S. government entity paid about $1 million to keep stolen files from being leaked, according to a new case study by Rakesh Krishnan for Ransom-ISAC, built on a leaked negotiation chat and the blockchain trail the payment left.

The odd part: the group that took the money calls itself Kairos, but it may not be a ransomware gang at all. Krishnan found no sign that it ever locked a single machine: no encryptor, no locker, no demand for a decryption key. The threat was simpler. Steal the files, then charge the victim not to publish them.

Krishnan does not name the victim, but the chat points to Union County, Ohio. The proof-of-theft files carry names like Union.xlsx, 1 union co psi template.doc, and a final archive called union.rar. The victim calls itself a small county with limited resources. The attacker leans on one folder in particular, marked "prosecutors office," warning that leaking it would help criminals dodge charges.

The clues fit a real case. In May 2025, Union County, Ohio, said it detected ransomware on its network and later notified 45,487 residents and staff that their data had been taken, affecting most of the county of roughly 70,000. The stolen records ran from Social Security and financial details to fingerprints and passport numbers.

Neither the county nor Kairos has confirmed the connection. But if it holds, a county government paid a seven-figure ransom it has never publicly disclosed. The Hacker News has contacted the Union County Commissioners' Office for comment. This story will be updated with any response.

The negotiation ran for about a month. Kairos opened at $3 million and claimed it was holding more than 2 terabytes of data, some 1.6 million files. The county started at $100,000, crept up to $255,000, then $430,000. Kairos dropped to $2 million, then set a hard final number: $1 million, pay by Friday, or the files go public.

The payment on-chain: about 9.44 BTC lands in the Kairos-linked wallet.

It used the usual levers: a countdown timer, tight deadlines, and threats to dump the most sensitive folders first. The county paid on June 13, 2025, ten times its first offer.

The payment was roughly 9.44 bitcoin, worth about $1 million at the time. Krishnan traced the money from there. Within hours, it was split in two and pushed through a chain of wallets toward deposit addresses tied to the crypto exchanges Bybit, OKX, and a Russian service called BELQI.

That kind of tracing hands investigators leads, not names. And the money bought nothing solid. Kairos sent over a "proof of deletion" file, but a list of file names shows only that the attacker once had the files, not that the originals were wiped. Paying to make stolen data disappear is an act of faith, and the receipt is written by the thief.

Union County called what happened to it ransomware, the word everyone reaches for, but in the Kairos case, nothing was locked. That is the real shift: much of what still gets called ransomware now skips encryption and uses the stolen data itself as the pressure point.

Sophos reported in 2025 that only about half of ransomware attacks still involve any encryption, the lowest rate in six years. Some crews have dropped it entirely. Silent Ransom Group, a Conti offshoot, has spent years running pure data-theft extortion against U.S. law and finance firms with no encryptor at all.

The Kairos chat fits a familiar negotiation pattern, too. When Black Basta's internal chats leaked in February 2025, an analysis of the messages turned up a deal that ran from a $1.5 million demand to a $100,000 counter to a $1 million payment, almost the same arc. Those chats, and the Conti leaks before them in 2022, are how researchers now reconstruct the way these bargains actually get struck.

Kairos itself has gone quiet. The leak site is down, and its last known victim showed up in June 2026. But a wallet tied to the operation was still moving money as recently as May 2026, a reminder that a dark leak site is not the same as a dead crew.

For anyone running a small government network, the lessons are dull and familiar, which is rather the point. Turn on multi-factor authentication, since Kairos claimed it got in by simply guessing a password.

Watch for repeated failed logins, large outbound data transfers, and burner file-sharing links like the temp.sh addresses Kairos used to move the files. Keep legal, HR, and citizen records walled off from the rest of the network. Have a public statement plan ready before you need one. And treat any promise to delete stolen data as worth exactly nothing.



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

North Korean Hackers Publish 108 Malicious Packages and Extensions in PolinRider Campaign

The North Korean threat actors linked to the Contagious Interview campaign have been observed publishing 108 unique packages and web browser extensions spanning npm, Packagist, Go, and Google Chrome as part of an ongoing activity referred to as PolinRider.

"The campaign remains active, and new malicious packages are likely to continue appearing as threat actors compromise maintainer accounts, modify legitimate repositories, and publish infected package versions where they retain or obtain registry access," Socket security researcher Karlo Zanki said in an analysis published this week.

The 162 malicious release artifacts span multiple release versions corresponding to 108 unique packages and extensions, including 19 npm libraries, 10 Composer packages, 61 Go modules, and one Google Chrome extension.

Contagious Interview is the moniker assigned to a North Korea-aligned campaign that weaponizes job recruitment to target software developers and individuals working in the cryptocurrency sectors, using persuasive job interviews and assessments to trick them into executing malicious code.

Cybersecurity

The activity is known to be active since at least 2023. Attackers masquerade as recruiters or collaborators on platforms like LinkedIn, GitHub, or freelance websites, often setting up elaborate front companies and AI-generated employee profiles to build trust and ultimately deliver malware.

PolinRider was first flagged by the OpenSourceMalware team in March 2026, describing it as involving the threat actors implanting malicious obfuscated JavaScript payloads in hundreds of public GitHub repositories belonging to several unique owners to deliver a new variant of BeaverTail, a known JavaScript malware associated with Contagious Interview.

As of April 11, 2026, the activity has compromised 1,951 public GitHub repositories associated with 1,047 unique owners, while also merging with another cluster called TaskJacker that drops malicious VS Code task files into GitHub users' existing repositories. The VS Code tasks include the "runOn: 'folderOpen'" option to trigger the execution of arbitrary code when the folder is opened as a workspace folder in an IDE like VS Code or Cursor. 

"The threat actor is not using stolen GitHub credentials," OpenSourceMalware said. "Instead, the victims have been compromised via a malicious VS Code extension or npm package." It's believed that the attackers are taking over maintainer accounts, likely through expired domain takeover or another account recovery path, to pull off the scheme.

Once executed, the malware searches the infected computer for certain files like "postcss.config.mjs," "tailwind.config.js," "eslint.config.mjs," next.config.mjs," babel.config.js," and "app.js," and, if found, appends malicious JavaScript code to them.

It also makes use of a Windows batch script to stealthily modify the last commit, while making it appear as if they were made by the original author. It's suspected that similar tools are being utilized to rewrite Git history for other operating systems like Linux and macOS.

"The core tradecraft remains consistent across the campaign: threat actors plant obfuscated JavaScript loaders in legitimate repositories, conceal the code through whitespace padding or fake .woff2 font files, and trigger execution through developer tooling such as VS Code task files," Socket said.

Cybersecurity

In the latest wave, the payload functions as a JavaScript malware loader that reaches out to blockchain infrastructure, including TRON, Aptos, and BNB Smart Chain services, to fetch an encrypted second-stage payload that unpacks to DEV#POPPER RAT and OmniStealer. This attack chain was detailed by eSentire in March 2026.

"The threat actors use Git history rewriting, including force pushes and anti-dated commits to make malicious changes appear older and less suspicious," Zanki said. "This makes the GitHub landing page and visible commit history unreliable indicators of compromise; defenders should review repository activity logs, package release metadata, VS Code task configuration, and suspicious changes to configuration files."

The development comes as JFrog uncovered a cluster of npm packages linked to Contagious Interview, some of which masqueraded as Rollup polyfill tools to enable remote access and data theft. Earlier this week, another set of npm packages and Go packages was identified as incorporating VS Code auto-run tasks to run JavaScript payloads disguised as fake font files, indicating tactical overlaps between Fake Font, TaskJacker, and PolinRider.

Users who have installed these packages should treat the environment as compromised, rotate exposed secrets from a clean machine, remove affected versions and rebuild from a known good lockfile, and audit developer workstations and repositories for hidden execution paths or suspicious commits that have modified ".vscode/tasks.json," "config.js," "vite.config.js," and "eslint.config.js" files.

Found this article interesting? Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.



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