{
	"id": "203482f9-c72b-43b4-90bb-9a538512fd02",
	"created_at": "2026-04-06T00:21:23.962493Z",
	"updated_at": "2026-04-10T03:21:03.632105Z",
	"deleted_at": null,
	"sha1_hash": "d9b5942d25e92a654ed74ad3bb841c8a5755ae00",
	"title": "Cyber-Attack Against Ukrainian Critical Infrastructure | CISA",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 58516,
	"plain_text": "Cyber-Attack Against Ukrainian Critical Infrastructure | CISA\r\nPublished: 2021-07-20 · Archived: 2026-04-05 21:55:02 UTC\r\nDescription\r\nOn December 23, 2015, Ukrainian power companies experienced unscheduled power outages impacting a large number of\r\ncustomers in Ukraine. This report provides an account of the events that took place based on interviews with company\r\npersonnel. \r\nUpdated July 20, 2021: The U.S. Government attributes this activity to Russian nation-state cyber actors and assess that\r\nRussian nation-state cyber actors conducted a cyber campaign against Ukrainian critical infrastructure. For more\r\ninformation on Russian malicious cyber activity, refer to us-cert.cisa.gov/Russia.\r\nSUMMARY\r\nOn December 23, 2015, Ukrainian power companies experienced unscheduled power outages impacting a large number of\r\ncustomers in Ukraine. In addition, there have also been reports of malware found in Ukrainian companies in a variety of\r\ncritical infrastructure sectors. Public reports indicate that the BlackEnergy (BE) malware was discovered on the companies’\r\ncomputer networks, however it is important to note that the role of BE in this event remains unknown pending further\r\ntechnical analysis.\r\nAn interagency team comprised of representatives from the National Cybersecurity and Communications Integration Center\r\n(NCCIC)/Industrial Control Systems Cyber Emergency Response Team (ICS-CERT), U.S. Computer Emergency Readiness\r\nTeam (US-CERT), Department of Energy, Federal Bureau of Investigation, and the North American Electric Reliability\r\nCorporation traveled to Ukraine to collaborate and gain more insight. The Ukrainian government worked closely and openly\r\nwith the U.S. team and shared information to help prevent future cyber-attacks.\r\nThis report provides an account of the events that took place based on interviews with company personnel. This report is\r\nbeing shared for situational awareness and network defense purposes. ICS-CERT strongly encourages organizations across\r\nall sectors to review and employ the mitigation strategies listed below.\r\nAdditional information on this incident including technical indicators can be found in the TLP GREEN alert (IR-ALERT-H-16-043-01P and subsequent updates) that was released to the US-CERT secure portal. US critical infrastructure asset owners\r\nand operators can request access to this information by emailing ics-cert@hq.dhs.gov .\r\nDETAILS\r\nThe following account of events is based on the interagency team’s interviews with operations and information technology\r\nstaff and leadership at six Ukrainian organizations with first-hand experience of the event. Following these discussions and\r\ninterviews, the team assesses that the outages experienced on December 23, 2015, were caused by external cyber-attackers.\r\nThe team was not able to independently review technical evidence of the cyber-attack; however, a significant number of\r\nindependent reports from the team’s interviews as well as documentary findings corroborate the events as outlined below.\r\nThrough interviews with impacted entities, the team learned that power outages were caused by remote cyber intrusions at\r\nthree regional electric power distribution companies (Oblenergos) impacting approximately 225,000 customers. While\r\npower has been restored, all the impacted Oblenergos continue to run under constrained operations. In addition, three other\r\norganizations, some from other critical infrastructure sectors, were also intruded upon but did not experience operational\r\nimpacts  \r\nThe cyber-attack was reportedly synchronized and coordinated, probably following extensive reconnaissance of the victim\r\nnetworks. According to company personnel, the cyber-attacks at each company occurred within 30 minutes of each other\r\nhttps://www.us-cert.gov/ics/alerts/IR-ALERT-H-16-056-01\r\nPage 1 of 3\n\nand impacted multiple central and regional facilities. During the cyber-attacks, malicious remote operation of the breakers\r\nwas conducted by multiple external humans using either existing remote administration tools at the operating system level or\r\nremote industrial control system (ICS) client software via virtual private network (VPN) connections. The companies\r\nbelieve that the actors acquired legitimate credentials prior to the cyber-attack to facilitate remote access.\r\nAll three companies indicated that the actors wiped some systems by executing the KillDisk malware at the conclusion of\r\nthe cyber-attack. The KillDisk malware erases selected files on target systems and corrupts the master boot record, rendering\r\nsystems inoperable. It was further reported that in at least one instance, Windows-based human-machine interfaces (HMIs)\r\nembedded in remote terminal units were also overwritten with KillDisk. The actors also rendered Serial-to-Ethernet devices\r\nat substations inoperable by corrupting their firmware. In addition, the actors reportedly scheduled disconnects for server\r\nUninterruptable Power Supplies (UPS) via the UPS remote management interface. The team assesses that these actions were\r\ndone in an attempt to interfere with expected restoration efforts.\r\nEach company also reported that they had been infected with BlackEnergy malware however we do not know whether the\r\nmalware played a role in the cyber-attacks. The malware was reportedly delivered via spear phishing emails with malicious\r\nMicrosoft Office attachments. It is suspected that BlackEnergy may have been used as an initial access vector to acquire\r\nlegitimate credentials; however, this information is still being evaluated. It is important to underscore that any remote access\r\nTrojan could have been used and none of BlackEnergy’s specific capabilities were reportedly leveraged.\r\nMITIGATION\r\nThe first, most important step in cybersecurity is implementation of information resources management best practices. Key\r\nexamples include: procurement and licensing of trusted hardware and software systems; knowing who and what is on your\r\nnetwork through hardware and software asset management automation; on time patching of systems; and strategic\r\ntechnology refresh.\r\nOrganizations should develop and exercise contingency plans that allow for the safe operation or shutdown of operational\r\nprocesses in the event that their ICS is breached. These plans should include the assumption that the ICS is actively working\r\ncounter to the safe operation of the process.\r\nICS-CERT recommends that asset owners take defensive measures by leveraging best practices to minimize the risk from\r\nsimilar malicious cyber activity.\r\nApplication Whitelisting (AWL) can detect and prevent attempted execution of malware uploaded by malicious actors. The\r\nstatic nature of some systems, such as database servers and HMI computers, make these ideal candidates to run AWL.\r\nOperators are encouraged to work with their vendors to baseline and calibrate AWL deployments.NCCIC/ICS-CERT, Seven\r\nSteps to Effectively Defend Industrial Control Systems, https://ics-cert.us-cert.gov/sites/default/files/documents/Seven%20Steps%20to%20Effectively%20Defend%20Industrial%20Control%20Systems_S508C\r\nweb site last accessed February 25, 2016.\r\nOrganizations should isolate ICS networks from any untrusted networks, especially the Internet. All unused ports should be\r\nlocked down and all unused services turned off. If a defined business requirement or control function exists, only allow real-time connectivity to external networks. If one-way communication can accomplish a task, use optical separation (“data\r\ndiode”). If bidirectional communication is necessary, then use a single open port over a restricted network path.a\r\nOrganizations should also limit Remote Access functionality wherever possible. Modems are especially insecure. Users\r\nshould implement “monitoring only” access that is enforced by data diodes, and do not rely on “read only” access enforced\r\nby software configurations or permissions. Remote persistent vendor connections should not be allowed into the control\r\nnetwork. Remote access should be operator controlled, time limited, and procedurally similar to “lock out, tag out.” The\r\nsame remote access paths for vendor and employee connections can be used; however, double standards should not be\r\nallowed. Strong multi-factor authentication should be used if possible, avoiding schemes where both tokens are similar types\r\nand can be easily stolen (e.g., password and soft certificate).a\r\nhttps://www.us-cert.gov/ics/alerts/IR-ALERT-H-16-056-01\r\nPage 2 of 3\n\nAs in common networking environments, control system domains can be subject to a myriad of vulnerabilities that can\r\nprovide malicious actors with a “backdoor” to gain unauthorized access. Often, backdoors are simple shortcomings in the\r\narchitecture perimeter, or embedded capabilities that are forgotten, unnoticed, or simply disregarded. Malicious actors often\r\ndo not require physical access to a domain to gain access to it and will usually leverage any discovered access functionality.\r\nModern networks, especially those in the control systems arena, often have inherent capabilities that are deployed without\r\nsufficient security analysis and can provide access to malicious actors once they are discovered. These backdoors can be\r\naccidentally created in various places on the network, but it is the network perimeter that is of greatest concern.\r\nWhen looking at network perimeter components, the modern IT architecture will have technologies to provide for robust\r\nremote access. These technologies often include firewalls, public facing services, and wireless access. Each technology will\r\nallow enhanced communications in and amongst affiliated networks and will often be a subsystem of a much larger and\r\nmore complex information infrastructure. However, each of these components can (and often do) have associated security\r\nvulnerabilities that an adversary will try to detect and leverage. Interconnected networks are particularly attractive to a\r\nmalicious actor, because a single point of compromise may provide extended access because of pre-existing trust established\r\namong interconnected resources.NCCIC/ICS-CERT, Improving Industrial Control Systems Cybersecurity with Defense-in-Depth Strategies, https://ics-cert.us-cert.gov/sites/default/files/recommended_practices/NCCIC_ICS-CERT_Defense_in_Depth_2016_S508C.pdf , web site last accessed February 25, 2016.\r\nICS-CERT reminds organizations to perform proper impact analysis and risk assessment prior to taking defensive measures.\r\nICS-CERT also provides a recommended practices section for control systems on the ICS-CERT web site (http://ics-cert.us-cert.gov). Several recommended practices are available for reading or download, including Improving Industrial Control\r\nSystems Cybersecurity with Defense-in-Depth Strategies and Seven Steps to Effectively Defend Industrial Control Systems.\r\nOrganizations that observe any suspected malicious activity should follow their established internal procedures and report\r\ntheir findings to ICS-CERT for tracking and correlation against other incidents.\r\nFor more information on securely working with dangerous malware, please see US-CERT Security Tip ST13-003 Handling\r\nDestructive Malware at https://www.us-cert.gov/ncas/tips/ST13-003 .\r\nDETECTION\r\nWhile the role of BlackEnergy in this incident is still being evaluated, the malware was reported to be present on several\r\nsystems. Detection of the BlackEnergy malware should be conducted using the latest published YARA signature. This can be\r\nfound at: https://ics-cert.us-cert.gov/alerts/ICS-ALERT-14-281-01E. Additional information about using YARA signatures\r\ncan be found in the May/June 2015 ICS-CERT Monitor available at: https://ics-cert.us-cert.gov/monitors/ICS-MM201506.\r\nAdditional information on this incident including technical indicators can be found in the TLP GREEN alert (IR-ALERT-H-16-043-01P and subsequent updates) that was released to the US-CERT secure portal. US critical infrastructure asset owners\r\nand operators can request access to this information by emailing ics-cert@hq.dhs.gov .\r\nSource: https://www.us-cert.gov/ics/alerts/IR-ALERT-H-16-056-01\r\nhttps://www.us-cert.gov/ics/alerts/IR-ALERT-H-16-056-01\r\nPage 3 of 3",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://www.us-cert.gov/ics/alerts/IR-ALERT-H-16-056-01"
	],
	"report_names": [
		"IR-ALERT-H-16-056-01"
	],
	"threat_actors": [],
	"ts_created_at": 1775434883,
	"ts_updated_at": 1775791263,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/d9b5942d25e92a654ed74ad3bb841c8a5755ae00.pdf",
		"text": "https://archive.orkl.eu/d9b5942d25e92a654ed74ad3bb841c8a5755ae00.txt",
		"img": "https://archive.orkl.eu/d9b5942d25e92a654ed74ad3bb841c8a5755ae00.jpg"
	}
}