«
»

Firewall bypassing via FWB++

May 26th, 2009 by carrumba

Tool name : FirewallBypassing++ 0.1
 
Description : A tool to check if your desktop firewall can be bypassed by injecting code into a remote process. It opens an existing process (in this case a running instance of Internet Explorer), allocates memory in the address space of the remote process where the new malicious code will be copied to. After copying the malicious code it will be executed as a new thread. If everything works as expected the Internet Explorer will connect to the Megapanzer homepage and informs you if the connection was established successfully.
 
Tested on : Windows XP
 
Feedback : In case you encounter any problems with the tool, you have suggestions to improve it, or you tested it with a Windows version i’ve not yet tested please drop me an email.
 
Downloads : Binary | Source


tags: , , , ,

posted in Tools & sources

2 responses to “Firewall bypassing via FWB++”

  1. anoldtimer says:
    2009/08/28 at 18:49

    Here’s some trivia about the origin of the fwb+/fwb++ name.
    This was originally posted by the coder of the Bifrost RAT some years ago at a now closed security forum:
    ————————————————————————————-
    In 2002 a new technique to bypass software firewalls started to get popular. By compiling the RAT as a dll and then injecting it to the web browser I was able to bypass the firewalls. It was called firewall bypass (fwb).
    One of the first more common RATs to use this tech was Optix Lite, released in june 2002.

    I found the method so interesting that I started to code some private tools for my self. I’ve been coding for 25 years but at this point I started getting interested in coding RATs.

    At the end of 2003 more and more firewalls were blocking dll injection. They did it by setting kernel and/or user level API hooks to detect the injection and also by keeping track of all dll’s normally residing in the browser.

    This article explained an interesting method of injecting pure code to another process and I started writing on a small program that used this method instead of injecting a dll.
    Unfortunately I found that there were several firewalls it would not bypass as they detected the injection by using API hooks. If I remember correctly, ZA, Kerio and Sygate were among those.
    After installing most of the firewalls at market one by one I eventually found ways to beat all hooks. At that point I didn’t know how to unhook kernel level hooks, but it was possible to avoid them with other methods.
    For example, some of them detected that the browser was started in suspended mode by some unknown process, but that was avoided by injecting some small piece of code to explorer to have the brower process started from there. Explorer will of course always be allowed to start processes. :)

    In beginning january 2004 I had a small downloader called Troll ready for release, which was using these techniques.

    The “fwb” tech was getting more and more old, so I wanted to mark in someway that this was something different, as it could bypass all existing firewalls by avoiding all hooks and injecting pure code. I decided to add a “+”, so I called it “FireWall ByPass +”, or just “FWBP+”.

    While working on Troll I had another swedish coder called Gargamel helping me beta testing it.

    Later, while I worked on the first version if Bifrost in the spring 2004, Gargamel worked on a RAT called Flux. It was also written in C++ and used these methods. Together we developed these methods futher as some firewalls already had improved since Troll.

    When it was to be released from EvilEyeSoftware, GSEPP (EES admin) started a topic making some jokes about it. Among other things he asked if this also was to be called “FireWall Bypass Plus +”.
    Soon after that there were several releases from other coders where they claimed to be using this “fwb++” method.
    Someone told me the abbreviation of “firewall bypass” should be “fwb” and not “fwpb” so I later skipped that extra “p”.

    At some point later on, after Bifrost was released, Tiny firewall added so many both kernel- and user level hooks that it would stop all RATs. In fact, it was more or less impossible to use it at all as it stopped everything.
    Aphex then released some example source code that demonstrated how to unhook some user level hooks (WriteProcessMemory and some others), claiming this to be a step futher and called it “fwb#”. It was a nice piece of code, but it didn’t bypass any firewalls at all. The only firewall hooking these API’s was Tiny, but it used several kernel level hooks that would stop a RAT anyway.
    And did it have something more than “fwb+”? Not really. Even if Bifrost didn’t unhook exactly those API’s, the fwb+ method already had methods to unhook or avoid hooks. But I guess Aphex didn’t know that.

    And of course, soon after this it started to appear RATs where the author claimed it had “fwb++#”.
    I’m sure many of them were better than Bifrost in many ways, but they did not bypass more firewalls.

    Conclusions:

    * What does “fwb” mean?
    Dll injection, I suppose.

    * What does “fwb+” mean?
    What I meant when giving it that name was that it could avoid dll detection and had enough user- and kernel API hook avoidance to bypass all existing software firewalls.

    But today I think the name is rather useless.
    Most RAT’s are using a pe-loader to inject the dll and is avoiding detection that way. Many of them are unhooking user- and kernel level hooks – there are lots of source code examples of how to do that.
    But there are still firewalls they don’t bypass, because the firewalls have improved as well.

  2. h says:
    2009/09/15 at 15:49

    now thats a nice writeup about the differences between those three. thanks! it explained a lot

Leave a comment


But please respect the commenting rules. Critizism is appreciated and also general comments of course. If you're rude, I have to delete your comment. Also use your personal/nick name but avoid using business names. Have fun and thanks for participating the discussion.