What Kind of Malware Can Bypass Anti-Exes?

Discussion in 'other anti-malware software' started by Brandonn2010, Jun 15, 2012.

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

    Brandonn2010 Registered Member

    Joined:
    Jan 10, 2011
    Posts:
    1,854
    Title is self-explanatory. Anti-exes seem like they would have a near 100% effectiveness like policy-restriction programs, but what kind of malware could bypass them?
     
  2. STV0726

    STV0726 Registered Member

    Joined:
    Jul 29, 2010
    Posts:
    900
    I had a mini-debate with HungryMan on this recently, actually...

    He is one of the experts here that claims anti-execution via an anti-EXE app, software restriction policy, applocker, etc...is NOT a good security mechanism. He claims it is just security through obscurity and if enough people used it malware authors would trivially find holes in code to bypass them...and/or use techniques such as hijacking already whitelisted programs (such as the browser) to run stuff and poop your computer up.

    Where's the proof? Ehh..maybe one piece of malware that was designed as a specific-type of attack. So...almost none. It's kinda theoretical at this point. Yes, it can be done, but after days of talking with him, I still find it hard to abandon anti-executable for this one weak spot, and here's why...

    Processes can communicate to other processes on the same level. Most people I'm aware of that are smart enough to use anti-executables also use it with a standard user account or at least on an admin account with UAC turned to always on. If set thusly, then hijacked processes (again, like a browser) running without admin token cannot do any real damage to Windows itself. If Windows/the user's PC is unaffected, in my philosophy, I consider the malware attack unsuccessful. A growing many will certainly disagree with me here, pointing to the alarming increase in social engineering attacks. I do not disregard those...I simply put them in a different category of cybercrime...because technically...it can be done without any malware at all...or it can be done simply by running an executable on a LUA and asking someone to put their credit card information in. The best defense for that is RIGOROUS USER EDUCATION. Really, it's a separate debate IMO.

    --> There ARE privilege escalation exploits though. Most of them rely on default Windows 7 UAC setting as far as I'm aware.


    Next, if you use EMET, you can apply that system-wide and/or to your browser to help plug any of these holes that may or may not exist. Additionally, what I do is I use Sandboxie for browsing and risky Internet applications as an added layer of protection.

    --> HungryMan affirms that Sandboxing & Virtualization is the best type of security, and I would agree...but I still affirm that the Software Restriction Policy is the (2nd) best thing an INTERMEDIATE to ADVANCED Windows user can do to kick their level of security up into the clouds.

    Many experts do rely on just SRP alone. I am not one of them. I advocate for a layered approach...always & forever.

    Just my two cents...more like two dollars. Hope this helps, though it will likely continue to make many of us drift into uncertainty for a bit. :p

    (Note: I am paraphrasing/summarizing HungryMan's viewpoints from a previous thread. Giving credit where credit is due.)
     
    Last edited: Jun 15, 2012
  3. m00nbl00d

    m00nbl00d Registered Member

    Joined:
    Jan 4, 2009
    Posts:
    6,623
    If you got time, dedication and resources, anything becomes bypassable. But, in order for that to happen, you'll need precisely to find how to bypass any thing, and this means anti-executable, sandboxes, virtualization... And, if it isn't this, then it will be something like what's mentioned here -http://www.h-online.com/security/news/item/Intel-CPUs-affected-by-VM-privilege-escalation-exploit-1616866.html

    Saying anti-executables are worthless doesn't reflect the reality, IMHO. While it's true this sort of security mechanism isn't used by the masses, it's also true it is used by enterprises. Is there any actual data that reveals these security mechanisms failed protecting against targeted attacks, in such environments?

    Are they the silver bullet? Nope. Then again, nothing really is.
     
  4. STV0726

    STV0726 Registered Member

    Joined:
    Jul 29, 2010
    Posts:
    900
    ^ +1

    I forgot to mention before that my theory ultimately boils down to the notion that implementing anti-execution correctly provides a much higher prevention rate than any anti-malware application/black list measure... many people say 99% or 99.99%.
     
  5. blacknight

    blacknight Registered Member

    Joined:
    Sep 25, 2007
    Posts:
    3,344
    Location:
    Europe, UE citizen
    I agree with all said things here. But i wonder why don't prefer to use an HIPS, that join " anti exes " functions with a full control of the system - if the user is smart.
     
  6. Scoobs72

    Scoobs72 Registered Member

    Joined:
    Jul 16, 2007
    Posts:
    1,113
    Location:
    Sofa (left side)
    It's a tricky question to answer precisely because there isn't really that much malware that can bypass anti-execs. A big question is "what type of anti-exec", because you could be talking about a HIPS (e.g. Online Armor), a pure anti-exec (e.g. Faronics) or something built into Windows (e.g. SRP, Applocker or parental controls).

    It also depends on what you mean by "bypass". A HIPS could allow malware to execute because it is signed by a CA that is on the HIPS trusted list, for example. Is that a 'bypass'? SRP can be theoretically bypassed using macros or executing using specifc flags (sandbox_inert) if I recall - but it doesn't appear to have been used by any malware and a patch is now available from MS.

    Then you have privilege escalation attacks, that DLL loading trick where a malicious DLL is loaded from the 'wrong' location...and probably a bunch of others than I can't remember.

    So, in general (and this is being very generalist), signed malware is probably the biggest risk for a HIPS, and privelege escalation is probably the biggest risk for SRP.
     
  7. m00nbl00d

    m00nbl00d Registered Member

    Joined:
    Jan 4, 2009
    Posts:
    6,623
    Didn't Microsoft solve that issue already? I know they released a hotfix for AppLocker. I don't recall if they have released one for SRP? Anyway, anyone using a Windows 7 version with AppLocker, should choose to use it, instead of SRP, and simply because SRP is weaker, because it works at the user-level, while AppLocker works at the kernel-level, making it harder for malware to bypass it.
     
  8. tuatara

    tuatara Registered Member

    Joined:
    Apr 7, 2004
    Posts:
    777
    Of course there is malware that can bypass this kind of antimalware,
    but the biggest problem is, the end user that needs to decide if the exe is safe or not.

    In a company were only administrators decide which exe's are allowed to run, this is not really a problem.

    But for the average enduser that has downloaded/got new software, it certainly is.

    I think this 'anti-executable-only' software is a VERY good addition to your system security, if wisely used, but it must be seen as 1 layer of it.

    BTW , of course you can install this (for example) on the pc of your kids, and keep the password to yourself
    that way your kids are unable to start executables that are unknown to you.
    And in that case even average user pc's are better protected :)
     
  9. noone_particular

    noone_particular Registered Member

    Joined:
    Aug 8, 2008
    Posts:
    3,798
    There's a lot of other factors involved here, starting with the method/app used to enforce the whitelist. Some classic HIPS for instance can also be configured to control the interactions between different whitelisted applications. Using the pro version of SSM on XP for instance, the user can specify any/all of the following for each individual process:
    1. allow/deny physical memory access.
    2. allow/deny low level disk access.
    3. allow system shutdown.
    4. allow/deny low level keyboard access.
    5. allow/deny remote code control.
    6. prevent suspending of threads and processes.
    7. allow/deny remote data modification.
    8. block/allow to terminate other processes.
    9. Allow only whitelisted command line parameters for each.
    Combine these with the ability to specify which other applications/executables each is allowed to start or be started by (parent-child settings) which can load drivers, and to an extent DLLs, and it becomes much more difficult to maliciously use another whitelisted process or to gain access to the memory used by another process. In addition, the user can choose to protect individual processes/executables from any or all of the following, even when another process has permission to perform them:
    1. Termination
    2. Suspending.
    3. Inter-process messaging.
    4. Remote code control.
    5. Remote data modification.

    Specifying each of the above for each executable/process on your system is a very time consuming process. It requires the user to know or be able to determine which if any of the above needs to be allowed for a specific executable, and when. For most users, it's a complete overkill and is beyond anything they'll want to do. It's also much easier to implement such restriction as you build your system than it is to apply it to an already completed unit. I don't use Vista, 7, or 8 and am not familiar with the abilities and limitations of other HIPS and process controlling applications, or how much those operating systems restrict their abilities to perform those tasks.
     
  10. curious george

    curious george Registered Member

    Joined:
    Jun 24, 2007
    Posts:
    218
    I can kind of see both sides of the arguement...

    When one thinks of linux, and how secure it is, one must awknowledge its marketshare too. I mean linux is in essense far more secure off the bat than windows (at least in my opinion), but, thats not completely why there is very little viruses written for it. Its the fact that not too many people use it.

    Same senerio applies here. Sure, anti-executables will prevent a whole lot of malware...but lets say the market share for oh, i dont know, defensewall booms, and most users use it...well, you can expect malware written to target and bypass it.


    Just my two cents...
     
  11. Scoobs72

    Scoobs72 Registered Member

    Joined:
    Jul 16, 2007
    Posts:
    1,113
    Location:
    Sofa (left side)
    The same patch applies to Applocker and SRP.
     
  12. noone_particular

    noone_particular Registered Member

    Joined:
    Aug 8, 2008
    Posts:
    3,798
    Agreed. The HIPS and signed malware problem can be at least partially mitigated on some HIPS via their options. SSM pro for instance allows you to decide if you trust signed files.
    SSM signed.GIF
    I'm sure others do as well, but using this option does make updating more of a manually performed administrative task. Looking at the latest problem with Windows Update and the potential for similar problems with other vendors, manual updating isn't necessarily a bad idea.
    That is possible, and if it can be done, someone would find it. Like before, there's a lot of variables. Near the top of that list is getting access to the HIPS in order to attack it. Unlike the browser, the HIPS doesn't need to be an exposed part of your attack surface. This is one reason I prefer a separate HIPS, not one that's part of the firewall. An attack would need to come thru another app that can be targeted, exploit a buffer overrun, use an unmonitored or undocumented API, etc. Possible, yes. Definitely not easy, especially when the OS itself is hardened.
     
  13. Scoobs72

    Scoobs72 Registered Member

    Joined:
    Jul 16, 2007
    Posts:
    1,113
    Location:
    Sofa (left side)
    I think we're talking about different issues here. I don't mean malware that uses a forged digital signature (i.e. which your SSM checkbox would take care of), I mean malware using a valid certificate, either because they have been erroneously issued one by the CA (it happens a lot), or the malware author has signed their own malware using a stolen private key. HIPS are going to let those through unless the specific CA or certificate is blacklisted.
     
  14. noone_particular

    noone_particular Registered Member

    Joined:
    Aug 8, 2008
    Posts:
    3,798
    I can't comment on other HIPS but some like SSM can be configured to not regard signing or certificates at all, and focus solely on file integrity. It treats signed and unsigned exactly the same. If an update replaces explorer.exe or browseui.dll, SSM will intervene and ask if you want to accept that change, or if its UI is disconnected, it will deny without asking.
     
  15. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,146
    Any malware can be designed to work from RAM instead of Disk.

    Normally you have:
    1) Attack in RAM
    2) Drop payload to disk
    3) Execute from disk

    This method is useful because it breaks drive by downloads up into smaller files (you only need one dropper file.)

    There is no reason why an attacker has to rely on this. It's easier, that's it. They can handle most things in the address space.

    What you lose with an attack that is stuck in RAM is persistence. RAM is cleared on shutdown. That's pretty big but consider how much an attacker can do from RAM in a short time, even within a sandbox.

    STV covered my point pretty well. It's mostly effective because no one uses it and it breaks that "step 2." Step 2 isn't actually critical. It's not that AE is addressing some critical point in the process that all hackers rely on, it's just adding a bit of entropy into the mix. It's not one of those things where "oh well given enough time they'll figure out how" - they're already in RAM when they get to your system lol they don't need the disk.

    I do agree with STV that it's another layer and I think it's actually a fine one. Stopping persistence is pretty nice. I would only ever use an AE combined with a sandbox. Personally I wouldn't really bother with it but if you go through the time to get it working and you layer it with other appropriate approaches I think it's fine.

    P.S. All AE are HIPS by definition.
     
    Last edited: Jun 15, 2012
  16. STV0726

    STV0726 Registered Member

    Joined:
    Jul 29, 2010
    Posts:
    900
    :D I was just waiting for Hungry Man to respond! Yay!

    So basically EMET is a good tool to help plug some potential hole that RAM attacks can make use of, though it's no gurantee. This is why I combine EMET, with policy restriction, AND sandboxing of dangerous internet facing applications, primarily my browser and Skype. You COULD always extend this and sandbox everything that has holes that regularly need patching...a lot of people recommend this. (i.e. Microsoft Office)
     
  17. Scoobs72

    Scoobs72 Registered Member

    Joined:
    Jul 16, 2007
    Posts:
    1,113
    Location:
    Sofa (left side)
    Interesting post Hungry Man. Thanks. Some quick Googling found this:
    http://www.infoworld.com/d/security/java-based-web-attack-installs-hard-detect-malware-in-ram-188960
     
  18. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,146
    Yes, that was one of the more interesting attacks and the only actual case where malware worked for a large part in the virtual address space before downloading the payload.

    Were AEs more common something like that would be typical.
     
  19. Melf

    Melf Registered Member

    Joined:
    Sep 7, 2010
    Posts:
    105
    Pointing out that anti-executables don't protect against RAM attacks is like pointing out that an umbrella doesn't protect against the wind. The solution is not "leave the umbrella at home", because you'll get rained on. The solution is not "stay inside forever", because then you can't live your life. The solution is "make sure you're not made of paper so you won't get blown over".

    (ie Chrome's sandbox, firewall, EMET)
     
  20. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,146
    The difference is that it's not preventing hackers from doing anything critical. All attacks already begin in virtual address space.
     
  21. Cutting_Edgetech

    Cutting_Edgetech Registered Member

    Joined:
    Mar 30, 2006
    Posts:
    5,694
    Location:
    USA
    Appguard protects the RAM. Have you tried AG? Its extremely effective in stopping all types of attacks. I'm not saying it can't be by-passed, but AG addresses the RAM attack that some AE's are acceptable to.
     
  22. STV0726

    STV0726 Registered Member

    Joined:
    Jul 29, 2010
    Posts:
    900
    Microsoft really should seriously start looking into updating Software Restriction Policy and (or at least just) AppLocker to extend restrictions to memory execution; though they may come from the viewpoint of "that's what DEP and EMET is for. Use it."

    And AEs DO very much so prevent hackers from doing something critical - executing their attacks. If they cannot execute, there's an impasse and their methods fail 100%. What I agree with Hungry Man on is there are new, rare but possible attacks that can execute by other means than payload dropping on the disk.

    The good news? RAM attacks are non-surviving and a reboot will kill them. So the concern is the damage they can do instantly rather than a lasting infection's consequences.

    I can see RAM attacks being good for phish/rogue programs that want to quickly get your money, but unsuitable for stuff like Botnets or attacks that need to permanently damage/alter Windows itself.

    EDIT: Uh...nevermind about that. I suppose theoretically a special, targeted piece of malware could get into RAM, use a privilege elevation exploit attack, run a script to turn off your policy restriction, then enjoy lasting control over your computer.

    Also...AppGuard protects from RAM execution? How can you test this? I wonder AppLocker already does.
     
  23. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,146
    Attacks always start in a programs virtual address space. It's only after that that they *choose* to move to the disk for the benefit of persistence and avoiding AVs. The AE is an inconvenience that attacks the common procedure, at no point is it attacking something critical.

    Keeping them in RAM doesn't hinder them all that much at all as persistence is overrated and likely not difficult to achieve regardless. As you say you won't see a botnet without persistence but you could still have every piece of information on your system stolen. But, again, it remains to be seen how simple persistence can be achieved.

    There's no real way to stop attacks from starting in the virtual address space nor is there a way to confine them. Not in a conventional way ie: preventing the exploit to begin with. If programs couldn't allocate new memory... they couldn't function.

    Like I said, fine for an extra layer, nothing to rely on.
     
  24. CloneRanger

    CloneRanger Registered Member

    Joined:
    Jan 4, 2006
    Posts:
    4,978
    Ten years ago, one of the things BOClean was designed to do, was detect Malware in memory :thumb:

    Kevin McAleavey who wrote BOClean, amongst other software, now owns & codes KNOS http://knosproject.com/aboutuscge.html
     
  25. Noob

    Noob Registered Member

    Joined:
    Nov 6, 2009
    Posts:
    6,491
    Yeah, i have ALWAYS wondered why people that uses Anti-Exe software (Faronics AE etc.) don't choose a full blown HIPS instead. :rolleyes:
     
    Last edited: Jun 17, 2012
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.