A Steganography sample malware

  • Thread starter Thread starter Art
  • Start date Start date
I've put JPG-SCAN.ZIP up at my web site for anyone interested.
It uses a a extremely simple algorithm for detecting the subject
samples. I had a collection of 78 .JPG files I had downloaded a
long time ago ... mostly pictures of various locations in Alaska. Of
these, 10 alerted my scanner since they had some kind of extraneous
bytes near the end of the file after the JPG end bytes. I have no
reason to think these 10 are actually Trojanized, but it's curious
that files like this are created somehow. I "cleaned" one of them
using IrfanView at 100% quality and the file size more than tripled
up to nearly a half meg from less than 200K. People will just have
to tinker around finding a quality percentage that's suitable for
them consistent with lower file sizes.

It was fun designing the scanner, and I might add other kinds
of simple but useful "oddball" detections, such as for Word DOC
embedded Trojans. The scanner can be speeded up considerably,
but for now there's little point in doing that since it takes less
than a minute to scan the 1,250 folders on my Win 2K PC main
partition.

Art
http://home.epix.net/~artnpeg
 
I've put JPG-SCAN.ZIP up at my web site for anyone interested.
It uses a a extremely simple algorithm for detecting the subject
samples. I had a collection of 78 .JPG files I had downloaded a
long time ago ... mostly pictures of various locations in Alaska. Of
these, 10 alerted my scanner since they had some kind of extraneous
bytes near the end of the file after the JPG end bytes. I have no
reason to think these 10 are actually Trojanized, but it's curious
that files like this are created somehow. I "cleaned" one of them
using IrfanView at 100% quality and the file size more than tripled
up to nearly a half meg from less than 200K. People will just have
to tinker around finding a quality percentage that's suitable for
them consistent with lower file sizes.
Click to expand...

Wouldn't it be better to simply truncate the files? Irfanview would
only ruin any hidden data in the files if it was mixed in with the
image datastreams (which it isn't).


Jim.
 
Wouldn't it be better to simply truncate the files? Irfanview would
only ruin any hidden data in the files if it was mixed in with the
image datastreams (which it isn't).
Click to expand...

No, IrfanView does truncate the files and remove the extraneous bytes
after the "end of JPG" marker bytes. IOW, it removes appendages.

My thinking on this first go-around with the scanner was that it would
not offer to modify files. That way "power users" at least could look
at the files flagged as suspicious in a hex editor and see what's
going on, so to speak. But now that you bring it up, I think I will
include a option to truncate the files as a convenience to users,
since that would eliminate the need to use Irfan (or other apps).
So far as I can determine, the scanner would only have to find
the first occurance of the "end of JPG" marker bytes and truncate
all bytes after that.

Art
http://home.epix.net/~artnpeg
 
If a JPG file that was flagged by JPG-SCAN.ZIP was really some sort of
malware, would it (could it) still contain a viewable image that could
be rendered by any typical viewer without resulting in any strange
behavior, error messages, etc?

I ran JPG-SCAN and found that it flags some legit files (such as
contained in C:\Program Files\Canon\PhotoStitch\Samples).

Of 50-odd files that it flagged for me, all of them open with Corel
Photo-Paint - but a few are dammaged images (some part of the image is
either washed out or missing).
 
If a JPG file that was flagged by JPG-SCAN.ZIP was really some sort of
malware, would it (could it) still contain a viewable image that could
be rendered by any typical viewer without resulting in any strange
behavior, error messages, etc?
Click to expand...

Yes, of course, the Trojanized samples I have (JPG of a little cartoon
frog) all look fine in a viewer.
I ran JPG-SCAN and found that it flags some legit files (such as
contained in C:\Program Files\Canon\PhotoStitch\Samples).
Click to expand...

I mentioned that I found 10 JPGs on my PC with appendages
and thus don't meet the proper JPG format. They all look fine
in a viewer.
Of 50-odd files that it flagged for me, all of them open with Corel
Photo-Paint - but a few are dammaged images (some part of the image is
either washed out or missing).
Click to expand...

Currently, my scanner uses a very simple criteria for calling a JPG
file suspicious. If there isn't a hex FF D9 at the end of the file but
there is a FF D8 at the start, it flags it. That's all that's
necessary for flagging the Trojanized samples I have. You see,
the Trojanized samples have the "end of jpg" FF D9 earlier in the
file. Now, chances are that the 50 files the scanner flagged for
you have a FF D9 somewhere in the file with appendages after
that ... just like the Trojanized samples I have. Your files have
apparently gotten corrupted somehow just as the 10 files I have
are corrupted. You can easily verify this using the search feature
of a hex editor. Take some of those 50 files and do a search for
FF D9. Again, chances are you'll find at least one occurrance
but not located at the two bytes of the file. I suspect that if
a FF D9 doesn't exist at all, that a viewer will complain of
file corruption and not attempt to render a image.

Art
http://home.epix.net/~artnpeg
 
But now that you bring it up, I think I will include a option to truncate
the files as a convenience to users, since that would eliminate the need
to use Irfan (or other apps). So far as I can determine, the scanner
would only have to find the first occurance of the "end of JPG" marker
bytes and truncate all bytes after that.
Click to expand...

No. JFIF containers can have nested data streams. Often your method
would truncate right after a preview picture, deleting the whole
real thing. There can be other stream nestings, too. So the only
possible way is to evaluate one JFIF block after another, parsing
any data stream until EOI and continue the scan through the next
JFIF blocks and data streams. You'd need to detect invalid or
suspicious blocks or data to act properly.

JFIF blocks have size definitions (usually at byte 2 with length
word), while data streams have no size property.

BeAr
 
No. JFIF containers can have nested data streams.
Click to expand...

What file extension(s) is/are used?
Often your method
would truncate right after a preview picture, deleting the whole
real thing. There can be other stream nestings, too. So the only
possible way is to evaluate one JFIF block after another, parsing
any data stream until EOI and continue the scan through the next
JFIF blocks and data streams. You'd need to detect invalid or
suspicious blocks or data to act properly.

JFIF blocks have size definitions (usually at byte 2 with length
word), while data streams have no size property.
Click to expand...

Yes, well it's no surprise that the plot thickens :) BTW, I added a
search for FF D9 anywhere in the file, and two of the ten suspicious
but probably legit JPGs were isolated with this test. I verified using
a hex editor that they indeed had no FF D9 anywhere in the file.
My guess that such files would cause Irfan to just flag them as
corrupted was wrong. Irfan displays them with no complaints. I went
ahead and used Irfan Save on all ten files, and they no longer flag as
suspicious, meaning that they now all have FF D9 as the last two bytes
in the file (as expected).

Art
http://home.epix.net/~artnpeg
 
What file extension(s) is/are used?
Click to expand...

Huh? Usually, *.jpg or *.jpeg. JPEG is a compression scheme. And JFIF
(JPEG File Interchange Format) is the file format mainly used to write
JPEG data.

An extended ISO variant is SPIFF, which supports "directories" inside
the file. Still, you'll encounter such files as *.jpg/*.jpeg. As I
understand the format description, your seemingly valid *.jpg which
don't end with EOI might be totally valid SPIFF files with indirect
data on end. That's data from too large directory entries mapped to
the end of the file. IrfanView may just reorganize the files such,
that the need of these extra entries disappears.

BeAr
 
The JPG-SCAN program at my web site has been updated
to detect certain narrower specific characteristics that the
Trojanized JPG samples I have display. Deletion of detected
Trojanized JPGs is left up to the user.

Art
http://home.epix.net/~artnpeg
 
The JPG-SCAN program at my web site has been updated
to detect certain narrower specific characteristics that the
Trojanized JPG samples I have display. Deletion of detected
Trojanized JPGs is left up to the user.
Click to expand...

Updated again Sunday afternoon to accomodate additional
Trojanized samples I found. It's quite unlikely that the scanner
will false alarm on non-Trojanized JPGs, so if the picture image
is of little value the file(s) detected should be deleted. If anyone
finds apparent FPs, please send sample(s) of the file(s) to
artsown at epix dot net.

As of this afternoon here in cental Pa., I see Ewido added as the
fourth to to the very short list of av/anti-malware vendors alerting
on the Trojanized files.

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

As of today, most vendors are still not alerting on the JPGs.
Some such as TIBS.JPG and WEB.JPG only have one vendor
alerting ... Symantec. With PROXY.JPG, only Fortinet and
Symantec alert.

I made a attemt to get a idea of which vendors might alert
on a realtime scanner basis. I isolated the appending malicous
code portions of the files, and for five of the eight samples
I was able to also determine the XOR decryptor used. I found
that McAfee in particular didn't alert on the encrypted files
but it did on some of the decrypted files. So to nursemaid
the av products a bit, I only uploaded decrypted files to
VT. Notably, in my other tests using McAfee SCAN, F-Prot
DOS and KAVDOS32, F-Prot and Kaspersky didn't care if the
files were decrypted or not.

The details are far too lengthy to report here since they involve
many Virus Total results as well as other details. Suffice it to say
that the results are quite mixed and detection is "spotty". While
some of the better av/antimalware products can be expected to
alert realtime on some of the files (when a new and "unknown"
companion runs the appended malicious code), I wouldn't place
any bets on it in general.

So IMO, the situation is just as peculiar, or worse, as when I
started this thread. Three of my samples, NT1, NT2 and NT3
(the ones I failed to decrypt) aren't detected by any vendors
in their isolated non-JPG form. Yet these are the three that
four vendors alert on in their full JPG form. So we have
reason(s) to expect that the appended code is malicious. I'm
not about to use a companion to extract, decrypt and run
the code (on a goat PC) to see which av alert, if any.

Why the vendors don't alert on the JPGs is beyond me. They
are leaving users at much higher risk, when it would be so
easy for them to provide detection.

Art
http://home.epix.net/~artnpeg
 
My JPG-SCAN program has been speeded up considerably,
and there have been some cosmetic changes done recently.
Detection is now "tight enough" that there should be no
false positives on legit JPG files.
Click to expand...

Jeeze Art... Are you going to make a gif/tga/bmp scanner too? *grin*
 
Art said:
I sure am, wise ass, if there's a need for it.
Click to expand...

Wiseass? jeeze.. I wasn't trying to be one, it was simply a question.
I've never seen a jpeg scanner until now.

I don't know if somebody spiked your coffee, so make a fresh pot drink
some, wakeup, and then come to usenet.

Have a good one,
Dustin
 
Wiseass? jeeze.. I wasn't trying to be one, it was simply a question.
I've never seen a jpeg scanner until now.

I don't know if somebody spiked your coffee, so make a fresh pot drink
some, wakeup, and then come to usenet.

Have a good one,
Click to expand...

Ok, I apologize then for the "wise ass" comment. It's just that you've
posted your negative opinion on av scanning the JPGs and I figured
your comment reflected that negative opinion and you were being
a wise ass about it.

I'm convinced that as long as most av turn their backs on detecting
the appended malicious code in the JPGs, they aren't serving their
customers well. As I posted, I've accumulated some evidence that
many av probably won't alert realtime when a new and unknown
companion extracts, decrypts, and runs the appended malicious
code. Many don't even seem to have detection for the various
downloader Trojans and Trojan droppers contained in the JPGs.
So the JPGs are a sitting time bomb waiting to go off.

It's not that the vendors haven't been fed samples. They have and
they're ignoring them and the malicious code contained within them, it
seems. And all are guilty of it to one extent or another. Of all the
damn things, Kaspersky suddenly started alerting on just one of the
JPG samples I have ... the one named WEB.JPG. Yet Kaspersky
alerts on the emebbed code in five of the JPG samples I have if I
extract it from the JPG and thus isolate it. It's nutty and
inconsistent as hell ... just like much I've seen with other av
in connection with the "froggies" and the appended code.

Bottom line is that as long as av are behaving so erratically
and unreliably, I see a need for something like my "froggy
detector" so that users can be alerted and get rid of them.

Art
http://home.epix.net/~artnpeg
 
Art said:
Ok, I apologize then for the "wise ass" comment. It's just that you've
posted your negative opinion on av scanning the JPGs and I figured
your comment reflected that negative opinion and you were being
a wise ass about it.
Click to expand...

Nah. I disagree with scanning jpegs, sure; but no reason to be a jerk
about it. I have no problem with your program, it's neat. I just never
saw one specifically designed to hunt malware from a jpeg before. :)
I'm convinced that as long as most av turn their backs on detecting
the appended malicious code in the JPGs, they aren't serving their
customers well. As I posted, I've accumulated some evidence that
many av probably won't alert realtime when a new and unknown
companion extracts, decrypts, and runs the appended malicious
Click to expand...

This is where it gets a little foggy for me. If the companion is new
and unknown, why does it even need to extract old code? It already has
the system by the gonads.
code. Many don't even seem to have detection for the various
downloader Trojans and Trojan droppers contained in the JPGs.
So the JPGs are a sitting time bomb waiting to go off.
Click to expand...

In a way, yes.. I suppose they are, but by the same token, if a new
unknown companion gets on the box to use them, the user is already
hurting.
JPG samples I have ... the one named WEB.JPG. Yet Kaspersky
alerts on the emebbed code in five of the JPG samples I have if I
extract it from the JPG and thus isolate it. It's nutty and
Click to expand...

The thing is, if the code your extracting is appended, it's not really
Steganography. If the code was hidden properly, would your program
still alert on it? I think I'm going to do a little tinkering and find
out. No worries, no sources, description of how to evade your program
(if any evading is to be done) will be published. I'll email you the
results of my findings.
inconsistent as hell ... just like much I've seen with other av
in connection with the "froggies" and the appended code.
Click to expand...

If the code is appended, it's not a true steganographic file...
Bottom line is that as long as av are behaving so erratically
and unreliably, I see a need for something like my "froggy
detector" so that users can be alerted and get rid of them.
Click to expand...

Understandable. I'm just thinking, if the author properly
steganographed the files, whether your utility would work, I'm thinking
no....
 
Nah. I disagree with scanning jpegs, sure; but no reason to be a jerk
about it. I have no problem with your program, it's neat. I just never
saw one specifically designed to hunt malware from a jpeg before. :)
Click to expand...

I used to have one just to scan Word docs for embedded Trojans until
the av vendors finally got off their asses and starting alerting on
"known" ones.
This is where it gets a little foggy for me. If the companion is new
and unknown, why does it even need to extract old code? It already has
the system by the gonads.
Click to expand...

You're ignoring the possibility of companions whos only purpose and
function is to extract and run the code in the JPGs. Now, it may be
that av vendors have developed heuristic/generic detection of that
kind of activity and will block it without specific sigs as
"suspicious". I don't know. If that's that's the way many av vendors
plan to deal with the issue, it certainly doesn't inspire any
confidence with me :)
In a way, yes.. I suppose they are, but by the same token, if a new
unknown companion gets on the box to use them, the user is already
hurting.
Click to expand...

Not if the companion's sole purpose in life is running the code in the
JPGs. Remember that these things are being generated by a
organized mob of hackers.
The thing is, if the code your extracting is appended, it's not really
Steganography.
Click to expand...

I don't know if all experts agree that this "simple" method is a form
of steganography. Some claim that it is. Personally, I'm not the least
bit interested in the semantics as long as we each know what the
other is talking about. In this case, all the samples I have are
simple appendages of encrypted code.
If the code was hidden properly, would your program
still alert on it?
Click to expand...

Well, I know what you mean by "properly" I think, and the answer
is a very definite NO! My program simply looks for certain
characteristics all of the samples I have have in common. For one
thing, they all have a End of Image marker in the same location
in the file. But I also require that the two bytes following that
marker are match either of the two different byte pairs I've
seen in the samples. So I definitely need samples of any new
froggies to update my signatures :)
I think I'm going to do a little tinkering and find
out. No worries, no sources, description of how to evade your program
(if any evading is to be done) will be published. I'll email you the
results of my findings.
Click to expand...

I've already given that issue some thought and decided it would
be silly to not divulge the very simple method I'm using. It's
not rocket science, to be sure.
If the code is appended, it's not a true steganographic file...
Click to expand...

I'm not taking the bait since I don't give a shit one way or
another what various people's opinions are on the semantics
and word definitions.
Understandable. I'm just thinking, if the author properly
steganographed the files, whether your utility would work, I'm thinking
no....
Click to expand...

That's correct. It wouldn't.

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