DefenseWall, SBIE and SSM bypassed by Trojan

[Rasheed187]

Seems like another trojan is able to at least partially bypass these tools, this is really disappointing, you would think that the developers would know about most if not all possible attack vectors. ::)

http://sandboxie.com/phpbb/viewtopic.php?t=1655

[LoneWolf]

That link does not appear to work

[Blackcat]

-{ Quote: "That link does not appear to work" }-
It's okay here ;)

[Meriadoc]

-{ Quote: "this is really disappointing, you would think that the developers would know about most if not all possible attack vectors. " }-
Hee, wouldn't that be nice! It will soon be fixed. By the way Sandboxie wasn't bypassed?

[LoneWolf]

Is that link for sandboxie forum?
404 error message when using that link.
going to SandBoxie website and tring to go to forum that way I get this message.

[walking paradox]

I get the following:

[img=http://img117.imageshack.us/img117/3845/pagenotfoundrs1.th.jpg] (http://img117.imageshack.us/my.php?image=pagenotfoundrs1.jpg)

First time trying to insert an image, so not really sure if I did it right. I hosted it via image shack and posted the link in case the attachment didn't work.

[zopzop]

hello rasheed, nice find with this trojan. i was able to access the thread on the sandboxie forum. it seems that this trojan is very buggy, some testers can't get it to "work". i want to test it vs geswall (i'll try doing it in shadow mode with powershadow first, just incase geswall can't stop it). i'll report back here.

EDIT :

kks i just finished testing it using geswall 2.5.1 (on my friends pc, he seems to like this version and refuses to upgrade so this is the version i tested) while under shadow mode in powershadow (2.6 english version).

results :

the trojan runs, makes a copy of itself in programs/config32 (no big deal since geswall doesn't stop isolated programs from creating files), then attempts to hijack explorer and write to the registry. geswall 2.5.1 stops this cold. the only thing it managed to do was copy itself to that directory (config32) and that's not unusual while isolated under geswall. i consider this a "pass" for geswall. i emailed gentlesecurity tech support so they can run this test on their end and see what happens.

[LoneWolf]

A little more info on that trojan(ironic;D)
Checked out while sandboxed,took linkscanner with me.

[innerpeace]

Thanks for the pics LoneWolf.

So, this trojan has to be started by the user? I guess this is why people keep talking about common sense being needed. ::)

[Ilya Rabinovich]

Yes, this piece of code is using very interesting technique I didn't know. DefenseWall is already hardened against it. Will be published with v2.0 RC2 build.

[Espresso]

DSA blocks it with the warning:

"A potential threat to physical memory direct access has been detected."

Antivir, AVG, ClamAV, and Fortinet flag it as a backdoor trojan.

Oddly, on subsequent attempts to run it, it pops up this dialog:

http://i17.tinypic.com/53ai90o.png

It appears to have some type of software protection.

[lucas1985]

-{ Quote: "Yes, this piece of code is using very interesting technique I didn't know. DefenseWall is already hardened against it. Will be published with v2.0 RC2 build." }-
Ilya,
What's new about this trojan?

[Ilya Rabinovich]

It is using interesting provileges escalation technique.

[lucas1985]

Care to elaborate? :)
Thanks Ilya.

[Rasheed187]

Yes, not everyone could make the trojan work, but it did work on my virtual machine, it manages to escape from the sandbox, and SSM can´t stop it from executing IE as a hidden process.

Btw, a bit OT, but I just saw that Process Viewer (the "Process Monitor" part) is able to install a driver without SSM giving any alert about it, is this normal? ::)

http://www.teamcti.com/pview/prcview.htm

[Ilya Rabinovich]

DefenseWall v2.0 RC2 (last one before release) is out. 100% defense against prueba-based injection technique.

[aigle]

-{ Quote: "hello rasheed, nice find with this trojan. i was able to access the thread on the sandboxie forum. it seems that this trojan is very buggy, some testers can't get it to "work". i want to test it vs geswall (i'll try doing it in shadow mode with powershadow first, just incase geswall can't stop it). i'll report back here.

EDIT :

kks i just finished testing it using geswall 2.5.1 (on my friends pc, he seems to like this version and refuses to upgrade so this is the version i tested) while under shadow mode in powershadow (2.6 english version).

results :

the trojan runs, makes a copy of itself in programs/config32 (no big deal since geswall doesn't stop isolated programs from creating files), then attempts to hijack explorer and write to the registry. geswall 2.5.1 stops this cold. the only thing it managed to do was copy itself to that directory (config32) and that's not unusual while isolated under geswall. i consider this a "pass" for geswall. i emailed gentlesecurity tech support so they can run this test on their end and see what happens." }-Nice work zopzop. Pls let us know their reply.

Thanks

[zopzop]

-{ Quote: "Nice work zopzop. Pls let us know their reply.

Thanks" }-

they tested the latest version of geswall and it stopped it (you can even select the "terminate" option and smack down the trojan without breaking a sweat).

[aigle]

Well my results are as follows( with GW 2.6) :

When I run it GeSWalled, it created its copy in config32 folder in Program files. It also started an instance of explorer.exe and default browser that were isolated by GW. However PC became too slugish( almost near to stuck) as these isolated instances of explorer.exe and opera.exe( my default browser) were using most of CPU( have seen this issue when some malware processes are sandboxed by GW) so I killed them manually.

Also GW gave attack notification about isolated instance of explorer.exe acting in a malicious way.

However I am not sure what this trojan is actually supposed to do and how well GW prevents against it in reality. I will interested to know any details.

SSM Pro and EQSecure don,t give any popup about launch of an instance of explorer.exe and default browser by the malware, very strange( these instances are invisible, no GUI, u can just see them in Process Explorer).

[aigle]

It seems a very interesting piece of malware, once allowed to execute, it is bypassing SSM Pro and EQSecure totally. Not sure about PS and GeSWall.

[aigle]

GeSWall log.

[herbalist]

An interesting little demo trojan. Here's how it behaved on my box.
I launched the original from my download folder, a fairly normal practice.
191214
On my box, SSM free alerts to the initial launching of the demo, but does not detect its injection into explorer.exe. Best I can tell, the process runs within explorer.exe entirely in memory. In this regard, the demo does defeat SSM free. I can't test the pro version.

If I allow the initial launch, the demo creates the following:
1, file - C:\windows\oreans.vxd
2, folder - C:\program files\config32
3, file - C:\program files\config32\prueba.exe (a copy of itself)
My file system monitoring apps warned of this immediately.
Once the demo attempts to connect out, it also creates
C:\program files\config32\klog.dat

SSM did alert to the attempt to launch Sea Monkey, my default browser. Most users will not see an alert for the attempt to launch their default browser as it's normally an allowed child process of explorer.exe. On mine, browsers are launched via batch files, partly as a security measure against exploits and partly to start other processes simultaneously.
191215
If I allow the launch of Sea Monkey, I then get an alert for a hook by Sea Monkey.
191216
By now, Kerio 2.1.5 is alerting to Sea Monkey's outbound connection attempt. The trojan demo ignored the proxy settings and tried to connect out directly. On my box, the browser has to connect out thru Proxomitron, which is launched by the same batch file as Sea Monkey. The trojan demo has some flaw that prevents it from connecting even when I allowed it. Not sure if it's the trojan or the sites it's trying to connect to. Seen 2 different IPs so far but this isn't particularly relevant to the test.

If I kill the instance of Sea Monkey launched by the demo, SSM alerts to the attempt to launch the copy of prueba.exe in the config32 folder.
191217
I get the same alert if I kill explorer.exe with SSM, then restart it. When explorer is killed and restarted via SSM, the above alert is followed by this one.
191218
If I block the launching of prueba.exe after killing either Sea Monkey or Explorer.exe, the demo is killed.

While SSM doesn't detect this demo's method of using explorer.exe, a properly designed layered package still defeats it. The fact that the user allows this demo to run has to figure into this test. The HIPS did their initial job, intercepting an unknown process. By your choosing to allow it, you changed the role of the HIPS from blocking malicious processes to one of damage control. From this point forward, your ruleset, system configuration, and the rest of your security package come into play.

This demo shows the weakness in rulesets that allow explorer.exe to parent any process, which ends up including the trojans executable and the browser. Take the time to specify the child processes and get rid of that "allow any" setting for all processes. This is an example of how a well designed security package can defend a system by preventing collateral damage, even when an initial exploit succeeds. Any security app can and will be defeated. It's how well your package does as a whole that matters.

In this instance, the demo's author made some basic mistakes, probably because it is a demo. Even with the real thing, if the writer doesn't think the process all the way thru, he can make similar basic mistakes and often does. It's often such mistakes that lead to the discovery of his trojan and his new method.
1, He assumed the browser has a direct connection out. In my case, I connected thru Proxomitron. Caught by the firewall.
2, He assumed that the browser is an allowed child process of explorer.exe. Usually it is, but not always. I use batch files to lauch the browsers, Proxomitron, and other items I won't name here all at once. Break that direct connection between common system executables like explorer and the web applications like your browser and mail handler.

Rick

[Kees1958]

Rick,

Nice avitar, great post

Regards Kees

[lucas1985]

-{ Quote: "
3, file - C:\program files\config32\prueba.exe (a copy of itself)
My file system monitoring apps warned of this immediately." }-
Which app is this?
Thanks.

[Rilla927]

Just out of curiousity, I wonder if it can get passed Deep Freeze?

[aigle]

Why it should bypass DeepFreeze?

[TopperID]

I can't seem to run this little blighter on my system. As soon as I allow it through my execution protection I get a pop-up from ZAP warning me of dangerous behaviour involving IE (which I had open) but before I could finish reading the message or get a screenshot I get rebooted. So I don't know if ZAP is protecting me or the demo is plain buggy!

Sometimes I get prueba.exe in config32, but that's the only change.

[aigle]

-{ Quote: "An interesting little demo trojan. Here's how it behaved on my box.
I launched the original from my download folder, a fairly normal practice.
191214
On my box, SSM free alerts to the initial launching of the demo, but does not detect its injection into explorer.exe. Best I can tell, the process runs within explorer.exe entirely in memory. In this regard, the demo does defeat SSM free. I can't test the pro version.

If I allow the initial launch, the demo creates the following:
1, file - C:\windows\oreans.vxd
2, folder - C:\program files\config32
3, file - C:\program files\config32\prueba.exe (a copy of itself)
My file system monitoring apps warned of this immediately.
Once the demo attempts to connect out, it also creates
C:\program files\config32\klog.dat

SSM did alert to the attempt to launch Sea Monkey, my default browser. Most users will not see an alert for the attempt to launch their default browser as it's normally an allowed child process of explorer.exe. On mine, browsers are launched via batch files, partly as a security measure against exploits and partly to start other processes simultaneously.
191215
If I allow the launch of Sea Monkey, I then get an alert for a hook by Sea Monkey.
191216
By now, Kerio 2.1.5 is alerting to Sea Monkey's outbound connection attempt. The trojan demo ignored the proxy settings and tried to connect out directly. On my box, the browser has to connect out thru Proxomitron, which is launched by the same batch file as Sea Monkey. The trojan demo has some flaw that prevents it from connecting even when I allowed it. Not sure if it's the trojan or the sites it's trying to connect to. Seen 2 different IPs so far but this isn't particularly relevant to the test.

If I kill the instance of Sea Monkey launched by the demo, SSM alerts to the attempt to launch the copy of prueba.exe in the config32 folder.
191217
I get the same alert if I kill explorer.exe with SSM, then restart it. When explorer is killed and restarted via SSM, the above alert is followed by this one.
191218
If I block the launching of prueba.exe after killing either Sea Monkey or Explorer.exe, the demo is killed.

While SSM doesn't detect this demo's method of using explorer.exe, a properly designed layered package still defeats it. The fact that the user allows this demo to run has to figure into this test. The HIPS did their initial job, intercepting an unknown process. By your choosing to allow it, you changed the role of the HIPS from blocking malicious processes to one of damage control. From this point forward, your ruleset, system configuration, and the rest of your security package come into play.

This demo shows the weakness in rulesets that allow explorer.exe to parent any process, which ends up including the trojans executable and the browser. Take the time to specify the child processes and get rid of that "allow any" setting for all processes. This is an example of how a well designed security package can defend a system by preventing collateral damage, even when an initial exploit succeeds. Any security app can and will be defeated. It's how well your package does as a whole that matters.

In this instance, the demo's author made some basic mistakes, probably because it is a demo. Even with the real thing, if the writer doesn't think the process all the way thru, he can make similar basic mistakes and often does. It's often such mistakes that lead to the discovery of his trojan and his new method.
1, He assumed the browser has a direct connection out. In my case, I connected thru Proxomitron. Caught by the firewall.
2, He assumed that the browser is an allowed child process of explorer.exe. Usually it is, but not always. I use batch files to lauch the browsers, Proxomitron, and other items I won't name here all at once. Break that direct connection between common system executables like explorer and the web applications like your browser and mail handler.

Rick" }-Nice analysis.
On XP Home with SSM pro, if u have rules for ur browser to be launched by explorer, u will not get any alerts except intial execution of malware. Even no alert of global hook by the browser. Very clever piece of work by this malware. SSM pro fails here.

Mind it that no one uses such a paranoid set up as u( like launching browser via batch files). Just see above the alert by DSA, that is infact the best response by a HIPS against this malware. Even PS responded better than SSM. EQS and SSM proved poor in this response.

With GW, when malware infects explorer.exe GW isolates this and u will see two explorer.exe instances in task manager, one isolated( infected)and one normal( trusted). If u kill the isolated explorer.exe via GW or task manager( and kill the browser via task manager) the demo will stop.

[aigle]

Can anybody try it against KAV PDMs?

[nicM]

Good description herbalist, but you've missed one point :D

Hint : Try Firehole leaktest (which SSM is passing), after the trojan/backdoor is tested. I'm ready to bet that SSM will then fail.

;)

[herbalist]

NicM,
I don't see what that would accomplish. On my box, the firehole test fails on its own, even when I allow everything. Just for fun, I tried launching it after launching the demo. Explorer locks up, so I can't even try the idea.

lucas1985,
The app that alerted was MoniDir 2000, a polling folder contents checker. It's not real time. Just happened to be checking when I launched the demo. Sorry if I gave the impression I had a real time file/folder checker. Wish I did.
-{ Quote: "Even no alert of global hook by the browser." }-
Is SSM configured to allow your browser (Opera?) to set global hooks? I don't know how Opera compares to Sea Monkey or IE6, but Sea Monkey has never asked to set a hook during normal usage, only when testing something like this demo. IE6 has, but I blocked it with no ill effects. This could also be from differences in the OS being used, XP vs 98. Either way, I'm suprised the free version detected the hook but not the pro version. I'd be interested to hear others results on this point with different browsers, OSs, SSM versions.
Rick

[lucas1985]

-{ Quote: "lucas1985,
The app that alerted was MoniDir 2000, a polling folder contents checker. It's not real time. Just happened to be checking when I launched the demo. Sorry if I gave the impression I had a real time file/folder checker. Wish I did. " }-
Thanks herbalist :)

[nicM]

-{ Quote: "NicM,
I don't see what that would accomplish. On my box, the firehole test fails on its own, even when I allow everything. Just for fun, I tried launching it after launching the demo. Explorer locks up, so I can't even try the idea.

" }-

Hi Rick,

The leaktest failed, nevermind, that was just a hint : What I wanted to point out is that, the most important thing about this trojan is not its ability to open the browser without detection, in itself, but the changes it performs on the system, in order to do so. It's making changes -somewhere ;D - so that the ability of various HIPS to detect this browser launching is affected, indeed.

It is the most important, because, how to say, these HIPS do not work "as good" after the test than they did before ;D : Hence the success of starting the browser without alert.

Thus is is this "change" that needs to be prevented, more than the detection of the browser starting. Otherwise, system is already affected.

Cheers,

nicM

[aigle]

-{ Quote: "
On XP Home with SSM pro, if u have rules for ur browser to be launched by explorer, u will not get any alerts except intial execution of malware. Even no alert of global hook by the browser." }-
-{ Quote: " Is SSM configured to allow your browser (Opera?) to set global hooks? I don't know how Opera compares to Sea Monkey or IE6, but Sea Monkey has never asked to set a hook during normal usage, only when testing something like this demo. IE6 has, but I blocked it with no ill effects. This could also be from differences in the OS being used, XP vs 98. Either way, I'm suprised the free version detected the hook but not the pro version. I'd be interested to hear others results on this point with different browsers, OSs, SSM versions.
Rick" }-
Sorry SSM gives the alert of keyboard hook atleast. Actually my browser was GeSWalled so SSM did not alert, probably the hook was blocked by GW. My other description is correct though( but in my rules set explorere is allowed to launch my browser).

[herbalist]

Except for that and Pro Security's debugging alert, which SSM free doesn't cover, our results are pretty much the same. I won't try to guess how SSM and PS interact in that situation. I'd expect that would even be influenced by the order they're installed, which one intercepts a given item first.

IMO, all bets are off when malicious code is allowed to execute. I'm convinced that there is no end to the number of ways apps and operating system components can be exploited when malicious or test code is allowed to run. If it were possible to plug all the holes in an app or operating system, you'd think XP or IE6 would be fixed by now with so many patches on them. I wholly expect it'll be the same with security apps. If the code is allowed to run, they'll all be defeated eventually, be patched, and the process will repeat. Even if the apps are hardened, how much damage was done while it was defeated? Was your system compromised when the security app was defeated? How would one know when to check or what to look for? IMO, it's too great of a risk to rely on containment or damage control apps like sandboxes, virtual operating systems, etc, because they will eventually be beaten.

I'm waiting for the day someone packs a new exploit, a real one into a firewall test. So many click on a "test" with no hesitation that a new botnet could be made from the PCs of security buffs.

Rick

[LoneWolf]

-{ Quote: "I'm waiting for the day someone packs a new exploit, a real one into a firewall test" }-

I have thought of that many times. Not just a firewall test but any test for that matter.Even scanning the test file with something like virus total is no guarantee that it is safe.One must be sure that it is from a trusted source.
But even at that how can one be sure that site was not hacked and compromised?

Looking thru BOCleans covered trojans list,it seems BOClean covers this one as well.(Prueba)

[aigle]

-{ Quote: "Except for that and Pro Security's debugging alert, which SSM free doesn't cover, our results are pretty much the same." }-
I have no idea of this debuging alert but I guess this is the main interception against this malware( I may be wrong though). KAV PDMs give same alert as well on behavioral analysis.

[xuesisi]

It's fail in my PC

I used TINY I am not afraid

[aigle]

-{ Quote: "It's fail in my PC

I used TINY I am not afraid" }-That,s great. I am really impressed.
Can u explain how it blocks it? Any screenshots pls?

Thanks

[xuesisi]

-{ Quote: "That,s great. I am really impressed.
Can u explain how it blocks it? Any screenshots pls?

Thanks" }-


This , the first time

This test , after i added it to the trusted group .if not, the " prueba " can't do anything

[aigle]

Thanks, I know Tiny is discontinued. Is there a site to get a trial of this firewall( Pro Version). I will like to play with it.

Thanks

[aigle]

-{ Quote: "This , the first time

This test , after i added it to the trusted group .if not, the " prueba " can't do anything" }-
By the way, u this thread. "Explorer exe wants to start the trojan", if u deny this and think PASS, then all HIPS pass this test, SSM , NG, PS etc etc. None of them fails.

We are talking about allowing prueba.exe to run and then see if ur HIPS stops its malicious actions or not? This is a test of behavioral blocker functionality of HIPS( not the anti-execution functionality), otherwise any simple anti-execution software will make this trojan dead.

[LoneWolf]

-{ Quote: "Thanks, I know Tiny is discontinued. Is there a site to get a trial of this firewall( Pro Version). I will like to play with it.

Thanks" }-


Maybe here.
http://www.321download.com/LastFreeware/page3.html#Tiny%20Personal%20Firewall

EDIT: Just took a second look. NOT for XP or Vista.

[Kees1958]

-{ Quote: "
1. IMO, all bets are off when malicious code is allowed to execute. I'm convinced that there is no end to the number of ways apps and operating system components can be exploited when malicious or test code is allowed to run.

2. If the code is allowed to run, they'll all be defeated eventually. I'm waiting for the day someone packs a new exploit, a real one into a firewall test. So many click on a "test" with no hesitation that a new botnet could be made from the PCs of security buffs.

3. IMO, it's too great of a risk to rely on containment or damage control apps like sandboxes, virtual operating systems, etc, because they will eventually be beaten.

Rick" }-

Rick,

First I want to say that I really appreciate your contributions in this forum. Second I have some time to kill, so I will argue with you (just for fun).

Ad 1.
Rick, that is true point taken. Still an Anti Executable also has to find out all possible entries of executable code. Due to rise of the 'networked' community all sorts of remote or distributed code is shared across platforms and networks. On top of this embedded dynamic code (eg the Jpeg exploit, all sort sof scripts, executable meta data, XML, etc). This is not bad is the ideal of the network being the computer with only lean clients and applications or sniplets of code made available when the user requires it. To conclude the principle is true, this does not mean that an Anti Executable has an easy and straight forward job to do. If an Anti Executable was able to close all entries on a given platform, SSM for instance would not fail one single tests.

Ad 2.
Now you yourself are providing me the Achilles weak spot of Anti Executables. Over a period of time any user is confronted with a few changes to his executable base (being updates, additional programs). When you choose allow, you on your own, while containment measures like behavior analysis or rights/policy managers still provide backing. In an earlier post I challenged AE-fan's what kind of measurements they took before allowing a new ap (that is setting the gates of your defense wide open). Your answer was the only one which made sense and showed a contained risk prevention way of handling this.

Ad 3.
This is true when people with AE's would not change there system after the clean installation. In terms of risk management you better of with lower average protection all time through than higher protection combined with periods (say yes to a leaktest for instance) of lowering your AE-shield.

I live in the Netherlands with a statiscal higher chance of a nuture disaster than some one living in the center of France, say my nature disaster chance is 0,005% and for the French guy it is 0,001%. When our conditions are stable (no variances in riks), the French Guy is better off. Only the French guy happens to work for Air Liquide. Part of his job is to check and maintain for a period of two weeks a year the production of highly compressed gasses. During this period his risk on a disaster is 0,01%. Which of us has the highest risk profile is it me with 0,005%, because on average the French guy's risk is lower 0,0013% ( (0,001 x 50 + 0,01 x 2)/ 52 weeks )? I am sorry to say that this is a miscalculation, the French guy has more risk of getting an incident because of nature/external reasons than me.
This is not just a theoretical example this is a real world fact based on a lengthy law suit/court with a multiple of experts opinions coming to the same conclusion. In the US 30 workers were killed on the premises of a production plant an oil company (I thought it was BP), because they were located to close to a dangerous high risk part of the plant for two weeks a year, the oil company had violated the safety regulations.
This two weak high risk period are the moments of weakness of an Anti Executable, you some times have to allow new code.
To conclude : Yes a containment strategy does provide a lower security than a prevent start/anti executable white list strategy. But on the moments you are CONSIDERING to change or increase your whitelist, you are left naked, hanging out to dry in the wind.

One closing remark.
Because sandboxes base their rights/authorization allocation upon the likelyhood of possible external code (only focus on the threat gates), by nature/design this type of containment is maybe simpler in the design than an Anti Executable. GesWall Pro 2.71 (next release) also provides a track list of the behavior of untrusted applications. DefenseWall has had for long a file and registry track option (with roll back option). Although this is only meant for th epower user, it provides me with a lot of info. So I bet that our PC's with out of the box configuration (A2 paid + DefenseWall paid, CyberHawk paid + GeSWall paid) have an overall higher protection/lower infection chance than the majority of Anti Executable users (who have painfully tried to configure/figure out a protection rule set).

[TopperID]

-{ Quote: "By the way, u this thread. "Explorer exe wants to start the trojan", if u deny this and think PASS, then all HIPS pass this test, SSM , NG, PS etc etc. None of them fails.

We are talking about allowing prueba.exe to run and then see if ur HIPS stops its malicious actions or not? This is a test of behavioral blocker functionality of HIPS( not the anti-execution functionality), otherwise any simple anti-execution software will make this trojan dead." }-
I get the same type of warnings from ZAP. First I get an OS FW alert of dangerous behaviour involving IE, then, if I allow that, I get component control warning of Explorer trying to connect; if I deny either of these the trojan is stopped. So I think the Explorer thing is to do with .dll loading rather than execution control (which ZAP doesn't do) - but I don't know anything about Tiny so maybe I'm missing something. (Does Tiny do execution protection?)

[wat0114]

I get all these four alerts from SSM and Outpost fw Pro: It should be clear that a layered approach supported by a little common sense can stop this. It is of no surprise to me that at least herbalist has got it right. It astounds me to see so much concern expressed over this when clearly there is no need for it.

[xuesisi]

-{ Quote: "By the way, u this thread. "Explorer exe wants to start the trojan", if u deny this and think PASS, then all HIPS pass this test, SSM , NG, PS etc etc. None of them fails.

We are talking about allowing prueba.exe to run and then see if ur HIPS stops its malicious actions or not? This is a test of behavioral blocker functionality of HIPS( not the anti-execution functionality), otherwise any simple anti-execution software will make this trojan dead." }-

It's my rules,auto stop it .
I don‘t want to change the rules .
so this test “prueba.exe”this thread , auto ended .
By the way I use BBlean ,and I renamed "Explorer.exe".
“prueba.exe”can't find it.
I re. back "Explorer.exe" for this test.

Second test
Omitted some pictures (maximum of 5 files one day )

191337
191335
191332
191333
191336

[herbalist]

-{ Quote: "Still an Anti Executable also has to find out all possible entries of executable code." }-
I'm not sure what you're specifically referring to with "possible entries". If this referrs to types of files or media which can contain executable code, it's all suspect anymore. If you mean the apps and/or the possible commands these apps could be made to execute, that's theoretically almost unlimited. Given that this is limited to the apps and components installed on a given PC, I'll assume you're referring to the files and media types. If this doesn't address what you were referring to, let me know.

I'm assuming that "networked community" is referring to a LAN, such as is used in a business or multiple PC household. I'm also assuming that the user has control over their own PC. In some situations, being part of a LAN could limit your ability to filter out potentially malicious content, such as material from another workstation or department over which you have no control, material you have to open.

IMO, there is no type of media or file that can be treated as safe. Even a simple text file can be malicious when combined with a couple of normal user commands like "Rename". How many apps would consider the renaming of a text file as malicious? What about when the rename changes the file extension fron txt to reg, bat, or hta? I've seen several AVs intercept batch files I use, identifying them as suspect or malicious whenever Deltree and windows appear in the same line. Basically, the user should treat any file or code not their own as suspect and every application that could be used to open that file as an entry point.

For all purposes, you're potentially opening malicious content every time you go online. What guarantee do you have that someone didn't find a brand new exploit in the software used by this forum (or your homepage) and made use of it 5 minutes ago to deliver a trojan to anyone who visits it? How do you know that a thread link supposedly leading to a screenshot doesn't connect to an HTA designed to send you to a drive-by site? Likely, no, but there's no guarantees. You can only filter out so much with firewalls and filtering apps, especially when your PC is used as part of your work and has to accept files from other PCs at work. The LAN or at work scenario only changes the number of apps that can be used as potential entry points, not the basic security policy.

I regard every app that opens files of any type as a potential target, working on the assumption that I can't intercept all potentially malicious content. By limiting the parent-child settings of each app to only what it absolutely needs, AEs like SSM do perform a type of sandboxing. It would be very difficult to completely prevent your browser from caching a given file, say a malicious dll or exe, but I can prevent the browser from launching that exe, registering that dll, or running that dll using rundll32.exe. I might not be able to stop a bit of embedded code from executing in an already running application but I can intercept its attempts to access other system critical functions, changing system settings in the registry, or gaining a command shell.

-{ Quote: "Now you yourself are providing me the Achilles weak spot of Anti Executables. Over a period of time any user is confronted with a few changes to his executable base (being updates, additional programs). When you choose allow, you on your own, while containment measures like behavior analysis or rights/policy managers still provide backing." }-
-{ Quote: "To conclude : Yes a containment strategy does provide a lower security than a prevent start/anti executable white list strategy. But on the moments you are CONSIDERING to change or increase your whitelist, you are left naked, hanging out to dry in the wind." }-
Adding or updating the executable base is a more vulnerable point in time for users who depend on an AE but that doesn't hang you out to dry, unless you're one who shuts down everything at the time. I leave everything turned on and deal with the alerts. In addition to recording all the system changes, I'm alerted to every new process during the install, every new dll that gets registered, every new autostart entry, etc as it happens. Yes, it's a pain, especially if you're installing something like OpenOffice.org or GIMP, feels like a lifetime supply of alerts. If I see autostart entries I don't want during the install process, I will block them. If that screws up the install, I can always restore and do it again. Even if I allow all the registry changes, they aren't permanent until I save the new registry with the batch files (http://www.freewebs.com/herbalists/index.htm) I wrote for that purpose.

When configured well, an AE will not hang you out to dry unless you shut it off. How well it does is up to the user, the rules they write, and what other defenses they use. Besides, it isn't just AE's that have this problem. How many functional defenses do you have if the app being updated is your sandbox or containment app? What happens if the updated sandbox conflicts with something else you use? If you didn't back up your system before updating, you could have big problems.

Rick

[Rasheed187]

@ wat0114

After I execute this trojan, SSM Pro is not able to stop it from executing IE, at least not on my system. And it also manages to escape from the sandbox in DefenseWall and Sandboxie, that´s the problem. Cool to know that ProSecurity, Outpost and Tiny performed better. Btw, this trojan is called Bifrose if I´m correct.

http://www.f-secure.com/v-descs/bifrose_uz.shtml

[wat0114]

-{ Quote: "@ wat0114

After I execute this trojan, SSM Pro is not able to stop it from executing IE, at least not on my system. And it also manages to escape from the sandbox in DefenseWall and Sandboxie, that´s the problem. " }-

Hi Rasheed,

I don't doubt that and the way this trojan works is probably in a very diabolical manner, but one still has to allow explorer.exe to launch it in the first place, after prompted by SSM. Outpost, at least in my case, just adds another layer of defense in case I mistakenly allow the former sequence to occur.

It seems to come down to the defense package one deploys on their machine, as well as how attentive and knowledgeable one is to these alerts. I would even venture to say surfing habits play a significant role in how likely it is to stumble upon one of these ;) Until I come across an exploit that does not trigger any kind of alert from at least one of my defense layers, I'm not really worried about it. If I blow it by allowing something malicious to run even after one or more alerts, that is my tough luck and, heaven forbid, my own stupidity :)

It would simply mean restoring one of my Acronis backups.

However, I do enjoy testing these exploits. It satisfies my curiosity and provides a bit of a learning experience as well.

[TNT]

I ran prueba.exe sandboxed (v 2.85) and it was supposed to evade the sandbox and create C:\Program Files\config32\prueba.exe

It sure didn't. Nothing was to be found there. ???