A Steganography sample malware

[B. R. 'BeAr' Ederson]

| I describe 2 things: There are possibilities for general (heuristic)
| detection of abnormal formed data file sections.

What's the second?

| And your described method has to be refined to really be useful.

That's the second. (And maybe the method isn't worth the effort of
refining, at all...)

Why don't you experiment with your idea of steganographic content surviving
more than one compression? And report the results here? That would be a
real contribution.

You don't get! I posted the results: The first picture I choose to
manipulate the way you suggested had barely half the data altered, if
you don't do a byte-by-byte comparison but allow realignment. The
streams of unaltered data comprise of several dozen to several hundred
bytes in a row. Enough to store code within. You can try by yourself.
But it isn't worth to further pursue this in such a trivial approach.

And I posted before, that outcome is supposed by design of the JPEG
compression algorithm. I could sit down and think of a method to alter
chrominance, too, using a method which doesn't render the picture
ugly/useless.

If you read (and understood) my first posting, you'd know by now, that
I regard the true and sustainable "disinfection" a non-trivial task.
Otherwise, similar topics wouldn't be military funded university
research themes. Whether this degree of knowledge is required for
dealing with that topic depends (of course) on the sophistication
used by manufacturing the malicious sample.

BeAr

 

[Art]

From: "Art" <[email protected]>


|
| On what basis? How do users know which JPGs are infested and which
| aren't?
|
| Art
| http://home.epix.net/~artnpeg

You're not going to be getting JPEGs from reputable companies that have a Trojan embedded.
You'll be getting them at malicious locations. That's why detection is important. If they
are found, the file should summarily be deleted.

But detection of embedded malware is highly problematical and almost
non-existent at the present time. That's why I like the idea of
routinely scrubbing all JPGs.

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

 

[B. R. 'BeAr' Ederson]

What about rotating 90 degrees...or interleaving the bitmapped image
data and resaving?

IMHO, saving the file with another compression method or compression
level shows better results than most (any?) global operations. (That's
my - subjective - impression of comparing nearly related files.)

...of course, all could be gotten around with newer malware versions.

Yes. Sad but true. (At least to a degree which can not be foreseen
at the moment.)

BeAr

 

[Art]

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.

also known as lsb steganography
(http://en.wikipedia.org/wiki/Steganography#An_Example_from_Modern_Practice)

[snip]

Huh? They both execute. The companion causes the code in the
JPG to run.

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)...

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?

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

 

[Phil Weldon]

'BeAr' wrote, in part:
| That's the second. (And maybe the method isn't worth the effort of
| refining, at all...)
_____

So much for a fruitful discussion.

What I don't get is why you are claiming the non-existent.

Did you post '| You don't get! I posted the results: The first picture I
choose to
| manipulate the way you suggested had barely half the data altered, if
| you don't do a byte-by-byte comparison but allow realignment.'
steganographically?

And I don't get why you treat a suggestion for an experiment as an excuse
for a polemic.

Phil Weldon

message | On Sun, 25 Jun 2006 19:33:36 GMT, Phil Weldon wrote:
|
| >| I describe 2 things: There are possibilities for general (heuristic)
| >| detection of abnormal formed data file sections.
| >
| > What's the second?
| >
| >| And your described method has to be refined to really be useful.
|
| That's the second. (And maybe the method isn't worth the effort of
| refining, at all...)
|
| > Why don't you experiment with your idea of steganographic content
surviving
| > more than one compression? And report the results here? That would be
a
| > real contribution.
|
| You don't get! I posted the results: The first picture I choose to
| manipulate the way you suggested had barely half the data altered, if
| you don't do a byte-by-byte comparison but allow realignment. The
| streams of unaltered data comprise of several dozen to several hundred
| bytes in a row. Enough to store code within. You can try by yourself.
| But it isn't worth to further pursue this in such a trivial approach.
|
| And I posted before, that outcome is supposed by design of the JPEG
| compression algorithm. I could sit down and think of a method to alter
| chrominance, too, using a method which doesn't render the picture
| ugly/useless.
|
| If you read (and understood) my first posting, you'd know by now, that
| I regard the true and sustainable "disinfection" a non-trivial task.
| Otherwise, similar topics wouldn't be military funded university
| research themes. Whether this degree of knowledge is required for
| dealing with that topic depends (of course) on the sophistication
| used by manufacturing the malicious sample.
|
| BeAr
| --
|
===========================================================================
| = What do you mean with: "Perfection is always an illusion"?
=
|
===============================================================--(Oops!)===

 

[GEO Me]

"edgewalker" wrote:
Some dll extensioned files are very nearly identical to exes. Most are
indeed executable, but can't (as named) be executed by simply invoking
them from the gui or command line.

I have looked at other DLL files and, looking at them on Notepad, I
had noticed what you mentioned; that was why I was surprised to see
that the ones included on the zipped Bagle were formed by ASCII
characters. It made me wonder what was the information included in the
extra file. Any guesses?

Geo

 

[Art]

On Mon, 26 Jun 2006 00:12:26 GMT, "Phil Weldon"

BTW, Phil, I did try a experiment altering the brightness slightly
and it did result in all three vendors that normally alert then not
alerting. I use IrfanView which might not be the best for the
purpose since when I Save the altered image it has a "Save
qaulity" slider which ranges from 0 to 100%. I'm concerned
that even with a 100% setting, there may be changes to
the original in addition to just brightness. Also, with just a simple
small cartoonish image as the Frog, any subjective judgements
as to discernable differences to my eye and brain betweeen
the original and the altered image are worthless in this case.
You can really make pretty drastic changes to brightness,
colors, contrast and gamma correction without noticeable
changes in to the eye in this particular case, or at least to
the subjective picture quality.

Loss of detection by av is one thing, and viability is another
matter. The proof of the pudding, as always, is whether or
not the embedded code has been rendered unworkable and
harmless. But it's pointless for me to try viability tests on a
goat machine without knowing _exactly_ how the image is
modified. I think for that, I would need far better tools and
preparation than I have.

I thought though that you might be interested in the result
of a sort of "quick and dirty" test anyway. I still think you have
a good idea ... at least until proven otherwise. I also think
quite a extensive develpment and testing project is required to
determine whether or not the idea is truly feasible.

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

 

[Phil Weldon]

'Art' wrote, in part:
| BTW, Phil, I did try a experiment altering the brightness slightly
| and it did result in all three vendors that normally alert then not
| alerting.

Thanks for the reply Art. Since I don't have a sample image, I can't try it
myself. Applications like 'Photo Paint' in the Corel Draw suite and Adobe
PhotoShop offer a lot more choices, including customized plug-in filters.

Phil Weldon

| On Mon, 26 Jun 2006 00:12:26 GMT, "Phil Weldon"
|
| BTW, Phil, I did try a experiment altering the brightness slightly
| and it did result in all three vendors that normally alert then not
| alerting. I use IrfanView which might not be the best for the
| purpose since when I Save the altered image it has a "Save
| qaulity" slider which ranges from 0 to 100%. I'm concerned
| that even with a 100% setting, there may be changes to
| the original in addition to just brightness. Also, with just a simple
| small cartoonish image as the Frog, any subjective judgements
| as to discernable differences to my eye and brain betweeen
| the original and the altered image are worthless in this case.
| You can really make pretty drastic changes to brightness,
| colors, contrast and gamma correction without noticeable
| changes in to the eye in this particular case, or at least to
| the subjective picture quality.
|
| Loss of detection by av is one thing, and viability is another
| matter. The proof of the pudding, as always, is whether or
| not the embedded code has been rendered unworkable and
| harmless. But it's pointless for me to try viability tests on a
| goat machine without knowing _exactly_ how the image is
| modified. I think for that, I would need far better tools and
| preparation than I have.
|
| I thought though that you might be interested in the result
| of a sort of "quick and dirty" test anyway. I still think you have
| a good idea ... at least until proven otherwise. I also think
| quite a extensive develpment and testing project is required to
| determine whether or not the idea is truly feasible.
|
| Art
| http://home.epix.net/~artnpeg

 

[4Q]

How exactly is this a good example tho? The user had to rename it to
get it to execute.

It's a good example of an exception to the companion stego executer.
i.e. the data is pseudo hidden in the picture, *but* the .bmp picture
data is also a complete working program.

Art is suggesting the jpegs themselves should be detected and removed,
because they pose a danger. I maintain that without win32.exe, they are
harmless.

I've acquired a sample of them, and I'm not sure if I will add them to
bughunter or not... I'm really not keen on the idea of scanning
jpegs...

*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 ;]])

Anyhow that being the case I guess you aren't going to be impressed
with this next little trick a mutual hacker friend of ours showed me
many years ago... How about a .vbs application that changes itself
into a .com application

*sound of fanfare*

without any modification to the code?!? Yes a schizophrenic
poly-morph application that flips from .vbs to .com then
..com to .vbs etc etc just by double clicking on it.

*clue time*

The trick has a vague similarity to the stego .bmp (if anyone can
work it out without me having to print the code here) and involves
machine code for 'decimal adjust AL after addition'

It's a very sad state if his ITW thing went anyplace.

Yeah it would never ever get ITW in a month of sundays but
is just an example of how a coder can think beyond the limits
of what systems were originally intended to do.

Like when you contacted the author of ASIC and said
"Hey great news, I've used your ASIC tool for virus! bet you
never thought anyone would do that" *impressed?!* *grin*


4Q

 

[B. R. 'BeAr' Ederson]

On Mon, 26 Jun 2006 00:12:26 GMT, Phil Weldon wrote:

---------- restored snipped text --------------------------

So much for a fruitful discussion.

I don't think, whether it is wise to answer, at all. But I'd like to
assure you, that you still walk another path in this discussion as
I do. The sentence in parenthesis doesn't mean that I consider your
approach wrong. Quite the opposite. It just says, that it *may*
prove unusable. And to sort that out isn't a task for *testing* a
couple of images, but for *research*.

What I don't get is why you are claiming the non-existent.

Did you post
steganographically?

My first post on that subject:

Msg-ID: <[email protected]>

is already based on testing images and clearly states:

| If you try your suggestion on an image twice in a row to ensure the same
| compression settings, you'll find large portions of the images 2 and 3
| unchanged. Most of the data may shift position. But a trigger program
| can look for code snippets to get the offset of the malicious code.

After that, I explained the most likely reason. - Without going into the
depth, because I still think the more subtle details have to be sorted
out by specialists. Cryptography, steganography and compression can't
be dealt with in an amateur fashion. OTOH, showing that an approach is
*not* sufficient only needs one sample out of the line. And that's, what
I posted about.

And I don't get why you treat a suggestion for an experiment as an excuse
for a polemic.

No polemic on my side. Did your try your suggestion yourself? Under
the additional condition of unchanging compression method and strength?
(Which is necessary to rule out other influences when testing the effect
of brightness changes.)

BeAr

 

[B. R. 'BeAr' Ederson]

I'm concerned that even with a 100% setting, there may be changes to the
original in addition to just brightness.

Huh? If the former compression wasn't 100%, too, the images will have
*significantly* other data streams. Just save an *unchanged* image
with 100% to test. The JPEG algorithm changes quantisation step
width and the like according to the compression factor.

BeAr

 

[B. R. 'BeAr' Ederson]

Huh? If the former compression wasn't 100%, too, the images will have
*significantly* other data streams. Just save an *unchanged* image
with 100% to test. The JPEG algorithm changes quantisation step
width and the like according to the compression factor.

To try this, save the original image and the one compressed afterwards
with 100% into a lossless, non-compressing image format.

Remind: The JPEG format is lossy even at 100%. Only JPEG2000 introduces
lossless compression.

BeAr

 

[Art]

To try this, save the original image and the one compressed afterwards
with 100% into a lossless, non-compressing image format.

Well, BeAr, while I'm enthused about the idea, I would have to do a
lot of "boning up" work before pursuing any more tests. I lack the
requisite expertise and the tools in several areas. I've never even
studied the various image formats in detail.

Your suggestion of making sure the Saved image is lossless and
non-compressed interests me though. I might give that a try just
to see if the three av products still fail to alert on the result.
Doing a viability test though will be difficult, I would think. I
would have to allow the companion to run and then check to
see if it was succussful in running the embedded code under
both conditions .... unmodified JPG and modified JPG. Makes
me wonder if there's a much easier way to determine that
the JPG has been rendered harmless. There again, I lack the
analysis tools and expertise.

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

 

[B. R. 'BeAr' Ederson]

Your suggestion of making sure the Saved image is lossless and
non-compressed interests me though. I might give that a try just
to see if the three av products still fail to alert on the result.

I made this suggestion for comparing equivalents of the memory imprint
of different versions of a picture. It removes the necessity of direct
memory access.

Doing a viability test though will be difficult, I would think.

IMHO, the testbed needed is the first question, which is difficult to
answer. Let's have a look a different possibilities of storing code
inside a *.jpg picture: (Not all qualify as steganography, but could
be efficient, nevertheless.)

- Usage (abuse) of standard header fields: Would show up garbage with
dedicated tools; usually unaffected by image manipulation; only
few transformations to different image file formats will retain this
data; can be deleted using standard tools
- Creation of hidden data streams: persistence depends on algorithm
for saving used by the image manipulation program; should not
survive format changes
- Embedding into the memory imprint of the picture: Image manipulation
may or may not successfully destroy the data; changed compression
factor will probably have the largest impact (as long as the visual
appearance of the image shall not be altered, noticeably); code may
be activated even within the other file format (that format can be
compressed or not compressed, when extraction is done from memory)
- Embedding in an intermediary result of decompression (for instance
luminance or chrominance data or the result of a predefined step of
decompression): Consequences of image manipulation and format
changes aren't predictable, as long as the storage algorithm of the
code is unknown; compression changes may show the best effect in
destroying the code, but may be non-effective for special crafted
data
- Embedding into the data stream of the image *file* (on disk): Could
survive image manipulation methods, as long as no compression
change is involved; usually destroyed by saving with another
compression factor; may survive lossless back-and-forth format
changes as long as the last saving as *.jpg is done with original
compression
- Core information storage: the code is embedded within the data
which endures the most radical image manipulation (transformation
to black and white and the like): needs huge image sizes for
moderate code amounts; probably combined with checksums and
autocorrection; will probably survive any non-destructive image
manipulation, format change,...
- Specially crafted noise data with redundance for checksums and
auto-correction: dto.

Makes me wonder if there's a much easier way to determine that the JPG
has been rendered harmless.

This would need knowledge about the algorithm used by the malware
and about the code inside the picture, IMHO. And even if the code
seems defunct: If the next version of the trigger program includes
some "parity" bytes, it may repair the whole thing, nevertheless.

Just a few thoughts. And not meant to be complete in any way.

BeAr

 

[Art]

I made this suggestion for comparing equivalents of the memory imprint
of different versions of a picture. It removes the necessity of direct
memory access.


IMHO, the testbed needed is the first question, which is difficult to
answer. Let's have a look a different possibilities of storing code
inside a *.jpg picture: (Not all qualify as steganography, but could
be efficient, nevertheless.)

- Usage (abuse) of standard header fields: Would show up garbage with
dedicated tools; usually unaffected by image manipulation; only
few transformations to different image file formats will retain this
data; can be deleted using standard tools
- Creation of hidden data streams: persistence depends on algorithm
for saving used by the image manipulation program; should not
survive format changes
- Embedding into the memory imprint of the picture: Image manipulation
may or may not successfully destroy the data; changed compression
factor will probably have the largest impact (as long as the visual
appearance of the image shall not be altered, noticeably); code may
be activated even within the other file format (that format can be
compressed or not compressed, when extraction is done from memory)
- Embedding in an intermediary result of decompression (for instance
luminance or chrominance data or the result of a predefined step of
decompression): Consequences of image manipulation and format
changes aren't predictable, as long as the storage algorithm of the
code is unknown; compression changes may show the best effect in
destroying the code, but may be non-effective for special crafted
data
- Embedding into the data stream of the image *file* (on disk): Could
survive image manipulation methods, as long as no compression
change is involved; usually destroyed by saving with another
compression factor; may survive lossless back-and-forth format
changes as long as the last saving as *.jpg is done with original
compression
- Core information storage: the code is embedded within the data
which endures the most radical image manipulation (transformation
to black and white and the like): needs huge image sizes for
moderate code amounts; probably combined with checksums and
autocorrection; will probably survive any non-destructive image
manipulation, format change,...
- Specially crafted noise data with redundance for checksums and
auto-correction: dto.


This would need knowledge about the algorithm used by the malware
and about the code inside the picture, IMHO. And even if the code
seems defunct: If the next version of the trigger program includes
some "parity" bytes, it may repair the whole thing, nevertheless.

Just a few thoughts. And not meant to be complete in any way.

BTW, I haven't yet located a suitable image manipulator that will Save
as lossless. I did a experiment this morning still using IrfanView and
I found that simply Saving the image as JPG at 100% quality is
sufficient to detroy detection by the three vendors. IOW, using
IrfanView, there's no need to change brightness or anything. I was
surprised at this result of checking file sizes:

NT1.JPG Original 25,277 bytes
NT1.JPG Saved by Irfan 1,643 bytes

NT2.JPG Original 36,214 bytes
NT2.JPG Saved by Irfan 1,634 bytes

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.

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

 

[B. R. 'BeAr' Ederson]

BTW, I haven't yet located a suitable image manipulator that will Save
as lossless.

IrfanView writes "Windows Bitmap" as uncompressed. This way you should
get an exact representation of the memory imprint of the currently
opened *.jpg file.

I did a experiment this morning still using IrfanView and
I found that simply Saving the image as JPG at 100% quality is
sufficient to detroy detection by the three vendors. IOW, using
IrfanView, there's no need to change brightness or anything. I was
surprised at this result of checking file sizes:

NT1.JPG Original 25,277 bytes
NT1.JPG Saved by Irfan 1,643 bytes

NT2.JPG Original 36,214 bytes
NT2.JPG Saved by Irfan 1,634 bytes

Interesting. Looks like the malware code is stored as "hidden data
stream". (As I called it in my last posting.) You may experiment with
advanced options (keep original EXIF/IPTC/Comments) to see, whether
the code is located in such fields. And you may test the structure
using this (or a similar) tool:

www.picturel.com/utils.html (JPEGInfo)

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.

Sounds reasonable. But to be sure... ;-)

BeAr

 

[Art]

IrfanView writes "Windows Bitmap" as uncompressed. This way you should
get an exact representation of the memory imprint of the currently
opened *.jpg file.

I just noticed there's a "lossless" plugin for Irfan which I've yet to
download.

Interesting. Looks like the malware code is stored as "hidden data
stream". (As I called it in my last posting.) You may experiment with
advanced options (keep original EXIF/IPTC/Comments) to see, whether
the code is located in such fields. And you may test the structure
using this (or a similar) tool:

I've been leaving those checked.

www.picturel.com/utils.html (JPEGInfo)

Got and tried it out, thanks.

Sounds reasonable. But to be sure... ;-)

I did some searching for a (preferably) freeware image converter, and
so far one freeware and one payware app seem to do a similar thing in
that they cut the file size down to about 1.5 KB. 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,
though I realize I'm getting ahead of myself here in saying that
But most likely it seems that such a simple scheme will work for the
particular method of embedding used in the subject JPG files. That IMO
would be cool. At least it seems quite promising at this point.

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

 

[edgewalker]

The trick has a vague similarity to the stego .bmp (if anyone can
work it out without me having to print the code here) and involves
machine code for 'decimal adjust AL after addition'

Go ahead and post it in acvsc. Reminds me of batman186 (IIRC)
which uses a script to com/com to script flip.

 

[edgewalker]

I have looked at other DLL files and, looking at them on Notepad, I
had noticed what you mentioned; that was why I was surprised to see
that the ones included on the zipped Bagle were formed by ASCII
characters. It made me wonder what was the information included in the
extra file. Any guesses?

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.

 

[Dustin Cook]

It's a good example of an exception to the companion stego executer.
i.e. the data is pseudo hidden in the picture, *but* the .bmp picture
data is also a complete working program.

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...

*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 ;]])

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.

You could hide code in just about any type of file you wanted. Whats
the point in the long run tho?

Anyhow that being the case I guess you aren't going to be impressed
with this next little trick a mutual hacker friend of ours showed me
many years ago... How about a .vbs application that changes itself
into a .com application

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.

without any modification to the code?!? Yes a schizophrenic
poly-morph application that flips from .vbs to .com then
.com to .vbs etc etc just by double clicking on it.

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.

The trick has a vague similarity to the stego .bmp (if anyone can
work it out without me having to print the code here) and involves
machine code for 'decimal adjust AL after addition'

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.

</end of hax0r tricks>

hax0r tricks based on old old schoolness.

Yeah it would never ever get ITW in a month of sundays but
is just an example of how a coder can think beyond the limits
of what systems were originally intended to do.

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

Like when you contacted the author of ASIC and said
"Hey great news, I've used your ASIC tool for virus! bet you
never thought anyone would do that" *impressed?!* *grin*

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.

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.