July 14, 2026 23 min read

Phorpiex: Inside the Botnet Powering Global Sextortion Spam Operations

Kedar Shashikant Pandit and Prathamesh Shingare Lat61 Threat Intelligence Team
Phorpiex: Inside the Botnet Powering Global Sextortion Spam Operations

Executive Summary

Point Wild analyzed a sextortion campaign leveraging infrastructure associated with the Phorpiex botnet, a malware family historically known for large-scale spam distribution and financially motivated operations.

Our analysis identified an infection chain in which downloader components communicate with command-and-control (C2) infrastructure to retrieve additional payloads and trace the victim’s geo-location. Observed functionality includes downloading secondary executables, gathering host information, and determining the victim’s geographic location. The campaign ultimately transitions from technical activity to monetization, where victims are targeted with sextortion-themed emails designed to coerce cryptocurrency payments.

The extortion emails claim that the victim’s device has been compromised through a Remote Administration Tool (RAT) and that compromising recordings have been captured through webcam surveillance. Victims are threatened with the public release of the alleged content unless a Bitcoin payment is made within a specified timeframe. Despite the alarming nature of these claims, the emails provide no supporting evidence, indicating that the operation relies heavily on psychological manipulation and reputational fear rather than demonstrating a confirmed compromise.

Point Wild’s findings highlight how threat actors continue to repurpose established botnet infrastructure to support financially motivated campaigns at scale. By combining automated malware distribution with socially engineered extortion tactics, the actors can maximize victim reach while minimizing operational overhead. This activity underscores the ongoing evolution of cybercriminal monetization strategies, where technical capabilities and human-targeted deception work together to increase the likelihood of financial gain.

Point Wild independently analyzed the sample and infrastructure; however, since Phorpiex has been extensively documented by the security community, relevant public research is referenced to provide historical context and acknowledge prior work.

Possible Initial Infection Vectors

Based on the observed infection chain and historical Phorpiex activity, victims were likely targeted through one or more of the following delivery mechanisms:

  • Large-scale spam email campaigns containing malicious attachments.
  • Phishing emails with links to downloader malware.
  • ZIP or archive files containing malicious executables.
  • Social engineering lures are disguised as invoices, receipts, or financial documents.
  • Fake shipping, delivery, or payment notification emails.
  • Trojanized software installers obtained from untrusted sources.
  • Malvertising campaigns redirect users to malware-hosting websites.
  • Fake software or browser update prompts.
  • Secondary payload delivery through existing malware infections.
  • Downloads from compromised or attacker-controlled websites.

Fear, Sextortion, and the Illusion of Compromise

Fig 1: Sextortion email claiming device compromise and webcam recording to extort Bitcoin payments from victims

Imagine opening your inbox to find a message claiming that a threat actor has been secretly monitoring you through your webcam. The email alleges that your device was infected with a Remote Administration Tool (RAT), granting the attacker access to your files, accounts, and camera. To intensify the pressure, the sender claims to have recorded compromising footage and threatens to distribute it to family members, friends, colleagues, social media contacts, and even dark web communities. As observed by Point Wild, the message is carefully crafted to provoke an immediate emotional response, leaving victims feeling exposed, vulnerable, and pressured to act before verifying the legitimacy of the claims.

However, this extortion attempt does not exist in isolation. Point Wild’s analysis indicates that the sextortion emails are part of a broader malware-driven ecosystem involving the Phorpiex botnet. Leveraging millions of compromised systems, the botnet distributes malicious emails at scale, significantly increasing the reach of the campaign.

Point Wild has been identified as a campaign primarily associated with sovereign states in Asia. For details on the number of systems compromised by this botnet, refer to this valuable Bitsight resource. Victims who interact with the delivered content may unknowingly execute downloader components that establish communication with command-and-control (C2) infrastructure and retrieve additional payloads. According to Point Wild’s findings, these payloads are capable of collecting victim information, downloading secondary malware, and identifying the victim’s geographic location, enabling threat actors to better understand and categorize potential targets.

Once victim information has been gathered, the campaign shifts from technical activity to psychological manipulation. The sextortion email serves as the monetization stage of the operation, where fear becomes the primary weapon. Point Wild observed that the threat actor attempts to strengthen the credibility of the threat by claiming that all traces of the malware have already been removed from the victim’s system and warning that multiple copies of the email will be delivered until the demand is met. The victim is instructed to transfer $1,200 USD in Bitcoin (BTC) to a specified cryptocurrency wallet, with references to legitimate cryptocurrency exchanges provided to simplify the payment process.

Point Wild’s analysis suggests that the effectiveness of the campaign lies not in demonstrating a verified compromise but in exploiting human emotions. Fear of reputational damage, embarrassment, and public exposure is used to manipulate victims into making impulsive decisions. Notably, the email provides no evidence to substantiate its claims, a characteristic frequently observed in large-scale sextortion campaigns. By combining botnet-powered distribution, victim profiling, and fear-based social engineering, threat actors can target a vast number of individuals while maintaining a highly scalable and cost-effective operation. The campaign demonstrates how modern cybercriminals increasingly blend malware infrastructure with psychological coercion, transforming technical access and victim data into a tool for financial extortion.

Point Wild Observation: Live Botnet-Driven Spam Distribution

Fig 2: Live Botnet- driven spam distribution through SMTP

Point Wild observed the process establishing multiple concurrent SMTP connections to numerous external mail servers shortly after execution. The network activity included communication with infrastructure associated with various email service providers and domains, with several connections reaching an ESTABLISHED state while others remained in SYN_SENT, FIN_WAIT2, or CLOSING states. The volume and diversity of outbound SMTP connections indicate automated email transmission behavior rather than normal user-driven email activity.

This pattern is consistent with malware leveraging infected systems to distribute large volumes of email messages as part of a spam or botnet-driven operation. By directly communicating with multiple mail servers, the malware can efficiently deliver messages to a large number of recipients while reducing dependence on a single email provider. In the context of the broader Phorpiex-related activity observed during this investigation, the behavior aligns with the botnet’s historical use of compromised hosts to facilitate mass email distribution, including spam, malware delivery, and sextortion campaigns.

The observed SMTP activity demonstrates how infected hosts can be repurposed as email distribution nodes within a larger botnet infrastructure. Such functionality enables threat actors to scale campaigns, increase delivery success rates, and support subsequent monetization efforts through malware distribution and extortion operations.

Attack Flow

Fig 3: Attack Flow

Technical Details:

During analysis, we observed that the sample invoked the GetTempFileNameW API from kernelbase.dll to generate a temporary filename within the user’s temporary directory. The API was provided with C:\Users\admin\AppData\Local\Temp\ as the target path for file creation. The malware dynamically generates the filename instead of using a hardcoded value. This approach helps it evade simple signature-based detection and reduces the likelihood of filename collisions on the infected system.

Fig 4: Random Temporary Filename Generator – Malware Payload Staging with Unpredictable Filenames

Upon analysis, the binary was observed invoking CreateFileW to access a temporary file located in C:\Users\admin\AppData\Local\Temp\. The sample constructs the path dynamically and uses the filename 7B5C.tmp, indicating that the file is generated at runtime rather than being statically defined.

Fig 5: Temp Directory File Operations

Fig 5: Temp Directory File Operations

After creating the temporary file, the file was observed modifying the extension of a temporary filename generated through

GetTempFileNameW. The routine receives pointers to the strings .tmp and .exe and performs a character-by-character copy operation to overwrite the original extension.

Fig 6: Malware File Extension Converter – .TMP to .EXE Transformer

As a result, the malware converts the generated temporary file path from a non-executable format into an executable file. For example, a filename such as “FFFF.tmp” is transformed into “FFFF.exe” before being used in subsequent operations.

Fig 7: Malware String Decoder – Remote payload

In Fig.7, it was observed that the sample dynamically constructs the download URL in memory by writing individual Unicode characters to stack-based buffers through multiple mov instructions. The resulting string forms the URL http[:]//178.16.54.109/32.exe.

The malware does not store the complete URL as a contiguous string within the binary. Instead, it assembles the URL character-by-character at runtime, likely as a simple obfuscation technique to evade static string-based detection and hinder automated analysis.

Fig 8: Malware Payload Download Engine – URLDownloadToFileW API Implementation

During dynamic analysis, it was observed that the sample invokes the URLDownloadToFileW API from urlmon.dll to retrieve a remote payload from a remote server. The API is supplied with the URL http[:]//178.16.54.109/32.exe as the source location and saves the downloaded file to C:\Users\admin\AppData\Local\Temp\7B5C.exe.

Following the API invocation, the file performs a status check using the test eax, eax instruction to determine whether the download operation completed successfully. A return value of 0 (S_OK) indicates that the payload was downloaded successfully.

This behavior demonstrates that the analyzed sample functions as a downloader, where the initial executable retrieves a secondary-stage payload from an external server and stores it within the user’s temporary directory for subsequent execution

Artifact of this downloader file-

Fig 9: Downloader file (32.exe)

In Fig.10, the sample was observed invoking the CreateProcessW API to execute the downloaded payload. Before the API invocation, the malware initializes the STARTUPINFO structure by setting its cb member to 0x44, corresponding to the expected size of the structure. In addition, a PROCESS_INFORMATION structure is allocated to receive information related to the newly created process.

Fig 10: CreateProcessW Loop for Parallel Malware Execution

After preparing the required execution parameters, the malware supplies the path of the downloaded executable to CreateProcessW and attempts to launch the secondary-stage payload. The success of the operation is subsequently verified by examining the return value of the API call.

Stage 2: Analysis of the Downloader file

Fig 11: IP Geolocation Detector – Identifies Victim’s Country for Geofencing

Network Reconnaissance and Geolocation Analysis

While analyzing, the sample was observed delaying execution for approximately 20 seconds before initiating network communications. Following the delay, the malware invokes the getaddrinfo API to resolve the hostname ip-api.com over TCP port 80.

The returned address information is used to create a TCP socket via the socket API. The sample then iterates through the resolved addresses and attempts to establish a connection using the connect API. If a connection attempt fails, the socket is closed, and the next available address is tested until a successful connection is established.

The use of ip-api.com, a public IP geolocation service, suggests that the malware may be collecting information about the infected host’s external IP address and geographic location. Such information can be used to perform victim profiling, apply geographic targeting rules, or determine whether execution should continue based on the victim’s location.

Fig 12: victim profiling info

During memory analysis, a complete HTTP response from the geolocation service ip-api.com was recovered from process memory. The response contained a JSON object providing geographic and network-related information associated with the infected host’s public IP address.

The presence of this data in memory confirms that the malware successfully communicated with the external geolocation service and retrieved victim profiling information.

The memory dump contains the following geolocation information:

{
 "status":"",
 "country":"",
 "countryCode":"",
 "region":"",
 "regionName":"",
 "city":"",
 "zip":"",
 "lat":,
 "lon":,
 "timezone":"",
 "isp":"",
 "org":"",
 "as":"",
 "query":""
}

Fig 13: Memory dump of geolocation information

Fig 14: IP Geolocation Detector – Identifies Victim’s Country for Geofencing and Targeted Malware Distribution

During analysis, the sample was observed implementing a geolocation-based execution control mechanism before downloading its secondary payload. The malware parses the response received from the external geolocation service and extracts the value associated with the countryCode field.

The extracted country code is compared against a hardcoded list of countries, including the United States (US), Sweden (SE), Canada (CA), Switzerland (CH), the United Kingdom (GB), Liechtenstein (LI), the Netherlands (NL), Luxembourg (LU), New Zealand (NZ), and Germany (DE).

If the infected system is determined to be located within one of the specified countries, the malware displays a message box and immediately terminates execution via ExitProcess(). This behavior prevents the payload delivery process from continuing on systems located within those regions.

When the victim’s country does not match any entry in the exclusion list, the malware proceeds to download a secondary-stage payload from http[:]//178.16.54.109/newtpp.exe

Fig 15: Malware Payload Download Engine – URLDownloadToFileW API Implementation

During analysis, the sample was observed invoking the URLDownloadToFileW API from urlmon.dll to retrieve a secondary-stage payload from the remote URL http[:]//178.16.54.109/newtpp.exe. The downloaded file is written to C:\Users\admin\AppData\Local\Temp\3082523530.exe.

Then, the sample was observed invoking the CreateProcessW API from kernelbase.dll to execute a previously downloaded payload

After completing the geolocation validation and payload download stages, the malware proceeds to execute the downloaded component using the legitimate Windows process creation mechanism.

Fig 16: Downloader file (newtpp.exe)

Stage 3: Analysis of deliverable Twizt file

During analysis, the newtpp.exe was observed invoking the URLDownloadToFileW API to retrieve an executable payload from the remote URL http[:]//178.16.54.109/twizt.exe. Following the download attempt, the malware verifies the success of the operation by examining the API return value.

Fig 17: Malware Payload Download Engine – URLDownloadToFileW API Implementation

During analysis, we observed that the newtpp.exe file carries the Phorpiex payload, specifically the Twizt Downloader. It is a well-known Phorpiex botnet malware sample. Below, we analyze this Twizt file in detail.

Downloader Twizt File Analysis:

Twizt is a multifunctional malware sample that includes worm-like propagation capabilities to spread infection and deploy a complete botnet architecture. In addition, it downloads the malicious XMRig miner to perform cryptocurrency mining.

Clipboard hijacking code targeting cryptocurrency wallet

Fig 18: Crypto Wallet Stealer – Clipboard Address Interceptor

This is a cryptocurrency wallet address replacement trojan that hijacks the Windows clipboard to redirect cryptocurrency transactions to attacker-controlled wallets. The code detects when users copy cryptocurrency addresses (Bitcoin, Monero, Cosmos, Nano) by checking for distinctive byte patterns and prefixes specific to each cryptocurrency format.

When a legitimate wallet address is detected, the malware retrieves a hardcoded malicious wallet address and performs a clipboard hijacking attack: allocating memory, copying the attacker’s address, opening the clipboard, clearing the original content, and injecting the malicious address. The victim then unknowingly pastes the attacker’s wallet address instead of the intended recipient’s address, causing cryptocurrency funds to be redirected to the attacker with no way to recover them. This is a critical financial theft mechanism commonly used in banking trojans and cryptocurrency-targeting malware.

Persistence and File Distribution Module

Fig 19: Multi-Named Malware Persistence Installer with Evasion Techniques

This code establishes malware persistence by creating a mutex for single-instance enforcement, then checking if the process is already running under the name “DrvSvcsrMgrsvr.exe” and performing registry checks. It removes the Zone.Identifier alternate data stream to erase forensic evidence of download origin. The code then creates three hidden copies of the malware named syscvnrhost.exe in critical system locations: the system directory (%windir%), user profile directory (%USERPROFILE%), and AppData directory. Each copy is hidden using file attribute 3, then registered in the Windows Run registry key under HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run\ with the value name “WindowsSetting”. This ensures the malware automatically executes on every system reboot with both system and user-level persistence, providing multiple fallback execution paths if one instance is detected and removed.

Command-and-Control Infrastructure Initialization

Fig 20: Command-and-Control Infrastructure Initialization with Multi-Threaded Worker Pool Spawning

This code initializes the malware’s network communication and threading infrastructure. It starts Winsock networking with WSAStartup, creates configuration files (tbtnds.dat for C2 settings and tbtcmds.dat for commands) in the user profile directory, and spawns multiple worker threads with deliberate delays between launches. These threads handle C2 communication (sub_407A50), message window dispatching (sub_405CA0), and disk inventory collection (sub_407150). The code creates a thread pool using system-aware sizing, initializes synchronization primitives, including event objects for coordination, and establishes multiple named thread pools that will monitor incoming commands from the C2 server.

Botnet Architecture & Worm Propagation

Below we can see the code of these three threads that have a Unified Malware Command-and-Control Infrastructure description. This is a coordinated three-thread malware framework that forms the complete command-and-control (C2) pipeline for a sophisticated botnet. 

Fig 21: Complete Botnet C2 Pipeline: Remote Command Fetcher + Hidden Message Relay for Distributed Payload Execution

The first thread acts as the primary C2 callback mechanism, connecting to remote command servers on a 14-hour schedule and downloading malicious commands by constructing URLs from hardcoded C2 addresses with numbered suffixes. It downloads payloads and processes them through an execution handler, maintaining persistent connectivity to the attacker’s infrastructure.

The second thread creates a hidden message-only window with randomized naming to serve as an internal command relay station and inter-process communication hub. This window doesn’t appear on screen but receives and dispatches messages from other malware components, allowing commands fetched by the C2 downloader to be relayed and coordinated across multiple processes and threads within the infected system. It acts as an internal message broker, decoupling the C2 communication from actual command execution.

Fig 22: Disk Drive Profiler and USB Detection Monitor

The third thread continuously enumerates all disk drives on the system every 2 seconds, collecting inventory data including volume names, disk capacity in gigabytes, and filesystem information for both fixed and removable media. This inventory is reported back to the C2 server, providing attackers with complete visibility into the victim’s storage infrastructure, identifying USB drives for malware propagation, and locating high-value data targets for exfiltration or encryption.

Together, these three threads form a complete botnet architecture: the downloader fetches remote commands, the message dispatcher relays them internally for execution, and the inventory collector profiles the system and reports findings to the C2. The coordinator ensures all three threads remain active and restarts any that crash, creating a resilient, self-healing malware framework capable of receiving commands, executing them reliably, and maintaining persistent reconnaissance of the compromised system.

Botnet-Based TCP Flooding

Fig 23: TCP Flooding Botnet Activity Observed on the Compromised Host

In Fig.23, the infected system was observed running a malicious process identified as syscvrnhost.exe, which established continuous outbound TCP communications with external infrastructure while simultaneously maintaining local listening sockets and active UDP communication channels. Such behavior is consistent with TCP flooding activity, specifically TCP SYN flood operations commonly associated with distributed denial-of-service (DDoS) attacks.

The malware appears to function as part of a botnet infrastructure, where compromised hosts are remotely controlled to generate malicious network traffic against designated targets. In this scenario, the infected host acts as a bot node capable of participating in coordinated TCP flooding attacks designed to exhaust target resources, disrupt network services, or degrade system availability

Additionally, the Twizt downloader generates multiple HTTP file download requests dynamically. It also issues additional requests to download and write the file to the system.

One of them is http[:]//178.16.54.109/[1]

Fig 24: Additional payload from downloading c2 server

XMRig miner

In our case, the file sysfrodolv.exe was downloaded and written to %USERPROFILE% in a hidden manner. Analysis of sysfrodolv.exe reveals that it downloads a malicious XMRig miner

Fig 25: Monero Mining Botnet Installer and Launcher

This is a cryptocurrency miner dropper and loader that silently installs and executes XMRig (a Monero cryptocurrency miner) on the infected system. The code begins with a 2-second delay and mutex creation to enforce single-instance execution. It then calls a validation function before proceeding with the mining setup.

The malware attempts to download XMRig from the hardcoded C2 server at http[:]//178.16.54.109/xmrig.exe and saves it as sysmgnrsv.exe in the user profile directory. If the download fails on the first attempt, it retries after waiting 5 seconds (0x1388 milliseconds), providing redundancy to ensure the miner is installed even if the initial download is blocked.

Once the XMRig executable is confirmed to exist, the malware removes the Zone.Identifier alternate data stream from its own executable to erase forensic evidence. It then copies itself to multiple locations with the disguised name sysfrodolv.exe, setting hidden file attributes (3) on each copy. The copies are registered in both the system-level and user-level Windows Run registry keys, ensuring automatic execution on every system reboot.

Fig 26: Cryptocurrency Mining Command Injector

Finally, the malware launches XMRig with specific mining parameters via ShellExecuteW: pointing to the mining pool at 178.16.54.109:6060, using a hardcoded Monero wallet address (83h9mBvy1LL2qW6c2HeWczYVJQsFDF7RfVqDnaiSfFBdDcxfyJfWhRnZqZkY5chb5b6tmKZ1PPhuQbNgXggCdwTrMYWN8hi), and limiting CPU usage to 25% across 2 threads to avoid overwhelming the system and triggering user suspicion. This transforms the compromised system into a cryptocurrency mining bot that generates revenue for the attacker while consuming system resources.

At last, sysmgnrsv.exe is run through CMD. This indirect execution through cmd.exe is an evasion technique that can help bypass some security tools and process monitoring that might have rules against directly executing suspicious executables. The cmd.exe intermediary provides a layer of obfuscation between the parent process and the actual miner execution.

Fig 27: Process view of executing Xmrig file through cmd

Sextortion botnet payload analysis

Fig 28: SMTP Email Spoofing Code

This is an SMTP email spoofing engine that automatically sends phishing or spam emails through compromised mail servers with completely forged headers to hide the malware’s origin. The code implements a finite state machine that walks through the SMTP protocol handshake, starting with EHLO/HELO greeting negotiation to identify the server type.

The state machine progresses from initial connection negotiation (case 1) to specifying the sender address (case 3) using a spoofed “[MaliID].com” email, then specifying the recipient address passed to the function (case 4), and issuing the DATA command to begin the email body (case 5).

In the final critical stage (case 6), the malware constructs completely forged email headers designed to appear legitimate while obscuring the true origin.

The header forgery includes generating fake “Received” headers with spoofed IP addresses (randomly generated numbers formatted as IP octets), creating fictional domain names and generating fake Message-IDs and timestamps. The malware uses helper functions like sub_401350 to generate random strings for various header fields and constructs headers for “From” ([MaliID] + spoofed address), “To” (actual target), “Subject” (hardcoded as “You Pervert I Rec”), “Date”, and “Message-ID”. This level of header forgery makes the spam emails appear to come from legitimate mail servers and trusted senders, making them more likely to bypass spam filters and trick users into opening them.

Fig 29: Botnet C2-Driven Payload Downloader with Mass Thread Spawning and Parallel Execution Engine

This is a coordinated botnet payload downloader and multi-threaded executor that orchestrates mass deployment of malicious payloads across an infected system. The code operates as a command-driven loop controlled by a remote C2 server. The thread begins by copying connection parameters and seeding the random number generator with the current system tick count. It retrieves a command server hostname and expands the Windows temp directory path, then constructs URLs pointing to manifest files on the C2 server (a file named “n.txt” and numbered payload files like “1.txt”, “2.txt”, etc.). It downloads the manifest file and extracts an integer counter value indicating how many payload execution cycles to perform.

In each execution cycle, the code downloads a numbered payload file, saves it with a randomized filename (like “1234567890123.jpg”) in the temp directory, and then spawns 5,000 threads in coordinated bursts (100 iterations with 50 threads spawned per iteration, each thread separated by 50-100 milliseconds). Each spawned thread calls the payload execution function. This massive parallel execution ensures the malware payload runs simultaneously across thousands of threads, overwhelming security monitoring tools and maximizing impact.

Execution of botnet payload and process view

Fig 30: Process view of botnet payload

So in our case, the attackers have uploaded a list of target email addresses and user passwords and our infected system is now weaponized to send mass phishing/spam emails to all those addresses using the SMTP connections described earlier (Fig.1). Each bot ( Fig.2) spawns thousands of threads to process this email list simultaneously, maximizing the spam/phishing campaign reach.

The JPG file is not a traditional image file; instead, it’s a disguised data payload containing target email addresses and user information for the spam/phishing campaign. The .jpg extension is a camouflage technique to avoid detection.

Example of one randomized .jpg file that is saved in the %Temp% directory-

Fig 31: Randomized .jpg file that have target email addresses

SMTP Attack Chain: How Compromised Mail Servers Bypass Internal Security While External Senders Get Blacklisted

Fig 32: Failed External SMTP Relay – Spamhaus Blacklist Rejection (550 Error)

External Relay (REJECTED):

The infected machine (192.168.4.103) attempts SMTP relay to external mail servers (Gmail, Yahoo) from public IP 36.255.184.9. TCP connection succeeds, but receiving mail servers query Spamhaus and find 36.255.184.9 blacklisted. They respond with an SMTP 550 error code at the application layer (not TCP layer), rejecting the mail after the connection is already established. The rejection occurs AFTER the MAIL FROM command, when Spamhaus lookup happens.

Fig 33: Successful Internal SMTP Relay: Botnet Malware Exploiting Local Mail Server to Distribute Sextortion Payload

Internal Relay (SUCCEEDED):

The same infected machine connects to the local mail server (192.168.4.103:25). Because it’s internal and locally authenticated, the mail server SKIPS Spamhaus checks (doesn’t apply to internal processes). The mail server accepts the relay request and forwards sextortion emails with spoofed sender addresses and hardcoded cryptocurrency payment instructions to external recipients. Packets show the email data (209 bytes, 71-byte fragments) successfully transmitted through the internal relay.

This investigation demonstrates that modern botnet infrastructure represents a critical threat requiring multi-layered detection and response capabilities. Implement strict network controls, monitor outbound SMTP traffic, and conduct regular malware assessments to prevent your infrastructure from becoming weaponized in mass sextortion campaigns.

Detection and Mitigation

UltraAV, powered by Point Wild, helps defend against such threats by focusing on initial-stage files. Point Wild has detected this file at each stage of the different payloads hosted on the attacker’s server.

Fig 34: Detection

In the modern age, the Phorpiex botnet has shown that antivirus protection is important for every consumer, regardless of age. This demonstrates the importance of regularly updating UltraAV virus definitions as soon as new updates become available to ensure effective identification and mitigation of emerging threats.

Conclusion

At Point Wild, the analysis revealed a multi-stage malware infection involving staged payload downloads, geolocation-based victim filtering, persistence mechanisms, cryptocurrency mining, and botnet-related activity. The malware downloaded and executed multiple payloads using legitimate Windows APIs, ultimately deploying the XMRig cryptocurrency miner on the compromised system. Persistence mechanisms enabled long-term execution, while the malware also exhibited TCP flooding behavior associated with botnet-driven DDoS activity. Additionally, the infection distributed multiple extortion-related message files across the victim machine.

Overall, the malware demonstrates a modular and persistent threat capable of cryptocurrency mining, botnet communication, payload delivery, and network-based attacks.

Indicators of compromise

MD5 Filename
63760c4b545d9d655439379b7f0c0923 DRemover.exe
362fc53afbda6450184b73746802a6fa 32.exe
d56881c9efd4fde5babaea7b074b4b2b newtpp.exe
4d2d3b04cf612c15cf5815be0fbeac51 Twizt.exe/syscvnrhost.exe
07bd5d0edaca14204802b8ff7db346ce sysfrodolv.exe
ac458ece671fdde066ce60e448f12bc0 Sysmgnrsv.exe (Xmrig.exe)

 

http[:]//178.16.54.109/ C2 Server

Keep reading