In memory fileless malwar edetection ..... any antimalware software?

Discussion in 'malware problems & news' started by aigle, Sep 10, 2015.

  1. boredog

    boredog Registered Member

    Joined:
    Feb 1, 2015
    Posts:
    2,499
    "First requirement to be taken in is you have to be stupid" TRUE

    but what about those 80 year olds that are on the internet? My supervisor is always talking about his dad getting email like those. I seem to get that IRS is suing me phone call all the time too.

    Here is the latest one I got. Funny thing is I don't have a PayPal account. But of course they give a link to log in.

    Hello xxxxxxx@xxxxx

    You submitted an order in the amount of £35.85 GBP to Brakes Group.

    Thanks for using PayPal. Please note that this is not a charge. Your account will be charged when the merchant processes your payment. You may receive multiple emails as the merchant processes your order.

    Your funds will be transferred when the merchant processes your payment. Any money in your PayPal account at that time will be used before any other payment source.

    To see the full transaction details, log in to your PayPal account.

    Merchant
    Brakes Group.
    contact@xxxxxxxxxx
    01743362202 Instructions to merchant
    You haven't entered any instructions.
    Shipping address
    Dan Locke
    17 redmires lane
    Sheffield, S10 4jz



    Shipping details
    The seller hasn’t provided any shipping details yet.
     
  2. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    Came across a good ref. on how reflective DLL injection works for you. Read pages 2-4 of this document: http://www.infosecurityeurope.com/__novadocuments/85421?v=635660939307100000 . Also this will show why SRP and anti-execs will not stop it.
     
  3. boredog

    boredog Registered Member

    Joined:
    Feb 1, 2015
    Posts:
    2,499
    itman


    https://www.lumension.com/endpoint-management-security-suite/free-trial/total-track.aspx

    So who owns Bouncer now anyway?

    Through the acquisition of CoreTrace, Lumension ® Application Control includes CoreTrace’s Bouncer patentpending technology. Bouncer can detect and stop RMI attacks by monitoring an endpoint’s memory address space and associated processes for distinct evidence of exploitation. The architecture and kernel-level position of Lumension ® Application Control allow it to extend beyond simple whitelisting to provide memory protection.
     
    Last edited: Sep 26, 2015
  4. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    I believe CoreTrace's Bouncer not the same product as that referenced in Wilder's Anti-malware sub-forum, if that is what you are referring to?
     
  5. Mr.X

    Mr.X Registered Member

    Joined:
    Aug 10, 2013
    Posts:
    4,796
    Location:
    .
    I think he tried to point us to this one:
    http://excubits.com/content/en/products_bouncer.html
    https://www.wilderssecurity.com/threads/bouncer-previously-tuersteher-light.359127/
     
  6. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    17,546
    Location:
    The Netherlands
    Yes read about it, but this is not related to "process hollowing". And they also describe a scenario where an exploit is used. My confusion (in the MRG test thread) was about how malware that's running on the local machine (user install) can use this method. But you already explained.
     
  7. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    As I noted in the link I posted in reply #118 on process hollowing:

    The malware then writes it's own new code into the hollow host process using WriteProcessMemory, writing data to the memory allocated in the host process with VirtualAllocEx.
    Doesn't matter what the source process is; reflective dll injection, process hollowing, etc.. They all need to use the API function, WriteProcessMemory, to inject their code into a targeted process. The HIPS rule against process modification will detect and block it.

     
  8. Peter2150

    Peter2150 Global Moderator

    Joined:
    Sep 20, 2003
    Posts:
    20,590
    Just out of curiosity exactly what HIPS are we talking about.
     
  9. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    I use Eset's; the one included in Smart Security and NOD32. So far it has been able to catch any memory mod attempt for any process where I have defined a rule for process modification.

    Now, ROP and heapspray in the browser are different memory mod methods. Eset's exploit and memory protection located in its network filter handles those.

    My major complaint against it is that it doesn't support file name wildcards; e.g. *.exe. However, it does have a "start process" option that does the same thing. I have tested it against exec's renamed xxxx.scr for example and it prevented those from running. It does not however catch script startups e.g. .vbs, .bat, .cmd, etc. so I have to define separate rules to monitor their execution. Eset keeps saying they will be adding file wildcard support in the retail versions, but never does it. Now the endpoint versions have this feature plus many others.
     
  10. Peter2150

    Peter2150 Global Moderator

    Joined:
    Sep 20, 2003
    Posts:
    20,590
    Hi Itman

    There in lies the problem with the Eset HIPS. You have to define every rule. So if you mess up and don't catch a rule it doesn't work. That's why I like the combo of ERP Appguard, and SBIE
     
  11. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    Well, you don't have to. I do it as additional protection.

    My approach is to try to stop the 0-day malware execution initially using EAM's and Eset's behavior blockers. This should stop 95% or so of all that type of malware. However, there are these nasty exploits, signed/cloaked malware, etc., so the HIPS rules are primarily a backup to try to mitigate their damage.
     
    Last edited: Sep 29, 2015
  12. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    17,546
    Location:
    The Netherlands
    OK, I see what you mean. But there is still a difference between the two, with process hollowing, malware tries to fool HIPS by starting up a system process. So HIPS should watch for modification to child processes.
     
  13. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    A HIPS by definition is an anti-executable plus a whole lot more. HIPS's existed long before the current breed of anti-execs hit the market.

    To run a HIPS in "anti-executable" mode, you first do the same thing that you do for the current anti-exec software - you set it to training mode to whitelist all your current apps. Once that is completed, you then set it to "policy mode." In that mode, it will block any executable that is not whitelisted. There are obvious disadvantages to this such as when new software has to be installed, updated, etc.

    The next mode of operation a HIPS has is interactive mode. In this mode, you will receive an alert for non-whitelisted executable with options to:

    - allow and optionally have the HIPS create corresponding rules for new applications or processes or;
    - deny the execution and optionally have the HIPS create a permanent block rule for the processes or applications.​

    The above two modes are the most secure means of HIPS operations. They are also the ones that require the most user interaction with the HIPS.

    The mode I use is less secure than the above two modes but require less user interaction. I predefine all known vulnerable apps and system processes and registry areas. I then add more detail protection options to those processes. Also, every HIPS has predefined rules that can't be modified and allow for the execution of critical system processes like driver loading and the protection of critical system processes and registry areas so those don't have to be use defined.

    From a cost point of view, purchasing an Internet Security suite with a HIPS is less costly than purchasing separate AV and anti-exec software. Actually, one of the best HIPS's on the market is free; Comodo's Defense+.

    Finally there is the "integration factor." The firewall, AV components, and the HIPS are all designed to work together as an integrated security protection device when incorporated into an Internet Security suite.
     
  14. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    The malware loads the target process, let's say it's a browser stub, in a suspended state. It's doing this to evade detection tampering both by the OS and AV software. It then craves out it's memory, injects the malicious code, tidies up protected code areas, and then starts the process. Finally, the malware terminates itself. Hence the term "zombie" process because the browser instance at this point is running without a parent process. If you view all this in Process Explorer for instance, you would see the malware stub located under the parent browser instance. However if you view the malware stub details, you will see that it has no parent process.:eek:

    Now this can be prevented a couple for ways using a HIPS rule:

    1. Monitor all startup instances of the browser. In most cases; it should only be explorer.exe.
    2. Monitor the suspending or termination of the browser. In most cases it should only be explorer.exe or the browser itself for any stubs it generates.
    3. I still believe a HIPS process modification rule for the suspended process will detect any memory modification for the suspended process. I will test this shortly with the refective dll test tool I have.

    -EDIT- Suspended an IE11 browser stub instance and ran the refective dll injection test tool to inject the reflective dll into the suspended process. My Eset HIPS rule for IE11, stopped the injection attempt of the suspended process.:thumb:
     
    Last edited: Sep 29, 2015
  15. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    Came a across a technique used by CPUZ HWMonitor that is very interesting. If malware used the same, it could run virtually undetectable on your PC.

    Assumptions: the malware payload is allowed to run and is running with least at admin privileges. Payload could be an exploit or coupled with an exploit that could escalate privileges to full admin level. Most likely a memory injection of malware into a legit process. I became aware of this because I had Eset's HIPS set to monitor changes to all registry start up areas.

    Below are the steps CPUZ HWMonitor uses to execute unimpeded by most conventional security software. Due to the system hardware monitoring CPUZ HWMonitor performs, it pretty much runs with driver level privileges.

    1. C:\Windows\System32\services.exe Modify startup settings HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\cpuz138\Start
    2. C:\Windows\System32\services.exe Modify startup settings HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\cpuz138\ImagePath
    3. C:\Windows\System32\services.exe Modify startup settings HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\cpuz138\Start

    Explanation

    Developers of CPUZ HWMonitor were clever enough to use a registry area, ControlSet001, that is not monitored for the most part by most conventional security software. Using services.exe, CPUZ HWMonitor creates a start registry key for CPUZ HWMonitor (Step 1). Services.exe then modifies same to create an ImagePath key pointing to a system monitoring process .exe location (Step 2). CPUZ HWMonitor using services.exe then starts execution of the system monitoring process.

    Upon CPUZ HWMonitor completion, it uses services.exe to delete all CPUZ registry keys it previously created resulting in all traces of its activity being removed from the registry(Step 3).

    -EDIT- Actually it is HWMonitor that does this. Developer is CPUZ.
     
    Last edited: Oct 8, 2015
  16. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    17,546
    Location:
    The Netherlands
    I don't get it, what's so special about this? You should only allow fully trusted apps to install services, because they have system rights. And if you do allow them to be installed, these services should normally still be monitored for suspicious behavior. Although it's likely that a lot of HIPS will automatically trust installed services.
     
  17. Gullible Jones

    Gullible Jones Registered Member

    Joined:
    May 16, 2013
    Posts:
    1,466
    @Rasheed187
    If I'm reading that right, it fools Windows into invoking the executable as SYSTEM user, and then erasing the registry entry used to do so... And does so without alerting any of Windows' native security mechanisms.

    IOW, this sounds like a privilege escalation hole.

    @itman
    Have you notified Microsoft about this? I mean, I'm not very familiar with the company policy side of this stuff, but it seems like the kind of thing they'd want to know about.
     
  18. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    Actually, most HIPS would not be monitoring ControlSet001 registry key by default. This is why I posted this. BTW - another service that runs at start up from this registry key is Encrypted File Service.

    -EDIT- When an app creates a required service, it usually does so when it is being installed and running with Installer privileges. Also the service is permanent; it remains in the registry.

    Actually, I didn't quite explain this right. At startup time, the OS uses a setting in the registry to determine what hive to use as the active load point. This is almost always ControlSet001. So if you want to run a service dynamically, just create it in that location. Ref.: http://blog.cylance.com/windows-registry-persistence-part-2-the-run-keys-and-search-order
     
    Last edited: Oct 9, 2015
  19. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    17,546
    Location:
    The Netherlands
    Yes, but you could have blocked it from starting the service, correct? This is all what counts, and like I said, malicious behavior from services should still be blocked by HIPS, unless you trust the service.

    I didn't read anything about bypassing UAC?
     
  20. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    The problem is you can't really effectively monitor ControlSet001 changes with a HIPS rule since it's a transitory key. At boot time, it is loaded with data currently present in ControlSet key.

    From a forensic point of view, it is a good practice to review data in ControlSet002 key since it will be refreshed with whatever was in ControlSet001 at system shutdown time.
     
    Last edited: Oct 11, 2015
  21. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    Came across a Blackhat presentation that describes every type of malware injection that exists: https://www.blackhat.com/presentati...Presentation/bh-usa-07-butler_and_kendall.pdf . Toward the end of this is a "real eye opener" I am sure most are not aware of.

    Also of interest in this article is how Meterpreter works since it also performs memory based injection. Note from the below screen shots that it has to set a hook prior to each API function it performs:

    Metasploit Meterpreter 1.png

    Metasploit Meterpreter 2.png
     
    Last edited: Oct 12, 2015
  22. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    17,546
    Location:
    The Netherlands
    Yes interesting, the question is, does it make sense to monitor these API's inside exploited processes. I'm not sure if other legit processes are hooking these API's inside browser memory for example.
     
    Last edited: Oct 13, 2015
  23. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    Yes, monitoring API hooks like those posted would be difficult and problematic. You would need a high powered endpoint HIPS to do so and you would probably bork the app.

    However, non-OS based API hooking is not easy and does leave a tracking trail that could be monitored as noted below:

    Hooking API calls is more complicated, more messy. There is no built-in way to do it; you usually want to find a library to help you such as Detours.
    http://research.microsoft.com/en-us/projects/detours/

    You can use Deviare API Hook for this. With this library you can hook any API in 10 lines of code even with .NET. The difference with Detours is that you don't have to write the code that is inserted in each process. You can hook all the processes you want just attaching them. Then, you receive the calls in your own process.
    http://www.nektra.com/products/deviare-api-hook-windows/


    Ref: http://stackoverflow.com/questions/...specific-api-on-windows-with-setwindowshookex
    There is a section on Detours in the Blackhat presentation link I posted previously.
     
    Last edited: Oct 13, 2015
  24. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    There is a good discussion on hooking here: http://malwaretips.com/threads/how-advanced-persistent-threat-works.48396/ reply #16.

    Also there is a general consensus in the security community that most malware which uses hooking for dll injection, will use SetWindowsHooksEx since it is the easiest to implement. This is especially true on x64 OS's since many of the API hook functions no longer work properly. Most retail HIPS's support monitoring of this. I use Eset's HIPS for monitoring a number of OS programs along with all my Internet facing apps for SetWindowsHooksEx with no adverse effects. You do have to create an exception rule to allow any security apps you have since many of those use SetWindowsHooksEx to insert their own monitoring hook dll in the same OS and app program .exe's.
     
    Last edited: Oct 13, 2015
  25. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    FlashPlayer Exploit Using Metasploit

    This link explains the whole Metasploit processing in detail: http://null-byte.wonderhowto.com/ho...h-windows-8-using-adobe-flash-player-0155228/ . The initial Meterpreter DLL payload download is being initiated via an external malicious web server download. From this SANS article: https://www.sans.org/reading-room/whitepapers/forensics/analysis-meterpreter-post-exploitation-35537:

    When the payload is downloaded it is saved only to RAM, and from there it is migrated to other processes as required. This technique is called Reflective DLL Injection, which is beyond the scope of this paper.

    Although it is not stated explicitly anywhere, a memory exploit to FlashPlayer would have had to occur first. This is necessary to create a place to store the Meterpreter DLL payload download. Also the Meterpreter DLL payload download has to contain an executable and other garbage to perform the reflective injection of the Meterpreter DLL into other processes. All this being run remotely from the rouge server.

    The only way to prevent this is by catching the initial FlashPlayer memory exploit. Some AV and HIPS's IPS processing is capable of detecting the Meterpreter DLL download; e.g. Eset's did:

    10/12/2015 7:24:55 PM HTTP filter file https://www.offensive-security.com/metasploit-unleashed/msfpayload Win32/Agent.QKN trojan connection terminated - quarantined. xxxxxx\Dxx Threat was detected upon access to web by the application: C:\Program Files\Internet Explorer\iexplore.exe.​

    Additionally, HIPS rules for detecting process modifications would have alerted/blocked any reflective injection attempts of the Meterpreter DLL.

    In any case, there is no way any anti-exec would catch this!
     
    Last edited: Oct 13, 2015
  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.