 Good morning. Am I speaking to loud for some of you? Hi everybody, thanks for coming to our talk. We appreciate it. We're going to have to think of something to say for the next 15 minutes to keep you all busy. We may get unstuck after 10 or 20 if we do, we're going to, I don't know, we'll find something. My name is Shawl, actually I'm not rule of taming or Harun Mir. Harun wasn't able to give this talk this morning for some obscure reason. And Harun, and rule of his, there he comes. Rule of his supposed to be here. So we're going to be presenting a paper which we've titled, Satiri Advances in Trojan Technology. Now Satiri is from, I should say this, we're from South Africa. We're from the 11 officially recognized ethnic groupings. So if you go to court for example and you have to stand trial, you can ask to stand trial in one of 11 different languages. And the government has to accommodate you. And one of those languages is called Swahili. And Satiri is the Swahili word for hidden, which is where the name of the Trojan comes from. Which is what we're going to be talking about. And before I do that, I'm supposed to make an announcement. Can everybody see that? Good. What I'm supposed to say is that this conference is being recorded on video and audio CD-ROM. And that you can get copies of the recordings downstairs at the aptly named recording sales desk. So if you want to buy a video of any of the talks that were given in this conference, or if you want to buy a CD-ROM, then you can get it downstairs in the Parthenon Fair. And there's some more. Speaker, please announce the following at the start and end of your talk. The next session in this room is session name from below. The speaker is down there at the back. I know what it is. I know what it is. It's on... Where's Mike? Where's Mike? Speaking next. No, not Mike Myers. So this is what we want to talk about. We're going to be speaking about Trojans. I think what I should say right up front is that our paper and the talk that we're going to be giving is focuses on what we call establishing a communications channel in a hostile environment. So it's not so much about the functionality of a Trojan. It's also not about the delivery mechanism. It's not about how we put a Trojan on somebody else's machine. It's about how having put a Trojan on somebody's machine and assuming that the Trojan has the functionality that you want to pop the guy's CD-ROM drive or look at him through his own webcam or anything like that, assuming that you've got all that, how do we actually communicate with that Trojan in an environment that's designed to keep us out? Like most environments these days are. This work is based really on a level research that Rudolf here did, assisted by his beautiful assistant Harun who's hiding in the corner. And I'm just talking because I'm the best looking. So those are the things that we want to cover. We're going to talk a little bit about why we have Trojans although I think that's pretty obvious. Give you a brief history of Trojans and the concept of covert channels. We're going to introduce a model that we've adapted for this communications path which we call a hybrid model. I don't know what anyone else would call it, but we call it a hybrid model. Then we're going to introduce Satiri. And unfortunately what we're not going to be able to do today is to give you a demonstration because we have no network connectivity which is really sad. The wireless is down, we can't reach it from here. Maybe we'll get it up before we have to get the demo. They're working on it. The good people of DevCon are working on it at the moment so maybe if we can get the wireless up in time we'll show you how it works. These guys only came for the demonstration. They're leaving. That's not nice. I think what we can do is we do have some screenshots, luckily, which we took so we can walk you through the screenshots and show you how it would work. This is an existing technology. We've built it, it works. We use it. So it's out there. But we're not going to be giving it to you. And then when we've done showing off, maybe if we have some more time we'll talk about how we would take this technology further if somebody threw tons of money at us to do it. A little bit about us. Rudolph and myself, hi, I'm Shaw. This is Rudolph and we're alcoholics. This is a different convention. That's not this convention. I'm sorry. We're from Saints Post. Saints Post, like I said, is a South African company. So we traveled just about 26 hours to get here. We planned to go home a lot faster. And it's about a 10-man company. There's myself, Rudolph, and I really make up about half of what there is. And what we do is essentially security assessments, penetration testing, a little bit of consulting work. We're not an R&D shop per se and we're also not a development shop per se. Object to this presentation. Why don't you put that in the slide for me? So why do you have Trojans? Essentially you have Trojans when you want to hack into shit. You have Trojans because you don't have another way to get into places. The development and thinking about Trojan technology was a bit of a new thing for us because essentially what we do best, I guess, is internet security assessments, looking at people's security infrastructure from the outside. And so typically in the work that we do, we would actually steer away from using Trojans. We figure you don't have to demonstrate the use of a Trojan to someone in order to convince them that Trojans are a real problem. But if you were a real criminal, if you really wanted to hack into a place, then a Trojan is certainly something that you might consider using. And we're talking in our business about the path of least resistance to the 2020 rule which essentially says that for the least amount of effort, I want to get the highest possible level of return. And that's something that a Trojan can get you. So without having to write custom buffer overflows or reverse engineer some proprietary protocol or figure out how something works at layer 2, all I need to do is get someone to run an executable on their machine. And if I then have a way to talk with that agent which is running on the computer, I essentially own the machine and from there taking the rest of the network becomes trivial. The weirdness in the industry that we see, and I guess it's not really that weird, is that security systems are all outward facing. So people put tons and tons of time and money and effort and energy into protecting the networks from attacks or against attacks from the outside. So you can manipulate your IP flag headers, you can reverse engineer the protocols you can throw just about anything that you want at them from the outside. My mouth is dry, excuse me. I wonder why. It's funny, I've been drinking so much and I'm still thirsty, I don't get it. That was funny, that was funny. Where was I? Right, so you can throw stuff and you can throw it at the firewall and you can give it as much as you want. And most times, most times you're going to struggle because outward facing defenses on your sort of standard corporate, advanced corporate network today are pretty sophisticated. But if I can get an agent operating on my behalf on the inside of the network and if I have some way of talking with that agent so I can tell it to do stuff for me and I can get the responses of what it does back to me, then I'm pretty set. Because once you're inside the network we talk about clubbing baby seals. We wouldn't really club baby seals. I rule of mind, but I wouldn't. And as I was very, very hungry I would not club a baby seal. But it's an analogy. So we speak about clubbing baby seals just because things on the inside of the network are typically pretty soft and easy. So a brief history of Trojans and COVID. I really can't remember any of this stuff. You had the whole thing with the city of Troy. It was being invaded, Aaron. Yeah, that's right. It was the Greeks. It was those skanky Greeks. Those skanky Greeks were trying to invade the city of... I'm sorry if anyone's Greek. I didn't mean to be offensive. These Greeks were trying to invade the city of Troy and that's exactly what they were doing. They'd been hammering and hammering and hammering at the front door of this fortified city and as hard as they tried they couldn't get in. So they devised this cunning plan. They had a plan so cunning you could stick a tail in it and call it a weasel. And so what they did was they built this beautiful big wooden horse. Huge big wooden horse. And they gave it to the leaders of the city as a gift. And what the people of the city didn't know was that hiding away inside this horse were a whole lot of really bad dudes. And as soon as the horse had been pulled into the city and the doors had been closed for the night the guys all jumped out and they massacred everyone. And everyone lived happily ever after. And Trojans have been around just about as long as computers have been around. So the concept of Trojan in a machine from a security point of view is not new. It's something we've all been talking about forever basically. And that's what you said at the beginning of this talk is what we've been looking at is not really developing the concept of Trojans or even developing the methodology or the methods and techniques of Trojans but concentrating on how I speak with that Trojan once it's on the inside. So let's maybe take a quick walk through the development of Trojans in different kinds of environments and as security systems became more and more advanced we see Trojans having to adapt themselves to be effective in those increasingly hostile environments. So in the simplest case you have a PC, a user's machine that's connected to the internet, maybe he's dialed up or maybe it's in the early days when the internet was still a beautiful place and you could just hook your machine up there and you'd get an IP address and you could talk out on the net. In an environment like that if I can get my Trojan to execute on someone's machine communicating with that Trojan is trivial. Now I can establish a TCP connection to it I can have it establish a TCP connection back to me I can send it ICMP packets, I can send it UDP packets I can do just about anything I want and there's nothing that's going to stop me. So that's hardly worth talking about. Then we saw the introduction of the firewall firewall essentially designed to screen internal hosts from malicious traffic originating from the internet. If this place is going to blow away will somebody just tell me? Because I'd hate to be the last guy standing here to nobody or you will rush out to save your lives. So with the introduction of the firewall it's no longer trivial for us to send packets to the Trojan. It's no longer trivial for us to establish a TCP connection to the Trojan. And so the Trojan basically has to become a whole lot smarter. So what are the kinds of things that Trojans would do in this kind of slightly more hostile environment? Well the first thing we can do is we can get the Trojan to do a dial home, which is pretty smart. So instead of us trying to establish a TCP connection to the Trojan, which we can't do because the firewall stops us in your earlier naive kind of firewall configurations we get the Trojan to establish a connection outwards to us, which is cunning because the firewall trusts the users on the inside so it allows the outgoing connection. Other things we can do is we can play around with the source and destination ports in the hope of taking advantage of some lane configuration on the firewall. For example, checkpoints 501 up until recently by default allowed TCP port 53 in. So if I have a firewall that allows port 53 in I only have to configure my Trojan to listen on port 53 and when they send a packet through. Another example is FTP. All the implementations of firewalls to allow the FTP reverse connection would allow any TCP connection from source port 20 to a port higher than 1024 to a high port. I mean we did that for years also because we just didn't know of another better way to do it. So if you could get your Trojan to listen on a high port and you could establish your controlling connection from source port 20 then you could just shoot way through the firewall. The assumption behind the rule was from system and firewall administrators was that there's nothing listening on high ports. But of course we can make our Trojan listen on any port that it wants to. And then we can do slightly more sophisticated things. I don't know how to pronounce. It fits through my concept now with my mouth being so dry. We introduced the concept called act tunneling where instead of trying to establish a TCP connection of a full TCP connection to AC and AC what we do is we just tunnel our entire communication session inside packets with the AC flag set. And on the other side, the TCP socket calls it simply pulls the data that it needs out of the AC packet without expecting it to have a SIM flag. And the reason why we get past the firewall there is because the firewall assumes that a flag with only the AC flag set is part of an already established connection. This is with your earlier more naive firewall implementations. But you still see this today. You see this kind of behavior perhaps with your basic screening routers. So basically even after we have a firewall installed especially on our earlier more naive firewall implementations we still have ways of talking to our Trojan by essentially exploiting naive assumptions that system and firewall administrators make. And if that fails, we can maybe get our Trojan to talk out to us. But so then the defenses get a little bit more advanced and you see the introduction of what we call stateful firewalls. Incidentally, my word processor was moaning about the spanning of stateful, putting like a little line in it and when I asked it how it thinks it should be spelt it said tasteful. So I speak under correction here. We're talking about tasteful filters. And what tasteful filters do is they start to take into account the context of a TCP connection. So they're no longer relying solely on the set of IP and TCP flags that are in the packet. They're basically looking at the packet history and they're saying if this is an AC packet coming back as part of an already established connection then surely they must have previously been a SIM packet that was used to establish this connection. And I don't have a history of this in packet. I don't have it in my state table. So I'm not going to buy that this packet is part of an established connection and the packet gets dropped. And that starts to cut out a lot of the tricks that we used previously. So we can no longer do AC flag tunneling, for example. We can no longer do the whole source port 20 thing because now firewalls are handling FTP reverse connections better. And so a lot of those options that we had previously where we basically stuff around with the way an IP packet or a TCP packet is put together, those things start to fall apart and one has to give credit to the firewall vendors for getting this right. So what would a Trojan do in this case? There's still those things we can do. For example, we saw Trojans, we saw the people that were essentially plug-ins for Trojans like back office that would allow us to establish control connections by posting to IOC channels. So if the firewall administrator is allowing IOC out through his firewall, then we can basically log on to IOC as the Trojan and send and receive information, communicate with the controller via IOC. And I'm going to give you some examples of that sort of thing in the next slide where we start to talk about tunnels. The idea behind tunneling is essentially that we hide or that we transport the data that we want to communicate within an existing channel that the firewall and the network supports. So typical existing tunnels that immediately come to mind are things like email. So email typically is allowed in and out of a network. That would be useful for a tunnel or DNS, something that's allowed in and out of the network. And the one that's really received the most attention is HTTP. We can tunnel stuff inside of HTTP. So what we do is we take our entire control session, the entire dynamics of the communications between us and the Trojan, and we bundle it inside what essentially looks like a standard HTTP request. And you can understand why that's a neat thing to do is because HTTP is going in and out of the network like there's no tomorrow. And the system administrator has no reason to think that HTTP traffic is malicious in any way. The concept of tunnels in the sense goes back, all the way back to 1985. In 1996, Frack Magazine did a, in fact, released a tool called Locky where they tunneled stuff inside of ICMP. So basically you can send ping packets and get ping replies. And although those are really genuine, do you guys say genuine here? Genuine? We say genuine back home. If somebody says something, if you say something amazing, the guy says really, you go genuine. So if you want to... Don't you? It's true. Right, ICMP. Oh yes, thank you very much. Jeez. We got a streaker. At least now I didn't have to do that. That was genuine. When our speakers said, please note there will be a streaker and I was a bit worried it was going to be me. But luckily I see someone else do that because you don't see me streak. Right, so you can ping something essentially and in those ping requests and ping replies we're embedding control data that allows us to manipulate our Trojan and get data back. Frack Magazine did that all the way back in 1996. Did I say something funny now? In 1998 we saw the release of something called RWW shell. Don't try and say that with a full mouth. And that was really the first of the tools that did, that effectively did HTTP tunneling where we took control data, any kind of data that you wanted and you put it in what was essentially a conventional HTTP request. So if you look at that using Etacap or... Not Etacap. Ethereal. Ethereal or whatever your favorite sniffer is what you would see is just normal web traffic. It would look like someone surfing the internet. If you look at the content of those packets you can actually control information. The concept developed further with HTTP tunnel and today you get commercial offerings things like Firethrough where I can load a little Java client on my PC and I make use of a tunnel termination server that this company offers commercially and I can pretty much put anything that I want through this encapsulation client put it into HTTP, I can even send it via my proxy I can even send it via by configuring a proxy and when it gets to the tunnel termination server on the other side they strip off the HTTP and they send out what the original traffic was. We do that all the time. For example to read your email using SSH when SSH is not allowed at the network I fire up this client, I configure it to tunnel SSH over HTTP and then my SSH to my machine to local host on port 22 that gets wrapped up inside of HTTP off it goes and then the other side gets taken out. So this is also not a new concept. The reason why Trojans having all this technology at their disposal the reasons why Trojans still fail is partly due to stateful firewalls and IDS we saw already how the whole direct model starts to fall apart with advances in firewalling technology we see guys increasingly blocking stuff off so you're just not seeing IOC go out of networks anymore you're just not seeing administrators allowing SSH out anymore you're seeing guys using and this is a clever trick you're seeing guys using authentication proxies and what does that mean? It means that in order for me to surf out of the network I have to go via a proxy on the internal net, right? But before I can use a proxy that proxy uses basic authentication and it prompts me for a username and a password and that pretty much flummoxes the Trojan because the Trojan doesn't know the username and password is so if you have authentication proxies that's going to stop cancelling out these kinds of tunneling approaches and then we see other things like personal firewalls personal firewalls see that the Trojan is attempting to establish a connection and it'll notify the user and say there's a new process, there's a new application on your machine that's attempting to open a socket and make a socket call, is that allowed and the user can then block that outgoing traffic Oh my, what is that? Alright So if you look at a typical network these are the kinds of things that you see you're going to see at the gateway to your network you're typically going to see some kind of net-based firewall something that understands the concept of a TCP session Inside you're going to have IDSs and virus scanners you're going to have maybe a content checking firewall that's actually going to look what kind of traffic it is but the content of those packets and see what is it that's going up and down here is this really a legitimate HTTP request that's being made on port 80 On the PC itself, on the end-user's workstation we're seeing increasingly the use of personal firewalls and personal firewalls are maybe not so useful to protect the machine from connections from the outside in but they can be incredibly useful in preventing something like HTTP tunnels because you're just not able to make a connection out We see the authentication proxy which I already touched on and a whole bunch of stuff which is really designed these days not only to stop us from making connections in but also to stop us from making connections out and in a well-configured network what you should see is you should see the user being allowed to send email via his preconfigured SMTP gateway or via his preconfigured exchange server he should be allowed to surf out via his authentication proxy and pretty much that should be it he makes his DNS requests via an internal DNS server and there should really be no reason for the user to make a connection out onto the internet at all Clearly in a network like this you can see how something like back-office or sub-server or net-pass is not going to work How am I doing for time? I have half an hour? Oh, cool I'm going to sing this presentation Right, so at Black Hat New Orleans which was earlier this year we introduced a technology which we have developed which we call Khatslag Khatslag and what we're going to do is we have some neat t-shirts here but actually they're not so neat we just have them left over and we don't know what else to do with them and we're going to give a t-shirt to anyone who concretely pronounced the word Khatslag Oh, you guys rock Well done You guys rock, well done So this one I'm going to give to anyone who can tell me what Khatslag means No, not you You didn't count What does Khatslag mean? Anyone? Slam on the butt Yeah, it's pretty close It's pretty close Yeah, if you were to translate it literally directly it's two words and they translated blowhole but that's not what it means So what they guys did with Khatslag is they took the concept of a tunnel and the concept of atrocious and they put them together but in order to defeat these control mechanisms that I've been speaking about what we did was instead of trying to make the HTTP connection ourselves we said we'll let us use the existing Microsoft Internet Explorer browser that's on a computer to make the connection for us and for that we use something called object linking and embedding OLE and OLE allows communications, control communications between different Microsoft applications on the same platform This is really the core of what you need to know here is that as we don't make the connection ourselves we actually use OLE to communicate with a browser and let the browser make the connection and that's got a lot of advantages that I'm sure Sean will point out to you I'm sure you will So what we're doing now is instead of trying to establish a TCP connection on port AT and do HTTP we're just using OLE to call the browser and we're having the browser do the HTTP for us So essentially how that works is that we fire up a browser on your PC using OLE and that's not... I know this term gets used a lot but that's not rocket science To use OLE you fire up the browser and we surf out to a web page on the internet which we define and in the title of that web page we embed the commands that we want the chosen to execute So in this model you have three components you have the execution engine which is actually going to do the commands for you and in our particular trojan that execution engine is relatively simplistic but you could have something really sophisticated like RFS doing the same thing That's the first component The second component is the browser which we control using OLE and the third component is the web server sitting somewhere on the internet and we want to contain the commands that we want the trojan to execute and it sends those commands down to the trojan in the title of the web page With the Khat Slach model we actually didn't use a web server we developed a pseudo web server in pull which emulated the behavior of a web server with obviously much more limited functionality and what you would get is you would get a little prompt on the server and you could type in the commands that you wanted you could create the web page the pseudo web page and put the command that you wanted executed in the title If we wanted to get data down to the trojan why would we want to get data down? For example, if I want to put a keylogger instead of me having to build the keylogger functionality into the trojan itself I download, I take something like Klogger and I simply send it to the trojan and I have the trojan executed on my behalf So I want a way of sending data down to the trojan To do that, we build the web page and we encode the binary in a form of encoding that Rulof developed and we send it down like it was a web page The form of encoding wasn't particularly sophisticated but it worked So you could then theoretically actually surf that page and if you did, you would see the encoded binary on the page and then using RLE you can then read that encoded binary out of the web content out of the browser essentially and decode it and then write the executable to file So using standard get requests we can only get commands we can actually get data down to the browser also If we want to get data up HTTP allows us to do that also using the standard HTTP post method So using HTTP post I can encode something and post it up just the same way that you would upload an attachment on your web mail client except that there's not really a web server there's not really a web page that you surf to there's this thing that's pretending to be a web server and for that we use the browser also I'm so running out of water I'm never going to drink so much ever again Why did it work? Why was Khatslach better than what we saw before? Apart from the fact that it was genuinely pretty charming and very good looking it did some of the following things We could use a proxy that did authentication because the browser already has authenticated itself to the proxy and there's two models for that The one model is NTLM which is Microsoft's proprietary authentication protocol So what you do in a Microsoft network to make things go seamlessly or make things go smoother for the user is you allow the user to login say to his domain controller once he's logged in all the Microsoft applications that require domain authentication can make use of that existing authenticated session So essentially what that means is when you're surfing through your proxy you're actually logging in you just don't know it because your PC is logging in for you in the background automatically and because we're using the browser and because the browser is a registered application on the machine which can make use of NTLM we bypass the authentication proxy The second thing we can do which is really, really sweet is we can use SSL and that's again, it's built into the browser we don't have to do anything clever instead of making our request to HTTP something we now make our request to HTTP S something and automatically that session gets encrypted and again it looks like standard word traffic your IDS is not going to see it your IDS can't look at the packet and we really don't have to go to any additional effort We can also bypass personal firewalls because what the personal firewall is going to see is it's going to see your browser making a connection on port 80 which is what browsers do so your personal firewall is not going to complain about it and it's not quite platform independent but within the Microsoft environment it's platform independent, why? because everybody's running IE well, most people are running IE what we also did in the hope of establishing some amount of redundancy and flexibility was we used the concept of a master and a controller and essentially what that meant was the controller was the host to which you would connect to get your instructions and the master was a pre-connection host which would tell us where the controller sat so the trojan when it fires up it first goes to the master and from the master it gets the IP address of the controller so we can move the controller around on the internet with relative ease simply by changing the IP address of the master so for example if my controller gets compromised because someone's been monitoring the web traffic then we can simply move the controller by changing the IP address in the master so they say a picture speaks a thousand words that's what it depicts how Khatslach worked on the bottom right-hand corner you see the victim and that's running the Khatslach executable which you have to get on his machine somehow but that's a story for another day then Khatslach is using the browser is connecting out via the proxy it's authenticating over NTLM because the user's already logged in that encapsulated web traffic is going out through the firewall first to the master and from the master we get the IP address of the controller once it's got the IP address of the controller we make a second connection again encapsulated over HTTP using the browser and then we send it to the controller where the operator sits and in the Khatslach model the operator is sitting there in real time and the program has to be running so you have to be sitting in that machine you have to wait for your trojan to log in register itself and once registered you can send it come on but you need to be there at that time okay so we done the whole thing but there were some pretty big problems with Khatslach it was cool and all but it didn't work that well I think the biggest problem was that the IP address of the controller could be obtained so that's not something you want to have let's say you trojan someone then if someone monitors with a sniffer the network traffic coming out of that machine then you can obviously see your IP address and this is not something you would want to have which is one of the major problems with Khatslach the second thing was you could trojan one person there's one instance running if you had multiple instances of this trojan running you had big big problems there was no GUI support this was essentially a command line trojan kind of thing and we know that people kind of like GUI like Shah said the controller needed to be online all the time you couldn't for instance batch commands together so you'd write one command and then you have to wait for the output of that and then write the next command and then wait for the output of that you couldn't have more than one controller controlling the same trojan and like I said the upload facility was really inefficient because the encoding that we used for files was really awful it really sucked big time we now have something that is more platform independent it can run on anything 95, 98, NT, ME, XP so it runs on a lot of platforms that's much more stable and works generally just works better the one thing that we also wanted to do was session level tunneling this would mean that you have a trojan over here a controller over there and a session to a secondary machine can be made through the trojan by Shah that's right okay, Shah you want to take it from here or? yeah just to comment again on what Rulof said that the session level tunneling is a powerful concept what we would like to have done with Khatslag is to give ourselves the opportunity to establish a fully functional TCP connection via the trojan to another host to an additional host and that's one of the things that we didn't get right with with Khatslag we also didn't get it right with Satiri so don't hold your breath so with Satiri the things that we did was we moved the commands that we want the trojan to execute away from the title of the web page into the web page itself so you now have a full HTML body there's now the commands that we want to execute and the reason we did that is to overcome the question of the issue of batching so now because we have a much bigger body that we can put our commands into we can send more than one command to the trojan at the same time and later when we show you the screenshots we'll show you how that looks and how we use that to track state between the commands that were sent and the commands that were executed we use, instead of now using a custom pseudo web server that we wrote ourselves and this was Rulof's very very cunning plan is we moved it to a standard web server so we now use standard Apache based web server and we just wrote a whole lot of CGI's on the web server to do the stuff that we want to do and that's where Rulof's point about platform independence comes in because now instead of you having to sit at the machine and enter the control connections over the console in the same way that the trojan browsers to the server to get the commands that you want executed you can browse to the server in order to control the trojan which separates you from the machine where the controller software is running the things that the trojan can do is essentially what we call an exec which is a DOS command so anything that you could type on your DOS prompt we can do with our trojan and in addition to that we can send stuff down and we can get stuff back up again I think the idea there was we didn't want to build trojans the idea was really more to explain the concept to see that bi-directional communications is possible so we essentially given a very reduced kind of instruction set that would be upload, download and DOS execute if you want to do something funny like log keystrokes or something like this you can write your own keyboard logger upload it there and run it on the machine itself essentially anything that you want to run on that machine you can upload and run it there you can have the output part to a file and then you can just download the output file so if you want to do a port scan from your trojan you download something like CBPS execute it, part the output to a file, grab the file you want to sniff, you download something like butt sniff they're all tiny DOS based applications you download something like butt sniff you can sniff, part the output to a file, upload the file so there's pretty much not a lot of stuff that we can't do and then also now because we have this fully fledged web server structure that we can use we can now make provision for multiple instances of the trojan and all that we've done is we've just given each trojan a special sub-directory within the directory structure of the web server where its stuff lies so the command set for trojan 1 is going to sit in sub-directory 1 and the command set for trojan 2 is going to sit in sub-directory 2 and in the same way when the trojan features files to download or pushes files back up to us it uses that sub-part of the directory structure and so we can easily, very easily keep track between different instances of the trojan so that's just to, oh hang on I've jumped the gun a little, that's okay so that's just to show you how that works you see now we have Satiri running on the victim's machine and we now have support for multiple victims so we can handle any number of instances of the trojan on different machines you don't have to have three computers on your desk they can all be in different places also I just put them all together so you can see them on slide sorry, just a sec okay so we've skipped ahead let me just handle this slide, I'll go back to the picture you'll remember that Roulou spoke about the fact that with Hutzlach, one of the big problems we had was that the IP address of the controller was traceable with whatever else we did if you go on the network and you look what was happening on the wire you would see our HTP or HTPS requests going from the victim machine out to the controller and the one possible option would have been to try and use some proxy server on the internet some open proxy the problem with that is we're relying on the proxy on the internal network to get our stuff out in the first place so we're not able to configure we're not able to configure an additional proxy so the concept of using some proxy on the net to hide our traffic was unfortunately not available to us so what we did was we used anonymizer and what's needed about anonymizer is anonymizer is not configured as your actual proxy server it uses application-based proxying which means that you surf to anonymizer and you embed the actual URL of the website that you want to go to in your get request it's really quite simple you say those of you who use it will know you say http s www.anonymizer.com slash and then the URL that you want to go to so your traffic is going via the internal proxy out to the net and it's going fully encrypted to anonymizer and anonymizer is going to forward it on and tunnel between you and the actual destination we don't have to configure a second proxy so now what we have is we have SSL from us to anonymizer we have SSL from anonymizer to whatever the master sits and everything including the IP address of the master is hidden it's completely out of sight and the only way that you could get it out is by legally forcing anonymizer to give it via some form of reinforcement agency Karin, can you give me some more water please? Okay so on this picture here you can see what actually happens the connection is made via the proxy server out it needn't go through a proxy server of course it can just go directly as well and the picture that we have here we just show the proxy server in there as well so it can go through the firewall it hits anonymizer so if you look at the destination IP address of the packets going out of your network you'll see that it's going to anonymizer and it's not going to the controller itself you won't be able to see where it's going from anonymizer it goes to the controller the controller can be totally hidden away anyway and the operator then has a CGI interface to the controller to basically put files in there to upload files, download files and to execute commands and we'll have a look and see what the actual web page looks like in a while Charlotte is just sorting out all these water problems I just want to point out two additional things from this picture that I think are significant the first is you'll notice that the operator is no longer physically associated with the host he sits somewhere on the internet and essentially browsers to the controller to control the Trojan the other thing you'll see is we now have the facility to handle multiple operators so via a single server we can have control via a number of operators over a number of different Trojans is it also a custom in your country to drink Gin at 11? or is it just where we come from? okay, we've done that but there's the interface I think Rulof you can... okay now, this is the controller's interface to the Trojan on the left hand side, on the left frame you'll see that there's a couple of commands that we have entered there we can enter as many as we want it gets executed in batch mode which means you can always go back to the previous command to see what the output of that would be on the top, the frame on the right hand side on the top is for entering the commands that is for actually browsing your own file system your own file system to actually upload files there there's a drop-down box list there with some various different commands it's in the paper that's on the CD as well and there's parameters for instance, one of the commands would be exec and the parameters would be address command door, IP config, set, time minus t, slash t anything that you want the middle frame there is the output of such a command it is linked with the frame on the left hand side so if you click on any of the commands on the left hand side you'll see the output in the middle frame the frame at the bottom is basically just a direct review of the specific instance that would give you the capability if we can go to the next slide that gives you the capability to view the files that you actually downloaded from your victim directly in that frame be there there a doc file or XOS file or something like this it means I can click on it right there and it displays it in that frame but I need to save it to disk and go along with that next slide okay, this is on the left hand side I'm sure the people at the back there can't see a thing I've been in the back there as well and basically you have to look on your CD for this what happens on the left hand side there you'll see a page that is actually the real web page that the controller is pulling down it contains the commands separated by a sequence number well it's a sequence number then it's the command, then it's the parameters additional parameters in the time that the command was actually input given to the system separated by hashes it's just easier for me when the Trojan actually gets the page to extract the commands and the time from the fields because it's separated with an hash I'm just a lazy programmer at the other side you'll see there's a capture there from ethereal and on that slide you can see that there's the machine is actually only going out to anonymizer you can't see the IP number of the real controller okay so let's just to recap why do fences fail we allow our users to serve the internet right in network you're allowed to serve the internet if you can serve the internet then this Trojan will work against you if you look at content level staff ideas what I'm sending out is a perfectly perfectly 100% stable HCP request and reply coming in and out I'm basically configuring a browser to browse a site and do actions when it gets to certain parts of that website so if you can serve the internet if you can browse that site then obviously the Trojan will work against you your content level filters and protocol filters can't find anything wrong with normal HTTP because we slap HTTPS because we use SSL your ideas basically just won't work your ideas can't lock onto any ports because we're using normal ports we're not using funny ports like 1, 3, 1, 3, 3, 7 anything like that we have SSL on there personal firewalls is also just a little bit of a waste with this because you probably configured your personal firewall to allow IE to go out as well so it's not a foreign application that's making a request somewhere but to mine if the user can serve the web this thing is going to work against you okay the solution to the problem the big thing that we didn't talk about was delivery delivery is up to you at the end of the day if you can keep nasty out of your network then you're going to be safe against something like this we talk about a concept of whitelisting you know in packet filters you basically in packet filters you don't say deny this, deny this, deny this and allow the rest do you? you don't you say deny all and allow these few ports to go out correct? okay so do the same thing with your websites tell the people at the company they can serve to cnn.com and to abco or whatever .com and the rest are blocked that's called whitelisting that's a solution to this problem user education, the old kind of thing education uses if they get attachments that's basically the whole raw kind of I think we're finishing off here because we're running a little bit late I think one of the things that we really wanted to show here was that we don't have a big budget we don't have budget for us we don't have motivation for this other than speaking at Black Hat and speaking at Defcon that's our motivation for creating something like this so I think if you have a team of programmers that's more motivated with a bigger budget and you know more time they could probably build something that is crazy it's probably going to work on the same concept but it might work a lot better it might be embedded in some of the tools and systems that you know Word, Excel, you know that kind of thing so our motivation really today was just to make you aware that it's possible to write something like this it's out there, it's alive and it's kicking thank you very much thank you the next speaker is going to be Michael Shrank he's speaking on Wraped Spiders he's here somewhere and we were told that we can give some of these goodies away so if somebody wants something that's here you can have one thing it's right up front, there's a keyboard and I think this is a tape drive and a xyplex something nice talk, you got part am I supposed to give them all away? just one thing we also ask us if there's any questions we'll be around the pool area the first pool so if you want to ask any questions you can meet us there and we'll answer some of your questions thanks guys