The Copeland Incident On 2 November 2026, two Administrator sessions on an internet-exposed Copeland XWEB Pro 1.9.0 refrigeration controller read settings across 31 devices, then made 743 parameter writes, muted alarms, locked keypads and triggered defrosts. We examine the event log and its limits, and set out how operators can reduce exposure. Massimo Giaimo Contributors: Ellis Stannard, Tammy Harper, M. Smith Share: Contents Introduction The wider campaign How the attack unfolded Settings changed across 31 devices Timeline How the site is anonymized Internet exposure Limits of the evidence What to alert on Unpatched devices Longer-term hardening Conclusion Indicators of compromise Appendix: exposed services Sources and reporting notes The Sea of Ice (Das Eismeer) by Caspar David Friedrich (digitally altered) The Sea of Ice (Das Eismeer) by Caspar David Friedrich (digitally altered) Introduction Commercial refrigeration rarely looks like a cyber target. Yet a supervisory controller can sit above dozens of cabinets, freezers, and cold rooms, collecting alarms and temperatures while sending operating instructions to field controllers. That central position is operationally convenient but also security-critical: access to the supervisor can become access to the physical process. That risk became particularly concrete in 2026. Claroty Team82 reported 23 vulnerabilities in Copeland XWEB Pro, 21 described as high severity, including authentication weaknesses and command-injection flaws that could enable remote code execution. Its demonstration showed that a compromised supervisor could manipulate connected refrigeration functions and potentially conceal a cooling failure. [3] Copeland released firmware 1.13 to address the reported findings. [1] The bulletin's FAQ already advised against exposing the device to the internet. Figure 1. The FAQ in Copeland’s February 2026 XWEB PRO security bulletin. Its first recommendation is to keep devices off the public internet. Figure 1. The FAQ in Copeland’s February 2026 XWEB PRO security bulletin. Its first recommendation is to keep devices off the public internet. CISA’s February 2026 advisory likewise lists XWEB Pro versions through 1.12.1 as affected, describing possible authentication bypass, denial of service, memory corruption, and arbitrary code execution. [2] The incident log examined here records a compromise on 2 November 2026 at a commercial refrigeration site. The controller was reportedly running X-Web Pro 1.9.0 and was reachable through a public internet address. The controller address is withheld in this article; the two source IPs used by the attackers are published as indicators of compromise. The system names, translated from Italian and altered with fictional labels and non-original codes, are anonymized throughout. Figure 2. The X-Web Pro login page of the affected controller, captured on 5 November 2026. The site name is redacted. Figure 2. The X-Web Pro login page of the affected controller, captured on 5 November 2026. The site name is redacted. Version 1.9.0 is older than the affected-version ceiling in CISA’s advisory (1.12.1 and earlier), so it falls within the stated affected range for the covered XWEB Pro models. The known critical vulnerabilities for this version are as follows: CVE-2026-21718 - CVSS 10.0 (Critical) / EPSS 0.00692: an authentication bypass that may allow code execution without authentication. CVE-2026-24663 - CVSS 9.0 (Critical) / EPSS 0.03691: operating system command injection via a specially crafted request, potentially allowing for remote code execution without authentication. That does not prove that any specific published vulnerability was used in this incident. At the time of writing, no public proof-of-concept exploit is known for either vulnerability. The event log only records administrator-level actions, not the exploit itself or how the attackers got in. Other evidence shows the way in: the controller still used its default Administrator credentials, so no exploit was needed. The wider campaign In October, attackers hit about 700 of France’s 10,000 supermarkets through Danfoss, Copeland, and Dixell controllers and forced intense defrost cycles that spoiled food. [8] In early November, a second wave hit supermarkets in at least nine European countries. Analysts found about 13,000 refrigeration systems in Europe that still run vulnerable software, and researchers found 1,173 Copeland XWEB units exposed to the internet worldwide. On the night of November 1 to 2, attackers went through Coolworld, a contractor of the French blood service (EFS), and changed freezer settings from about −30°C to 110°C at three EFS sites. Staff responded to the alarms, and EFS reported no loss of blood products and no health consequences. On November 4, NoName057(16) and Z-Pentest claimed the supermarket attacks, but investigators did not confirm the claim or establish a link between the blood-service attack and the supermarket attacks. [4] [5] [6] [7] Figure 3. A NoName057(16) Telegram post headed “Global audit continues: Danish giant Danfoss fallen”. It claims a DDoS attack on danfoss.com, renewed refrigeration outages and a leak of Danfoss employee and customer credentials. These claims are unverified. Figure 3. A NoName057(16) Telegram post headed “Global audit continues: Danish giant Danfoss fallen”. It claims a DDoS attack on danfoss.com, renewed refrigeration outages and a leak of Danfoss employee and customer credentials. These claims are unverified. Video 1. A propaganda video from the pro-Russian groups NoName057(16) and Z-Pentest Alliance boasting of hacking Danfoss refrigeration systems and spoiling food supplies. It shows Danfoss and Dixell XWEB (Copeland) branding and a map of targets across Europe. We have covered its closing QR code, which links to the NoName057(16) Telegram bot @info_links_channels_bot. The incident examined in this article took place in the early hours of 2 November, the same night as the EFS attack. We have no evidence linking it to NoName057(16), Z-Pentest Alliance or the attacks in France. The event log records two source addresses and nothing about who used them. The changes resemble the reported attacks, with setpoints pushed to 110°C and defrost cycles manipulated, but anyone with administrative access can make them, so the similarity does not link the incidents. Why this campaign matters This campaign matters because attackers caused physical damage with the normal control functions of refrigeration systems, with no ransom demand and no known malware. Thousands of these controllers are still open to the internet, and third parties that manage them remotely often do not install the necessary updates. Danfoss linked the attacks to end-of-life devices and outdated firmware, and both Danfoss and Copeland released fixes for known flaws before the attacks. The blood-service case shows that the compromise of one contractor can reach equipment that keeps essential medical products safe. In October, the head of ANSSI warned that refrigeration for medical storage was a possible target, and the attack on the blood service followed weeks later. In December 2025, Denmark linked both groups to the Russian state, but no authority published evidence of state direction for the refrigeration attacks. [5] [6] [7] How the attack unfolded At approximately 03:10, an Administrator session began from 198[.]251.85.67. The IP is located in Australia and registered to RouterHosting LLC, and it is not flagged as malicious. No open ports are detected at the time of writing, but earlier scans showed RDP (3389/TCP), SSH (22/TCP) and an unidentified service on 8080/TCP. The RDP service named the Windows host VPS-97D1AF38, a naming pattern typical of rented virtual servers. The full service banners for both source addresses are in the appendix. The account spent the next several minutes reading device parameters across 31 listed refrigeration assets. The sweep covered display cases, freezer cabinets, cold rooms, and central refrigeration equipment. This was reconnaissance: the account identified the controllers and recorded their settings before changing any of them. The first burst of modifications followed soon after. Between approximately 03:15 and 03:21, the same source made 588 parameter writes across 26 devices. That is about 1.6 writes per second, a pace more consistent with a script or a bulk-programming function than with manual edits. A second Administrator session, from another external source (85[.]137.52.63), appeared around 03:36. The IP is located in the Netherlands and registered to SOLLUTIUM EU Sp. z o.o., and it is not flagged as malicious. RDP (3389/TCP) and SMB (445/TCP) are open at the time of writing; earlier scans also showed HTTP (80/TCP) and SSH (22/TCP) accepting password logins. The services on this address report different systems. RDP and SMB give different Windows builds (10.0.20348 and 10.0.17763), and the SSH service identified as Ubuntu Linux. More than one system appears to sit behind the address, which fits shared hosting or a relay better than an operator's own machine. Both addresses are useful indicators, but they say little about who the operator is. After another sequence of parameter reads, that session made 155 further writes across five cold rooms, between approximately 03:42 and 03:44. In total, the log records 743 parameter writes affecting 31 devices. Settings changed across 31 devices The changes were not isolated corrections. Across multiple refrigeration assets, setpoints were moved from ordinary cold-storage values to extreme values, including 110°C and 150°C. Alarm thresholds, limits, and delays were also pushed to outlying values, often 150 or 255, while other control settings were reduced to zero. Defrost-related parameters were changed as well, including intervals, termination values, and modes. Figure 4. Event log excerpt from the first Administrator session (03:20:33 to 03:20:40): parameter writes, a keypad lock and an alarm mute. Device names are redacted. Figure 4. Event log excerpt from the first Administrator session (03:20:33 to 03:20:40): parameter writes, a keypad lock and an alarm mute. Device names are redacted. Because the log contains abbreviated controller parameter codes rather than full descriptions, each setting should be checked against the correct model manual and the controller’s post-incident state. Still, the pattern is strongly inconsistent with routine maintenance: extreme setpoints paired with altered alarm behavior and operating parameters could undermine normal refrigeration while obscuring the resulting fault. The log also records direct commands to mute alarms and lock local keypads on a number of units. Time Level User (source) Event 02/11/2026 03:21:00 info Administrator (198[.]251.85.67) Sent command “Alarm Mute” to device [REDACTED] Table 1. Event log entry for an “Alarm Mute” command sent by the first Administrator session at 03:21:00. The device name is redacted. Two refrigerated island units received defrost commands. One alarm-mute attempt failed because the target reported “no valid function”; the remaining recorded commands should be treated as potentially successful until independently verified. What the commands do “KeyboardLock” and “Blocco tastiera” - keypad-lock commands. These were sent to multiple cases and cabinets; they indicate an attempt to disable or restrict local keypad operation, subject to confirming the command’s effect on each controller model. “Alarm Mute” - alarm-silencing command. The log records several such sends. One attempt returned “no valid function,” so that specific command failed; the other entries record that the command was sent but do not confirm that alarms were silenced. “Defrost ON” and “ActiveDefrost” - commands that request or activate a defrost cycle on the named units. The log shows one of each; verify the controller response and equipment history to establish whether the cycles started. Figure 5. Event log excerpt from the second Administrator session (03:43:58 to 03:44:18): keypad locks, alarm mutes and defrost commands. Device names are redacted. Figure 5. Event log excerpt from the second Administrator session (03:43:58 to 03:44:18): keypad locks, alarm mutes and defrost commands. Device names are redacted. “Read parameters” - a read action that changes nothing. It appears in the reconnaissance phase as settings were collected across the device fleet. “Wrote parameters” - configuration-write events rather than a single named command. Logged examples include SEt (setpoint), ALL/ALU (low/high alarm thresholds on these controllers), and several defrost-related codes such as idF, MdF, dFd, dtS, and dtE. The meanings and units are model-dependent; the article reports the recorded before-and-after values without assuming a universal meaning. “Sent device command” from scheduler - the log also contains routine scheduler-originated events. Their presence alone does not identify attacker activity; they should be correlated with expected schedules and device telemetry. Timeline ~03:10 - Administrator login from 198[.]251.85.67; broad parameter-reading activity begins. ~03:10 to 03:14 - Parameters read from 31 listed devices, spanning multiple equipment categories. ~03:15 to 03:21 - 588 parameter changes recorded across 26 devices from the first external source. ~03:36 - A second Administrator session appears from 85[.]137.52.63 and begins additional parameter reads. ~03:42 to 03:44 - 155 parameter changes across five cold rooms; keypad locks, alarm mutes, and defrost commands appear in the wider command record. How the site is anonymized To protect the site, the article uses invented labels rather than the original device identifiers. The original codes, location name, site details, and controller public address have been excluded or replaced. These labels are editorial aliases for the real equipment. Internet exposure and the vulnerable version The reported public reachability is an important exposure condition. A management controller intended to supervise industrial equipment should not be directly reachable from the public internet. An internet-facing service can be scanned and attacked continuously, and the risk is amplified when a device runs software within a known affected version range. The public research gives context but does not prove the attack path. CISA lists authentication bypass and pre-authentication code-execution issues among the reported defects, as well as multiple command-injection vulnerabilities. Claroty describes how weaknesses could be chained from remote access to privileged control and then to connected field devices. In this incident, the Administrator sessions came through the default credentials, so none of these vulnerabilities was needed. [2] [3] Limits of the evidence The current evidence can tell us that administrator-level sessions read the settings and then recorded large-scale changes, that those changes affected a wide range of refrigeration assets and that alarm muting, keypad locking, and defrost commands were issued. It cannot tell us the actual temperatures reached, whether every write was accepted, whether the settings persisted, whether equipment safeguards intervened, or how long any unit operated in an unsafe state. It also cannot identify the operator behind the source addresses, or say whether the two sessions were one operator or two. Temperature telemetry, controller state exports, alarm history, network records, and inventory assessments are needed to establish true physical impact. What to alert on The event log that recorded this attack also shows what monitoring could have caught. Each pattern below appears in the log; tune the thresholds to the site's normal maintenance activity. Bulk parameter writes: more than about 20 “Wrote parameters” events a minute from one account, or writes to more than three devices within five minutes. The first session made about 98 writes a minute. Safety-function commands: any keypad-lock (“KeyboardLock”, “Blocco tastiera”), “Alarm Mute”, “Defrost ON” or “ActiveDefrost” command that does not come from the scheduler. Implausible values: setpoints (SEt) outside the plausible range for the asset, such as the 110°C and 150°C written here, and alarm thresholds (ALL/ALU) pushed to outlying values such as 150 or 255. Logins from unexpected sources: an Administrator login from any address outside the site's approved management networks, or a second Administrator session from a different address within the same hour. Read sweeps: parameter reads across most of the device fleet shortly after a login. Here the sweep began about five minutes before the first write, making it the earliest sign of the attack in the log. Reducing exposure on unpatched devices For operators who still run an affected XWEB Pro release, treat this as a priority OT security issue. Copeland directs users to its model-specific update pages and also documents an update route through SYSTEM → Updates → Network for an internet-connected unit. Confirm the correct model and supported update procedure with Copeland or an authorized service provider; do not assume a firmware package for one model applies to another. CISA advises impact analysis and risk assessment before deploying defensive changes. [2] Change the default Administrator password, and any other default credentials, immediately. Remove direct internet reachability: disable port forwarding and public management access; apply an upstream deny rule. Do not use “temporary” exposure as a substitute for a controlled remote-access design. If remote administration is essential during remediation, allow it only through an organization-managed VPN or secure remote-access gateway with MFA, named accounts, restricted source networks, and logging. Keep the controller itself off the public address space. Inventory every XWEB/XWEB Pro model and firmware level. Prioritize devices at or below 1.12.1 for vendor-directed remediation; install the latest vendor-supported fixed release for the exact model, and verify the installed version afterward. Before updating, preserve configuration backups, logs, and operational settings; coordinate the maintenance window with refrigeration and food-safety personnel. Validate alarms, sensors, local controls, defrost cycles, and cooling operation after the update. If compromise is suspected, preserve evidence first, then isolate the management plane where safe. Restore settings from a known-good baseline, rotate credentials from a clean workstation, and independently verify temperatures and product safety. Longer-term hardening Network architecture: place supervisory controllers in a dedicated OT zone behind firewalls; separate OT from corporate IT and guest networks; deny inbound internet traffic by default; restrict outbound connections to documented necessities. Remote access: use a brokered, monitored jump host or VPN with MFA, individual accounts, time-bounded approvals, and session logging. Disable unused remote services and remove default or shared credentials. Access governance: least privilege, unique credentials, controlled service accounts, strong credential rotation, and review of account changes and authentication events. Keep vendor access explicit, approved, and time-limited. Monitoring and recovery: alert on bulk parameter writes, unusual setpoints, disabled or delayed alarms, keypad locks, unexpected defrost commands, new logins, and changes outside maintenance windows. Keep offline, tested configuration backups and a written safe-recovery procedure. Operational safeguards: use independent temperature monitoring and alert paths where feasible, regularly test alarms, and ensure staff can recognize discrepancies between controller displays and independent measurements. Lifecycle management: maintain an asset register with model, firmware, owner, exposure, and patch status; subscribe to vendor and CISA advisories; and include OT devices in vulnerability-management and incident-response plans. Conclusion Control of a supervisory controller gives control of the equipment it manages. The attackers needed no vulnerability, only the default credentials. The log does not show whether stock was lost. It does show what the attackers did once they had administrative control: they surveyed the equipment, changed settings across 31 devices, and targeted local alarms and keypads. Refrigeration operators should change default credentials, patch promptly, keep supervisory controllers off the public internet, and check temperatures with instruments that do not depend on the controller. Indicators of compromise Indicator Description 198[.]251.85.67 Source of the first Administrator session (from about 03:10) 85[.]137.52.63 Source of the second Administrator session (from about 03:36) Appendix: services exposed by the source IPs Service banners collected by internet scans of the two source addresses. They describe the systems that answer on those addresses, which may be shared or relayed. 198[.]251.85.67 Port 3389/TCP Port Service Protocol: rdp Port Service CPEs: [{"cpe":"cpe:/o:microsoft:windows","product":"","version":""}] TLS Encrypted: False Operative System: Windows Transport: TCP Scripts: Target_Name: VPS-97D1AF38 NetBIOS_Domain_Name: VPS-97D1AF38 NetBIOS_Computer_Name: VPS-97D1AF38 DNS_Domain_Name: vps-97d1af38 DNS_Computer_Name: vps-97d1af38 Product_Version: 10.0.19041 System_Time: 2026-10-27T03:48:14+00:00 RDP Fingerprint: Windows Server 2016 or 2019 RDP OS Version: 10.0.19041 RDP Target Name: VPS-97D1AF38 Port 8080/TCP Port Service Protocol: unknown TLS Encrypted: False Transport: TCP Port 22/TCP Port Service Protocol: ssh Port Service CPEs: [{"cpe":"cpe:/a:openbsd:openssh:9.6p1","product":"Openbsd Openssh","version":"9.6P1"}] TLS Encrypted: False Transport: TCP Scripts: 256 5689b2f43b06b8404a129c82be5140ab (ECDSA) 256 SHA256:TKNagUZVAdq0B7owdHe82PfvLpqSSydn+bS0hgEHEi8 (ECDSA) 256 xikis-dotip-guzap-vidyk-symyv-babiz-bipav-fisik-rosaf-hefez-goxax (ECDSA) +--[ECDSA 256]---+ |=oo | |o+.. . . | |+oo o . o | |+= o + . | |E + . o S | | . . . o . | | . + | | . . | | | +-----------------+ ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBIR3hNJKQXioMHcdyBt+fJ8mSk00qPxHfYDQxEOqmkGN3UXDd26q+/0NoQHX2vcs3+MbjUJJnQHmJkjUksudjbw= 256 777eead826b260875b1333ed6c0478ba (ED25519) 256 SHA256:p1XFRQ3m+CkFsxrT73ZALgPZJcNLaHFQXYCQez4gFPo (ED25519) 256 xufif-modut-gigon-davyc-zufof-vybez-medaf-nideb-gifyn-guvyr-nixux (ED25519) +--[ED25519 256]-+ | | | . | | . o | | o o | | . S + . | | o O o | | E + + . . | | . =.o.o.o | | . .o.++ | +-----------------+ ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGMZJh+d83wO+qCnLo6UBgdJlJPV3Og1RYdftLLj46T8 Extra Info: protocol 2.0 SSH Raw: AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBIR3hNJKQXioMHcdyBt+fJ8mSk00qPxHfYDQxEOqmkGN3UXDd26q+/0NoQHX2vcs3+MbjUJJnQHmJkjUksudjbw= SSH Software: OpenSSH SSH Version: 9.6p1 SSH Comment: protocol 2.0 Host Key Fingerprint: SHA256:TKNagUZVAdq0B7owdHe82PfvLpqSSydn+bS0hgEHEi8 Host Key Type: ecdsa-sha2-nistp256 85[.]137.52.63 Port 3389/TCP Port Service Protocol: rdp Port Service CPEs: [{"cpe":"cpe:/o:microsoft:windows","product":"","version":""}] TLS Encrypted: False Operative System: Windows Transport: TCP Scripts: Target_Name: U6SFQPST NetBIOS_Domain_Name: U6SFQPST NetBIOS_Computer_Name: U6SFQPST DNS_Domain_Name: U6sfQpsT DNS_Computer_Name: U6sfQpsT Product_Version: 10.0.20348 System_Time: 2026-11-05T02:57:58+00:00 RDP Fingerprint: Windows Server 2016 or 2019 RDP OS Version: 10.0.20348 RDP Target Name: U6SFQPST Port 445/TCP Port Service Protocol: smb TLS Encrypted: False Operative System: 10.0.17763 Transport: TCP SMB Signing Enabled: True SMB NetBIOS Computer Name: U6SFQPST SMB NetBIOS Domain Name: U6SFQPST SMB DNS Computer Name: U6sfQpsT SMB DNS Domain Name: U6sfQpsT SMB OS Version: 10.0.17763 Port 22/TCP Port Service Protocol: ssh Port Service CPEs: [{"cpe":"cpe:/a:openbsd:openssh:8.9p1","product":"Openbsd Openssh","version":"8.9P1"},{"cpe":"cpe:/o:linux:linux_kernel","product":"","version":""}] TLS Encrypted: False Operative System: Linux Transport: TCP Scripts: 256 6f18feb541b155c3ff273d0963417512 (ECDSA) 256 SHA256:T2LoyDp737j0gvhWfaFM1VDIWoVnH8mLZjz7RQq84pM (ECDSA) 256 xogiz-gabub-tyhyt-furon-gudon-kycik-gyleb-rulav-vutuv-gaved-zuxux (ECDSA) +--[ECDSA 256]---+ | ..E+o| | . +o| | . o .| | B .| | S + o.o| | . + . .o+| | o o o .o| | o . o | | . . | +-----------------+ ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBEd/y4ANMgSuWcp/3mJf8P+gUOxilt0XkFbpoNmamM9ULgfhDHj/X2kniFI2wu4t7PN06LJCSLNLskc1uXQoXMA= 256 c358bd092eb2e4d0b5e394a1e7180aaa (ED25519) 256 SHA256:XJVWMDtqPqYABu2y9g4jfs2jwStzlv9ZWWn4LL0gvhE (ED25519) 256 xisad-lasez-revyt-dikan-numuf-lakog-nezyp-nuzah-kygil-lupip-fexyx (ED25519) +--[ED25519 256]-+ | | | . | | o o . | | . o O . o | |. . * O S o | |.. = X o . | |. . + o | |. | |E | +-----------------+ ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAINNmHP757FV7SlzFPLyL5sb/HxVSlNfyJek0bGyqI5kB Extra Info: Ubuntu Linux; protocol 2.0 SSH Raw: AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBEd/y4ANMgSuWcp/3mJf8P+gUOxilt0XkFbpoNmamM9ULgfhDHj/X2kniFI2wu4t7PN06LJCSLNLskc1uXQoXMA= SSH Software: OpenSSH SSH Version: 8.9p1 Ubuntu 3ubuntu0.17 SSH Comment: Ubuntu Linux; protocol 2.0 Host Key Fingerprint: SHA256:T2LoyDp737j0gvhWfaFM1VDIWoVnH8mLZjz7RQq84pM Host Key Type: ecdsa-sha2-nistp256 Password Auth Enabled: True Port 80/TCP Port Service Protocol: http TLS Encrypted: False Transport: TCP Sources and reporting notes Copeland, “XWEB PRO Security Update Bulletin - February 26”, released 26 February 2026. Security update bulletin (PDF) CISA, “Copeland XWEB and XWEB Pro,” ICS Advisory ICSA-26-057-10, released 26 February 2026. Affected versions and mitigation recommendations. ICSA-26-057-10 Claroty Team82, “Chilling Discoveries: Unpacking Vulnerabilities in Copeland XWEB Pro Controllers,” 9 August 2026. Vulnerability research and controlled demonstration. Team82 research ACHR News, reporting on the refrigeration attacks against French supermarkets. achrnews.com GBHackers, reporting on the attack against the French blood service. gbhackers.com Tech Insider, reporting on the second wave against European supermarkets. tech-insider.org Facilities Dive, reporting on internet-exposed refrigeration controllers after the French attacks. facilitiesdive.com OCCRP, reporting on the attacks on French supermarket refrigeration through Danfoss, Copeland, and Dixell controllers. occrp.org Primary incident source: supplied XWEB event log dated 2 November 2026. Statistical counts and timeline in this article are derived from the supplied log. The controller address and identifiable site and device names are intentionally redacted or anonymized; the two attacker source IPs are published as indicators of compromise.