A Steganography sample malware - Page 2

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View

Re: A Steganography sample malware



[interesting, but snipped anyway]

My take on this is that the jpg's are indeed trojans, but only in the presence
of the executable malware companion. That companion is the threat. The
obfuscated code could be any filetype at all and the code encrypted as well
as steganogrified - then where are you. I don't think the industry would want
to add technology to find hidden code when the hidden code can be so easily
encrypted anyway. To stop a threat, cut off its head. Deal with the jpg's as
part of the verification process (to get exact identification of variant) and to
help with cleanup. It doesn't need to produce an alert.

...any more than "Eddie lives...etc... does



Re: A Steganography sample malware


|
|
| [interesting, but snipped anyway]
|
| My take on this is that the jpg's are indeed trojans, but only in the presence
| of the executable malware companion. That companion is the threat. The
| obfuscated code could be any filetype at all and the code encrypted as well
| as steganogrified - then where are you. I don't think the industry would want
| to add technology to find hidden code when the hidden code can be so easily
| encrypted anyway. To stop a threat, cut off its head. Deal with the jpg's as
| part of the verification process (to get exact identification of variant) and
to
| help with cleanup. It doesn't need to produce an alert.
|
| ...any more than "Eddie lives...etc... does
|

I agree.  This goes back to the experimental, demonstration, infector called
W32/PerRun --
http://vil.nai.com/vil/content/v_99522.htm ~ 4 years ago.  While steganography
was not
mentioned in conjunction with this I knew it would eventually be used.  Here we
are, 4 years
later, and we have active Trojans using the technology.

BTW, the source, the Russian Mob !

--
Dave
http://www.claymania.com/removal-trojan-adware.html
http://www.ik-cs.com/got-a-virus.htm



Re: A Steganography sample malware

On Fri, 23 Jun 2006 21:19:31 GMT, "David H. Lipman"

Quoted text here. Click to load it

  The latest version of Bagle was formed by two files inside the ZIP
file, one an EXE and one a DLL. Looking at the DLL with Notepad I
noticed that it was nothing but ASCII characters:
'ucrjsyfzimaepnc.....'

  Geo


Re: A Steganography sample malware


Quoted text here. Click to load it

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.



Re: A Steganography sample malware

wrote:

Quoted text here. Click to load it




  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


Re: A Steganography sample malware


Quoted text here. Click to load it

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.



Re: A Steganography sample malware

wrote:


Quoted text here. Click to load it


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

ucrjsyfzimaepnctcgbhyfvgrfkhdqohcpouckkitblmewxpbcweorvructcyy
lnnzesfrqkohbkyfcazcdjuxzlfcckliqhppfxtjacuvbuglwmvbttxuy......
..etc

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


  Geo


Re: A Steganography sample malware


Quoted text here. Click to load it

Seems like a lot of effort for very little gain to me. There are too
many proprietary steganography techniques to cover to make it a
worthwhile venture given that the likelihood of the hidden malware
ever being executed is close to zero.

If it's created by a joke steganography program like Data Stash which
purports to use blowfish encryption but in fact just stores the hidden
file as a plain zip appended at the end then it might cause a few
scanners to alert regardless of any steganography functionality.

Jim.


Re: A Steganography sample malware

wrote:

Quoted text here. Click to load it

1. "Too many" or "potentially endless" considerations haven't
prevented vendors from doing a partial job at least of handling
various runtime packers and file compression (archiving) methods
when scanning on-demand. New packers are created
specially to confuse av, yet vendors like Kaspersky have clearly
attempted to keep up with them. Kaspersky and some others
have also pursued extraction and "scanning within" installation
and setup .EXE files even though that puts them in the position
of having to keep up with new installers as time goes on.

Now, if you want to argue that all of the above is unnecessary
because realtime scanning will/should eventually catch the
malware when run, that's a different matter and a different
argument. But I see no difference between making on-demand
scanning attempts at some of the JPG (and other) files in
circulation and making attempts at other "containers".

2. Your statement that the probability of the malware being
executed is zero is nonsense no matter how you look at it. Even
without the presence of a current companion, a new and
currently "unknown" companion could cnceivably get past av
scanners and run the code embedded in the JPGs. The JPGs
are a threat as long as they are on a PC. In fact, this sort of
thing may well be a part of the plan of the bad guys. Now,
it may be that realtime scanners will be smart enough to figure out
which file contains the embedded code that a day zero companion
runs, but I doubt it. So the damn JPGs could just sit there
undetected forever, endlessly used by new and "unknown"
companions. Some will argue that this boils down to nothing
more or less than _any_ day zero problem and av only need
be concerned with detecting companion malware which they
view as the _real_  and _only_ culprits. I would argue as (1.)
(above) and say that it's worthwhile IMO to make attempts
at alerting on files containing embedded malicious code if it's
feasible to do so, in as many cases as possible. And if JPG
embedded code is completely ignored by analysts, that begs
the question of whether or not realtime scanners will catch
the "unknown" code when it _ is_ run by a companion.
There's no way around analyzing the embedded code and
providing at least realtime detection in all cases when it's
feasible to do so in a scanner.  

That's why I'm so interested in hearing back from Kaspersky,
though I'm not optimistic about receiving a "policy statement"
from most of their analysts or even from Eugene :) I'm just
hoping that I can "read between the lines" and deduce a
current policy on detecting embedded malicous code in
such files as I submitted. Based on their past history of not
shying away from "container" challenges, it will be interesting
to find out what they, in particular, plan to do. It's going on
two days now, and I've not yet heard back.        

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

Re: A Steganography sample malware


| wrote:


Quoted text here. Click to load it


| 1. "Too many" or "potentially endless" considerations haven't
| prevented vendors from doing a partial job at least of handling
| various runtime packers and file compression (archiving) methods
| when scanning on-demand. New packers are created
| specially to confuse av, yet vendors like Kaspersky have clearly
| attempted to keep up with them. Kaspersky and some others
| have also pursued extraction and "scanning within" installation
| and setup .EXE files even though that puts them in the position
| of having to keep up with new installers as time goes on.

| Now, if you want to argue that all of the above is unnecessary
| because realtime scanning will/should eventually catch the
| malware when run, that's a different matter and a different
| argument. But I see no difference between making on-demand
| scanning attempts at some of the JPG (and other) files in
| circulation and making attempts at other "containers".

| 2. Your statement that the probability of the malware being
| executed is zero is nonsense no matter how you look at it. Even
| without the presence of a current companion, a new and
| currently "unknown" companion could cnceivably get past av
| scanners and run the code embedded in the JPGs. The JPGs
| are a threat as long as they are on a PC. In fact, this sort of
| thing may well be a part of the plan of the bad guys. Now,
| it may be that realtime scanners will be smart enough to figure out
| which file contains the embedded code that a day zero companion
| runs, but I doubt it. So the damn JPGs could just sit there
| undetected forever, endlessly used by new and "unknown"
| companions. Some will argue that this boils down to nothing
| more or less than _any_ day zero problem and av only need
| be concerned with detecting companion malware which they
| view as the _real_  and _only_ culprits. I would argue as (1.)
| (above) and say that it's worthwhile IMO to make attempts
| at alerting on files containing embedded malicious code if it's
| feasible to do so, in as many cases as possible. And if JPG
| embedded code is completely ignored by analysts, that begs
| the question of whether or not realtime scanners will catch
| the "unknown" code when it _ is_ run by a companion.
| There's no way around analyzing the embedded code and
| providing at least realtime detection in all cases when it's
| feasible to do so in a scanner.

| That's why I'm so interested in hearing back from Kaspersky,
| though I'm not optimistic about receiving a "policy statement"
| from most of their analysts or even from Eugene :) I'm just
| hoping that I can "read between the lines" and deduce a
| current policy on detecting embedded malicous code in
| such files as I submitted. Based on their past history of not
| shying away from "container" challenges, it will be interesting
| to find out what they, in particular, plan to do. It's going on
| two days now, and I've not yet heard back.

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

I haven't heard back from Kaspersky as well and I submitted the samples before
you did.

--
Dave
http://www.claymania.com/removal-trojan-adware.html
http://www.ik-cs.com/got-a-virus.htm



Re: A Steganography sample malware


Quoted text here. Click to load it

That's not the same though. If (say) a least significant bit method is
used to hide the malware, any detection would be dependent on the
image containing the malware and not just the malware itself. So if
someone got a (separate) infection which wrote a malware program to
the least significant bits of all the jpg's (over a minimum size to
suit the malware) on a particular machine then by the same reasoning,
all the av vendors would have to add detection for all these images to
their list since they are infected and already in the wild. There
could be gazillions of detections needed for one piece of malware.


Quoted text here. Click to load it


Then it's not the jpg which gets executed. It's the "unknown"
companion which just slipped past your av scanner. That's what needs
to be detected and stopped.


<snip>
Quoted text here. Click to load it

Unless a joke program like Data Stash that I mentioned earlier is
used, then it's not going to be feasible.


Jim.


Re: A Steganography sample malware

wrote:

Quoted text here. Click to load it

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.  

Quoted text here. Click to load it

Well, I suppose I could modify the JPGs I have slightly and see if Bit
Defender and Symantec quit alerting on them.

Quoted text here. Click to load it


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

Quoted text here. Click to load it

I've already addresed and answered that. Sure the companions
must be stopped and that's what the vendors are addressing.
But day zero companions will/may run the code in the JPGs so
the JPGs must be detected as well.

Quoted text here. Click to load it

If it's not feasible, how do you explain the detections by Bit
Defender and Symantec?

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

Re: A Steganography sample malware


Quoted text here. Click to load it

I meant a technique which mixes the data in with the image causing
changes which aren't very noticeable to the eye rather than appending
the whole of the (malware) data before some beginning of file marker
or after an end of file marker. Such a technique is more pertinent to
bitmaps where the least significant bit in a 24 bit pixel can be
easily altered to something else (to store the malware) without
radically altering the colour of the pixel. With (lossy) jpg's it
wouldn't be so simple of course but will nonetheless be possible to
some degree.


Quoted text here. Click to load it

The malware is probably all together as a comment at the beginning or
at the end after the end of file marker so altering the image itself
wouldn't make any difference.


<snip>

Quoted text here. Click to load it

I meant it's not feasible generally if some serious steganography prog
has been used to create the image. Remember that as well as
discovering that there is a hidden file within an image, the av also
has to determine that the hidden file is malware which will likely
involve breaking some serious encryption.

Adding detection for non serious stuff like the frog jpegs shouldn't
be difficult, but there could also be any number of infected images on
the same computer which are undetectable. Therefore the emphasis must
surely be placed on detecting and stopping the companion needed to
activate the malware.


Jim.
 

Re: A Steganography sample malware

wrote:

<snip to just this portion>

Quoted text here. Click to load it

Do av really have to determine that a "diddled with" JPG contains
encrypted "information" and be able to deal with decrypting it? Or is
it sufficient to recognize that something is definitely unusual for a
otherwise recognizable JPG format?

Why couldn't ISP email scanner/blockers treat such animals as
exceptions and pass them on to the users with a warning message
to the effect that something "fishy" has been detected? That way,
the few users exchanging legit altered JPGs could deal with the issue
by passing on a MD5 in the message body, passwords for the zips, etc.
Users not expecting a "fishy" JPG have been duly warned and if they
have half a brain they simply delete the attackment.

Similarly, all av could treat such JPGs as a exception and simply
issue a "something's fishy" warning to users. In fact, I suspect
a very strong warning might be legitimately issued, but I might
be overly optimistic about the definiteness of the determination.

Art
http://home.epix.net/~artnpeg
BTW, we've limited the discussion to JPGs because of the actual
sample malware I discussed, but we're really talking about
multimedia files and other "data" files as well.

Re: A Steganography sample malware


Art wrote:

Quoted text here. Click to load it

How would AV know if it's diddled or not? The whole point behind the
process is to alter only enough bits spread thruout the file to store
your data, for all intents and purposes, it's video data... Nothing but
a few bytes here and there altered... hardly noticable...

--
Regards,
Dustin Cook
http://bughunter.atspace.org


Re: A Steganography sample malware

On 24 Jun 2006 18:19:39 -0700, "Dustin Cook"

Quoted text here. Click to load it

A downloader Trojan (for example) in just a few bytes? I was thinking
in terms of otherwise unused space and a fairly large # of bytes. I
don't know if it's practical to alter the large # of bytes for complex
Trojans in the actual image data without very noticeable picture
distortions (noisy images). Guess it's time to really study the
subject rather than just glossing over a article or two on picture
image steganography :)

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

Re: A Steganography sample malware


Quoted text here. Click to load it

I suppose not. It would certainly help to clean up the steganography
market and "out" the plethora of crapware which claims to be
undetectable but is just a con.


Jim.


Re: A Steganography sample malware

'Art' wrote, in part:
| Well, I suppose I could modify the JPGs I have slightly and see if Bit
| Defender and Symantec quit alerting on them.
_____

Try an image editor and change the overall 'brightness by 1%.  That should
destroy any executable hidden in a .jpg image.

Phil Weldon

.
|
| 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.
|
| >any detection would be dependent on the
| >image containing the malware and not just the malware itself.
|
| Well, I suppose I could modify the JPGs I have slightly and see if Bit
| Defender and Symantec quit alerting on them.
|
| >>2. Your statement that the probability of the malware being
| >>executed is zero is nonsense no matter how you look at it. Even
| >>without the presence of a current companion, a new and
| >>currently "unknown" companion could cnceivably get past av
| >>scanners and run the code embedded in the JPGs.
|
| >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.
|
.
|
| If it's not feasible, how do you explain the detections by Bit
| Defender and Symantec?
|
| Art
| http://home.epix.net/~artnpeg



Re: A Steganography sample malware

On Sun, 25 Jun 2006 01:25:38 GMT, "Phil Weldon"

Quoted text here. Click to load it

Now, there's some thinking outside the box! Let's say that such a
minor and unobjectionable modification to color, brightness, contrast,
etc., is a sure-fire way to destroy the code. Call your invention a
"malware scrubber for JPGs" and peddle it :) Or maybe av products
could incorportate a scrubber feature whereby with user permission
all JPGs on all drives are found and scrubbed. Anyone with legit
JPG steganogrphy files could keep them on removeable media for
safety from the scrubbing operation.

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

        

Re: A Steganography sample malware

'Art' wrote, in part:
| Now, there's some thinking outside the box! Let's say that such a
| minor and unobjectionable modification to color, brightness, contrast,
| etc., is a sure-fire way to destroy the code.
_____

JPEG compression is 'lossy'; the image cannot be restored to the original
quality, as are other compression standards, including MPEGx, MP3, and WMF.
Think about the steganographic possibilities with MPG2 files!

Ultimately, I think the cost of defense against steganographic content is
not bearable for any but the most critical applications (and that is likely
to be hidden data, not executables.)  The defense will be blocking the
decoder malware.

Consider the possibilities of broadband MPG2 content distributed on the
Internet.  MPG2 compression has more dimensions than JPEG because time is
involved.  More than one 'frame' of information is necessary to reconstruct
any one displayable frame.  Steganography with MPEG2, for example, could
include information from more than one frame that must be combined to
retrieve the hidden message.  At a certain level of complexity the
processing power to even find a recognizable signature would be prohibitive,
especially since it would have to be done in real time.  Some frames could
contain information that the decoder malware could use to find the real
message.  That could go to arbitrary levels - easy for the decoder malware,
very difficult to defend against.  This could lead to an arms race with
offense being much cheaper than defense - a $50,000 anti-tank missile
destroys a $3,000,000 tank; a $1,000,000 missile destroys a $1,000,000,000
ship.

Analog broadcast television (and videotapes) have long had hidden
information in the vertical blanking interval.  NTSC television, for
example, has 525 lines, but 42 lines are hidden, and have no picture
content.  A number of these lines are available for switching signals, test
signals, closed captioning, auxiliary data services ( and other, covert uses
I am sure.)

Phil Weldon

| On Sun, 25 Jun 2006 01:25:38 GMT, "Phil Weldon"
|
| >'Art' wrote, in part:
| >| Well, I suppose I could modify the JPGs I have slightly and see if Bit
| >| Defender and Symantec quit alerting on them.
| >_____
| >
| >Try an image editor and change the overall 'brightness by 1%.  That
should
| >destroy any executable hidden in a .jpg image.
|
| Now, there's some thinking outside the box! Let's say that such a
| minor and unobjectionable modification to color, brightness, contrast,
| etc., is a sure-fire way to destroy the code. Call your invention a
| "malware scrubber for JPGs" and peddle it :) Or maybe av products
| could incorportate a scrubber feature whereby with user permission
| all JPGs on all drives are found and scrubbed. Anyone with legit
| JPG steganogrphy files could keep them on removeable media for
| safety from the scrubbing operation.
|
| Art :)
| http://home.epix.net/~artnpeg
|
|



Site Timeline