Can malware load/execute themselves without windows loader

Discussion in 'malware problems & news' started by victor43, Dec 13, 2011.

Thread Status:
Not open for further replies.
  1. victor43

    victor43 Registered Member

    Joined:
    Nov 4, 2009
    Posts:
    43
    Hello. I would like to know whether its possible for an executable (i.e. malware) to load itself into memory and execute without going through the windows loader. Say malware had a separate loader file that its only job was to load another file (malware) into memory and to start its execution but without using the aid of the windows loader. Please note that I am referring to the windows loader and NOT the boot loader. I am not sure whether there is an instance of malware that exist and that could do this but I thought I would ask. My interest is strictly from a detection stand point of view only.

    Thanks in advance

    Victor
     
  2. Magnus Mischel

    Magnus Mischel Security Expert

    Joined:
    Oct 24, 2002
    Posts:
    185
    If you are referring to malware being able to start without using CreateProcess(), then yes, that is possible so long as another program which is specifically designed to do this is involved. You can use CreateFileMapping, MapViewOfFile(), and specify the correct flags to get a process up and running. You'll need to use some undocumented functions and flags and functions which however are fairly widely known.

    However, this requires the program that does this to be "in on it". And that first program has to be started somehow. And it would likely be classified as malware as no regular program does this. So, in short, you can't have malware just launch itself like this without the aid of another malware program.
     
  3. Searching_ _ _

    Searching_ _ _ Registered Member

    Joined:
    Jan 2, 2008
    Posts:
    1,988
    Location:
    iAnywhere
    Javascript through the browser maybe?
     
  4. victor43

    victor43 Registered Member

    Joined:
    Nov 4, 2009
    Posts:
    43
    Thanks Magnus. Yes that is what I mean, an executable A gets executed via whatever legit method i.e window service or autorun or patching a windows system file but in turn it launches another executable B without using functions like shellexecute or winexec. If a malware executable B is a kernel mode driver then I suppose avoid the use of StartService...to get the driver module up and running...Does this exist in the wild ?

    Thanks to both replies.

    Victor
     
  5. wat0114

    wat0114 Guest

    This is a good question, one I'm glad to see someone ask in a point blank manner :thumb:

    It seems drive-by downloads, the way they are often discussed in forums, are as close to "automatic" as an exploit can get, although from what little I understand about them, there is a "triggering" mechanism involved with them, too. I'd really like to see expert opinion, or even semi-expert for that matter, and discussion on them, if possible :)

    There is pretty good, recent article on them here:

    -http://blogs.technet.com/b/security/archive/2011/12/08/what-you-should-know-about-drive-by-download-attacks-part-1.aspx

    There's a part 2 as well:

    -http://blogs.technet.com/b/security/archive/2011/12/12/what-you-should-know-about-drive-by-download-attacks-part-2.aspx
     
  6. Searching_ _ _

    Searching_ _ _ Registered Member

    Joined:
    Jan 2, 2008
    Posts:
    1,988
    Location:
    iAnywhere
    GnuCitizen has some pretty good articles about Javascript malware and how it would access memory and various functions used to go deeper. The browser could be considered A in your scenario, executed by the user.
     
  7. trismegistos

    trismegistos Registered Member

    Joined:
    Jan 29, 2009
    Posts:
    363
    Though not exactly a malware but a penetration/hacking tool, the Metasploit framework's VNC and Meterpreter shells can be loaded from memory and it's very hard to detect using the usual rootkit detection tools. But of course by now AV with memory scan capability already have signature of those payloads but it could be obfuscated to go beyond the radar screen once again.

    Those dlls loaded from memory still needed an initial exploit however.
     
  8. wat0114

    wat0114 Guest

    I checked out a couple of those. Some nice easy to read and informative posts. Thank you!
     
  9. J_L

    J_L Registered Member

    Joined:
    Nov 6, 2009
    Posts:
    8,738
    I'm posting comments with loading on threads now...

    Anyhow, how do we detect the forms of threats?
     
  10. trismegistos

    trismegistos Registered Member

    Joined:
    Jan 29, 2009
    Posts:
    363
    Last edited: Dec 15, 2011
  11. J_L

    J_L Registered Member

    Joined:
    Nov 6, 2009
    Posts:
    8,738
    Looks like rather limited distribution.
     
  12. trismegistos

    trismegistos Registered Member

    Joined:
    Jan 29, 2009
    Posts:
    363
    ^
    Not everyone will be a recipient of targetted attacks. But we can expect more and more future malwares having those types initially as initial trojans then downloading more malwares like tdl4 variants, mbr trojans or rootkits to hook deeply and persistently into the host systems.
     
  13. trismegistos

    trismegistos Registered Member

    Joined:
    Jan 29, 2009
    Posts:
    363
    The closest thing, probably, is Duqu. But not exactly(more on that later on).
    [​IMG]

    Exploit -> kernel -> driver in kernel -> loader dll in services.exe -> big pnf in services.exe -> big pnf installing from lsass or AV process

    Though, executable A is not actually an executable but a shellcode(the payload of the exploit on the win32k.sys vulnerability via true type font) loading a kernel mode Driver, your executable B. However B is not yet the main module and will still need to inject the main dropper dll to services.exe to install the main malicious module. Well, if you consider Executable A as the legitimate application, i.e. Microsoft Word. Then, this could be it. But, then again, Word is a legitimate trusted process and not a rogue one that was legitimately installed. Not exactly to your given scenario of two executables(malwares) since this is only a single malware.

    ==============
    Nice to know...

    [Still using CreateProcess, however]
    Reverse shell through DLL Injection using undocumented API function
    Code:
    http://0x191unauthorized.blogspot.com/2011/08/reverse-shell-through-dll-injection.html
    Shell of the Future – Reverse Web Shell Handler for XSS Exploitation
    Code:
    http://blog.andlabs.org/2010/07/shell-of-future-reverse-web-shell.html
    Exploring Javascript Shellcode Using Metasploit
    Code:
    http://vinasupport.com/2010/exploring-javascript-shellcode/
     
    Last edited: Dec 18, 2011
  14. trismegistos

    trismegistos Registered Member

    Joined:
    Jan 29, 2009
    Posts:
    363
    After rereading the Duqu FAQ, we can definitely say that the Duqu malware fits your hypothetical scenario. Duqu(the TROJAN backdoor) was installed by an exploit in memory and was able to download IN MEMORY and execute another malware, an INFOSTEALER...

     
  15. cozofdeath

    cozofdeath Registered Member

    Joined:
    Dec 18, 2011
    Posts:
    6
    Location:
    USA
    Yeah, I think most malware uses some type of hook/injection. I mean don't almost all of them rely on exploits in order to do this which is injection usually? I really can't see a piece of malware using a map api or shellexec type function because it would be be detected easily by avs and you would still have to inject code somewhere right? I mean what would you be executing? It would already have to be on the machine and in a specific location and how would you get it there?
     
Thread Status:
Not open for further replies.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.