I'm really proud to be here for Recon.
I'm extremely scared because it's Friday the 13th and I'm presenting at 10.30.
Remove the zeros, that's another 13.
That's crazy.
So it's an honor to be at Recon.
As you see, the title of my presentation is How I Learned Reverse Engineering with Storm.
So this is an honest fact.
I've been following the Storm worm for the last year and a half and really learning from
it because every time a new sample would come out, I'd open it inside a debugger or inside
IDA and have a look and see how it was working.
So the real objective of my presentation is not to show you how good and clever I am because
I know lots of people in this room are much better than I am.
But I really want to share some reverse engineering experience.
And by the way, I also want to break some of the myths about the Storm worm because
it's not the thing that's going to kill everyone, of course.
And hopefully I will also be able to learn from your comments and recommendations that
you can send me afterwards by email or right after this presentation.
Here's a quick outline of my presentation.
I want to start with the general overview of Storm.
So this is not a technical overview, it's really a brief history.
And then I will go into the technical details and their evolution including the packer that
has been used, some rootkit and system drivers, browser exploits, et cetera, et cetera.
So there has been various names applied to the Storm worm.
The most commonly used one is Newar, which has been given by Microsoft, Trend, McAfee
and ESET.
By the way, ESET is my employer, so you see the nice logo on the right.
Symantec calls it Pecom and Kaspersky calls it Zlatan.
We have sometimes seen samples being called by other names, but they are just confusing.
They're not the good names.
For example, P, Tibs and Xpack are the name of the packer that is used to wrap around
the executable, so it's not really the name of the thread.
And same thing for FooClip.
FooClip is really the rootkit component of this thread, and it should not be used to
describe the complete executables of the Storm worm.
Now with a brief history.
The first files we've seen from Storm appeared in the fall 2006.
They were distributed as attachments to emails, and the titles of the email were something
like Nuclear War Against Iran.
So this is where Newar comes from.
And we've also seen emails with FooClip of Sadamusen Execution, so this is where the
name FooClip comes from.
But the name Storm really comes from the StormKiril.
Have you guys heard of the StormKiril?
Any people from Europe here?
No one?
Come on, there has to be at least someone.
Well, StormKiril hit Europe on January 17th of 2007, and I know that our company got really
hit badly because we lost power for a couple of hours, and there has been lots of damages.
I think two or three people died in Europe because of this storm.
But the name comes from, the Storm worm has been called like this because as soon as this
storm hit, they started sending spam saying, oh, look at the video from Storm, and then
you can double click on the executable and have lots of fun with an infected PC.
So after that, we are seeing new propagation waves of the storm worm with almost every
special date on the calendar.
For example, Valentine's Day, Easter, everything else.
So can you guys in the back still hear me?
Is everything all right?
Yeah, feeling falling asleep?
Not yet.
In terms of infection vector, storm usually propagates through email.
So this is not really interesting technically, but it seems to be the more effective infection
vectors because everybody reads their email and everybody likes to click on everything
they see.
So inside the email, you would get just a quick sentence and saying, oh, go click on
this link.
So the social engineering scheme is relatively successful.
But we've also seen other infection vectors such as browser exploits.
The file would copy itself to removable drives as installed at EXE.
So if you remove the drive, stick it in another computer, then you have chances of affecting
this new computer.
But also affiliate programs.
This is a new trend in malwares where you will have one gang that's going to pay the
gang next door for them to install your malware.
For example, if you have two botnets, the guy behind this botnet is going to pay this
one to install their malware on this one as well.
So you just double the size of your botnet.
And it works.
I mean, people are paying for that.
There are a couple of examples of social engineering because Storm is not only evolving on the
technical level.
The guys behind it are also investing time into making nice, incredible social engineering
campaigns.
For example, we had the laughing cycle kitty cat that was in Flash.
And extremely annoying to me because it has sounds and moves and it's really, really awful.
We also had the arcade game world where people would be redirected to a web page and everywhere
you click on this page, you get an executable that is, of course, a new variant of Storm.
Then around Christmas, we had some spicy screensavers.
And if you can't read there, it says, find out what is keeping Santa so jolly.
I thought that was interesting.
The most successful social engineering campaign from Storm has always been postcards, either
electronic cards, electronic postcards.
And they are coming back to this theme again and again and again.
So this is a good way to see that they are monitoring the success rate of their campaign.
And whenever a good theme is found, they will come back to it and use it again and again.
And at April's Fool, we also had some cool images.
In terms of number of infected hosts, Storm is using a decentralized network.
I'm going to give a lot more detail on that later.
But it means that all the infected hosts are not going to enter into communication with
a specific central command and control server.
So it's very hard to have a good estimate on the number of infected hosts.
So Microsoft in September released an update for their malicious software removal tool
that would help remove Storm from any PC that has accepted to run this tool.
And they claim that they disinfected 275,000 machines.
There is a slight nuance here that has to be introduced, is that these machines might
have been infected, but they didn't necessarily communicate with the rest of the botnet, because
they might have been sitting behind firewalls and things like that.
So this is really the higher bound that I could find for the number of infected hosts.
On the other hand, Thorsten Holst's team did some very good research where they would crawl
the peer-to-peer network and try to find all the infected hosts.
And their estimate is that at the lower bound, they found 6,000 machines participating into
the botnet and 80,000 as the higher bound.
And my company has a central reporting system where we receive reports of any infection
that occurs, and we receive about 10,000 detection per month.
But this is not really a number of infected hosts, because we've detected the thing and,
well, it's just an executable that was thrown at a computer.
Now the purpose of this whole operation is to create a botnet.
And the botnet has been used for various purposes.
The first one and main one is spam.
They're always sending spam with the botnet.
They've also used it for denial of service and distributed denial of service against
other gangs.
I thought it was interesting, because they're really acting like gangsters.
If they see that another gang is stealing some of their business, then they're going
to attack it.
And also they had automatic denial of service against researchers.
If you spend a bit too much time poking around at an infected computer, you might attract
their attention and receive a huge denial of service.
The rumor has it that they went out of internet for like 15 minutes because somebody has been
paying a bit too much attention to Storm.
We have propagation.
Of course, the botnet is used to send more emails.
And finally, pump and dump.
So who is familiar with this term?
That's one, two, three.
Oh, come on.
So pump and dump scams are where some malicious actor will buy stock from the stock market
and then start advertising it and hope that the price is going to raise.
So if you buy lots of stock that is worth one cent, you wait for it to get to 10 cents
and then you sell the whole bunch of them.
So that means that within a couple of hours, you can have 10 times more money than you
had before.
After that, the botnet has also been used to harvest email addresses.
So if you get infected by Storm, the malware will parse your hard drive and try to find
an email address it can find and then you will receive lots of spam.
They also participate in affiliation programs where they will install other malwares on
your computer.
For example, bankers, which is a kind of malware that will steal your bank information.
My last bullet is who knows because the operations of Storm are really well planned out and they
will never use the whole botnet for an operation.
They will only select a subset of the infected computers to, for example, perform a spam
run.
So I thought it's very interesting because it's going to be very hard to find out exactly
what the botnet is doing at every time because the infected hosts are not all doing the same
thing.
If you want to follow the rest of this presentation or take it offline and have a look, then you
will need some binaries because the rest of the presentation is about technical details.
The easiest way is probably to check your spam folder because Storm has been sending
out samples for the last year and a half.
But also if you find an infected host on your network, just make a request on the HTTP port
and you will be redirected to a page serving malicious files.
There's also Google, just search for some of the strings that you see in there, and
offensive computing.
If you guys don't know about it, it's offensivecomputing.net.
It's a very good project where you can find more analysis on Storm but also thousands
of binaries.
Now let's start with some technical details on the packer.
So this is Recon.
How many people here know what a packer is?
Excellent.
So I don't have to explain what it is.
For those who don't know, you can see it as a wrapper around the executable that will
help protect it.
The packers with Storm are very interesting because they will develop a completely new
one every time they want to do a propagation wave.
So this is clearly to evade antivirus detection and make reverse engineering a bit harder.
But it's not really that harder because the packer are really simple and efficient.
They don't want to have problems with it, they just want to change what the executable
will look like from outside, from static analysis.
And this is probably why I'm here today presenting, because the packers are not too hard to go
past them and you can basically fairly easily understand them.
So the packers are a protection mechanism for the executables.
They don't want you to look inside.
So they have implemented a couple of different tricks in there to evade antivirus detection.
As you should know, antivirus engines don't only apply static strings to match on a file.
They are now using emulators where they have a small module that will load an executable
in memory and let it run for a while and let it unpack so that they then can have a look
at the executable file in clear form or in its original form.
So the answer by Storm was to implement some anti-emulation tricks.
The first problem with emulators is that they don't implement every functionality that can
be found in Windows.
And this makes total sense because you don't want your antivirus to come with a separate
Windows distribution.
So the packer will make calls to exotic functions.
For example, in this screenshot, it's a drag accept files.
So there is no reason why an emulator would need to implement such a function.
But they make a call to it and check if the result is normal.
And you can see, or maybe you can't, on the left side, it checks the result.
And if it's not what they want it to be, they just exit process.
So that's a really small line on the left.
And on the right side, they continue execution.
Now this is not necessarily obvious to the untrained eye, but I just found it by single
stepping through the code.
And when you see a call like this inside a packer, there is no reason for it to be there
except to trick antivirus.
Or if I'm mistaken, please send me an email after the presentation.
I want to learn from you guys.
The next trick or the next step they took, because maybe this thing was a bit too easy
to spot, is that they used the result from the drag query file system call.
And they used it in the decryption of some pointers in memory.
So if you don't return the good value from this system call, then you end up decrypting
something in the wrong position and you will execute junk code.
So this is the assembly you can see on the left.
Another trick I've seen about one month ago was to load complete executables inside the
malware memory.
So the emulator is not going to go around with a copy of notepad and calc.exe.
It makes no sense.
But every computer, every Windows computer will have calc and notepad.
So this is wise of them.
So what they did is they made the system called load library for notepad and calc.
And then they check if the handles that were returned are the same.
If they're the same, then this is an emulator trying to fool around with the malware.
And otherwise, then you're on a real system and you should continue executing.
There has also been some obfuscation that I could see.
Okay.
There has also been some obfuscation.
This is a small trick that I didn't spot on the first try.
But once again, by single stepping through it and by reading it maybe 20 times, I could
finally understand I'm a slow person.
Instead of moving bytes in memory, they will change the value of the stack pointer and
then push data to a fake stack, which is actually the destination buffer.
And then they will restore the stack pointer.
So this is for instruction replacing a move in assembly.
There has been a bunch of other tricks that could be seen inside in Storm.
For example, breakpoint detection, where they will allocate a little loop on the heap, execute
it, that will parse the code.
And if they find a breakpoint, a software breakpoint, then they will stop execution.
And also, they would redirect the execution to a new memory location, making it harder
to dump memory because you're not executing the executable in its original position.
They allocate memory somewhere else and then they execute the code from there.
And now, let's move forward to the rootkit and system drivers.
So as you see in this outline, it's really nice to have time to analyze Storm because
there's a lot of stuff you can learn from.
And when I was analyzing Storm, to be very honest, I was reading the rootkit book at
the same time, and one morning I was reading, then at the afternoon I was analyzing the
code and it's the exact same thing.
So they clearly read the book before me and implemented it inside their code.
So it's great.
They implemented the rootkit only in some variants.
I think it is because it introduced a bit too much complexity into their code, but they
used it to hide the configuration file and their main executable.
And the trick I found to bypass it was to grab the original executable and make a break
point on a system call that is create file.
So whenever they create the file, you just single step a bit and then they will write
to it, close it, and afterward they will activate the rootkit.
So for a moment, you have access to all the files before they start hiding.
So that's an easy trick.
And don't forget to rename the files afterward because when the rootkit gets activated, it
will intercept calls to the drivers that will make the file invisible.
So make sure to rename the file and then you can go on and analyze it.
There has been some other functionalities as well implemented inside system drivers.
So to me that was an introduction to ring zero debugging.
In some variants, this is really small so you don't have to, I'll just explain it quickly
and if you want to take the slides offline afterward.
In some scenarios, you will get a first stage dropper in an executable that would simply
write a kernel driver to disk and then start it as a service.
So then you have a system driver that is running.
This system driver will unpack an executable, a P executable, and inject it into service.exe.
My first mistake here was to try to debug service.exe.
Not good.
It just froze my complete system.
Afterward I was able to find out that this executable that was injected into service.exe
was responsible for all the functionalities of Storm.
So for example, they were the one establishing the peer-to-peer communication and all the
other functionalities.
So this is interesting but the way I found them is even more interesting.
By simply reading the code inside the very good IDA, you can see that the PE image is
not really encrypted.
It's only encoded with an XOR key and this key is one byte long.
So the decryption loop is really small.
And by reading it you can understand how it's working.
So my first approach to find the injected code, because this is where all the functionalities
are, so this is what I wanted to dump to disk and then analyze statically, was I decided
to try the Sizer debugger.
I think this is a Chinese project.
It's a ring-zero debugger.
It has a nice GUI and everything, so you should give it a try if you haven't done that yet.
And I put a breakpoint on allocate memory.
So when they're ready to allocate memory inside the service that EXE processed, then you know
that they're up to no good and they're going to inject the code and that what you want
to have a look at has already been decoded.
But this is a bit hard and playing inside ring-zero is not really my kind of stuff.
So an easier way was to implement a small script inside IDA Python.
That is, that would just make the same decryption loop on the code I had and then dump it to
disk to a separate file.
These small bits of codes are probably not going to be extremely useful, but I'm going
to release them so if you guys want to have a copy I'll be happy to share them with you.
I've also included a link to IDA Python, which is a great tool.
And also Danny Quist from Offensive Computing has made a similar analysis from this system
driver, but on his side they decided to emulate the decryption loop with x86 EMU.
So that's another approach that could have been taken to decode the injected code.
So that's it for the system drivers.
Using some of the propagation campaigns from Storm, they tried using some browser exploits.
So a typical scenario would be that web links would be sent through email and inside this
email if you click on the link then you are redirected to a proxy which would then send
your request to a mothership that would serve malicious JavaScript.
The first thing you realize when you open up this JavaScript is that it is obfuscated.
But the obfuscation is not really hard to understand because once again it's an XOR
operation.
But they tell you because the variable is called XOR string and the plain string is
called plain string.
So I mean it's obfuscated but it's pretty easy to understand.
And they're also trying to have some nice messages.
I don't know if you guys can read this.
But yeah, they're playing around with AV companies.
So they have two functions that do absolutely nothing except insult some other companies.
And I didn't make it up.
I'm not kidding.
You can go and have a look.
They're really doing this.
So that was a good opportunity for me to learn about decoding JavaScript.
The first thing I found was to replace the eval call that is always used to evaluate
some JavaScript after it's been deobfuscated.
And I would replace this call to eval by a call to alert which would basically just bring
a message box to your browser.
But the output was way too long and it would make a really big window and I couldn't copy
and paste from it or edit it.
So since this is a very easy thing to understand that it was an XOR operation, I did a quick
Python script to XOR every byte that was there in the string.
But this is not a really generic approach.
So after looking a bit and finding on this sense diary, so the URL is there, I replaced
the eval function with this show me function that would simply make a text area at the
bottom of the page.
Instead of executing the obfuscated JavaScript, it will display it in a nice text area where
you can copy and paste from and then run all your analysis.
Is that for me?
So by analyzing the malicious JavaScript, I found out that these were the JavaScript
was trying to exploit the following security flaws inside web browsers to basically download
and install a copy of Storm.
And whenever I would see such a list, I would just wonder how do these guys find the list
of exploits that are being used?
So the lazy way is to check out OniWalk from Jose Nazario and to grip through the file
called activex.py because the script will basically call activex component with a CLSID
and then you can just grip the activex.py for the CLSID and it will give you a nice
reference to either the name of the vulnerability or a CV number, common vulnerability enumeration.
And if you don't find what you're looking for with this lazy method, you can also just
have a look at the code and see calls to weird functions because the exploit code is usually
very straightforward.
They make one or two calls and then launch the exploit.
So if you Google for these calls to activex methods, you usually find either the exploit
code or a description of the vulnerability.
And to show you how nice and clean the code is, here is a part of the decoded JavaScript.
First of all, you notice that it's all indented properly.
Once again, you have all the variable names that are extremely readable.
So for example, the first variable is called URL real exe.
So that's our original executable file.
And then you have a call to XML HTTP download with the real executable.
Afterward, they create a file name on C colon slash slash S Y S plus get ran string.
I mean, this is really easy to understand once you've been able to decode the JavaScript.
So there is no black magic in there.
You can simply either decode the JavaScript by yourself or use the text area trick to
find out what it's all about.
Now, the reason why Storm got so much attention in the beginning was because it's using a
peer-to-peer network as a command and control mechanism.
And I'm going to give you a bit more details on how this peer-to-peer network works.
There is no time here to explain everything in details, but there has been other publications,
including the one by Thorsten Hals that I referred to earlier, that can definitely give
you more details.
But the Storm peer-to-peer network is based on Kademia, which is also known or used with
Overnet or E-Donkey.
In this network, each peer is identified by a 16-byte hash, and also each information
you might search for is identified by a 16-byte hash.
These networks were really made to share files.
So for example, if you search for a Britney Spears video clip, they will make an MD4 of
your keywords you're searching for, and then they're going to search for it.
All the communications are done over the UDP protocol, and they are not using any predefined
ports.
So it's a bit of a challenge to be able to connect to the peer-to-peer network.
So in order to connect to the peer-to-peer network, a new peer needs a list of peers
to contact.
So then when you contact one of the peer that is in this list, this peer will send you a
new list of other peers you can get into contact with.
So you will repeat this process recursively until you get connected with thousands of
other machines.
Here's a really cool animation I spent the night on.
So if you have a malware, so that's the SCO, and then it comes with a list.
It gives you the coordinates, so that means their IP, their hash, and the port you should
communicate with.
Then you enter in communication with these peers, and each one of these peers will give
you the coordinates of new computers you should contact, because they are also participating
into the network.
And as you see as well, you will get connected with thousands of computers, but you will
not be connected to the complete network.
You only get into contact into enough computers to be able to communicate properly.
So this is how the initial peer list looks like for Storm.
It's stored on disk and usually has the same name as the executable.
You see that the first field is the ID of the infected system.
Second field is the UDP port it's going to bind to.
And afterward you have the list of the peers.
Each line is the description of the peer.
So the first part before the equal is the ID of the peer, so this is your 16 byte hash.
Then the eight following bytes are the IP address in hexadecimal form, and then the
port you should communicate on over UDP.
So in this case the IP address is 66.169.14.51.
By looking at the format of this peer list and by searching on the internet, I ultimately
came across the KADC peer-to-peer library, which is a C library designed for academia
networks.
By looking at the structure of their configuration file and the structure of their code, it's
the exact same thing that has been implemented inside Storm.
So I don't think that this has been made publicly before, but Storm is definitely using KADC.
So if you find something or a bug inside KADC, then you have a big but net.
Now that you're connected to the peer-to-peer network, the reason why you want to connect
to this network is that you want to search for information.
When you're searching for information on the overnet or Storm peer-to-peer network, you
first ask your neighbors about a hash.
Do you know this information or do you have this information?
If the neighbor doesn't know, then they ask their neighbors, et cetera, et cetera.
The way Storm has implemented its command and control mechanism is that every infected
computer will search for a specific hash every day.
So every day, all the infected computers are going to search for the same hash.
And the result from these search will be encrypted, and it will be the comment to the but net.
This is usually encrypted with RSA, and it contains an update location.
So every day, the Storm button will download a new executable and execute it.
And this is very powerful because you can do anything you want with the but net.
When it fetches an executable file, let's say they want to send spam the next day, then
all the information that is necessary is going to be in this new executable file.
So they didn't have to implement a whole language of communication that say, oh, if I send you
flood, this IP, et cetera.
No, they just send an update location.
It actually downloads it and executes it.
Now that you understand a bit better how the whole communication is working, I wanted to
connect to the Storm's but net and see what I could find out.
But to do so, I needed to find a bit more information from the binaries.
So first of all, I did a quick script to translate the peers from their, well, not obfuscated,
but compact format to something that could be fed into KDC.
So once again, this is a small piece of code I can release.
And after that, I came across a bit more of a complex problem, which is the hash generation
routine.
As I told you, Storm is going to generate a hash every day, and it's going to search
for it to find this hash before they would, or at the same time, and then search for this
information as well.
The problem with the hash generation routine is that it would slightly change between variants
of Storm.
And I'm still learning reverse engineering, so it's a bit of a long process to every day
reverse engineer this hash generation routine, reimplement it into something, into another
language, and use it.
So what I decided to do is to use Storm's code to generate the hashes.
What is needed to do that is to first of all unpack the binary in memory so that I could
find the hash generation routine.
Once I find this routine, I use PyDBG and PyME.
I think Pedram is over there, so if you have questions on this project, he's the one to
refer to.
And then you make a call to this hash generation routine.
So that means that you don't have to understand the complete process of hash generation.
You just have to find this function in memory and call it.
And there's a slight bit, it's a bit more complex because they don't generate only one
hash in reality.
They generate 32 of them because there is one byte that is random inside the hash generation.
So instead of calling it once, you call it 32 times and you're going to get all the hashes
you are looking for.
So I'm going to show you quickly how I did that.
So let's start with this video.
I've started using Immunity Debugger.
It's pretty nice.
If you haven't played with it yet, I strongly recommend it.
The executable I have used for this demonstration is a bit, is like a month old, so the code
might have changed a bit.
The first thing I do is I scroll down and read the code.
You see it's relatively understandable.
You can have a look later on.
But it's not doing like funky function calls and everything.
It's plain assembly, straight assembly, decoding.
So what I did is put a break point at the end of this decoding code and let the program
execute until we reach this point and then step into.
Then we hit a portion of code that has not been analyzed before, meaning that it has
been decoded.
So what I do is I hit the analyze button.
Then we see that we have more code with calls to load library and get proc address.
So this is the process where the import table is being rebuilt.
Once again, I simply put a break point at the end of this portion of code with call
EBX and let the program execute it.
So of course, this is something that is going very quickly for you.
But by simply stepping through this code slowly and trying to understand what it was trying
to do, after a couple of hours you can understand that it's relatively simple and only decoding
some assembly inside memory.
Now that we've reached the end of the import table reconstruction, we once again step into
and we reach the original entry point.
Now that we've reached the original entry point, I'm very lazy.
So to find the hash generation routine, I simply search for the first 10 bytes of this
routine.
I haven't had any problems with that yet.
It's not really nice.
I could have had a much more elegant solution, but it has worked so far.
So now I have all the information I need.
I used the script that is present in PyME that is called remote debuggy call, I think.
And I've slightly modified it to execute a variant of storm, put a break point everywhere
I needed to in order to reach the original entry point.
Once I have reached this original entry point, I use it to call the hash generation routine.
So this code is also going to be available if you're interested.
And once we've found this information, we can simply launch the script and give it as
an argument the executable that we are analyzing.
So basically, why is this useful?
It's because you can fetch a binary that you've never seen before and the only thing you have
to do is to unpack it.
And then you can use it to find the ashes that are going to be used by storm every day.
So when you're ready, you use G and then it's going to list all the ashes.
So we have all the 32 ashes we were looking for.
And that's it.
So of course, there are lots of things that could be improved with this demo.
I should change the binary match to something a bit more elegant.
Also I have more interesting unpacking techniques and save the results to something else than
printing them to the screen.
Earlier this winter, the guys behind storm made a significant change.
Well, it's not really significant, but a change that threw away lots of researchers when they
started to encode their communication.
Because before that, you could simply parse the traffic with Wireshark and decode it as
Idonkey traffic and you would understand everything.
You see the search request, search result and everything.
And they probably realized that there were too many researchers paying attention to what
they were doing.
So they tried to obfuscate their communications.
And what they did is once again, they used the XOR operator to encode all their traffic.
But the messages had the same length and the constant values are the same.
So I didn't find this, Joe Stewart did, but we had access to earlier messages.
So messages from yesterday were not encoded, they looked like this.
And then a new message today is encoded.
But they had the same length and everything.
So you could just XOR the two of them and find the key that was used.
After that, I was able to search a bit inside the code.
And when you look for calls to send to and receive from, then you see that just before
them there is a call to the encoding routine and just after them there's also a call.
So this is what the encoding routine looks like.
And the key is only 40 bytes long.
So what I did is, because you have to remember that my objective here is only to connect
to the Storm button and understand what's going on.
So what I did is I grabbed a copy of KADC, grabbed a copy of the peers, I patched the
communication routine to have the XOR before sending data and after receiving data.
And now that I have all the hashes that I want to look for, well, I just put them inside
the small program and it's going to work.
So that's it.
This is how I learned reverse engineering with Storm.
My conclusions are, first of all, that Storm's authors are reading a lot more books than
I do.
And I thank them for teaching me that much on malware this year.
But it's very hard to describe exactly what they've been doing and where they are going
because they're in constant evolution.
And the reason why this thread is really interesting is not only from the technical level, but
also for the coordination of all their operation.
For example, they will always make big operations around dates where no IT professional is going
to be working, Christmas Eve, New Year's Eve, or when there's a big storm hitting or everything.
So they have a very interesting operation.
And I think this concludes my presentation.
I've been saying a big thank you to these guys that have helped me a lot inside and
outside ESET.
And if you have any questions or comments, I will be glad to address them.
Come on.
Yes.
Q Do you consider the poison what the possibility of poisoning the network?
Yes, there has been.
The question is if I have considered poisoning the network.
Personally, I haven't, but I know that other researchers, for example, Thorson Holtz, he
did it.
He tried.
And he also measured the efficiency of his poisoning.
And yes, if you know what the ashes are going to be searched for tomorrow, then you can
try to poison it.
But you probably need a lot of bandwidth.
And what they did is that they made a custom client that will try to establish connection
with every node on the botnet, meaning that if any of them is asking for a certain information,
they are going to be the first one answering this.
So this was a good way to poison the botnet.
They did it for like a week, and then they stopped because it was only for research purpose.
And I don't think that anybody really has the legal power to do that on the long term.
But yeah, that could be a solution.
Q You mentioned that they are selecting just subsets of the botnets for a particular operation.
How do they do that?
Because all the machines are running research with the same key.
Is it at the executable level or?
The reason is I'm not sure.
I think that they can redirect some of the, because every time you make a request to update
your executable, then they know where you're coming from or what you're doing.
So when you're asking for an update, then they can probably redirect to one file or
the other to make sure that you do what they want.
Q First of all, thank you for the very valuable service you did there.
Q For the what, sorry?
Q The very valuable service that you did in the space of the inner executable.
I'd like to ask you, if you had to rank order in terms of complexity and especially finance
time, the five or six end measures that you looked into to figure out what happened, what
was the hardest thing that you cracked a priori, and what was the hardest thing that you cracked
once you went across the board?
It was, well this is for myself, right?
It would be completely different for other researchers.
But for myself it was the ring zero code because I'm not really used to playing inside the
system drivers and such.
Q I may ask a follow up question.
This data that you write folks, they were great gifted but they were not professional
scientists.
They used to be in four hashers, they used to be in XOR sites.
All this can be made much better and much more powerful.
Once you feel professional to do this, when you say please, the conversation is possible
to which you're going right now.
It could be worse, it can always be worse.
But what they have to take into account is that they want to maintain the complexity
of their creation as low as possible and as maintainable as possible.
And simply applying an XOR key to their network traffic was enough to throw researchers away
for like three weeks.
Maybe less for gifted ones.
But they don't necessarily have enough incentive to make big steps.
They're not going to make big steps in making it harder to reverse engineer because they're
already winning.
Antivirus products can detect this threat but the authorities are not spending money
to really hit this button or anything.
Do we have time for this?
Is this okay?
Yeah.
Yes, yes, yes.
And this is probably why I'm presenting here today.
But yes, this is right.
I mean, probably anyone that has really paid attention to reverse engineering has also
paid attention to software piracy protection and things like that.
Is your question, are they going to move to a more legit business or?
No, no, I mean, quite the opposite.
They may have gained their skills in space, breaking protection, and all these things
that they're doing with certain actors in software piracy protection.
Yes.
I mean, piracy is up front.
What are your thoughts rather than being professionals with that computer science background?
They might have come from an amateur background in software piracy and then through whatever
kind of product they've ever used.
They don't need to be involved.
It's a good point.
At this point, they have definitely a lot of experience in reverse engineering, and
they were able to probably reverse engineer Antivirus products to find flaws inside their
emulators.
So they definitely know about software reverse engineering.
But I think that at the moment, they're doing a lot more money than they would ever do inside
the legitimate business.
So they're just going to continue inside.
So if you have any more questions, you can take them offline or send me an email.
I will be more than happy to answer them.