TDL/TDSS trojan series bypassing isolation software

[Empath]

Originally Posted by xorrior

If there is.......

Originally Posted by dax123

sounds like hell

With the proper 'ifs', anything is possible.

[xorrior]

Originally Posted by Empath

With the proper 'ifs', anything is possible.

It isn't really a mystery. Most people with the skills have reversed sandboxie DLLs and driver. There two ways I know to defeat it without even looking into it much, much much more methods probably exist..

1.LoadLibraryA method of detection to conceal payload
2.Thread interlock method supplemented with detours to overwrite it's injection from the PE. From here you can fool it's driver and write outside it's emulated environment.

These people who code rootkits aren't exactly the idiots sandboxie community takes them for. It's not publicly exploited cause not enough people use it yet. Not because there isn't a way or because anyone lacks the skills. There are noob level VB and delphi malwares using the LoadLibraryA method currently, and has been for a while. When industrial kit authors take notice they will most likely do a generic method to hijack the driver and overwrite the DLL injections, or disable the user32.dll method it uses.

Originally Posted by tzuk

Thanks for link. Seems IceSword does get to do what it wants.. I will check it out.

He confesses after he and his community members flamed a lot of respected people at sysinternals for pointing it out..

[Buster_BSA]

Originally Posted by xorrior

It isn't really a mystery. Most people with the skills have reversed sandboxie DLLs and driver. There two ways I know to defeat it without even looking into it much, much much more methods probably exist..

1.LoadLibraryA method of detection to conceal payload
2.Thread interlock method supplemented with detours to overwrite it's injection from the PE. From here you can fool it's driver and write outside it's emulated environment.

Define "defeat".

Do you mean to write to real disk instead sandbox folder?

[Serapis]

Originally Posted by xorrior

It isn't really a mystery. Most people with the skills have reversed sandboxie DLLs and driver. There two ways I know to defeat it without even looking into it much, much much more methods probably exist..

1.LoadLibraryA method of detection to conceal payload
2.Thread interlock method supplemented with detours to overwrite it's injection from the PE. From here you can fool it's driver and write outside it's emulated environment.

These people who code rootkits aren't exactly the idiots sandboxie community takes them for. It's not publicly exploited cause not enough people use it yet. Not because there isn't a way or because anyone lacks the skills. There are noob level VB and delphi malwares using the LoadLibraryA method currently, and has been for a while. When industrial kit authors take notice they will most likely do a generic method to hijack the driver and overwrite the DLL injections, or disable the user32.dll method it uses.

Hi xorrior, I remember reading a similar topic posted by you at the sandboxie name under the name 'lothar'. It is not a part of my character to criticize blindingly what you have shared -- I am definitely not a fanboy, but am a heavily reliant on Empiricism.

Have you personally tested these critters against sbie? do you know where they are currently being developed? Do you personally utilize sandboxie? I think the most ethical action to take is to share links of these malwares on tzuk's forum where he can get a chance to look at them and improve his product accordingly.

[Serapis]

Originally Posted by tzuk
Thanks for link. Seems IceSword does get to do what it wants.. I will check it out.

If I recall correctly, it turned out that sandboxie was only bypassed on systems that had icesword run on them beforehand, unsandboxed. any subsequent executions within the sandbox relied on communicating with the already installed icesword driver to facillitate a bypass.

In the situation of malware, what this translates to is; once you execute them out of the sandbox (at least even once), you're pretty much on your own.

[Buster_BSA]

Originally Posted by Serapis

Hi xorrior, I remember reading a similar topic posted by you at the sandboxie name under the name 'lothar'. It is not a part of my character to criticize blindingly what you have shared -- I am definitely not a fanboy, but am a heavily reliant on Empiricism.

I think like you. First he must defined "defeat" so we can know if he´s talking about not publicly available exploits that allow writing to real disk to sandboxed applications.

As soon as we know if he means that, we can continue with the third degree.

[xorrior]

Yes defeat is writing outside of the emulation. It can also be overwriting the actual code of sandboxie post-load which is easy because the sections are writable and it doesn't hide itself.

The entire system is based entirely around the following binaries, SbieDll.dll alone reveals how the entire engine works. SbieDrv.sys is only for security, but once you have control over the dll you can issue new tokens and your process can write outside. The service only injects the dll as a thread into sandboxed processes and hooks stuff it finds in the IAT.

SbieSvc.exe
SbieDll.dll
SbieDrv.sys

Like I said you don't see it cause nobody cares. Sandboxie doesn't pose a threat to commercial/industrial rootkits on a big enough scale.

LoadLibraryA is extremely trivial though, one line of code in languages most of these kits are being written in. The other method uses thread interlocks to manipulate sandboxies injections. I'm not going to write anything, I don't work for them, and if you can't implement this yourself you're probably criticizing above your pay grade.

[Buster_BSA]

Originally Posted by xorrior

Like I said you don't see it cause nobody cares. Sandboxie doesn't pose a threat to commercial/industrial rootkits on a big enough scale.

I think we don´t see it because it´s not possible.

Originally Posted by xorrior

LoadLibraryA is extremely trivial though, one line of code in languages most of these kits are being written in. The other method uses thread interlocks to manipulate sandboxies injections. I'm not going to write anything, I don't work for them, and if you can't implement this yourself you're probably criticizing above your pay grade.

Sorry but I consider you are not going to write anything because you don´t know how to do it. You only know to blah blah blah this and blah blah blah that.

Write a POC that writes out of the sandbox or shut up.

I remember that not many time ago I found someone writing a blog that promised to write the same POC. I added a comment telling him to hurry up and show it. After two weeks the blog was removed.

I guess now you will put excuses to don´t write the POC. Ok, that´s fair but for me you are a ... whatever, that´s an opinion I´ll keep for myself.

[Buster_BSA]

btw... My BSA has a method to fool the noob level VB and delphi malwares using the LoadLibraryA method. Sandboxie goes unnoticed for them.

[Buster_BSA]

Do this: Visit Sandboxie´s forum and open a thread at "Anything else" where you explain technically how to write to real disk from a sandboxed application.

Then we wait tzuk gives his opinion about your method and we see if it´s possible or not, ok?

[nick s]

Originally Posted by xorrior

He confesses after he and his community members flamed a lot of respected people at sysinternals for pointing it out..

You forgot to mention the issue's resolution. The real system was already "infected" (http://www.wilderssecurity.com/showp...3&postcount=29).

Just in case somebody is reading this without reading the rest of the thread, I'll repeat what I said here in a later message and in the other: unlike what the subject says, IceSword is actually NOT able to break out of Sandboxie in normal conditions. I mistakenly thought I had found a Sandboxie security flaw at first, but this was not the case: Sandboxie DOES block IceSword from running in kernel level, unless IceSword is executed outside the sandbox before.

If IceSword is executed outside the sandbox, it loads its kernel driver, which is not "unloaded" when the IceSword program is shut down; only because of this reason Sandboxie is unable to stop it later on. If you start IceSword only in the sandbox, it won't run, because Sandboxie will block it from loading its driver. So this is not a flaw in Sandboxie.

[nick s]

Originally Posted by xorrior

EDIT: Some variants in the 7.10.09.10 Avira DB now defeat NIS 2011 and some other solutions btw..

Just like previous TDL/TDSS variants were defeating NIS 2010 and other solutions for many months. I would rather depend on Sandboxie to avoid its damage than on an AV.

[Buster_BSA]

Originally Posted by nick s

You forgot to mention the issue's resolution. The real system was already "infected"

You are right, but that´s an old story. Now xorrior explained that Sandboxie can be bypassed using the thread interlock method.

I give him two possibilities:

1) create a POC application showing how to write out of the sandbox

2) Explain to tzuk the technics involved to bypass Sandboxie so tzuk can agree or deny the bypass method

Let´s wait for his reply to know what he´s going to do.

[xorrior]

Originally Posted by Buster_BSA

I think we don´t see it because it´s not possible.



Sorry but I consider you are not going to write anything because you don´t know how to do it. You only know to blah blah blah this and blah blah blah that.

Write a POC that writes out of the sandbox or shut up.

I remember that not many time ago I found someone writing a blog that promised to write the same POC. I added a comment telling him to hurry up and show it. After two weeks the blog was removed.

I guess now you will put excuses to don´t write the POC. Ok, that´s fair but for me you are a ... whatever, that´s an opinion I´ll keep for myself.

FYI: I don't respond to trolling.

SbieSvc.exe
--.text executable+readable
--.data readable+writable
--.rsrc readable

SbieDll.dll
--.text executable+readable
--.data readable+writable
--.rsrc readable
--.reloc readable

SbieDrv.sys
--.text executable+readable
--.rdata readable
--.data readable+writable
--.INIT executable+readable+writable
--.rsrc readable
--.reloc readable

If you don't know what that means, then you obviously have no clue what is possible, or what I'm even talking about.

LoadLibraryA is being used in the wild, and not by just sophisticated malware.

There also plenty of things to be done with native thread syscalls like I said. I don't work for that company, I'm not going to write code to help them or malware authors. If you don't approve I really don't care. They had the same response when this was coming from people at sysinternals with a lot of credibility. We don't do work for companies that choose to ignore.

[Buster_BSA]

Originally Posted by xorrior

FYI: I don't respond to trolling.

Trolling is what you do, accusing Sandboxie of being vulnerable but not giving any proof of it.

Why don´t you want to discuss with tzuk at a technical level about the method you consider that is able to bypass his security software? Are you afraid of something?

If you pretended to come here and get some fame and attention doing that kind of statements... sure, you did it! but I´m afraid that at the moment the only fame and attention you got is not of the good one.

Originally Posted by xorrior

We don't do work for companies that choose to ignore.

I can assure you that if you open a thread at Sandboxie´s forum explaining how you would bypass Sandboxie´s protection you will not be ignored.

If you don´t do that everybody will be able to see the validity of your statements.

[xorrior]

Originally Posted by Buster_BSA

Trolling is what you do, accusing Sandboxie of being vulnerable but not giving any proof of it.

Why don´t you want to discuss with tzuk at a technical level about the method you consider that is able to bypass his security software? Are you afraid of something?

If you pretended to come here and get some fame and attention doing that kind of statements... sure, you did it! but I´m afraid that at the moment the only fame and attention you got is not of the good one.



I can assure you that if you open a thread at Sandboxie´s forum explaining how you would bypass Sandboxie´s protection you will not be ignored.

If you don´t do that everybody will be able to see the validity of your statements.

Discuss with tzuk? I and about 15 other people already presented the information. These things are still in 3.46. Not just random pseudonyms either, some credible people in rootkit research.

I'm not afraid of anything, just the info I posted in my last post alone proves my statements. You obviously don't comprehend because you don't know anything about the subject matter.

I presented technical-literal information, you presented nothing, but defended based off information you most likely comprehended on the front page of the vendors website.

This will be my last post on these forums, have fun presenting your substanceless retorts to more technical discussions.

[Buster_BSA]

Originally Posted by xorrior

Discuss with tzuk? I and about 15 other people already presented the information. These things are still in 3.46. Not just random pseudonyms either, some credible people in rootkit research.

Links to read the information and the discussion, please.

Originally Posted by xorrior

I presented technical-literal information, you presented nothing, but defended based off information you most likely comprehended on the front page of the vendors website.

For two times I found vulnerabilities in Sandboxie and I was the first person to be very critic with the software. You only have to read my posts at Sandboxie´s forum to confirm that.

Nobody can accuse me of being an arse licker of any vendor. In fact these days I have been criticing almost every "reboot and restore" vendor for hiding the vulnerability they have had in their software for years.

The difference between you and me is that when I have accused a vendor of being vulnerable I have showed proofs. Anyone could reproduce the vulnerability and see how the software was bypassed.

Originally Posted by xorrior

This will be my last post on these forums, have fun presenting your substanceless retorts to more technical discussions.

Now just because someone asks you to provide a POC or talk to tzuk you leave the forum... you can guess how convincing your statements look like.

[tzuk]

Originally Posted by xorrior

The service only injects the dll as a thread into sandboxed processes and hooks stuff it finds in the IAT.

Hello xorrior. I see you come here and pretend you have done some deep analysis on Sandboxie and know how it works. Unfortunatley you got it wrong which paints your claims in a weak light.

For example, it isn't the service that injects the DLL, but rather the driver. Stuff isn't hooked by overwriting IATs but by overwriting actual code at top of API functions.

Originally Posted by xorrior

but once you have control over the dll you can issue new tokens and your process can write outside.

No, that's not how things work. First, the "in-sandbox" indicator is inherited from one process to another, regardless of security token. So you can't switch tokens as a way to escape the sandbox. Second, Sandboxie doesn't care which security token is used. If the process belongs to a sandbox, then access is granted or denied based on file/registry/object path, not based on the security token.

Originally Posted by xorrior

I'm not going to write anything, I don't work for them, and if you can't implement this yourself you're probably criticizing above your pay grade.

Don't you think that takes all your credibility away? If you make wild accusations, then step up and prove them. Saying that you can't be bothered to prove anything, because you don't work for Sandboxie, I'm afraid that doesn't give your claims any merit. Quite the contrary.

Now as Buster said, if you can back up your claims with proof-of-concept code, then I'll be happy to take a look. If there is anything to it, I'll be more than happy to adjust Sandboxie. But until you come back with some proof, I can't take your wild accusations seriously, can I?

[Buster_BSA]

Originally Posted by tzuk

But until you come back with some proof, I can't take your wild accusations seriously, can I?

Nor you neither anyone with a minimum of intelligence.

He didn´t accept the challenge of discussing things at a technical level with you even. Instead he prefered to quit the forum. For me that says enough about him and his statements.

[Saraceno]

Great reading. Fantasy world verse reality!

Thanks tzuk and Buster.

[acuariano]

Originally Posted by Saraceno

Great reading. Fantasy world verse reality!

Thanks tzuk and Buster.

[kennyboy]

Now's your chance xorrior.

Tzuk is here and willing to discuss anything you have to say. Give your self some credibility and discuss it with the man who can give you some informed and credible answers.

[Peter2150]

Originally Posted by kennyboy

Now's your chance xorrior.

Tzuk is here and willing to discuss anything you have to say. Give your self some credibility and discuss it with the man who can give you some informed and credible answers.

Lets not stir anything more up please. There already has been enough.

Pete

[kennyboy]

Originally Posted by Peter2150

Lets not stir anything more up please. There already has been enough.

Pete

I take offense at that Peter. I in no way stirring anything up.

I was purely trying to encourage some constructive discussion among the parties who should be engaging more.

[BlueZannetti]

Originally Posted by kennyboy

I take offense at that Peter. I in no way stirring anything up.

I was purely trying to encourage some constructive discussion among the parties who should be engaging more.

You shouldn't be taking offense here. My reaction was identical to Peter's. Just because you wished to convey another message doesn't mean that message was received by the readers.

Now - let's get back to the topic of the thread.

Blue