{
	"id": "0b9c0734-72c4-4a55-a3da-e2a153b514ad",
	"created_at": "2026-04-06T00:22:27.459648Z",
	"updated_at": "2026-04-10T13:11:43.239516Z",
	"deleted_at": null,
	"sha1_hash": "8d4c669ba1eb89136a3c362cf15ad8afc21f48e3",
	"title": "Monitoring Critical Infrastructure and Security",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 104678,
	"plain_text": "Monitoring Critical Infrastructure and Security\r\nBy Joe Slowik\r\nArchived: 2026-04-05 17:49:10 UTC\r\nIntroduction\r\nOn 08 February 2021, officials from Pinellas County, Florida announced an unknown entity accessed water\r\ntreatment operations for the city of Oldsmar. In addition to technical analysis based upon limited details, multiple\r\nmedia outlets responded to the incident with immediate reporting lacking significant additional details. At this\r\ntime, while the general nature of this incident is somewhat known, many questions remain, especially concerning\r\nwhat entity was responsible for the incident and what their precise intentions were in attempting to modify water\r\ntreatment operations.\r\nWhile further investigation is warranted, available details allow us to reach some preliminary conclusions on the\r\nincident itself and its likely implications. Furthermore, based on what we know with respect to this event and past\r\nIndustrial Control System (ICS) intrusions, we can formulate an understanding of this incident’s maturity. Finally,\r\nthe event in Oldsmar provides sufficient information to provide defensive guidance to detect, mitigate, or prevent\r\nsimilar scenarios in the future.\r\nOverview of the Oldsmar Incident\r\nOn 05 February 2021, operators at the municipal water treatment facility serving the small city of Oldsmar,\r\nFlorida noticed strange activity on the systems used to monitor and control operations at the plant. Initial reporting\r\nfrom Reuters indicated the facility used TeamViewer remote access software for remote monitoring and\r\nhttps://www.domaintools.com/resources/blog/visibility-monitoring-and-critical-infrastructure-security\r\nPage 1 of 7\n\nmanagement, which was subsequently confirmed in follow-on reporting and interviews conducted by Wired.\r\nWhile plant operators have since removed the software, at the time an unknown entity identified the TeamViewer\r\ninstance and managed to authenticate to the system.\r\nIdentification of critical infrastructure systems exposed to the internet is hardly a new phenomenon. As previously\r\ndocumented by Kim Zetter in several articles from the early 2010s, various tools exist that enable researchers (or\r\nless scrupulous entities) to search for and identify ICS devices or similar equipment. Prior to the Oldsmar incident,\r\nresearchers identified several instances of likely malicious entities remotely accessing control system equipment\r\nin the water sector, with the following standing out as most interesting:\r\n2013: Intruders, assessed to be linked to Iranian entities, accessed control systems for the small Bowman\r\nAvenue Dam. Although a relatively minor structure and resulting in no disruptive consequences, analysts\r\ntheorize the intruders may have intended to target the much larger Arthur R. Bowman Dam in Oregon,\r\ninstead.\r\n2016: In its annual data breach report, Verizon reported several water utilities—combined into the single,\r\npseudonymous organization “Kemuri Water”— experienced breaches of varying severity. In a few\r\ninstances, the unknown intruders appear to have manipulated water treatment controls in a haphazard way,\r\ncausing operational disruption but no harm or destruction.\r\n2018: An unknown entity utilized VPNFilter malware to attempt an unspecified attack on a chlorine\r\nproduction plant in Ukraine. Although not directly targeting water treatment operations, the incident would\r\nhave significantly impacted the sector had a disruption occurred at the targeted site.\r\n2020: Unknown entities, although tentatively linked to Iranian interests, accessed and performed minor\r\nmodifications to multiple water pumping and treatment devices in Israel in April and July 2020. Based on\r\nanalysis of available information, affected devices were externally accessible with minimal or no\r\nauthentication preventing the intruder from accessing control systems. While there is some speculation that\r\nthis event may be linked to the Oldsmar incident, no evidence exists connecting the two and all similarities\r\nappear circumstantial.\r\nIn all of the above cases, external access to control systems resulted in either no or very limited disruption to\r\nphysical operations. While the same is roughly true of the Oldsmar incident in terms of ultimate impact, the\r\nunknown intruder’s actions in the environment are concerning. Specifically, the entity utilized remote access to\r\nICS equipment to manipulate sodium hydroxide levels in the treatment plant. While normal operations run at 100\r\nParts Per Million (PPM) of sodium hydroxide in the treatment environment, the unknown intruder attempted to\r\nincrease the amount to 11,100 PPM.\r\nWhile attempting to make the above alteration, personnel monitoring the equipment, likely a Human Machine\r\nInterface (HMI) in the plant environment, noticed the action and reversed it. Had the action not been caught in\r\nprogress during standard working hours, officials indicate it would take 24-36 hours for the change to be reflected\r\ndownstream among the population served by the district, and that automated testing and similar safeguards would\r\nhave detected the physical process change.\r\nBased on all available evidence and statements from local authorities, the intrusion and manipulations to the ICS\r\nenvironment were prevented through operator attentiveness and interaction, with further engineering controls\r\nproviding additional layers of safety. Although the incident resulted in neither significant disruption nor outright\r\nhttps://www.domaintools.com/resources/blog/visibility-monitoring-and-critical-infrastructure-security\r\nPage 2 of 7\n\ndamage, the simple fact that some unknown entity attempted the above action is deeply concerning—reflecting\r\neither callousness given the potential harm, or ignorance as to what the attempted change might have produced in\r\nthe serviced population.\r\nProcess Visibility and Intruder Maturity\r\nAlthough deeply concerning, the intrusion (if not “attack”) scenario described above shows multiple immaturities.\r\nParticularly:\r\n1. Events took place during normal operational hours where personnel were on-hand and available to quickly\r\nrespond.\r\n2. The intruder did not attempt to hide or mask their activity through interaction with or overwrite of HMI\r\nsystems or spoofing of sensor data.\r\n3. The modification to sodium hydroxide levels was so extreme as to almost certainly trigger engineering or\r\nother non-ICS controls or alarms within the environment.\r\nThese three factors, taken together, indicate an attack that was either immature, rushed, or potentially\r\nunintentional following access to the controlling HMI. To better understand how these items function, especially\r\nin light of a potential integrity-targeting ICS incident, a quick review of historical ICS incidents is helpful.\r\nStuxnet Incident\r\nAlthough well-documented, especially through resources such as Kim Zetter’s Countdown to Zero Day and\r\nSymantec’s Stuxnet Dossier, certain elements of Stuxnet are frequently misunderstood or overlooked in general\r\ndiscussion. While reviewed in other sources in depth, the critical item enabling Stuxnet’s success was the\r\nmalware’s ability to induce a general loss or denial of view condition in the victim environment. In this specific\r\ncase, the malware recorded “normal” plant operations then played these recordings back to monitoring systems\r\nduring physical attack sequences to mask events from plant operators. Absent this critical step, operators would\r\nhave been able to detect anomalous operations in the plant environment enabling intervention and process\r\ndiagnosis.\r\n2015 Ukraine Power Event\r\nIn 2015, entities linked to Russian military intelligence (GRU) penetrated multiple electric distribution centers in\r\nUkraine. In a coordinated operation in late December of that year, the attackers disrupted distribution operations\r\ninducing blackout conditions through a combination of rogue control devices and logging on to user workstations\r\nto disconnect equipment.\r\nYet for such operations to succeed, personnel had to be locked out of their workstations to prevent operator\r\nintervention during the initial phases of the attack. Subsequent activity in the victim environment resulted in the\r\nuse of wiper malware to remove remote operational control, followed by a malicious firmware update to serial-to-ethernet converters which made communication to equipment impossible. Overall, these steps amount to a\r\ncoordinated effort to induce a loss or denial of control condition that enabled a sustained, widespread impact to\r\nUkrainian electric utility operations.\r\nhttps://www.domaintools.com/resources/blog/visibility-monitoring-and-critical-infrastructure-security\r\nPage 3 of 7\n\n2016 Ukraine Industroyer/CRASHOVERRIDE Incident\r\nIn 2016, Ukraine again witnessed an electric power incident in December linked to Russia’s intelligence services,\r\nthis time targeting a single transmission substation. Referred to as the Industroyer or CRASHOVERRIDE event,\r\nthe incident again wiped control systems to induce loss of control—but also likely aimed at a loss of view\r\ncondition as well to enable a potentially destructive (if failed) physical damage scenario. In this particular case,\r\nremoving operator logical control (to force manual operations) combined with loss of logical view into the health\r\nand status of the system was used in sequence to enable a process protection-focused attack scenario. Absent these\r\nconditions, it would be highly unlikely for the sequence of events required to restore operations in an unprotected,\r\nunsafe state (enabling possible destruction) would materialize.\r\n2017 TRITON/TRISIS Event\r\nIn 2017, a petrochemical plant in Saudi Arabia experienced multiple unexpected plant shutdowns due to the\r\nplant’s Safety Instrumented Systems (SIS) tripping for then-unknown reasons. Subsequent investigation identified\r\na purpose-built malware variant, referred to as TRITON or TRISIS, as responsible for the disruption. Further\r\ninvestigation and analysis indicated that rather than a direct attack on plant safety equipment, the malware’s\r\npurpose was to enable undetected, arbitrary modification of SIS parameters. Combined with access elsewhere in\r\nthe plant environment, an attacker could remove or alter safety controls to induce physical damage. Yet to\r\nsucceed, the attacker needed to ensure not only access to modify safety parameters, but also the ability to alter\r\nsuch parameters without operators knowing such changes took place.\r\nImplications for Oldsmar\r\nOverall, these four examples of high-profile, technically complex ICS attack scenarios emphasize a critical barrier\r\nto adversary success: the ability to evade, influence, or outright deny operator visibility into and control over ICS\r\nenvironments. In all four examples, the attacks required some mechanism to hide from operators or deny their\r\nability to correct or mitigate changes made to operating parameters.\r\nIn the case of the Oldsmar treatment plant incident, the intruder failed to attempt any such action based on\r\ninformation currently available. Had the unknown entity spoofed or otherwise interfered with HMI display\r\nparameters or sensor data, the operator on duty would be less likely to notice the incident as it took place,\r\nresulting in an attack moving on to engineering and process controls for potential mitigation or detection. Not only\r\ndid the intruder fail to limit or manipulate process view in the environment, they executed the event during\r\nprimary working hours on a weekday, almost ensuring that such activity would be quickly noticed (and mitigated).\r\nBased on these observations and in light of past ICS incidents, we can therefore make a reasonably confident\r\nclaim with available evidence that this was not an especially complex or savvy “attack”. As described in multiple\r\nsources, the intruder appears to have merely taken advantage of weakly secured, accessible remote access\r\nmechanisms to connect to plant equipment controls, followed by either deliberate or potentially inadvertent\r\nmanipulation of the environment. That such an attempt occurred at all is certainly concerning, but the\r\noverwhelming evidence given event timing and execution indicate that there were only slight possibilities for this\r\nevent to produce significant damage or harm.\r\nhttps://www.domaintools.com/resources/blog/visibility-monitoring-and-critical-infrastructure-security\r\nPage 4 of 7\n\nDefensive Countermeasures and Attack Surface Reduction\r\nWhile this particular incident did not result in any damage or even notable operational disruption, events at the\r\nOldsmar water treatment facility highlight the real risks and dangers associated with remote access to critical\r\ninfrastructure systems. While the knee-jerk answer to such issues would be to remove or curtail access to such\r\nsystems as much as possible, this is unrealistic and inactionable in modern operational environments. For reasons\r\nranging from centralized control over geographically distant control systems to vendor requirements to system\r\naccess for telemetry and maintenance purposes to the limitations placed on personnel by COVID-19 restrictions,\r\nremote accessibility cannot simply be removed or shut off. However, the ways in which such connectivity are\r\nimplemented can ensure that such operations are done in a securable, defensible fashion.\r\nFirst and foremost, while precise details on the system in question are not available, available evidence indicates\r\nthat if the HMI controlling sodium hydroxide levels was not directly accessible via the TeamViewer instance at the\r\nfacility, then access to such a system was easily gained from that initial access point. While such direct access may\r\nbe convenient, it is insecure and undesirable. Instead, having a purpose-built bastion or “jumphost” can provide a\r\nsingle, hardened point for remote access and monitoring. By using different sets of credentials for the bastion host\r\nto internal network and system authentication, security can be increased further as password brute forcing or\r\ncredential capture for the bastion will not enable immediate follow-on access to other systems in the network.\r\nNetwork segmentation, access controls, and sound network engineering can work in concert to reduce the overall\r\nattack surface to a limited number of defensible nodes (such as the bastion), while also facilitating monitoring of\r\nactivity to a smaller set of devices. When applied with even more robust security controls, such as the\r\nimplementation of robust Multi-Factor Authentication (MFA) schema for remote login activity, exposed attack\r\nsurface can be reduced even further.\r\nWhile certain controls such as complex passwords or hardware token MFA may be undesirable in certain ICS\r\nenvironments due to operational overhead and similar considerations, applying such defensive measures and\r\nsimilar controls to external facing network access points is critical. The profusion of scanning and indexing tools\r\nfor remotely accessible services combined with the ability of adversaries to either brute force or potentially\r\ncapture user credentials mean these accessible systems must be hardened.\r\nRemote Access Monitoring and Indicator Enrichment\r\nOnce networks are appropriately hardened and segmented, network operators and defenders can then proceed to\r\nNetwork Security Monitoring (NSM) and traffic analysis. In well-designed environments with only a few\r\nexternally-communicating or -accessible bastions, NSM operations are simplified and manageable, allowing for\r\npotentially powerful security analysis and response.\r\nWith proper monitoring, defenders can begin asking a number of questions or formulating hunting hypotheses\r\nrelative to their network posture. Particularly, operators can utilize near real-time enrichment of network\r\nobservables such as IP addresses and domain names to build an intelligence picture of traffic flows and\r\ncommunications.\r\nhttps://www.domaintools.com/resources/blog/visibility-monitoring-and-critical-infrastructure-security\r\nPage 5 of 7\n\nAt the most basic level, this may constitute little more than geographic enrichment of IP addresses to identify odd\r\nor anomalous connections. This methodology can certainly produce errors—such as the case of an Illinois water\r\npump station where a worker on vacation remotely accessed a device prompting calls of Russian critical\r\ninfrastructure hacking. Typically, observing remote authentication attempts from non-local address space for a\r\nmunicipal utility network can form a good starting point for follow-on investigation.\r\nIn more advanced use-cases, enrichment of external infrastructure using third-party intelligence sources can\r\nenable complex, higher-confidence queries for suspicious or known malicious activity. Examples would include\r\nbeing able to correlate source infrastructure for connection attempts to anonymizing infrastructure such as TOR,\r\nor identifying connections from Internet Service Providers (ISPs) or Autonomous System Numbers (ASNs) either\r\nhighly correlated with known-malicious activity, or never previously associated with any known-good, legitimate\r\noperation.\r\nAs documented in previous items from DomainTools researchers, identifying indicators in general, and network\r\nindicators in particular, as composite objects yields a number of possibilities for enrichment and analysis. In this\r\nparticular case, defenders and network operators can leverage enrichment of network data to identify suspicious\r\nremote access activity or other signs of initial intrusion, potentially enabling operator response and mitigation\r\nactions before such intrusions proceed to the manipulation of controls in a critical infrastructure environment.\r\nFrom the opposite view, and as previously documented in the context of the SUNBURST campaign, near real-time enrichment of outbound traffic can potentially identify stealthy, otherwise difficult to detect intrusion\r\nscenarios by flagging items related to Command and Control (C2) activity.\r\nConclusion\r\nThe Oldsmar water treatment plant intrusion raises many concerns: first, that such an intrusion even happened in\r\nthe first place indicates a certain maliciousness or lack of caution by the entity in question; second, while this\r\nspecific instance appears relatively simplistic and immature, the same initial access vectors used in this event\r\ncould be leveraged by more operationally savvy entities to produce a disruptive or dangerous impact. Yet while\r\nthe incident is concerning, network operators and defenders have many options available to fight back against\r\nsuch events. Through a combination of network hardening, attack surface reduction, network segmentation, and\r\nNSM with indicator enrichment, defenders can dramatically reduce the likelihood of such events, significantly\r\nreduce their efficacy, or increase the likelihood of identifying such activity at relatively early stages.\r\nOf course, for many smaller organizations, such as municipal water treatment entities, some of the security\r\nsuggestions offered above may remain out of reach for budgetary or technical reasons. While a “100% solution”\r\nmay not be feasible for such entities, certain preliminary steps such as attack surface analysis and reduction\r\nremain within reach. Irrespective of maturity and capability, given that various entities are actively probing and\r\nattempting to interact with connected critical infrastructure systems, all organizations responsible for operating\r\nsuch equipment must take all available steps within reason to secure these networks as best as possible.\r\nOverall, and as documented by various entities, malicious activity against critical infrastructure networks in\r\ngeneral and ICS networks in particular appear to be increasing. Through a combination of proactive defensive\r\nhardening and enhanced visibility or network monitoring, asset owners, operators, and defenders can better\r\nposition themselves against such intrusions. Failure to apply these lessons now mean potential adversaries at\r\nhttps://www.domaintools.com/resources/blog/visibility-monitoring-and-critical-infrastructure-security\r\nPage 6 of 7\n\nvarying levels of complexity and capability will continue to find vital networks unprepared for future intrusion\r\nscenarios.\r\nSource: https://www.domaintools.com/resources/blog/visibility-monitoring-and-critical-infrastructure-security\r\nhttps://www.domaintools.com/resources/blog/visibility-monitoring-and-critical-infrastructure-security\r\nPage 7 of 7",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://www.domaintools.com/resources/blog/visibility-monitoring-and-critical-infrastructure-security"
	],
	"report_names": [
		"visibility-monitoring-and-critical-infrastructure-security"
	],
	"threat_actors": [
		{
			"id": "68cc6e37-f16d-4995-a75b-5e8e2a6cbb3d",
			"created_at": "2024-05-01T02:03:07.943593Z",
			"updated_at": "2026-04-10T02:00:03.795229Z",
			"deleted_at": null,
			"main_name": "BRONZE EDISON",
			"aliases": [
				"APT4 ",
				"DarkSeoul",
				"Maverick Panda ",
				"Salmon Typhoon ",
				"Sodium ",
				"Sykipot ",
				"TG-0623 ",
				"getkys"
			],
			"source_name": "Secureworks:BRONZE EDISON",
			"tools": [
				"Gh0st RAT",
				"Wkysol",
				"ZxPortMap"
			],
			"source_id": "Secureworks",
			"reports": null
		},
		{
			"id": "d4ac28d1-66eb-4f2d-9f9b-a72394349fd0",
			"created_at": "2023-01-06T13:46:38.667954Z",
			"updated_at": "2026-04-10T02:00:03.061447Z",
			"deleted_at": null,
			"main_name": "APT4",
			"aliases": [
				"PLA Navy",
				"MAVERICK PANDA",
				"BRONZE EDISON",
				"SODIUM",
				"Salmon Typhoon"
			],
			"source_name": "MISPGALAXY:APT4",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "6fbff48b-7a3e-4e54-ac22-b10f11e32337",
			"created_at": "2022-10-25T16:07:23.318008Z",
			"updated_at": "2026-04-10T02:00:04.539063Z",
			"deleted_at": null,
			"main_name": "APT 4",
			"aliases": [
				"APT 4",
				"Bronze Edison",
				"Maverick Panda",
				"Salmon Typhoo",
				"Sodium",
				"Sykipot",
				"TG-0623",
				"Wisp Team"
			],
			"source_name": "ETDA:APT 4",
			"tools": [
				"Getkys",
				"Sykipot",
				"Wkysol",
				"XMRig"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "f2ce5b52-a220-4b94-ab66-4b81f3fed05d",
			"created_at": "2025-08-07T02:03:24.595597Z",
			"updated_at": "2026-04-10T02:00:03.740023Z",
			"deleted_at": null,
			"main_name": "BRONZE FIRESTONE",
			"aliases": [
				"APT19 ",
				"C0d0s0",
				"Checkered Typhoon ",
				"Chlorine ",
				"Deep Panda ",
				"Pupa ",
				"TG-3551 "
			],
			"source_name": "Secureworks:BRONZE FIRESTONE",
			"tools": [
				"9002",
				"Alice's Rabbit Hole",
				"Cobalt Strike",
				"Derusbi",
				"PlugX",
				"PoisonIvy",
				"PowerShell Empire",
				"Trojan Briba",
				"Zuguo"
			],
			"source_id": "Secureworks",
			"reports": null
		}
	],
	"ts_created_at": 1775434947,
	"ts_updated_at": 1775826703,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/8d4c669ba1eb89136a3c362cf15ad8afc21f48e3.pdf",
		"text": "https://archive.orkl.eu/8d4c669ba1eb89136a3c362cf15ad8afc21f48e3.txt",
		"img": "https://archive.orkl.eu/8d4c669ba1eb89136a3c362cf15ad8afc21f48e3.jpg"
	}
}