About The Project

Given the recent news of the Meow attacks, I was curious about obtaining malware data related to Elasticsearch attacks. I’m a huge fan of Elasticsearch and use it heavily in my side-projects. I’m aware of the dangers of exposing a fresh database install on the open internet. So I simply set up a netcat listener and redirected the output to a file. I was pleasantly surprised at how successful this was. There was absolutely nothing done to mimic Elasticsearch functionality, but rather a plain and simple TCP listener on port 9200 (the default Elasticsearch port). This is the story of how a simple netcat listener can lead to an evening of reversing fun.

Initial Exploit & Dropper

The origin of this story starts with a pretty suspicious looking post request shown below. A quick search of some of the body parameters led me to this Trend Micro blog that I referenced throughout my analysis.

The initial exploit is taking advantage of CVE-2015-1427/CVE2014-3120, which results in remote code execution on the target. Taking a look at the POST of the body, we can actually see that a simple Java string builder converts the ASCII characters into the individual numbers that make up the wget command which downloads “init[.]sh”. This becomes the initial dropper for three additional payloads.

The initial dropper is a 900+ line bash script that kills several processes that are associated with other known crypto currency miners. Then the script downloads three additional modules (networkservice, sysguard, and sysupdate), and sets up persistence. A subset of the processes being killed can be seen below.

Next, cron is modified with a 30-minute timer to run “update .sh” which is the same content as init .sh If the script is running with UID 0, a public key is added to the root user’s authorized keys. Then, The last three modules are downloaded to /etc/ if root running as a root user or /tmp/ if non-root.

Finally, the ports 3333, 5555, 7777, 9999 and IP address 43[.]245[.]222[.]57 are explicitly dropped.

To recap the dropper does the following:

1. Kill selinux/app armor processes
2. Kill processes associated with crypto currency miners
3. Runs chattr -i on /etc/{sysupdate,networkserviced config.json}, /root/.ssh/authorized_keys
4. Adds entry to cron
5. Drops ssh key (if root).
6. Downloads additional modules from hardcoded staging server (to /etc/ or /tmp/ depending on perms).
7. Starts the Cryptocurrency miner with a nice value of 15.
8. Recently downloaded files (/etc/sysupdate, /etc/networkservice, /etc/config.json, /root/.ssh/authorized_keys) are chattr +i and chmod 777

One noticeable element is where the developers took extra care to ensure their persistence mechanism is locked in and what they overlooked. For example, the start of the script disabled SELinux, but never checks if it’s a RHEL host. Later, the script tries to disable AppArmor. However, the nice value which controls the amount CPU time the scheduler allocates for a process is set to attempt to minimize the amount of CPU usage during crypto mining activities. Nuances like this and trying to think of software design choices made by the developer(s) particularly interest me.

Three Payloads

Networkservice

Networkservice appears to be a propagation utility used to spread this Cryptocurrency mining malware. While executing within a sandbox, sysupdate attempts to fetch a list of integers from a hardcoded staging server which is then converted to IPv4 addresses. To discover this functionality, in an isolated network I modified the /etc/hosts which pointed the staging server domain to localhost. I then stood up an Apache webserver which hosted files also obtained from the dropper.

After the file of decimal converted IPv4 addresses is downloaded, Sysupdate begins throwing a significant amount of exploits at the remote targets. There also were IPv4 addresses not resident within the dropped file being targeted. My static Golang-reversing skills are not the best, but a quick run of strings correlated to what I saw in Wireshark reveals several different exploits being thrown against the list of hosts obtained from the C2 server.

Below is a list of associated exploits being used by the utility.

After performing a network capture the following observed destination ports are being targeted:

• 34264
• 9200
• 8088
• 8080
• 7002
• 7001
• 6380
• 6379
• 1433
• 80

During a thirty second run in a network isolated environment, the Networkservice utility averaged roughly 1500 packets per-second.

While executing the binary under systrace, errors related to the number of open files this process was creatng were being thrown. This was due to the number of sockets being open by the malicious process. While the developers of the initial dropper took care to ensure the amount of CPU time wasn’t too significant, they failed to show the same amount of caution. The result is a significant amount of noise on the network.

Sysupdate

Sysupdate was a UPX packed version of the open-source XMRig miner. XMRig can use a JSON configuration file to specify what to mine, what pools to join, their usernames/password, etc… This is where the config.json file that’s also dropped is leverage. Below we can see the output running the utility interactively with the config file dropped by init.sh.

Sysguard

Sysguard is a Golang binary that sleeps for a period of time and then tries to download update.sh from the hardcoded staging server. Then update.sh is placed within /etc/ and added as a cron job. This serves as a persistence mechanism in the attacker’s toolkit, enabling the authors to only have to update init.sh in order to re-download other utilities or update their XMRig Miner configuration files. This was the only functionality I could see this utility serving, and given the purpose of the two other pieces, it made sense from an attacker perspective that this was a stand-alone tool. From my testing failing to be able to reach this server just causes the utility to sleep before trying to download again with a User-Agent of Go-http-client.

After adding the destination IP to an internal host to mock HTTP responses I was able to construct a pattern of life graph for the HTTP communication without having to perform any static analysis. The spike below shows the periods between checkins to re-download update.sh.

Finally, in-between requests sysguard attempts to see get file stats about network service from within the /etc/ or /tmp/ directory. This confuses me as the init.sh script handles this functionality as well.

Beyond The Blog

By no means is this a complete analysis of all the functionality within these binaries. Rather, it’s a quick look to understand their base functionality and how the attacker(s) are leveraging these utilities to move around the internet and perform Cryptocurrency mining-related activities. I’ve included the artifacts below if you’re interested in looking at some of these samples. If you’re interested in where to download them from, checkout Malshare for a free account!

While Cryptocurrency mining isn’t anything new in the wild west of the malware landscape, I do believe there’s some value in recreating what other researchers have published and perhaps findings aspects that they overlooked or studying what’s changed since a blog has been published. I encourage other homelab users to setup actual honeypots such as Cowrie or Glutton and start digging into malware analysis.

Artifacts

Staging IP: 185[.]181[.]10[.]234

Domain: de[.]gsearch[.]com[.]de

SSH KEY: ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC9WKiJ7yQ6HcafmwzDMv1RKxPdJI/oeXUWDNW1MrWiQNvKeSeSSdZ6NaYVqfSJgXUSgiQbktTo8Fhv43R9FWDvVhSrwPoFBz9SAfgO06jc0M2kGVNS9J2sLJdUB9u1KxY5IOzqG4QTgZ6LP2UUWLG7TGMpkbK7z6G8HAZx7u3l5+Vc82dKtI0zb/ohYSBb7pK/2QFeVa22L+4IDrEXmlv3mOvyH5DwCh3HcHjtDPrAhFqGVyFZBsRZbQVlrPfsxXH2bOLc1PMrK1oG8dyk8gY8m4iZfr9ZDGxs4gAqdWtBQNIN8cvz4SI+Jv9fvayMH7f+Kl2yXiHN5oD9BVTkdIWX [email protected]


8e9957b496a745f5db09b0f963eba74e  miner_payloads/networkservice (UPX)
c31038f977f766eeba8415f3ba2c242c  miner_payloads/sysguard       (UPX)
149c79bf71a54ec41f6793819682f790  miner_payloads/sysupdate      (UPX)

4cc8f97c2bf9cbabb2c2be292886212a  miner_payloads/init.sh   
4cc8f97c2bf9cbabb2c2be292886212a  miner_payloads/update.sh

bbfce19f23e8e263f535118d0f46b6ad  networkservice unpacked (golang) (propagater)
f01afd3d643dd984e09fe920a0d65962  sysguard unpacked  (golang)      (persistence)
f94330ea9011863cf14fcf5f7519c266  sysupdate unpacked (C/C++)       (crypto miner)


// config.json users
"user": "43zqYTWj1JG1H1idZFQWwJZLTos3hbJ5iR3tJpEtwEi43UBbzPeaQxCRysdjYTtdc8aHao7csiWa5BTP9PfNYzyfSbbrwoR.1130"
"user": "3HVQkSGfvyyQ8ACpShBhegoKGLuTCMCiAr.1130"