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 18 Jul 2006 13:33 On Mon, 17 Jul 2006 23:52:55 GMT, GEO wrote: >>Known entry gates for malware have to be closed. > > Entry gates? The internet? The programs? The operating system? Transmission (protocol based exchange), programs, container files,... Close -> Check -> Allow valid/suppress all other. BeAr -- =========================================================================== = What do you mean with: "Perfection is always an illusion"? = ===============================================================--(Oops!)===
From: B. R. 'BeAr' Ederson on 18 Jul 2006 13:57 On Mon, 17 Jul 2006 23:52:53 GMT, GEO wrote: > The latest version of Bagle had a companion DLL that was made up of > letters. For all I know it might be information that was used by the > executable. Your question targets, whether no-code parts of malware should be detected. I'd say that depends. If generic heuristic detection is possible (data on positions, where usually no data should be and the like - as is the case with the additional non-pictorial data at the end of *.jpg): yes. If malware is widespread and special detection is included, anyway: also yes. In all other cases: not necessarily required. > Some worms have been very small. Do you recall which one was the > smallest? Not a worm, but a successful program for Core Wars has been "The dwarf", a single <Move> command. > Should the AV examine every file for extra code? At least in manually <Scan all> mode definitely yes. And embedded complete executable files should be detected even when a simple XOR and the like is applied. BeAr -- =========================================================================== = What do you mean with: "Perfection is always an illusion"? = ===============================================================--(Oops!)===
From: Art on 18 Jul 2006 16:05 On Tue, 18 Jul 2006 19:57:04 +0200, "B. R. 'BeAr' Ederson" <br.ederson(a)expires-2006-07-31.arcornews.de> wrote: >> Should the AV examine every file for extra code? > >At least in manually <Scan all> mode definitely yes. And embedded >complete executable files should be detected even when a simple >XOR and the like is applied. I very rarely post to say nothing other than "I agree" but in this case I feel so strongly about the on-demand scanning issue that it's _really_ nice to see someone post a opinion I agree with. It's a good thing that I'm not in charge of a av scanner comparative test agency since I'd be flunking products left and right for not alerting on the froggies :) Art
From: edgewalker on 18 Jul 2006 16:03 "GEO" <Me(a)home.here> wrote in message news:44bbd190.31349322(a)news.telus.net... > On Mon, 17 Jul 2006 14:57:03 -0400, "edgewalker" <null(a)null.invalid> > wrote: > > >You want to detect the malware executable, and not any and all data stores that > >may contain data to be translated into code by said executable. > > The latest version of Bagle had a companion DLL that was made up of > letters. For all I know it might be information that was used by the > executable. Since dlls can be executable code, I would expect them to be scanned. I don't however expect that code hidden in there will always be recognizeable. It is trivial to have it encrypted (and thus non-executable without a helper program). > >Such trojans are already out there. There is no reason they can't themselves > >carry the additional code you would have embedded in jpegs for distribution. > >You "still" have to distribute the new trojan to make those jpegs useful. > > Some worms have been very small. Do you recall which one was the > smallest? I'm guessing Sapphire - a single packet connectionless (two way) worm. > >The "real" malicious part "is" the small translator that makes the embedded > >code executable. > > > > >...Otherwise, only executables can be considered malware. > >Don't execute malware, and you needen't worry > >about jpegs having hidden code in them. > > >....The size restrictions > >forced upon some buffer overrun attacks may make the placement of jpeg > >embedded code a worthy part of an attack scenario. > > What other formats could hide this extra code? Too many too list here for sure. > Should the AV examine every file for extra code? No, that's what I'm saying - they should concern themselves with the executable malware only and not with how or from where it fetches more code to execute. For instance, you want to detect a batch file that calls format.com while not detecting format.com itself. The malware itself, not the code it calls upon from elsewhere. You start detecting code in data files, then they go steganographic. They devise a way to detect the code even if steganographic techniques are used, so the malware writers will encrypt it also. At that point the "code" will be virtually undetectable - only there may be some clues that point to the fact that steganography was used. There may be no way at all for them to determine that encrypted and steganographically embedded code is not a legitimate part of the host data itself if it is done right.
From: edgewalker on 18 Jul 2006 16:26
"Art" <null(a)zilch.com> wrote in message news:0bfqb25ffmqmsj2eb99jm1j5ru55a7rcpt(a)4ax.com... > On Tue, 18 Jul 2006 19:57:04 +0200, "B. R. 'BeAr' Ederson" > <br.ederson(a)expires-2006-07-31.arcornews.de> wrote: > > >> Should the AV examine every file for extra code? > > > >At least in manually <Scan all> mode definitely yes. And embedded > >complete executable files should be detected even when a simple > >XOR and the like is applied. > > I very rarely post to say nothing other than "I agree" but in this > case I feel so strongly about the on-demand scanning issue that > it's _really_ nice to see someone post a opinion I agree with. It's > a good thing that I'm not in charge of a av scanner comparative > test agency since I'd be flunking products left and right for not > alerting on the froggies :) This is why AV gets so bloated with superflouos features. I'm sure e-mail scanning (coming and going) was adopted because users actually wanted AV to do this and would gravitate to those offerings that do and the ones that don't will lose marketshare. That doesn't make that feature any less useless. Scan all files for simple (and not so simple) encryption techniques,with and without steganographic embedding, on demand if you want to. But don't you think people will complain about how long it takes to thoroughly check all files this way? Why not just look for the malware, and if found look for the data store it attempts to fetch from. Why waste time with non-threats? |