In-Depth

Anatomy of a Self-Inflicted Ransomware Attack

See the destructive path of an intentional ransomware exploit in a lab environment consisting of Linux and Windows workstations and servers, and learn how implementing some simple steps will ensure you can recover from such an attack.

• By André Ruschel
• 10/02/2017

Ransomware attacks are nothing new, but they have inten­sified at an alarming pace this summer. The latest wave of ransomware, the malicious software that encrypts and thereby blocks access to files and often to entire enterprise infrastructures until victims pay ransoms, has shut down several large global organizations for a number of days. Some victims reportedly took a few weeks to recover.

Ransomware exploits such as WannaCry/WannaCrypt/PetrWrap/SambaCry/Petya/NotPetya (W/WC/PW/SC/P/NP), use increasingly more sophisticated phishing and social engineering techniques than prior variants. The exploits still take advantage of the fact that many organizations haven't employed best practices to protect themselves from the risks they face from these attacks. When struck by ransomware, most organizatons must seek help from authorities and information security experts. Remediation and containment often require sophsticated countermeasures such as the use of cybernetics, an artifical intelligence-based forensic technique.

IT professionals who manage Windows, Linux and macOS systems, along with mobile devices, face a real challenge with this new wave of malicious software circling the Internet in search of easy targets, especially organizations with vulnerabilities in their OSes and other suites that are typically not patched properly. While proper patching is a prerequisite for protecting against ransomware, ensuring interoperability between OSes with different versions and different protocols is also an essential part of that process. To understand why this is important, I created a test lab where I infected PCs and servers with the W/WC/PW/SC/P/NP ransomware variants.

The reason I simulated attacks of these various ransomware strains was to analyze their behavior and illustrate what the worms are and what types of files they tend to encrypt. From there, I created a scenario with Windows Server 2016 and Active Directory, as well as a Linux server with Samba and, finally, Windows and Linux workstations joined into the AD domain. I'll describe how I entered the workstations and the Linux server into the Windows Server domain—because Windows now manages the Linux permissions—then I'll show how to update Samba on Linux and, finally, I'll identify which worm created the malicious environment and how to create file extenstions to protect yourself from compromise.

WannaCry
Native changes based on the Eternalblue code was created by the National Security Agency (NSA) as a cyberweapon and leaked in April by a hacker group called Shadow Brokers. WannaCry exploits a vulnerability in the Windows Server Message Block (SMB) protocol on ports 139 and 445 as described in a late June Redmondmag.com report. EternalBlue targeted Windows Server 2008 R2, Windows Server 2008, Windows XP, Windows Vista and Windows 7 (both x86 and x64 platforms).

WannaCry can encrypt a wide range of file types, including everything listed in Table 1.

Petya/PetrWrap/NotPetya
According to analysts, Petya originated from EternalBlue and EternalRomance code. It uses a remote code exploitation via TCP port 139 and 445 in addition to leveraging the PsExec (a Windows Sysinternals administration tool that allows admin­istrators to run commands on remote systems on other systems, with full interactivity and without having to install software manually) and Windows Management Instrumentation (WMI), which enables management of network devices and applications from Windows computing systems. Microsoft also confirmed that the first systems were infected through the auto­matic update mechanism of a Ukrainian third-party software product called M.E. Doc.

When Petya obtains local administrator permissions, it encrypts the entire disk and overwrites the Master Boot Record (MBR). But if it fails to obtain administrator privileges, Petya begins to encrypt the file types specified in Table 2.

The mode of operation of Petya suggests that the attack doesn't seem to just want to raise money, but also after the successful implementation, it leaves the destruction of the data and makes Windows inaccessible by disabling the MBR. Systems can be fixed by following Microsoft's bulletin MS17-010 or deactivating SMBv1 (KB2696547) files that were not affected.

Linux/Samba
While the Windows OS was the target of WannaCry, Samba installed on Linux systems was exploited by the SambaCry variant, with the same vulnerability in the SMB protocol. Samba is an open source project written at the beginning of 1992 and is widely used in Linux and Unix computers so that they can work with files and Windows print services. Samba connects a Linux client to Windows servers or Windows clients connected to Linux servers. In some scenarios, you can still use Samba as an LDAP server and authenticate and control access to a Windows/Linux network.

SambaCry and WannaCry are similar in that both exploit the vulnerability of the SMB protocol to find a network share that has the credentials with read/write permissions. Once it gains access, it attempts to copy a Linux library that was created with malicious code. According to Samba advisory CVE-2017-7494, the code execution vulnerability involves allowing a malicious client to upload a shared library to a writable share, and then causes the server to load and execute it.

Simulation Environment
The scenario created in my lab consisted of a server running Windows Server 2016 with Active Directory, a Linux server with Ubuntu Server having Samba installed (file server) and workstations with Windows 10, Windows 8/8.1, Windows 7 and Ubuntu Desktop 17.04 (see Figure 1). All are members of the Windows domain (andreruschel.br).

Ubuntu Server-Samba in Windows Server 2016
In order to manage permissions to access the directories on the Linux (Ubuntu) server, it had to be a member of the AD domain. To join the Linux server, I accessed the terminal as root and edited the /etc/hosts file by adding the following content: server2016 server2016.andreruschel.br 192.168.1.100, where:

Server IP: 192.168.1.100
Hostname: server2016
Domain: andreruschel.br

I then edited the /etc/resolv.conf file and added nameserver 192.168.1.100 Search andreruschel.br, where Windows Server IP is 192.168.1.100.

Kerberos
To install the packages on the Linux station, I opened the terminal as root and typed:

aptitude install krb5-user libpam-krb5 krb5-config libkrb53 libkadm55

I then edited the /etc/krb5.conf file and added the following content:

[libdefaults]
default_realm = ANDRERUSCHEL.BR
dns_lookup_realm = true
dns_lookup_kdc = true
ticket_lifetime = 12:00 am
Forwardable = yes
[realms]
ANDRERUSCHEL.BR = {
KDC = server2016.andreruschel.br
admin_server = server2016.andreruschel.br
default_domain = ANDRERUSCHEL.BR
  }
[domain_realm]
.andreruschel.br = ANDRERUSCHEL.BR
andreruschel.br = ANDRERUSCHEL.BR

Samba and Winbind
I installed the packages by typing the following:

apt-get install samba winbind smbclient samba-common smbfs

And edited the /etc/samba/smb.conf file by adding the following content (note that in security, use ads; realm use andreruschel.br):

Workgroup = andreruschel
Max log size = 50
Security = ads
password = server2016.andreruschel.br
realm = ANDRERUSCHEL.BR
idmap uid = 1000-2000000
idmap gid = 1000-2000000
template shell =/bin/bash
template homedir =/home/%U
winbind use default domain = true
winbind enum users = yes
winbind enum groups = yes
winbind separator = +
winbind refresh tickets = yes
winbind nested groups = yes

I edited the /etc/nsswitch.conf file adding the following content, where I must inform where it must get log-in information once I have users and groups:

Passwd: compat winbind
Group: compat winbind
shadow: compat

Configuring the Pluggable Authentication Module (PAM)
I edited /etc/pam.d/common-auth by adding the following content:

auth sufficient pam_unix.so
pam_winbind.so use_first_pass auth required
auth required pam_deny.so

And then I edited /etc/pam.d/common-session by adding the following content:

session required pam_permit.so
session optional pam_winbind.so
session required pam_unix.so
session optional/etc/skel/skel = pam_mkhomedir.so umask 0077
session optional pam_mount.so

Next, I edited /etc/pam.d/common-account by adding the following content:

account sufficient pam_unix.so
account required pam_winbind.so use_first_pass

I restarted Winbind by typing:

/etc/init.d/winbind restart

Testing Kerberos
Now, I'll describe how to test the Kerberos authentication using the user Administrator. On the Linux server, I opened the terminal as root and typed:

$ sudo Kinit [email protected]

If I have everything right, the following should display:

Using short domain name--ANDRERUSCHEL
Joined ' FSLINUX ' to ' andreruschel.br ' realm

Still in terminal mode of the Linux server, as root, I can bet a ticket by typing the command klist:

$ sudo Klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default: [email protected]
Valid starting Expires Service principal
krbtgt/04/07/17 15:34:06 04/10/18 01:34:09 ANDRERUSCHEL. [email protected]
renew until 04/07/17 15:34:06

Joining Linux Server in Active Directory
Performing the initial steps, I'll illustrate how to join the Ubuntu Server andreruschel.br in the Windows Server domain. In the terminal of the Linux server, I typed the following and then I entered the password for the user Administrator (Windows domain):

sudo net ads join-U Administrator

To verify if winbind can see AD users, I ran the command $ sudo wbinfo-u.

These actions resulted in the listing of AD properties:

fslinux\andreruschel
fslinux\anaruschel
fslinux\alexandre
fslinux\eduardo
fslinux\giovana
fslinux\viviani
Guest
Administrator

When using a Linux-based file server with Samba installed, you should have Linux and Windows workstations share direc­tories so they can access files on that server. Even though you have the Linux server with Samba updated (version 4.6.5) containing shares, files that will be consumed by Windows systems will be vulnerable if the Windows systems are infected by WannaCry/WannaCrypt. I'm referring to the files shared by the Linux server, which are documents with extensions targeted by malware, but if cited on the Linux server itself, this will not be compromised by the SMB vulnerability due to Samba being properly updated.

Before performing this procedure I made sure to perform the backup of smb.conf file.

I checked for new packages available and updated the Samba package as follows:

$ sudo apt-get update
$ sudo apt-get dist-upgrade

I then checked which version of Samba was running by typing smbstatus --version.

Before updating Samba I had to ensure that all dependencies were installed by running:

apt-get install acl attr autoconf build-essential bison \
Debhelper dnsutils xml docbook-xsl docbook-flex gdb krb5-user \
Libacl1-dev libaio-dev libattr1-dev libblkid-dev libbsd-dev \
Libcups2-dev libcap-dev libgnutls-dev libjson-perl \
Libldap2-dev libncurses5-dev libpam0g-dev libparse-yapp-perl \
Libpopt-dev libreadline-dev perl perl-modules pkg-config \
Python-all-dev python-dev python-dnspython python-crypto \
Xsltproc libgpgme11-dev zlib1g-dev python-gpgme python-m2crypto

Next, I had to stop the Samba service:

/etc/init.d/samba stop

And then I downloaded and extracted the source files:

wget https://www.samba.org/samba/ftp/samba-latest.tar.gz
tar xzf samba-latest.tar.gz
cd samba-4.6.5

I ran the following:

./configure
make
make install

And then restarted the service:

/etc/init.d/samba restart

In order to see if I was already running the updated version, I typed: smbstatus --version. I made sure I had the correct version, CVE-Samba 2017-7494.

Petya in Action
This was my favorite simulation, where I infected the computer with Petya. The PC had two hard drives running Windows 7 (see Figure 2).

The hard drive containing the OS that had the MBR was partially destroyed; however, the second hard drive had no damage on the MBR or even data that was compromised.

Protecting Data Backups
In my test lab, I renamed the backup to prevent the ransomware from encrypting those files. Here are the steps I took:

1. Backups on external and internal disk or even to the backup tool should generate files with known extensions, which are cited as targets of these variants.

2. The backups on the other drives should have the extensions .7z, .zip, .rar or .sql.

3. I included the following script after the execution of the backup tool to rename multiple files at once:

Rename's/\ .7z $/@andreruschel/\. ' * .7z

forfiles/P e:\backup\/c "cmd/c @path rename @fname. @andreruschel"

Use the following path:

e:\backup—where are the backup files

.@andreruschel—extension to be given to the archives

Note that I renamed all files to .@andreruschel before infecting with W/WC/PW/SC/P/NP (see Figure 3).

After infection with W/WC/PW/SC/P/NP the files weren't encrypted because the @andreruschel extension wasn't part of the extensions targets.

Once this was done, I simply removed the hard drive and put it in another computer and ran the following script to rename all the files to .7z again (see Figure 4):

forfiles/P e:\backup\/c "cmd/c @path rename @fname .7z"

After the processes were completed, all files were intact.

Analysis and Challenges
In simulating these ransomware attacks in my lab environment, I took into consideration a multi-OS environment that's interoperable. However, whether you have a Windows- or Linux-only environment, you should always keep your OSes and other suites or applications properly updated.

All virtual worms cited exploited system vulnerabilities where administrators failed to apply proper security updates. There's no end to this problem in sight so it's essential to be prepared for the next inevitable attack.