A zero-day vulnerability in WinRAR is being exploited by at least two Russian criminal groups:
The vulnerability seemed to have super Windows powers. It abused alternate data streams, a Windows feature that allows different ways of representing the same file path. The exploit abused that feature to trigger a previously unknown path traversal flaw that caused WinRAR to plant malicious executables in attacker-chosen file paths %TEMP% and %LOCALAPPDATA%, which Windows normally makes off-limits because of their ability to execute code.
Unpacking the attack took work because much of the JavaScript in the .svg images was heavily obscured using a custom version of “JSFuck,” a technique that uses only a handful of character types to encode JavaScript into a camouflaged wall of text.
Once decoded, the script causes the browser to download a chain of additional obfuscated JavaScript. The final payload, a known malicious script called Trojan.JS.Likejack, induces the browser to like a specified Facebook post as long as a user has their account open.
“This Trojan, also written in Javascript, silently clicks a ‘Like’ button for a Facebook page without the user’s knowledge or consent, in this case the adult posts we found above,” Malwarebytes researcher Pieter Arntz wrote. “The user will have to be logged in on Facebook for this to work, but we know many people keep Facebook open for easy access.”
This isn’t a new trick. We’ve seen Trojaned .svg files before.
Security teams often need to analyze potentially malicious files, binaries, or behaviors in a tightly controlled environment. While this has traditionally been done in on-premises sandboxes, the flexibility and scalability of AWS make it an attractive alternative for running such workloads.
However, conducting malware analysis in the cloud brings a unique set of challenges—not only technical, but also policy-driven. Amazon Web Services (AWS) enforces a range of policies that govern acceptable use, prohibited activities, and testing permissions. For more information see AWS Acceptable Use Policy and AWS Service Terms.
Security teams must architect their malware analysis environments in a way that adheres to these policies, enforces strong isolation, and helps prevent misuse or escalation of privileges.
Setting up secure malware analysis environments that meet compliance requirements can be challenging, especially in cloud environments. Security teams need isolated sandbox environments, robust security controls, and proper monitoring policies to safely analyze malware. In this post, we discuss the basic steps to build these capabilities in AWS, showing you how to implement best practices for both new deployments and migrations of existing malware analysis workloads. You’ll learn how to create secure, compliance-aligned analysis environments that align with AWS policy requirements.
Problem statement
Performing malware analysis in AWS introduces unique security and operational challenges. Unlike typical workloads, malware analysis environments must be treated with heightened caution because of the risk of malicious behavior and the need to strictly adhere to the AWS Acceptable Use Policy and AWS Service Terms.
Figure 1 is a high-level illustration of the malware analysis architecture.
Figure 1: Malware analysis architecture
At a high level, the malware analysis architecture includes:
A security analyst gains access to the environment through AWS Systems Manager Session Manager.
The analyst connects to an EC2 instance (malware detonation host) in a private subnet.
The subnet resides in a dedicated isolated VPC within the AWS malware analysis account and has no outbound connectivity.
The EC2 instance connects to the malware samples and artifacts bucket through a VPC gateway endpoint for Amazon S3.
Data is transferred securely using encrypted transfer.
Key considerations
Conducting malware analysis in AWS requires a thoughtful balance between flexibility, security, and compliance to help make sure that teams operate within AWS policies while minimizing risk and cost.
Adhering to AWS policies and service terms: Activities such as simulating malware behavior or generating exploit traffic might fall under restricted use cases defined in the AWS Acceptable Use Policy and Service Terms. In addition, teams must submit a formal request for approval through the penetration testing and simulated events form for malware testing.
Need for isolation: Malware analysis requires isolated environments that can safely contain malicious code without exposing internal resources, AWS services, or other accounts. In addition, no malicious traffic is allowed to leave the Amazon Virtual Private Cloud (Amazon VPC).
Guardrails and lifecycle management: Without clear boundaries, sandbox accounts can become long-lived, misused, or even treated as production environments—potentially increasing your exposure to security risks or incurring ongoing costs unnecessarily. Guardrails such as budget alerts, lifecycle automation, and AWS Identity and Access Management (IAM) permission boundaries are essential.
Lack of unified patterns: Existing AWS guidance covers sandboxing and security best practices but doesn’t provide a focused blueprint for malware analysis that aligns with policy constraints, isolation needs, and security operations.
Architecture building blocks
Designing a secure malware analysis environment in AWS begins with containment. The architecture must assume that the code under investigation is malicious and capable of attempting escape, exfiltration, or lateral movement. That’s why isolation, tight access controls, and strict egress management are a core requirement of the architecture described below.
Network isolation with Amazon VPC
The foundation of a secure sandbox is a dedicated VPC in a dedicated account that is fully isolated from other workloads. Key considerations include:
Note: Outbound traffic can be allowed out from AWS in a bring your own IP (BYOIP) scenario for approved use cases.
No internet access: Egress should be completely blocked. NAT gateways, internet gateways, and VPC endpoints should be avoided unless explicitly needed and secured. This helps make sure that malware samples cannot beacon out or download additional payloads.
DNS disabled: To help prevent malware from resolving command-and-control (C2) infrastructure, disable DNS resolution in the VPC settings unless simulation tools (such as INetSim) require it, in which case they must operate strictly inside the same VPC.
IAM and permission boundaries
IAM plays a critical role in helping to make sure that the sandbox doesn’t gain unexpected permissions over time.
Enforce the principle of least privilege (PoLP), which means granting only the minimum permissions necessary for users, roles, and services to perform their required tasks.
Use permission boundaries to scope what roles within the sandbox can do, even if they’re granted broader policies later.
Help prevent sandbox IAM roles or users from creating or modifying IAM resources or attaching policies.
Use service control policies (SCPs) to block privilege escalation or cross-account access from the start.
Instance hardening
Even though malware analysis sandbox accounts are designed to be isolated, every instance should be hardened:
Use hardened Amazon Machine Images (AMIs) (such as CIS benchmark), and keep systems fully patched before use. See Building CIS hardened Golden Images as an example.
Make sure that host-level monitoring is enabled using agents such as AWS Systems Manager, Amazon CloudWatch Agent, Amazon GuardDuty Runtime Monitoring, or external endpoint detection and response (EDR) tooling (without enabling internet connectivity).
Note: The Systems Manager Agent requires access to Systems Manager endpoints to maintain updates and will regularly report node status. Consider this connectivity requirement when designing your isolation strategy.
GuardDuty Runtime Monitoring requires a VPC endpoint and will transmit telemetry data to the GuardDuty service. GuardDuty findings can be generated based on activities observed on the host, which could be expected behavior in a malware analysis environment.
Detonation hosts should be built to be ephemeral—treated as single-use, with instance refreshes after each session to avoid persistence.
Storage and containment
Proper storage configuration is critical when handling malware samples and related artifacts. Storage solutions, particularly Amazon Simple Storage Service (Amazon S3) buckets, must implement multiple layers of security controls, as described in the following lists.
Encryption requirements:
Enable default encryption on all S3 buckets
Use either AWS Key Management Service (AWS KMS) customer managed keys (CMK) or AWS managed keys for encryption based on your security requirements
Enforce encryption in transit by requiring HTTPS (TLS) using bucket policies
Deny any unencrypted object uploads using bucket policies
Network access:
Configure VPC endpoints (gateway endpoints) for Amazon S3 to help facilitate private communication within the VPC
Implement endpoint policies to restrict access to specific buckets and actions
Avoid cross-account sharing of buckets used in malware analysis unless absolutely necessary and reviewed on an ongoing basis.
Implement least-privilege bucket policies that explicitly deny access except to approved sandbox roles or accounts
Use resource-based policies to help prevent cross-account access unless specifically required
Enable Versioning in Amazon S3 to help prevent accidental or malicious overwrites
Enable Amazon S3 Object Lock (if needed) to help prevent deletion of critical log files or samples
Monitoring, guardrails, and operational controls
A secure malware analysis environment in AWS must balance controlled flexibility with enforced boundaries. Even in an isolated VPC, human error is possible, tools might not operate as intended, and malicious code can attempt to escape or persist. That’s why you need layers: visibility, guardrails, and operational discipline.
This section covers how to monitor activity, detect threats, and enforce sandbox boundaries—whether you’re operating in an organization within AWS Organizations or a standalone account.
Monitoring activity using AWS CloudTrail
AWS CloudTrail is an AWS service that helps you enable operational and risk auditing, governance, and compliance of your AWS account. Actions taken by a user, role, or an AWS service are recorded as events in CloudTrail.
GuardDuty: Native threat detection
GuardDuty is a threat detection service that continuously monitors your AWS environment for malicious activity through the analysis of VPC Flow Logs, CloudTrail logs, and DNS logs. When implemented in a malware analysis environment, GuardDuty generates findings that detail potential security threats that it detects through machine learning models and threat intelligence feeds. Security teams should note that in a malware analysis sandbox, GuardDuty will generate findings for activities that might be intentional parts of the analysis process. It’s crucial to establish proper procedures for reviewing and categorizing these findings, distinguishing between expected sandbox behavior and actual security concerns.
Organizations should configure appropriate notification workflows and create baseline expectations for normal sandbox operations. This enables security teams to focus on findings that might indicate sandbox escape attempts or unexpected malicious activities while properly managing expected alerts from normal analysis operations. Each finding provides detailed information about the detected activity, including the affected resources, severity level, and specific details about the potential security issue, enabling teams to make informed decisions about necessary response actions.
Service control policies: Policy guardrails in AWS Organizations
For malware analysis environments, we recommend operating the sandbox account within AWS Organizations rather than as a standalone account. This strategy uses SCPs to establish critical security boundaries while maintaining necessary operational flexibility. Operating within Organizations enables centralized security policy enforcement, clear isolation from production workloads, and enhanced audit capabilities—all essential for secure malware analysis operations. While this approach might require additional governance overhead and careful organizational unit (OU) structure design, the security benefits outweigh these considerations.
By placing the malware analysis account in a dedicated OU with specific SCPs, you can enforce strict security controls while enabling necessary analysis capabilities. This organizational structure maintains clear separation from production workloads while providing the robust security controls needed for malware analysis activities. The ability to implement granular permission boundaries through SCPs, combined with centralized logging and monitoring, creates a more secure and manageable environment for conducting malware analysis while helping to prevent potential security risks from affecting other organizational resources.
For malware analysis we recommend implementing SCPs to enforce the following:
Deny accounts from leaving the organization: When an account leaves an organization, it’s no longer bounded by the controls established within that organization. This SCP can be used to help prevent someone from moving an account to a different organization that has a set of different controls that aren’t as restrictive and there is risk of someone making undesired changes.
Deny access to specific AWS Regions (reduce surface area): AWS has 37 Regions, yet customers scope down to one Region when it comes to malware analysis. This SCP gives you the ability to limit the Regions where AWS resources can be deployed, thus reducing the scope of impact.
Help prevent escalation of privileges: Privilege escalation refers to the ability of a threat actor to use stealthy permissions to elevate permission levels and compromise security. To help prevent privilege escalation, use SCPs to help prevent users in your accounts from using administrative IAM actions, except from approved roles. With this policy, administrative IAM actions can be restricted to delegated IAM admins. You can use permissions boundaries to safely delegate permissions management to trusted employees or a continuous integration and delivery CI/CD pipeline.
What if your account isn’t a part of an organization?
If your environment doesn’t use AWS Organizations and SCPs aren’t available, you can enforce similar boundaries using IAM permissions boundaries and identity-based policies:
Use permissions boundaries for roles used in the sandbox to prevent them from escalating or accessing other AWS services
Explicitly deny sensitive IAM actions (such as iam:*Policy, iam:PassRole) at the identity policy level
Implement resource tagging policies through AWS Organizations or custom enforcement logic to provide resource ownership and control
Operational best practices
The following best practices help make sure your sandbox remains ephemeral, controlled, and cost-aware.
Immutable by design: Treat analysis virtual machines (VMs) as disposable. Never reuse a detonation instance across sessions
Automated teardown: Use lifecycle policies or automation scripts to destroy resources after each use
Cost and drift control: Tag relevant resources (Environment=sandbox, Owner=security), enable AWS Budgets, and monitor with AWS Config to help maintain sandbox hygiene
Setup checklist
This checklist provides a step-by-step guide for creating a secure malware analysis environment in AWS, focusing on isolation, access control, monitoring, and cost.
Submit a formal request for approval through the penetration testing and simulated events form for malware testing. This needs to be done for every simulated event you plan on running.
Account setup
Use a dedicated AWS account for malware analysis (if the account is part of an organization, also use a dedicated OU).
Apply SCPs to restrict Region access, deny IAM changes, and enforce tagging and encryption.
VPC design
Create a dedicated sandbox VPC with no internet gateway or NAT gateway.
Disable DNS resolution at the VPC level (unless simulating Amazon EC2 behavior internally).
Verify that no public IPs are assigned to any resource.
Use security groups and network access control lists (network ACLs) to restrict ingress to known internal IP ranges.
Disable SSH; use Systems Manager Session Manager for access.
Use EC2 Auto Recovery or instance refresh patterns for teardown between analyses.
Storage and logging
Use encrypted S3 buckets for sample storage and log archival.
Make sure that audit logs (CloudTrail) are retained and protected.
Store logs centrally in a secure logging account.
Monitoring and detection
Enable GuardDuty for behavioral detection (VPC, API, and DNS analysis).
Enable AWS Config rules to detect drift (for example, internet gateways and public IPs).
Set up a dedicated CloudTrail log for the relevant account with multi-Region logging for full traceability.
Enabling VPC Flow Logs and Amazon Route 53 query logs might provide additional visibility into how the malware is operating.
IAM and permissions
Generate policies using AWS IAM Access Analyzer policy generation. You can use this to generate an IAM policy that is based on access activity for an entity. You can then refine the policy to exactly what is needed to operate in the account and adhere to the principle of least privilege.
Apply permission boundaries to sandbox roles to restrict privilege scope.
IAM permissions should forbid/minimize cross account access where applicable
Restrict use of services outside the malware analysis scope. See the following documentation on how to only allow the use of a subset of services in your environment
Tag to assist with financial allocation, ownership and support use cases (for example, Environment=sandbox, Purpose=malware-analysis). For more information, see Best Practices for Tagging AWS Resources.
Conclusion
Malware analysis can be an effective addition to modern security operations—but when conducted in cloud environments, it demands strict architectural discipline and adherence to system-level policies. AWS offers the tools and services needed to build secure, isolated, and policy-aligned environments.
This guide has outlined a defense-in-depth approach that you can use to create a malware analysis sandbox in AWS that prioritizes isolation, visibility, and control. From VPC configuration and IAM boundaries to monitoring and organizational guardrails, each layer contributes to a controlled and repeatable environment while reducing risk to your broader AWS environment.
By following these patterns, you can empower your security teams to investigate threats without compromising the integrity, security, or governance of your broader AWS environment.
It will be interesting to watch what will come of this private lawsuit:
Google on Thursday announced filing a lawsuit against the operators of the Badbox 2.0 botnet, which has ensnared more than 10 million devices running Android open source software.
These devices lack Google’s security protections, and the perpetrators pre-installed the Badbox 2.0 malware on them, to create a backdoor and abuse them for large-scale fraud and other illicit schemes.
This reminds me of Meta’s lawauit against Pegasus over its hack-for-hire software (which I wrote about here.) It’s a private company stepping into a regulatory void left by governments.
Massistant is the presumed successor to Chinese forensics tool, “MFSocket”, reported in 2019 and attributed to publicly traded cybersecurity company, Meiya Pico.
The forensics tool works in tandem with a corresponding desktop software.
Massistant gains access to device GPS location data, SMS messages, images, audio, contacts and phone services.
Meiya Pico maintains partnerships with domestic and international law enforcement partners, both as a surveillance hardware and software provider, as well as through training programs for law enforcement personnel.
The good news, per Balaam, is that Massistant leaves evidence of its compromise on the seized device, meaning users can potentially identify and delete the malware, either because the hacking tool appears as an app, or can be found and deleted using more sophisticated tools such as the Android Debug Bridge, a command line tool that lets a user connect to a device through their computer.
The bad news is that at the time of installing Massistant, the damage is done, and authorities already have the person’s data.
A whole class of speculative execution attacks against CPUs were published in 2018. They seemed pretty catastrophic at the time. But the fixes were as well. Speculative execution was a way to speed up CPUs, and removing those enhancements resulted in significant performance drops.
Now, people are rethinking the trade-off. Ubuntu has disabled some protections, resulting in 20% performance boost.
After discussion between Intel and Canonical’s security teams, we are in agreement that Spectre no longer needs to be mitigated for the GPU at the Compute Runtime level. At this point, Spectre has been mitigated in the kernel, and a clear warning from the Compute Runtime build serves as a notification for those running modified kernels without those patches. For these reasons, we feel that Spectre mitigations in Compute Runtime no longer offer enough security impact to justify the current performance tradeoff.
I agree with this trade-off. These attacks are hard to get working, and it’s not easy to exfiltrate useful data. There are way easier ways to attack systems.
There has been a significant decrease in social engineering attacks linked to the Black Basta ransomware group since late December 2024. This lapse also included the leaked Black Basta chat logs in February 2025, indicating internal conflict within the group. Despite this, Rapid7 has observed sustained social engineering attacks. Evidence now suggests that BlackSuit affiliates have either adopted Black Basta’s strategy or absorbed members of the group. The developer(s) of a previously identified Java malware family, distributed during social engineering attacks, have now been assessed as likely initial access brokers, having potentially provided historical access for Black Basta and/or FIN7 affiliates.
Figure 1. Confirmed malicious chat requests, Feb 12 through May 7, as observed by Rapid7.
Overview
The first stage of the attack remains the same. The operator will flood targeted users with a high volume of emails, to the order of thousands per hour. This is often accomplished by signing the target user’s email up to many different publicly available mailing lists at once, effectively creating a denial of service attack when each service sends a welcome email. This technique is commonly known as an email bomb.
Following the email bomb, the strategy then splits between operators, though they all ultimately reach out to impacted users pretending to be a member of the targeted organization’s help desk. The majority of operators still perform this step via Microsoft Teams using either a default Azure/Entra tenant (i.e., email account ends with onmicrosoft[.]com) or their own custom domain. In rare cases however, operators, particularly those affiliated with BlackSuit, may forgo Microsoft Teams in favor of calling the targeted users directly with a spoofed number. This strategy, if successful, allows them to circumvent the cloud logging that would be recorded otherwise. For the first time, an explanation of the process written by Black Basta’s leader is also available for a summary of the process, in the context of explaining the attack to a new affiliate:
If the affiliate is able to gain the user’s confidence, they will still primarily attempt to gain access to the user’s asset — and thereby the corporate network — via Quick Assist. Quick Assist is a built-in Windows utility that allows a user to easily grant remote access to their computer to a third party. The utility has been widely abused for social engineering attacks, a trend which continues. BlackSuit affiliates in particular may also direct the user to a malicious domain that hosts a fake Quick Assist login page, for the purpose of harvesting their credentials.
Figure 3. Fake Quick Assist login page, functions as a credential harvester.
In cases where the affiliate is unable to get Quick Assist to work, they will still cycle through a variety of other popular remote access tools (e.g., AnyDesk, ScreenConnect), and if that still doesn’t work, they may simply hang up on the user and move on to the next target.
Figure 4. One of Black Basta’s operators discusses their strategy regarding remote access tools.
Black Basta had at least one caller template/script for this purpose:
Quickly obtaining reliable access to the target network is still the top priority in the early stages of the attack, typically facilitated by stealing the targeted user’s credentials. In the past this has been achieved, for example, via a QR code sent to the target user via Microsoft Teams or the download and execution of malware which creates a fake Windows authentication prompt.
Figure 6. One of Black Basta’s operators discusses the usage of QR codes for credential harvesting.
In some cases the operator who makes the initial call may also coerce the target user to provide an MFA code while still on the phone. Historically, operators will also attempt to steal VPN configuration files once remote access is established, which can allow them to authenticate directly to the network if the compromised user account is not remediated.
Figure 7. One of Black Basta’s operators discusses using stolen credentials to authenticate directly to the VPN for the targeted environment.
After the affiliate has successfully gained access they will typically transfer and execute malware on the compromised system. The specific malware differs per operator and typically marks the stage in which the access is passed from the caller to an operator within the group who specializes in what they refer to as “pentesting.” To facilitate the access, the operator who calls typically coordinates with the “pentester” to increase the chances of success. At this point in the attack the affiliate who called the user has already hung up under the guise of having fixed the spam problem, and the “pentester” then begins to enumerate the environment. Rapid7 has observed AS-REP and Kerberoasting attacks to be commonly attempted along with Active Directory Certificate Services (ADCS) abuse and other types of brute force password attacks.
Technical Analysis
After initial access has been achieved, the follow-on malware payloads that are downloaded to the compromised system and executed differ, per operator.
Java RAT
A large volume of social engineering incidents handled by Rapid7 have resulted in a Java RAT being downloaded and executed. This tactic was first observed by Rapid7 during October of 2024, and initially reported on in December 2024 in relation to the payload identity.jar. The first samples of the Java RAT observed by Rapid7 only utilized Microsoft OneDrive with optional proxy servers (e.g., SOCKS5) for a more direct C2 connection. The configuration was left in plain text, and did not contain any functionality to dynamically update or encrypt the configuration, primarily functioning only as a RAT via PowerShell session commands.
In the past 6+ months, development of the Java malware payload has continued to add/change numerous features. The Java malware now abuses cloud-based file hosting services provided by both Google and Microsoft to proxy commands through the respective cloud service provider’s (CSP) servers. Over time, the malware developer has shifted away from direct proxy connections (i.e., the config option is left blank or not present), towards OneDrive and Google Sheets, and most recently, towards simply using Google Drive. The logic of the RAT is obfuscated using various types of junk code, control flow obfuscation, and string obfuscation in an attempt to impede analysis.
Figure 8. Obfuscated logic within the Java RAT, where three simple statements become dozens of lines and indentations.
The Java RAT and other payloads are distributed within an archive, the link for which is most often sent to the target user via a pastebin[.]com link. In cases as recent as May of 2025, Rapid7 has observed that the archives are still being publicly hosted on potentially compromised SharePoint instances. The archive and the payloads within are named to fit the initial social engineering lure. For example, in a recent incident, the archive was named Email-Focus-Tool.zip, likely to help prevent suspicion by the targeted user during the attack. The archive contains a .jar file (the Java RAT), a copy of required JDK dependencies contained within a child folder, and at least one .lnk file intended to make the malware easy to execute.
Figure 9. The contents of an archive delivered by the threat actor and a `log.txt` file containing enumeration command output.
The archive is most often extracted to the staging directory C:\ProgramData\ prior to execution. In at least one case, Rapid7 has also observed the operator who initiated the attack outputting system enumeration data to a plaintext file in the same directory, a technique commonly used in the past by Black Basta. Historically, this is information that they share during the initial stages of the attack to assess the network and the type of defenses they may have to deal with. For example, shown above, the operator who initially accessed the compromised asset spawned a command prompt and redirected the output of the ipconfig /all and tasklist commands to the file log.txt.
Most recent versions of the Java RAT have the capability to use Google Sheets to dynamically update the stored C2 configuration, which includes a Google spreadsheet ID (SSID), proxy server IPv4 addresses, application credentials (OneDrive), and/or service account credentials (Google Drive). At least one of the Google Spreadsheets used in this way was observed by Rapid7 to have been taken down by Google, which highlights the potential unreliability of using certain cloud services as a malware traffic proxy.
Figure 10. A Google spreadsheet used by the malware for dynamic configuration updates was taken down by Google.
One of the first actions taken by the malware on launch is to check for an existing configuration in the user’s registry, and if it is not already present, the copy included within the .jar payload, contained within the file config.json, is written there. All samples analyzed by Rapid7 did not have debugging messages removed, allowing them to be viewed by simply executing the .jar file in a console window, as all the debugging messages are written to stdout.
Figure 11. Debug statement output after executing the Java RAT via console.
The registry value name(s) and content for the stored config are both base64 encoded (e.g., HKCU\SOFTWARE\FENokuuTCyVq\JJSUP0CEcUw9PENaNduhsA==), with the decoded configuration content being encrypted using AES-256-ECB. The encryption key is derived from a seed that is stored as a 16 byte string within a file named ek (encryption key), that is contained within the .jar archive. The registry key name, a randomized alphabetic string, is hard coded and stored in a similar manner within the file r_path (registry path). The malware creates a SHA256 hash of the encryption key seed string, and the first 32 bytes of the SHA256 hash are then used as the AES-256-ECB key to encrypt and decrypt the malware’s configuration. Every sample analyzed by Rapid7 contained a unique key seed, though a particular sample is often distributed (within the related archive) to multiple targets for an extended period of time, often around a couple weeks.
After checking and loading the configuration from the registry, local resource, or updated configuration, the RAT will then establish at least one PowerShell session.
Figure 12. Example process tree for the Java RAT.
The stdin and stdout for the PowerShell console are used to process remote commands. The commands sent to the Java RAT are proxied through the respective CSP by the malware creating two specific files within the cloud drive. The name of the files all contain the UUID of the infected asset, which is retrieved at the malware’s startup. There are two prefixes added onto the primary communication files, cf_ and rf_ which contextually appear to stand for create file and receive file, respectively. These two files correspond to the standard output (stdin) and standard input (stdin) of the PowerShell console. The malware uses the input file in two major ways. If the cf_ file (stdin) starts with a specific command string, the content following it will be processed by the malware to execute functionality implemented by the malware developer.
Figure 13. The logic for the `loginform` command within the if-else command processing chain used by the Java RAT. The malware developer did not update one of the debug statements for Google Drive.
Otherwise, the content will be executed as a regular PowerShell command.
Figure 14. The default case in the if-else chain executes the command string via PowerShell.Figure 15. The ‘execute()’ function within the same class executes the command string as a PowerShell command via jPowerShell.
Command
Function
send
Send a file from the operator’s machine to the infected machine.
recive
Upload a file from the infected machine to the relevant cloud drive. The command string includes a typo made by the developer.
extract
Extract a specified file archive.
loginform
Present a fake login prompt to the user. Entered credentials are validated locally, and if correct, are uploaded to the operator’s machine through the cloud drive. The username must be specified by the operator.
newconfig
Replace the existing configuration with one retrieved from Google Sheets.
checkconfig
Check Google Sheets using the SSID to see if an update is available.
startsocks5
Initiate a Socks5 proxy tunnel using python.
steal
Attempt to decrypt and steal stored browser database information. (e.g., credentials)
screen
Given a supplied URL, download and execute a Java class in memory.
Table 1. Command key for the Java RAT.
The previously seen credential harvesting payload, identity.jar, has now also been integrated into the Java RAT, and instead of writing the entered credentials to a randomly named file within the working directory, the RAT sends it to the cloud drive C2 file that has been designated to the compromised host. This functionality is executed by the operator by sending the loginform (the Java class is abbreviated as “Lf”) command to the RAT via the cloud drive file. After decompiling and deobfuscating the Java code that the module consists of, it can be cleaned up, recompiled, and executed as a standalone program. This allows us to see that the appearance of the module to the targeted user is the same, including the fake “Windows Security” title. A review of the code indicates that it has not changed in any other significant way. The harvester still forces the active window on top and will not let the user close the window without entering their password or forcibly terminating the process.
Figure 16. The credential harvesting window used by the Java RAT.
As a result of the cloud service credentials being stored within the malware payload, and that, for example, Google Drive stores a revision history for every created file by default, it is possible to view the entire history of commands sent to each infected asset, including stdin and stdout.
This gives a unique in console view of what the threat actor saw while they were hands-on-keyboard and executing commands. Command log snippets can be seen below, with identifying information redacted. Once access is established, the operator nearly always verifies the user’s name with the dir command and then uses this information to execute the loginform command, as the malware does not retrieve the executing user’s name on its own.
Infected Host GUID: 4C4C4544-0038-4610-8036-B6C04F394733 2025-04-24T16:53:34.038Z: dir c:\users\ 2025-04-24T16:54:47.967Z: loginform <username> 3 2025-04-24T18:40:36.584Z: net time 2025-04-24T18:42:54.426Z: whoami 2025-04-24T18:43:48.284Z: net user <username> /domain 2025-04-24T18:48:35.089Z: hostname 2025-04-24T18:49:57.182Z: net group "Domain Computers" /domain 2025-04-24T18:50:56.578Z: net time 2025-04-24T19:17:14.259Z: ipconfig /all 2025-04-24T19:19:44.442Z: hostname
Infected Host GUID: 594045B3-008B-4106-8FF4-B850DF6C76D0 2025-04-24T17:20:09.896Z: dir c:\users\ 2025-04-24T17:20:58.179Z: loginform <username> 3 2025-04-24T17:36:52.542Z: wmic qfe list brief 2025-04-24T17:40:13.454Z: net time 2025-04-24T17:41:26.860Z: ping -n 2 <domain_controller_hostname> 2025-04-24T17:49:08.598Z: net group "Domain Computers" /domain > c:\users\public\001.txt
In some cases, Rapid7 has observed a command log gap ranging from around 4 to 12 days, beginning after the RAT is successfully executed and the user’s credentials have been stolen. In some cases an SSH tunnel is also established before activity stops. This type of behavior indicates that the threat actor may not be intending to use the access for themselves, but rather sell it to another group that specializes in fully compromising the network towards various ends (e.g., data theft, extortion, ransomware). Rapid7 has also observed the access being used to test new malware payloads and functionality, rather than progress the compromise within the targeted networks.
Qemu
In a smaller volume of incidents handled by Rapid7, operators have been observed sending the user a Google Drive link to download a zip archive containing QEMU (Quick Emulator) and its dependencies, including a custom made .qcow2 (QEMU Copy-On-Write version 2) virtual disk image. The image contains a Windows 7 Ultimate virtual machine (VM) configured to automatically logon and execute a RunOnce registry key that launches a ScreenConnect installer. In most cases a link to a fake Quick Assist login page (credential harvester) was also delivered to the targeted user by proxy via a self-destructing link service such as 1ty[.]me alongside the Google Drive zip archive link.
Figure 17. Evidence left in the .qcow2 image, including a ScreenConnect installer, registry command, and QDoor malware.
Once the remote session is established in this way, the VM also contains a copy of QDoor, Rust malware that functions as a C2 proxy, which allows the the threat actors to tunnel C2 traffic through a proxy to the VM, on the infected machine in the target user’s environment. In all cases handled by Rapid7, the QEMU executable was renamed (e.g., w.exe/svvhost.exe), and, as the emulator of the VM, it is the source on the infected host machine for all network connections resulting from processes running inside the VM. QDoor malware has been attributed to the BlackSuit ransomware group by ConnectWise.
In more recent cases, Rapid7 has observed the BlackSuit affiliates distributing a much smaller (64MB vs. 8.6GB) .qcow2 image that contains TinyCore Linux. When the image is loaded by QEMU, the bootlocal[.]sh script that is executed upon startup of the TinyCore OS has been set by the threat actors to sleep unless a successful ping is made to one of their servers. Once the ping is successful, an ELF file, 123.out is executed which attempts to connect to a C2 server.
Figure 18. The contents of `bootlocal[.]sh within the TinyCore VM`
Within the command log of the VM image, .ash_history, a wget command is also present which indicates the external server that the 123.out file was originally downloaded to the VM from.
Figure 19. Part of the `.ash_history` command log within the TinyCore VM.
In an alternate tc.qcow2 payload observed by Rapid7, the TinyCore VM boot script will unconditionally execute two ELF files, nossl and ssl. These ELF payloads function as multi-threaded socks proxies, where the ssl copy uses the OpenSSL library to encrypt traffic and ssl sends traffic in plaintext. In both cases, the ELF payloads send registration information to the C2 proxy server on port 53, which is typically used for DNS.
Figure 20. The ELF `nossl` begins execution by setting the C2 IPv4 address. Debugging symbols were left inside the file, which shows the original variable names.Figure 21. The registration string sent by `nossl` to the C2 proxy server from within the TinyCore VM.
As shown below from the Black Basta chat leaks, BlackSuit has connections with the group, so the adaptation of their typical spear phishing attacks towards these types of social engineering attacks for initial access is unsurprising.
Figure 22. One of Black Basta’s operators (@tinker) discusses their connection to a member of the BlackSuit ransomware group, with Black Basta’s leader (@usernamegg).
Malware Testing
After migrating the Java RAT’s functionality primarily to Google Drive, the threat actor developing the malware also began including the service account they use to test the malware within their own lab environment. The most recent versions of the RAT now also have the command screen which can download and execute a new Java class in memory. The threat actor first tested this in their own lab before trying it in infected devices that they had gained access to, as seen in the command logs below. Despite the name of the command and the name of the Java class that the test payload has (Screenshot), the payloads have varying functionality, but are generally intended to dynamically add new functionality to the RAT. The first test payload observed loads the Java class Screenshot, which then downloads a shellcode blob via a hard coded URL, and injects it into a new java.exe process using the WINAPI calls VirtualAllocEx, WriteProcessMemory, and CreateRemoteThread.
Figure 23. Injection logic implemented by one version of the dynamically loaded Java Screenshot class.
The analyzed test shellcode payload would then perform local PE injection for an embedded Rust PE using NTAPI calls, which for the purposes of the test appears to only spawn a confirmation message box. The Rust PE has an original filename of testapp.exe, a PDB named testapp.pdb, and was originally compiled on 2025-04-10T15:45:28Z. Notably, the Rust PE did have the Windows Graphics Device Interface (GDI) library and several related function imports as dependencies, which could be used to access or manipulate the screen, but did not appear to be fully implemented yet.
Figure 24. Test message box spawned by the Rust executable `testapp.exe`.
The screen command was then successfully used several times in compromised environments, though for different reasons. In one case the operator simply used it as a way to check the external IP address of the infected host. The command log below shows the threat actor testing the screen command for the first recorded time, using the payload with the embedded Rust PE, within their lab, shortly before starting a new spamming/social engineering attack run (during which they would distribute several copies of the malware).
Figure 25. One version of the Java Screenshot class implements functionality to retrieve the infected host’s external IP address and save it to a file named `info.txt`.
Rapid7 observed at least one other Rust malware payload, updater.exe being used by the threat actor, which appeared to be a custom loader for the SSH utility, containing the PDB name rust_serverless_killer.pdb. As many of the compromises facilitated by the social engineering attacks have resulted in SSH reverse tunnels being established to provide access, the loader is likely an attempt to evade detections targeting SSH commands by obscuring the related metadata. The SSH executable being loaded has the same functionality however, and as a result the command line arguments that must be passed remain the same.
The threat actor tested a variety of functionality for the Java RAT within their test lab. This includes the zipped python RAT the group would historically upload, decompress and execute (facilitated by the built in send and extract commands), or distribute instead of the Java RAT. The python RAT has a similar command menu to that of the Java RAT. The python RAT has also been previously analyzed by Gdata with similar findings, who refer to it as Anubis (likely based on the source code) and attribute the malware to the FIN7 group.
Figure 26. The python RAT source labels the decrypted payload as “Anubis”.
InputStart@2025-03-28T13:31:01.430Z: checkconfig InputStart@2025-04-01T15:21:49.251Z: recive c:\programdata\video\log.txt InputStart@2025-04-03T17:01:26.653Z: send C:\Users\Public\Libraries\nature.zip extract C:\Users\Public\Libraries\nature.zip\qwerty dir c:\users\ InputStart@2025-03-28T14:01:17.825Z: checkconfig newconfig InputStart@2025-04-01T13:16:18.589Z: send C:\Users\Public\Libraries\nature.zip startsocks5 C:\Users\Public\Libraries\nature\debug.exe C:\Users\Public\Libraries\nature\test.py
Several commands executed in the threat actor’s test lab can be seen above, where the python based payload was delivered via the Java RAT. In several past incidents handled by Rapid7 the name of initial payload archives containing python malware was Cloud_Email_Switch.zip and the script was named conf.py, where the script was executed via a copy of pythonw.exe that had its metadata stripped. The threat actor appears to have now moved to using the Java RAT primarily instead of the python version, although the Java payload retains the functionality to upload, extract, and execute python scripts.
Command
Function
killexit
Immediately terminates the process.
ip
Creates a UDP socket targeting Google’s DNS server (8.8.8[.]8) and connects to it to retrieve the machine’s local IP address.
‘cd ‘
Change the working directory to one specified by the C2.
‘gt ‘
Steal a specified file or directory. Reads and sends the content straight to the C2. If the target is a directory, the script will archive it into a zip file first.
‘up ‘
Upload a file sent by the C2, to the infected host, to a specified file path.
env
If the C2 specifies a ‘list’ command, the RAT returns all the existing environmental variables. Otherwise returns a specific variable chosen by the C2.
!cf!
Create/update a key (named via hard coded string) in the user’s registry using configuration data sent by the C2. Allows for the malware’s configuration to be dynamically updated.
!tcf!
Test C2 addresses supplied by the current C2 in a new config, by creating a TCP socket to attempt to connect to the new address(es) supplied. Returns the result to current C2. Doesn’t update the config.
default
If one of the above commands is not present, create a child console process (cmd.exe) to execute the contents received from the C2 and return stdout.
Table 2. Command key for the python RAT.
Among the output of the commands the threat actor ran in their test lab, we can also see a listing of their Downloads directory. The output shows that they have likely been developing Rust malware since at least 2024-09-21. The test lab is most likely also the environment in which they compiled testapp.exe as Rust executables contain cargo references which include the user’s name, for example: C:\Users\User\.cargo\registry\src\<truncated>. In contrast, updater.exe, the Rust SSH loader previously mentioned, references the user lucak.
Figure 27. A listing of the Downloads directory on an asset within the malware developer’s test lab.
Finally, while setting up the testing environment, the threat actor made changes to several Google Drive files from what appears to be a personal Gmail account: palomo************[@]gmail[.]com. These changes were visible as numerous versions of the Java RAT were distributed with the threat actor’s test lab Google Drive service account credentials included.
Mitigation Guidance
Rapid7 recommends taking the following precautions to limit exposure to these types of attacks:
Restrict the ability for external users to contact users via Microsoft Teams to the greatest extent possible. This can be done for example by blocking all external domains or creating a white/black list. Microsoft Teams will allow all external requests by default. For more information, see this reference.
Standardize remote management tools within the environment. For unapproved tools, block known hashes and domains to prevent usage. Hash blocking can be done, for example, via Windows AppLocker or an endpoint protection solution.
Provide user awareness training regarding the social engineering campaign. Familiarize users with official help desk and support procedures to enable them to spot and report suspicious requests.
Standardize VPN access. Traffic from known low cost VPN solutions should be blocked at a firewall level if there is no business use case.
Require Multi-Factor Authentication (MFA) across the environment. Single factor authentication facilitates a large number of compromises. For example, If an attacker steals a user’s credentials and acquires the network’s VPN configuration, no MFA on the VPN allows them to easily access the environment.
Regularly update software and firmware. Ransomware groups like Black Basta are known to purchase exploits for initial access.
Rapid7 Customers
InsightIDR, Managed Detection and Response, and Managed Threat Complete customers have existing detection coverage through Rapid7’s expansive library of detection rules. Rapid7 recommends installing the Insight agent on all applicable hosts to ensure visibility into suspicious processes and proper detection coverage. Below is a non-exhaustive list of detections that are deployed and will alert on behavior related to this activity:
Detections
Suspicious Chat Request – Potential Social Engineering Attempt
Initial Access – Potential Social Engineering Session Initiated Following Chat Request
Attacker Technique – Base64 String Added to HKCU Registry Key
Suspicious Process – LNK Executes PowerShell via JAR
Suspicious Process – QEMU Loads Disk From Staging Directory
Credential Access – Steal or Forge Kerberos tickets
Anomaly Detection – Failed AS-REP Roasting Attack
Non-Approved Application – Remote Management and Monitoring (RMM) Tools
Rapid7 has been tracking a malware campaign that uses fake software installers disguised as popular apps like VPN and QQBrowser—to deliver Winos v4.0, a hard-to-detect malware that runs entirely in memory and gives attackers remote access.
The campaign was first spotted during a February 2025 MDR investigation. Since then, we’ve seen more samples using the same infection method—a multi-layered setup we call the Catena loader. Catena uses embedded shellcode and configuration switching logic to stage payloads like Winos v4.0 entirely in memory, evading traditional antivirus tools.
Once installed, it quietly connects to attacker-controlled servers—mostly hosted in Hong Kong—to receive follow-up instructions or additional malware. While we’ve seen no signs of widespread targeting, the operation appears focused on Chinese-speaking environments and shows signs of careful, long-term planning by a capable threat group.
Rapid7 has deployed detections for this activity and continues to monitor for new variants. Indicators and analysis related to this campaign are available in Rapid7 Intelligence Hub.
Introduction
This blog covers a malware campaign tracked by Rapid7 that uses trojanized NSIS installers to deploy Winos v4.0, a stealthy, memory-resident stager. The first sample was flagged during a February 2025 MDR investigation. Following that case, we identified additional related samples through threat hunting and malware analysis.
All observed samples relied on NSIS installers bundled with signed decoy apps, shellcode embedded in `.ini` files, and reflective DLL injection to quietly maintain persistence and avoid detection. We refer to this full infection chain as Catena, due to its modular, chain-like structure.
The campaign has so far been active throughout 2025, showing a consistent infection chain with some tactical adjustments—pointing to a capable and adaptive threat actor.
In this report, we start with a brief recap of the February 2025 MDR incident, which was also covered by other researchers. We then focus on newer samples found later in 2025 that follow the same core infection chain but introduce changes in delivery, tooling, and evasion—highlighting how the campaign continues to evolve.
How it started: QQBrowser Installer in MDR Case
In February 2025, Rapid7’s MDR team detected suspicious activity on a customer asset involving a trojanized NSIS installer masquerading as QQBrowser installer `QQBrowser_Setup_x64.exe`. While the file initially appeared legitimate, further analysis revealed it delivered malware via a multi-stage, memory-resident loader chain. Upon execution, the installer created an Axialis directory under %APPDATA% and dropped several files:
`Axialis.vbs` – a VBScript launcher
`Axialis.ps1` – a PowerShell-based loader `Axialis.dll` – a malicious DLL
`Config.ini` and `Config2.ini` – binary configuration files containing shellcode and embedded payloads
A desktop shortcut and the original QQBrowser setup binary used for deception
Upon execution, the malware follows this chain shown below.
Figure 1: QQBrowser-Based Infection Flow Observed in MDR Case
During runtime analysis, the `Axialis.dll` loader creates the mutex `VJANCAVESU` via the `CreateMutexA` API. If the mutex exists, it loads `Config2.ini`; if not, it loads `Config.ini`.
This behavior has been described by other researchers, who observed similar configuration switching logic in the DeepSeek campaigns — where the selected payload depended on the infection state. Both `.ini` files contain shellcode and embedded payload DLLs, all loaded and executed reflectively in memory.
Rapid7 analysis confirmed that the shellcode in `Config.ini` was built using the open-source sRDI loader.
Figure 2: Side-by-side comparison of shellcode from GitHub (left) and shellcode found in Config.ini (right)
The malware communicates with hardcoded command-and-control (C2) infrastructure over TCP port 18856 and HTTPS port 443.
Persistence is achieved through a combination of process monitoring and scheduled task registration. The embedded DLL in `Config.ini` created and executed `Monitor.bat`, which continuously checked for malware processes and relaunched them if terminated. To ensure persistence, the malware dropped `updated.ps1` and `PolicyManagement.xml`, which are used to register a scheduled task that re-executes the VBS loader `Decision.vbs` via `wscript.exe`.
The scheduled task executed weeks after initial compromise, suggesting long-term persistence. Interestingly, the malware includes a language check that looks for Chinese language settings on the host system. But even if the system isn’t using Chinese, the malware still executes. This suggests the check isn’t actually enforced—it could be a placeholder, an unfinished feature, or something the attackers plan to use in future versions. Either way, its presence hints at an intent to focus on Chinese-language environments, even if that logic isn’t fully implemented yet.
While infrastructure details (e.g., C2 IPs) varied, for example in our case involving 156.251.17.243[:]18852 and the reference blog citing 27.124.40.155[:]18852 — both campaigns used similar communication ports (18852 and 443), suggesting that the activity belongs to the same threat actor.
Campaign evolution
Following the initial discovery, Rapid7 continued tracking the campaign throughout early 2025. During this period, multiple incidents were observed reusing the same infection chain—abusing trojanized NSIS installers, reflective DLL loading, shellcode-embedded INI files, and staged persistence mechanisms. These variants were often disguised as legitimate software such as LetsVPN, Telegram, or Chrome installers.
However, in April 2025, we observed a tactical shift. Threat actors began modifying their approach: for instance, staging scripts like `Axialis.ps1` were dropped entirely, DLLs were invoked directly using `regsvr32.exe`, and new samples showed more efforts to evade antivirus detection. These changes suggest an evolving playbook—one that retains core infrastructure and execution logic but adapts to detection pressure and operational constraints.
Evolving tactics: LetsVPN Installer leading to Winos v4.0
The diagram below illustrates the Catena execution chain as observed in the LetsVPN variant.
Figure 4 Catena Loader: From LetsVPN Installer to Winos v4.0
The following sections break down this chain, stage by stage—from the initial installer and script logic to in-memory payload delivery and infrastructure interaction.
Our analysis started with `Lets.15.0.exe` SHA-256: 1E57AC6AD9A20CFAB1FE8EDD03107E7B63AB45CA555BA6CE68F143568884B003, a trojanized NSIS installer masquerading as a VPN setup. The installer included a decoy executable `Iatsvpn–Latest.exe` and a license file to appear legitimate. However, its true purpose was to deploy multi-stage, memory-resident malware across several directories.
Upon execution, the installer stages components in:
%LOCALAPPDATA%: first-stage loader `insttect.exe` and shellcode blob `Single.ini`
%APPDATA%\TrustAsia: second-stage payloads `Config.ini`, `Config2.ini` and loader DLL `intel.dll`
Figure 5: The extracted file structure by Lets.15.0.exe
The following sections walk through each step of this chain, starting with the NSIS installer and leading to in-memory payload execution.
Installer setup: NSIS script behavior
The `NSIS.nsi` script embedded in `Lets.15.0.exe` sets up both the fake VPN installation and the deployment of malware. It acts as the first step in the execution chain. The script starts by running a PowerShell command that adds Defender exclusions for all drives (C:\ to Z:), reducing system defenses.
First-stage payloads
The NSIS script begins by dropping initial payloads to %LOCALAPPDATA%:
`Single.ini`: a binary blob combining sRDI shellcode and an embedded DLL
`insttect.exe`: loader that reads and executes `Single.ini` in memory
Second-stage payloads
Next, the script drops second-stage files to %APPDATA%\TrustAsia:
`Config.ini`, `Config2.ini`: alternate sRDI payloads loaded later based on mutex logic
`intel.dll`: a secondary loader invoked via regsvr32.exe
To trigger this second stage, the NSIS script executes:
As seen in the February 2025 MDR incident, the NSIS script completes the decoy setup by dropping `IatsvpnLatest.exe`ba0fd15483437a036e7f9dc91a65caa6e9b9494ed3793710257c450a30b88b8a and creating a desktop shortcut pointing to it. Despite the filename containing a typo, the binary is a legitimate LetsVPN executable, signed with a valid digital certificate.
Figure 6: Malicious NSIS script
The following sections outline the role of each dropped binary in the execution chain.
Stage 1: Execution of insttect.exe and Single.ini file
We analyzed `insttect.exe`, a trojanized loader masquerading as a legitimate Tencent PC Manager installer. The binary, titled 腾讯电脑管家在线安装程序 (machine translation: “Tencent PC Manager Online Installation Program” (in both metadata and resource strings).
The binary is signed with an expired certificate issued by VeriSign Class 3 Code Signing CA (2010) and allegedly belongs to Tencent Technology (Shenzhen), valid from 2018-10-11 to 2020-02-02.
The binary includes deceptive artifacts such as localized UI strings in Chinese, internal references to Tencent development paths, and hardcoded XML updater config pointing to `QQPCDownload.dll`
Figure 7: Hardcoded PDB path from `insttect.exe`
These elements reinforce the loader’s appearance as legitimate software.
Upon execution, `insttect.exe` locates `%LOCALAPPDATA%\Single.ini`, allocates memory with PAGE_EXECUTE_READWRITE permissions, copies the file into that region, and transfers control to its start. As previously described, the payload uses the sRDI format—enabling the embedded shellcode to self-parse and reflectively load the DLL without separate extraction.
Windows API calls related to shellcode loading are resolved dynamically via hashed function names.
Figure 8: Hashed API Resolution Routine
The DLL embedded within `Single.ini` takes a snapshot of running processes and continuously checks for `360tray.exe` and `360safe.exe`. These are components of 360 Total Security, a popular antivirus product developed by Chinese vendor Qihoo 360.
However, when tested with a dummy `360tray.exe`, the malware showed no response—neither terminating the process nor altering its own behavior.
Stage 2: Execution of intel.dll and Config.ini files
The `.nsi script` drops `intel.dll`, `Config.ini`, and `Config2.ini` into %APPDATA%\TrustAsia, and uses nsExec::Exec to invoke intel.dll via a regsvr32 call.
Both `Config.ini` and `Config2.ini` initially appeared benign due to their generic names. However, as with earlier payloads, both `.ini` are binary blobs containing shellcode formatted using the Shellcode Reflective DLL Injection (sRDI) technique described earlier.
As noted in the QQBrowser case, earlier variants loaded the shellcode from disk using PowerShell scripts. In this version, execution is handled entirely in memory via `regsvr32.exe`, which invokes `intel.dll`. As is typical for DLLs executed this way, `intel.dll` exports the `DllRegisterServer` function, which is automatically called.
While this shift avoids PowerShell, it’s not necessarily more evasive, since `regsvr32.exe` is a well-known LOLBin and is commonly monitored by modern EDR solutions. Upon execution, `intel.dll` loader creates a hardcoded mutex `99907F23-25AB-22C5-057C-5C1D92466C65` using the `CreateMutexA` API, and checks for the presence of two indicators: the mutex itself, and a file named `Temp.aps` in %APPDATA%\TrustAsia. If both are found, `Config2.ini` is loaded; otherwise, the default `Config.ini` is used.
Figure 9: Handle to Config.ini being returned
Once the appropriate `.ini` file is chosen, the loader opens it using `CreateFileW` and loads its contents into memory. As seen in earlier stages, the `.ini` file contains a shellcode blob using the sRDI format, which self-parses and reflectively loads an embedded DLL.
The in-memory DLL, extracted and executed entirely from within the shellcode blob, exports a single function named `VFPower`, a naming convention consistent across all observed samples. Debug symbols embedded in the DLL reference a Chinese development path E:\冲锋\进行中\Code_Shellcode – 裸体上线用作注入\Release\Code_Shellcode.pdb (machine translation: E:\Charge\In Progress\Code_Shellcode – Naked online for injection \ Release \ Code _ Shellcode.pdb).
During runtime, this in-memory DLL creates a hardcoded mutex `zhuxianlu` (machine translation: main line) and verifies if it was launched from `UserAccountBroker.exe`. If true, it immediately initiates C2 communication, likely assuming it was started with elevated privileges. Otherwise, the malware continues execution by spawning five threads, each responsible for a specific task before ultimately reaching the same C2 routine.
Figure 10: Mutex Check and C2 Trigger Logic
The five threads carry out the following actions:
Thread 1 launches PowerShell via `ShellExecuteExA` to add a Microsoft Defender exclusion for the C:\ drive.
Thread 2 attempts to establish persistence via scheduled task registration as seen in the earlier QQBrowser incident described in the introduction. It generates two files:
`PolicyManagement.xml` — an XML file defining a scheduled task
`updated.ps1` — a PowerShell script that imports and registers the task
To ensure the script runs without restriction the malware first sets PowerShell policies to `Unrestricted` (for the current user) and `Bypass` (for the specific script). The scheduled task is configured to invoke `regsvr32.exe` at logon, which in turn re-executes either `intel.dll` or `insttect.exe` loader.
Although this operation failed during our analysis even with the Chinese language pack installed, it was attempted twice—we believe to ensure redundancy or persistence across both loaders. Both files `PolicyManagement.xml` and `updated.ps1` are deleted immediately after execution.
Thread 3 takes a snapshot of all running processes and scans for any instance of `Telegram.exe`, `telegram.exe`, or `WhatsApp.exe`. If any of these are detected, it creates an empty marker file named `Temp.aps` in %APPDATA%\TrustAsia, and then executes:
This triggers the second-stage loader. The presence of the `Temp.aps`alters the loader’s behavior, causing it to run `Config2.ini` instead of `Config.ini`.
Thread 4 checks for the existence of the file `TrustAsia\Exit.aps`. If found, the file is deleted and the malware terminates.
Thread 5 acts as a persistence watchdog for the second-stage loader. It creates two files: `target.pid`, which stores the process ID of the running regsvr32.exe instance executing `intel.dll` loader, and `monitor.bat`, a batch script that checks whether this process is still running. If not, the script attempts to relaunch it. This check runs every 15 seconds to ensure `intel.dll` remains continuously active.
Figure 11: Content of monitor.bat watchdog
Following thread execution, the final function is responsible for C2 communication. Since the earliest observed sample from February 2024, the malware has used Windows sockets and the `getaddrinfo` API to resolve a hardcoded IP and port 18852 which also seems to be consistent across all analyzed samples of `Config.ini`.
Once the connection is established, malware retrieves the next-stage payload from the C2 server, allocates a new memory region with PAGE_EXECUTE_READWRITE permissions, copies the downloaded content into memory, and transfers execution to it. This is the delivery of the final stage, observed as Winos v4.0 in recent samples.
Figure 12: Jump to final payload
Final payload Winos4.0
The `intel.dll` loader selects either `Config.ini` or `Config2.ini` based on runtime conditions, such as the presence of a mutex `VJANCAVESU` and a `Temp.aps`marker file. Each of these `.ini` files contains sRDI shellcode that connects to a different C2 server to download the next-stage payload which was Winos4.0 in our case.
In recent samples, the payloads were downloaded from:
`Config.ini` → 134.122.204[.]11:18852
`Config2.ini` → 103.46.185[.]44:443
Although being retrieved from different C2 servers, both payloads were nearly identical: 112 KB in size and structured as sRDI shellcode containing an embedded DLL. This DLL uses the same reflective loading technique seen in previous stages, exports a single-function `VFPower` and and includes debug metadata referencing a Chinese development path:
Based on available evidence supported by debug info, we can say this is Winos4.0 stager `上线模块.dll`( machine translation: `Online Module.dll`.)
Extracted configuration
The Winos v4.0 stager downloaded from 134.122.204[.]11:18852 contains an embedded configuration block. The data appears to control runtime behavior, C2 communication, and implant settings. A decoded sample is shown below:
Extracted Configuration from Payload (134.122.204[.]11:18852)
Configuration
Data
Description
p1
134.122.204[.]11
First CC IP address
o1
6074
First port
t1
1
Protocol (TCP)
p2
134.122.204[.]11
Second CC IP address
o2
6075
Second option port
t2
1
Protocol (TCP)
p3
134.122.204[.]11
Third CC IP address
o3
6076
Third option port
t3
1
Protocol (TCP)
dd
1
Implant execution delay in seconds
cl
1
Beaconing interval in seconds
fz
认默 (default)
Grouping
bb
1.0
Version
bz
2025.4.24
Generation date
jp
0
Keylogger
bh
0
End bluescreen
ll
0
Antitraffic monitoring
dl
0
Entry point
sh
0
Process daemon
kl
0
Process hollowing
bd
0
N/A
In previous incidents, Winos 4.0 has been linked to the Silver Fox APT group operation known for distributing malware like ValleyRAT via trojanized utilities and vulnerability exploitation. Notably, similar TTPs were observed in the CleverSoar campaign described by Rapid7 in November 2024 which also delivered Winos4.0 and checked system locale settings for Chinese or Vietnamese—suggesting targeting based on regional language.
Infrastructure
During our investigation, the hardcoded IP address 103.46.185[.]44 found in `Config.ini` was confirmed to host the final Winos 4.0 payload. Shodan scans showed it serving a binary blob that begins with recognizable sRDI shellcode and contains an embedded DLL identical to the Winos 4.0 stager (“Online Module”) analyzed in this report.
Pivoting on this sample using Shodan hash -646083836, we identified eight additional IPs distributing the exact same payload: 112.213.101[.]161, 112.213.101[.]139, 103.46.185[.]73, 47.83.184[.]193, 202.79.173[.]50, 202.79.173[.]54, 202.79.173[.]98, and 103.46.185[.]44.
Each host returned identical byte sequences, indicating a shared and coordinated infrastructure distributing the same stage-one loader across multiple nodes, mostly hosted in Hong Kong.
Figure 13: Shared Hosting of Identical Winos v4.0 Payloads
To expand this infrastructure mapping, we extracted additional C2 addresses from historic MDR case data and active threat hunting leads. These included:
Pivoting on these nodes using Shodan hash correlations revealed additional infrastructure often resolving to the same ASNs or hosting providers, such as
CTG Server Ltd. / MEGA-II IDC (AS152194) OK COMMUNICATION / LANDUPS LIMITED (AS150452) Alibaba Cloud (AS45102) Tcloudnet, Inc. (AS399077)
Conclusion
This campaign shows a well-organized, regionally focused malware operation using trojanized NSIS installers to quietly drop the Winos v4.0 stager. It leans heavily on memory-resident payloads, reflective DLL loading, and decoy software signed with legit certificates to avoid raising alarms.
The malware’s logic—using mutexes to choose payloads, hiding shellcode in INI files, and layering persistence tricks like scheduled tasks and watchdog scripts—points to an actor that’s refining, not reinventing, their playbook. Infrastructure overlaps and language-based targeting hint at ties to Silver Fox APT, with activity likely aimed at Chinese-speaking environments. Rapid7 continues to track this threat and has detections in place to help protect customers.
InsightIDR and Managed Detection and Response customers have existing detection coverage through Rapid7’s expansive library of detection rules. Below is a non-exhaustive list of detections that are deployed and will alert on behavior related to Catena. We will also continue to iterate detections as new variants emerge, giving customers continuous protection without manual tuning:
As AI coding assistants invent nonexistent software libraries to download and use, enterprising attackers create and upload libraries with those names—laced with malware, of course.
EDITED TO ADD (1/22): Research paper. Slashdot thread.
There is a new botnet that is infecting TP-Link routers:
The botnet can lead to command injection which then makes remote code execution (RCE) possible so that the malware can spread itself across the internet automatically. This high severity security flaw (tracked as CVE-2023-1389) has also been used to spread other malware families as far back as April 2023 when it was used in the Mirai botnet malware attacks. The flaw also linked to the Condi and AndroxGh0st malware attacks.
[…]
Of the thousands of infected devices, the majority of them are concentrated in Brazil, Poland, the United Kingdom, Bulgaria and Turkey; with the botnet targeting manufacturing, medical/healthcare, services and technology organizations in the United States, Australia, China and Mexico.
Creating four backdoors facilitates the attackers having multiple points of re-entry should one be detected and removed. A unique case we haven’t seen before. Which introduces another type of attack made possibly by abusing websites that don’t monitor 3rd party dependencies in the browser of their users.
Here’s a supply-chain attack just waiting to happen. A group of researchers searched for, and then registered, abandoned Amazon S3 buckets for about $400. These buckets contained software libraries that are still used. Presumably the projects don’t realize that they have been abandoned, and still ping them for patches, updates, and etc.
The TL;DR is that this time, we ended up discovering ~150 Amazon S3 buckets that had previously been used across commercial and open source software products, governments, and infrastructure deployment/update pipelines—and then abandoned.
Naturally, we registered them, just to see what would happen—”how many people are really trying to request software updates from S3 buckets that appear to have been abandoned months or even years ago?”, we naively thought to ourselves.
Turns out they got eight million requests over two months.
Had this been an actual attack, they would have modified the code in those buckets to contain malware and watch as it was incorporated in different software builds around the internet. This is basically the SolarWinds attack, but much more extensive.
But there’s a second dimension to this attack. Because these update buckets are abandoned, the developers who are using them also no longer have the power to patch them automatically to protect them. The mechanism they would use to do so is now in the hands of adversaries. Moreover, often—but not always—losing the bucket that they’d use for it also removes the original vendor’s ability to identify the vulnerable software in the first place. That hampers their ability to communicate with vulnerable installations.
Software supply-chain security is an absolute mess. And it’s not going to be easy, or cheap, to fix. Which means that it won’t be. Which is an even worse mess.
Kaspersky is reporting on a new type of smartphone malware.
The malware in question uses optical character recognition (OCR) to review a device’s photo library, seeking screenshots of recovery phrases for crypto wallets. Based on their assessment, infected Google Play apps have been downloaded more than 242,000 times. Kaspersky says: “This is the first known case of an app infected with OCR spyware being found in Apple’s official app marketplace.”
There are thousands of fake Reddit and WeTransfer webpages that are pushing malware. They exploit people who are using search engines to search sites like Reddit.
Unsuspecting victims clicking on the link are taken to a fake WeTransfer site that mimicks the interface of the popular file-sharing service. The ‘Download’ button leads to the Lumma Stealer payload hosted on “weighcobbweo[.]top.”
A newly discovered VPN backdoor uses some interesting tactics to avoid detection:
When threat actors use backdoor malware to gain access to a network, they want to make sure all their hard work can’t be leveraged by competing groups or detected by defenders. One countermeasure is to equip the backdoor with a passive agent that remains dormant until it receives what’s known in the business as a “magic packet.” On Thursday, researchers revealed that a never-before-seen backdoor that quietly took hold of dozens of enterprise VPNs running Juniper Network’s Junos OS has been doing just that.
J-Magic, the tracking name for the backdoor, goes one step further to prevent unauthorized access. After receiving a magic packet hidden in the normal flow of TCP traffic, it relays a challenge to the device that sent it. The challenge comes in the form of a string of text that’s encrypted using the public portion of an RSA key. The initiating party must then respond with the corresponding plaintext, proving it has access to the secret key.
The lightweight backdoor is also notable because it resided only in memory, a trait that makes detection harder for defenders. The combination prompted researchers at Lumin Technology’s Black Lotus Lab to sit up and take notice.
[…]
The researchers found J-Magic on VirusTotal and determined that it had run inside the networks of 36 organizations. They still don’t know how the backdoor got installed.
According to a DOJ press release, the FBI was able to delete the Chinese-used PlugX malware from “approximately 4,258 U.S.-based computers and networks.”
To retrieve information from and send commands to the hacked machines, the malware connects to a command-and-control server that is operated by the hacking group. According to the FBI, at least 45,000 IP addresses in the US had back-and-forths with the command-and-control server since September 2023.
It was that very server that allowed the FBI to finally kill this pesky bit of malicious software. First, they tapped the know-how of French intelligence agencies, which had recently discovered a technique for getting PlugX to self-destruct. Then, the FBI gained access to the hackers’ command-and-control server and used it to request all the IP addresses of machines that were actively infected by PlugX. Then it sent a command via the server that causes PlugX to delete itself from its victims’ computers.
Many thanks to Rapid7 MDR and incident response teams for their contributions to this analysis.
While investigating incidents related to Cleo software exploitation, Rapid7 Labs and MDR observed a novel, multi-stage attack that deploys an encoded Java Archive (JAR) payload. Our investigation revealed that the JAR file was part of a modular, Java-based Remote Access Trojan (RAT) system. This RAT facilitated system reconnaissance, file exfiltration, command execution, and encrypted communication with the attacker’s command-and-control (C2) server. Its modular architecture includes components for dynamic decryption, network management, and staged data transfer.
It’s worthwhile to note that this isn’t necessarily the only payload that has or will be deployed in attacks targeting Cleo software — it’s entirely possible an alternate payload could be leveraged. This underscores the importance of timely detection and response capabilities, as well as the critical role of monitoring assets that may be impacted by unknown zero-day threats.
At a high level, the attack flow can be visualized like so:
As Huntress pointed out in their blog on this threat campaign, part of the attack chain involves uploading and executing an XML file as part of a ZIP. When analyzing the XML file that contains the PowerShell code, we looked at the code to understand how the code would trigger in line with the known CVE (CVE-2024-50623) and the new CVE (still pending) for the unauthenticated malicious hosts vulnerability in Cleo software.
The XML snippet appears to define a “Host” and “Mailbox” configuration in Cleo Integration Suite (e.g., Harmony, VLTrader, or LexiCom). Cleo software often uses XML-based configuration files for trading partner setups, hosts, mailboxes, and scheduled actions or commands. Each <Host> element represents a communication endpoint, and each <Mailbox> often represents a sub-endpoint or logical folder.
The <Action> elements define which tasks (commands, scripts, or transfers) should be performed. Looking at the code of our XML, we observed a suspicious element.
Under <Mailbox> there is an <Action> element with actiontype=”Commands”. Inside this action, there’s a <Commands> tag that runs:
SYSTEM cmd.exe /c "powershell -NonInteractive -EncodedCommand <base64_data>" > webserver/temp/webserver-<GUID>.swp
The <Commands> directive is invoking cmd.exe which runs PowerShell with an encoded command. The command is outputting to a .swp file, possibly to hide or store results locally.
By embedding this script within the <Action> element of the XML, if the CLEO system imports this configuration and executes the defined action by combining the vulnerability mentioned in CVE-2024-50623, the malicious code will run on the server. This could completely compromise the system running CLEO, given that CLEO often runs with significant privileges and access to internal systems and file shares.
Analyzing the malicious PowerShell script content
The script in question was originally invoked as remote code execution (RCE) during suspected CVE-2024-50623 exploitation:
This is a common technique used by attackers to obfuscate their malicious code. Decoding the Base64 string reveals a PowerShell snippet that:
Establishes a TCP connection to a suspicious external host (185.181.230.103) on port 443. (See additional external host indicators in the IOCs section.)
Retrieves and decrypts data from the remote server using a custom XOR-based routine.
Writes the decrypted output as a JAR file named cleo.2853.
Executes the malicious JAR using the embedded Java runtime of Cleo LexiCom (jre\bin\java.exe -jar cleo.2853).
Step-by-step analysis
Network connection setup The script begins by creating a Net.Sockets.TcpClient object and connecting it to the remote server:
A StreamWriter $w is then created, allowing the script to send initial data to the server. The malware sends the “TLS v3 <string.>” and processes the response. This serves as a form of handshake or protocol initialization.
2. XOR decryption setup Before reading any payload from the server, the script sets up key variables for decrypting data:
It continuously reads data from the remote server into $a.
For each byte, it calculates an index $j into $k (cycling through the key bytes).
It XORs the received byte with $k[$j] and a running state variable $g.
$g and $k[$j] evolve dynamically, meaning the key changes with every byte processed, making static detection harder.
Decrypted bytes are then written directly into the file cleo.2853.
The number behind the “cleo.*” differs in the cases we observed. By the end of this loop, the attacker’s encrypted payload is stored locally as a decrypted file.
4. Final steps: Executing the malicious JAR After fetching and decrypting the data, the script closes all streams and sets some environment variables:
The $env:QUERY variable appears to include additional IP addresses and contains the AES key used to decrypt the next stage and the string to send to the C2 server to receive the next payload. Finally, the script runs the malicious JAR file:
This leverages the Cleo environment’s embedded Java runtime. Since Cleo’s file transfer products come bundled with their own Java environment, the attackers don’t need to rely on a system-wide installation — they can simply run their malicious JAR directly. In one of our IR cases, the “cleo.xxxx” file was written to the C:\VLTrader\ directory.
Inside the JAR file The core functionality revolves around a custom class loader named “start”.
Instead of loading classes from the file system, this loader accepts a byte array representing a compressed archive of class files. It then extracts each entry and stores them in a map, ready to be defined as Java classes on demand.
What does this custom class loader do?
Extracts classes from a byte array: The constructor of the start class takes a byte array (like a JAR) and reads the class using a ZipInputStream. Each entry is unpacked and stored in a map keyed by the entry name. For example:
ZipInputStream zis = new ZipInputStream(new ByteArrayInputStream(byteArray));
ZipEntry entry;
while ((entry = zis.getNextEntry()) != null) {
ByteArrayOutputStream bos = new ByteArrayOutputStream();
int read;
while ((read = zis.read(buffer)) > 0) {
bos.write(buffer, 0, read);
}
cs.put(entry.getName(), bos.toByteArray());
}
Defining Classes at Runtime: Later, when a class is requested, the findClass method checks the map. If found, it uses defineClass to load that class directly from the in-memory bytes:
if (cs.containsKey(className)) {
byte[] classData = (byte[]) cs.get(className);
return defineClass(className, classData, 0, classData.length);
2. Fetches and decrypts class data remotely. The main method doesn’t just run local code — it also does the following:
Reads configuration and keys from environment variables.
Connects to a remote host over port 443 and sends a “TLS v3” handshake-like message.
Receives encrypted data, which it then decrypts using AES keys derived from the environment-provided values.
Once decrypted, this data is treated like a JAR file, passed into a new start instance, and thus new classes are loaded at runtime.
3. Executes a specific class (Cli): With the new classes loaded, the code uses reflection to instantiate a particular class named “Cli” and invoke its constructor.
This mechanism allows the JAR to remain small and stealthy, as it doesn’t contain all its logic up front. Instead, it fetches critical code at runtime, decrypts it, and executes it dynamically. But it didn’t stop here — after executing this first JAR file, which acts as a loader, it downloads a zip file that contains multiple JAR files:
File name
MD5
Cli
fa0ffca3597af31fc196ca27283aa038
Dwn
510a7fa9d425f1c3a38ad81d813b3f17
DwnLevel
7dcaffc9c26fe9e08e9b66e05c644cfc
Mos
ee7acd7a8a5795308942f094c950de6f
Proc
37a761f4d02577cf6789676f87cb9fc6
ScSlot
6ff85e7bec211869073b969dbd10c8eb
SFile
ca3de6f055f94acc87c6d335d9cc5c04
Slot
d924ffd1f2952a03da29c0a7a33e6a54
SrvSlot
bcc1bf75e0be3efabbd616cc8cfa8c35
Overall this is how the modules work together and what their function is:
The Cli class appears to be a key component of a remote backdoor mechanism. On startup, it determines the operating system and sets flags accordingly before attempting to connect to a remote host over port 443 using Java’s non-blocking I/O. Once connected, it can manage data streams via asynchronous event loops, handle received data, and potentially issue commands. After initialization, the code instructs the system to delete its own initial file to remove evidence of its presence.
In Rapid7 MDR investigations into exploitation of Cleo software, we observed commands being executed that we would categorize as reconnaissance attempts.
The DWN class appears to facilitate the packaging and transmission of files from the local system to a remote server. It assembles files (and directories) into a ZIP archive on the fly, splitting them into multiple ZIP chunks if they exceed a certain size threshold. Using a SrvSlot reference, it sends compressed file data over a network channel, carefully managing buffers and limiting throughput to avoid overwhelming the connection. The code iterates through directories, queues files, and processes them incrementally, updating statistics and retrying if conditions are not ideal. Through this mechanism, this class effectively automates and streamlines the mass transfer of local files, hinting at a data exfiltration or remote backup process. It’s designed to run quietly in the background, handle large file sets, and provide periodic progress updates to its server counterpart.
The DwnLevel class is a simple helper structure that represents a single level in a file traversal hierarchy. It holds an array of file objects, along with an index and a state variable to track the current processing position. As the Dwn class iterates through directories, the DwnLevel Java class instance keeps track of which files have been processed and which remain, helping the file packaging and transfer process proceed smoothly through potentially nested directories.
The Mos class acts as a custom output stream for sending ZIP data through Dwn. Instead of writing to disk, it buffers data in memory, attaches metadata like the job ID and packet offsets, and then hands the chunks off to Dwn to send out. This setup allows code that writes ZIP entries to operate as if it were writing to a normal output stream, while the Mos and Dwn classes handle the network transmission details behind the scenes.
Proc is a thread that runs external commands on the system, captures their output, and sends it back through SrvSlot. It can launch interactive shells, parse configuration files, and handle input given before the process starts.
In the code of this class, we also can discover that it is cross platform designed, either executing a cmd (Windows) or bash (*nix) shell:
ScSlot manages a network connection for a specific channel. It handles connecting, reading data, and relaying it to the SrvSlot class. If the connection fails or no data is received, it signals the server to close the channel. Its tick method processes incoming data in chunks to ensure smooth communication.
The SFile class handles file reading and writing operations. It can both read from an existing file or write to a new file, depending on the flags provided. The class tracks the file size, saved size and handles errors by setting status messages.
The Slot class manages the network connection using the Java network IO class. It handles connecting, reading, and writing, ensuring a smooth data transfer.
Last but not least, since it is a core component of this Java RAT, is the SrvSlot class. It interacts with other classes as described before and is the central node for handling encrypted communications and data transfer — it handles the ZIP transfer traffic. Besides traffic handling, a small component in the code of this class appears to be for debugging purposes (i.e., providing diagnostics and session statistics).
Overall this set of Java classes provide a modular multi-stage system (Java-RAT) designed to communicate with a C2, has file-transfer and management functionality, can execute commands and applies packet level encryption/decryption.
In multiple attack chains, after initial exploitation, the adversary executed the following enumeration commands via cmd to gather user, group and system information from the impacted system and display domain trust relationships.
systeminfo
net group /domain
whoami
wmic logicaldisk get name,size
nltest /domain_trusts
Rapid7 also observed post-exploitation activity in the form of an "OverPass-The-Hash" attack, in which the adversary leverages the NTLM hash of an account to obtain a Kerberos ticket that can be used to access additional network resources within the impacted environment.
MITRE ATT&CK Enterprise Techniques
Initial access
Exploit Public-Facing Application (T1190)
Execution
Command and Scripting Interpreter (T1059)
Discovery
System Owner/User Discovery (T1033)
System Information Discovery (T1082)
Domain Trust Discovery (T1482)
Permission Groups Discovery (T1069)
Lateral movement
Use Alternate Authentication Material: Pass the Hash (T1550/002)
The company’s Mobile Threat Hunting feature uses a combination of malware signature-based detection, heuristics, and machine learning to look for anomalies in iOS and Android device activity or telltale signs of spyware infection. For paying iVerify customers, the tool regularly checks devices for potential compromise. But the company also offers a free version of the feature for anyone who downloads the iVerify Basics app for $1. These users can walk through steps to generate and send a special diagnostic utility file to iVerify and receive analysis within hours. Free users can use the tool once a month. iVerify’s infrastructure is built to be privacy-preserving, but to run the Mobile Threat Hunting feature, users must enter an email address so the company has a way to contact them if a scan turns up spyware—as it did in the seven recent Pegasus discoveries.
Beginning in early October, Rapid7 has observed a resurgence of activity related to the ongoing social engineering campaign being conducted by Black Basta ransomware operators. Rapid7 initially reported the discovery of the novel social engineering campaign back in May, 2024, followed by an update in August 2024, when the operators updated their tactics and malware payloads and began sending lures via Microsoft Teams. Now, the procedures followed by the threat actors in the early stages of the social engineering attacks have been refined again, with new malware payloads, improved delivery, and increased defense evasion.
Overview
The social engineering attacks are still initiated in a similar manner. Users within the target environment will be email bombed by the threat actor, which is often achieved by signing up the user’s email to numerous mailing lists simultaneously. After the email bomb, the threat actor will reach out to the impacted users. Rapid7 has observed the initial contact still occurs primarily through usage of Microsoft Teams, by which the threat actor, as an external user, will attempt to call or message the impacted user to offer assistance. The account domains in use include both Azure/Entra tenant subdomains (e.g., username[@]tenantsubdomain[.]onmicrosoft[.]com) and custom domains (e.g., username[@]cofincafe[.]com).
In many cases, Rapid7 has observed that the threat actor will pretend to be a member of the target organization’s help desk, support team, or otherwise present themself as IT staff. Below are examples of Microsoft Teams display names observed, by Rapid7, to be in use by operators. The display names may or may not be padded with whitespace characters. Rapid7 has also observed threat actors use a first and last name, as the chat display name and/or account username, to impersonate an IT staff member within the targeted organization.
Operator Chat Display Name
Help Desk
HELP DESK
Help Desk Manager
Technical Support
Administracion
If the user interacts with the lure, either by answering the call or messaging back, the threat actor will attempt to get the user to install or execute a remote management (RMM) tool, including, but not limited to, QuickAssist, AnyDesk, TeamViewer, Level, or ScreenConnect. Rapid7 has also observed attempts to leverage the OpenSSH client, a native Windows utility, to establish a reverse shell. In at least one instance, the threat actor shared a QR code with the targeted user. The purpose of the QR code is unconfirmed but appears to be an attempt to bypass MFA after stealing a user’s credentials. The URL embedded within the QR code adheres to the following format: hxxps://<company_name>[.]qr-<letter><number>[.]com.
Figure 1. A QR code (obfuscation by Rapid7) sent by an operator.
In a majority of cases, Rapid7 has observed that the operator, after gaining access to the user’s asset via RMM tool, will then attempt to download and execute additional malware payloads. In one case handled by Rapid7, the operator requested more time — potentially to hand off the access to another member of the group.
Figure 2. An operator stalls for time.
The payload delivery methods vary per case, but have included external compromised SharePoint instances, common file sharing websites, servers rented through hosting providers, or even direct upload to the compromised asset in the case of RMM tool remote control. In one case, the operator used the group’s custom credential harvester to dump the user’s credentials, the results for which were subsequently uploaded to a file sharing site — publicly exposing the stolen credentials. SharePoint has been used to distribute copies of AnyDesk portable, likely to circumvent security measures that would prevent the user from downloading it directly from anydesk[.]com. Such attempts have been blocked by web proxy in previous cases.
The overall goal following initial access appears to be the same: to quickly enumerate the environment and dump the user’s credentials. When possible, operators will also still attempt to steal any available VPN configuration files. With the user’s credentials, organization VPN information, and potential MFA bypass, it may be possible for them to authenticate directly to the target environment.
Rapid7 has observed usage of the same credential harvesting executable, previously reported as AntiSpam.exe, though it is now delivered in the form of a DLL and most commonly executed via rundll32.exe. Whereas before it was an unobfuscated .NET executable, the program is now commonly contained within a compiled 64-bit DLL loader. Rapid7 has analyzed at least one sample that has also been obfuscated using the group’s custom packer. The newest versions of the credential harvester now save output to the file 123.txt in the user’s %TEMP% directory, an update from the previous qwertyuio.txt file, though versions of the DLL distributed earlier in the campaign would still output to the previous file.
Figure 3. The credential harvesting prompt shown to the user upon executing the DLL (redaction by Rapid7).
The credential harvester is most commonly followed by the execution of a loader such as Zbot (a.k.a. Zloader) or DarkGate. This can then serve as a gateway to the execution of subsequent payloads in memory, facilitate data theft, or otherwise perform malicious actions. Rapid7 has also observed operators distributing alternate payload archives containing Cobalt Strike beacon loaders and a pair of Java payloads containing a user credential harvester variant and a custom multi-threaded beacon by which to remotely execute PowerShell commands. In some cases, operators have sent the user a short command, via Teams, which will then begin an infection chain after execution by the targeted user.
Rapid7 continues to observe inconsistent usage of the group’s custom packer to deliver various malware payloads, including their custom credential harvester. A YARA rule is now publicly available that can be used to detect the packer. For example, this packer was used to deliver several obfuscated versions of Black Basta ransomware, obtained via open source intelligence, which directly links operators to the ongoing social engineering campaign.
At the time of writing, the threat actors behind the campaign continue to update both their strategy for gaining initial access and the tools subsequently used. For example, around the time the most recent campaign activity began, Rapid7 observed the delivery of a timestamped and versioned payload archive, 171024_V1US.zip (2024-10-17, version 1, US), which, when compared to a more recently delivered archive, 171124_V15.zip (2024-11-17, version 15), highlights the rapid iteration being undertaken. Many of the payloads being delivered follow a similar pattern as previous activity and often consist of a legitimate file where an export or function entry point has been overwritten to jump to malicious code, and the result is signed with a likely stolen code signing certificate.
Intrusions related to the campaign should be taken seriously — the intent goes beyond typical phishing activity. Past campaign activity has led to the deployment of Black Basta ransomware. While Rapid7 has handled a high volume of incidents related to the current social engineering campaign across a variety of customer environments, to date, every case has been contained before the operator was able to move laterally beyond the targeted user’s asset.
Technical Analysis
Initial Access
Each attack is preceded by the targeted user receiving an often overwhelming amount of emails. An operator will then attempt to contact the user via Microsoft Teams, either via messaging or calling, by which they will pretend to offer assistance. Operators will attempt to impersonate the organization’s help desk, such as using the names of existing staff members.
During this social engineering stage, operators often need to troubleshoot with the user to establish remote control of the user’s asset. Based on the environment, for example, RMM tool downloads or execution may be blocked (often some, but not all) or QuickAssist may be disabled, causing the operator to cycle through their options at establishing a foothold. One of the most common first steps after gaining either the confidence of the user, or remote access, is to execute a custom credential harvester.
Credential Harvesting
The credential harvester used by operators, for example SafeStore.dll (SHA256: 3B7E06F1CCAA207DC331AFD6F91E284FEC4B826C3C427DFFD0432FDC48D55176), is an updated version of the previously analyzed program AntiSpam.exe. The DLL variant of the credential harvester is executed by a command like the following example:
rundll32.exe SafeStore.dll,epaas_request_clone
The module will quickly execute three enumeration commands to gather system information — systeminfo, route print, ipconfig /all — and then prompt the user for their password. The user’s credentials are appended onto a new line of the text file 123.txt with each attempt, after the enumeration command output, regardless of whether the credentials are correct. If the user enters the wrong password, they will be prompted to try again. The output for the enumeration commands and the user’s credentials were saved to the file qwertyuio.txt in older versions of the harvester, but are now saved to 123.txt, within the user’s %TEMP% directory. The enumeration commands within the updated version are executed via successive calls to CreateProcessA.
Figure 4. Success and failure messages for the credential harvester.
Based on analysis of one credential harvester sample, EventCloud.dll, the program was present in shellcode form. The shellcode is decrypted from the Cursor Group 880 resource embedded within the executable, using the XOR key 5A 3C 77 6E 33 30 4D 38 4F 38 40 78 41 58 51 30 42 5F 3F 67 71 00, and then injected locally. The following strings which were extracted from the shellcode show the output file and list dynamically loaded libraries:
Credential Harvester Strings
–
–
–
–
cmd.exe /c
%s%s
%s%s%s%s
123.txt
ooki
Update
filter kb_outl
Need credentials to update…
Username:
Password:
ntdll.dll
Gdi32.dll
user32.dll
msvcrt.dll
ucrtbase.dll
Comctl32.dll
Advapi32.dll
kernel32.dll
–
–
The Java variant of the credential harvester, identity.jar, provides a similar prompt to the user, though when a password is entered it is appended, without the username, to a .txt file with a random 10-letter alphabetic name to the current working directory. The cancel button on the prompt, shown below, is not functional and the prompt is drawn on top of other windows, meaning that it will not close until the user has entered their password correctly.
Figure 5. The credential harvesting prompt created by `identity.jar`.
Malware Payloads
Following execution of a credential harvester, an operator will typically infect the asset with Zbot or DarkGate. One of the Zbot samples delivered after initial access, SyncSuite.exe (SHA256: DB34E255AA4D9F4E54461571469B9DD53E49FEED3D238B6CFB49082DE0AFB1E4) contains similar functionality and strings to other Zbot/Zloader samples previously reported by ZScaler. However, in addition to previously observed strings, the sample also contains encrypted strings for an embedded command help menu, error messages, and more. Rapid7 observed the embedded malware version was 2.9.4.0.
Upon execution, the malware will copy itself to a random folder within the %APPDATA% directory. If the file does not have its original filename however, the process will immediately exit. The malware also contains the functionality to establish persistence either via a Run key at HKCU\Software\Microsoft\Windows\CurrentVersion\Run or a scheduled task named after the executable, which executes the malware copy in %APPDATA% whenever the user logs on. After collecting the hostname, username, and the installation date from the InstallDate value contained within the registry key HKLM\Software\Microsoft\Windows NT\CurrentVersion, this data is concatenated (delimited by underscore characters) and encrypted, along with other config information. It is then stored within the user’s registry inside a random key created at HKCU\Software\Microsoft\. The analyzed sample will also load a fresh copy of ntdll.dll to avoid hooking, which is then used to perform calls to NTAPI functions. SyncSuite.exe ultimately injects itself into a suspended instance of msedge.exe, created using NtCreateUserProcess and executed via ResumeThread, a technique known as Process Hollowing.
All of the strings used by the malware are stored encrypted within the .rdata section along with the configuration. The strings are decrypted using an obfuscated loop that is ultimately a simple XOR operation with the hard coded key 16 EB D5 3E AA E6 51 09 14 D3 DF 18 AD D6 1B BD BE, which is also stored in the .rdata section. The configuration is decrypted using an RC4 key, F3 F9 F7 FB FA F3 F7 F7 FF F5 F2 F3 FA FD FE F2 for this sample. The decrypted configuration for SyncSuite.exe can be seen below, with empty rows removed. The configuration contains a different public RSA key and botnet ID than the one previously shared by ThreatLabz, indicating that the campaign is being run by a different affiliate. All decrypted strings from SyncSuite.exe can be seen in the Zbot Strings section following other Indicators of Compromise.
Figure 6. The decrypted Zbot configuration for `SyncSuite.exe` (1264 bytes).
Rapid7 has also observed the delivery of DarkGate malware following initial access. One payload archive contained both a DarkGate infection initiation script, test.vbs, and an executable copy of the DarkGate malware itself, SafeFilter.exe (SHA256: EF28A572CDA7319047FBC918D60F71C124A038CD18A02000C7AB413677C5C161 ), though this copy is packed using the group’s custom packer. The final payload containing the DarkGate malware, after several layers of decrypting and loading, contains the version string 7.0.6. If the folder c:\debugg exists on the system when the malware is executed it will display the version number via MessageBoxA. The configuration for this sample can be seen below along with hard coded commands. Notably, the campaign ID for the sample appears to be drk2.
Figure 7. DarkGate displays its version using a debug message box.
The configuration is decrypted with the key ckcilIcconnh within a customized XOR loop near the beginning of execution to reveal CRLF delimited options. However, due to the implementation of the decryption loop, the keyspace is effectively reduced to that of a single byte (0-255), after the first byte. This makes the XOR key for the majority of the config 0x60, for this sample allowing for the encrypted data to be trivially bruteforced.
| SafeFilter.exe DarkGate Config |-|
Key-Value Pair
Description
0=179.60.149[.]194|
C2 domains or IP addresses, delimited with ‘|’ characters
8=No
If enabled and the file C:\ProgramData\hedfdfd\Autoit3.exe does not exist, call MessageBoxTimeoutA using keys 11 and 12 and a timeout of 1770ms.
11=Error
Used by key 8 as a message box title.
12=PyKtS5Q
The string Error, base64 encoded with the custom alphabet zLAxuU0kQKf3sWE7ePRO2imyg9GSpVoYC6rhlX48ZHnvjJDBNFtMd1I5acwbqT+=. Used by key 8 as a message box caption.
13=6
Unknown
14=Yes
Unknown
15=80
C2 communication port.
1=Yes
Enables infection.
32=Yes
If enabled, attempt bypass of detected security products. For example, enables calls to RtlAdjustPrivilege and NtRaiseHardError to cause a crash if hdkcgae is not present in C:\temp\ and a Kaspersky product has been detected.
3=No
If disabled, do an anti-vm display check.
4=No
If enabled, compare system drive size to key 18. If below, exit.
18=100
Minimum drive size in GB.
6=No
If enabled and key 3 is disabled, check the display for known virtual machine display strings using EnumDisplayDevicesA. If matched, exit. Failed to match properly when tested.
7=No
If enabled, compare system RAM to key 19. If below, exit.
19=4096
Minimum RAM size in MB.
5=No
If enabled, check the registry key ProcessorNameString at HKLM\HARDWARE\DESCRIPTION\System\CentralProcessor\0 for xeon. If found, exit.
21=No
Unknown
22
Not present in the config for this sample, but is still checked for in the code. If enabled, set the variant string to DLL, otherwise ?.
23=Yes
If enabled, set the variant string to AU3 for Autoit3 payloads.
31=No
If enabled, set the variant string to AHK for AutoHotKey payloads.
25=drk2
Campaign ID
26=No
Unknown
27=rsFxMyDX
Decryption key, also used to bound/find payloads stored within other files.
/c cd /d "C:\Users\User\AppData\Roaming<browser_dir>" && move <browser_name> <browser_name><random_alphabet_string>
/c cd /d "C:\Users\User\AppData\Local" && move <browser_name> <browser_name><random_alphabet_string>
/c cmdkey /delete:
/c cmdkey /list > c:\temp\cred.txt
/c del /q /f /s C:\Users\User\AppData\Roaming\Mozilla\firefox*
/c ping 127.0.0.1 & del /q /f /s c:\temp & del /q /f /s C:\ProgramData\hedfdfd\ & rmdir /s /q C:\ProgramData\hedfdfd\
/c shutdown -f -r -t 0
/c shutdown -f -s -t 0
/c wmic ComputerSystem get domain > C:\ProgramData\hedfdfd\fcadaab
During execution, DarkGate will hash certain strings and use the result to create or check files at the directories C:\ProgramData\hedfdfd(mainfolder) and C:\temp\. The hashing algorithm uses a randomized key generated at runtime, so the hashes across infections will be different. Commonly used strings and their resultant hash, for the analysis environment, are shown below.
Path String
DarkGate Custom Hash
mainfolder
hedfdfd
logsfolder
fhhcfhh
settings
dhkbbfc
domain
fcadaab
mutex0
hfgdced
mutex1
cekchde
au3
dgfeabe
c.txt
adfcbdd
cc.txt
dehgaba
script
daaadeh
fs.txt
hdkcgae
DarkGate may also change its behavior if a known security product is detected. This is achieved by using CreateToolhelp32Snapshot and related functions to loop through running processes which are compared to a hard-coded list. The malware will also check for known installation directories using GetFileAttributesA. If a security product is found, a flag will be set which may alter the execution path. Only the following products had associated flags:
DarkGate “Supported” Security Products
–
–
–
–
Windows Defender
Sophos
Quick Heal
MalwareBytes
Panda Security
Norton/Symantec
ESET/Nod32
Kaspersky
Avast
SentinelOne
Bitdefender
–
–
–
–
At the end of the first execution of the DarkGate payload, it will then attempt to inject itself into a host process. First, DarkGate will select the injection target by searching a list of hard coded directories for any executable that contains the string updatecore.exe, subdirectories included. The path C:\Program Files (x86)\Microsoft\EdgeUpdate\ is searched first, with the fallback being C:\Program Files (x86)\Microsoft\EdgeUpdate\MicrosoftEdgeUpdate.exe. If a matching Edge executable is not found, the path C:\Program Files (x86)\Google\Update\ is then searched. If that also fails, the malware will attempt to use C:\Windows\Microsoft.NET\Framework\v4.0.30319\msbuild.exe.
After successfully choosing the injection target, DarkGate will then inject itself into the target process using shellcode, terminating the original instance of the final DarkGate payload after executing the shellcode. When creating an instance of the target process to inject, DarkGate will also attempt to spoof the parent process ID (PPID) of the injection target by enumerating running processes for accessibility using OpenProcess and then randomly selecting one from an assembled list. The PPID of the target is then updated using UpdateProcThreadAttribute prior to creation with CreateProcessA.
Execution of the injected process is coordinated by checking for the presence of two file based mutexes within C:\ProgramData\hedfdfd\ (mainfolder). Each instance of the DarkGate malware checks both of the file-based mutexes. The file mutex usage is checked via calls to CreateFileA using an exclusive share mode flag (0) and a creation disposition of CREATE_ALWAYS, which means that if the mutex is already in usage by another DarkGate instance the call will fail. If the call to both mutexes created by DarkGate, hfgdced and cekchde, fails, DarkGate will exit. As a result of having two mutexes, DarkGate will typically run within two injected process instances at the same time, so if one process is terminated, the remaining instance will spawn another. If a DarkGate instance is spawned and both calls to open the file based mutexes fail, indicating two existing DarkGate instances, the new instance will terminate. This technique is rarely used by malware developers and highlights the sophistication of DarkGate malware.
DarkGate will unconditionally log keystrokes as well as clipboard data that is under 1024 bytes. The logged data is stored encrypted at C:\ProgramData\hedfdfd\fhhcfhh (mainfolder\logsfolder) within files named <date>.log. The logged data may be sent directly to the C2 address contained within the config. A thread is also created to persist on infected systems by creating the Run key daaadeh (script) at HKCU\Software\Microsoft\Windows\CurrentVersion\Run. The Run key will point to the copies of Autoit3.exe and the compiled AU3 script payload dgfeabe.a3x (au3) created at C:\ProgramData\hedfdfd (mainfolder), with the former executing the latter every time the user logs on. When the AU3 script is executed, DarkGate reinfects the system. The thread continuously monitors the text within the infected user’s active window however, sleeping 1500ms between checks, and will delete the registry key if a blacklisted application is detected. This list includes popular analysis tools such as Process Hacker, Process Monitor, Task Manager, and even the Windows Registry Editor.
The DarkGate sample executed by SafeFilter.exe contains 78 remote commands, some of which can be seen below with their intended function. Every loop, the malware will re-send the text of the active window, user idle time, and whether or not the malware instance has admin rights, before checking for a command.
Command ID
Function
1000
Sleep for a randomized amount of time.
1004
Use MessageBoxA to display the message test msg.
1044,1045,1046
Click the user’s mouse at specified screen coordinates using SetCursorPos and successive calls to mouse_event. 1044 for double left-click. 1045 for single left click. 1046 for single right click.
1049
Create a remote shell via powershell.exe.
1059
Terminate process by PID.
1061
Inject DarkGate shellcode into a specified process or an Edge/Chrome process if none is selected. The shellcode is then executed via ResumeThread.
1062,1063,1064
Inject DarkGate shellcode into a specified process or cmd.exe if none is selected. The shellcode is then executed via CreateRemoteThread.
1066
Remove infection files by using cmd.exe to delete the staging directories C:\ProgramData\hedfdfd and c:\temp\.
1071
Steal sitemanager.xml and recentservers.xml from %APPDATA%\FileZilla\ if present.
1079
If admin, delete stored credentials found using cmdkey.
1080
Rename browser directories for Firefox, Chrome, and Brave if present after terminating the related browser executable. Attempt to steal Opera cookies if present, after terminating the process.
1081
Use NTAPI calls RtlAdjustPrivilege and NtRaiseHardError to crash the system.
1083
Use the shutdown command to turn the system off.
1084
Use the shutdown command to restart the system.
1089
If 1=Yes in config, reinfect system with AU3 payloads.
1093
Create a remote shell via cmd.exe.
1097
Infect system with AU3 variant. Creates the files script.a3x and Autoit3.exe in c:\temp and then executes script.a3x via Autoit3.exe using CreateProcessA.
1104
Infect system with AHK variant. Creates the files script.ahk, test.txt, and AutoHotkey.exe in c:\temp and then executes script.ahk via AutoHotkey.exe using CreateProcessA.
1108
Infect system with DLL variant. Creates the files libcurl.dll, test.txt, and GUP.exe in c:\temp and then executes GUP.exe via CreateProcessA.
1111
Create the files ransom.txt and decrypter.exe in c:\temp. Terminate decrypter.exe if already running and then execute decrypter.exe using CreateProcessA. Likely ransomware deployment method.
DarkGate Remote Command Related Strings
–
–
–
–
U_Binder
U_BotUpdate
U_Constantes
U_FTPRecovery
U_FileManager
U_FileManagerMisc
U_GetScreens
U_HVNC
U_HVNC_7
U_HWID
U_InfoRecovery
U_InjectOnFly
U_Keylogger
U_LNKStartup
U_MemExecute
U_MemExecuteMisc
U_RemoteScreen
U_SysApi
U_SysNtReadWrite
U_miniclipboard
u_AntiAntiStartup
u_Antis
u_AudioRecord
u_CustomBase64
u_ExtraMisc
u_HollowInstall
u_InjectEP
u_InvokeBSOD
u_RDPRecovery
u_Ransomware
u_ReadCookies
u_ReverseShell
u_RootkitMutex
u_Settings
u_SettingsPad
u_ShellcodeEP
u_UnlockCookies
u_loadpe
hxxps://ipinfo[.]io/ip
Mitigation Guidance
Rapid7 recommends taking the following precautions to limit exposure to these types of attacks:
Restrict the ability for external users to contact users via Microsoft Teams to the greatest extent possible. This can be done for example by blocking all external domains or creating a white/black list. Microsoft Teams will allow all external requests by default. For more information, see this reference.
Standardize remote management tools within the environment. For unapproved tools, block known hashes and domains to prevent usage. Hash blocking can be done, for example, via Windows AppLocker or an endpoint protection solution.
Provide user awareness training regarding the social engineering campaign. Familiarize users with official help desk and support procedures to enable them to spot and report suspicious requests.
Standardize VPN access. Traffic from known low cost VPN solutions should be blocked at a firewall level if there is no business use case.
Rapid7 Customers
InsightIDR, Managed Detection and Response, and Managed Threat Complete customers have existing detection coverage through Rapid7’s expansive library of detection rules. Rapid7 recommends installing the Insight agent on all applicable hosts to ensure visibility into suspicious processes and proper detection coverage. Below is a non-exhaustive list of detections that are deployed and will alert on behavior related to this activity:
Detections
Suspicious Chat Request – Potential Social Engineering Attempt
Initial Access – Potential Social Engineering Session Initiated Following Chat Request
Suspicious Conversation – Potential Social Engineering Message Interaction
Attacker Technique – Process Executed Using Nt Object Path
Suspicious Process – Enumeration Burst via ShellExecute
As published in HackerNoon and featured as a “Top 20 Best Read Article” for AI.
Introduction
The rapid advancement of AI has offered powerful tools for malware detection, but it has also introduced new avenues for adversarial attacks. As an example, recently OpenAI reported threat actors abusing ChatGPT to execute reconnaissance, help fix code, write partial code, or look at vulnerabilities. These are, to me, examples of AI aiding “basic” steps, but would threat actors invest and use more advanced applications?
Universal Adversarial Perturbations (UAPs) have gained attention due to their potential to bypass machine learning models in various domains, including malware detection. UAPs can manipulate malware in ways that evade AI-based detection systems without altering the malware’s core functionality. However, despite this capability, cybercriminals have not widely adopted AI-driven techniques like UAPs. This blog delves into the complexity and effort required to generate UAPs for malware and explains why it might not be worth the trouble for attackers.
Just to be clear on definitions:
Artificial Intelligence (AI) is a broad field that aims to create machines or software capable of performing tasks that typically require human intelligence, such as understanding language, recognizing images, problem-solving, and decision-making. AI encompasses various techniques and approaches, from rule-based systems to learning algorithms.
Machine Learning (ML) is a subset of AI that focuses on building systems that learn from data. Instead of being explicitly programmed for each task, ML models identify patterns in data to make predictions or decisions, improving over time with more experience.
UAPs: A Brief Overview
Universal Adversarial Perturbations (UAPs) are subtle modifications applied to input data (such as malware samples) to mislead AI models. What makes UAPs particularly interesting is that a single perturbation can be applied to many inputs (one ring rules them all), causing the AI model to misclassify them. Think of it as changing just a few pixels in a picture to make a powerful facial recognition system mistake someone for someone else. In the below example, a single bit of random code is added to multiple different images, resulting in the classifying model going completely wrong on the identification.
When we look at the example of the platypus, the model identifies the animal partially right based on the training on the beak with other images, but due to the interference with the added “noise” in the pixels, it classifies it wrong. That is exactly the interesting space when it comes to malware detection and evasion. You want malicious files to be classified wrong.
In the context of malware detection, UAPs allow attackers to evade detection without having to create entirely new malware variants. While this seems like a low-effort, high-reward strategy, generating effective UAPs is far more challenging than it appears, particularly in the malware domain.
Complexity in Crafting UAPs for Malware
In their paper, “Realizable Universal Adversarial Perturbations for Malware,” Labaca-Castro et al. demonstrate that crafting UAPs for malware requires an intricate balance between manipulating feature space (abstract representations of malware) and problem space (real-world executable malware). Unlike image or text data, where perturbations may be easily applied without affecting functionality, malware is far more delicate. A slight misstep in the perturbation process can corrupt the malware sample, rendering it unusable. You need to respect (with regards to Windows malware) the PE structure of a file. A modification to that structure will break its functionality and the malware will not execute. It may have bypassed detection but it is useless to the attacker.
The process requires attackers to perform a series of careful transformations to avoid breaking the executable while still evading detection. This is a far cry from simply adding noise to an image or text dataset. As a result, the time and expertise required to create UAPs that both fool AI/ML malware detection models and preserve malware functionality is significant.
UAPs vs. New Malware Variants
Given the complexity of generating UAPs, cybercriminals face a dilemma: Should they invest time and resources into crafting these perturbations, or is it easier to create entirely new strains of malware?
Developing a new malware strain might involve reusing code from previous versions, applying known obfuscation techniques, or modifying payloads. This process is often faster, less risky, and more predictable compared to the complex sequence of transformations required to generate UAPs. As a result, many attackers prefer to invest in creating new strains of malware, which are more likely to achieve the desired outcome without the same level of effort and risk.
Challenges
One of the major hurdles in applying UAPs to malware is the real-world execution environment. Malware operates in dynamic, unpredictable conditions, and UAPs crafted in controlled environments may not perform as expected once deployed. Small changes in the operating system, file structure, or antivirus defenses can render the UAP ineffective. This fragility is a key reason why UAPs remain largely theoretical for malware attacks rather than a widely adopted technique in practice.
Additionally, defenders are not standing still. Adversarial training—where AI models are retrained using adversarial examples—can harden systems against UAPs, making it even harder for attackers to succeed. Mitigation strategies will raise the cost and effort required for attackers to generate successful UAPs, further reducing their appeal.
Conclusion
The idea of using AI to defeat AI, particularly through Universal Adversarial Perturbations, may seem like a natural progression in the ongoing battle between attackers and defenders. However, the reality is that the complexity and risk associated with developing UAPs for malware make this approach unattractive for most cybercriminals. Instead, attackers tend to rely on more straightforward methods like creating new malware variants, which offer a better return on investment with less risk of failure. If you examine some of the latest ransomware campaigns, none of them highlight the use of AI-based techniques. Instead, as shown in recent coverage of ransomware tactics, attackers consistently focus on tried-and-tested approaches that maximize impact and minimize operational complexity.
As long as the development of UAPs remains fraught with difficulties—such as maintaining functionality and overcoming problem-space constraints—it’s unlikely that we will see widespread adoption of these techniques in the cybercriminal world. Instead, traditional malware development and deployment methods will continue to dominate the landscape, while defenders must remain vigilant and adaptive to the evolving AI threat landscape.
The collective thoughts of the interwebz
Manage Consent
To provide the best experiences, we use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behavior or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions.
Functional
Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.
