{
	"id": "cc232b7d-6c5f-4b35-8e0f-17555a7e502a",
	"created_at": "2026-04-06T00:12:16.4869Z",
	"updated_at": "2026-04-10T13:12:36.187385Z",
	"deleted_at": null,
	"sha1_hash": "666ea9931359d1c5d1dbe74a4164e48f75429cf4",
	"title": "FrostyGoop’s Zoom-In: A Closer Look into the Malware Artifacts, Behaviors and Network Communications",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 8266605,
	"plain_text": "FrostyGoop’s Zoom-In: A Closer Look into the Malware Artifacts,\r\nBehaviors and Network Communications\r\nBy Asher Davila, Chris Navarrete\r\nPublished: 2024-11-19 · Archived: 2026-04-05 12:43:00 UTC\r\nExecutive Summary\r\nIn July 2024, the operational technology (OT)-centric malware FrostyGoop/BUSTLEBERM became publicly\r\nknown, after attackers used it to disrupt critical infrastructure. The outage occurred after the Cyber Security\r\nSituation Center (CSSC), affiliated with the Security Service of Ukraine, disclosed details [PDF] of an attack on a\r\nmunicipal energy company in Ukraine in early 2024.\r\nFrostyGoop is the ninth reported OT-centric malware, but the first that used Modbus TCP communications to\r\nimpact the power supply to heating services for over 600 apartment buildings. FrostyGoop can be used both\r\nwithin a compromised perimeter and externally if the target device is accessible over the internet. FrostyGoop\r\nsends Modbus commands to read or modify data on industrial control systems (ICS) devices, causing damage to\r\nthe environment where attackers installed it.\r\nBased on this reporting, we conducted a deeper analysis and uncovered new samples of FrostyGoop and other\r\nrelated indicators. These new indicators include configuration files and libraries used by the malware, as well as\r\nartifacts associated with an infection. We also investigate network communications and provide new insights\r\nbased on open-source intelligence (OSINT) data and our own telemetry.\r\nOT malware is an increasing concern of security professionals across the globe, and FrostyGoop provides a\r\nnotable case study of this growing threat.\r\nPalo Alto Networks customers are better protected from the threats discussed in this article through our products\r\nand services such as the following:\r\nIndustrial OT Security\r\nInformation provided by Palo Alto Networks Next-Generation Firewall with Advanced Threat Prevention\r\nAdvanced WildFire\r\nCortex Xpanse\r\nCortex XDR and Cortex XSIAM\r\nPrisma Cloud\r\nIf you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response\r\nteam.\r\nTechnical Analysis of FrostyGoop\r\nhttps://unit42.paloaltonetworks.com/frostygoop-malware-analysis/\r\nPage 1 of 21\n\nAttackers employed this malware associated with Russian actors in a cyberattack that caused a two-day heating\r\nsystem outage affecting over 600 apartment buildings in Ukraine, during sub-zero temperatures.\r\nAccording to an open-source report, attackers made the initial compromise through a vulnerability in a MikroTik\r\nrouter. However, we have not confirmed this delivery method and bad actors might instead have delivered the\r\nmalware via OT devices exposed to the internet.\r\nFrostyGoop makes use of the Modbus TCP protocol to interact directly with ICS/OT devices, and therefore it is\r\nconsidered an ICS-centric malware. This is the ninth known ICS-centric malware.\r\nIn addition, Modbus is one of the most common protocols used in critical infrastructure. During this attack, the\r\nadversaries dispatched Modbus commands to ENCO control devices, leading to inaccurate measurements and\r\nsystem malfunctions. Remediating these issues took nearly two days.\r\nAlthough bad actors used the malware to attack ENCO control devices, the malware can attack any other type of\r\ndevice that speaks Modbus TCP. Our telemetry indicates that 1,088,175 Modbus TCP devices were exposed to the\r\ninternet from Sept. 2-Oct. 2, 2024, and 6,211,623 devices were exposed overall.\r\nThe details needed by FrostyGoop to establish a Modbus TCP connection and send Modbus commands to a\r\ntargeted ICS device can be provided as command-line arguments or included in a separate JSON configuration\r\nfile.\r\nMalware Samples Analysis\r\nFrostyGoop is compiled using the Go programming language, sometimes referred to as Golang. The malware uses\r\na relatively obscure open-source Modbus implementation.\r\nFurther analysis of the Modbus library revealed this implementation does not natively support supplying\r\narguments using a JSON file, making this a strong identifier for the malware. Moreover, the JSON object structure\r\nfollows a specific format based on the commands this malware supports. FrostyGoop also contains capabilities for\r\nlogging the output to a console or to a JSON file.\r\nAttackers can supply two types of parameters to FrostyGoop:\r\nThe first type of parameter consists of the possible operations an attacker can execute toward the registers\r\nof a Modbus device\r\nThe second parameter consists of timing configurations.\r\nFigure 1 shows an example of the first type of parameter for an operation using Tasks and Iplist under the register\r\nfor main::main.TaskList___runtime.structtype_fields.\r\nhttps://unit42.paloaltonetworks.com/frostygoop-malware-analysis/\r\nPage 2 of 21\n\nFigure 1. Binary Ninja showing FrostyGoop operations for Tasks and Iplist under the\r\nmain::main.TaskList___runtime.structtype_fields register.\r\nFigure 2 shows an example of an operation for Code, Address, Count, Value and State under the register for\r\nmain::main.TaskList___runtime.structtype_fields.\r\nhttps://unit42.paloaltonetworks.com/frostygoop-malware-analysis/\r\nPage 3 of 21\n\nFigure 2. Binary Ninja showing FrostyGoop operations for Code, Address, Count, Value and State\r\nunder the main::main.TaskList___runtime.structtype_fields register.\r\nFigure 3 shows the timing configuration for main.Cycle.getCycleConfig.\r\nFigure 3. Binary Ninja showing FrostyGoop timing configuration in the registry entry under\r\nmain.Cycle.getCycleConfig(main.Cycle x,main.Cmd cmd).\r\nhttps://unit42.paloaltonetworks.com/frostygoop-malware-analysis/\r\nPage 4 of 21\n\nFrostyGoop also leverages Goccy’s go-json library, a faster JSON encoder and decoder compatible with the Go\r\nprogramming language standard encoding/json package. In addition, it incorporates a specific open-source\r\nexecution controller named queues. The relative obscurity of this code means it can serve as another possible\r\nindicator of FrostyGoop.\r\nFigure 4 shows our analysis of a Windows executable file for FrostyGoop within the tool Binary Ninja. This\r\nanalysis reveals URLs from open-source libraries for modbus, go-json and queues.\r\nFigure 4. Open-source libraries: Modbus, go-json and queues.\r\nAlthough not all FrostyGoop samples contain the strings shown in Figure 4, other strings contained within those\r\nlibraries can serve as part of the detection for this malware.\r\nFrostyGoop also implements a debugger evasion technique by checking the BeingDebugged value in Windows'\r\nProcess Environment Block (PEB). Figure 5 shows this method in the disassembled code from a FrostyGoop\r\nsample. This method provides an alternative way to check the PEB's BeingDebugged flag without calling\r\nIsDebuggerPresent(). Attackers use this technique to detect and avoid debuggers used by malware analysts.\r\nFigure 5. Disassembled code from a FrostyGoop sample showing a check for the PEB's\r\nBeingDebugged flag.\r\nGo-encrypt.exe Sample Analysis\r\nhttps://unit42.paloaltonetworks.com/frostygoop-malware-analysis/\r\nPage 5 of 21\n\nOur investigation revealed a Windows executable sample named go-encrypt.exe written in Go that was not\r\nFrostyGoop, but it originally appeared on the same approximate date that other indicators of FrostyGoop were\r\nreported. Command-line options for this software reveal the file is used to encrypt and decrypt JSON files as\r\nillustrated in Figure 6.\r\nFigure 6. Command-line options for go-encrypt.exe.\r\nAfter executing go-encrypt.exe using the -encrypt argument, it creates two files:\r\nAn encrypted JSON\r\nA 32-byte file containing a decryption key named key\r\nFigure 7 shows the encryption, decryption and the generated key.\r\nFigure 7. Using go-encrypt.exe to encrypt and decrypt a JSON file.\r\nhttps://unit42.paloaltonetworks.com/frostygoop-malware-analysis/\r\nPage 6 of 21\n\nFigure 8 shows the content of an encrypted JSON file generated by go-encrypt.exe.\r\nFigure 8. An encrypted JSON file viewed in a hex editor.\r\nFigure 9 shows a filtered list of processes generated by go-encrypt.exe in Process Monitor. We have highlighted\r\nwhen go-encrypt.exe created the decryption file named key and the 32 character content of this key file.\r\nhttps://unit42.paloaltonetworks.com/frostygoop-malware-analysis/\r\nPage 7 of 21\n\nFigure 9. Process Monitor showing go-encrypt.exe generating the key file.\r\nDecompiling go-encrypt.exe revealed it uses the Cipher Feedback (CFB) mode of the AES encryption algorithm\r\nto create the encryption/decryption key in the key file as shown in Figures 10 and 11.\r\nFigure 10. Decompiled code of go-encrypt.exe showing its AES main encryption routine.\r\nhttps://unit42.paloaltonetworks.com/frostygoop-malware-analysis/\r\nPage 8 of 21\n\nFigure 11. Decompiled code of go-encrypt.exe showing CFB mode.\r\nAs shown previously for the key generated in Figure 7, the key value is in decimal format. The decimal value of\r\nthe key from Figure 7 is:\r\n71 76 90 67 120 104 86 98 85 97 88 54 88 50 75 77 71 78 116 89 74 66 51 50 75 103 70 117 56 100 117\r\n88\r\nWe can decode these decimal numbers into the 32-byte value of the key through a variety of methods, like the\r\nPython script shown in Figure 12. This script will convert the binary values to hexadecimal.\r\nFigure 12. Example of a Python script to convert the decimal value of the key to hexadecimal.\r\nThe 32-byte value of the key in hexadecimal is:\r\nhttps://unit42.paloaltonetworks.com/frostygoop-malware-analysis/\r\nPage 9 of 21\n\n47 4c 5a 43 78 68 56 62 55 61 58 36 58 32 4b 4d 47 4e 74 59 4a 42 33 32 4b 67 46 75 38 64 75 58\r\nAccording to Go’s documentation for aes.NewCipher, a byte stream of 32 bytes corresponds to a 256-bit AES\r\nencryption in CFBmode. We confirmed the 32-byte hexadecimal value of the key from our example matches the\r\nASCII value in the key file using CyberChef as shown below in Figure 13.\r\nFigure 13. Using CyberChef to verify the hex value matches the ASCII value of the key file.\r\nAlthough we cannot confirm go-encrypt.exe was used for the FrostyGoop attack, two circumstances indicate the\r\nattackers might have used it during this activity:\r\nFirst, it is used to encrypt and decrypt JSON files, and encrypted JSON files are an essential element of\r\nFrostyGoop functionality.\r\nSecond, go-encrypt.exe first appeared in the wild around the same time as the FrostyGoop samples and the\r\ntask_test.json file.\r\nTherefore, attackers could have used this piece of software to conceal target information in JSON files for later\r\nuse to perpetrate attacks.\r\nInvestigation of the Targeted Infrastructure\r\nAccording to the Dragos report on FrostyGoop, they initially discovered this malware in April 2024. This report\r\nnotes an example of a FrostyGoop configuration file named task_test.json.\r\nSearching VirusTotal, we found one occurrence of task_test.json on Oct. 10, 2023. Pivoting on that file, we\r\ndiscovered Windows executable files that we subsequently identified as FrostyGoop and go-encrypt.exe.\r\nFigure 14 shows the same first-seen date of Oct. 10, 2023, for task_test.json, go-encrypt.exe and the other\r\nWindows executable files.\r\nhttps://unit42.paloaltonetworks.com/frostygoop-malware-analysis/\r\nPage 10 of 21\n\nFigure 14. Malware samples and task_test.json detection timestamps in VirusTotal.\r\nThe data structure of task_test.json and its key/values are the format we would expect to be used as a\r\nconfiguration file by a FrostyGoop executable file. Our analysis of FrostyGoop samples indicates the malware\r\nperforms read, write and write-multiple Modbus operations. The content of the task_test.json sample depicted in\r\nFigure 15 only shows read operations (Code 3).\r\nhttps://unit42.paloaltonetworks.com/frostygoop-malware-analysis/\r\nPage 11 of 21\n\nFigure 15. The content of task_test.json used by a FrostyGoop malware sample.\r\nThe IP address contained in this JSON file corresponds to an ENCO control device located in Romania as noted.\r\nhttps://unit42.paloaltonetworks.com/frostygoop-malware-analysis/\r\nPage 12 of 21\n\nFigure 16. Xpanse query indicating it is an ENCO device in Romania.\r\nWidening our search for exposed ENCO devices, our telemetry revealed 32 IP addresses, all located in either\r\nRomania or Ukraine as noted in Figure 17.\r\nhttps://unit42.paloaltonetworks.com/frostygoop-malware-analysis/\r\nPage 13 of 21\n\nFigure 17. Xpanse query of IP addresses with exposed ENCO devices.\r\nThe ENCO devices we discovered all have TCP port 23 exposed for Telnet. Telnet provides a communications and\r\nmanagement interface that is considered obsolete because it has no built-in encryption.\r\nSimply connecting to an exposed ENCO device over Telnet reveals an ENCO banner with a list of available\r\ncommands as shown below in Figure 18. This provides a reportedly easy method to probe for and identify ENCO\r\nprogrammable logic controller (PLC) devices on the internet.\r\nhttps://unit42.paloaltonetworks.com/frostygoop-malware-analysis/\r\nPage 14 of 21\n\nFigure 18. Telnet banner from an exposed ENCO device.\r\nFigure 19 shows a portion of our Xpanse report covering details of the network services running on the server\r\nlisted in task_test.json. This matches the exposed ports among the other ENCO exposed devices we discovered:\r\nTCP ports 23 (Telnet)\r\n502 (Modbus)\r\n1024 (Router WebUI)\r\n37777 (ENCO connect port)\r\nhttps://unit42.paloaltonetworks.com/frostygoop-malware-analysis/\r\nPage 15 of 21\n\nFigure 19. Xpanse report for open ports on.\r\nWe can glean further information on the ENCO device by accessing it using a web browser and recording the\r\ntraffic. Figure 20 shows a login screen shown when accessing the ENCO device from a web browser. By viewing\r\nthe web traffic in Wireshark and examining the HTTP response headers, we find the router is being used as a web\r\nserver and the name of the router is TP-LINK Wireless Lite N Router WR740N.\r\nhttps://unit42.paloaltonetworks.com/frostygoop-malware-analysis/\r\nPage 16 of 21\n\nFigure 20. Information gleaned from accessing an ENCO device over a web browser.\r\nAccording to the NIST website, versions 1 and 2 of the WR740N router's firmware are susceptible to a command\r\ninjection vulnerability. However, there is no hard evidence to indicate that the attackers exploited this vulnerability\r\nin the July 2024 FrostyGoop attack.\r\nNetwork Traffic Analysis\r\nTo analyze FrostyGoop traffic, we tested two samples using task_test.json as the configuration file. The two\r\nFrostyGoop samples have the following SHA256 hashes:\r\n5d2e4fd08f81e3b2eb2f3eaae16eb32ae02e760afc36fa17f4649322f6da53fb\r\na63ba88ad869085f1625729708ba65e87f5b37d7be9153b3db1a1b0e3fed309c\r\nThe task_test.json configuration file only has a function code value of 3, which represents a Modbus command to\r\nread the holding registers. Accordingly, the FrostyGoop samples only generated commands to read the holding\r\nregisters of the targeted device at over TCP port 502.\r\nFigure 21 shows an example of the Modbus traffic generated during our test of the FrostyGoop samples, filtered in\r\nWireshark with a customized column display. It reveals Modbus traffic to over TCP port 502, as well as the four\r\nregister values specified in the task_test.json configuration file:\r\n53370\r\n53882\r\nhttps://unit42.paloaltonetworks.com/frostygoop-malware-analysis/\r\nPage 17 of 21\n\n53760\r\n54272\r\nFigure 21. Example of Modbus traffic from our FrostyGoop sample test filtered in Wireshark.\r\nFigure 22 shows an example of a Modbus function code 3 request to read values from the holding registers of the\r\nENCO device, starting with the register number 53760 for the next 123 registries. The device responded with\r\nvalues from registry 53760-53882. These registry entries hold UINT16 values for unsigned integers that can range\r\nfrom 0-65535.\r\nFigure 22. Modbus interaction with the hardware device.\r\nWe reverse engineered the samples to track down their functions. Our analysis revealed that the taskWorker\r\nfunction selects actions performed through the following function parameters:\r\nread holding registers (3)\r\nwrite (6)\r\nwriteMultiple (6)\r\nIf the JSON configuration file contains the number 1 as a word count value, only one register is returned. If it does\r\nnot contain the number 1 as a word count value, more than one register is returned.\r\nhttps://unit42.paloaltonetworks.com/frostygoop-malware-analysis/\r\nPage 18 of 21\n\nFigure 23 shows a code snippet from a FrostyGoop sample with the logic to select Modbus operations depending\r\non the value provided:\r\n3 for read holding registers\r\n6 for write single holding register\r\n16 for write multiple holding registers operation\r\nFigure 23. Code snippet from a FrostyGoop sample showing how it implements Modbus operations.\r\nConclusion\r\nWith cyberattacks against ICS/OT devices and critical infrastructure increasing in recent years, the cybersecurity\r\nlandscape in these types of environments has become increasingly dangerous. Countries like Ukraine, Romania,\r\nIsrael, China, Russia and the United States have all been affected by attacks targeting their critical infrastructure.\r\nPrior to these incidents, cybersecurity in OT was not considered an essential part of their defensive operations.\r\nThe past decade has seen an increase in CS-centric malware, with FrostyGoop being the most recent prominent\r\nexample. During this time frame, the number of OT and internet of things (IoT) devices exposed to the internet\r\nhas drastically increased.\r\nhttps://unit42.paloaltonetworks.com/frostygoop-malware-analysis/\r\nPage 19 of 21\n\nAn increasing number of OT networks have been connected with IT networks to facilitate facilities management.\r\nThis has unleashed new ways to perform cyberattacks that can not only damage the cyberspace realm, but also the\r\nphysical world. Malicious actors can send control commands to field devices easily disguised as regular\r\noperations within network traffic, making the activity more difficult to detect and prevent.\r\nFor these reasons, we must implement security measures to prevent and mitigate these attacks. Palo Alto\r\nNetworks customers are better protected from the threats discussed in this blog through the following products:\r\nIndustrial OT Security is designed to:\r\nUse machine learning techniques to detect abnormal network traffic and abnormal behavior in\r\nengineering workstations and field devices\r\nRaise alerts in the event of a compromised environment, based on anomalous command access\r\nGenerate alerts based on Modbus operations\r\nImplement analytics rules for detection of suspicious traffic including anonymous telnet login,\r\nbrute-force login attempts, default credentials usage\r\nCover and identify Common Vulnerabilities and Exposures (CVEs) in MikroTik and other common\r\nrouters\r\nLeverage upstream Advanced WildFire and Advanced Threat Prevention detections, along with IoT\r\ndevice detection capabilities, to detect malware command and control communication\r\nDetect devices running vulnerable versions of firmware\r\nNext-Generation Firewall (NGFW) and Advanced Threat Prevention are designed to:\r\nProvide complete visibility and control of the applications in use across all users and devices in all\r\nlocations all the time\r\nAutomatically reprogram your firewall with the latest intelligence using inline machine learning as\r\nwell as the application and threat signatures\r\nImplement rules TID 31667 (Modbus read coils) and TID 31668 (Modbus write coils), which\r\nallows administrators to identify abnormal devices performing Modbus operations\r\nImplement MikroTik CVEs related to prevent remote code execution and command injection\r\nvulnerabilities from being exploited within the network\r\nAdvanced WildFire is designed to:\r\nIdentify malicious binaries and make verdict determinations when analyzing executing processes\r\nImplement detection rules to identify, block and prevent deployment of\r\nFrostyGoop/BUSTLEBERM and its variants, as well as other ICS-centric ransomware and malware\r\nCortex Xpanse is designed to:\r\nProvide a complete, accurate and continuously updated inventory of all global internet-facing assets,\r\nincluding exposed OT services and devices\r\nEnable discovery, evaluation and mitigation of cyberattack surface risks\r\nFacilitate evaluation of supplier risk\r\nCortex XDR and XSIAM are designed to:\r\nAccurately detect threats with behavioral analytics and reveal the root cause to speed up\r\ninvestigations\r\nBetter protect against malware discussed in this article through Cortex XDR, including WildFire,\r\nBehavioral Threat Protection and the Local Analysis module\r\nhttps://unit42.paloaltonetworks.com/frostygoop-malware-analysis/\r\nPage 20 of 21\n\nUnit 42 researchers at Palo Alto Networks are committed to discovering new malware and threats. We\r\nshare our findings and feed the results back into our products and services, so our customers are better\r\nprotected.\r\nIf you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident\r\nResponse team or call:\r\nNorth America Toll-Free: 866.486.4842 (866.4.UNIT42)\r\nEMEA: +31.20.299.3130\r\nAPAC: +65.6983.8730\r\nJapan: +81.50.1790.0200\r\nPalo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA\r\nmembers use this intelligence to rapidly deploy protections to their customers and to systematically disrupt\r\nmalicious cyber actors. Learn more about the Cyber Threat Alliance.\r\nSource: https://unit42.paloaltonetworks.com/frostygoop-malware-analysis/\r\nhttps://unit42.paloaltonetworks.com/frostygoop-malware-analysis/\r\nPage 21 of 21",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"ETDA",
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://unit42.paloaltonetworks.com/frostygoop-malware-analysis/"
	],
	"report_names": [
		"frostygoop-malware-analysis"
	],
	"threat_actors": [],
	"ts_created_at": 1775434336,
	"ts_updated_at": 1775826756,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/666ea9931359d1c5d1dbe74a4164e48f75429cf4.pdf",
		"text": "https://archive.orkl.eu/666ea9931359d1c5d1dbe74a4164e48f75429cf4.txt",
		"img": "https://archive.orkl.eu/666ea9931359d1c5d1dbe74a4164e48f75429cf4.jpg"
	}
}