TDL/TDSS trojan series bypassing isolation software

Discussion in 'sandboxing & virtualization' started by taleblou, Jun 29, 2010.

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

    Empath Registered Member

    With the proper 'ifs', anything is possible.
  2. xorrior

    xorrior Registered Member

    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.

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

    Buster_BSA Registered Member

    Define "defeat".

    Do you mean to write to real disk instead sandbox folder?
  4. Serapis

    Serapis Registered Member

    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.:D
  5. Serapis

    Serapis Registered Member

    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.
  6. Buster_BSA

    Buster_BSA Registered Member

    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.
    Last edited: Jul 7, 2010
  7. xorrior

    xorrior Registered Member

    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.


    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.
  8. Buster_BSA

    Buster_BSA Registered Member

    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.
    Last edited: Jul 6, 2010
  9. Buster_BSA

    Buster_BSA Registered Member

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

    Buster_BSA Registered Member

    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?
  11. nick s

    nick s Registered Member

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

    nick s Registered Member

    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.
  13. Buster_BSA

    Buster_BSA Registered Member

    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.
  14. xorrior

    xorrior Registered Member

    FYI: I don't respond to trolling.

    --.text executable+readable readable+writable
    --.rsrc readable

    --.text executable+readable readable+writable
    --.rsrc readable
    --.reloc readable

    --.text executable+readable
    --.rdata readable 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.
    Last edited: Jul 7, 2010
  15. Buster_BSA

    Buster_BSA Registered Member

    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.
    Last edited: Jul 7, 2010
  16. xorrior

    xorrior Registered Member

    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.
  17. Buster_BSA

    Buster_BSA Registered Member

    Links to read the information and the discussion, please.

    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.

    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.
  18. tzuk

    tzuk Developer

    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.

    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.

    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?
  19. Buster_BSA

    Buster_BSA Registered Member

    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.
  20. Saraceno

    Saraceno Registered Member

    Great reading. Fantasy world verse reality! ;)

    Thanks tzuk and Buster. :thumb:
  21. acuariano

    acuariano Registered Member

  22. kennyboy

    kennyboy Registered Member

    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.
  23. Peter2150

    Peter2150 Global Moderator

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

  24. kennyboy

    kennyboy Registered Member

    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.
  25. BlueZannetti

    BlueZannetti Administrator

    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.

Thread Status:
Not open for further replies.