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: Art on 5 Jul 2006 12:38 On Wed, 5 Jul 2006 17:10:23 +0100, "Noel Paton" <NoelDPspamless(a)crashfixpc.com> wrote: >While I think of it, Art - what happens if you run Ad-Aware over your JPG >samples, in ADS-test mode?? Haven't tried it but I will if that mode is available on the free version or a free-to-try demo. Art http://home.epix.net/~artnpeg
From: Art on 5 Jul 2006 16:14 On Wed, 5 Jul 2006 20:37:08 +0100, "Noel Paton" <NoelDPspamless(a)crashfixpc.com> wrote: >Yup - it's a little hidden, but it's there all right I don't see anything in AdAware SE about a ADS-Test mode. Exactly what is it that you're talking about and why do you think AdAware would be of any use in the case of JPGs containing appended encrypted code when most av products aren't even alerting? Art http://home.epix.net/~artnpeg
From: Art on 5 Jul 2006 17:15 On Wed, 5 Jul 2006 21:45:17 +0100, "Noel Paton" <NoelDPspamless(a)crashfixpc.com> wrote: >In Ad-Aware - Scan now >Scan Mode - Scan Volume for ADS (Alternate Data Streams) Ok, set it to scan my entire drive. No alerts. >Back in Dec/January, when the WMF exploits initially reared their head, one >distinguishing feature of infected files was that they all showed positive >on testing for ADS (even when tested in Win9x, IIRC) using Ad-Aware. >It was an effective discovery tool before the AV's caught up (and >incidentally demonstrated why Win9x wasn't vulnerable to that particular >exploit). Interesting. I missed that tidbit :) Art http://home.epix.net/~artnpeg
From: Christopher P. Winter on 16 Jul 2006 13:48 On Wed, 05 Jul 2006 20:07:54 GMT, Art <null(a)zilch.com> wrote: >On Wed, 5 Jul 2006 15:37:36 -0400, "edgewalker" <null(a)null.invalid> >wrote: >> >>So where's the "need" for jpg scanning? > >I've already explained that in my other posts in this thread. > >>I can see there would be a need >>to detect a program that attempts to use jpg data as code, but the need >>for scanning data files for possible 'data as code' inclusions escapes me. > >Your attitude and opinion escapes me. > >>Aside from just a mental exercise, and in the process learning more about >>the jpeg specs - I think you're wasting time. Any data filetype can contain >>data destined to be used as code by a nefarious trojan. > >That why container scanning is important. In practicing safe hex, I >don't rely on some single realtime av. That's far too risky, and in >this particular case it's exceptionally risky for reasons I've pointed >out. I want my scanners to detect malicious code during on-demand >scans of various containers, and in compressed and packed files. > I'm an infrequent visitor here. Let me see if I understand your concern. You're saying that the malicious code could "lie doggo" in JPEG image files on someone's machine until an apparently innocuous .exe was inadvertently downloaded and executed? (By "apparently innocuous" I mean one that anti-malware programs don't detect.) It may be that the action of automatically opening the JPEG is something that can be consistently detected and blocked, in which case malicious code in JPEGs (or any other data files) might become moot. I say "might be" because of watermarks. Now, I don't know much about how watermarks work, but I do know they are supposed to be immune to image manipulation. If they can be, so can the malware code. Also, the action of a legitimate watermark reader might be hard to distinguish from that of a malware activator. Bottom line: I think your concern is valid, but I also think that coning up with a real-world solution will be a very thorny problem.
From: edgewalker on 16 Jul 2006 17:36
"Christopher P. Winter" <chrisw20(a)chrisw20.best.vwh.net> wrote in message news:jtukb2pl9o62p98quvefk4jsaeoar78mf7(a)4ax.com... > It may be that the action of automatically opening the JPEG is something that > can be consistently detected and blocked, in which case malicious code in > JPEGs (or any other data files) might become moot. I can see only rare instances where the companion executable wouldn't be able to just carry any 'other' malicious code within itself rather than to store that code in some companion data filetype. Couple that with the fact that "any" filetype can contain data that will later represent malicious code when read by a companion executable programmed for that purpose. The companion executable could even be the decryptor of encrypted data leaving you no way to detect the data companion as having malicious content. I came to the conclusion that Art wants to detect this "on-demand" just for the sake of completeness when scanning incoming data filetypes. That's okay with me, but there are so many ways that malware writers can get around detectability in data filetypes that I think it is not worthwhile. > I say "might be" because of watermarks. Now, I don't know much about how > watermarks work, but I do know they are supposed to be immune to image > manipulation. If they can be, so can the malware code. Also, the action of a > legitimate watermark reader might be hard to distinguish from that of a > malware activator. You hit that grey area like is it a remote administration tool or a remote access trojan. The same exact program could be either, depending on circumstances. Detection for some kinds of trojans are on a first come first served basis. Any application that executes on your machine and gets data to be interpreted and executed as code (like Java) cannot be judged as malware on that basis alone. (maybe they should be though). What about an batch that changes your very own batch files to malware by changing paths from your cleanup.bat (deletes temp files) to delete files in directories you wanted preserved? Gee, now you'll have to detect your very own batch files as malicious because of some future malware that may use some code from them to do bad things. |