Colonial Pipeline ransomware attack

1. Brief of Colonial Pipeline ransomware attack

The Colonial Pipeline ransomware attack in 2021 was a significant cyber incident that impacted
critical infrastructure and caused disruptions to fuel supplies along the U.S. East Coast. Here are the
key details:

• Date: The attack occurred in May 2021.

• Target: Colonial Pipeline, one of the largest fuel pipeline operators in the United States,
responsible for transporting fuel from Texas to the Northeast.

• Ransomware: Colonial Pipeline fell victim to a ransomware attack, specifically involving a

variant of the DarkSide ransomware.

Impact:

• Operational Disruption: The attack forced Colonial Pipeline to shut down its operations
temporarily as a precautionary measure to contain the breach and prevent further damage.

• Fuel Supply Disruptions: The pipeline shutdown resulted in disruptions to fuel supplies
across several states on the East Coast, leading to concerns about potential fuel shortages.

Response and Recovery:

• Ransom Payment Controversy: Colonial Pipeline paid a ransom of approximately $4.4 million
in cryptocurrency (Bitcoin) to the attackers to regain control of its systems. This decision
sparked debates regarding ransom payments and cybersecurity practices.

• Restoration of Operations: Colonial Pipeline resumed operations after a few days, but it took
additional time for full functionality to be restored.

Investigations and Fallout:

• Investigations: Federal authorities, including the FBI, investigated the attack. The U.S.
government attributed the attack to a criminal group based in Eastern Europe.

• Policy Implications: The attack highlighted vulnerabilities in critical infrastructure and

sparked discussions about improving cybersecurity measures and regulations for such
entities.

The Colonial Pipeline ransomware attack underscored the vulnerabilities in critical infrastructure
systems, raising concerns about the potential impact of cyberattacks on essential services. It also
prompted discussions about cybersecurity practices, incident response, and the need for
collaboration between public and private sectors to enhance defenses against cyber threats.

2. The REvil ransomware Details

The REvil ransomware, also known as Sodinokibi, is a sophisticated strain of malware used in
ransomware attacks. While the intricacies of the malware's code and operation might not be fully
disclosed, understanding its general operational aspects can shed light on its functionalities:

a. Infection and Encryption:

 • Delivery: REvil commonly infiltrates systems through phishing emails, exploit kits, or
software vulnerabilities.

• Encryption: Once inside a system, it encrypts files, rendering them inaccessible. It often
targets a wide range of file types, encrypting data across the system.

b. Ransom Note and Extortion:

• Ransom Demand: After encrypting files, REvil displays a ransom note informing the victim
about the encryption and demanding payment in cryptocurrency (typically Bitcoin) for the
decryption key.

• Extortion Tactics: The ransom note often threatens to leak stolen data or permanently delete
files if the ransom is not paid within a specified time frame.

c. Encryption Techniques:

• Sophisticated Encryption: REvil uses strong encryption algorithms to encrypt files (RC4 &
Public Key), making decryption without the key practically impossible without the attackers'
assistance.

• File Modification: It alters file extensions or modifies file headers to prevent victims from
accessing their data.

d. Exploitation and Propagation:

• Exploiting Vulnerabilities: REvil might exploit known vulnerabilities in systems or software to

gain initial access and spread within a network.

• Lateral Movement: Once inside a network, it attempts to move laterally to infect and
encrypt as many systems as possible.

e. Payment and Communication:

• Cryptocurrency Payment: The attackers demand ransom payments in cryptocurrencies,

usually Bitcoin, to facilitate anonymity in transactions.

• Communication Channels: The attackers establish communication channels, often through

the dark web, to negotiate with victims and provide decryption instructions upon ransom
payment.

It's important to note that while understanding the operational aspects of REvil provides insight into
its mechanisms, the specifics of its code, infrastructure, and evolving tactics are continually changing
as cybercriminals adapt to security measures and exploit new vulnerabilities.

3. Revil attack vector (https://www.nomios.com/resources/what-is-revil-ransomware/)

REvil ransomware is a file blocking virus considered a serious threat that encrypts files after infection
and discards a ransom request message. The message explains that the victim needs to pay a ransom
in bitcoins and that when the ransom is not paid in time the demand doubles.

McAfee’s Advanced Threat Research team (ATR) observed the new ransomware family in the wild,
dubbed Sodinokibi (or REvil), at the end of April 2019.
The name Sodinokibi was discovered in the hash ccfde149220e87e97198c23fb8115d5a where
‘Sodinokibi.exe’ was mentioned as the internal file name; it is also known by the name of REvil.

REvil: Ransomware-as-a-Service

At first, REvil ransomware was observed propagating itself by exploiting a vulnerability in Oracle’s
WebLogic server. Similar to some other ransomware families, however, REvil is what is also called a
Ransomware-as-a-Service (RaaS). Ransomware-as-a-Service is where a group of people maintain the
code and another group, known as affiliates, spread the ransomware.

Such a RaaS model allows affiliates to distribute REvil ransomware in any way they want, such as
mass-spread attacks using exploit-kits and phishing campaigns, where other affiliates adopt a more
targeted approach by uploading tools and scripts to gain more rights and execute the ransomware in
the internal network of a victim or brute-forcing RDP access. McAfee has investigated several
campaigns spreading REvil, most of which had different modus operandi but they did notice many
started with a breach of an RDP server. McAfee also revealed that the code part responsible for the
random URL generation of REvil ransomware has similarities with regards to how it is generated in
the GandCrab malware.

According to McAfee 'overall, the code is very well written and designed to execute quickly to
encrypt the defined files in the configuration of the ransomware.'

Based on the code comparison analysis McAfee conducted between GandCrab and Sodinokibi
McAfee consider it a likely hypothesis that the people behind the Sodinokibi ransomware may have
some type of relationship with the GandCrab crew.
REvil Ransomware Functionalities

REvil ransomware world map overview

Based on visibility from McAfee's MVISION Insights, McAfee was able to generate an overview map
of REvil ransomware infections observed from May through August 23rd, 2019:
Detecting REvil ransomware

McAfee is detecting this family by the following signatures:

• “Ransom-Sodinokibi”

• “Ransom-REvil!”

MITRE ATT&CK techniques

The malware sample uses the following MITRE ATT&CK™ techniques:

• File and directory discovery

• File deletion

• Modify registry

• Query registry

• Registry modification

• Query information of the user

• Crypt files

• Destroy files

• Make C2 connections to send information of the victim

• Modify system configuration

• Elevate privileges

YARA rule
rule Sodinokobi

/*

This rule detects Sodinokobi Ransomware in memory in old samples and perhaps future.

*/

meta:

author = “McAfee ATR team”

version = “1.0”

description = “This rule detect Sodinokobi Ransomware in memory in old samples and perhaps
future.”

strings:

$a = { 40 0F B6 C8 89 4D FC 8A 94 0D FC FE FF FF 0F B6 C2 03 C6 0F B6 F0 8A 84 35 FC FE FF FF 88 84
0D FC FE FF FF 88 94 35 FC FE FF FF 0F B6 8C 0D FC FE FF FF }

$b = { 0F B6 C2 03 C8 8B 45 14 0F B6 C9 8A 8C 0D FC FE FF FF 32 0C 07 88 08 40 89 45 14 8B 45 FC 83
EB 01 75 AA }

condition:

all of them

Protecting against REvil ransomware/Sodinokibi

To protect your organisation against Sodinokibi, make sure your defence is layered. The actors either
buy, brute-force or spear-phish themselves into your company or use a trusted third-party that has
access to your network. Some guidelines for organisations to protect themselves include employing
sandboxing, backing up data, educating users, and restricting access.
 CVE-2019-8453 Detail
CWE-ID CWE Name Source

CWE-426 Untrusted Search Path NIST (https://cwe.mitre.org/data/definitions/426.html)

CWE-114 Process Control Check Point Software Technologies Ltd.

(https://cwe.mitre.org/data/definitions/114.html)

CWE-114: Process Control

CWE 114 Description: Executing commands or loading libraries from an untrusted source or in an
untrusted environment can cause an application to execute malicious commands (and payloads) on
behalf of an attacker.

Process control vulnerabilities take two forms: An attacker can change the command that the
program executes: the attacker explicitly controls what the command is.

An attacker can change the environment in which the command executes: the attacker implicitly
controls what the command means.

Process control vulnerabilities of the first type occur when either data enters the application from an
untrusted source and the data is used as part of a string representing a command that is executed by
the application. By executing the command, the application gives an attacker a privilege or capability
that the attacker would not otherwise have.

Example Usage of CWE 114: The code uses System.loadLibrary() to load code from a native library
named library.dll, which is normally found in a standard system directory. The problem here is that
System.loadLibrary() accepts a library name, not a path, for the library to be loaded. From the Java
1.4.2 API documentation this function behaves as follows: A file containing native code is loaded from
the local file system from a place where library files are conventionally obtained. The details of this
process are implementation-dependent. The mapping from a library name to a specific filename is
done in a system-specific manner. If an attacker is able to place a malicious copy of library.dll higher in
the search order than file the application intends to load, then the application will load the malicious
copy instead of the intended file. Because of the nature of the application, it runs with elevated
privileges, which means the contents of the attacker's library.dll will now be run with elevated
privileges, possibly giving them complete control of the system.

CWE-426: Untrusted Search Path

The product searches for critical resources using an externally-supplied search path that can point to
resources that are not under the product's direct control.

This might allow attackers to execute their own programs, access unauthorized data files, or modify
configuration in unexpected ways. If the product uses a search path to locate critical resources such
as programs, then an attacker could modify that search path to point to a malicious program, which
the targeted product would then execute. The problem extends to any type of critical resource that
the product trusts.
Some of the most common variants of untrusted search path are: In various UNIX and Linux-based
systems, the PATH environment variable may be consulted to locate executable programs, and
LD_PRELOAD may be used to locate a separate library. In various Microsoft-based systems, the PATH
environment variable is consulted to locate a DLL, if the DLL is not found in other paths that appear
earlier in the search order.

Example

This program is intended to execute a command that lists the contents of a restricted directory, then
performs other actions. Assume that it runs with setuid privileges in order to bypass the permissions
check by the operating system.

This code may look harmless at first, since both the directory and the command are set to fixed
values that the attacker can't control. The attacker can only see the contents for DIR, which is the
intended program behavior. Finally, the programmer is also careful to limit the code that executes
with raised privileges.

However, because the program does not modify the PATH environment variable, the following attack
would work:

• The user sets the PATH to reference a directory under the attacker's control, such as
"/my/dir/".
• The attacker creates a malicious program called "ls", and puts that program in /my/dir
• The user executes the program.
• When system() is executed, the shell consults the PATH to find the ls program
• The program finds the attacker's malicious program, "/my/dir/ls". It doesn't find "/bin/ls"
because PATH does not contain "/bin/".
• The program executes the attacker's malicious program with the raised privileges.