A Steganography sample malware

Discussion in 'Anti-Virus' started by Art, Jun 22, 2006.

  1. Art

    Art Guest

    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.

    The subject sample came in a zip of four files, three JPEGS
    and a file named WIN32.EXE. Here's the Virus Total result
    for the WIN32.EXE file:
    ***********************************
    AntiVir TR/Crypt.F.Gen
    Authentium no virus found
    Avast no virus found
    AVG no virus found
    BitDefender Trojan.Downloader.Small.AMA
    CAT-QuickHeal no virus found
    ClamAV no virus found
    DrWeb Trojan.DownLoader.9540
    eTrust-Inoculat no virus found
    eTrust-Vet Win32/Vxidl!generic
    Ewido Downloader.Tibs.eo
    Fortinet no virus found
    F-Prot no virus found
    Ikarus no virus found
    Kaspersky Trojan-Downloader.Win32.Tibs.eo
    McAfee 4791 Generic Downloader
    Microsoft no virus found
    NOD32v2 probably a variant of Win32/TrojanDownloader.Small.AWA
    Norman no virus found
    Panda Adware/Adsmart
    Sophos no virus found
    Symantec Trojan.Galapoper.A
    TheHacker no virus found
    UNA no virus found
    VBA32 Trojan.DownLoader.9540
    VirusBuster no virus found
    ************************************
    Only Bit Defender and Symantec alerted on the JPEGS.
    Bit Defender found Trojan.HideFrog.A in all three
    (they are images of a frog :))

    Symantec alerted as follows:
    NT1.JPG W32.Looksky!gen
    NT2.JPG Trojan.Desktophijack.B
    NT3.JPG Trojan.Jupillites

    I'm puzzled that only two products alert on the JPEGS
    even though many alert on the (apparently)
    companion malware. I would think it important to
    alert on the JPEGS as a warning to users to get rid
    of them.

    I'm also puzzled/curious about the Symantec
    alerts.

    Here's a McAfee blog with some info on this
    malware set:

    http://www.avertlabs.com/research/blog/?p=36

    BTW, while McAfee alerts on WIN32.EXE as Generic
    Downloader, it does not alert on the JPEGS.

    Art
    http://home.epix.net/~artnpeg
     
    Art, Jun 22, 2006
    #1
    1. Advertisements

  2. Art

    Art Guest

    I've sent the JPEGs to Kaspersky asking why KAV doesn't alert.
    Depending on the analyst, I might get a good answer. Sometimes
    Eugene himself is the analyst, and if I'm lucky I'll hit paydirt :)

    Art
    http://home.epix.net/~artnpeg
     
    Art, Jun 23, 2006
    #2
    1. Advertisements

  3. Art

    kurt wismer Guest

    minor quibble - steganography is a technique for hiding messages in
    other things, it's not just for hiding malware...

    [snip]
    think of it as being analogous to the issue of scanning inside of
    various types of archives (which i know you're already quite familiar
    with)... ultimately the jpegs are just acting as a kind of container...
    how good are av apps at scanning inside containers in general and exotic
    (ie. non-zip/rar/arj) containers in particular? i seem to recall you
    saying something about problems unpacking installation files even (and
    one wouldn't normally consider those to be 'exotic')...
     
    kurt wismer, Jun 23, 2006
    #3
  4. Art

    Art Guest

    To paraphrase Winston Churchill, "Such errant pedantry up with I shall
    not put!". Obviously if malicious code can be embedded in certain
    fles, any code can be embedded.

    Art
    http://home.epix.net/~artnpeg
     
    Art, Jun 23, 2006
    #4
  5. Art

    Art Guest

    Here's a snippet from the blog I referenced where the author responds
    to a comment by "Mike":
    *******************************************************
    And basic X-raying is all that’s required to decrypt these files, for
    now anyway.
    *******************************************************
    Now, I dunno what he means by "basic X-raying" but he makes it
    sound as if the decryption in this particular case is straightforward.
    Whether he means in a lab only or in a scanner is a question.
    Anyway, that's partially why I'm surprised that Kaspersky in
    particular isn't alerting. They seem to never shy away from difficult
    "unravelling" and "scanning within" all kinds of files. Plus the fact
    that it _appears_ that Symantec is effectively decrypting,
    and Bit Defender _may_ also be decrypting. As of this moment, I
    haven't yet heard back from a Kaspersky analyst. I'm hoping
    their response will shed light on my questions.

    Art
    http://home.epix.net/~artnpeg
     
    Art, Jun 23, 2006
    #5
  6. Art

    Dustin Cook Guest

    The code contained inside the jpegs isn't functional without something
    to read it, win32.exe. Otherwise, the jpegs are a picture of a frog,
    with hidden code. Code only readable by software that already knows
    it's there. I don't think picture viewer will do anything bad if you
    decide to look at one. :)

    You could stenagraphy a .gif, .bmp, almost anything that doesn't have
    crc checks and/or a hashing table. The catch tho is, your code likely
    isn't operational on it's own. A 3rd party will need to come read, and
    put you back together in order to run.
    I believe BugHunter also picks up win32.exe, but it doesn't alarm on
    the jpegs either. And it's not going too....
     
    Dustin Cook, Jun 23, 2006
    #6
  7. Art

    Art Guest

    Of course it doesn't but that's beside the point.
    Yep, and that's exactly why I think the .JPGs should be detected.
    Too bad. It would be a useful detection IMO.

    Art
    http://home.epix.net/~artnpeg
     
    Art, Jun 23, 2006
    #7
  8. Art

    Dustin Cook Guest

    I'm lost then.
    Steganography is the art and science of writing hidden messages in such
    a way that no one apart from the intended recipient knows of the
    existence of the message; this is in contrast to cryptography, where
    the existence of the message itself is not disguised, but the content
    is obscured.
    Ehm... You do realize the growing possibility of false alarms if we
    have antivirus/malware products trying to guess if something has a
    hidden bit of code in a jpeg right?

    That's alot of signatures. :)
    I would tend to disagree...
     
    Dustin Cook, Jun 23, 2006
    #8
  9. Art

    Art Guest

    In this case they use JPG steganogrophy to hide malicious code in
    JPGs. Companion malware is required to decrypt and run the malicious
    code.
    I don't know that av have to "guess" (use heuristics only). It doesn't
    appear that Symantec is detecting heuristically since it gives exact
    IDs (and different ones) on three different JPG files.
    Hell, signatures are balooning outa sight anyway :) What's a few
    more?
    I'd say informing the user of the infested JPG which might be
    used by the companion malware at any point is important. I'd
    say it's more important than wasting sigs as some do on
    commercial sw which might be used for nefarious purposes.
    I'd go so far as to say it's more important than flagging
    harmless adware that's merely annoying. After all, we're
    talking here about some nasty downloader Trojans.

    Art
    http://home.epix.net/~artnpeg
     
    Art, Jun 23, 2006
    #9
  10. Art

    Dustin Cook Guest

    Nah, your right, they're using sigs. The malware isn't really keen on
    the process, IE: it's fixed, or appears to be.
    How very true, and quiet saddening. :)
    Fair enough Art, You've convinced me to hunt down the frog jpegs and
    add them to bughunter...Although, I still maintain they are harmless
    without win32.exe....
     
    Dustin Cook, Jun 23, 2006
    #10
  11. Art

    4Q Guest

    Raidy an exception to the rule maybe Minders .bmp IRC worm
    His code was contained inside the .bmp file and looked like
    a little bit of random noise inside a viewer, however his
    worm was also a weak SE trick and the picture contained a
    message asking the user to rename the .bmp to a .com
    Then it operated as a normal wormoid.

    Bit lame as an ITW example but hey nice example of a hax0r
    thinking outside the box.

    4Q
     
    4Q, Jun 23, 2006
    #11
  12. Art

    Art Guest

    Woe to me :(

    Art :)
    http://home.epix.net/~artnpeg
     
    Art, Jun 23, 2006
    #12
  13. Art

    Art Guest

    See my reply to Dustin concerning that. Think of the cost of all the
    sigs nowdays for harmless adware, cookies, and controversialware.

    Art
    http://home.epix.net/~artnpeg
     
    Art, Jun 23, 2006
    #13
  14. From: "Art" <>

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

    | The subject sample came in a zip of four files, three JPEGS
    | and a file named WIN32.EXE. Here's the Virus Total result
    | for the WIN32.EXE file:
    | ***********************************
    | AntiVir TR/Crypt.F.Gen
    | Authentium no virus found
    | Avast no virus found
    | AVG no virus found
    | BitDefender Trojan.Downloader.Small.AMA
    | CAT-QuickHeal no virus found
    | ClamAV no virus found
    | DrWeb Trojan.DownLoader.9540
    | eTrust-Inoculat no virus found
    | eTrust-Vet Win32/Vxidl!generic
    | Ewido Downloader.Tibs.eo
    | Fortinet no virus found
    | F-Prot no virus found
    | Ikarus no virus found
    | Kaspersky Trojan-Downloader.Win32.Tibs.eo
    | McAfee 4791 Generic Downloader
    | Microsoft no virus found
    | NOD32v2 probably a variant of Win32/TrojanDownloader.Small.AWA
    | Norman no virus found
    | Panda Adware/Adsmart
    | Sophos no virus found
    | Symantec Trojan.Galapoper.A
    | TheHacker no virus found
    | UNA no virus found
    | VBA32 Trojan.DownLoader.9540
    | VirusBuster no virus found
    | ************************************
    | Only Bit Defender and Symantec alerted on the JPEGS.
    | Bit Defender found Trojan.HideFrog.A in all three
    | (they are images of a frog :))

    | Symantec alerted as follows:
    | NT1.JPG W32.Looksky!gen
    | NT2.JPG Trojan.Desktophijack.B
    | NT3.JPG Trojan.Jupillites

    | I'm puzzled that only two products alert on the JPEGS
    | even though many alert on the (apparently)
    | companion malware. I would think it important to
    | alert on the JPEGS as a warning to users to get rid
    | of them.

    | I'm also puzzled/curious about the Symantec
    | alerts.

    | Here's a McAfee blog with some info on this
    | malware set:

    | http://www.avertlabs.com/research/blog/?p=36

    | BTW, while McAfee alerts on WIN32.EXE as Generic
    | Downloader, it does not alert on the JPEGS.

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

    Hi Art:

    I see a nice thread came from this :)

    I orginally received from Symantec the following...

    We have analyzed your submission. The following is a report of our findings for each file
    you have submitted:

    filename: nt1.jpg
    machine: AVCAutomation:
    result: See the developer notes

    filename: nt2.jpg
    machine: AVCAutomation:
    result: See the developer notes

    filename: nt3.jpg
    machine: AVCAutomation:
    result: See the developer notes

    Developer notes:
    nt1.jpg is an image file that contains virus. You should delete this file.
    nt2.jpg is an image file that contains virus. You should delete this file.
    nt3.jpg is an image file that contains virus. You should delete this file.

    -----

    I was asking myself "What Virus" ? They didn't identify anything !

    Now on another batch...

    Symantec is calling the submitted JPEGs -- Trojan.Frogexer!gen.

    filename: proxy.jpg
    machine: AVCAutomation:
    result: This file is detected as Trojan.Frogexer!gen.

    filename: tibs.jpg
    machine: AVCAutomation:
    result: This file is detected as Trojan.Frogexer!gen.

    filename: jpg.jpg
    machine: AVCAutomation:
    result: This file is detected as Trojan.Frogexer!gen.

    filename: tool.jpg
    machine: AVCAutomation:
    result: This file is detected as Trojan.Frogexer!gen.

    filename: winlogon.jpg
    machine: AVCAutomation:
    result: This file is detected as Trojan.Frogexer!gen.
     
    David H. Lipman, Jun 23, 2006
    #14
  15. From: "edgewalker" <>

    |
    |
    | [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 !
     
    David H. Lipman, Jun 23, 2006
    #15
  16. Art

    Dustin Cook Guest

    How exactly is this a good example tho? The user had to rename it to
    get it to execute. :)
    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...
    It's a very sad state if his ITW thing went anyplace.
     
    Dustin Cook, Jun 24, 2006
    #16
  17. Art

    GEO Me Guest

    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
     
    GEO Me, Jun 24, 2006
    #17
  18. Art

    James Egan Guest

    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.
     
    James Egan, Jun 24, 2006
    #18
  19. Art

    Art Guest

    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
     
    Art, Jun 24, 2006
    #19
  20. From: "Art" <>


    | 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.
     
    David H. Lipman, Jun 24, 2006
    #20
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.