Page 3 of 4 FirstFirst 1234 LastLast
Results 21 to 30 of 32

Thread: Forensic Analysis of Malcode - Step by Step

  1. #21
    Senior Member nihil's Avatar
    Join Date
    Jul 2003
    Location
    United Kingdom: Bridlington
    Posts
    17,188
    I am confused

    what good is a keylogging backdoor trojan that prompts for a password before it runs on a victim's machine?
    I would have thought that you would want to protect it?

    1. To stop others stealing your "bots"
    2. To stop anybody/thing messing with it.

    Isn't there a bit of confusion here between "installing" a trojan and "running" it subsequently?

  2. #22
    Junior Member TangledWeb's Avatar
    Join Date
    Apr 2004
    Posts
    10
    TH13 - just to let you know that I found your Tut on the forensic analysis of malcode informative and illuminating.

    TW

  3. #23
    Master-Jedi-Pimps0r & Moderator thehorse13's Avatar
    Join Date
    Dec 2002
    Location
    Washington D.C. area
    Posts
    2,885
    would have thought that you would want to protect it?

    1. To stop others stealing your "bots"
    2. To stop anybody/thing messing with it.

    Isn't there a bit of confusion here between "installing" a trojan and "running" it subsequently?
    Thank you Nihil. Indeed there have been many cases where drone armies (botnets) have been hijacked by competing criminal groups. So as you see, protecting your criminal enterprise is very common, thus, my commentary on the malware sample used in this tutorial.

    Now, I have mentioned in published articles, IRC channels, this site, in training classes, basically everywhere I go, that there is no central regulatory group on forensics (as of this writing) and because of this, what one person says is good another may say is bad. In this case, someone felt that the abscense of going through ASM registrys indicates that something was wrong along with his two inaccurate views on av engines and malware.

    That said, I stand by the information in my tutorial as 100% accurate and best practice, with the absolutely minor technicality of referring to Olly and Softice as hex editors (which they are) instead of a full debugging suit.

    I'm done with this. No further comments will be made by me in this thread.

    --Th13
    Our scars have the power to remind us that our past was real. -- Hannibal Lecter.
    Talent is God given. Be humble. Fame is man-given. Be grateful. Conceit is self-given. Be careful. -- John Wooden

  4. #24
    Senior Member
    Join Date
    Jun 2003
    Posts
    188
    A few things i would like to say

    1. If you don't have a seprate machine use vmware ( i am amazed how it was missed out).

    2. thhorse13 i think you missed out a very basic point, you need *skills* to study
    a malware not just tools.

  5. #25
    Senior Member nihil's Avatar
    Join Date
    Jul 2003
    Location
    United Kingdom: Bridlington
    Posts
    17,188
    1. If you don't have a seprate machine use vmware ( i am amazed how it was missed out).
    I am not...................it is no "silver bullet"..............fine for testing different systems, interfaces etc. but it should not be regarded as a security solution

    If you want to analyse malware seriously you should do it on a separate machine/network NOT in your production environment.

    To even begin to learn practically, you need the right tools; both software and hardware.


  6. #26
    Junior Member
    Join Date
    Dec 2005
    Posts
    4
    nihil your question was a good one - it is true that malware authors do try to protect their code from analysis. the way in which they do this is by encrypting the executable. this prevents the code from being disassembled and reverse engineered easily.

    this encryption is commonly combined with compression, and the result is what is commonly referred to as 'packing'. this is the most effective technique used by modern malware authors to subvert analysis as well as detection by anti-virus software. the reason for this is that in order to perform anything more advanced than pattern-matching (where a sequence of bytes is used as a 'fingerprint' for detection), the code in a executable must be read by the scanning engine. in order to do this the layer of encryption or packing must be gotten past.

    more advanced detection techniques include sequencing of API calls or strings in a malware family that enable pro-active detection of new variants. this is something done by all the better anti-virus vendors, and obvious examples of malware that are frequently detected proactively are common bot families such as agobot, sdbot or rbot.

    one might reasonably think that there is a significant difference between the installation and subsequent running of a malware executable. however it is rarely desirable or practical from the point of view of the malware author that he/she be at the victim's machine to install the malware. in practice the malware is written in such a way that it effectively installs itself on first running by copying itself to somewhere like the system folder and creating registry keys that ensure this copy is automatically run on startup, but in a covert fashion. the reason for this is that the machine is usually compromised remotely. this may in the case of a trojan be through a webpage that contains an exploit to force Internet Explorer to download and run a trojan from a location on the internet. a network worm may exploit vulnerabilities in network services to compromise a machine.

    one method that is not seen in common malware is the use of password protection. this is seen in evaluation or shareware software, but not malware. this is not, i hasten to add, my opinion! this is i am afraid a fact based on practical experience. i take the lack of forthcoming examples of any malware that uses password protection as a testament to this!

    it may be fair to state that there is no 'central regulatory group on forensics' however there are many security companies, most notably anti-virus vendors, that depend on the quality of their analyses and detection to survive in a competitive commercial market in a world where there are many threats to internet security.

    these vendors have established best-practices when it comes to analysing and detecting malware. these best practices have at their forefront a thorough understanding of the malware code, the architecture of the operating system and processors. this is only possible through possesing knowledge, as warl0ck7 states, of most importantly assembly language, as this is how machine code is represented in a disassembler or debugger. the disassembly of a malware sample is the most important aspect of commercial professional malware analysis. fact. (assembly language has nothing to do with the windows registry, it is not hexadecimal code and i reiterate the ollydbg are softice are most certainly *not* hex editors!)

    my 'views' on the anti-virus industry are accurate and truthful for a very compelling reason! please justify any future criticisms you might have with substance and example! believe me everything i have submitted to this forum stands up to close technical scrutiny.

    have a merry christmas.

  7. #27
    Senior Member nihil's Avatar
    Join Date
    Jul 2003
    Location
    United Kingdom: Bridlington
    Posts
    17,188
    Hmmmm,

    You want an example?

    one method that is not seen in common malware is the use of password protection. this is seen in evaluation or shareware software, but not malware. this is not, i hasten to add, my opinion! this is i am afraid a fact based on practical experience. i take the lack of forthcoming examples of any malware that uses password protection as a testament to this!
    http://en.wikipedia.org/wiki/Sub7

    I would consider SubSeven to be pretty common malware, and it is password protected.

    I think that a clear distinction needs to be made between remote access, key logger type software and the virus/vandal type of stuff. The latter are typically "fire and forget" whereas the former require tending/management.

    Virus/vandal type software would tend to be encrypted, compressed, armoured, polymorphic etc.

    All the remote control software needs to do is load surreptitiously and run undetected. It is natural for the server side of this software to be password protected as you want to avoid losing control of it and the machine you have installed it on.

    Really this is no different from perfectly legitimate keylogging and remote management software of which there are numerous examples that can be purchased on the open market.

    What I am saying is that there is a grey area into which this software type falls, and it is really the motivation of the user that determines whether it is malware or not.


  8. #28
    Junior Member
    Join Date
    Dec 2005
    Posts
    4
    i am glad we now seem to be in the realms of a proper discussion.

    in the case of a subseven-type backdoor trojan, the password protection you refer to is a remote authentication presented by the installed backdoor to anyone trying to connect to it through the backdoor (usually from another machine!)

    the password protection mentioned in this discussion was presented as a barrier to the static and dynamic analysis of a malware binary sample that you might have on your own computer that you wish to analyse! (i.e. the unpacking/running, although this point is somewhat confused)

    it is worth clarifying the distinction between a password preventing the unpacking and/or running of an executable (which does exist in the realms of legitimate software protection) and a password for something like an IRC channel that a running bot might check for before accepting remote commands.

    there is to be fair a significant difference between these two things, and if you have in your possesion a backdoor malware sample that you wish to analyse dynamically (i.e. by running it in a debugger or with other monitoring tools) or statically you will not encounter password protection as a barrier to this. the barrier to disassembly or other static analysis is the packer.

    it may be that a given malware sample has been compiled with hardcoded credentials such that when it is run it will only allow authenticated users to communicate with it using the backdoor it creates. this is however not a barrier to analysis of the binary itself, since with a proper unpacking and disassembly the full functionality of the malware - and any hardcoded credentials - are open for analysis.

  9. #29
    Senior Member
    Join Date
    Jun 2003
    Posts
    188
    bah most of the malwares are rotten cut and copy paste code, the best
    packing you can find is asprotect. Most of them are written in borland delphi.

    also in these times it is not hard to have tools only skills.

  10. #30
    Junior Member
    Join Date
    Mar 2006
    Posts
    1
    hi,

    thank you for that real great and interesting tutorial, for now i found that very useful,

    i´m not new to security related things, as it may seem cause it is my first post, as i said above i will try that on my home pc, can anyone give me a good advice with which malware i can do that for educational purposes that does not get me in to big troubles with my pc and it´s settings.

    is there a malware that is not a big potential security threat

    thank you for that.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •