While no two organizations are the same, they can learn from one another's mistakes. A step-by step analysis of a ransomware investigation can prove fruitful in helping organizations learn where they might be vulnerable and the steps they should take to avoid a similar cyberattack.
At the 2020 (ISC)² Security Congress, SCADAfence CEO Elad Ben-Meir took the virtual stage to share details of a targeted industrial ransomware attack against a large European manufacturer earlier this year. His discussion of how the attacker broke in, the collection of forensic evidence, and the incident response process offered valuable lessons to an audience of security practitioners.
The firm learned of this attack late at night when several critical services stopped functioning or froze altogether. Its local IT team found ransom notes on multiple network devices and initially wanted to pay the attackers; however, after the adversaries raised their price, the company contacted SCADAfence's incident response team. Within the first seven hours of the attack, around 200 critical servers had been encrypted and the entire production network was down.
Before it arrived on-site, the incident response team instructed the manufacturer to contain the threat to a specific area of the network and prevent the spread of infection, minimize or eliminate downtime of unaffected systems, and keep the evidence in an uncontaminated state.
"The initial idea was to try to understand where this was coming from, what machines were infected and what machines those machines were connected to, and if there was the ability to propagate additionally from there," said Ben-Meir in his talk.
Responders began collecting evidence before they arrived on-site. They asked the local IT team to gather data such as images of affected systems, images of log files and configuration files, and anything that might contain information that could prove helpful to the investigation. This had to be done in a timely manner, he stressed, as "there is lots of information of importance to the timeline of an attack." If a timeline changes, it's harder to collect key forensic evidence.
At the scene, the team began looking at machines that showed signs of infection and those that could be central hubs for deploying payloads. The main controller, for one, communicates with machines on the network and could be valuable to an attacker. Responders looked for devices with signs of malicious activity, such as attack tools that could lead to further propagation.
"That gave us a unique picture of understanding who communicates with who, and how an attack could be stopped in its tracks by identifying those connections," Ben-Meir explained.
The forensic team inspected machine configuration, suspicious executables, file time stamps, log files, and event logs. Suspicious executables and binary files were sent to the reverse engineering team for further analysis.
Catching the Culprit
Analysis quickly taught the investigators where the attacks were coming from, what tools were used, and indicators of compromise from binaries and executables collected. "Merging that with the data we have on network topology, and how the network behaves, gave substantial visibility into the event itself," Ben-Meir said.
A few hours after arriving on the scene, the researchers noticed network scanning activity from a machine that was absent from their list of infected devices. Its scanning was not visible in the firewall logs because some of the networks had been bridged using a network interface card (NIC) on the machine rather than routing through the firewall. The manufacturer wasn't aware of these configurations and assumed all cross-segment traffic was routed through the firewall.
The incident response team could see the attackers trying to scan different segments of the network and noticed abnormalities, including a payload moving from one segment to another. Ben-Meir said he believes this was not the work of an advanced attacker but rather a script kiddie or nonprofessional cybercriminal.
Still, the attackers employed several methods to infiltrate their target: They disabled Windows updates and tried to conceal their activity by hiding executables in legitimate folders. They disabled endpoint protections, locked input devices during encryption so employees couldn't stop the encryption process, and used tools like Mimikatz in the attack infrastructure.
Within 10 hours of arriving on-site, the situation was under control. Investigators realized the infected machine was a third-party device managed by an external contractor; its sole purpose was to enter the operational technology network to provide maintenance and support. The machine had an external IP address, which made it difficult to find in the firewall logs. It had an RDP port open to the Internet, was unpatched, and its firewall was disabled, Ben-Meir added.
"It was very vulnerable, and it was at the edge, pointing to what was beforehand a very secure network," he explained, noting that this wasn't a one-off occurrence. In many customer firms, there is one unmanaged device that exposes the entire network and because of a lack of resilience, it could let an attacker propagate. It's crucial for organizations to better understand who connects to a network and whether the device is patched and has endpoint protection.
Ben-Meir also strongly urged firms to segment their networks. "The smaller segments are, the more tight and well-managed the segments are, the less likelihood of an adversary being able to propagate and then cause actual damage to the infrastructure and cause disruptions to manufacturing," he said. A well-prepared network with the right security controls and processes is difficult to attack, slows down the attackers, and allows defenders to take action.
Network segmentation is particularly crucial in OT environments, where patching isn't always possible. Understanding vulnerabilities on the network can help manufacturers and other industrial firms learn how to segment devices that lack patch management or endpoint security.