Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Threat Intelligence

11/16/2020
05:35 PM
Connect Directly
Twitter
LinkedIn
RSS
E-Mail
100%
0%

Breakdown of a Break-in: A Manufacturer's Ransomware Response

The analysis of an industrial ransomware attack reveals common tactics and proactive steps that businesses can take to avoid similar incidents.

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.

Related Content:

Manufacturing Sees Rising Ransomware Threat

The Changing Face of Threat Intelligence

New on The Edge: We Secured the Election. Now How Do We Secure Trust in Results?

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.

Kelly Sheridan is the Staff Editor at Dark Reading, where she focuses on cybersecurity news and analysis. She is a business technology journalist who previously reported for InformationWeek, where she covered Microsoft, and Insurance & Technology, where she covered financial ... View Full Bio
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Oldest First  |  Newest First  |  Threaded View
northdmr
50%
50%
northdmr,
User Rank: Strategist
11/17/2020 | 11:03:44 AM
Segmentation and/or NAC
Risk and vulnerabilities accepted by one affects many.  Segmenta tion is good startegy to limit the impact. NAC is better and would deny the 3rd party device to connect and would help minimize if not elimnate the threat.  DBN
Commentary
Cyberattacks Are Tailored to Employees ... Why Isn't Security Training?
Tim Sadler, CEO and co-founder of Tessian,  6/17/2021
Edge-DRsplash-10-edge-articles
7 Powerful Cybersecurity Skills the Energy Sector Needs Most
Pam Baker, Contributing Writer,  6/22/2021
News
Microsoft Disrupts Large-Scale BEC Campaign Across Web Services
Kelly Sheridan, Staff Editor, Dark Reading,  6/15/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
The State of Cybersecurity Incident Response
In this report learn how enterprises are building their incident response teams and processes, how they research potential compromises, how they respond to new breaches, and what tools and processes they use to remediate problems and improve their cyber defenses for the future.
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-23962
PUBLISHED: 2021-06-23
A cross site scripting (XSS) vulnerability in Catfish CMS 4.9.90 allows attackers to execute arbitrary web scripts or HTML via a crafted payload entered into the "announcement_gonggao" parameter.
CVE-2020-18657
PUBLISHED: 2021-06-23
Cross Site Scripting (XSS) vulnerability in GetSimpleCMS <= 3.3.15 in admin/changedata.php via the redirect_url parameter and the headers_sent function.
CVE-2020-18658
PUBLISHED: 2021-06-23
Cross Site Scriptiong (XSS) vulnerability in GetSimpleCMS <=3.3.15 via the timezone parameter to settings.php.
CVE-2020-18659
PUBLISHED: 2021-06-23
Cross Site Scripting vulnerability in GetSimpleCMS <=3.3.15 via the (1) sitename, (2) username, and (3) email parameters to /admin/setup.php
CVE-2021-29620
PUBLISHED: 2021-06-23
Report portal is an open source reporting and analysis framework. Starting from version 3.1.0 of the service-api XML parsing was introduced. Unfortunately the XML parser was not configured properly to prevent XML external entity (XXE) attacks. This allows a user to import a specifically-crafted XML ...