Posts on Security, Cloud, DevOps, Citrix, VMware and others.
Words and views are my own and do not reflect on my companies views.
Disclaimer: some of the links on this site are affiliate links, if you click on them and make a purchase, I make a commission.
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
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
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
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 Managementpoints 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.
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 risk‑based 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. Code‑to‑cloud 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.
The Frost Radar™ for Cloud Security Posture Management visualizes how leading vendors compare across innovation and growth—two key measures of market leadership and future potential. Microsoft is positioned in the upper-right quadrant alongside top providers, reflecting strong performance in both innovation and growth as CSPM continues to evolve into a broader, integrated cloud security capability.
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.
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
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
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
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
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
There’s a level of unhappiness and distrust of the frontier labs from CEOs
There needs to be an application layer on top of LLMs (e.g. “harness”, Palantir Ontology)
This application layer prevents the LLMs from learning your business from your data
“Alpha” is business differentiation (ability to outperform the market)
He questions why the frontier model labs are charging by tokens and not outcomes (questions the entire AI business model)
He questions “the true cost” of AI outputs
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”)
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
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.
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.
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
Security firm runZero has disclosed seven vulnerabilities in FatFs, a small filesystem library that lets a device read and write the FAT and exFAT formats used on USB drives and SD cards.
The flaws matter because FatFs is nearly everywhere. It ships inside the firmware that runs security cameras, drones, industrial controllers, hardware crypto wallets, and other devices built on real-time operating systems.
On the worst-affected systems, an attacker who gets a booby-trapped USB drive, SD card, or update file onto a device can corrupt its memory and run their own code.
Many embedded devices lack the memory protections found on phones and desktops, which is why runZero says "any physical access leads to a jailbreak." A public kiosk, a camera with an SD slot, an ATM, or a voting machine with a USB port should not hand over full control after a moment of physical access, but here it can.
All seven bugs work the same basic way. The device tries to read a storage volume or firmware image that has been deliberately malformed, and FatFs mishandles the bad data. runZero rated the set CVSS Medium to High, with no Criticals.
The headline bug is CVE-2026-6682 (CVSS 7.6), an integer overflow in the code that mounts a FAT32 volume. Bad math can produce a false file size, which later code treats as a real read length. On real hardware, that can become memory corruption and code execution.
Here are all seven, worst first by runZero's ranking:
CVE-2026-6682 (7.6, High): FAT32 mount integer overflow leading to memory corruption and possible code execution. Reachable through some firmware updates, not just physical media.
CVE-2026-6687 (7.6, High): an exFAT volume-label field overflows a small buffer, giving an attacker a clean memory-corruption foothold.
CVE-2026-6688 (7.6, High): long filenames overflow the wrapper code many projects put around FatFs, such as a strcpy of fno.fname into a fixed buffer. Hard to fix inside FatFs alone.
CVE-2026-6685 (6.1, Medium): a math wrap in cache handling on fragmented volumes that can silently corrupt data.
CVE-2026-6683 (4.6, Medium): an exFAT divide-by-zero that crashes the device. In an update flow, it can brick hardware. Also reachable through some firmware updates.
CVE-2026-6686 (4.6, Medium): a file extended past its end can leak leftover data from previously deleted files.
CVE-2026-6684 (4.6, Medium): a malformed GPT partition table (the disk's map) can hang the device during mount. It is the only one of the seven fixed upstream, in FatFs R0.16.
Here is the hard part. FatFs is maintained by one developer in a small corner of the internet, and runZero says it tried repeatedly to reach the maintainer and looped in Japan's JPCERT/CC coordination center, with no response.
By runZero's account, there is no upstream fix for the memory-corruption bugs, no security mailing list, and no way for the many products that bundle FatFs to learn they are affected. Updating helps with the GPT hang, since the current release blocks it, but the rest fall to downstream vendors to patch on their own.
runZero names affected platforms, including Espressif ESP-IDF, STMicroelectronics STM32Cube, Zephyr, MicroPython, ArduPilot, RT-Thread, Mbed, Samsung TizenRT, and the SWUpdate updater. That pushes the problem downstream into consumer IoT, industrial gear, drones, and crypto wallets.
As of runZero's July 1 disclosure, no attacks using these bugs had been reported, and none have surfaced since. But the exploit material is already public: runZero shipped proof-of-concept disk images, a test harness, and a working QEMU-based exploit example in a companion repository.
If you build firmware that touches FAT or exFAT media, the advice is direct. Find the copy of FatFs in your product, audit the wrapper code around it, look hard at how you handle filenames and file sizes, and plan to patch.
If you run affected devices, treat physical ports and update channels as an attack surface: limit who can plug in media, and watch for vendor firmware updates.
Why this keeps happening
runZero first audited FatFs by hand in 2017 and found little worth reporting. Returning in March 2026, the team pointed an off-the-shelf setup at the same code: Visual Studio Code, GitHub Copilot in "auto" mode, and a few plain prompts.
The LLM built a fuzzer, a tool that feeds malformed data into code until something breaks. That surfaced bugs the manual audit had missed and helped confirm they were exploitable.
Just last month, an autonomous AI agent surfaced 21 memory-safety bugs in FFmpeg, another widely embedded C library. runZero's point is blunt: if a mostly off-the-shelf AI pipeline can find these, so can anyone, so sitting on them quietly protects no one.
The patching problem is familiar. runZero expects downstream fixes to take years, not days, and PixieFail is the precedent: a 2024 batch of nine bugs in the network-boot code of EDK II, the firmware behind many PC and server brands, that vendors were slow to patch. FatFs has the same shape and a weaker fix pipeline, because there is no responsive upstream at all.
Watch for two things: whether the FatFs maintainer resurfaces with a patch, and how the big platform vendors that bundle it respond. Until they do, assume that plenty of shipping devices read untrusted storage with code that has no fix behind it.
from The Hacker News https://ift.tt/1kxMnDr
via IFTTT
Cybersecurity researchers have discovered a previously undocumented modular malware framework codenamed Avalon that's distributed by means of a multi-stage phishing chain capable of bypassing traditional security controls.
Avalon combines credential collection, lateral movement, remote access, recovery disruption, and ransomware execution, bringing together diverse functions under one umbrella. The ransomware component has been internally named CrownX.
"The attack began with a spoofed legal document email directing recipients to a password protected archive on Proton Drive," Blackpoint Cyber researchers Nevan Beal and Sam Decker said. "Malicious content was embedded inside an ISO image rather than attached directly, reducing the likelihood of detection at the email layer."
Should the email recipient interact with a document-themed Windows Shortcut ("Secure Document CA-283505.pdf.lnk") inside the mounted image, it triggers a staged malware sequence that culminates in the deployment of Avalon. Specifically, the shortcut runs a command to launch an MSBuild project located in the ISO image.
The MSBuild project, for its part, loads an embedded .NET assembly, which then interferes with the regular functioning of Event Tracing for Windows (ETW) to reduce forensic visibility and download a next-stage payload over HTTPS responsible for launching Avalon.
The malware framework boasts of an extensive defense evasion subsystem that aims to evade detection, while incorporating specific methods to conceal execution from security tools associated with Microsoft Defender, SentinelOne, CrowdStrike, Sophos, Elastic Endpoint, FortiEDR, ESET, McAfee, and Bitdefender.
"These capabilities give the framework a multitude of ways to reduce telemetry, bypass user mode monitoring, and adjust its execution depending on the defensive controls present on the host," the researchers said.
The complete set of features built into Avalon is as follows -
Harvest credentials, cookies, history, and bookmarks from Chromium-based browsers and Mozilla Firefox.
Gather data from cryptocurrency wallet apps like MetaMask, Phantom, Coinbase Wallet, Exodus, Electrum, Atomic Wallet, Ledger Live, and Bitcoin Core, along with Discord, Slack, Teams, OpenVPN, WireGuard, and Windows Credential Manager.
Collect details about SSH known hosts, saved RDP connections, Wi-Fi profiles, and Group Policy Preferences cpassword artifacts.
Exfiltrate data to a remote server ("helloxcherry[.]com") and poll the server for receiving tasking commands.
Perform reconnaissance and prioritize systems that can expand the scope of the compromise.
Encrypt files associated with business operations, software development, engineering, data storage, and virtual infrastructure using Windows Cryptography API and deliver a ransom note containing payment instructions and deadline timers that show how much time is left before the ransom amount is increased.
Inhibit system recovery by terminating the Volume Shadow Copy Service and deleting shadow copies.
Remove traces of artifacts using an anti-forensic cleanup subsystem to complicate incident response efforts.
Directly interact with disk structures likely in an effort to damage partition information, boot records, or other critical areas of the drive, effectively rendering the system unusable.
"CrownX represented the final extortion stage, but the damage extended well beyond the encryption itself," the company said. "By the time the ransom note appeared, the broader framework had already collected credentials, established C2 communications, prepared multiple paths for lateral movement, and weakened local recovery options."
Another important detail is that Avalon shows signs of artificial intelligence (AI)-assisted development, one that has assembled multiple components with scant regard for sophisticated tradecraft or operational security, something that requires significant expertise to build.
The findings are yet another sign of how AI can lower the barrier to entry, making malware development more accessible with little time and effort, and even allowing actors with little technical expertise and resources to come up with tools that may require extensive development effort. In other words, the presence of a certain capability is no longer a reliable indicator of a threat actor's sophistication or operational maturity.
"The kill chain illustrates how a familiar business lure can progress into a reusable, multi-capability framework designed to harvest credentials, retrieve subsequent payloads entirely in memory, and stage multiple follow-on actions from a single compromised endpoint," Blackpoint Cyber said.
LLM Behind an Agentic Ransomware Attack
The disclosure comes as Sysdig detailed what it said was the first publicly documented agentic ransomware infection driven by a large language model from start to finish, while retrying and tweaking its actions in real-time to complete tasks. The agentic threat actor (ATA) behind the operation has been codenamed JADEPUFFER.
The operator "gained initial access to an internet-facing Langflow instance through CVE-2025-3248 and ran an adaptive and fully automated campaign, ultimately pivoting to the intended target and running a destructive database-extortion playbook against the victim's production database server," Sysdig's Michael Clark said.
"The skill floor for running ransomware has dropped to whatever it costs to run an agent, and if that agent is running on stolen credentials through LLMjacking, the cost to an attacker is close to zero."
AI Malware That Uses LLM in a Codeless Attack
The findings also follow the discovery of an AI malware that brings together a Telegram bot with a public LLM API to devise a codeless attack. Once launched, the implant transmits basic details about the compromised system to the attacker's Telegram bot and enters into a command-and-control (C2) loop that polls the bot API every 5 seconds for new messages. The results of the command execution are exfiltrated back using the same channel.
The speciality of this malware is that each operator message is forwarded to a public LLM API endpoint ("api.groq[.]com/openai/v1/chat/completions"), which then translates the natural language instructions provided by the attacker into its equivalent shell command. The artifact was uploaded to the VirusTotal platform on March 11, 2026, and has zero detections across all engines to date.
"This work introduces an LLM translation layer that replaces shell syntax with plain text. The attacker types plaintext instructions in Telegram," Palo Alto Networks Unit 42 said. "The LLM translates the instructions into shell commands. And the victim executes the shell commands. No command-line knowledge is required."
from The Hacker News https://ift.tt/uEayDvm
via IFTTT
