{
	"id": "9c16d0fe-2e53-4857-9e00-260501c76ba3",
	"created_at": "2026-04-06T00:19:21.896626Z",
	"updated_at": "2026-04-10T13:11:55.292196Z",
	"deleted_at": null,
	"sha1_hash": "2d5b0f6f8042eb5b195ba7843b5e12a7e941f886",
	"title": "Clipsa – Multipurpose password stealer",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1206524,
	"plain_text": "Clipsa – Multipurpose password stealer\r\nBy Threat Research TeamThreat Research Team\r\nArchived: 2026-04-05 22:09:18 UTC\r\nHigh level overview\r\nClipsa is a multipurpose password stealer, written in Visual Basic, focusing on stealing cryptocurrencies, brute-forcing and stealing administrator credentials from unsecured WordPress websites, replacing crypto-addresses\r\npresent in a clipboard, and mining cryptocurrencies on infected machines. Several versions of Clipsa also deploy\r\nan XMRig coinminer to make even more money from infected computers.\r\nClipsa spreads as a malicious executable file, likely disguised as codec pack installers for media players. Once on\r\nan infected device, Clipsa can perform multiple actions, such as searching for cryptowallet addresses present in\r\nvictims’ clipboards to then replace the addresses victims want to send money to with wallet addresses owned by\r\nthe bad actors behind Clipsa. Furthermore, Clipsa is capable of searching for and stealing wallet.dat files, and\r\ninstalling a cryptocurrency miner.\r\nAdditionally, Clipsa uses infected PCs to crawl the internet for vulnerable WordPress sites. Once it finds a\r\nvulnerable site, it attempts to brute-force its way into the site, sending the valid login credentials to Clipsa’s C\u0026C\r\nservers. While we cannot say for sure, we believe the bad actors behind Clipsa steal further data from the breached\r\nsites. We also suspect they use the infected sites as secondary C\u0026C servers to host download links for miners, or\r\nto upload and store stolen data.\r\nCampaign overview\r\nWe estimate that the attack vector is most likely malicious codec pack installers for media players ( Ultra XVid\r\nCodec Pack.exe or Installer_x86-x64_89006.exe ). Users who try to install these codecs for their media players\r\ninadvertently download malicious installers instead of clean ones. Once users begin the installation process, they\r\ndeploy Clipsa on their machines and the malware immediately starts its malicious behavior.\r\nThe campaign is most prevalent in India, where Avast has blocked more than 43,000 Clipsa infection attempts,\r\nprotecting more than 28,000 users in India from the malware. We have also observed higher infection attempt\r\nrates in the Philippines, where Avast protected more than 15,000 users from Clipsa and in Brazil, protecting more\r\nthan 13,000 users. In total, Avast protected more than 253,000 users more than 360,000 times, since August 1,\r\n2018. We protect all our users against Clipsa and all of its components.\r\nhttps://decoded.avast.io/janrubin/clipsa-multipurpose-password-stealer/\r\nPage 1 of 19\n\nMap illustrating the countries Clipsa has targeted from August 2018 – July 2019\r\nGraph illustrating Clipsa’s spread in time (hits)\r\nAnalysis\r\nClipsa uses a single executable binary with several parameters (command line arguments). The parameters\r\ndistinguish program phases which run as separate processes, simultaneously. Each phase focuses on a different\r\nfunctionality and is started by Clipsa’s initialization process, which does not have any parameters.\r\nClipsa uses these parameters for phases:\r\n1. No parameters\r\n2. --CLIPS\r\n3. --CLIPSS\r\n4. --WALLS\r\n5. --PARSE\r\n6. --BRUTE\r\nPhases 2-4 are designed to steal data from users, focusing on crypto-wallet related data. Phases 5 and 6 focus on\r\nfinding vulnerable WordPress websites and stealing their administrative credentials. We will focus on each of\r\nthese phases in the rest of this analysis.\r\nThe parameterless phase\r\nWhen the malware is run on an infected machine, the program intuitively starts without any parameters. This\r\nphase allows Clipsa to install and hide itself on the system. Then it continues by initializing other phases that\r\nperform malicious actions.\r\nPre-installation\r\nIn the pre-installation phase, Clipsa creates a message dialog box which makes it look like some kind of a setup\r\nprocess. However, this dialog box (see figure below) is actually just a disguise, so the user thinks the codec pack\r\nhttps://decoded.avast.io/janrubin/clipsa-multipurpose-password-stealer/\r\nPage 2 of 19\n\nthey downloaded is being installed. The truth is the dialog box only displays randomly generated numbers\r\n(incrementally summed) and prints the sum. Clipsa also adds a random sleep between increments, making the\r\nprocess look natural.\r\nFigure illustrating the setup progress as a disguise\r\nAfter the sum 99% is reached, the process closes the dialog. During the imaginary setup process, the malware\r\nperforms no malicious nor useful actions. We believe the purpose of this behavior is to delay the actual malicious\r\nprocess, thus avoiding detection in auto-sandboxing tools.\r\nAfter the imaginary setup is finished, Clipsa checks whether Task Manager is running using Windows\r\nManagement Instrumentation (WMI):\r\nSelect * from Win32_Process WHERE Name = 'taskmgr.exe'\r\nAnd if it is running, terminates the program to avoid user detection.\r\nInstallation\r\nClipsa then copies itself to the %APPDATA%\\Roaming directory. The specific folders and binaries are named\r\ndepending on the version of Clipsa. One of the newer versions copies itself to:\r\nC:\\Users\\user\\AppData\\Roaming\\AudioDG\\condlg.exe\r\nC:\\Users\\user\\AppData\\Roaming\\AudioDG\\zcondlg.exe\r\nSome older versions were located in:\r\nC:\\Users\\user\\AppData\\Roaming\\WinSys\\coresys.exe\r\nC:\\Users\\user\\AppData\\Roaming\\WinSys\\xcoresys.exe\r\nFrom now on, we will only consider the newer version which uses the AudioDG path, along with C\u0026C server\r\npoly.ufxtools[.]com . For further details about the other C\u0026C servers, see the C\u0026C servers section, below.\r\nDuring the installation process, additional directories and files are created as well:\r\nC:\\Users\\user\\AppData\\Roaming\\AudioDG\\log.dat\r\nC:\\Users\\user\\AppData\\Roaming\\AudioDG\\obj\\\r\nC:\\Users\\user\\AppData\\Roaming\\AudioDG\\udb\\\r\nAdditionally, the path to condlg.exe is added to registry autorun, assuring the malware’s persistence:\r\nHCU\\Software\\Microsoft\\Windows\\CurrentVersion\\Run\\11f86284\r\nThe registry key name 11f86284 is created from the first four bytes of a SHA-256 hash, which was computed\r\nfrom the H3c7K4c5:H3c7K4c5 hard coded string. Note that we will see the string H3c7K4c5 many times during\r\nthe analysis – mostly in the encryption functions.\r\nhttps://decoded.avast.io/janrubin/clipsa-multipurpose-password-stealer/\r\nPage 3 of 19\n\nFurthermore, a new process condlg.exe is created (without parameters), which serves as a dropper and also\r\nstarts other malicious phases. This process is, however, started from the hidden folder AudioDG and this is exactly\r\nhow Clipsa knows it is already installed on the system.\r\nLast but not least, the initial Clipsa process is doomed to end. Even when the entire Clipsa installation process is\r\nsuccessful, the malware displays an error message to the users, to make the users believe the codec installation\r\nfailed, making them think nothing was installed:\r\nFigure illustrating an invoked error message at the end of Clipsa’s successful installation\r\nThe condlg.dll file\r\nDuring the installation process, Clipsa checks for the presence of an additional file in the directory from which the\r\nuser executed the malware. This file is usually named 65923_VTS.vob or setup.dll . However, it is neither a\r\nmultimedia container nor a library. The file is an encrypted text file that is decrypted by Clipsa and it is saved to a\r\nnew file:\r\nC:\\Users\\user\\AppData\\Roaming\\AudioDG\\condlg.dll\r\nThe file holds several thousand Bitcoin addresses. As we will see later, this file will be used in the CLIPS phase\r\nduring which crypto-wallet addresses are replaced in the clipboard. However, its presence is optional and Clipsa is\r\nfully functional without it.\r\nNote that the names of the original files follow the assumption that Clipsa is served disguised as codec pack\r\ninstallers for media players.\r\nThe decryption process is very straightforward. Clipsa loads the file and XORs each byte with a current index in\r\nthe byte array modulo 0xFF:\r\nCoinmining\r\nOnce Clipsa is successfully installed on the system, it uses the process condlg.exe to harvest information about\r\nthe infected system (like OS version, serial number, username) and sends the information to the\r\nhttps://decoded.avast.io/janrubin/clipsa-multipurpose-password-stealer/\r\nPage 4 of 19\n\npoly.ufxtools[.]com file repository. This step also serves as a heartbeat, identifying whether the server is still\r\nalive. The actual data takes on this form:\r\nxxxxxxxx|PING|OS version|0|0|0|0|0|0|0|0\r\nwhere the first column is the first four bytes of a SHA-256 hash calculated from the drive’s (where the malware is\r\nlocated) serial number in the decadic form and username, creating a fingerprint for the user. The third column is\r\nan OS version in plaintext, followed by a sequence of numbers parsed from the AudioDG\\log.dat file (implicitly\r\nzeroes). More information about the log file can be found at the end of our analysis in the logging subsection.\r\nIf  poly.ufxtools[.]com is alive, the malware proceeds with downloading and executing an XMRig coinminer.\r\nThe download is performed using this request:\r\npoly.ufxtools[.]com/wp-content/plugins/WPSystem/dl.php?a=d\r\nand the file is named as the first four bytes of a SHA-256 hash calculated from a randomly generated floating\r\npoint number between 0-1 (rounded to 7 digits after the decimal point):\r\nC:\\Users\\user\\AppData\\Local\\Temp\\xxxxxxxx.exe\r\nThis coinminer uses several layers of obfuscation. At first, its Base64-encoded overlay is decoded, creating a new\r\nPowerShell script. This script decodes a GZIP file from another Base64-encoded string. This archive is unpacked\r\nand a slightly obfuscated final script is created. This final script then decodes a few additional Base64 strings and\r\none of them is the XMRig binary, which is executed afterwards.\r\nFiles 65923_VTS.asx and setup.bin\r\nLast but not least, Clipsa checks whether the user’s localization matches any of the locales in this hard coded list:\r\nARE,AUS,AUT,BEL,BGR,CAN,CHE,CHN,CYP,CZE,DEU,DNK,ESP,EST,FIN,FRA,GBR,GEO,HKG,HUN,\r\nIDN,IRL,ISR,ITA,JPN,KOR,LUX,LVA,MAC,MCO,MYS,NLD,NOR,NZL,PHL,POL,PRT,QAT,SAU,SGP,\r\nSVK,SVN,SWE,SWZ,THA,TUR,TWN,USA\r\nIf the user’s locale does not match any of the locales in the hard coded list, Clipsa attempts to find two additional\r\nfiles in the directory from which the malware was started:\r\n65923_VTS.asx\r\nsetup.bin\r\nIf one of these files is present, Clipsa copies it into the local temporary folder:\r\nC:\\Users\\user\\AppData\\Local\\Temp\\xxxxxxxx.exe\r\nwhere xxxxxxxx are four random bytes generated with the same random generator mentioned above in the\r\ncoinmining subsection. After the file is copied, it is executed as well. Note that only one of these files is expected\r\nto be found, because it is actually one file with two name variants. Clipsa doesn’t contain this file directly in its\r\nbinary. It is, however, very likely that some installers do contain this file and it is dropped along with Clipsa.\r\nDuring our analysis, we didn’t encounter this file bundled in Clipsa installers. We did, however, discover it\r\nthrough other sources.\r\nThe file 65923_VTS.asx is yet another coinminer. It mines the Monero cryptocurrency, sending the money to the\r\naddress:\r\n49Y3XrW9mPtAqVDmFjAWNXF5X8sEgTS23Sa6ZVvJwFEEMa5rG7Yt3zaDY2TKH1sfChjPkUqYpygyKNVy\r\nhttps://decoded.avast.io/janrubin/clipsa-multipurpose-password-stealer/\r\nPage 5 of 19\n\nhPguXU1f4WGFp2f\r\nin a pool:\r\npool.supportxmr[.]com\r\nThe miner uses several anti-debugging techniques, few obfuscations, and persistence actions. Some of the samples\r\nwe found were inside a crypter, too.\r\nTo mention some of the coinminer properties, the coinminer is always copied and renamed into a new location:\r\nC:\\Users\\user\\AppData\\Roaming\\Host\\svchost.exe\r\nimmediately after execution (thus, the file Temp\\xxxxxxxx.exe is truly temporary) and a new process is created\r\nfrom this location. This confuses the user to think the coinminer is a legitimate Windows process. Furthermore, it\r\nwrites autorun entries into registry and it also registers itself into Task Scheduler with a somewhat ironic name,\r\nusing the following command:\r\ncmd.exe /c SCHTASKS /Create /SC MINUTE /MO 2 /TN \"Microsoft Malware Protection\r\nCommand Line Utility\" /TR \"C:\\Users\\user\\AppData\\Roaming\\Host\\svchost.exe\"\r\nThe coinminer also uses multithreading, where one of the threads periodically checks the following list of active\r\nprocesses:\r\ntaskmgr.exe\r\nprocexp64.exe\r\nprocexp.exe\r\nprocesshacker.exe\r\nprocmon.exe\r\nwireshark.exe\r\nvnc.exe\r\nanvir.exe\r\nand these opened windows:\r\nProcess Hacker [%s\\%s]\r\nProcess Hacker [%s\\%s]+ (Administrator)\r\nProcess Explorer - Sysinternals: www.sysinternals.com [%s\\%s]\r\nwhere the strings %s are respectively:\r\n%USERNAME%\r\n%COMPUTERNAME%\r\nIf any of these windows or processes are found, the coinminer pauses its actions. This is done to persuade the user\r\nthat nothing is wrong with their computer.\r\nThe OK download\r\nAfter the coinminer is downloaded and executed, Clipsa downloads an additional file from the URL:\r\npoly.ufxtools[.]com/wp-content/plugins/WPSystem/ok.php\r\nto a path:\r\nC:\\Users\\user\\AppData\\Local\\Temp\\xxxxxxxx.log\r\nHowever, during our analysis, this URL was returning 0 bytes and we could not verify the purpose of the file\r\nbecause of this.\r\nhttps://decoded.avast.io/janrubin/clipsa-multipurpose-password-stealer/\r\nPage 6 of 19\n\nThe tsk.dat file\r\nAfter a heartbeat with information about the user’s system is returned, Clipsa performs a request:\r\npoly.ufxtools[.]com/wp-content/plugins/WPSystem/dl.php?a=i\r\nDuring our analysis, this request returned a string ogirejsorg584erg4sgef which represents a “task” from the\r\nC\u0026C server.\r\nThe task is saved to a new file:\r\nC:\\Users\\user\\AppData\\Roaming\\AudioDG\\tsk.dat\r\nThis file contains information about the C\u0026C from which the request was received and also the task. Both values\r\nare hashed using SHA-256 (only the first four bytes are used) and prefixed by hard coded letters P and T :\r\nPf66ef67b\r\nTf8ab7df4\r\nWhere f66ef67b is calculated from http[:]//poly.ufxtools[.]com (without safety brackets) and f8ab7df4\r\nis calculated from the task string ogirejsorg584erg4sgef .\r\nInitialization of phases\r\nAt this stage, Clipsa performs the initialization of phases which are started one by one. For this purpose, the\r\nbinary zcondlg.exe is used. Clipsa starts processes with these parameters, which run simultaneously:\r\nzcondlg.exe --CLIPS\r\nzcondlg.exe --CLIPSS\r\nzcondlg.exe --PARSE\r\nzcondlg.exe --BRUTE\r\nzcondlg.exe --WALLS\r\nAfter this initialization, the process condlg.exe is not terminated. Instead, it creates a new BRUTE process\r\nevery 10 seconds. These new processes are used as “brute-force workers” who take on new brute-force jobs and\r\ntry to gain administrative login credentials of WordPress websites (see the BRUTE phase for details).\r\nThe bool.scan file\r\nAfter the WALLS phase is started (parameter --WALLS ), a file bool.scan is created:\r\nC:\\Users\\user\\AppData\\Roaming\\AudioDG\\bool.scan\r\nThis file is empty and serves as a check whether this phase was started or not. This prevents Clipsa from\r\nrepeatedly scanning the entire disk for crypto-wallets.\r\nThe CLIPS phase\r\nThis phase is dedicated to modifying the user’s clipboard. The clipboard is continuously checked and validated if\r\nits contents match Bitcoin (BTC) or Ethereum (ETH) address formats. If an address in the correct format is found,\r\nClipsa replaces the address with the most similar BTC address from a predefined list. This serves as an easy way\r\nof stealing money from users when they, for example, copy and paste their own crypto-wallet address to a friend,\r\neffectively misleading the user to send money elsewhere.\r\nhttps://decoded.avast.io/janrubin/clipsa-multipurpose-password-stealer/\r\nPage 7 of 19\n\nReplacing wallet addresses\r\nBefore the actual replacement process begins, Clipsa checks the existence of a file\r\nC:\\Users\\user\\AppData\\Roaming\\AudioDG\\condlg.dll\r\nThis file, however, is a text file and we could see its decryption process in the condlg.dll file subsection. If the file\r\nexists, the malware reads its content and compares it with the BTC wallet address below:\r\n111u5Bbmz7gmaf2NXVyciTjCfdfqejzWm\r\nThis address is the first address in the condlg.dll file, thus Clipsa checks if the file contains valid content. If it\r\ndoes, Clipsa uses this huge list of addresses in the selection process.\r\nIf a valid Ethereum address is found instead in the clipboard, it is exclusively replaced by:\r\n0x4966DB520B0680fC19df5d7774cA96F42E6aBD4F\r\nThis means that no other ETH address is used and the selection process is omitted.\r\nDuring our analysis, the total amount of ETH received in this wallet was 55.059107 ETH (at the time of\r\npublishing this was ~12,632.76 USD). Note that since some funds could have come from other sources, the total\r\namount does not necessarily reflect the actual amount of cryptocurrencies stolen by Clipsa.\r\nIf the file condlg.dll is not found or it has different contents, Clipsa decrypts two different lists of BTC wallets.\r\nThese two lists are then concatenated, creating a list with 2,000 valid BTC addresses (see A.1 BTC addresses list\r\n(2000)). Details about received funds to the BTC addresses can be found in subsection received funds at the end\r\nof this analysis.\r\nFrom this list, the most similar address is selected and is used as a replacement if a valid BTC address is found in\r\nthe user’s clipboard.\r\nA complete list of available BTC addresses used by Clipsa can be found in A.2 BTC addresses list (complete).\r\nSelection process\r\nThe selection process is designed in two stages. In the first stage, the algorithm selects a sublist from the BTC\r\naddresses, depending on whether the original address starts with a number, 1 or 3. All the other addresses from the\r\nlist are omitted. Note that BTC addresses match this regular expression: [13][a-km-zA-HJ-NP-Z1-9]{25,34} .\r\nIn the second stage, a specific algorithm is used. It compares two BTC addresses (the original one and the selected\r\none from the sublist), calculating a similarity index SI which is a distance between the two strings. The\r\nsimilarity index changes depending on the compared bytes of both strings where the outer bytes have a greater\r\ninfluence on the similarity index and the middle one the lowest. The bytes are compared from both sides of the\r\naddresses.\r\nThis calculation can be represented by the equation listed below:\r\nhttps://decoded.avast.io/janrubin/clipsa-multipurpose-password-stealer/\r\nPage 8 of 19\n\nwhere n is a desired calculation length from the beginning of the string and from the end of the string, i is an\r\nindex in the string and v is a value representing a match strength:\r\nv=0 when the bytes match\r\nv=1 when the bytes match case insensitive\r\nv=2 when the bytes don’t match\r\nFrom this definition, we can see that the wallet with the lowest SI is selected from the sublist.\r\nLast but not least, note that Clipsa uses n=2 as a parameter for calculating the SI value, effectively checking\r\nonly the first two and last two bytes for similarity comparison. The selection process described above makes\r\nsense, because users are more likely to notice the change in the first and last n characters.\r\nSaving the result\r\nWhen the address in the clipboard is successfully replaced, Clipsa creates a new file:\r\nC:\\Users\\user\\AppData\\Roaming\\AudioDG\\rep.dat\r\nThis file contains encrypted information about what address was replaced by which address. This information is\r\nrepresented by the string in the following format:\r\npattern|original address|new address\r\nwhere pattern is a randomly selected string: 1,2 or 2,1 . However, if the wallet address is the ETH address,\r\npattern is set to a letter E . It is unclear why Clipsa chooses between the strings 1,2 and 2,1 . In our\r\nopinion, it would be sufficient to add, for example, a prefix B and omit the “obfuscation”.\r\nIn a later stage, the file rep.dat is then used in the CLIPSS phase as a log data which is sent to the C\u0026C server.\r\nString encryption\r\nAs mentioned above, the string saved in the rep.dat file is encrypted. Furthermore, almost all the strings found\r\nin the Clipsa binaries are encrypted as well. This encryption process is actually the same one the malware author\r\nused to obfuscate strings in Clipsa. Clipsa contains several types of custom encryption/decryption functions. This\r\nfunction, however, is the most prevalent.\r\nA custom encryption function is designed to achieve the string encryption. To explain the process properly, let’s\r\nfirst look at the decryption function in Python code below:\r\nhttps://decoded.avast.io/janrubin/clipsa-multipurpose-password-stealer/\r\nPage 9 of 19\n\nThe string encrypted is the input for this decryption function. Note that this string always contains only valid\r\nASCII values.\r\nThe encryption function has, however, a bit of a different approach. It takes the to-be-encrypted plaintext and\r\nconverts it to hexadecimal form. After that, it selects two random letters from the predefined alphabet:\r\nabcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789\r\nThese two bytes ( xx ) are then appended to the string H3c7K4c5xx and Clipsa tries to decrypt it. Consider it as a\r\nsingle step of the decrypt function listed above. If the desired output is equal to the plaintext, the two bytes are\r\nconsidered valid and they are saved as a ciphertext. This process repeats, as long as all bytes of the ciphertext are\r\ngenerated and can be correctly decrypted to plaintext. Thus, the whole process of encryption is not deterministic,\r\ni.e. one plaintext can be encrypted to multiple ciphertexts.\r\nFor example, let’s take the replacement of the hard coded Ethereum address to the same address, represented as\r\nthe string below:\r\nE|0x4966DB520B0680fC19df5d7774cA96F42E6aBD4F|0x4966DB520B0680fC19df5d7774cA96F42\r\nE6aBD4F\r\nThe encrypted output might look like this:\r\nIZZNRwqRnwWUdb56NoutldDWpJkJl4s6OCWOQV9Ur5Brz1ctf3GUm0SDjq52BuoxPRY4PB9hGDmu5lVc\r\nH6R0Ng0Qg4AFk2gT4xHSakkEtxrWXfBgnwnAllIruQlLGOJlt0LKLLIwgw3fjaSIng3losV8l4cfs6xq\r\nWgUwmPEDN7oSGG3NZSmLDHqlLFsKthuTJqpQD8kZN7meKeafK5SD0bHK48yuFcWuElwZldwuV3S6RM7A\r\nngcWOXSfy2bmvS4Sj9015auLkziW2uBJqs5t4XFUZAfmrUH04hsyUyDPKMBHH6pQTPAK3aS6bmcqxf1A\r\n9RTuLT5IWdlGS1oVq6QFfcUl3AKR\r\nThe CLIPSS phase\r\nThe CLIPSS phase is closely entangled with the CLIPS phase. It continually searches for the rep.dat file. When\r\nit is found, Clipsa decrypts its contents (see string encryption for details) and parses the values. If the file is not\r\nfound or has invalid (e.g. empty) content, the process sleeps for one second and then repeats.\r\nhttps://decoded.avast.io/janrubin/clipsa-multipurpose-password-stealer/\r\nPage 10 of 19\n\nAfter that, the malware creates a new string that contains five values separated by pipes:\r\nfingerprint|REPL|type|original address|replaced address\r\nWhere fingerprint is created as the first four bytes of a SHA-256 hash calculated from the user’s serial number\r\n(in decimal form) and computer name, type is a “type” of the address ( E for Ethereum or a random string\r\n1,2 or 2,1 for BTC). The original address and the replaced address represent the user’s and attacker’s\r\naddresses respectively.\r\nAfter this plaintext string is created, it is once again encrypted and Clipsa attempts to upload it to the\r\npoly.ufxtools[.]com C\u0026C server. After the upload is completed, the malware deletes the contents of the\r\nrep.dat file and repeats the entire process (i.e. waits for new content).\r\nThe WALLS phase\r\nThe WALLS phase is designed to find wallet.dat files on the disk (hence the name). Note that wallet.dat is\r\na typical filename for cryptocurrency wallets. Stealing this file effectively results in stealing money from this\r\nwallet. Furthermore, Clipsa also finds all text files ( *.txt ) which contain bip-39 patterns. If any such files are\r\npresent, they are encrypted by RC4 stream cipher and sent to the poly.ufxtools[.]com file repository.\r\nHowever, not all filesystem directories are searched. The malware recursively scans the whole filesystem,\r\nexcluding only a list of predefined locations (separated by pipes):\r\n\\AppData|\\Boot|\\PerfLogs|\\Program Files|\\Temporary|\\AMD\\|\\Dell\\|\\HP\\|\\Intel\\|\r\n\\McAfee\\|\\Norton\\|\\NortonInstaller\\|\\vim\\|Chrome|Drivers|Ebook|lessons|Lyrics|\r\nMicrosoft|Sample Music|Sample Pictures|savedIndexNames|TypingMaster|Windows|Games|\r\nHeroOnline|iTunes|FIFA|League|MineCraft|nDoors|SmileGate|Steam|TwelveSky|WarRock\r\nFile encryption (RC4)\r\nAs mentioned before, when the file of interest is found, Clipsa encrypts its contents. This is done by RC4 stream\r\ncipher.\r\nFirst of all, Clipsa hashes a hard coded string H3c7K4c5 using SHA-256 and uses the output as a key with a key\r\nlength of 32 bytes:\r\n4d7b290afaa14d86b4cf64fc5bcca8de99536196ee5a18f963d51f26d7956775\r\nThe rest of the cipher follows a typical RC4 implementation.\r\nSaving the result – wallet.dat\r\nAfter the content of the file is encrypted, two new files are created. The encrypted content is written into a file\r\nwith the extension .data.bin . The second file contains a plaintext path to the file whose contents were stolen\r\nand its extension is .path.bin . Furthermore, both files have a name created from two hashes, separated by a dot.\r\nThe first hash is created from the user’s fingerprint (see the CLIPSS phase for details). The second hash is\r\ncalculated from the absolute path to the stolen file – only the first two bytes are used:\r\nC:\\Users\\user\\AppData\\Roaming\\AudioDG\\xxxxxxxx.yyyy.data.bin\r\nC:\\Users\\user\\AppData\\Roaming\\AudioDG\\xxxxxxxx.yyyy.path.bin\r\nhttps://decoded.avast.io/janrubin/clipsa-multipurpose-password-stealer/\r\nPage 11 of 19\n\nClipsa then tries to upload these files to the poly.ufxtools[.]com C\u0026C server:\r\npoly.ufxtools[.]com/wp-content/plugins/WPSecurity/up.php\r\nSaving the result – text files\r\nAs previously mentioned, Clipsa also focuses on text files that contain words with specific patterns. These patterns\r\nform bip-39 mnemonic seed recovery phrases (or “mnemonic word sequences”) which are used as a seed for a\r\npseudo-random generator. If a user knows the seed, they can deterministically generate the same wallet keys that\r\nwere generated when the user first created their wallet. Thus, Clipsa in this phase actually focuses on stealing\r\nmnemonic word sequences to crack cryptocurrency wallets.\r\nSelecting the correct text files\r\nEven though each wallet.dat file is stolen, only text files with maximum length of 32,771 bytes are selected.\r\nFurthermore, after the contents of these text files are truncated and all redundant spaces are removed, the contents\r\nhave to match specific patterns from the list below:\r\n#WWWWWWWWWWWW#\r\n#WWWWWWWWWWWWN\r\nNWWWWWWWWWWWW#\r\nNWWWWWWWWWWWWN\r\n#NWNWNWNWNWNWNWNWNWNWNWNW#\r\n#NWNWNWNWNWNWNWNWNWNWNWNWN\r\nNNWNWNWNWNWNWNWNWNWNWNWNW#\r\nNNWNWNWNWNWNWNWNWNWNWNWNWN\r\nThese patterns are made up of letters. Each letter represents a word (string which is delimited by space (0x20)).\r\nThere are three types of letters:\r\nN – Number (decadic)\r\nW – Word from bip-39 word list\r\n# – Unknown word\r\nThus, every word from the text file is tested to check whether the word is in the bip-39 word list. This is done by\r\nmatching every word from the file content against a hard coded encrypted word list (see decryption of word list\r\n(bip-39) below). If a word matches, the character # , N , or W is appended to a new pattern. After the new\r\npattern is finished and if it matches any of the patterns listed above, the file is copied, its contents encrypted, and\r\nuploaded.\r\nSaving text files on disk\r\nSaving the selected text files is very similar to the stolen wallet.dat files. Instead of using the extension .bin ,\r\nan extension .txt is used:\r\nC:\\Users\\user\\AppData\\Roaming\\AudioDG\\xxxxxxxx.yyyy.data.txt\r\nC:\\Users\\user\\AppData\\Roaming\\AudioDG\\xxxxxxxx.yyyy.path.txt\r\nNote that after the files are successfully uploaded, they are then deleted from this location.\r\nhttps://decoded.avast.io/janrubin/clipsa-multipurpose-password-stealer/\r\nPage 12 of 19\n\nDecryption of word list (bip-39)\r\nThe decryption process of the word list is very straightforward. The cipher is a simple substitution which uses a\r\nlookup table and a ciphertext.\r\nFor the word list, this lookup table is given:\r\nJyBhjP0OSI3qVQn!U4ZlvK5zsfDEdgTRx%XaF|br6YA1u87Li2mpkWNtecoGCwM9H\r\nwhile using this alphabet:\r\n0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ|!%\r\nHere is a decryption of the beginning of the ciphertext (truncated) to plaintext:\r\n3q3zQszM3qZKZgXM3qKnM3qsTgM3qsRnM\r\nabandon|ability|able|about|above|\r\nFor the whole word list in plaintext, see B.1 Word list (bip-39).\r\nNote that this list exactly matches the bip-39 word list for generating mnemonic phrases for crypto wallets.\r\nThe PARSE phase\r\nIn the PARSE phase, Clipsa decrypts a hard coded word list. From this list, it selects particular keywords which\r\nare used by Google and Bing search engines. Every site from the search engine results page is parsed and saved\r\ninto separate files on the disk in obfuscated representation.\r\nKeywords selection\r\nBefore the random selection of the keywords begins, Clipsa uses a hard coded string:\r\nw1|w2|w1 w2|w2 w1|w1 and w2|w1 at w2|w1 but w2|w1 else w2|w1 for w2|w1 if w2|\r\nw1 in w2|w1 of w2|w1 or w2|w1 with w2\r\nWe can look at this string as a list of patterns (separated by pipes) which is used for searching in search engines. A\r\nrandom pattern from this string is selected. The words w1 and w2 are then replaced by randomly selected words\r\nfrom the word list. Thus, even though both w1 and w2 are selected, the malware can skip one of them\r\n(depending on the used pattern).\r\nParsing\r\nWhen the keyword pattern is selected, it is inserted into Google search:\r\nhttps://www.google.com/search?q=PATTERN\u0026start=0\u0026num=100\r\nwhere PATTERN could, for example, be abandon in above .\r\nIf the Google search request is unsuccessful, the malware tries an additional request using Bing:\r\nhttps://www.bing.com/search?q=PATTERN\u0026first=0\u0026count=50\r\nIf a valid response is received, Clipsa parses all URLs present in all \u003ccite\u003e HTML tags and simplifies them by\r\nremoving http , https , \u003cstrong\u003e tags, and any text after the domain name. Furthermore, the malware hashes\r\nthe URLs using SHA-256 and creates a new directory structure in the AudioDG\\udb\\ folder. It takes the first two\r\nbytes from the calculated hash for a folder name and a file name (hexadecimal):\r\nhttps://decoded.avast.io/janrubin/clipsa-multipurpose-password-stealer/\r\nPage 13 of 19\n\nAudioDG\\udb\\xx\\xx.dat\r\nand the file xx.dat contains additional two bytes of the hash. This way, Clipsa knows which URLs were parsed\r\nand it omits any duplicities found on the search result page.\r\nAll these unique URLs are then continually visited by new requests:\r\nhttp(s)://website.example/xmlrpc.php\r\nIf the xmlrpc.php file is accessible on the WordPress server, the page returns:\r\nXML-RPC server accepts POST requests only\r\nand Clipsa tries to access\r\nhttp(s)://website.example/wp-login.php\r\nas well, attempting to confirm that it is indeed a WordPress server with a login page.\r\nAt this point, Clipsa attempts to get the WordPress site’s admin username. To achieve this, the malware executes a\r\nsimple HTTP request for user enumeration (exploiting a weak configuration of the WordPress site):\r\nhttp(s)://website.example/?author=1\r\nwhich will often redirect the URL to:\r\nhttp(s)://website.example/author/admin/\r\nwhere admin is the first username on the WordPress server, which is usually the admin’s username (ID=1). Note\r\nthat it usually matches admin literally, too…\r\nHowever, Clipsa does not extract information from the new URL, but it instead parses the redirected site contents\r\nand searches for the following pattern:\r\nhref=\"http(s)://website.example/author/admin/feed/\"\r\nwhere the admin is extracted.\r\nIf Clipsa successfully retrieves the admin’s username, the whole PARSE phase is considered successful and the\r\nmalware creates an additional file in the AudioDG\\obj\\ subdirectory. The file is named using the first four bytes\r\nof the SHA-256 hash calculated from the URL address and it serves as a log file and a “brute-force job” for the\r\nBRUTE phase. The file contains four values separated by pipes and we will refer to it as the URL file for\r\nsimplicity:\r\nwww.website.example|admin’s name|0|0\r\nAs we will see later in the BRUTE phase, the last two columns are actually the “number of brute-force attempts”\r\nand an “epoch time from the last brute-force attempt”, respectively.\r\nThe BRUTE phase\r\nThe BRUTE phase serves a single purpose: Brute-force its way into the administrative privileges of the WordPress\r\nwebsite and send brute-forced credentials to the poly.ufxtools[.]com file repository.\r\nHowever, it is strictly bound to the PARSE phase, because it uses the URL file created at the end of its last\r\nsuccessful run. Note that a new process ( --BRUTE ) is created every 10 seconds, effectively parallelizing the\r\nbrute-force process.\r\nParsing the URL file and login credentials\r\nhttps://decoded.avast.io/janrubin/clipsa-multipurpose-password-stealer/\r\nPage 14 of 19\n\nClipsa selects a random URL file from the \\obj\\ subdirectory. This file also has to have a timestamp (the last\r\ncolumn in the file) lower than the present date. Clipsa then parses the file, retrieving the to-be-brute-forced URL\r\nand admin’s username.\r\nAfter the admin’s username is retrieved, Clipsa uses three additional values as usernames:\r\n%domain%\r\nadmin\r\ntest\r\nwhere %domain% is replaced with the current to-be-brute-forced domain. The rest of the strings are hard coded\r\n(and they match common usernames).\r\nMoreover, the malware decrypts a list of frequently used passwords. It uses a simple substitution cipher (which\r\nactually uses the same lookup table as in the WALLS phase) to retrieve the list. For the full list of passwords in\r\nplaintext, see C.1 Passwords list in the appendix.\r\nHowever, this password list is not complete. As we can see, the list starts with these two columns:\r\n!|%domain%\r\nThe first column (exclamation mark) is replaced with the admin’s username and %domain% is replaced with the\r\ncurrent to-be-brute-forced domain. The rest of the password list is kept as is.\r\nBrute-forcing\r\nBefore the brute-forcing begins, Clipsa increases the penultimate number in the URL file by one (number of\r\nbrute-force attempts) and replaces the last number by the current timestamp (from epoch), indicating a new brute-force attempt.\r\nAfter all these preparations are finished, Clipsa begins to brute-force. First, it creates a XML-RPC request for the\r\nxmlrpc.php file:\r\n\u003cmethodCall\u003e\r\n\u003cmethodName\u003ewp.getUsersBlogs\u003c/methodName\u003e\r\n\u003cparams\u003e\r\n\u003cparam\u003e\r\n\u003cvalue\u003e\r\n\u003cstring\u003eadmin\u003c/string\u003e\r\n\u003c/value\u003e\r\n\u003c/param\u003e\r\n\u003cparam\u003e\r\n\u003cvalue\u003e\r\n\u003cstring\u003epassword\u003c/string\u003e\r\n\u003c/value\u003e\r\n\u003c/param\u003e\r\n\u003c/params\u003e\r\n\u003c/methodCall\u003e\r\nhttps://decoded.avast.io/janrubin/clipsa-multipurpose-password-stealer/\r\nPage 15 of 19\n\nwhere admin and password are filled in according to the selected username and the selected password (from\r\nthe list).\r\nIf the attempt to retrieve the UserBlogs is successful, the response should contain a string isAdmin . If XML-RPC is enabled and poorly configured, an attacker can use the request above to obtain the response with the\r\nconfirmation of the credentials. With the verbose response, Clipsa knows the credentials are valid and the brute-forcing is successful. If not, the next password is selected and Clipsa tries again.\r\nWhen Clipsa successfully brute-forces its way into a WordPress admin account, it creates a string with all the\r\ninformation it obtained in the process:\r\nfingerprint|GOOD|www.website.example|admin’s username|password\r\nThis string is then encrypted and uploaded to the poly.ufxtools[.]com file repository.\r\nLogging\r\nAs we marginally mentioned in the beginning of the analysis, Clipsa creates and uses an additional file:\r\nC:\\Users\\user\\AppData\\Roaming\\AudioDG\\log.dat\r\nThis file is used for logging purposes, which the malware author can use to debug Clipsa and obtain statistics.\r\nThe file contains eight columns, separated by pipes. Each column holds a different piece of information. At the\r\nbeginning, when the file is created, it is empty, meaning all the columns are filled with zeros:\r\n0|0|0|0|0|0|0|0\r\nA curious observer could find out that the file is actually created with 10 columns (all zeros). However, these\r\nadditional columns are removed after the first write into the log.\r\nThis file is then continually filled after each successful functionality iteration. Depending on the phase in which\r\nthe functionality is located, the specific column is modified. In the table below, we present which phase affects\r\nwhich column(s):\r\nNow, let’s break down what these numbers mean, exactly, based on Clipsa phases, which we explained earlier:\r\n1. Number of parsed URLs\r\n2. Number of XML-RPC requests (a check whether the site is a WordPress site or not)\r\n3. Number of author requests (attempts to retrieve the admin’s username)\r\n4. Number of brute-force tries\r\n5. Number of successfully brute-forced sites (obtained administrative credentials)\r\n6. Current count of files in \\obj directory\r\n7. Number of replaced crypto-wallet addresses\r\n8. Number of stolen wallet.dat files or .txt files with mnemonic phrases\r\nhttps://decoded.avast.io/janrubin/clipsa-multipurpose-password-stealer/\r\nPage 16 of 19\n\nNote that the contents of the log.dat file are sent to the C\u0026C server with every heartbeat,  which is performed\r\nafter Clipsa is started (and after the successful installation).\r\nReceived funds\r\nIn this subsection, we will present a brief overview of the amount of money received in all the BTC addresses\r\navailable in Clipsa. The list contains 9,412 addresses in total (including the 65923_VTS.vob file, alias\r\ncondlg.dll ) and can be found in the A.2 BTC addresses list (complete).\r\nHowever, until our analysis, only 117 of all the addresses received funds. We will stick to these addresses here.\r\nFor a complete list of addresses sorted by received amounts, see A.3 BTC addresses list (sorted amounts).\r\nDuring our analysis, a maximum of 0.3511 BTC (which at the time of publishing was ~4,111.70 USD) was\r\nreceived at the address 1HKbDo1PeKPDcRzxCinvahTpusbHywEK3o in just one transaction. The minimum value\r\nreceived was 0.00001 BTC (which at the time of publishing was ~0.12 USD) at the addresses\r\n1BY59mYV1nqmkcUjbVPA4mzK52CuPipn2N and 13DmqnVDh9EwKoJdGCjkad4ZNQUKwiTnAV .\r\nIn the figure below, we illustrate the amounts of the top BTC addresses:\r\nFigure illustrating received BTC funds – top 117 addresses (sorted)\r\nFurthermore, we can see that only a few addresses received larger amounts of BTC. This is  illustrated in the\r\nhistogram below:\r\nhttps://decoded.avast.io/janrubin/clipsa-multipurpose-password-stealer/\r\nPage 17 of 19\n\nHistogram illustrating a distribution of wallets depending on received funds\r\nNow, let’s see how the money got to these crypto-wallets from August 2018, to July 2019. We listed all the\r\nincoming transactions to all of the 117 addresses and summarized the values. We didn’t find any direct income\r\nloops that would make the following graph inaccurate.\r\nFigure illustrating the received BTC funds – top 117 addresses (over time)\r\nC\u0026C servers\r\nDuring this analysis, we described only one C\u0026C server:\r\npoly.ufxtools[.]com\r\nThis approach was to simplify the description of how Clipsa works. The selection of the C\u0026C addresses is\r\nactually done by reading multiple hard coded addresses from the memory,  but of the several addresses only one or\r\nvery few of them is the C\u0026C server address. Each of these addresses is visited, and if the server responds\r\ncorrectly, Clipsa knows it is the C\u0026C. For example, the entire list of addresses in the analysed Clipsa sample is:\r\npoly.ufxtools[.]com\r\nindustriatempo.com[.]br\r\nrobertholeon[.]com\r\ndeluxesingles[.]com\r\nnaijafacemodel[.]com\r\nwww.quanttum[.]trade\r\nwww.blinov-house[.]ru\r\nssgoldtravel[.]com\r\nwww.greenbrands[.]ir\r\nnew.datance[.]com\r\nFurthermore, these sites are randomly permuted before every server interaction (e.g. an upload of stolen files).\r\nThis is performed to obfuscate the network communication by randomness and non-malicious requests/responses.\r\nMoreover, the list of addresses above is only an example. Nearly every Clipsa sample carries a different set of\r\naddresses that sometimes contain completely different C\u0026C addresses.\r\nhttps://decoded.avast.io/janrubin/clipsa-multipurpose-password-stealer/\r\nPage 18 of 19\n\nWithout further ado, here is a full list of active C\u0026C servers that we encountered during our analysis:\r\nhttp[:]//besttipsfor[.]com\r\nhttp[:]//chila[.]store\r\nhttp[:]//globaleventscrc[.]com\r\nhttp[:]//ionix.co[.]id\r\nhttp[:]//mahmya[.]com\r\nhttp[:]//mohanchandran[.]com\r\nhttp[:]//mutolarahsap[.]com\r\nhttp[:]//northkabbadi[.]com\r\nhttp[:]//poly.ufxtools[.]com\r\nhttp[:]//raiz[.]ec\r\nhttp[:]//rhsgroup[.]ma\r\nhttp[:]//robinhurtnamibia[.]com\r\nhttp[:]//sloneczna10tka[.]pl\r\nhttp[:]//stepinwatchcenter[.]se\r\nhttp[:]//topfinsignals[.]com\r\nhttp[:]//tripindiabycar[.]com\r\nhttp[:]//videotroisquart[.]net\r\nhttp[:]//wbbministries[.]org\r\nIndicators of Compromise (IoC)\r\nThreat Research Team\r\nThreat Research Team\r\nA group of elite researchers who like to stay under the radar.\r\nSource: https://decoded.avast.io/janrubin/clipsa-multipurpose-password-stealer/\r\nhttps://decoded.avast.io/janrubin/clipsa-multipurpose-password-stealer/\r\nPage 19 of 19",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://decoded.avast.io/janrubin/clipsa-multipurpose-password-stealer/"
	],
	"report_names": [
		"clipsa-multipurpose-password-stealer"
	],
	"threat_actors": [
		{
			"id": "b740943a-da51-4133-855b-df29822531ea",
			"created_at": "2022-10-25T15:50:23.604126Z",
			"updated_at": "2026-04-10T02:00:05.259593Z",
			"deleted_at": null,
			"main_name": "Equation",
			"aliases": [
				"Equation"
			],
			"source_name": "MITRE:Equation",
			"tools": null,
			"source_id": "MITRE",
			"reports": null
		}
	],
	"ts_created_at": 1775434761,
	"ts_updated_at": 1775826715,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/2d5b0f6f8042eb5b195ba7843b5e12a7e941f886.pdf",
		"text": "https://archive.orkl.eu/2d5b0f6f8042eb5b195ba7843b5e12a7e941f886.txt",
		"img": "https://archive.orkl.eu/2d5b0f6f8042eb5b195ba7843b5e12a7e941f886.jpg"
	}
}