A Steganography sample malware

  • Thread starter Thread starter Art
  • Start date Start date
edgewalker said:
Steganography aside, what if the companoin used a cookie file or
other text filetype to do effectively the same thing? Do you really
want to scan all filetypes for all known encoding or compressing
algorithms?
Click to expand...

I'd rather not. You can hide code in just about any filetype
imaginable. I could even hide code in a series of mp3s in the meta tag
section.
They're going down the wrong path in alerting on these harmless files.
They will howevr achieve their ultimate goal of marketing FUD.
Click to expand...

That seems to be the idea. A jpeg scrubber. AV, antimalware whatever
should focus on the program that can reconstruct the data, not the
potential data itself. BugHunter will not be adding the jpegs to it's
database, as I don't feel they pose any real danger to anyone. Symantec
should be ashamed of themselves for giving into this false alarm crap.
Users are paranoid enough as it is, now you want various products
scanning for code thats harmless... Such a waste.
 
I just noticed there's a "lossless" plugin for Irfan which I've yet to
download.
Click to expand...

It is for some standard operations which can be done lossless (like
basic rotation and scrubbing of EXIF data). It would be interesting,
The freeware 2JPEG is a command line converter that makes it convenient
to write programs or batch programs to find all JPGs and filter out the
embedded code
Click to expand...

You surely know that IrfanView can be scripted (via command line or
<Batch conversation/Rename>), too?

BeAr
 
Some programs use the dll extension for what are equivalent to ini files or
the Windows registry. Some Windows dlls are libraries of icon graphic
data. It could be anything.
Click to expand...

Does not look like an ini file, and no icons here:

ucrjsyfzimaepnctcgbhyfvgrfkhdqohcpouckkitblmewxpbcweorvructcyy
lnnzesfrqkohbkyfcazcdjuxzlfcckliqhppfxtjacuvbuglwmvbttxuy......
...etc

May be Symantec should be adding it too?? :)


Geo
 
It is for some standard operations which can be done lossless (like
basic rotation and scrubbing of EXIF data). It would be interesting,
whether <Optimize JPG file> or <*don't* keep other APP markers>
results in any significant size changes on your pictures...
Click to expand...

I made note of that.
You surely know that IrfanView can be scripted (via command line or
<Batch conversation/Rename>), too?
Click to expand...

I'd like to find a small stand-alone.

Art
http://home.epix.net/~artnpeg
 
From: "Art" <[email protected]>

| Regulars here are aware that steganography is a technique
| of embedding malicious code in picture image files (and other
| files). Such files are themselves harmless since they require
| companion active malware to run the embedded code.

< snip >

So you guys have a *REAL* example to play with...

hxxp://countbest.net/pic/winlogon.jpg
Click to expand...

That one is different from the three you sent me. Bit Defender
doesn't alert on this one. Fortinet and Symantec do. Where did
you find the other ones?

Art
http://home.epix.net/~artnpeg
 
'David H. Lipman' wrote:
| So you guys have a *REAL* example to play with...
|
| hxxp://countbest.net/pic/winlogon.jpg
|
| http://www.dnsstuff.com/tools/whois.ch?ip=COUNTBEST.NET
|
_____

Da5id, thanks for the post (you have read "Snow Crash", I hope.)
The frog I get from the URL is a windows bit map, not a JPEG compressed
image.
There seem to be pixels in the white background of the image that are not
necessary, and that could contain meaningful data. But you have posted
about JPEG images, and this frog isn't one.

Phil Weldon

| From: "Art" <[email protected]>
|
|| Regulars here are aware that steganography is a technique
|| of embedding malicious code in picture image files (and other
|| files). Such files are themselves harmless since they require
|| companion active malware to run the embedded code.
|
| < snip >
|
| So you guys have a *REAL* example to play with...
|
| hxxp://countbest.net/pic/winlogon.jpg
|
| http://www.dnsstuff.com/tools/whois.ch?ip=COUNTBEST.NET
|
|
| --
| Dave
| http://www.claymania.com/removal-trojan-adware.html
| http://www.ik-cs.com/got-a-virus.htm
|
|
 
From: "Phil Weldon" <[email protected]>


| _____
|
| Da5id, thanks for the post (you have read "Snow Crash", I hope.)
| The frog I get from the URL is a windows bit map, not a JPEG compressed
| image.
| There seem to be pixels in the white background of the image that are not
| necessary, and that could contain meaningful data. But you have posted
| about JPEG images, and this frog isn't one.
|
| Phil Weldon
|

Snow Crash ?
You lost me.

Look at the URL and the location it is from.
What was true Today may not be true Tomorrow.
These sites change often.
 
From: "Phil Weldon" <[email protected]>


| Da5id, thanks for the post (you have read "Snow Crash", I hope.)
| The frog I get from the URL is a windows bit map, not a JPEG compressed
| image.
| There seem to be pixels in the white background of the image that are not
| necessary, and that could contain meaningful data. But you have posted
| about JPEG images, and this frog isn't one.
|
| Phil Weldon
|

For more samples, go to; alt.binaries.comp.virus
Subject: Steganography

However you will have to get the password for the ZIP file from me via email.
 
'David H. Lipman' wrote:
| So you guys have a *REAL* example to play with...
|
| hxxp://countbest.net/pic/winlogon.jpg
|
| http://www.dnsstuff.com/tools/whois.ch?ip=COUNTBEST.NET
|
_____

Da5id, thanks for the post (you have read "Snow Crash", I hope.)
The frog I get from the URL is a windows bit map, not a JPEG compressed
image.
There seem to be pixels in the white background of the image that are not
necessary, and that could contain meaningful data. But you have posted
about JPEG images, and this frog isn't one.
Click to expand...

Phil, send me a emial at artsown at epix dot net and I'll send you the
three JPGs.

Art
http://home.epix.net/~artnpeg
 
Art said:
On Sun said:
Art wrote:
[snip]
I don't know what you mean by "least significant bit method". If we
can stick with the subject JPGs for the time being, clearly the
malware isn't hidden at all.
Click to expand...
also known as lsb steganography
(http://en.wikipedia.org/wiki/Steganography#An_Example_from_Modern_Practice)

[snip]
Then it's not the jpg which gets executed. It's the "unknown"
companion which just slipped past your av scanner.
Huh? They both execute. The companion causes the code in the
JPG to run.
Click to expand...
if i'm not mistaken, the companion *extracts* the code from the jpg and
then runs it... the jpg itself is never actually run... that's how
steganography generally works anyways (the stego app extracts the hidden
information for subsequent use)...
Click to expand...

That's what I ASSumed when I fearlessly Opened the little froggies
in IrfanView. I don't know how to Run JPGs anyway :) Maybe you were
thinking of the possibility of disguised executeables that might Run
in Windows in spite of the file extension?
Click to expand...

actually, for a deviation from the steganography norm, i was thinking of
something a little more like the eicar standard anti-virus test file...
if something can be a *.com file and plain ascii text at the same time
it stands to reason that *.com/jpg combinations might be possible too...

but i suspect that's rather difficult to implement...
 
Dustin said:
A complete working program which requires a very stupid user to
knowingly rename it so that it can be executed. It's an example of
pointless code...
Click to expand...

Oh well I'll pass on the sentiment to the pointless author.

*shrug* I was talking about a .bmp that allows for machine code to
be inserted into its internal structure, .bmp and .jpg don't have
the same internals. (this kind of trick was used in notepad.exe as
well, but was never published ;]])
Click to expand...

Actually, your talking about island or cavity infection, right? And
that trick if you will was published several years ago. .bmp and jpg
aren't internally the same, no; but the same principles still apply.
Click to expand...

I don't recall the .bmp code being published. Maybe I published
it on 4Q site and forgot.
You could hide code in just about any type of file you wanted. Whats
the point in the long run tho?
Click to expand...

Well in this case it is the same as asking the mountaineer why he
climbs the mountain... totally ****ing pointless.
It's about as cool as my text to .com converter I wrote in 92... really
neat, but.. utterly useless. Well, unless you were into bbses. Then it
was kinda cool. Instead of your bbs.txt file, you could have
kewlbbs.com :) And if you had ansi support, it was really cool.
Click to expand...

That sounds like some ASM utils developed by 'clockwise software'
BAT2COM, ANSI menus into binaries etc etc

And it's not difficult to do. :) 4Q, you can't honestly be impressed by
hat tricks can you? If you are, do some reading into the old
commodores, cocos, etc. They have more. :)
Click to expand...

*Hmmmm* Maybe I am impressed with hat tricks, but I think you
didn't understand my bad description. I'm talking about a piece
of code that is both a .com and a .vbs without any modification
to the code, just by changing the extension i.e. program.com is
identical to program.vbs (the same MD5 hash) But the act of running
the code flips the extension.
The trick has a vague similarity to the stego .bmp (if anyone can

Which is no different then the eicar test file. It's written in
assembly, but uses a very specific character set, IE: executable text.
Boring, then, boring now.


hax0r tricks based on old old schoolness. :)
Click to expand...

So I guess it should be very easy for someone to print the
code in here for the .vbs/.com simple hat trick. Maybe even embed
it into that pointless .bmp stego executable.

*looking forward* :)))))

Systems were intended to follow instructions, it's not thinking outside
the box to provide it instructions.


True, but writing a virus in asic wasn't thinking outside the box. Asic
was a programming language, it was doing what I told it. Nothing more,
nothing less.
Click to expand...

True, it's not thinking outside the box, but I guess the author
was surprised to see his creation used like that.

The only thing I can say about the entire thing was I didn't have/need
any tutorials, I had to write the code all by myself, so my work really
is my own, it's not based on somebody elses work, like so much vx is.
Otherwise, their nothing special. That was thinking outside the box. :)
All original code. heh, so rare these days.
Click to expand...

Well there ya go, just what hacking is all about. Exploring and
finding out.


4Q
 
Maybe that info will give you a clue on the method used by the
bad guys in this case of embedding the code. I'd guess that
the embedded code was completely clobbered by whatever
IrfanVeiw does when it Saves the JPG at 100% quality without
any attempt at image manipulation by the user in any way.
Click to expand...

Irfanview will automatically zap anything in the file after the FF D9
end of image marker. I just tested it to see.

What does your hex editor say? Is it that simple?


Jim.
 
Irfanview will automatically zap anything in the file after the FF D9
end of image marker. I just tested it to see.

What does your hex editor say? Is it that simple?
Click to expand...

Not quite :) I took NT1.JPG and found several occurances of FF D9.
If I blindly truncate everything after the first occurance, I do wind
up with a seemingly normal froggie image with a file length of 886
bytes. If I use the Irfan Save method I get a file length of 1,634
bytes.

It's interesting that when I use the Irfan Save method on the 886
byte file, the result is a 1,634 byte file ... the same length
resulting from using the Irfan Save method on the original.

Art
http://home.epix.net/~artnpeg
 
Not quite :) I took NT1.JPG and found several occurances of FF D9.
If I blindly truncate everything after the first occurance, I do wind
up with a seemingly normal froggie image with a file length of 886
bytes. If I use the Irfan Save method I get a file length of 1,634
bytes.

It's interesting that when I use the Irfan Save method on the 886
byte file, the result is a 1,634 byte file ... the same length
resulting from using the Irfan Save method on the original.
Click to expand...

To add a little more info, I found that all four files have the same
identical characteristic in that truncating them just after the first
occurance of FF D9 results in a 886 byte froggie which Irfan "thinks"
is a legit JPG file. By four files, I mean in addition to NT1, 2, 3
I'm including WINLOGON.JPG. In this latter file I found only one
occurance of FF D9 and that's probably the file Jim was looking
at.

I looked at a few ordinary or normal JPG files and they have
FF D9 at the actual EOF while none of the Trojaned files do,
so that suggests a simple heuristic for sorting and continuing to
look further only if no FF D9 exists at the actual EOF. Thus a
scrubber specifically aimed at these types of Trojaned files wouldn't
have to touch normal files at all. I too now wonder if it might turn
out to be very simple. What would be the danger in using a
simple agorithm that sorts JPGs on the basis of requiring FF D9 at
actual EOF and if not, truncate everything after the first
occurance of FF D9? Or maybe just delete all such files
and not bother to truncate them at all? Or leave the decision
up to the user?

Makes me wonder why more av aren't using a such a simple heuristic
to at least flag these files as suspicious.

Art
http://home.epix.net/~artnpeg
 
To add a little more info, I found that all four files have the same
identical characteristic in that truncating them just after the first
occurance of FF D9 results in a 886 byte froggie which Irfan "thinks"
is a legit JPG file. By four files, I mean in addition to NT1, 2, 3
I'm including WINLOGON.JPG. In this latter file I found only one
occurance of FF D9 and that's probably the file Jim was looking
at.
Click to expand...

I haven't got any of the files. I just added some plaintext onto the
end of a smallish jpg on my machine here to see if Irfanview left it
in after "saving as" another jpg. It didn't, of course, because it was
only interested in the stuff up to the first (and only in this case)
end of image marker and used that for creating its new file. The fact
that the image is a bit bigger than the original is one of the quirks
of jpeg when saving a low grade image at a higher percentage.

This appending at the end of the file is a common technique in some of
the not very good steganography products which guillermito reversed a
few years back. A good read if you're interested.
http://www.guillermito2.net/stegano/


Jim.
 
I haven't got any of the files. I just added some plaintext onto the
end of a smallish jpg on my machine here to see if Irfanview left it
in after "saving as" another jpg. It didn't, of course, because it was
only interested in the stuff up to the first (and only in this case)
end of image marker and used that for creating its new file. The fact
that the image is a bit bigger than the original is one of the quirks
of jpeg when saving a low grade image at a higher percentage.
Click to expand...

Yep. It's nice that a method like that isn't required at all.
This appending at the end of the file is a common technique in some of
the not very good steganography products which guillermito reversed a
few years back. A good read if you're interested.
http://www.guillermito2.net/stegano/
Click to expand...

Yes it is indeed a good read. Your inputs have been helpful. Thanks.

Art
http://home.epix.net/~artnpeg
 
On Mon, 26 Jun 2006 20:22:43 GMT, David H. Lipman wrote:

[Download link]
So you guys have a *REAL* example to play with...
Click to expand...

Nothing great to play with. Just a *.jpg with flange mounted Trojan
code. The most simple variant we discussed. No need to think about
brightness image changes and the like. Just let IrfanView with the
*.jpg lossless plugin Art mentioned yesterday scrub off all spare
bytes ("optimize") and you're done. Save and clean.

If the image were bigger, the attached code could be a set up wrong
track to distract from another danger. But the rest of the image is
too small to think about that another time.

BeAr
 
On Mon, 26 Jun 2006 20:22:43 GMT, David H. Lipman wrote:

[Download link]
So you guys have a *REAL* example to play with...
Click to expand...

Nothing great to play with. Just a *.jpg with flange mounted Trojan
code. The most simple variant we discussed. No need to think about
brightness image changes and the like. Just let IrfanView with the
*.jpg lossless plugin Art mentioned yesterday scrub off all spare
bytes ("optimize") and you're done. Save and clean.
Click to expand...

Why bother with IrfanView? It's easy to detect the Trojanized JPGs.
No need to scrub them. Simply delete them.

Art
http://home.epix.net/~artnpeg
 
Back
Top