Is this really a bypass for CFP, OA, GesWall ??

[aigle]

This is how you can reproduce this possible bypass. You must ahve more than one disk or partitions on ur PC.

Download and extract/ install XYplorer portable from here.

http://www.portablefreeware.com/index.php?q=xyplorer&m=Search

Put Defence Plus in Paranoid mode with Proactive Security configuration.

Open Defence Plus Pre-defined Security Policies and make a test policy. Allow only file access and Deny all other actions in this policy( see pic 1).

Now execute the malware b.css exe via cmd.exe and allow first execution pop up, allwoing execution of b.css by cmd.exe( see pic 2).

On second pop up alert choose test policy made by us( Pic 3) for b.css. Now Defence Plus will deny ecery single action by b.css without a pop up except file acess that will produce pop up alerts. Allow all file access( create/ modify/ delete) pop up alerts. Malware will create an autorun.inf file and a TPR.pif file in root directory of each hard disk partition. They will be hidden though, not visible via explorer.exe. Let the malware run and Open xyplorer by executig XYplorerfree.exe.

Navigate to one of your non-OS partitions( D, E, etc), locate TPR.pif file and double click on it to execute it via XYplorer( Pic 4).

Now here ius the point. One would expect here a pop up about TPR.pif being executed by XYplorer.exe. But interestingly instead you will first get two weired alerts about XYplorer.exe:

1- XYplorer.exe trying to access DNS/ RPC client service( Pic 5)
2- XYplorer.exe trying to access internet( Pic 6)

It,s after these two alerts that you get an alert about TPR.pif being executed by XYplorer.exe( Pic 7).

Now my question is how this malware manipulated XYplorer to access internet without any pop up alerts by Defence Plus about XYplorer manipulation or any windows message to xyplorer by the malware. Malware was never allowed to do anything excpet file creation etc. due to the test policy imposed on it?

Hope I have made my point clear. I need your opinions. Thanks

211779211780
211781211782
211783

[aigle]

Pic no. 6 and 7 are here.

[aigle]

OA same problem. No alerts.

[aigle]

GesWall bypassed as well.

211787
211790
211789

[Page42]

-{ Quote: "GesWall bypassed as well." }-
Hi aigle,

I'm probably in way over my head here, but I'd like to question your assertion that GeSWall was bypassed... your own screen captures show bcss.exe being isolated by GeSWall. And isn't it correct that even if a user has Process Termination set to Interactive Ignore, the process is under control and does not do harm to the OS?

Didn't you write essentially that same thing on the GW forum about a month ago...
-{ Quote: "BTW while I analyze malware I don,t terminate but I will let it run and analyze. It can,t harm my sytstem after all due to geswall. I will do same in real world scenario." }-
I emailed Brian Walche about eight months ago, regarding an unpatched bug in Internet Explorer... I asked Brian if GeSWall Pro would protect me from that exploit, the same way it protected me from the DNS vulnerability that Microsoft had to patch back in July (of last year)? Brian wrote back,

-{ Quote: "GeSWall doesn't stop the vulnerability but keeps it harmless." }-
Isn't that the same case with this bcss.exe malware? If not, what changed?

[aigle]

Hi, b.css is an untrusted process. It,s somehow able to manipulate a TRUSTED process XYplorerfree.exe to go outbound for a malware site. GesWall must not had allowed it.

[aigle]

Same with CFP. Question is how the malware is able to manipulate XYplorerfree.exe and xyplorer in turn starts trying to connect to a malwre site.

- through system take over( manipulation) ? probably NOT as our test policy imposed upon malware will block this( debug privileges blocked)

- the manipulation of xyplorer in memory ? NO as our test policy blockes this.

- through a global hook ? NO as our test policy blocks this.

- through a windows messag ? NO as our test policy blocks this.

This is a mystery atleast for me. Why a trusted process XYplorerfree.exe suddenly starts trying to access the internet?

[aigle]

Hi, tested MD. Same results. Could not find anything manipulating XYplorer but it tried for outbound.

[Ickk]

-{ Quote: "Navigate to one of your non-OS partitions( D, E, etc), locate TPR.pif file and double click on it to execute it via XYplorer( Pic 4)." }-

I may be wrong here but if you ran this file manually as a user will that overule the rule you set with your security app ?

[aigle]

-{ Quote: "I may be wrong here but if you ran this file manually as a user will that overule the rule you set with your security app ?" }-
I just double click it via XYplorer and never allowed it to execute when CFP gave an execution pop up. Infact the XYPlorer outbound acess pop up alert( denied by me) comes before TPR.pif execution alert.

[Ickk]

I still cant see the problem , i assume this PTR.pif is a packed exec , which is in the untrusted zone set by your security app.
Then you have run it with a Trusted app (XYPlorer) , in this case your security apps still disallowed it to run and asked you if you wanted to allow it.

[aigle]

you need to read and understand the thread again.

[Pliskin]

Maybe it's a new vulnerability.

Why there are no more opinions about this malware? MD is bypassed too.

[aigle]

I gave up on this. It,s a mystery that I can,t solve.

[_kronos_]

it's too strange that all these softwares fail this attack...
a friend tried b.css with RTD e SSM, they failed (BTW they're discontinued::) )

imo there's something we are not taking present...but what??

[1boss1]

-{ Quote: "Same with CFP. Question is how the malware is able to manipulate XYplorerfree.exe and xyplorer in turn starts trying to connect to a malwre site.
" }-

I don't think the malware is manipulating XYplorer, but rather XYplorer is simply reading the file and deciding how to handle it itself.

I have not used XYplorer, but have used a similar third party Explorer replacement called Opus. They usually use plugin or file handlers to read files, and decide how to pass them to Explorer or display them. For example in Opus if i single click an .exe it's shows as Hex in the preview panel.

To me it appears the trusted XYplorer is reading the untrusted file contents, and acting on it like it's supposed to. So the .pif isn't executing.

Does it happen with other file types?

Information about .pif

-{ Quote: "Basically, it's an information file that when you click on it, the information in the file is used by Windows to run some program; including code that can be in the PIF file. It is a potentially dangerous file type and one should never click on one received via E-mail without extensive knowledge of exactly what it will do first. Note: This file type can become infected and should be carefully scanned if someone sends you a file with this extension." }-

[trismegistos]

This is just an intelligent guess or speculation in my part born from my small experience in testing wmf exploits in a vulnerable system.

The file could have used buffer overflows or arbitrary code execution to bypass detections from HIPS just like the wmf exploits but the payload in this case is to use a trusted process to access the internet, which is fortunately intercepted by any HIPS or firewall.

Even hardware DEP or even comodo memory firewall (or equivalent component) couldn't detect every arbitrary remote code executions or buffer overflows. And such actual shellcodes are also undetected by any HIPS but the payloads are surely be intercepted by it.

Now like the wmf exploits taking advantage of wmf vulnerability particularly on the offending vulnerable gdi32.dll, we should now take note if there is an existing vulnerability concerning pif file. Perhaps gdi32plus.dll (he he)? Or is this a zero day exploit taking advantage of a vulnerability?

Edit:
A simple search in the net give me this pif vulnerability on which a worm took advantage of... http://isc.sans.org/diary.html?storyid=1730

[Kyle1420]

@Tris, You got me thinking
- I looked up to the top of Aigles posts and I saw that in Comodo there was rules to deny interprocess memory access.
I could be wrong, But I don't think it's a result of BO.

[trismegistos]

-{ Quote: "@Tris, You got me thinking
- I looked up to the top of Aigles posts and I saw that in Comodo there was rules to deny interprocess memory access.
I could be wrong, But I don't think it's a result of BO." }-
Yes it could not be buffer overflow as the wmf exploit is not BO but something similar like remote code execution. I have tested the wmf exploits and out of the 15 or so samples of tif, wmf, jpeg or other image files containing the embedded codes, only 2 instances where Hardware DEP as well as the Comodo Memory firewall had prevented those exploits. But the good thing is, all the payloads where intercepted by the Host Intrusion Prevention System. So, this pif exploit and vulnerability is something similar.

Hardware DEP as well as any buffer overflow protections have high failure rates on these types of exploits like wmf and this pif.

Edit: what a clever piece of malware is this? masquerading as a cascading style sheet which would create a usb autorun file with pif file, which would use a trusted process to phone home or to download more malware.

I'll end with a quote from a poster who's concerened with the weak buffer overflow protections rendered by comodo memory firewall...
-{ Quote: "
This thread is very important, there is a serious mistake in Memory Firewall!

Memory Firewall is only detecting calls to ShellExecute, WinExec and so on, but it's not detecting calls to the standard C system() call. This is a serious security flaw since system() can do everything that ShellExecute can do. I want some developers in this thread.

Im not using Memory Firewall since i found out that it's useless, also, DEP and ASLR is a better way to protect your system since it does not need the "black list" of calls becaue everything is stopped.

Memory Firewall code is now part of CIS D+.
Can Comodo developers (e.g. Tyler Durden) confirm or disprove this kind of BO attack is a real life threat which bypasses BO protection of D+ ?
" }-

[aigle]

-{ Quote: "I don't think the malware is manipulating XYplorer, but rather XYplorer is simply reading the file and deciding how to handle it itself.

I have not used XYplorer, but have used a similar third party Explorer replacement called Opus. They usually use plugin or file handlers to read files, and decide how to pass them to Explorer or display them. For example in Opus if i single click an .exe it's shows as Hex in the preview panel.

To me it appears the trusted XYplorer is reading the untrusted file contents, and acting on it like it's supposed to. So the .pif isn't executing.

Does it happen with other file types?

Information about .pif" }-
Good idea indeed.

[Rmus]

-{ Quote: "Yes it could not be buffer overflow as the wmf exploit is not BO but something similar like remote code execution. " }-I thought the wmf exploits were buffer overflow. Here is the 2005/06 exploit:

(MS06-001) Microsoft Windows Metafile (WMF) Code Execution
Discovery Date - 12/27/2005
http://vil.nai.com/vil/content/v_137760.htm
http://vil.nai.com/vil/content/v_vul3222.htm

-{ Quote: "Type
Buffer Overflow
Impact of exploitation
Remote Code Execution
McAfee Host IPS’ generic buffer overflow protection blocks code execution that would result from the buffer overflow. " }-Microsoft Windows XP/2003 Picture and Fax Viewer
14.07.2006
http://securityvulns.com/Fnews578.html
-{ Quote: "Buffer overflow on parsing WMF metafiles. It may be used for silent Spyware/Trojan installation with Internet Explorer or another browser and also with Lotus Notes. There are vulnerabilities not covered by MS06-001." }-There have been quite a few WMF/EMF vulnerabilities using buffer overflow, as far back as 2004. They were patched. and didn't get the exposure that the one in 2005 did.

Microsoft Security Bulletin MS04-011
April 13, 2004
http://www.microsoft.com/technet/security/bulletin/ms04-011.mspx

-{ Quote: "A buffer overrun vulnerability exists in the rendering of Windows Metafile (WMF) and Enhanced Metafile (EMF) image formats that could allow remote code execution on an affected system. Any program that renders WMF or EMF images on the affected systems could be vulnerable to this attack. An attacker who successfully exploited this vulnerability could take complete control of an affected system." }-WMF Multiple DoS Buffer Overflow Vulnerabilities
http://www.opennet.ru/base/ms/1139852289_2153.txt.html
12 Feb 2006
-{ Quote: "Two buffer overflows with Microsoft Windows GRE (Graphics Rendering
Engine) have been discovered. Attackers can cause a DoS and crash
explorer.exe." }-OpenOffice WMF/EMF Processing Buffer Overflow Vulnerabilities
2007-01-08
http://secunia.com/advisories/23612/
-{ Quote: "A truncation error within the handling of the META_ESCAPE record can be exploited to cause a heap-based buffer overflow via a specially crafted WMF/EMF file." }-Microsoft GDI Buffer Overflow in Processing EMF and WMF Files Lets Remote Users Execute Arbitrary Code
Apr 8 2008
http://securitytracker.com/alerts/2008/Apr/1019798.html
-{ Quote: "A remote user can create a specially crafted EMF or WMF image file that, when loaded by the target user, will trigger a buffer overflow and execute arbitrary code on the target system. The code will run with the privileges of the target user.

A specially crafted EMF or WMF image file can trigger a heap overflow in performing integer calculations [CVE-2008-1083].An EMF file with specially crafted filename parameters can trigger a stack overflow [CVE-2008-1087]." }-Like the PDF file which seems to spawn new ways of exploiting the PDF Reader, the WMF file afforded many opportunities for exploitation!


----
rich

[trismegistos]

@rmus: remote or arbitrary code execution vulnerabilities and buffer overflow vulnerabilities, etc. those terms are confusing me. To me they are all the same. But from a conversation with Steve Gibson with a white hat concerning wmf... http://www.grc.com/sn/sn-021.htm

-{ Quote: "
Steve: Ilfak, the one thing that I've seen mixed issues about is whether this vulnerability is created by a buffer overrun bug in the Windows Metafile processing, or is it just taking advantage of a feature which is working correctly and has always been there.

Ilfak: It is the latter, the second. It's not a buffer overflow. It is something that is by design. So the design of these WMF files allows to specify a code sequence to be executed. And this code sequence is in the file itself, so anything can happen.
" }-

[Rmus]

-{ Quote: "@rmus: remote or arbitrary code execution vulnerabilities and buffer overflow vulnerabilities, etc. those terms are confusing me. To me they are all the same." }-To me also. As long as they all do the same thing: launch an executable -- they are dead in the water, as far as I'm concerned.

The reason I picked up on wmf and buffer overflow is that I remember from the 2005 exploit that there were three methods of protection before the Microsoft patch:

1) WMF file Signature -- Black Listing

2) blocking the executable from running - White Listing

3) block the Shell Code in the .wmf file from executing - Buffer Overflow protection.

EDIT: Actually 4 methods, if you include the 3rd-party patch prior to the Microsoft Patch.

This third one was mentioned by only a few companies, one of which was McAfee, which I quoted above. Again:

-{ Quote: "McAfee Host IPS’ generic buffer overflow protection blocks code execution that would result from the buffer overflow." }-As far as the conversation/discussion you reference: I am not technically informed enough to know one way or another.

Again, if the end result is a malware executable, and it can be blocked from running/installing, the method used is irrelevant.

-rich

[trismegistos]

Finally, I had some free time and tried out this malware firsthand instead of just speculating on how HIPS were bypassed.

I was wrong to assume that the PIF uses exploit/s to some unknown vulnerability/ies. TPR.Pif and B.css is essentially the same malware executable with the latter renamed as a harmless looking cascading style sheet (perhaps to avoid blacklisting detection) and the former executable, to run as an autorun together with autorun.inf. Just renaming them both to exe and see the properties of each and they have the same size(in kb), file version, product version, special build description, etc. Windchild was right after all.

I did the testing first by renaming b.css into b.exe and running from windows explorer. No need for the command prompt or cli(commandline interface) or using cmd.exe.
I have watched how so many registry entries were created and deleted, dll files created, drivers created and trying to load, created autorun.inf as well as the tpr.pif and finally phoning home to mothership(he he). I have observed some peculiarities on which what Aigle observed was that the malware was trying to use another trusted process to access the internet. There were instances where a trusted process like explorer.exe or windows explorer tried to phone home on behalf of the malware.

Using just windows explorer(no need to use Xyplorer), I double click the hidden tpr.pif in order to run the executable and it made the same actions as b.css. I repeat, the created daughter executable file, tpr.pif is essentially doing the same actions as the mother, b.css.

btw, in order for the windows explorer to see this hidden file, you have to go to tools/folder options and then, untick 'hide extensions for known file types' and 'hide protected operating system files' and of course you have to tick 'show hidden files and folders'.

I did run the file also in Xyplorer and did find the same actions or behaviour. Likewise, I did observe Xyplorer trying to phone home in behalf of the malware.

Edit: Now the question of aigle is how did the executable able to interact to a trusted process. Even if memory modification, windows messaging, dll and driver loading, dll injection, etc are all being covered and monitored by the HIPS. How after deliberately executing the malware, none of the any windows messages, interprocess communications or memory modification etc were not intercepted. What aigle seemed to be concerned of is that HIPS failed to intercept calls by the malware to another trusted process to phone home.

[1boss1]

-{ Quote: "I was wrong to assume that the PIF uses exploit/s to some unknown vulnerability/ies." }-

Thanks for testing, very interesting. I didn't think it was performing any kind of overflow type vulnerability, i thought it was just the Explorer/XYplorer file handler interpreting the contents of the .pif and carrying out the directions itself.

Where is WildChild's comment, is it in another thread? I'd love to see what he said so i can understand your finding a little better.

[trismegistos]

-{ Quote: "Thanks for testing, very interesting. I didn't think it was performing any kind of overflow type vulnerability, i thought it was just the Explorer/XYplorer file handler interpreting the contents of the .pif and carrying out the directions itself.

Where is WildChild's comment, is it in another thread? I'd love to see what he said so i can understand your finding a little better." }-

http://www.wilderssecurity.com/showpost.php?p=1539728&postcount=68

-{ Quote: "I've not looked at the .css file in question, but I would still bet that it's not a real .css file at all. It's most likely just a normal PE executable file that has simply been renamed to something harmless looking like "colorset.css". That is done all the time, to fool users, malware scanners and all sorts of things to think the file is innocent instead of being a normal executable that could be anything from nice game to nasty rootkit. The file extension doesn't matter at all: if code that is already running (like cmd.exe in this case, or exploit shellcode in some other case) wants to execute a file with a .css extension as a program, it can do that (cmd.exe calls CreateProcess on the file, and if it looks like a program, it is executed even if the file extension is .txt or .css or anything). Simply open the supposed .css file in a hex editor and check the headers - if there's an executable header, then it's a program, not a cascading style sheet at all.

Once executed, the program can then do what it wants, like create autorun.infs or other files that have innocent extensions but are really programs.

In this case, I wouldn't be quick to assume there's any exploit at all, as in, a vulnerability that is being exploited. I don't think anything suggests there's a buffer overflow or anything involved. The .css and .pif files are both likely just normal executables with a funny name to make them look innocent. If they can do something HIPS shouldn't allow, then there's probably some bypass of the HIPS products that has been discovered and is taken advantage of by the malware. The things HIPS attempts to do are extremely complex, and it would be a great wonder of the world if they were able to do a flawless job at it." }-

[trismegistos]

Update: I had done a quick retest and did some very tight configuration of the HIPS to even ask or prompt for any dll loading. I blocked the loading of dll or of the library file, which was created by the malware and was located in the C:\TEMP folder. After doing that, the malware wouldn't be able to interact with either windows explorer or xyplorer in order to phone home unlike my initial testing where the HIPS was bypassed. The library file if loaded seems to be the one responsible in doing some calls to either explorer.exe or xyplorerfree.exe which HIPS failed to intercept. The calls could be probably happening deep enough that HIPS failed to intercept (if some HIPS monitor only in certain areas under usermode level only and not at kernel level) or do some actions on areas not covered by the HIPS (not all areas in the kernel level are covered by HIPS).

[aigle]

Good work!

Can you give me the anme of this/ these dll? and location? Also screenshot of pop up alerts for these dll loading. I am asking as I am very much doubtfull as GesWall, DefenceWall, and SBIE etc will not allow such dll loading into a trusted process.

[trismegistos]

-{ Quote: "Good work!

Can you give me the anme of this/ these dll? and location? Also screenshot of pop up alerts for these dll loading. I am asking as I am very much doubtfull as GesWall, DefenceWall, and SBIE etc will not allow such dll loading into a trusted process." }-

The Dll names are arbitrary and are found in temp folder and are ending in .tmp file extension for e.g. dll1A.tmp . It seems that those sandboxing and HIPS sol'ns have simply allowed the loading of dll on temporary folder since those have .tmp file extension name.(Just a speculation). There's no breach in that the malware inside the sandbox will not be able to use a trusted process outside of the sandbox. All processes' activities are happening and are confined to the sandbox and isolated from the system. The malware may phone home but all actions are confined to the sandbox environment. Privacy breach, maybe, but, Security breach, no.

Sample logs below when b.exe or b.css was ran under Sandboxie with default config i.e allow internet access to all, no start-run restriction. You can see below that the malware had used Sandboxie's start.exe to access the internet...

-{ Quote: "
2009-09-17 08:50:20 Application protection(Execute application) Action:Allow
Process path: C:\WINDOWS\explorer.exe
File path: C:\Program Files\Sandboxie\Start.exe
Parameters:/box:DefaultBox C:\Sandbox\SYSTEM\DefaultBox\drive\C\b.exe

2009-09-17 08:53:26 File protection(Create file) Action:Allow
Process path: C:\Sandbox\SYSTEM\DefaultBox\drive\C\b.exe
File path: C:\Sandbox\SYSTEM\DefaultBox\drive\C\daping.dll

2009-09-17 08:53:26 File protection(Modify file) Action:Allow
Process path: C:\Sandbox\SYSTEM\DefaultBox\drive\C\b.exe
File path: (Hide file)C:\Sandbox\SYSTEM\DefaultBox\drive\C\daping.dll

2009-09-17 08:54:53 File protection(Create file) Action:Allow
Process path: C:\Sandbox\SYSTEM\DefaultBox\drive\C\b.exe
File path: C:\Sandbox\SYSTEM\DefaultBox\drive\C\TPR.PIF

2009-09-17 08:54:53 File protection(Create file) Action:Allow
Process path: C:\Sandbox\SYSTEM\DefaultBox\drive\C\b.exe
File path: C:\Sandbox\SYSTEM\DefaultBox\drive\C\AUTORUN.INF

2009-09-17 08:54:53 File protection(Create file) Action:Allow
Process path: C:\Sandbox\SYSTEM\DefaultBox\drive\C\b.exe
File path: C:\Sandbox\SYSTEM\DefaultBox\drive\C\TEMP\dll19.tmp

2009-09-17 08:55:50 File protection(Create file) Action:Allow
Process path: C:\Sandbox\SYSTEM\DefaultBox\drive\C\b.exe
File path: C:\Sandbox\SYSTEM\DefaultBox\drive\C\TEMP\dll1B.tmp

2009-09-17 08:55:53 File protection(Create file) Action:Allow
Process path: C:\Sandbox\SYSTEM\DefaultBox\drive\C\b.exe
File path: C:\Sandbox\SYSTEM\DefaultBox\drive\C\TEMP\dll1C.tmp

2009-09-17 08:55:55 File protection(Create file) Action:Allow
Process path: C:\Sandbox\SYSTEM\DefaultBox\drive\C\b.exe
File path: C:\Sandbox\SYSTEM\DefaultBox\drive\C\TEMP\dll1D.tmp

Firewall A:
type,date,time,source,destination,transport
PE,2009/09/17,09:11:32 -4:00 GMT,Rising RsShell,0.0.0.0:53,N/A
ACCESS,2009/09/17,09:11:38 -4:00 GMT,Rising RsShell was denied Internet access because of one or more modules.,N/A,N/A

Firewall B:
APP: Stopped PC >> Internet
Path:C:\PROGRAM FILES\SANDBOXIE\START.EXE
Name:Sandboxie Start
Data:C:\SANDBOX\SYSTEM\DEFAULTBOX\DRIVE\C\B.EXE
" }-

[Lebowsky]

So, is this a bypass of GesWall due to software bug or improper configuration by the user? Im confused.

[Joeythedude]

If it downloads an exe from the internet , is that exe also sandboxed ?

[aigle]

I highly doubt that GesWall will aloow loading of an untrusted dll.

[aigle]

-{ Quote: "If it downloads an exe from the internet , is that exe also sandboxed ?" }-
What do u mean by this?

Any untrusted application, if downloads something that will be automatically untrusted too.

[trismegistos]

-{ Quote: "I highly doubt that GesWall will aloow loading of an untrusted dll." }-

So, how was geswall bypassed? I have tested sandboxie and it contained this malware and, therefore, no security breach. Then, how can you explain this malware was able to use a trusted process under geswall to phone home, whereas in sandboxie, the malware wasn't able to use a trusted process outside of the sandbox. As the other poster said, is this a bug of geswall? Any other geswall experts or users could care to try out this malware?

-{ Quote: "GesWall bypassed as well.

211787
211790
211789" }-

[Joeythedude]

-{ Quote: "What do u mean by this?

Any untrusted application, if downloads something that will be automatically untrusted too." }-

Well if we are taking about it bypassing Geswall then maybe this aspect is bypassed too ..

I know how it should work !

[aigle]

-{ Quote: "So, geswall is not bypassed? Which contradicts your initial statements? I have tested sandboxie and it contained this malware." }-
Actually I got same results with SBIE, DW and GW. All of them contained the malware, excpet, that XYplorer tried to connect to internet with all three.

I can,t find the reason for this weired outbound connection by XYplorer and I can reproduce it consistently.

[trismegistos]

-{ Quote: "Actually I got same results with SBIE, DW and GW. All of them contained the malware, excpet, that XYplorer tried to connect to internet with all three.

I can,t find the reason for this weired outbound connection by XYplorer and I can reproduce it consistently." }-
But in your case, XYplorer was running inside the sandbox, right? In my testing with sandboxie, the malware wasn't able to use a trusted process outside of the sandbox.
If xyplorer is also running inside the sandbox, I am not surprised at all if that malware will be able to interact with xyplorer.

Edit: I ran within the default sandbox of Sandboxie both XYplorer and b.css. The malware wasn't able to use XYplorer to phone home but did so directly by itself(via start.exe) which was easily catched by any firewall or can be blocked by a simple tweak on the Sandboxie's settings. So, the HIPS(with a default permissive config: dll loading- allowed globally) was able to prevent interprocess communications between the two. Even without the help of any HIPS, Sandboxie has prevented this malware from using a trusted process outside of the sandbox to phone home. Then, I ran the malware through Xyplorer within the sandbox, that's when the malware was able to use Xyplorer to connect to the internet which is not surprising to me. But the point is, there's no security breach whatsoever even with the default settings of sandboxie, on which there's no start-run restriction and with allowed internet access for all processes. You can achieve even more bullet-proof protections as well as some privacy protections by doing simple tweaks on the settings.

[Athletic]

Super :) Sandboxie do what needs to do.Allow almost all but just inside box.Network leak via svchost form inside box is really just a little thing...

btw.O.K. the malware test is very good,but in the real world i think user of some HIPS+firewall would notice that is going something unusual and would block that.....''possible malware behavior''...

[trismegistos]

-{ Quote: "Super :) Sandboxie do what needs to do.Allow almost all but just inside box.Network leak via svchost form inside box is really just a little thing...
" }-
You can block all unwarranted network leaks with just a little tweak on Sandbox settings specifically on "Restrictions-Network access"

Then a tweak on Start/Run Access can stop all malwares from drive by downloads and leave them dropped cold.

A tweak on "Resource Access" can isolate any privacy leaks.

What more can you ask for from a little nifty freeware.

-{ Quote: "btw.O.K. the malware test is very good,but in the real world i think user of some HIPS+firewall would notice that is going something unusual and would block that.....''possible malware behavior''..." }-
Agree.

[aigle]

-{ Quote: "But in your case, XYplorer was running inside the sandbox, right? In my testing with sandboxie, the malware wasn't able to use a trusted process outside of the sandbox.
If xyplorer is also running inside the sandbox, I am not surprised at all if that malware will be able to interact with xyplorer.

Edit: I ran within the default sandbox of Sandboxie both XYplorer and b.css. The malware wasn't able to use XYplorer to phone home but did so directly by itself(via start.exe) which was easily catched by any firewall or can be blocked by a simple tweak on the Sandboxie's settings. So, the HIPS(with a default permissive config: dll loading- allowed globally) was able to prevent interprocess communications between the two. Even without the help of any HIPS, Sandboxie has prevented this malware from using a trusted process outside of the sandbox to phone home. Then, I ran the malware through Xyplorer within the sandbox, that's when the malware was able to use Xyplorer to connect to the internet which is not surprising to me. But the point is, there's no security breach whatsoever even with the default settings of sandboxie, on which there's no start-run restriction and with allowed internet access for all processes. You can achieve even more bullet-proof protections as well as some privacy protections by doing simple tweaks on the settings." }-
in all my testing xyplorer was running outside the sandbox. Pls read my first post to understand it fully. I tried to make it clear but it might still be confusing.

[aigle]

-{ Quote: "Well if we are taking about it bypassing Geswall then maybe this aspect is bypassed too ..

I know how it should work !" }-
in my brief testing, it was contained with no bypass.

[trismegistos]

-{ Quote: "in all my testing xyplorer was running outside the sandbox. Pls read my first post to understand it fully. I tried to make it clear but it might still be confusing." }-
Yes, I understand. Geswall, as you have said was bypassed. Because you ran the malware with xyplorer outside of Geswall's sandbox?

Now, it is clear to me.

Oh, you got to be kidding if you say Sandboxie was bypassed for the mere fact that you run the malware outside of the sandbox. Ofcourse, Sandboxie will not be able to save you on everything running outside. Ha ha

With my testing with Sandboxie, the malware b.css wasn't able to call out Xyplorer or any other trusted process outside of the sandbox. If you'd say that Xyplorer which was running outside of the sandbox and you ran the malware inside of the sandbox and was able to call out Xyplorer to connect to the internet. Then, there must be something wrong in your system? I observed that XYplorer on its own without the malware tend to phone home a lot.

Yes, I understand, you are still baffled on how the malware was able to use a trusted process despite running CFP, OA, Geswall etc.

Perhaps, experts like Prevxhelp, Windchild, Rmus, Sully or even SSJ100 or the developers would chip in.

[aigle]

-{ Quote: "in my brief testing, it was contained with no bypass." }--{ Quote: "
Oh, you got to be kidding if you say Sandboxie was bypassed for the mere fact that you run the malware outside of the sandbox. Ofcourse, Sandboxie will not be able to save you on everything running outside. Ha ha
" }-
I did not say that.

[trismegistos]

-{ Quote: "I did not say that." }-
I thought you are implying that. Because your statements are confusing and not clear. Anyways good to know those sandboxing solutions are not bypassed because the confusion stems from a few of your posts.
-{ Quote: "GesWall bypassed as well.
" }-

While here below, you seemed to imply that you actually ran the malware inside the sandbox because you said all of those sandboxing solutions 'contained the malware' and yet as you have said all the time XYplorer was running outside of the sandboxes but was able to connect to the internet with all three...
-{ Quote: "Actually I got same results with SBIE, DW and GW. All of them contained the malware, excpet, that XYplorer tried to connect to internet with all three.

I can,t find the reason for this weired outbound connection by XYplorer and I can reproduce it consistently." }-

I visited also the comodo forums. They are baffled also with our findings or are in a state of denial. Judging from the muddy responses, there will be no clear resolution to your problem.

[aigle]

Sorry for some confusion. I will try to clear some points.

1- I never run the malware out of sandbox as that will be not a test for sandbox in any way.

2- Malware was contained well by all sandboxes.

3- Only problem is that trsuted XYplorer tried to connect to internet when I tried to run an isolated/ untrusted malware file( .pif file) via trusted xyplorer. I am not sure whether it was something related to xyplorer. windows OS or some manipulation by malware.

[Joeythedude]

-{ Quote: "The Dll names are arbitrary and are found in temp folder and are ending in .tmp file extension for e.g. dll1A.tmp . It seems that those sandboxing and HIPS sol'ns have simply allowed the loading of dll on temporary folder since those have .tmp file extension name.(Just a speculation). There's no breach in that the malware inside the sandbox will not be able to use a trusted process outside of the sandbox. All processes' activities are happening and are confined to the sandbox and isolated from the system. The malware may phone home but all actions are confined to the sandbox environment. Privacy breach, maybe, but, Security breach, no.

Sample logs below when b.exe or b.css was ran under Sandboxie with default config i.e allow internet access to all, no start-run restriction. You can see below that the malware had used Sandboxie's start.exe to access the internet..." }-

If the malware phones home , downloads an exe , is that exe sandboxed/untrusted ?

Have you been able to test that ?

[trismegistos]

-{ Quote: "If the malware phones home , downloads an exe , is that exe sandboxed/untrusted ?

Have you been able to test that ?" }-
I see that you are using sandboxie and yet you haven't realized or don't fully trust its full potential, capability and design.
Obviously, everything running within the sandbox will remain isolated in the sandbox. Whether that malware which one gets easily by drive by downloads will download other malwares, those will never break out of the sandbox. Franklin and Peter2150 are the experts here and have tested sandboxie with a barrage of malwares and nothing has bypassed Sandboxie. Even this malware in question wasn't able to bypass Sandboxie.

The confusion stems from the methodology of testing Aigle implemented on which a deliberate bypass was done by user interaction. In this case, XYplorer which was running outside of the sandbox was used to run tpr.pif contained in the sandbox. That's tantamount to running tpr.pif unsandboxed. It's no surprise to me if tpr.piff was able to interact to XYplorer. It's like using unsandboxed windows explorer and double clicking on Sandbox contents and that's dangerous in terms of security because those contents could contain live malwares.

-{ Quote: "You can block all unwarranted network leaks with just a little tweak on Sandbox settings specifically on "Restrictions-Network access"

Then a tweak on Start/Run Access can stop all malwares from drive by downloads and leave them dropped cold.

A tweak on "Resource Access" can isolate any privacy leaks.

What more can you ask for from a little nifty freeware.
" }-
Now the tweak on Start/Run Access acts like a default deny policy or AntiExecutable type of protections. That malware will not even run and if for e.g. that malware was given a clearance to run and given leeway to download more nasty stuffs, those malwares that were downloaded will not be able to run or simply dropped down cold dead.

[trismegistos]

-{ Quote: "Sorry for some confusion. I will try to clear some points.

1- I never run the malware out of sandbox as that will be not a test for sandbox in any way.

2- Malware was contained well by all sandboxes.

3- Only problem is that trsuted XYplorer tried to connect to internet when I tried to run an isolated/ untrusted malware file( .pif file) via trusted xyplorer. I am not sure whether it was something related to xyplorer. windows OS or some manipulation by malware." }-
In point no.1, you said you never ran the malware out of sandbox, but, you deliberately run tpr.pif by using XYplorer which was running outside of the sandbox. That's the contradiction. Remember that tpr.pif is carbon copy of b.css or b.exe. So basically you are running the malware outside of the sandbox by double clicking tpr.pif from XYplorer.
It's no surprise to me if tpr.piff was able to interact to XYplorer. It's like using unsandboxed windows explorer and double clicking on Sandbox contents and that's dangerous in terms of security because those contents could contain live malwares.
-{ Quote: "in all my testing xyplorer was running outside the sandbox. " }-

[aigle]

.pif file was marked untrusted by GesWall/ DefenceWall, so even I tried to launch it via XYplorer, it will be launched isolated( with or without a pop up alert from GesWall).

[trismegistos]

-{ Quote: ".pif file was marked untrusted by GesWall/ DefenceWall, so even I tried to launch it via XYplorer, it will be launched isolated( with or without a pop up alert from GesWall)." }-
I don't use DefenceWall and GesWall. Obviously those are policy based HIPS and have different implementation from Sandboxie.
Those untrusted and sandbox terminologies have gotten us confused because we are talking about different softwares with different designs and implementations with the use of the same malware b.css with its carbon copy tpr.pif.
So, basically there's a bug with both defensewall or geswall, which caused the bypass. You must report this to Ilya and to the geswall author.

[aigle]

Not sure of bug but I have reported already.

[trismegistos]

-{ Quote: "Not sure of bug but I have reported already." }-
Probably. As the old excuse goes, "this is just a limitation of design." For e.g. Sandboxie's design limitation is it will not protect anything outside of the sandbox.

[Joeythedude]

Thanks I'm a good bit clearer now.

Its nothing to do with sandboxie.

And its a possible bug in Geswall