A Steganography sample malware
in [Anti-Virus]
|
Prev: c:\recycler\S-1-5-21-129_ ... Dc775.zip
Next: explorer.exe startet nicht richtig - HILFE bitte!!
From: B. R. 'BeAr' Ederson on 25 Jun 2006 18:59 On Sun, 25 Jun 2006 17:15:53 -0400, edgewalker wrote: > 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 -- =========================================================================== = What do you mean with: "Perfection is always an illusion"? = ===============================================================--(Oops!)===
From: Art on 25 Jun 2006 19:17 On Sun, 25 Jun 2006 17:40:23 -0400, kurt wismer <kurtw(a)sympatico.ca> wrote: >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] >>> 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 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
From: Phil Weldon on 25 Jun 2006 20:12 '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 "B. R. 'BeAr' Ederson" <br.ederson(a)expires-2006-06-30.arcornews.de> wrote in message news:12p951kvvz5x$.dlg(a)br.ederson.news.arcor.de... | 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!)===
From: GEO on 25 Jun 2006 21:03 On Sun, 25 Jun 2006 16:47:01 -0400, "edgewalker" <null(a)null.invalid> wrote: >> >| "Art" <null(a)zilch.com> >> >| 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. >> >D.Lipman wrote: >> >Now on another batch... >> >Symantec is calling the submitted JPEGs -- Trojan.Frogexer!gen. >> Geo wrote: >> 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.....' >"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
From: Art on 25 Jun 2006 21:12
On Mon, 26 Jun 2006 00:12:26 GMT, "Phil Weldon" <notdiscosed(a)example.com> wrote: 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 |