What Kind of Malware Can Bypass Anti-Exes?

The only way to deal with compromised trusted executables is sandboxing and heuristics.

 

1. With all due respect, because I trust that you are one of the more knowledgeable people here... P.O.C. please.

2. I'm beginning to realize that the stuff AE won't supposedly protect from is something more in the scope of EMET to protect from...specifically DEP and ASLR.

EDIT: Obviously as you can see from my signature, Sandboxie is an integral and resident component to my security setup...but for the sake of arguing for a minimalistic/Windows protecting Windows setup, I'm pretending I do not use it.

 

POC of what? Malware using a hijacked process to do what it wants? I can probably find examples of that in the wild. I've actually considered writing a POC to bypass AE and maybe I will in a few weeks. It'll be a fun learning experience. I think there has to be at least one competent programmer on here, right? They can chime in and say what something can do when it controls the address space of a program. The answer should be "anything that the program can do" but I'm not a competent programmer. edit: Checked with a professional programmer and he agrees.

Remember that all of these are possible on Windows.
1) IPC in general (duh)
2) Starting processes under another UID
3) Creating threads in other processes
4) (reflective) DLL injection

And probably a lot of other things I'm not remembering right now that look a lot like holes.

 

POC of bypassing an AE by means of

1. Hijacking a trusted executable
2. Memory only execution
3. Admin elevation exploit to turn SRP off

Until then it's all speculation based on theory which is really still speculation other than # 1.

This thread has really come down to

Side A: AEs provide far better protection than many other commonly used security methods by design save for a few exceptions such as user error
Side B: AEs currently are good but can trivially be rendered next to worthless when they become popular

Oh...and Side C: aka "The Productist". These are the people that insist you need to buy or install some product to protect your computer because Windows is innately incapable of protecting itself at all.

 

I'm really only interested in theory and speculation. If we limit ourselves to what we can see... discussions aren't worth having.

 

But without proof you cause people like me to shake, shiver, and cry over their once thought ironclad setup and worry endlessly, tossing and turning at night about who may find the pinhole in their AE.

lol

 

I'd rather you be worried and try to secure yourself further than be relaxed and not know what holes my lie in wait.

 

If a criminal's going to go through the extra effort to bypass AE for me, they'd be in for disappointment. Poor college student here.

My fetish and compulsive tendency for extreme levels of PC security is done solely for OCD/hobby purposes...if they're looking to crack a setup for loot they'd be better off with my neighbors and their default name SSID publicly broadcasted WIFI.

I was just joking though. Like I said, I don't disagree with you I'm just undecided on the whole thing. I'm mostly worried about people that want to rely on Windows itself (I consider EMET part of Windows basically) and don't want to use Sandboxie or other related protections.

 

AppGuard includes certain protections for most of these attack vectors excluding the browser session and os exploits. AG tries not to interfere with the browsing session itself but should interfere when the guarded browser begins to interfere with system process's including registry writes. EMET could guard against exploits with specific programs too.

 

I currently use EMET fully on legacy applications and have all system protections turned to max.

I am gradually going to start implementing for other high risk applications that I don't always sandbox...but I currently have avoided using the application-specific mitigations for always-sandboxed stuff due to uncertainty on both sides on whether or not the mitigations may conflict with Sandboxie. (I believe HungryMan and I already had a debate on this topic too! )

 

And the same for me.

I think bypassing an AE would be a really fun project. I'm going to try doing that in a few weeks.

 

Yes you can do 'damage', but the chances of the malware author reliably achieving what they want without persistence is low. Think of banking malware. This has to be active on your system for potentially quite some time until you visit your online banking website. It may have to survive several reboot over several days. Without persistence it fails. Persistence substantially increases the chances of success for the malware.

Yes. EMET, policy containment etc etc.

 

Ah okay, I see what you mean now, Scoobs.

Sorry but quick, minor off-topic but I must ask does your user name have anything to do with Scooby-Doo?

 

I'll be interested to see one that doesn't require me to approve the initial launch in order to work, one that can actually defeat a default-deny policy. POCs and malware that the user has to initially allow are not realistic examples as they require the user to bypass the base policy in order to test it.

I keep seeing this term, "trusted executables". On what basis are these executables "trusted"? Signed by the vendor? Vendor compiled whitelist? User chosen? File hash or checksum? Kareldjag makes an important point in the link to an earlier thread that he posted. "Since cmd.exe for instance is on the white list, this is a high level of risk, since we know some "exotic commands". This isn't an AE or HIPS shortcoming. This is a policy flaw. If malware or an attacker can gain access to a command prompt, it's game over. Access to a command prompt/interpreter should not be whitelisted. On my PCs, cmd.exe (and command.com on my 9X units) are "administrator access only" executables. These and several other executables on Windows do not belong on any user mode whitelist.

Regarding "compromised trusted executables", compromised by what and how? AEs and HIPS that use hashes or checksums will detect if the executable is physically altered and will regard it as unknown or new. How will this executable be compromised "in memory"? By what trusted executable? Unless the underlying policy has a weakness, I don't see a starting point for this, unless it comes back to using executables that shouldn't be whitelisted to start with, like cmd.exe

 

Well... legally I think I have to get you to at least click a button on a website/ give fair warning lol but obviously the rest will be automated. I'll just grab some exploits from metasploit for some old firefox vuln and then write the payload myself.

 

Looking forward to testing that Don't forget to post it

For more than one one person

People can spend the rest of their lives speculating & theorising, it's ONLY actions & facts/proof that Really count. That comes with Actually testing, like some of us Actually do on here, & have done for years, unlike those that just talk/write procrastinate etc

WTF ! So you wanna live in La La land ? Fine, the rest of us will continue to live in the Real world !

Yes indeed ! For eg, i have cmd.exe & run32.dll Auto blocked with ProcessGuard If i need them i have to maunually allow them, & then Only per instance.

 

If you base your security on what you think a hacker will do instead of what you think a hacker can do... it's not going to be very strong security.

I'll post it, of course. I won't start on it until at least July 1st though.

 

Interesting thread.

I would be interested in this myself.

 

same lol hope I can actually do it. I'll post whatever result I come up with.

 

First of all, LOL. I'll PM you a link that's really all you need to get started.

The payload is easy enough to generate, there are probably some pre-packaged in metasploit. Delivering it can be trickier. The exploits I have seen demonstrated required social engineering to run. Maybe if you have a malicious website set up you could get the browser to run something automatically simply by landing on the website. There are mouse-over exploits too (they run code simply by mousing over them), but I don't know how to create those.

 

Thanks Brandi =p I'll get started looking in a week. Perhaps I won't have to program anything myself, wouldn't that be nice. edit: well, a week is the soonest I can.

I'll just get someone to host it for me for a bit. If I were really hacking Wilders users social engineering wouldn't be an issue lol who doesn't trust Hungry Man?

 

Okies, turning off UAC, Comodo, and SandboxIE. I consult MBAM oracle and Beefy Miracle for advice.

Anyhow...PoC versus AE. Collision??

 

Sounds fair enough. Do I need to bypass Proxomitron so your code isn't filtered out? I don't use FireFox so whatever you pick would need to work against Seamonkey as well. BTW, if it uses any version of IE, it won't work here. Feel free to target either OS I use (XP-pro or 98SE). If you can't post the link, PM it to me.

Quite true, which is why I don't allow cmd.exe to execute in user mode. My core security policy assumes that all attack surface apps are exploitable and will be targeted. As much as possible, I isolate these apps from each other and from the rest of the system by restricting parent-child permissions, low level access, interprocess messaging, command line parameters, etc. It's been a while since I regularly tested my physical system with real malware. A lot of it was part of the beta testing of SSM. Almost without exception, I not only had to allow the initial launch of the malware, I had to allow a 2nd action for the malware or exploit to function.

One particular activity I saw on a few occasions could lead to the compromising of what is being called "trusted executables" here. The particular malware samples I have targeted explorer.exe in that manner. Once the original code is allowed, explorer.exe tries to launch another instance of itself, then terminates the original. The 2nd instance has code injected into it in memory. On most PCs, this behavior is allowed. Among users who employ default-deny and who have applied it to parent-child permissions often overlook the executables permissions in relation to another instance of itself.

 

I'll probably be picking Firefox and some old exploit that I can use reliably. I'm not interested in proving that I can hack you or anyone else, the goal is to show that I can control a process if I've exploited it ie: I'll drop a file and a registry key.

It's not about bypassing proximotron or anything else, just AEs.

You can run a VM or something without your security software and only with the AE if you'd like to see it work *if* it even works. I'm not looking into it for at least a week.

But if I can't convince people by telling them that a process can be controlled by an attacker I guess showing makes the most sense. I've been meaning to do something fun anyways.

 

I'm glad to see my post reignited your debate lol.