LSP Trojan beats firewalls and AV software
Gary Chapman
successfully evade firewalls and antivirus using LSP ?
Publicly available trojans are ridiculously visible - 'netstat -a' reveals
connecting IP's and owned ports, AV vendors have no problems finding
beautifuly long AV signatures, silly options to open and close CD drawers,
Code implimented using 'hidden' windows, processes visible.
I have successfully achieved 2 types of LSP (Layered Service Provider) level
trojans who's sockets CANNOT be enumerated and they successfully evade
detection by firewalls (I rather egotisiticaly belive my code is invisible
to ALL local firewalls)
Tested against ...
blackice, zonealarm (Piece of crap), Sphynx (Damn good wall IMHO), BigFire,
Conceal.
It inserts itself into the lowest position in the LSP service chain (Below
the firewall) thus gaining benefits over standard lameware trojans:
o In promiscuous mode ANY existing socket can be used regardless
of ownership specialy quoted commands are stripped from the incoming
stream before the data is passed back up the transport SPI to the socket
owning APP.
Data outbound is quoted and inserted INTO the outgoing stream.
The socket owning app is aware of a connection being made, and sees any
regular (Unquoted) traffic
o In non-promiscuous mode the LSP opens a socket structure and
communicates directly with the base layer, whilst ignoring any requests
from
the above layer, and without passing any notifications up the chain, thus
bypassing any normal winsock accountability.
o The LSP aggressively maintains the lowest position in the stack, due to
problems with other apps competing for this position in now 'claims' to
be
the base layer to satisfy any other agressive app that also demands
lowest
position in the stack.
This ensures we have exclusive direct control of the base layer without
possibility of any intervening code monitoring our transactions.
o Being an LSP we have full access to all data in/out of all ports, this is
the remote data logging function, and records EVERYTHING according
to a filter list (fields supported: Module, Lport, Rport, RMask,
Protocol)
There are too many possibilities here to list. But the main points are:
NO visible sockets
NO local packet logging
NO firewall blocking
NO process ID,
NO need to execute at boot time using run=,load= .ini entries -or- run,
runservice registry entries, -or- file-type associations.
NO enumeratable windows (Hidden or otherwise)
It is as a trojan should be - stealthed ... anything else would just be lame
in the extreme !
Finaly, I have managed to develop a polymorphic self-encryption engine that
leaves NO signature potential in the trojan greater than 3 bytes.
Previously ...
any self-encrypter needed a decryption header in front of the code. Of
course,
such a decryption header could not be encrypted as it had to be executable.
Im using a lookup table of 58 pieces of NO-OPERATION code of varying length.
the program inserts sections of this code BETWEEN the instructions in the
header using 3 passes (marking the points between instructions with a
sentinel
value so that insertion points can be found easily and inserted code doesnt
split
an instruction from its parameters ... then a fourth pass inserts NO-OP code
from
the first 10 entries in the NO-OP table (<3 byte variations of NO-OP code)
so that any larger NO-OP code segments previously inserted are also broken
up.
Finaly all the sentinels are removed, as we no longer need them to mark the
safe insertion points.
As it would take an AI to clean the header back up, we have a copy of the
original decryption header in the encrypted tail of the code (With its
safe-insertion
point markers)
So, what do we have?
Well ... so far we have a full stealth win-trojan that AV vendors would not
find a signature greater than 3 bytes for, and therefore could not
accurately
detect due to the amount of false-triggering it would cause. That current
Firewall
technology cannot see, and that can either hide its sockets, or take
commands
promiscuously. (To avoid external port-scans revealing the unreported
sockets)
What do I need ?
Well, heres where I get very ambitious ...
I need people interested in helping me create a suitable contagion vector
for this code. Since I have access to ALL data in and out of ALL sockets -
I am
thinking that it may be possible to detect a few forms of transaction
negotiations,
and modify them on the fly.
for example ... any POST (website), DCC SEND(irc), PUT(ftp) involving a .exe
could be seen by our code ... it may then be possible to alter the reported
length
of any pending executable to accomodate our trojan.
Then we look for the exe header as it leaves the host, and modify the header
to point at the start of our code (Which will be appended) - then we let the
rest
of the transfer go through uninhibited till we reach the end ... and we then
take
control, insert our code as though it was part of the rightful executable,
and modify
a JMP back to the original .exe's normal entry point. (The same as a viral
infection,
but done on the fly) - We then release any further data that we have been
buffering
from the legitimate application.
This of course would only infect exe's leaving the machine, but since the
recieving
machine will never have seen the exe before, any AV software running on the
remote
side won't know the length has increased, as it is a NEW file - as far as AV
is
concerned it has *always* been that length.
Anyone have any ideas on this as a contagion vector ? Its exactly the same
as a normal .exe viral infect, but done on the fly to an outgoing buffer
that we can
pause and resume as appropriate.
I see it as very workable, the only problem is the need to detect the
negotioation made BEFORE an exe is sent - so our method would only
apply to IRC, FTP etc ...
For IRC it would be ...
o Intercept 'DCC SEND ...' (and modify reported length) of the Send
instruction (Protocol specific)
o Wait for remote hosts reply (Generaly the listening port to send to)
(Protocol specific)
o Watch the connection to that port as it is made, and modify on the fly
Not the easiest way to infect, but at least it cant trigger an AV
file-length watcher
on the local machine.
Forming a group to work further on this ...
I need C++ & ASM people to help with work on this aspect of my trojan code -
its getting a bit big for me to deal with now.
Of course, my full source (50/50 C++/ASM) is available to the coders helping
on this. on the absolute condition that this is an internal project, and the
sources
are NOT to be distributed.
If you are interested in any part of the project as it currently stands, or
you have a comment or suggestion about outgoing contamination of
executables,
*email* me - a PGP key would be an advantage.
cDc sucks cawk IMHO
M3DU54 +44