
okay so I guess I'll get started my name is Kevin McNamee and today I'm going to talk a little bit about cracking command control protocol of a peer-to-peer botnet I work for a company called clean site and I'll give you a very brief introduction to what kind site as one slide and then I'll go straight into the the rest of the presentation the basic agenda for today is as follows there's also if you want you can get a copy of the paper that this presentations based on at the the URL just over there I believe it's up there at the moment so a little bit about kind site we're basically a company we're owned by
alcatel-lucent founded in 2007 we've offices in Mountain View in Ottawa Canada I'm from Ottawa what we basically guys are security analytics platform that service providers deploy in their networks and the platform allows you to do security analytics allows them to run a malware detection service and also we've got a new offering we're currently just announcing actually this week which is a mobile security offering the basic components of the system which are sort of relevant to the talk are we've got a snort based malware detection sensor that the service providers deploy in their network and that basically monitors traffic it's a snort based intrusion detection thing it's got customized signature set that allows it to look for malware infections in the
residential network residential subscribers so that's the game plan they also there's a security analytics engine they'll run in there their data center so the sensors feed information into the analytics engine and and that's you know that's how that's how the service basically works there's also a remediation aspect they can bring their subscribers into a portal and I'll take care of fixing the infections we find so the basic gist of it was the impetus for doing this the planning of this botnet came from the fact that we've got were deployed in these carrier networks and we have visibility into seeing the network traffic is and also part of that is we have to we're very concerned about false
positive so as soon as we see anything strange in the network our research team gets on it right away to makes it sort of find out what's going on and make sure we're seeing valid infections so that's how we came to sort of discover this this botnet okay so excuse me the key to the malware detection service is the basically the signature set that's deployed in the devices and we update the signature set basically once a week in all the sensors we have in the network and then we monitor very closely to see if things are working properly so as you can see in this here we deployed a new signature set and you see this
sort of big big spike in the in the infection rate this sort of got our attention sort of right off the bat we don't normally like to see stuff like that because it usually means something's wrong with the signatures rather than you know sort of a major event as it turned out in this case there was sort of an unusual it was a new signature the signatures snort signature shown at the bottom of the screen here and what it was telling us is it was telling us that there was in the home net which you see over here we had with 300 infected users in the home net which is the network we were monitoring communicating with about
60,000 peers on the Internet and that was sort of a fairly unusual pattern for us to see but it was a pattern that did indicate that it was potentially a peer-to-peer type botnet and a sort of a centrally controlled botnet we typically see lots of users talking to a few servers instead of a few relatively small number of users 300 talking to 60,000 peers out there in the network so that indicated it was a peer to peer never so the first thing we do when we we saw this I'll give you some other things we've been looking at this since basically December we've seen connections to over five million computers out here on the internet from
this particular little network here just to give you an idea the scale of this this thing okay I know the signature down here this is actually the signature comes from emerging threats and we use that that those signatures are very good it's actually quite a good signature as you notice it sort of got if you look closely at it it's very specific in terms of the length of the data packet and the location of these hex strings that it's looking for okay so it looks like a pretty good signature but it's got these ports as an e an e so this is looking at any TCP traffic that's on there so that is a bit suspicious so we
had to go in and make sure check for false positives first of all so we looked at that and when we retrieved some data from the field we found out it was only specific ports were being used and the port service that have listed there the the initial packet was almost twenty bytes long and the Arians she can sees that have been read in the packet there they were always the same I was identical and the peer and the internet responded with a packet it was always again the same size and it was very common fields in it so we looked at this and we came to the conclusion that well first of all it looks legit because of
the limited number of ports that have been used and second of all it certainly looks encrypted because of the characteristics of the data and it definitely looks like a peer to peer so we asked the question what is this malware right if you go back and you look at the signature it wasn't very hard to figure it because in there it says the signature comes it's called the zero access malware so we knew right away what it was so then we want to verify it our customers is going to come to us and ask us what we're seeing so we did a little bit of research went in Google and googled for zero access and
we find a really good report on the zero access malware itself from a number of sources but one of the good ones we found was from prevx but when we looked at that analysis of what zero accessed it's your axis is a rootkit that carries itself in the window system conceals itself and it's used to distribute malware but there was no talk and there was no discussion and the the malware report there about a peer-to-peer protocol so we figured we'd look a little bit deeper into it and see what what was going on there okay by the way if anybody's got a question askers we're going along feel free to jump in just raise your hand wave it around if
I'm not looking at you and we can answer any questions as we go so basically we saw this unusual traffic pattern we realized it was probably related to this zero access rootkit and we wanted to sort of look into a little bit deeper to find out what was this funny traffic it was generating well where did that come from so the first thing we had to do was find a sample to analyze now at clean site Security Labs we've got a collection of about 10 million malware samples but more than just the malware samples we've also currently got about 800,000 pcap files that are associated with those samples now that's less than 10% but we're working to get a bigger
library of pcaps as we go along we get the peek apps basically by deploying the samples in a sandbox watching the network traffic sometimes you have to tickle them a little bit to make them generate traffic but that's that's the game plan anyway so we've run these which at all of these 800,000 pcap files ran them against our signature set this one signature is the the one that triggered and what we found is we found 15,000 samples trigger this signature I expected to find maybe a few hundreds but that was very large number and the interesting thing was that often everyone's familiar with the fact that all the antivirus companies call things by different names you've got literally
hundreds of thousands of different samples are all really the same thing just repackaged but the interesting thing here was that the the names and the sizes of the various malware samples were very very different so we sort of fact that what this is this malware that we're deal with this this protocol we're dealing with it's actually being used and it's bundled with a whole bunch of different malware so it's like a common components like a building block people are using to to do this malware distribution as you'll see in a few minutes okay you can see over in the far side of the screen that's just a sample of some of the names these by the way
are names that come from virustotal okay so we take their samples to run them through virus totally give us the list of names so it's basically what the antivirus companies are calling it okay so we just wanted to look at what the protocol was so from that 15,000 samples we pick one because that's all we can sort of do it in depth analysis of it at any given time and so what I'm going to talk about for the rest of the the session it's what happened when we did the analysis of that sample there's some details on it there's also if you go to the get the document offer blog the links will be links to the virus total
and thread expert on this specific sample and the md5 is in there too if you want to anybody what Andy's interested so basically we took that particular sample and we loaded it onto a Windows 7 virtual machine and we just executed it manually just waited to see what would happen of course we'd all sort of ready to capture traffic from it everyone's all sort of ready to go and observe what's going on the first thing there was two phases in the infection the first phase I don't think is really related to zero access at all but the second phase seems to be because this first phase doesn't involve any rootkit the things raid out in the open and it's
just doing whatever it's gonna do so the very first thing it does is it creates this trace the directory and the the C Drive and the guy is really sort of who wrote this he seems to be very into hexadecimal because he's got this well your city's hexadecimal strings and various names and directory things all the way through it so that's sort of a characteristic of it anyway in there it created two files one file very creative file name okay one file was called X and the other was called @r the @ sign okay so the very first thing it did was it created these files and then it created an entry in the winner basically making X the win
logon shell so now this X is gonna be run every time you boot the system just did that right away so when X is run we took X and loaded into a debugger to see what it would do okay and it's really quite straightforward but what it does it basically injects a copy of a copy of the malware component it injects it into the Explorer dot exe process and I wasn't really that familiar with how this stuff was done so I was little learning as I was going along here but Microsoft provides a beautiful API for injecting code into various processes that you want okay you start off you do this open the process so opens Explorer
dot exe it basically allocates some virtual memory I mean this is a process running over here it opens a connection to explore dot exe and allocate some memory over here using the virtual memory allocate it takes it's a copy of a shell code and it writes it into the virtual memory and then it says go and execute that thread it's really neat I was I was quite surprised that it was so easy to do that what the shell code then does his own impacts that's peer to peer module which we then studied in a little bit more detail ok once it was running in Explorer dot exe the next things that what happened was open this file called
the add file what the add file contains was a list of IP addresses okay and it was a list of 256 IP addresses thus the malware running as a process within my my Explorer process went through connected to all of those peers are attempted to connect all of those peers and as it turns out once we decoded what it was doing and actually each of them returned a list of their 256 peers that were also that they knew about so this was this mechanism for basically figuring out who its peers were in the network okay once it and it used it did that using this get L command of course was encrypted but we figured that out later the next thing it
did was that then went to the very first peer that responded okay and it downloaded a whole bunch of files and it stored them in this directory in this this u directory over here it created in that subdirectory it created a directory called you okay there's a little picture of it down here and it dropped a whole bunch of malware files in there and I know their malware cuz we took them we ran them against that virus total and virus total told us all but what they were okay and it then executed those some of those things did different things I'll talk a little bit in the next slide of it where those those actually did the malware then repeated
this about every 20 minutes so every twenty minutes that wait up that go out and check who it was talking to in the network all the various peers update its list of who's currently active and check to see if there's any additional malware to download so that's basically what it was doing the additional effects that this is the malware that it downloaded there was some nothing really that dangerous and the that came along with it one of them for example this malware called in the name you know eight hexadecimal eight zero zero zero zero zero at sign that was that's the file name that was used and what it would do is that wake up about every twenty
minutes and it sends I get requests to this this this website this web server okay and actually all that did was return a little gift file and actually copied the Jeff out of the the pcap file it was returned and that's actually all it was so I think what this is doing is just trying to check in this being counted it's saying I'm here I got this machines infected but I never actually traced this any further because it did it seemed I was more interested in what the protocol was doing one of the things that was interesting about this particular thread when we traced it was in the debugger there was debug code that was actually enabled in the mouth
so if you looked at the log within the the Olli debugger that we were using the malware was actually logging stuff in there as it was going along to debug messages and you can actually put breakpoints in there when you if you've used the pods on debug string so if you're ever doing any malware analysis the guy that programmed that might have left the debugging code still in there so you can take advantage of that and see what worth looking at I didn't think it would be that simple anyway the second thing it did was this is an it was a click fraud scheme and basically this was another one of the other malware files that were downloaded
it's got that name up there and every 50 minutes it would wake up it issue again to a specific URL and that would downloads basically a configuration file which was a bunch of other URLs which were starting points for an ad click fraud then this particular malware would then go through and it would basically go to all of those websites and it just basically you know go through you know through all the various links that I could find clicking on stuff so the assumption being is this is an ad click fraud it would wake up every 15 minutes and another list of starting points and then it would take those and go through and clicking all those so that was what
it was doing again not really that damaging to the system but the idea for this is that you when it owns the system and it just sits there and it makes a little bit of money by clicking on things in the background doesn't really try and sort of disturb what the users technical experience would be wakes up quietly every 15 minutes and does this thing um so well all that was taking place there was the second phase of the infection and this part I think is related to the zero access rootkit because this was a little bit more nefarious in terms of what actually did to the system okay I was quite surprised actually it was that I
didn't realize that the the sort of the exploit it was trying to use here but what it did was it leveraged the fact that you know people are going to sort of give things like Adobe the Adobe Flash Player they're willing to click on a button to say yes I want to install this software and it used that to get itself enough permissions to actually build the rootkit environment that I wanted to do so the first symptom you saw this is that probably come up a couple of minutes after you installed it you get this little pop-up here okay and what it's saying is do you want to allow the following program to install to be completely honest when I saw this
the first time I said oh [ __ ] I shouldn't have left the Dolby running because now it wants to update itself it's gonna screw up my pcap file ok and I clicked ok but it wasn't Adobe it was the malware what it done is it it actually went out and downloaded a legitimate copy of the Adobe installer unpacked it dumped it into a temporary directory in the temporary directory it dumps in a copy of this MSM age 32 DLL a corrupted copy of that and then it launched the Adobe install program now the way that dll's get loaded as it typically loads dll's from the working directory so when I clicked ok for the
dhobi to install it loaded the corrupted infected DLL from that directory and then I was I was gone I was completely owned by the the malware ok when this thing in this malware now had the permissions that it needed to build the rootkit environment it created a hidden partition in the hard disk it installed a shadow copy of remember that command and control protocol we're looking at another version of that this version ran on port 2 to 292 the other one that was in the open that was installed in that that you know the other directory it was running on - 1 8 100 or something like that so it was just like at the same command and
control but a separate instance of it on a separate port but exactly the same protocol yeah
well I went i saw this and i said why better I'm gonna check so I clicked on the more information and verified the certificate so I verified that certificate and it came from Adobe this is the dhobi Flash Player is being installed so that's that's why he do it it's social engineering I honest honestly the first time I did this I honestly believe that that was Adobe and it got me but it was good that it got me because then I got to find out what it was doing um now the thing as this has been reported to adobe and they've fixed it up I think this must be some way that you can say don't load stuff from the
current directory and so it no longer the the when I try and do this run this piece of the malware back in the in the lab this part doesn't work anymore all it does now is installs Adobe which is a drag but anyway so the difference is is the the first one then phase one it attached itself to explorer.exe and ran on port 2 1 8 100 in this case it attached itself that a system process which is PID 4 and at Liston listened on port 2 to 292 so it's a completely separate instance in this case the file system where it put the malware files that it downloaded and where it keeps the app file and all the rest of that
there in a hidden file system within on the C Drive somewhere okay there is by the way if you want a little bit more information on that way of using leveraging an existing application installation process with a signed app to allow malware in you can look down McAfee is actually a pretty good paper on it and there's a link there at the bottom if you want some more information in that
what this also does is there's a watchdog this particular piece the phase two creates a watchdog process that runs and again there's another interesting link here you can look ABG and they're their threat report for 2011 they looked at this in detail and they came to the conclusion that this this extra process that shows up is actually a watchdog process when I tried to attach my debugger to it they killed my debugger and deleted it [Laughter] anyway so it's kind of a tangent it was sort of interesting when stepping through this it was good it was actually good fun it was a enjoy to some of the files that were created just briefly it's all malware right there was files
downloaded on the first day that's these for these ones here these were the ones that were responsible for that subsequent activity these ones down at the bottom here they were downloaded on a couple of weeks later so the malware was actually you know you could see it refreshing the files and downloading new stuff and the ones down here look like they had it was actually DLLs with embedded JavaScript I think what they do is they attach themself to their browser and do sort of redirection and stuff like that so they were kind of interesting too over here in this column here you can see what virustotal thinks of them and it's all malware this table
by the way if you've interested it's in that document I refer to on our website on our blog the other file it's download as this @ file which is the IP addresses it's just encoded and basically assists binary so this it's got an IP address and then as a time it was last active IP address time it was last active and it just repeats this file by the way it's not encrypted it's only encrypts it once it quits it on the wire okay when so when someone asks for send me your current list of IP addresses and then encrypts this and shoots it over to the to the peer on the network okay so by the way what time is it just
to give me a check 10:24 cool so I promised I would talk a little bit about how we cracked the in the basically encryption of this and to do that that was a little bit more tricky than just I mean that's worth describes so far it was just stuff that was happening to this you know it was reinstalled it knows as the things went went a bit he he were so what we had I thought the best approach to cracking the encryption was to get something that was reproducible I didn't just want the mouth sitting there shooting stuff at randomly every 20 minutes and stuff so within any peer-to-peer type a network each Davichi entity has both a client
piece and a server piece so what I figured the best let's try and execute you know exercise the server piece of this best malware so what I did is wrote a little C program and what it did is it connected to port you know 21 8 100 and it took that 20 bytes of data that was common in our segment all our signatures and it sent it to the port okay and of course our little malware responded with its list of IP addresses that was kind of cool and so notice that was pretty good so the next thing to do is basically we used the Oly debugger and attached it to the explorer process we
could tell that was the Explorer process because that was the process it was listening on the port so it was fairly straightforward now and then basically put some breakpoints and to try and figure out where the encryption routine was and what we're looking for basically its encryption keys and stuff like that and I can tell you that this is not a trivial task if something attaches itself to the Explorer process because that's basically the process that runs your desktop and anytime you move your little mouse out into left field that can do really weird things there's also so threads running in there and they're jumping up and down all over the place so it was a little bit tricky but
basically what we did is we isolated where the malware but the malware thread was in the process and then went through that and looked for function calls to look for where where was it calling it was obviously calling a socket interface to do the the network i/o so we we located the various socket functions within that and put the breakpoints there so we have breakpoints at all the various socket calls we throw in a packet and wait and see what happens and then from that if one of the breakpoints trips we then go through and trace it as far as we could until we sort of lose you know the thread terminates things disappear anyway it took a few days but eventually
we allocated we figured out that this particular little routine here was the actual the one that was called to do the encryption and decryption and we basically if you go back you can sort of see it you can't see it clearly but it's just basically some whole bunch of moves and stuff the key thing is at the bottom it says that XOR instruction down there that's the thing that actually does the the actual encryption operation itself the rest of its just basically getting a byte that it's going to XOR with it so we've reversed engineered the algorithm I said this is just the part that does the the actual physical like doing the encryption but before that it did a
number of things the first thing it did was it first of all initialized the buffer which basically meant that it moved then had her into the buffer and it moved the data and so it had the basically the clear text stuff in memory the next thing it did is it compute computed a CRC so it did that and then what it did is it called this other function that we didn't know what it did at first but basically what this other function did was it built this array of 256 bytes okay and as it turns out this byte array was the initialization for the the the for the the data it was going to use to do
that XOR to accomplish the encryption of the decription okay and it turns out that that array was it was created using an md5 of this hex value here okay for some reason and so this actually turns out to be the key this isn't any normal encryption algorithm by the way this is something the guy that wrote this malware I think he invented it himself I mean it's not very good encryption her but it you know missus he could have probably used like base64 or something would have been just as effective but anyway see you take this this value here this is basically the key you feed that into this function here a net byte array
and it goes out and creates this 256 byte array of sort of random bytes okay and then it calls this the script routine what effectively does it's actually a very sort of a naive stream cipher so every time basically but it does that for every character in the clear text it gets a bite of random byte of data and XOR sit within it just keeps doing that and as it turns out the way this algorithms works out the the the byte stream that is used to do the XOR ring terms are always to be the same regardless of what the input data is just as it's all based on this one key so and you'll actually find out also
this key is stored in the header of the packet encrypted of course but so you can always verify that if you've got the right key because the since it's always the same byte stream it's always the same bloody value you know so I said it's not very smart but it was you know it was fun to figure out here I remember years ago when the first presentation I ever gave died I knew fairly well and respected told me never show code I couldn't resist this is the this is the encryption decryption algorithm which we built based on based on that gobbly [ __ ] down there we got it into this thing here so the red stuff there that's the byte
array that is always the same and it's always generated and it's generated from that key value okay and it's just done and 56 relatively random bytes the little blue section over here is the actual encryption routine itself and what it basically is doing is it's going through I'll take it'll take a value from here someplace and now we use that value to pick up another value and then old switch them around in other words it keeps changing save this table here it this table here gets changed as the encryption process was on it keeps swapping values back and forth through it and then it takes eventually it you can see down here it does this XOR and that's what does the
interruption so that's basically the whole the whole encryption algorithm okay again it's not very it's a pretty awful encryption algorithm for anybody I'm not really a cryptographer per se I don't know much about it but I do know that this is since the byte stream is always the same I mean it's open to plaintext known text attacks don't disturb ever and the figure in this one it was fairly is fairly simple and trivial I mean even if you change the key it's it's a no-brainer to sort of decoder now we didn't break the crypto algorithm by doing any crypt analysis we broke it by looking at the code as I said I don't know how to do crypt analysis but I do
know how to look at code okay so now we get to what does the command and control protocol actually allow us to do and the command format is shown here the first thing is we've got the first four bytes is our key which will be encrypted always to the same thing the next four bytes is this CRC and then we've got a four byte command a four byte length and then we've got a variable length data okay so that's that's that's command we then went through and figured out well what are these various commands so we looked at the code that actually decoded the commands and it's down here it's a bit weird looking as it turns out these
are the commands here and their commands are coded in ASCII okay and they're sort of reversed because it's a Windows machine so it's a Intel machine so it's little and ian's so the numbers are all sort of in Reverse but basically this is get F get L and SRV question mark those are the only three commands this botnet has literally commands and we're like it's like the the peer is asking for stuff so you can say get get F is get me a file get Ellen's get me a list of IP addresses that you know about and SRV says tell me all the files you've got and it's that simple that's that's that's it's very rudimentary that's all
this thing that thing does the actual decode routine in the when we looked at it this is it here what it's doing is it's actually subtracting off these values a colleague of mine suggests that this was just it wasn't that the guy coded it up this way this is just be a compiler optimization it might be that but I didn't think compilers were that smart but they might be but it's a bit weird this just takes this byte value it subtracts it off if it's zero that means it must be this command they then subtract six from it and if it's that it must be this command and finally I subtract says funny value if it's that
and it must be this command here I just thought it was a bit strange I don't know much about compiler optimizations but maybe that's what it is so that's the general format of the command so here's the command specifically when you do the get L this is the key thing for finding out who's my peers in the network who else can I talk to okay um so when a peer response you'll respond with a list of IP addresses and they're there the format of those is down here and at the bottom so the basic gist of it is is that it issues this command and when the peer responds the heck they go to respond but a header that's exactly
the same except this will be instead of a get L will be a set L and then the length will be the length of the the return data and then the actual data will be in this format here so there's a number number of IP addresses which in this case was always 256 and then you have an IP address for bytes okay four bytes actually a network order then at a time value and the time value I believe when we sort of looked at it looks like the time that that pier last responded seemed to be based on a time starting in 1980 or something like that I'm not sure why I was expecting something like 1970
or whatever but it's a sort of a strange time value but it certainly is the time because as you as they're updated you can see this this thing so and that information when it retrieves all this what the bot does is it goes out and gets all this information from the various peers that talks to and it uses that in some way that I didn't figure out to update its at file its at sign file the one that's got the list of so it kept that up to date and then when some other peer contacted this one it would then spew that back out so that's the way he kept and sank as to who was out there and the
strange thing was is although would be when one infected host might talk to hundreds and hundreds of other peers they would only keep 256 the latest 256 so I'm not sure how it figured out how to do that but it seemed to the next thing was the get F command which is the get the file and the it's basically the same thing thing you don't get F command you'd the length was always four and then this piece here was actually a hexadecimal number and that hexadecimal number was then translated into ascii and used as the basis for the file name okay all of these files were stored in the directory this one under the sub
directory you and you can see how the file name would be constructed so it basically took the hexadecimal value and it added a dot @ on the end of it you know why chose this format I don't know but it's obviously that's just the way the the guy decided okay any questions yeah I can't hear
the question is were we able to send commands to different peers and the answer is yes we actually sent commands so to test how this was working to various peers out there that I can't hear no it didn't appear - it seemed to be quite happy just to do its thing no self-destruct we did not only that we see a little bit later on actually sent the get l commander to peers collected the IP harvested the IP addresses and to map the bots now ok so we did that too and it seems pretty rudimentary and there was no sort of other special things that it did so this was how it downloaded files when the file come back
when the peer responded with a file this would be instead of get F it would be set F the length would be the length of the file and then the data would just be the binary the encrypted file right witness indicates is that the way the malware works is the files have to all fit in memory you couldn't download really really large files because they have to fit inside the process memory you know so you can imagine if people were distributing very large malware this this mechanism probably would be problematic the SRV command is basically a mechanism for the bots to ask its peers what files they have ok and this was basically just the length is always four and what would
happen is the peer would return this is a sample of a buffer and the first basically if I had are the same as this and then the length would be the length of this buffer and then the data would be what's shown in here so here you've got basically it's got the first number is an 8 0 0 s an 8 so there's 8 files in the list ok it's then got file the format is basically file name file creation type file name file creation type the file names are coded in that hexadecimal but if each file name is a for an eight digit hexadecimal number which is encoded in binary here and then the creation time is basically again
from that strange time 90 80 being the base as far as I could tell okay there was a couple of weird things that we we did we first of all use the SRV command on both remember we two versions of the malware running in the one machine ones running on port 21 8 10 the elements running on 2 2 2 9 2 ones using a file system we can see the other ones using a file system we can't see I no way of figuring out where that was storing that it was all encrypted under this some place didn't know where it was but we could use ask them different questions so we for example we didn't
know that the file names and both of them were the same but the creation times were different obviously since the malware started and stopped at different times when we deleted a file in the visible system we could see it disappeared from the SRV list on that on port 21 8 10 but not on the other port so we could see it was definitely a different file system we weren't sharing the same file system and you know so that was interesting so the next thing we did is we tried to drop additional files in there ok now this is really weird when we dropped a file in there we could use the get F command to retrieve
the file from from the infected machine but it never showed up in the SRV command so we do an SRV commit give me a list of files didn't didn't see it but we could retrieve the file so we thought that was a bit weird so figured maybe we'll trace that through so I actually traced through the code and we found in the actual code that there's a piece of code in there that it when it was going through that directory list going through each file one at a time it retrieves the creation time and if that the microseconds and the creation time is nonzero it skips the file and goes to the next one we wondered why
what we think is that this is a mechanism to prevent accidentally distributing files so if you want to distribute a file you have to put it into the directory drop it in there and set the microseconds in the creation time to be zero and it's only then that that peer will tell all the other people about that file I know it sounds weird but that's that's what it dykes if could hardly believe the that was doing that but that's what it did okay so having played around with the various falls the next thing the next thing we decide to do was map the botnet as I said at the beginning on a live network we saw a
live us up with 300 computers then the network we were monitoring we're talking to a whole bunch out in the internet but once we broken the the crypto we could then go out to all these hosts and we could ask them the question what IP addresses do you know about and they would respond and we could decrypt it and get that list so we wrote a little program that basically did that recursively and I'm gonna have to learn how to do multi-threading socket gosh because it because most of the ones that it gives you don't actually respond they're not quite active they've been shut down or whatever so and when you're trying to make a connection to something
that isn't there you have to wait like at least three or four seconds to find air so it took a long time after about 24 hours we'd found about 21 120 thousand different infected machines out there but it so I think I'm gonna have to go back to the lab and learn how to do multi-threaded socket calls so I can speed up the process yep
oh yeah how did the Machine get infected in the first place typically if you go right back to the the the sample we looked at it turned out to be something about hot animal XXX whatever so I imagine people download it and to find out what that's all about that's it we just sort of installed it and ran it but I'm sure that you can probably get it in the standard ways that you can maybe so another thing is because this this protocol is so common we've seen in a lot of different types of malware it could be that you get infected with something else and it downloads this as part of its scheme so I think there's a
lot of ways to get infected with us ok yeah
that's yeah that the comment there was when looking at hosts that don't respond we should just sort of keep track of that and check them later on that's that's a good point the bottom line is since we've been looking at this since December and we've seen it as I said at the beginning but five half a million connections to unique peers half a million infected machines out there did we try - no we didn't do that with this many they seem to be fairly ready it's all there all over the place and by the way this was this five mill we were looking at this from the sensors were using to get these stats from we're
looking up a network that's got about 150,000 users and off those about 300 or something we're in fact that so this is 300 computers talking to half a million so it's so what's the purpose of the botnet it's simply there to distribute new malware and update existing moer that's all the only purpose I can see to this the botnet owner doesn't there's no command to tell it to do anything the botnet owner simply drops files into these directories sets the time properly and then the distribution is automatic okay so that's that's basically how it works that's all that's the purpose of it it's in a lot there's a lot of different malware bundles seem to have
this this particular protocol being used and it's a fairly I think is a fairly common fairly large problem yeah okay possible takedown okay so one of the ways to sort of take this down is to basically create a poison pill you find an infected host drop it into the directory and it's gonna spread automatically throughout the bot now that poison pill could kill the various processes you know like shut down the the delete the X file delete the address let's do all of that take it down you can also possibly attack it through the IP address distribution but that might be I think we'd have to do more research to find out how it selects
which peers it's going to talk to remember it gets a lot of information back it only keeps 256 so if we figure out how it does that I'm sure that can be attacked too and then you could if you didn't want to sort of kill it entirely you could always just replace the malware with files that are a little bit more benign so that's basically that's basically a yeah
no we didn't look at other than the fact that we saw it visiting all these websites and basically crawling the sites and clicking on all the links that's as far as we took it didn't didn't really pay too much too much attention to it if you want I mean someone else gets its I mean it would be pretty interesting we were more in focused on just figuring out what did this particular bot do sort of like was it you know was how did it work that said like the other malware it could download you can install it'll install whatever you whatever it's controllers give it it will install and run yeah
yeah each each system only had 256 and it would check every it would basically go through that list about every 15 or 20 minutes refreshing the list so it would wake up and go out talk to those 256 and then go back to sleep again okay and the other side effects like the click-fraud and the other thing whose were happening in separate processes and separate that was like a separate event separate process taking place yeah
I could probably tell if you want we can talk about what kinds like this after the talk I think we've only got a couple of minutes left so they probably take too long for FEMA that said we've got its we offer a malware detection service for the the service providers can offer to their customers so that would be the approach they would take the reason we did the detailed research in this is we have to understand Oh what we're detecting and we have to be able to talk to our customers which are the service providers and explain to them you know what we're seeing and why we're seeing it and stuff like that so once we've
done that that's our job done if they market that to their subscribers then they can go to a portal and get it fixed and cleaned up yeah a time frame we started looking at it at the basically beginning of December and put the paper together basically ran about the end of January kept it under covers until today this is the first time we've talked to better other than talking to Adobe about the fact that someone was
and switch t DSS that's also another one of the other names that's associated with the with with this T DSS we've good yeah I think T DSS is another nice I'm saying there's a few that we noticed with literally as I said 15,000 different samples some of that was T DSS yeah
okay so Zeus is using similar types of techniques and sweet okay so I guess I'm done thank you very much [Applause]