Re: [PEN-TEST] penetrating trojan

[Jean-Christophe Touvet <jct () EDELWEB FR>]

> Recently, associated with a penetration test of one of our customers, we
> had a long discussion about various hacker techniques including well
> known trojans such as bo2k or sub7.
>
> Despite of a huge variety of plug-ins that are available for bo2j for
> example, I did not encounter one that makes the trojan the initiator of
> a connection. The trojan may send the ip of the compromised system to
> his master or accept encrypted connections even over tunneling as I
> detected once.

 I don't know if some plug-ins exist, but it's quite easy to modify BO2K to
make it "phone home". We have a tool, called "Reverse Back Orifice" (RBO2K),
which is a modified BO2K opening outgoing HTTPS connections, either directly,
either through a proxy if one is defined in workstation's environment. We
found this method (using HTTPS to establish the connection, then tunnel BO2K
commands through this channel) most efficient than encapsulating BO2K commands
in separate HTTP requests. We didn't even modify BO2K client: a 20 lines perl
script does the reversing job on client side. Using a "proxy" on client side
also helps the attacker to hide his real address: the "home" address (or name)
hardcoded in the trojan could be a compromised host where the proxy is
running. The attacker just connects to this compromised host using a regular
BO2K client, as shown below, in order to establish the connection with the
reversed server:

Attacker with std BO2K client
        v
        v
Host running RBO2K proxy
        ^
        ^
Target's Firewall
        ^
        ^
Internal host running RBO2K

> So all companies that have Network Address Translation enabled, are safe
> from such trojans since the "master" never will be able to contact the
> trojan (the victims IP will not be routed from the outside) !?
>
> What would make the situation a lot more dangerous is when the trojan
> itself had the connection started, let's say over port 80 using http
> protocol, e.g. pretending being a browser. Most Firewall settings would
> allow such a connection and the trojan could unfold his power (assuming
> he was not detected by a local anti virus program.

 Until now, this attack only failed when outgoing connections were
password-protected (authenticating proxy). We have some ideas about how to
circumvent this problem, but no time yet to implement them...

    -JCT-

PS: don't ask for the code.